Большое количество программных продуктов и компонентов, которые создаются и выпускаются сегодня, можно по праву считать максимально веб-ориентированными утилитами, предназначенными для выполнения определенных задач в глобальной сети Интернет.
Создание веб-продукта подразумевает использование множества возможностей из разных сфер и наук, а именно: оперирование большим числом данных, функционирование вычислительных систем, создание сетевой безопасности, дизайн и многое другое.
Именно тестирование является весьма важной и фундаментальной частью создания программного продукта.
Постоянный рост строчек программного кода, а также увеличение количества программистов приводят к возникновению все большего числа технических ошибок в процессе создания программного компонента.
Как раз тестирование и позволяет найти эти ошибки как можно раньше, еще до процесса выпуска приложения. Скорость, с помощью которой можно быстро идентифицировать данные проблемы, всецело зависит от выбранного подхода к тестированию, количества тестеров, их совокупного опыта, а также выбранной массы инструментов, применяющихся в процессе обнаружения багов.
Существует очень много подходов к автоматизации процессов тестирования.
Чаще всего на слуху такие аббревиатуры, как 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
Итак, у нас есть совершенно пустой тест, который можно запросто редактировать (об этом поговорим немного позже).
Теперь наша задача заключается в том, чтобы записать тест, используя доступные возможности программы TestComplete.
Обращаемся к панели инструментов в верхней части диалогового окна и жмем на кнопку Record New Test.
В нашем случае мы попробуем записать простые математические операции на обыкновенном калькуляторе (например – к трем добавим два). Как итог получаем вот такой интересный скрипт:
Скрипт
Во всей колонке item видно имя объекта, с которым проводилось взаимодействие системы, в колонке Operator – выполняемая текущая операция (к примеру, ClickButton – имитация нажатия на кнопку), в колонке Value – заданный параметр операции (к примеру, название кнопки в нашем случае), а в колонке Description – описание проводимой операции. При всем этом если бы мы использовали NameMapping в данном проекте, то значение в колонке item было бы более понятным и читабельным, к примеру:
Значение в колонке item
Теперь предположим, что мы желаем очистить поле калькулятора перед тем, как выполнять следующие операции. Для этого нужно нажать кнопку Cancel.
Для добавления определенного шага в уже созданный тест имеется специальная кнопка Append to Test, расположенная на панели инструментов. Как только вы нажмете на нее, вы сразу же переходите в режим записи теста, записываете все выполняемые действия, и в конечном итоге они добавляются в конец ранее созданного и сохраненного скрипта.
Выполняемые действия
Специальные кнопки со стрелками позволяют перемещать любое добавленное действие в нужную строчку. В нашем случае мы установим очистку поля калькулятора перед процедурой проведения необходимых вычислений.
Кнопки со стрелками
Кнопка Run Test позволяет запустить работу нашего теста и убедиться наконец-то в том, что все функционирует именно так, как и предполагалось заранее.
Кнопка Run Test
Процессы модификации ранее записанных тестов
Базовое отличие простых тестов от группы KDT в том, что вторые помогают проводить аналогичные операции, но на основе специального визуального редактора, который используется вместо системы написания программного кода. Также в KDT запросто можно использовать специальные циклы, поиски по названию, специальным свойствам, а также применять условные выражения для оригинальных блоков перехватов и исключений.
Давайте начнем с наиболее простых и понятных действий. К примеру, с процесса добавления информации в лог сообщений (Мессенджер).
В левой части панели инструментов KDT расположен блок Operations, с помощью которого можно добавлять в систему новые действия и тесты.
Блок Operations
Здесь операции классифицированы на специальные логические группы:
- тестовые задачи – операции с блоками управления, работа с меню, а также процесс поиска объектов;
- Logging – работа с логами;
- чекпоинт – создание и добавление чекпоинтов;
- Statements – создание группы условий или циклов;
- Miscellaneous – остальные технические возможности (задержка прокрутки, оперирование индикатора).
Давайте сначала выполним очень простое действие: процесс вывода в лог сообщения «действие 3+2». Для этого нам потребуется переместить элемент Log Message с панели на ту строчку скрипта, где нам необходимо выводить именно это сообщение.
Сразу после этого на экране у нас высветится специальное диалоговое окно, в котором задаются параметры:
Сообщение журнала
В этом окне мы будем указывать, какой именно вид сообщения мы должны использовать, и при желании можем дополнить его текстом.
Далее жмем кнопку Finish и заканчиваем действие, либо же нажимаем на Next для того, чтобы сразу перейти на вторую страницу окна, где есть возможность ознакомиться со всем перечнем параметров и при необходимости отредактировать их значение.
Параметры работы
Как итог, наш проект получит уже готовую структуру:
Готовая структура проекта
Таким же образом проводится добавление и прочих элементов скриптов. К примеру, теперь мы хотим выполнить проверку значения, как только Калькулятор завершит выполнение действия.
Аналогичным способом перетаскиваем необходимый элемент из Operations туда, где необходимо выполнить проверку, и на основе инструмента Finder Tool отмечаем на экране специальное текстовое поле, а затем нажимаем на Next.
Окно Create Property Checkpoint
На следующей страничке окошка Create Property Checkpoint отмечаем нужное действие и нажимаем на Next. На третьей странице выбираем необходимое условие проверки. В нашем случае отмечаем параметр «равно».
Параметры сопоставления
Параметр «равно»
Еще раз запустим наш тест, чтобы убедиться в том, что все функционирует как нужно. В итоге мы можем ознакомиться с результатами работы нашего скрипта:
Результаты работы нашего скрипта
Процесс конвертации Keyword-Driven тестов
Хоть KDT-тесты и отличаются максимальной простотой и понятностью, не все операции можно выполнить исключительно с их помощью. Отчасти это обусловлено определенными различиями в формировании некоторых языков программирования, а частично тем, что только при помощи классического языка программирования можно создавать максимально сложные конструкции, а не оперировать лишь KDT.
И вот, если вы пожелаете использовать записанный KDT-тест на выбранном вами языке программирования, вам потребуется провести конвертацию.
Чтобы провести процедуру конвертации KDT-документации в простой тест, вам необходимо нажать 3 раза правой кнопкой мышки и выбрать специальный пункт Convert to Script.
Пункт Convert to Script
Затем в появившемся окне Specify Routine Name выбрать определенный модуль и ввести название функции, в которую и будет сконвертирован ваш тест.
Окно Specify Routine Name
В итоге у нас получается вот такой скрипт:
Пример скрипта
Как видим, ничего сложного, и при правильной настройке и оптимизации процессов тестирования можно подготовить широкомасштабную среду, в которой одновременно можно использовать несколько типов и разновидностей тестирования. Ведь, как известно, QA как услуга – это не просто проверка общего функционала по отдельности, но и работа со многими составными частями на основе большого количества инструментов и методов.
Оставить комментарий