Dream Test Framework (Фреймворк моей мечты :-)
Часть 0. Вводная: Мистер Фикс, у вас есть план? :-)
Уже довольно давно я занимаюсь автоматизированным тестированием и пробовал различные подходы:
- использование больших систем для тестирования (типа QTP, GH);
- использование различных утилит (типа httpUnit, jWebTest);
- создание собственного фреймворка для тестирования определённого приложения.
Обычно в проекте останавливаются на каком-то одном варианте и долго следуют в одном направлении. Изменить его довольно сложно, потому что надо существенно менять бюджет (тем более, если его надо сильно увеличивать), знания и опыт членов команды, правила взаимодействия и, как всегда, на это нет времени.
В каждом из этих вариантов есть свои плюсы и минусы. Лучше всего, для каждого проекта составить свою собственную таблицу с плюсами и минусами каждого подхода, тогда будет легко принять решение о том, какое тестирование будет лучше в каждом случае. Иногда один плюс или минус может повлиять на выбор. Давайте попробуем составить таблицу для типичного проекта.
1. Сложная и большая система для тестирования обычно:
плюсы | минусы |
|
|
2. Различные утилиты:
плюсы | минусы |
|
|
3. Собственный фреймворк:
плюсы | минусы |
|
|
Итого:
- К первому варианту добавить что-то сложно. Или есть возможность его использования или нет...
- Из второго варианта можно взять возможность использования специализированных утилит для тестирования.
- Из третьего - кастомизацию под проект, интеграцию различных утилит и внешних систем, общую идеологию.
Мне кажется, что лучше всего иметь собственный фреймворк для тестирования, который будет решать нужные задачи самым лучшим способом для проекта, быть полностью интегрированным в рабочее окружение тестировщиков, разработчиков, менеджеров и т.п. При этом, очень удобно использовать как различные утилиты, так и большие системы, если они могут помочь в определённых областях (хотя бы потому, что с ними можно быстро начать тестирование).
Вот и возникает вопрос - что надо сделать, чтобы можно было легко и просто создавать в проекте такое рабочее окружение. Cоздавать фреймворк для каждого проекта не очень удобно, и я не знаю такого, который можно было бы так использовать... ну, что ж, можно создать свой :-)
Мне хочется найти компромисный варинт:
- создать удобный для работы фреймворк для тестирования;
- добавить в него все те компоненты, которые нужны на каждом проекте;
- сделать его таким, чтобы использование лучших практик тестирования было очевидным;
- сделать его в рамках GLP v3, чтобы:
- можно было его использовать в любом проекте,
- получить конструктивную критику кода (типа code review со стороны тех, кто его будет использовать / улучшать / автоматизировать).
Мне кажется, "правильный" тестовый фреймворк должен:
- быть идеологически осованным на unit тестировании:
- каждый тест кейс - независим,
- перед каждым тест кейсом проводится инициализация тестового окружения,
- тест кейсы могут содержать любое количество тестов (asserts),
но при этом иметь особенности актуальные для тестирования, а не для разработки;
- тест должен быть связан с соответствующим bug_ом / request_ом;
- тест должен иметь severity level (выполнение тест кейса не должно заканчиваться провалом любого тест поинта);
- интегрироваться с:
- bug tracking системой (уметь узнавать состояние бага, соответсвующего test point_у);
- следить за лог файлами (очень часто ошибки в логах могут подсказать программистам причину глюков, да, и вообще, любая ошибка в логах - это плохо);
- быть написан на простом языке - всё же он предназначен для тестировщиков, а не для профессиональных программистов:
- выбираю Python как первый язык. Он довольно простой, легко ставится (во многих системах он стоит по умолчанию). В дальнейшем, можно будет расширить список языков для тех, кто предпочитает какой-то другой широко распространённый язык (например java). Или же надо будет оптимизировать какие-то подсистемы (по быстродействию / количеству используемой памяти);
- иметь веб интерфейс для удобства слежения за выполнением тестов;
- мониторить ресурсы (процессорное время / свободная и использованная память);
- уметь управлять некоторыми ресурсами (ограничивать скорость соединения, количество свободной памяти, и т.п.);
- иметь обратную связь для разработчика - сообщать про ошибки в самом фреймворке (mail / skype);
- иметь обратную связь для пользователя - сообщать про ошибки в тестах (mail / skype);
- легко интегрироваться в другие тестовые фреймворки:
- на уровне идей - просто прочитав что-то тут :-),
- на уровне модулей / классов / файлов - просто взяв соответствующие модули из репозитория,
- на уровне фреймворка - использовать его целиком или частично.
Планируется цикл статей, описывающих каждую часть данного фреймворка, которые будут появляться по мере появления этих самых частей.
Итак, начнём!