Пока нет оценок
Пожалуйста, подождите...

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

Создание веб-продукта подразумевает под собой использование множества возможностей из разных сфер и наук, а именно: оперирование большим числом данных, функционирование вычислительных систем, создание сетевой безопасности, дизайн и остальное.

Именно тестирование является весьма важной и фундаментальной частью создания программного продукта.

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

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

Существует очень много подходов к автоматизации процессов тестирования.

Чаще всего на слуху такие аббревиатуры, как KDT, DDT и BDD. И большая часть тестеров придерживается именно данных подходов в процессе построения методологии проверки программного продукта.

Суть тестирования на основе ключевых слов

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

Для начала формируется набор ключевых слов, потом ассоциации (определенное действие или функция), связанные с данным ключевым словом. То есть каждый такой шаг теста, например, открытие и закрытие иконки браузера, клик мышки по объекту, описывается специальным ключевым словом – открыть или нажать (open browser или click).

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

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

Базовые этапы создания тестов на основе ключевых слов:

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

В чем преимущество подобной формы тестирования:

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

Тест на основе ключевых слов в TestComplete7

Как раз начиная с версии TestComplete 7 продукт в автоматическом порядке может записывать так называемые Keywords Driven test.

Далее мы будем использовать краткое название – KD test.

Процесс записи тестов

Сначала давайте просто создадим обыкновенный KD test. Для этого нужно щелкнуть правой кнопкой мыши по проекту, а именно – на элементе KEYWORDSTESTS, и выбрать специальный пункт меню ADD – New Item.

В окне (creative project item) следует ввести название нашего нового теста (давайте назовем его KDT1).

После этого в TestComplete откроется новая панель KD Test.

Панель KD Test

Панель KD Test

Итак, у нас есть совершенно пустой тест, который можно запросто редактировать (об этом поговорим немного позже).

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

Обращаемся к панели инструментов в верхней части диалогового окна и жмем на кнопку Record New Test.

В нашем случае мы попробуем записать простые математические операции на простом калькуляторе (например – к трем добавим два). Как итог получаем вот такой интересный скрипт:

Скрипт

Скрипт

Во всей колонке item видно имя объекта, с которым проводилось взаимодействие системы, в колонке Operator – выполняемая текущая операция (к примеру, ClickButton – имитация нажатия на кнопку), в колонке Value – заданный параметр операции (к примеру, название кнопки в нашем случае), а в колонке Description – описание проводимой операции. При всем этом если бы мы использовали NameMapping в данном проекте, то значение в колонке item было бы более понятным и читабельным, к примеру:

Значение в колонке item

Значение в колонке item

Теперь предположим, что мы желаем очистить поле калькулятора перед тем, как выполнять следующие операции. Для этого нужно нажать кнопку Cancel.

Для добавления определенного шага в уже созданный тест имеется специальная кнопка Append to Test, расположенная на панели инструментов. Как только вы нажмете на нее, вы сразу же переходите в режим записи теста, записываете все выполняемые действия, и в конечном итоге они добавляются в конец ранее созданного и сохраненного скрипта.

Выполняемые действия

Выполняемые действия

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

Кнопки со стрелками

Кнопки со стрелками

Кнопка Run Test позволяет запустить работу нашего теста и убедиться наконец-то в том, что все функционирует именно так, как и предполагалось заранее.

Кнопка Run Test

Кнопка Run Test

Процессы модификации ранее записанных тестов

Базовое отличие простых тестов от группы KDT – в том, что вторые помогают проводить аналогичные операции, но на основе специального визуального редактора, который используется вместо системы написания программного кода. Также в KDT запросто можно использовать специальные циклы, поиски по названию, специальным свойствам, а также применять условные выражения для оригинальных блоков перехватов и исключений.

Давайте начнем с наиболее простых и понятных действий. К примеру, с процесса добавления информации в лог сообщений (Мессенджер).

В левой части панели инструментов KDT расположен блок Operations, с помощью которого можно добавлять в систему новые действия и тесты.

Блок Operations

Блок Operations

Здесь операции классифицированы на специальные логические группы:

  • тестовые задачи – операции с блоками управления, работа с меню, а также процесс поиска объектов;
  • Logging – работа с логами;
  • чек-поинт – создание и добавление чек-поинтов;
  • Statements – создание группы условий или циклов;
  • Miscellaneous – остальные технические возможности (задержка прокрутки, оперирование индикатора).

Давайте сначала выполним очень простое действие: процесс вывода в лог сообщения «действие 3+2». Для этого нам потребуется переместить элемент Log Message с панели на ту строчку скрипта, где нам необходимо выводить именно это сообщение.

Сразу после этого на экране у нас высветится специальное диалоговое окно, в котором задаются параметры:

Сообщение журнала

Сообщение журнала

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

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

Параметры работы

Параметры работы

Как итог, наш проект получит уже готовую структуру:

Готовая структура проекта

Готовая структура проекта

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

Аналогичным способом перетаскиваем необходимый элемент из Operations туда, где необходимо выполнить проверку, и на основе специального инструмента Finder Tool отмечаем на экране специальное текстовое поле, а затем кликаем на Next.

Окно Create Property Checkpoint

Окно Create Property Checkpoint

На следующей страничке окошка Create Property Checkpoint отмечаем нужное действие и кликаем на Next. На третьей странице выбираем необходимое условие проверки. В нашем случае отмечаем параметр «равно».

Параметры сопоставления

Параметры сопоставления

 

Параметр «равно»

Параметр «равно»

Еще раз запустим наш тест, чтобы убедиться в том, что все функционирует, как нужно. В итоге мы можем ознакомиться с результатами работы нашего скрипта:

Результаты работы нашего скрипта

Результаты работы нашего скрипта

Процесс конвертации Keyword-Driven тестов

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

И вот если вы пожелаете использовать записанный KDT-тест на выбранном вами языке программирования, вам потребуется провести конвертацию.

Чтобы провести процедуру конвертации KDT-документации в простой тест, вам необходимо кликнуть 3 раза правой кнопкой мышки и выбрать специальный пункт Convert to Script.

Пункт Convert to Script

Пункт Convert to Script

Затем в появившемся окне Specify Routine Name выбрать определенный модуль и ввести название функции, в которую и будет сконвертирован ваш тест.

Окно Specify Routine Name

Окно Specify Routine Name

В итоге у нас получается вот такой скрипт:

Пример скрипта

Пример скрипта

Как видим, ничего сложного, и при правильной настройке и оптимизации процессов тестирования можно подготовить широкомасштабную среду, в которой одновременно можно использовать несколько типов и разновидностей тестирования. Ведь, как известно, QA как услуга – это не просто проверка общего функционала по отдельности, но и работа со многими составными частями на основе большого количества инструментов и методов.

Оставить комментарий