Dream Test Framework. Вводная (Часть 0).

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);
  • легко интегрироваться в другие тестовые фреймворки:
    • на уровне идей - просто прочитав что-то тут :-),
    • на уровне модулей / классов / файлов - просто взяв соответствующие модули из репозитория,
    • на уровне фреймворка - использовать его целиком или частично.

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

Итак, начнём!

Продолжение следует...

быть написан на простом языке - всё ж он предназначен для тестировщиков, а не для профессиональных программистов:

  • выбираю Python;

Вот это может стать серьезной ошибкой. Особенно учитывая нацеленность на интеграцию с разными системами. Лучше подумать над тем, чтобы предостаивть широкий спектр используемых ЯП, причем с возможностью использования стандартных IDE для этих языков + возможно плагины к ним. Намного упростит работу с  решением.  К тому же, допустим, не всем удобин Python. Кто-то предпочитает Ruby, а кто-то вообще С++.

Спасибо за комментарий!

Согласен, что только Питон - это не предел мечтаний... но, не думаю, что "это может стать серьезной ошибкой".

ИМХО, добавить что-то в работающую систему гараздо проще, чем сразу делать одно и тоже на многих языках. Я, как на пример, смотрю на junit - он был реализован сначала на одном языке, потом хорошо себя зарекоммендовал, и лишь затем был портированн на многие языки. Поэтому, ИМХО, правильно начать делать на одном языке, а после того, как архитектура станет стабильной думать про развитие вширь, а не только вглубь... тем более, что я стараюсь изначально всё делать в духе ООП.