Сообщений в теме: 4

[Andrei Kulabukhau]

А давайте обсудим статью "Test Automation Frameworks" by Carl J. Nagle.

Собственно вопросы которые меня интересуют прежде всего:
1. Есть ли у кого опыть создания чего-то подобного?
2. Есть ли опыт использования упоминаемых в статье коммерческих фреймворков TestFrame и Certify? Что можно о них сказать?

Остальными мыслями обменяемся в процессе обсуждения...

Спасибо.

[Green]

Андрей,

ну и длинную статью ты выбрал для обсуждения.
:P

"Редкая птица..." - далее по тексту.
:D

[barancev]

Про TestFrame ничего не скажу. Я честно пытался разобраться, что такое Certify и чем он отличается от других инструментов тестирования.

Я пришёл вот к какому выводу: это такая НАДСТРОЙКА над существующими инструментами тестирования. То есть -- тесты разрабатываются якобы в "независимом от приложений" виде (а на самом деле, в "зависимом только от Certify"), после чего для выполнения их может использоваться в качестве движка любой из существующих инструментов тестирования или даже разные, а результаты всего этого сводятся воедино.

Вообще говоря, идея интересная, как технически (общий интерфейс, разные движки), так и концептуально (разработка тестов без программирования, чисто data driven).

Но дёгтя в этой бочке мёда полно. Изложу только основную мысль против, потому что она против концепции. Я не верю в успех "data driven" подхода ни в том виде, как он подаётся в упомянутой статье, ни так, как он реализован в Certify. Причин полно -- это не масштабируется, это трудно сопровождать даже при незначительных изменениях требований, это не позволяет автоматизировать создание тестов (а позволяет только выполнение).

Давайте посмотрим на табличку, приведённую в конце статьи в качестве примера.

Сначала посмотрим на эту табличку как она есть. Легко заметить, что там огромное количество повторений -- Login и VerifyLoginError повторяются совершенно идентично много раз, проверки выполняются одни и те же, требования к результатам похожие. Вывод: степень переиспользования вблизи нуля. На самых начальных курсах по программированию учат, что переисползование -- один из ключевых механизмов сокращения объёма работы. Повторяющаяся или похожая функциональность может быть вычленена, оформлена отдельно и использована неограниченное количество раз без дополнительных усилий. И когда нужно исправить ошибку в этой функции, её нужно исправить только в одном месте.

К счастью, эта проблема особенно остро стоит только при "ручном" составлении таких таблиц (Excel -- лучший друг data driven тестировщика). Certify в какой-то степени позволяет переиспользовать некоторые вещи. Но некоторые не позволяет. И происходит это оттого, что "не нужно программировать", основное достоинство оборачивается недостатком.

Проблема масштабируемости с одной стороны связана с низкой переиспользуемостью, а с другой стороны -- с тем, что набор табличек-сценариев всё таки определяется и разрабатывается вручную.

При большом количестве action'ов и вариантов их взаимодействия и влияния друг на друга количество сценариев нарастает как снежный ком. Из этого снежного кома дизайнер тестов вытягивает некоторые подпоследовательности, хорошо, если это делается систематическим образом, но гораздо большее количество последовательностей остаётся непротестированным. И в первую очередь вытягиваются "правильные" последовательности, а связанные с попаданием в нехорошие состояния, обработкой ошибок ввода и т.п. остаются за пределами видимости. По логике вещей, нужно генерировать тестовые последовательности из того, что называется в документе Site Application Map. Но никаких продвижений в эту сторону в инструменте Certify не видно.

Наконец, хотя это уже ворчание, пользовательский интерфейс Certify явно переусложнён, решать в нём простые задачи крайне сложно. Мы сами при разработке собственного инструмента тестирования сталкиваемся с этой проблемой. Инструмент предназначен для решения сложных задач, это такая большая пушка, поэтому для решения простых задач стрельбы по воробьям приходится заряжать снаряд, которым можно убить роту солдат. Мы боремся с этой сложностью интерфейса всеми силами и Certify'ю того же желаем!

[barancev]

Вот ещё неплохая статья на тему, специально для редких птиц, долетевших до конца предыдущей: Totally Data-Driven Automated Testing

[Mike]

Полностью согласен с Алексеем. Общие мысли о необходимости worklow и о разработке тестов в том же ключе что и разработка любых других програмных продуктов - весьма здравые. Что касается "Test Tables" - тоже можно согласиться, но только если выкинуть оттуда "Step Tables". Тестировние из excel, как его не развивай, годится для очень узкого круга задач.

Кстати, Mercury пытаестся сейчас в новой версии QTP внедрить что-то очень похожее на keyword-driven подход. Они даже переделали "Tree View" в "Keyword View" (или как-то так) - но они хоть не отказываются при этом от обычного программирования (то есть можно в одном тесте и так и так) - в случае же с "totally data-driven", тестер теряет возможность программировать, оставляе это для "гуру", которые пишут библиотеки, в результаты тесты как были убогими (если тестер - чайник), так и остаются, хоть и сделаны теперь из компонентов более высокого уровня.