Автоматизированное тестирование: ожидание vs реальность
Новые темы форума тестировщиков
Оригинал публикации: http://bytextest.ru/2017/06/20/autotest-vs-reality/#more-5727
Большинство занимающихся тестированием хоть раз испытывали желание нажать «волшебную» кнопку и смотреть, как программа все делает сама. Все любят автоматизацию. Это быстро, надежно, позволяет оптимально использовать ресурсы за счет работы ночью и не требует вмешательства человека. Казалось бы, наконец найдено решение проблемы эффективности.
Реальность: Автоматизация занимает много времени, денег и, самое главное, терпения. Написание скрипта автоматизации требует от тестировщика знания сферы деятельности, автоматизации тест-кейсов и возможности выбрать соответствующий фреймворк. Автоматизация, как и разработка приложений, нуждается в тестировании. Скрипты, написанные с помощью автоматизации, необходимо тщательно проверить, используя все тестовые данные и негативное тестирование. Инструмент, не прошедший такое тестирование, приводит к ошибкам в скрипте во время работы.
Читать публикацию полностью... итерация по переменным 2017-07-12 10:43 Всем привет! Вопрос по Python: в файле func.py есть функция, в файле config.py есть несколько словарей (keys1, keys2, ... keys n), в файле start необходимо вызывать функцию из func.py и подставлять в качестве аргумента словарь из config.py. Как сделать такой цикл, что бы итерировать все словари из файла? Manual Test Engineer 2017-07-12 11:18 Международной Компании очень нужен Специалист для ручного тестирования с опытом.
Гарантируем: Интересные проекты, оборудование, выпускаемое в промышленное производство, комфортные условия работы, гибкий график, расширенный социальный пакет и, конечно же, достойный уровень заработной платы (1500-2000$) .
Обязанности: · Анализ уже реализованной функциональности, известных дефектов и запросов пользователей. · Воспроизведение дефектов по описанию проблем от пользователей. · Разработка функциональных тестов, включающих в себя тестовые сценарии и наборы контрольных примеров. · Поддержание тестовой среды в рабочем состоянии, периодическое выполнение тестов, анализ результатов тестирования, регистрация дефектов.
Что мы ждём от Вас: · Высшее техническое образование; · Реальный опыт разработки тестовых планов (желательна презентация с реальным примером); · Владение основными средствами тестирования (issue tracking, testmanagement systems); · Ориентированность на понимание интересов конечного пользователя, умение их формулировать и мотивированно отстаивать перед разработчиками; · Знание английского языка, достаточное для письменного и устного общения на технические темы с тестировщиками, разработчиками и представителями заказчика; · Умение работать в команде в условиях коллективного владения продуктами разработки (спутниковая навигация, геодезия); · Здорово, если есть опыт автоматизации тестирования; · Нацеленность на долгосрочную перспективу.
Ждём Вас!
Ксения Соколова, sokolova@dp-hr.ru Выбор тестовой стратегии 2017-07-12 13:09 Всем привет!
Возникло разногласие с коллегами по поводу тестовой стратегии и оптимального покрытия тестами функционала приложения. Заказчик ждет предложение от нас.
Приложение трансформирует JSON объекты из одного формата (#1) в другой (#2). Для каждого поля есть подробная документация с правилами трансформации. Типов JSON объектов (поле "type") - более десятка, для каждого типа есть обязательные и опциональные поля.
К примеру, JSON из формата #1
{
"type": "Person",
"firstName": "Ivan",
"lastName": "Ivanov",
"age": 20,
"description": "Ivan Ivanov is ...",
"hobbies": null,
"education": [{"BSU"}, {"BSUIR"}]
}
будет трансформирован в
{
"type": "Person",
"name": "Ivan Ivanov",
"personAge": 20,
"description": "Description: Ivan Ivanov is ...",
"education": {"BSU, BSUIR"}
}
Поля, выделенные жирным - обязательные для формата #1.
Т. е., у некоторых полей может поменяться название ключа, значение, некоторые поля с пустыми значениями/null игнорируются, массив может преобразовываться в объект и наоборот.
Вопрос: как оптимально протестировать такие трансформации?
В планах это делать с помощью автоматизации.
Мое мнение: использовать JSON схемы для тестирования и структуры и значений полей. Для каждого типа объекта создать базовую схему, которая включает обязательные поля. Для каждого опционального поля создавать отдельную схему, которая наследуется от базовой и включает это поле. Таким образом, проверяется, что после трансформации получаем правильную структуру JSON объекта. Для тестирования значений полей можно использовать эти же схемы, в которых указывать какое значение ожидаем.
В итоге имеем следующие отдельные тесты на структуру и на значения полей:
- Позитивные тесты только с обязательными полями. Граничные значения, классы эквивалентности, спецсимволы и т. д.;
- Негативные тесты только с обязательными полями. К примеру, отсутствующее обязательное поле, недопустимые значения;
- Позитивные тесты на обязетельные поля + одно опциональное поле. Здесь тестируется только опциональное поле. Граничные значения, классы эквивалентности, спецсимволы и т. д.;
- Негативные тесты на опциональное поле. Недопустимые значения.
Плюсы: атомарные тесты. Если сломалась трансформация только для одного опционального поля, упадут только тесты, связанные с этим полем. Легко и быстро добавлять новые тесты. Если добавилось одно обязательно поле, достаточно добавить его в базовую схему и создать несколько отдельных тестовых методов для него. Проверяется структура объектов. Большое покрытие проверок значений полей (и позитивные и негативные).
Минусы: большое количество схем, которое необходимо хранить в проекте и большое количество тестов - на каждое поле несколько позитивных и негативных тестов.
Мнение коллег: достаточно создать несколько JSON объектов для каждого типа с максимальным количеством полей каждый, где комбинировать разные значения для значений этих полей. Тестировать только позитивные кейсы. Структуру не тестировать вообще.
Плюсы: небольшое количество тестовых методов и данных.
Минусы: если ломается трансформация одного поля, упадут все тесты, где используется тестовый JSON объект с этим полем. Из-за этого не узнаем, работает ли трансформация для других полей. Если не тестировать структуру, вполне возможно, что из-за бага могут появится лишние поля.
Какой подход вы бы выбрали? Если никакой из предложенных, поделитесь идеями, как бы вы организовали тестирование таких трансформаций?
Нагрузочное тестирование, удаленно. 2017-07-12 13:23 Есть ли вакансии нагрузочного тестирования на удаленку (и наши, и иностранные заказчики)? Сильный ли дефицит? Сейчас на этапе выбора пути "эволюционирования" - автоматизатор/нагрузочник и возможность перейти на удаленку через 3-4 года - существенный фактор для меня. tsung пример конфига с https и basic авторизация 2017-07-12 17:12 Всем привет. Может у кого есть пример конфига tsung с запросом по https и главное с Authorization: Basic. Буду благодарен. Или может ссылка где описано. Техники и инструменты поиска и оформления дефектов, начало 14 июля 2017-07-12 18:03 Онлайн-тренинг, 2 месяца занятий, 9 занятий, 23 практических домашних работы, постоянные консультации тренера в скайп-чате тренер: Ольга Назина (Киселева) Все ли вы знаете о техниках поиска багов? Как найти то, что мелькнуло лишь раз? Как воспроизвести проблему по невнятному описанию пользователя «У меня все сломалось»? Какие предположения строить? Что уточнять? В рамках курса мы создали специальный «бажный» сайт для тестирования. Внедрили туда 20 разных по типу ошибок. Чтобы их найти, придется применять разные техники и инструменты: — Собрать логи. — Проверить консоль JS. — Найти граничные значения. — Пройтись по туру, отмененному из-за дождя. — Проверить разные браузеры. — Убрать ограничение, установленное на клиенте. — … Сервер поднят на linux-е, куда у студентов есть доступ на чтение логов. Это позволяет применить полезные в будущем инструменты:
Еще на курсе будут использоваться:
Курс запускался в два этапа — год назад вышла первая версия на 4 занятия. Мы рассказывали только то, что не зависит от “веб — не веб, линукс — не линукс” итд. Как искать, локализовывать и оформлять задачи. Материала было много! По отзывам студентов: Ого, сколько материалов и заданий! Скучать не придется. А текст задания: "Меня обманули и обесчестили, я разворачиваюсь и ухожу." развеселил)) Но курс должен не только веселить, но и учить. Общаясь с ребятами, мы поняли просто “найти и локализовать” неинтересно. Это ведь все умеют, мы занимаемся этим каждый день. Интересно другое: — Как понять, кто именно сломался, если системы интегрированы? — Как доказать подрядчику, что проблема именно на его стороне? — Что делать, если ошибку уже пропустил? Или технические штуки, которые пригодятся в дальнейшем: — Залезть на сервер linux, найти нужный лог, изучить стек-трейс. Все это теперь есть! Мы расширили курс, теперь там девять уроков вместо четырех. И 27 домашних задания — чтобы как следует закрепить материал. Приходите к нам, если хотите взглянуть на “обычный” процесс поиска и локализации багов по новому. Подробное описание с примером видео-лекции © 2010 | Software-Testing.Ru |
| В избранное | ||
