t.me/atinfo_chat Telegram группа по автоматизации тестирования

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


(Mykhailo Poliarush) #1

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

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

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

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


(KaNoN) #2

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

  • выбираю Python;

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


(Yuka) #3

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

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

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