Введение во фреймворки (Часть 1)

Автоматизированное тестирование (АТ) наиболее эффективно, когда реализовано с помощью фреймворка. Несмотря на то, что в АТ термин фреймворк зачастую используется для описания совокупности объектов, которая формирует инструмент модульного тестированиия, эта статья будет в основном сфокусирована на фреймворках другого рода. Мы обсудим типы фреймворков, которые могут быть определены как совокупность абстрактных понятий, процессов, процедур и сред, с помощью которой автоматические тесты проектируются, создаются и реализуется. Кроме того, это определение фреймворка включает в себя физические объекты, используемые для создания тестов и их реализации, а также для организации логического взаимодействия между компонентами.
Автоматизированное тестирование (и, следовательно, фреймворки) развивалось годами, формируясь и усложняясь с каждой новой фазой эволюции. Эти фазы могут быть описаны в терминах трех поколений, каждое из которых обладает набором недостатков и преимуществ, благодаря которым каждое из них остается актуальным, несмотря на новые разработки. Представленные ниже понятия обычно используются для автоматизации функционального тестирования, но в некоторых случаях их можно применить и для решения задач модульного тестирования.

Первое поколение фреймворков

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

Линейные фреймворки

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

1. Input “John” into Username textbox
2. Input “JPass” into Password textbox
3. Click Login button
4. If “Welcome Screen” exists then
5.     Pass the test
6. Else
7.     Fail the test
8. End If

В большинстве случаев использование техники «запись-вопроизведение» не может рассматриваться в качестве фреймворка или серьезного подхода к автоматизации. Тем не менее, многие согласятся с тем, что эта техника в некоторых случаях может быть полезна.

Преимущества линейных фреймворков

• Быстрота создания скриптов — не требуется много действий по планированию, уделяется мало внимания аспектам качества автотестов как ПО. Учитывая это, а также тот факт, что разработка линейных скриптов часто основывается на использовании техники «запись-вопроизведение», легко понять, что стоимость такой разработки по времени, ресурсам и деньгам может быть относительно мала.
• Короткая кривая обучаемости w — автоматизация тестирования обычно требует знания инструмента автоматизации, языка программирования, а также того, как инструмент взаимодействует с тестируемым приложением. Использование техники «запись-воспроизведение» при создании линейных скриптов автоматически создает код, который соответствует действиям, которые необходимо выполнить в тестируемом приложении. Этот код может быть затем изучен автоматизатором для получения ответов на вопросы о синтаксисе языка инструмента автоматизации, а также о том, как инструмент взаимодействует с приложением.
• Быстрое получение информации об изменениях в тестируемом приложении — это преимущество близко связано с предыдущим. Использование техники «запись-воспроизведение» предоставляет информацию об изменениях в тестируемом приложении. Например, о том как изменяются свойства объектов после действий по изменению приложения.
• Независимость скриптов — учитывая тот факт, что все используемые скриптом компоненты находятся внутри самого скрипта, отсутствует опасность изменения скрипта таким образом, что это случайно затронет работу каких-нибудь других скриптов.
• Простота обнаружения ошибок — чем более продвинутым является фреймворк, тем он сложнее. Вместе со сложностью приходят проблемы связаные с поиском источника ошибки, особенно для тех, кто не знаком со структурой фреймворка. Учитывая тот факт, что все компоненты линейного скрипта находятся в нем самом, выяснение того, где произошла ошибка, не является проблемой.

Недостатки линейных фреймворков

• Некорректное воспроизведение — в случае, когда в основном полагаются на подход «запись-вопроизведение», записанные скрипты часто не вопроизводятся правильно. Это связано с тем фактом, что подобный подход не является аналитическим. При его применении не исследуются объеты приложения и его поведение, не принимается решение о том, как лучше взаимодействовать с этими объектами и поведением. При попытке исправить ошибки воспроизведения часто применяют серию временных решений, которые затем не проходят проверку временем.
• Избыточность — линейные скрипты не обладают преимуществом повторного использования, поэтому если несколько сценариев выполняют похожие или аналогичные действия, то функциональность будет дублироваться в каждом из скриптов. В случае изменения тестируемого приложения в последующих релизах мы получим в качестве результата рост затрат на обслуживание скриптов.
• Одномерность — в нагрузку к линейности прилагается малая гибкость. Скрипты могут быть легко запущены только на одном уровне, в одном месте и единственным образом. Если тест-менеджер хочет, чтобы автоматизатор выполнил часть тестов на основе определенных приоритетов или рисков, или в другой среде, или в другой последовательности, то автоматизатору придется потратить много времени для анализа скриптов, чтобы выполнить требуемое. Следовательно, сократится время, доступное для прогона скриптов или анализа результатов.
• Скрипты сложно читать — в сязи с отсутствием повторно используемых компонентов линейные скрипты перегружены кодом. Это делает скрипты трудными для чтения и, следовательно, тяжелыми для анализа и сложными в поддержке. Кроме того, в случае, когда в скрипт необходимо внести изменения, становится сложнее определить, в каком участке кода это нужно сделать.
• Требуется более высокий уровень знаний для поддержки — это напрямую связано с отсутствием деления на модули. Модульность помогает разобраться с вопросом, за что отвечает каждый из блоков кода. Свободные объявления в линейных скриптах делают этот процесс не таким легким. Так что, когда дело доходит до анализа или отладки линейного скрипта, автоматизатор должен сначала потратить значительное количество времени на то, чтобы понять код, для того, чтобы осуществлять эффективную поддержку скрипта.

Автор: grumbler_chester