Поясню для всех, что я вкладывал в понятие Helper. Для меня - это фреймворк(и), позволяющий максимально автоматизировать мою повседневную работу, к примеру сократить время создания теста. Есть у меня утопическая мечта, сделать тестовый фреймворк, который умел бы:
• запускаться по требованию или расписанию
• прогонять тест
• формировать и отсылать отчет
• заносить ошибка в систему трекинга багов
При этом, каждый пункт будет дробится еще на много мелких, которые я пока не буду описывать.
Пункт "Запуск по требованию или расписанию"
Не проблема, есть куча подобных примочек, тот же сruise сontrol и другие...
Пункт "Прогонять тест"
Как можно максимально упростить создание теста? - нужно определенное количество библиотек, фреймворков и инструментов, помогающих в работе.
Что у меня уже есть для этого?
• фреймворк, для создания и запуска тестов в удобном мне формате (написан моим коллегой по работе)
• библиотека для автоматической генерации данных и тест кейсов (написал сам около года назад)
• фреймворк позволяющий безболезненно переходить от одного инструмента автоматизации к другому без изменения самих тестов (в процессе создания, прототипная версия уже готова и работает с тремя инструментами: HtmlUnit, WATIJ, Selenium).
Пункт "Формировать и отсылать отчет"
Есть у меня надстройка над логированием тестов, позволяющая представлять результаты в удобной форме (опять таки написанная моим коллегой). Имея ее я не парюсь над тем как сгенерировать отчет о проведенном тестировании.
Пункт "Заносить ошибка в систему трекинга багов"
Проблема не большая, главное иметь доступ к БД баг трекера, желание написать правильную и не глючную функцию по добавлению багов...
Как вы видите, кое какие "упрощалки жизни" я уже насобирал и очень хорошо, что у меня они есть. Но все же, в какой-то момент ты понимаешь, что чем больше разных примочек ты имеешь, тем больше запутываешь клубок под названием "свалка", саппорт которой - это адский труд, и тем больше ты начинаешь ценить что-то, что содержит "все в одном флаконе".
Что мы видим сейчас. Все где мы пишем тесты - это продукты для разработчиков. Для тестеров мы имеем очень ограниченное количество плагинов и IDE-шек интегрированных в тяжеловесные инструменты (причем при всем при этом IDE там страшно отстойные, по сравнению с вылизанными девелоперскими)
Вот такое у меня сегодня настроение.
Много слов и слез...
Видимо пора в отпуск :)
Сообщения
4 комментария:
А я обычно ещё оцениваю и исследую ошибку, найденную любым средством автоматизации... и только потом, если это всё-таки ошибка, заношу её в баг трэккер.
А вот делать это автоматом - много условий должно совпасть... Классно, если это возможно в вашем проекте.
Тут я согласен - это достаточно трудоемкая задача автоматическое создание багов в БТС. Её реализация у нас к сожалению только в планах, т.к. она выставляет очень большие требования к качеству самих автотестов.
Автоматическое занесение бага BTS - идея интересная.
Но вот как будут заполняться поля? Проект, важность, ответственного можно легко проставить, а название и описание?
Freiman, Каждый шаг вашего автоматического теста логируется. Значит описание бага можно взять из логов.
На счет названия тоже не проблема. Вы знаете шаг на которм свалился ваш тест, исходя из этого формулруете и название. Оно не обязательно должно быть чем-то литературным. Думаю, что если разработчик получит баг с названием: "Автоматический тест тейс провалился на шаге Создание пользователя", - то он явно поймет что к чему, тем более, что в описании бага будут все шаги и данные, что привели к сбою тестируемого приложения.
Существует более сложная проблема - это анализ дублирующих багов, и проверка является ли сбой теста реальным багом... Вот над чем реально голова болит :)
Спасибо за Ваш комментарий.
Отправить комментарий