Перейти к содержимому

Публикации EugeneL

14 публикаций создано EugeneL (учитываются публикации только с 29 марта 2023)


#169310 Инструменты для тестирования веб-сервиса, использующего протокол STOMP

Отправлено автор: EugeneL 05 ноября 2018 - 11:51 в Инструменты и технологии

Добрый день, коллеги.

 

Подскажите, пожалуйста, есть ли инстурменты, которые позволяют тестировать веб-сервисы, реализованные на протоколе STOMP (http://stomp.github.io/). 

Я знаю, что существуют программные библиотеки, но меня интересуют инструменты с интерфейсом пользователя, вроде SOAP UI или Postman.




#169078 Начинающий Automation Lead vs Его Команда

Отправлено автор: EugeneL 22 октября 2018 - 11:59 в Управление тестированием

@Clipsa, худо-бедно, мы сработались. Rolling-over проект, который мне достался, был продлен еще 2 раза.




#166139 Создание отчета о выполненных тестах в SOAP UI 5.4.0 OS

Отправлено автор: EugeneL 10 мая 2018 - 08:00 в Тест-дизайн и ручное тестирование

Проблема решена.

На официальной странице SmartBear не была указана правильная структура pom.xml, поэтому т.к. я заполнял по аналогии с примером, мой файл был неправильный.

 

У меня не получается приложить свой pom.xml, чтобы можно было сравнить "как было" и "как стало", поэтому даю ссылку на статью, которая помогла мне в решении проблемы https://www.aviocons...pui-tests-maven

 

Уважаемые администраторы, пожалуйста, перенесите эту тему в форум, посвященный автоматизированному тестированию.




#166122 Создание отчета о выполненных тестах в SOAP UI 5.4.0 OS

Отправлено автор: EugeneL 09 мая 2018 - 07:49 в Тест-дизайн и ручное тестирование

Добрый день, уважаемые коллеги.

 

Возникла необходимость протестировать веб-сервис. Т.к. тест предполагался небольшим, а сервис изменяется очень редко, то был выбран SOAP UI в качестве инструмента. Тестовый проект был создан, успешно синтегрирован с maven при помощи плагина "soapui-maven-plugin" фирмы SmartBear.

 

Однако, оказалось, что SOAP UI не генерирует отчетов о тестировании после запуска тестов. Сам результат выполнения тестов хранится в виде текстовой информации в логе.

 

Подскажите, сталкивались ли Вы с похожей проблемой? Может, у Вас есть идеи, как ее возможно решить?

 

Вспомогательная информация.

Тесты запускаются из консоли командой

 mvn com.smartbear.soapui:soapui-maven-plugin:5.4.0:test

 

pom.xml приложен к сообщению




#165850 Можно ли синхронизировать несколько запросов средствами JMeter?

Отправлено автор: EugeneL 19 апреля 2018 - 08:43 в JMeter - Тестирование производительности

@APC Благодарю за помощь, с пайпами синхронизовать потоки получилось "на ура", тест-план (jmeter-овский) удалось ужать до 3-ех TG

 

@Spock Мне не нужно было проверять правильность, мне нужно было проверить, выдержит ли веб-сервис определенное количество обращений в единицу времени на чтение/запись.




#165759 Можно ли синхронизировать несколько запросов средствами JMeter?

Отправлено автор: EugeneL 16 апреля 2018 - 08:47 в JMeter - Тестирование производительности

Добрый день, коллеги.

 

Пробую пртестировать производительность веб-сервиса, который записывает/возвращает информацию. Запись в сервис идет через несколько Thread Groups параллельно. Есть необходимость проверить возврат информации. Проблема в том, что по SLA сервис отдает информацию через Х секунд после записи (Х фиксированно), т.е. нет гарантии, что сразу после записи информация будет доступна на чтение. Можно ли как-то синхронизировать процесс записи/чтения информации средствами JMeter, чтобы условие доступа к информации сохранялось?

 

Пока у меня есть одна мысль: сохранять время записи порции информации в Properties. Потом пробовать получить идентификатор порции по позиции времени Х секунд назад. Если идентификатор вернулся, то читаю блок, если не вернулся, ничего не делаю. 

Сознательно допускаю упрощение, что за одну единицу времени (секунда, миллисекунда) можно записать один идентификатор.

Есть сомнения относительно эффективности такого подхода, т.к. этот вариант, скорее всего, не очень быстрый, JMeter Properties захлямлятся, и будет трудно перезапускать Тест План.

 

Подскажите, а как бы решали похожую проблему Вы?




#163987 Page Object и одинаковые локаторы

Отправлено автор: EugeneL 09 декабря 2017 - 15:33 в Selenium - Functional Testing

@TatyanaV, @MrArty

 

Спасибо за ответ. Я думал ранее о чем-то таком, но меня смущало (и смущают до сей поры) 2 момента:

- аннотированные переменные-члены в Java не наследуются от суперкласса, если они не объявляены с аннотацией @Inherited;

- y аннотации @FindBy такой аннотации нет.

 

Соответственно, я предполагал, что переменные абстрактного суперкласса не будут видны WebDriver-у при работе с его потомками.




#163665 Page Object и одинаковые локаторы

Отправлено автор: EugeneL 22 ноября 2017 - 13:21 в Selenium - Functional Testing

можно общие части выделять в отдельные объекты и потом в пейдж-обжектах наследовать

А могли бы пример привести?

Я занимался тестированием веб-приложений при помощи Selenium Webdriver, но использовал Page Object с разметкой элементов при помощи аннотаций




#163628 Похвалите/поругайте подход к организации тестирования на проекте.

Отправлено автор: EugeneL 21 ноября 2017 - 09:53 в Управление тестированием

 

1. Много багов на проде (18% от общего числа), клиенты начинают уходить.

Как считаются эти проценты? Насколько критичны эти баги для клиентов?

 

Я посчитал. В багтрекере есть поле "Внешний/Внутренний". По приоритетам не смотрел, но гляну обязательно -- это хорошая идея.

 


Коллеги, подскажите, пожалуйста, в чем лучше всего рисовать? Слышал, что MS Project и Gannter - удобные средства, но они, к сожалению, недоступны.

Что именно рисовать?

 

Извините, смысл моего вопроса потерялся после нескольких правок.

От меня просят нарисовать что-то вроде Project Roadmap. C вехами/milestones, их содержанием и зависимостями, я уже определился. Теперь надо визуализировать, чтобы вышестоящему начальству показать.




#163625 Похвалите/поругайте подход к организации тестирования на проекте.

Отправлено автор: EugeneL 21 ноября 2017 - 09:13 в Управление тестированием

Изначально цель тестирования определяют владелец продукта и маркетинг, чуть позже - техподдержка. А Вам известны их цели?

 

А зачем маркетингу тестирование вообще?
Мы, наверняка, с их точки зрения вообще лишние)

 

Удалось прояснить причины введения отдела тестирования:

1. Много багов на проде (18% от общего числа), клиенты начинают уходить.

2. Если качество будет лучше, клиенты будут оставаться, и, в перспективе, рекомендовать наш продукт.

 

Коллеги, подскажите, пожалуйста, в чем лучше всего рисовать Project Roadmap? Слышал, что MS Project и Gannter - удобные средства, но они, к сожалению, недоступны.




#163623 Похвалите/поругайте подход к организации тестирования на проекте.

Отправлено автор: EugeneL 21 ноября 2017 - 09:06 в Управление тестированием

 

Плюс, специфика софта такая, что в ручную его тестировать достаточно утомительно: это -- консольное приложение для пакетной обработки файлов.

1. надо ли вам тест-кейсы вообще?
2. файлы для обработки приходят от клиентов?
Предположу, что узкое место - подготовка тестовых данных.

 

Все-таки от тест-кейсов решили отказаться, вместо них будем использовать таблицу с колонками, которые позволяют идентифицировать фичу, выяснить, какие поля документа затрагиваются, и понять какой результат должен получиться на выходе. Попробовал сделать в гуглодоке, получилось достаточно наглядно.

 

 

 



#163478 Похвалите/поругайте подход к организации тестирования на проекте.

Отправлено автор: EugeneL 13 ноября 2017 - 16:02 в Управление тестированием

 

Плюс, специфика софта такая, что в ручную его тестировать достаточно утомительно: это -- консольное приложение для пакетной обработки файлов.

1. надо ли вам тест-кейсы вообще?
2. файлы для обработки приходят от клиентов?
Предположу, что узкое место - подготовка тестовых данных.

 

1. В классическом виде, я не думаю. Т.к. кейсы будут отличаться только параметрами файлов с документами. В перспективе хотел использовать чек-лист use-case-ов, и нотацию Геркина как living documentation.

2. Да. Модель очень похожа на 1С-франчайзи: есть базовая версия, которая была внедрена клиентам фирмы. Но пара клиентов захотели внести изменения в базовую версию. Наша команда работает над версиями, которые модифицируются под крупных клентов.

 

Кстати, сейчас подготовка тестовых данных достаточно трудоемка. Есть несколько идей, как это оптимизировать. Пока, самые легкие решения:

- работать с чистой базой (это выглядит непросто, т.к. devops не горит желанием давать доступ к тестовым серверам);

- добавить timestamp c миллисекундами в поле-ключ тестовых данных (это труднее, т.к. придется работать с файлами из тестовых скриптов, и дольше).

Пока я склоняюсь к первому варианту.

 

В воздухе витает идея перейти на микросервисную архитектуру, тогда можно было бы ограничиться SOAP/REST запросами в Soap UI/Java + Rest Assured, но эта миграция находится на уровне концепции: даже PoC нет.




#163476 Похвалите/поругайте подход к организации тестирования на проекте.

Отправлено автор: EugeneL 13 ноября 2017 - 14:00 в Управление тестированием

А цель то всей этой движухи какая?

 

Целей несколько:

 

1. Уменьшить количество дефектов, приходяхщих с Production Environment.

Понимаю, что с автоматизированным тестированием цель слабо корреллирует, но это -- идея Solution Architecht'a, и так или иначе тестовые скрипты писать надо будет. С другой стороны, я до этого по канбану (о смысловом дрифте понятия "канбан" я в курсе, прошу не придираться) работал, и справлялся. Риски примерно осознаю.

Плюс, специфика софта такая, что в ручную его тестировать достаточно утомительно: это -- консольное приложение для пакетной обработки файлов.

 

2. До настоящего момента тестированием занимались либо программисты, либо сейлсы либо менеджеры по работе с клиентом. Отдел тестирования также решили создать, чтобы тестированием продукта занимались тестировщики, а не первый попавшийся человек из команды. Сейчас разработчиков - примерно 10 человек, тестирвщиков планируют нанять еще 3-ех. Т.е. удастся избежать ситуации, когда команда тестирования становится "узким местом".

 

3. Инициатива с тестированием исходит от Solution Architecht'a, поэтому нужно будет убедить бизнес, что команда тестирования нужна. Убеждать планирую с помощью отчетности (например, показать, что количество дефектов с продуктива уменьшилась, или, например, карту покрытия функционала тестами) и путем выполнения п. №1.

 

P.S. спасибо за ссылку на презентацию, чуток позже гляну.




#163461 Похвалите/поругайте подход к организации тестирования на проекте.

Отправлено автор: EugeneL 13 ноября 2017 - 09:08 в Управление тестированием

Добрый день, уважаемые коллеги.

 

Не так давно меня пригласили работать в небольшую продуктовую фирму, где до этого момента не было отдела тестирования. От меня ожидается постановка процесса тестирирования, и я хотел бы посоветоваться с Вами относительно шагов, которые я хочу предпринять на проекте.

 

1. Разработка осуществляется по итерациям. Т.к. процесс разработки идет активно, я планирую включать в scope
а) задачи текущей итерации;

б) задачи улучшения средств тестирования;

в) неохваченные (в плане тестирования) задачи из прошедших итераций.

 

2. Процесс примерно я представляю так:

а) выяснение требований в рамках конкретной User Story;

б) ручное тестирование User Story с документированием; на выходе этого шага я хочу получить тест-кейс и проверенную User Story;

в) автоматизация сценариев, которые еще не были автоматизированы (имеется в виду те сценарии, которые можно автоматизировать). Т.к. из тестировщиков на проекте только я, то я полагаю, что автоматизация будет запаздывать.

 

3. Предоставление информации о тестировании.

Я планирую предоставлять матрицу прослеживаемости (Traceability Matrix) и отчет о тестировании (Test Results Report).

Еще, планирую составить план тестирования и план проекта по автоматизации тестирования (или этот второй -- лишний?).

 

4. Состав команды.

Пока на проекте я один. В планах увеличить размер отдела еще на 3-ех человек. Поэтому, я хотел бы сделать уклон в автоматизацию, чтобы иметь уже покрытые

 

В качестве инструментов я планирую использовать:

1. Тест-кейсы держать в Google Docs;

2. Баг-трекер: Jira. Плагинов нет, но, быть может, что-то добудем.

3. В качестве инструментов автоматизации, использовать Java+Cucumber+(Webdriver/RestAssured). Почему именно Cucumber? Для него есть плагин, который позволяет получить матрицу прослеживаемости и список выполненных тестовых сценариев.

 

В заключение, хотел бы спросить Вашего совета:

1. Как Вы считаете, достаточно ли будет Traceability Matrix и Test Result Report (составленный по методологии ISTQB)?

2. Подскажите, есть ли средства, которые позволяли бы хранить информацию о тестовых сценариях выполненных/проваленных сценариях, связях тестовых сценариев с дефектами?

3. Есть ли средства, которые могут облегчить составление отчетности?

4. Какую технику использовали бы Вы для изучения требований на проекте? Я сейчас думаю насчет эксельки или карты интеллекта. Больше склоняюсь ко второму, т.к. эксельки часто громоздкими получаются.

5. Подскажите, какие метрики лучше использовать для определения прогресса тестирования? Я бы хотел использовать покрытие функционала, но в этом случае трудно определить итоговый объем работ, т.к. это - набор User Story из Jira.

 

Заранее большое спасибо.