Aвтоматизированный генератор тестовых скриптов, основанный на модели

В этой статье представлено вступление в новый способ генерирования тестовых скриптов для тестирования GUI (основанного на web или rich клиентах) используя model-based подход, а также описание того, как это меняет процесс тестирования. Описанный инструмент для генерирования тестовых кодов (Abstract Testing Tool) был разработан автором, при сотрудничестве с одним из наших клиентов. Сгенерированный код для автоматизации может использоваться для тестирования рабочих характеристик или функционального тестирования.

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

Вступление

Наиболее часто используемым способом создания тестовых скриптов для тестовых инструментов все еще (к сожалению) является „capture and replay “, хотя уже неоднократно демонстрировались преимущества того, чтобы обращаться с автоматизацией тестирования так же, как и с проектами разработки программного обеспечения. В подходе с использованием “capture and replay”, тестовый инструмент просто записывает действия пользователей и генерирует из них скрипт, который может использоваться для выполнения тестов. Этот подход имеет несколько недостатков. Каждый шаг должен фиксироваться каждый раз, когда генерируется скрипт, даже если этот шаг содержится в каждом скрипте. Хотя уже были разработаны инструменты с применением модулярного подхода, для них все еще необходимы глубокие познания инструмента тестирования и языка скриптов, из-за существующей необходимости адаптировать тестовые скрипты после их сбора из комплексных приложений, для того, чтобы сделать скрипты более устойчивыми.

С этой проблемой можно справиться, используя уровень абстракции, который мы будем называть “Abstract Testing Tool (ATT)”. ATT представляет уровень абстракции, разделяющий инструмент тестирования и тестовый скрипт и вводит представление тестируемой системы (System under Test (SUT) со всеми ее страницами и путями навигации, а также языком мета скриптов. Тестировщик генерирует скрипты путем навигации по SUT в GUI, предоставленном ATT.

Уровень абстракции

В этой части мы коротко расскажем, как создать уровень абстракции инструмента. Будут даны пояснения на следующие темы: модель test object , тестовый скрипт и генерирование кода.

Test Object Model содержит представление SUT со всеми ее страницами и путями навигации. Тестовые скрипты – скрипты, тестирующие приложение с помощью навигации, используя пути навигации, которые сохранились в модели объекта теста. Генерирование кода – процесс создания скриптов для тестовых инструментов, объединяющий тестовые скрипты иtest object model.

 

Test Object Model

Рис. 1: Test object model

Модель test-object является абстрактной моделью, представляющей объект теста. Минимум, требуемый от нее – содержание возможного взаимодействия в SUT (действия), что сформирует тестовые скрипты. Например, на веб сайте таким взаимодействием были бы клики на ссылки или кнопки. Действие в модели объекта должно содержать каждый компонент (например, параметры ссылки) который должен быть выполнен.

Страницы и механизмы для проверки должны также быть частью модели объекта теста. Страницы представляют стартовую и конечную точки для действий. Например, google.com и результаты поиска могли бы быть страницами, в то время как кнопка поиска (со всеми необходимыми параметрами) были бы действиями, ведущими со стартовой страницы к странице результатов поиска. Объекты проверки являются механизмами, проверяющими точность конечных точек действий. Как правило, объекты проверки являются набором последовательностей, картинок или других элементов, являющихся частью конечной точки. Например, для действия поиска Google, ожидаемый перечень результатов мог бы быть проверочной последовательностью. Если конечная точка действия не содержит действия поиска, проверка не будет успешной. Объекты проверки могут быть связаны или с действиями или со страницами. Также существует много различных возможных типов, таких как позитивные или негативные проверки и так далее. Следовательно, модель может быть произвольно комплексной. Например, события могут быть добавлены к проверке для реакции на ошибки. Возможными реакциями могли бы быть ошибочный вход, создание скриншотов или снимков среды.

Тестовые скрипты

Тестовый скрипт, в основном является перечнем действий, которые были определены в объекте теста. Язык мета-скриптов, сам по себе, может создаваться различными способами (Domain SpecificLanguage), но он должен быть таким, который может прочитать человек (не то, чтобы разработчики не были людьми, но мы уже отклонились …).

Тестировщик должен иметь возможность создавать тестовые скрипты, используя GUI. Использование диаграмм деятельности UML для представления тестовых скриптов в GUI может быть быстрым способом создания таких GUI, но может вести к проблемам с точностью, потому что редакторы UML не созданы для создания скриптов.

Собственный язык привнесет больше гибкости и точности. Но диаграммы деятельности также могут использоваться для визуализации вашего собственного языка.

Рис. 2: тестовый скрипт

Далее следует пример того, как может выглядеть язык скрипта. «Скрипт» объекта является корневым узлом и содержит много шагов.

Примером XML может быть:

{syntaxhighlighter brush: bash;fontsize: 100; first-line: 1; }<script> <step link=”technical or functional key from the test object model”/> <operation/> <step link=”technical or functional key from the test object model”/> </script>{/syntaxhighlighter}

Шаг является действием, которое пользователь может выполнять в рамках приложения. Каждому шагу необходима ссылка на действие из модели объекта. Очень важно различать шаги и действия потому, что действия уникальны (например, существует только одно действие для выполнения поиска в Google), но одно действие может иметь ссылки на многие шаги в скрипте (один поиск вGoogle может выполняться несколько раз в одном скрипте).

Операции представляют контрольные структуры, которые могут повлиять на течение скрипта или команды, которые необходимо выполнить. Комплексные структуры должны выполняться в форме вложений (например, если – else, loop exit, log, delay, run, wait Until, skip, store, check).

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

{syntaxhighlighter brush: bash;fontsize: 100; first-line: 1; }<operation type=”definition” > <step link=”…” /> <step link=”…” /> <operation type=”…” /> </operation>{/syntaxhighlighter}

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

Рисунок 3. Объединение обьекта тестовой подели и тестового скрипта

Уровень абстракции для генерирования кода

Этот раздел описывает как модель объекта теста и тестовый скрипт трансформируются в исходный код (для тестовых инструментов) или документов. Движок генератора необходим для слияния модели объекта теста и тестового скрипта. Выход генератора является графом объекта, который будет использоваться в качестве ввода для создания самого исходного кода теста. Этот механизм очень важен для изменения контента до того, как он будет отправлен на движок шаблона (шаблон будет описан в следующем абзаце). Рисунок 4 является визуализацией объединенных модели объекта теста и тестового скрипта.

 

Рисунок 4. Интеграция обьектной тестовой модели и тестового скрипта

Движки шаблона (например, Velocity, Xpand или Hamlets для Java) могут использоваться для того, чтобы сгенерировать код. Эта технология имеет преимущество наличия высокой степени гибкости. Движок может использоваться для конвертации графа в желаемый формат. Шаблоны должны разрабатываться для каждого желаемого формата. Например, один шаблон может быть создан для генерирования кода HP LoadRunner, а другой может генерироваться для создания кода Micro Focus SilkPerformer. В любом случае, язык шаблонов имеет тенденцию к не слишком высокому качеству .Следовательно, код шаблона должен быть структурированным и модулярным. Языки шаблона не предназначены для комплексной логики. При необходимости создания комплексной логики, это может быть делегировано целевым языкам программирования (например, C или Java) путем создания вызова функции.

Помните о следующих моментах:

Не повторяйте себя (DRY)

Наиболее важной частью является создание модели объекта теста, которую можно будет использовать избегая излишеств.

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

Все должно быть просто(KISS)

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

Не забывайте о контроле версий

Изменения модели и языка скрипта могут иметь место при каждом выпуске или внедрения SUT. Многие люди должны иметь возможность создавать скрипты и вносить изменения в модель. Зачастую это является источником ошибок. Изменения должны отслеживаться и иметь возможность восстановления предыдущего состояния. Контроль версий является основной характеристикой.

Каким образом инструмент меняет и усовершенствует процесс теста?

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

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

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

Ниже указаны некоторые преимущества ATT:

  • Тестовые скрипты генерируются независимо от используемого тестового инструмента
    • Возможно использовать одни и те же тестовые скрипты на разных этапах теста (например, тестовые скрипты могут генерироваться для различных инструментов тестирования рабочих характеристик для этапа тестирования рабочих характеристик, а различные скрипты для инструментов автоматизированного тестирования могут генерироваться для этапа функционального тестирования). Это значительным образом меняет процесс теста. Как правило, одна команда занимается генерированием и выполнением тестовых скриптов для каждого этапа теста. С подходом ATT, одна команда может нести ответственность за генерирование тестовых скриптов для всего процесса тестирования, в то время как команды тестовых этапов должны быть ответственны только за выполнение скрипта и анализ.
    • В случае изменения инструмента тестирования (например, переход от одного продавца к другому) все тестовые скрипты могут быть использованы повторно. Использование нового инструмента тестирования требует разработки нового шаблона и повторного генерирования тестовых скриптов, используя этот новый шаблон.
    • Регрессионные тесты могут определяться независимо от инструмента тестирования и использоваться с любым инструментом тестирования.

  • Изменения в SUT не требуют прямых изменений в тестовых скриптах ATT.

  • В случае необходимости изменений модель test object должна быть адаптирована, и тестовые скрипты могут генерироваться. Это значительно снижает необходимость действий, необходимых для поддержки, так как изменения необходимо производить только в одном центральном месте ( test object model).
    • Тестовые скрипты могут генерироваться без специфических знаний инструментов тестирования и используемом языке программирования.
    • Адаптация тестовых скриптов, выполняемая вручную, требующая навыков программирования, больше не является необходимостью. Как уже обсуждалось ранее, ATT и его функционал должны быть простыми, так как сложный функционал усложняет его использование. Таким образом, адаптация вручную будет необходима в случае функционала, который не внедрялся ранее в ATT. Например, если в ATT нет возможности тестировать функционал AJAX, сгенерированные скрипты должны адаптироваться вручную. 

  • Таким образом, члены команды «функционального» тестирования могут генерировать тестовые скрипты, так как это не требует навыков программирования. Единственное, что им необходимо – навигация по модели тестового объекта с целью генерирования их тестовых скриптов.

  • Нет необходимости в специальном обучении при смене инструментов тестирования, так как тестовые скрипты автоматически генерируются ATT. Но все же необходимо обучить ответственных сотрудников выполнять тестовые скрипты и анализировать результаты тестов.

  • Смысл в использовании ATT есть тогда, когда существуют шаги в тестовых скриптах, которые могут быть повторно использованы в других тестовых скриптах. Использование ATT не имеет смысла, если каждый скрипт уникален.

 

Рисунок 5. Изменение процесса тестирования

Недостатками ATT являются следующие моменты:

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

  • Так как ATT должен быть максимально простым, некоторые части объекта тестирования могут не подлежать тестированию при использовании исключительно ATT. Например, при тестировании AJAX в веб приложении, будет невозможно протестировать его, если ATT не предоставляет такой возможности. Требования к ATT должны постоянно утверждаться и обновляться в ATT при необходимости.

  • Хотя ATT дает больше независимости в отношении инструментов тестировании в процессе тестирования, он приводит к новой зависимости от ATT.

Выводы

Описанный подход добавляет новый вариант генерирования тестового скрипта к процессу тестирования. Он успешно используется на практике и была доказана его эффективность в отношении:

  • Эффективного использования времени и средств
  • Генерирования тестовых скриптов для различных инструментов
  • Повторное использование функционала в различных тестовых скриптах
  • Использование тестовых скриптов с SUT, которая до сих пор развивается и имеет частые изменения GUI.

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

Спасибо за комментарий, но если хотите чтобы перевод был более правильным и акуратным, предлагайте свой вариант и мы с радостью поправим существующую статью. Мы все делаем на добровольных начинаниях.
А журнал размещался бесплатно, почему сейчас за деньги, увы, не знаю. Но вариант в pdf доступен через эту ссылку http://www.testingexperience.com/testingexperience14_06_11.pdf