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

Часть 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

Ориентированная на данные версия этого скрипта будет использовать информацию из внешнего источника (электронная таблица, база данных, XML-файл и т.д.), примерно такого, как показано ниже.

Доработанная с ориентацией на данные версия линейного сценария показанная выше, может выглядеть следующим образом:

1. Open Data Table
2.     Input <NameParameter> into Username textbox
3.     Input <PasswordParameter> into Password textbox
4.     Click Login button
5.     If “Welcome Screen” exists then
6.         Pass the test
7.     Else
8.         Fail the test
9.     End If
10. Close Data Table

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

Преимущества ориентации на данные

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

Недостатки ориентации на данные

К недостаткам подобного подхода можно отнести следующие аспекты, унаследованные от линейных скриптов (см. Часть 1):

• Избыточность.
• Одномерность.
• Сложность для чтения.
• Требуется более высокий уровень знаний для поддержки.

Автор: grumbler_chester