Содержание
Обзор
В синтаксисе тестирования на основе ключевых слов перечислены тестовые примеры (слова данных и действия) в формате таблицы (см. Пример ниже). Первый столбец (столбец A) содержит ключевое слово Enter Client, которое представляет собой тестируемую функциональность. Затем оставшиеся столбцы BE содержат данные, необходимые для выполнения ключевого слова: имя, адрес, почтовый индекс и город.
| А | B | C | D | E |
|---|---|---|---|---|
| . | Имя | Адрес | Почтовый индекс | Город |
| Введите клиента | Джейн Смит | 6 Хай Стрит | SE25 6EP | Лондон |
Чтобы ввести другого клиента, тестировщик должен создать еще одну строку в таблице с ключевым словом Enter Client и данными нового клиента в следующих столбцах. Нет необходимости заново перечислять все включенные действия.
В нем вы можете разрабатывать свои тестовые примеры:
Учитывая итеративный характер разработки программного обеспечения, дизайн теста обычно более абстрактный (менее конкретный), чем ручная реализация теста, но он может легко превратиться в один.
Преимущества
Тестирование на основе ключевых слов снижает чувствительность к техническому обслуживанию, вызванному изменениями в тестируемой системе / программном обеспечении (SUT). Если макеты экрана меняются или система переносится на другую ОС, вряд ли какие-либо изменения нужно будет вносить в тестовые примеры: изменения будут внесены в документацию по ключевым словам, по одному документу для каждого ключевого слова, независимо от того, сколько раз ключевое слово используется в тестовые примеры, и это подразумевает глубокий процесс разработки тестов.
Кроме того, этот подход представляет собой открытую и расширяемую структуру, которая объединяет все инструменты, ресурсы и данные, связанные с тестированием и производимые в ходе него. В рамках этой единой структуры все участники тестирования могут определять и уточнять цели в области качества, над которыми они работают. Именно здесь команда определяет план, который будет реализовывать для достижения этих целей. И, что наиболее важно, он предоставляет всей команде одно место, куда можно в любое время определить состояние системы.
Дизайн теста отличается от проектной работы, которая должна быть выполнена при определении того, как построить вашу реализацию теста.
Методология
Методология тестирования на основе ключевых слов разделяет выполнение процесса тестирования на несколько этапов:
Определение
Автоматизация выполнения теста
Этап реализации различается в зависимости от инструмента или фреймворка. Часто инженеры по автоматизации реализуют структуру, которая содержит такие ключевые слова, как «проверка» и «ввод». Тестировщики или разработчики тестов (которым не нужно знать, как программировать) пишут тестовые примеры на основе ключевых слов, определенных на этапе планирования, которые были реализованы инженерами. Тест выполняется с использованием драйвера, который считывает ключевые слова и выполняет соответствующий код.
Автоматизация тестирования программных систем
Приветственное слово
Здравствуйте, уважаемые хабрапользователи! Хочу представить вашему вниманию статью, в которой речь пойдёт о тестировании программных систем, его автоматизации, а также средствах для этого используемых.
На сегодняшний день уже мало кто сомневается в целесообразности проведения процесса тестирования разрабатываемых программных продуктов, но, к сожалению, не все ясно себе представляют как тестирование грамотно внедрять и применять. Корифеям-тестировщикам моя статья не принесёт практической пользы, а вот интересующихся тематикой новичков порадовать есть чем.
Изначально я не ставлю своей целью охватить всю проблемную область. На это не хватит и серии книг, которую мне, к тому же, не хватит знаний и опыта написать. Основная задача статьи — не растекаясь мыслью по древу, создать у читателя достаточно чёткую картину того, что вообще из себя представляет автоматизация тестирования и когда, а также с чем её едят.
Основные понятия
Начну с небольшого теоретического экскурса.
Итак, под тестированием принято понимать деятельность, выполняемую для оценки и улучшения качества ПО. В общем случае тестирование базируется на обнаружении дефектов и проблем в программных системах.
Автоматизированное тестирование ПО — процесс тестирования программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, производятся автоматически с помощью инструментов для автоматизированного тестирования.
В свою очередь, инструмент для автоматизированного тестирования — это программное обеспечение, посредством которого осуществляется создание, отладка, выполнение и анализ результатов прогона тест-скриптов (Test Scripts — это наборы инструкций для автоматической проверки определенной части программного обеспечения).
Тестирование программных систем состоит из динамической верификации поведения программ на конечном наборе тестов. При этом тесты выбираются из обычно выполняемых действий прикладной области и обеспечивают проверку соответствия ожидаемому поведению системы.
Применение автоматизированного тестирования
Первым пунктом в этом списке стоит тестирование производительности. Нагрузочное, стрессоустойчивое, тестирование на стабильность… Без автоматизации его выполнение трудно себе представить. По этой причине имеется широкий выбор продуктов от разных производителей и столь же высокие цены, даже в случае неудобного и слабо функционального инструмента.
Следом идёт регрессионное тестирование. Означает оно проверку ПО на корректность функциональности, выпущенной и протестированной в предыдущей версии. Выполняется с регулярной частотой, задаваемой в зависимости от условий: у кого-то с каждым новым билдом, а у кого-то с каждой версией для заказчика.
Конфигурационное тестирование – выполнение одних и тех же тестов в разных условиях. То есть когда один или несколько компонентов архитектуры системы требуется проверить в разном окружении, обычно заявленном в изначальных требованиях. Например: поддержка СУБД от разных производителей, работа в разных клиентских браузерах, использование в нескольких ОС и т.п. То есть некий аналог регрессионного тестирования, но в рамках одной версии системы.
Функциональное тестирование. Ясно, что здесь речь идёт о проверке нового функционала. Иногда бывает, что без автоматизации никак не обойтись. Даже если нужно выполнить тестирование только один раз. Обычно, впоследствии эти тесты и используются для регресса.
Установочное тестирование, выполняется для проверки условий инсталляции (и настройки) продукта с учётом тех или иных требований к системе от заказчика.
«А зачем?»
Как автоматизировать тестирование?
Вернее даже будет сказать так: как подойти к внедрению процесса автоматизации тестирования в своей деятельности?
Во-первых, следует обратить внимание, насколько хорошо инструмент для автоматизации распознает элементы управления в приложении. В случае, когда элементы не распознаются, стоит поискать плагин, либо соответствующий модуль. Если такового нет – от инструмента лучше отказаться.
Во-вторых, нужно иметь в виду, сколько времени требуется на поддержку скриптов, написанных с помощью выбранного инструмента. Для этого можно записать простой скрипт, который выбирает пункт меню, а потом представить, что изменился пункт меню, который необходимо выбрать. Если для восстановления работоспособности сценария придется перезаписать скрипт целиком, то инструмент не оптимален, так как реальные сценарии гораздо сложнее.
И последний момент, на который надо обратить внимание – насколько удобен инструмент для написания новых скриптов. Сколько требуется на это времени, насколько можно структурировать код, насколько код читаем, и т.д.
На финишной прямой
Чтобы принять окончательное решение о целесообразности применения автоматизации, обычно советуют ответить на возникающий естественным образом в данной ситуации вопрос: «превалируют ли в нашем случае преимущества над недостатками?». Если недостатки в конкретном случае неприемлемы, то от автоматизации стоит воздержаться.
Выбор инструмента
Чаще всего зависит от объекта тестирования и требований к тестовым сценариям, т.к., разумеется, инструменты тестирования не могут поддерживать полный объём технологий, используемых при разработке приложений. Таким образом, выбор инструмента сводится к банальному методу проб и ошибок. В итоге, нередко тестировщики выбирают несколько инструментов для тестирования функций приложения.
Логично теперь будет поближе рассмотреть некоторые популярные средства автоматизации тестирования и привести пример написания простого тест-скрипта.
HP QuickTest Professional
Средство автоматизации от кампании Hewlett-Packard. Распространяется на платной основе (8000-10000 USD). Является основным инструментом автоматизации функционального тестирования от данного производителя. Позволяет автоматизировать функциональные и регрессионные тесты через записи действий пользователя при работе с тестируемым приложением, а потом исполнять записанные действия с целью проверки работоспособности ПО.
Записанные действия сохраняются в виде скриптов.
Скрипты могут быть отображенные в инструменте как VBScript (expert view), или же как визуальные последовательные шаги с действиями (keyword view).
Каждый шаг может быть отредактирован и на него можно добавить точки проверки (checkpoint), которые сравнивают ожидаемый результат с полученным.
IBM Rational Functional Tester
Тоже платный, но не настолько («всего-то» 6000 USD).
Rational Functional Tester предоставляет тестировщикам средства автоматизированного тестирования, позволяющие выполнять функциональное тестирование, регрессивное тестирование, тестирование пользовательского интерфейса и тестирование управляемое данными.
Много описательной информации о нём не дам, а лучше приведу практический пример.
Пример использования
Будет использована интеграция IBM Rational Functional Tester со средой разработки Microsoft Visual Studio. Для создания функционального теста необходимо выполнить следующие действия:
1) В среде разработки Microsoft Visual Studio создать новый проект «Functional Test Project»: 
2) Выполнить запись пользовательских действий с тестируемым приложением:
3) Создать проверочную точку в процессе выполнения записи. Проверочная точка также будет выполнять проверку значения в выпадающем списке:
4) Сохранить результаты записи:
Результат выполнения
8 лучших фреймворков для тестирования с помощью Python в 2021 году
Если вы когда-нибудь думали: «С какого же языка программирования мне следует начать свое путешествие в тестирование?» Ваш ответ – Python. Но он подойдет не только начинающим! В недавнем опросе, который я провела в LinkedIn, мы видим, что среди опытных программистов 35% проголосовали за то, что Python является их самым любимым языком программирования (немного опередив всеми любимую Java, которая заняла 2-е место с 32%).
На протяжении многих лет Python действительно набирает обороты как среди тестировщиков, так и среди разработчиков, да и в целом является самым динамично развивающимся языком программирования (как видно на диаграмме трендов Stack Overflow), и мы прекрасно понимаем, что это значит. Популярность = релевантность!
К концу этой статьи я ставлю своей целью дать вам понимание того, насколько мощным является язык программирования Python и какой фреймворк для тестирования лучше всего подойдет вашему проекту исходя из его потребностей.
Что хорошего в Python для автоматизации тестирования?
Есть довольно много причин, по которым популярность Python растет в области автоматизации тестирования и версий, почему он считается лучшим вариантом для нее. Среди них вы найдете: Дзен Python (19 основополагающих принципов философии проектирования на Python), удобство для начинающих, но мощность для профессионалов; Python – одновременно объектно-ориентированный и функциональный, у него есть большая библиотека пакетов для тестирования, серьезное сообщество по всему миру и многое другое! Я рекомендую прочитать вам чуть больше об этом в блоге AutomationPanda.
Фреймворк для тестирования на Python, который вам подходит
С ростом применения Python растет и популярность фреймворков для тестирования на его основе. Поначалу может быть неясно, какой инструмент из всего многообразия следует выбрать, поскольку у каждого из них есть свои плюсы и минусы. Тем не менее, у каждого проекта и организации, есть свои требования и ограничения, поэтому нам нужно учитывать их все при выборе инструмента, который подойдет нам лучше всего. Чтобы лучше разобраться в этом вопросе, я рекомендую вам прочитать эти статьи:
И, конечно, зачем же нужны списки с плюсами и минусами, как ни для того, чтобы собрать важные сведения об инструментах в одном месте! Итак, давайте рассмотрим 8 лучших фреймворков для тестирования на Python и рассмотрим как их преимущества, так и недостатки, чтобы вам было проще выбрать идеальный фреймворк для тестирования.
Преимущества и недостатки 8 лучших фреймворков для тестирования на Python
Тестирование на основе ключевых слов
Большое количество программных продуктов и компонентов, которые создаются и выпускаются сегодня, можно по праву считать максимально веб-ориентированными утилитами, предназначенными для выполнения определенных задач в глобальной сети Интернет.
Создание веб-продукта подразумевает использование множества возможностей из разных сфер и наук, а именно: оперирование большим числом данных, функционирование вычислительных систем, создание сетевой безопасности, дизайн и многое другое.
Именно тестирование является весьма важной и фундаментальной частью создания программного продукта.
Постоянный рост строчек программного кода, а также увеличение количества программистов приводят к возникновению все большего числа технических ошибок в процессе создания программного компонента.
Как раз тестирование и позволяет найти эти ошибки как можно раньше, еще до процесса выпуска приложения. Скорость, с помощью которой можно быстро идентифицировать данные проблемы, всецело зависит от выбранного подхода к тестированию, количества тестеров, их совокупного опыта, а также выбранной массы инструментов, применяющихся в процессе обнаружения багов.
Существует очень много подходов к автоматизации процессов тестирования.
Чаще всего на слуху такие аббревиатуры, как 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.
Итак, у нас есть совершенно пустой тест, который можно запросто редактировать (об этом поговорим немного позже).
Теперь наша задача заключается в том, чтобы записать тест, используя доступные возможности программы TestComplete.
Обращаемся к панели инструментов в верхней части диалогового окна и жмем на кнопку Record New Test.
В нашем случае мы попробуем записать простые математические операции на обыкновенном калькуляторе (например – к трем добавим два). Как итог получаем вот такой интересный скрипт:
Во всей колонке item видно имя объекта, с которым проводилось взаимодействие системы, в колонке Operator – выполняемая текущая операция (к примеру, ClickButton – имитация нажатия на кнопку), в колонке Value – заданный параметр операции (к примеру, название кнопки в нашем случае), а в колонке Description – описание проводимой операции. При всем этом если бы мы использовали NameMapping в данном проекте, то значение в колонке item было бы более понятным и читабельным, к примеру:
Значение в колонке item
Теперь предположим, что мы желаем очистить поле калькулятора перед тем, как выполнять следующие операции. Для этого нужно нажать кнопку Cancel.
Для добавления определенного шага в уже созданный тест имеется специальная кнопка Append to Test, расположенная на панели инструментов. Как только вы нажмете на нее, вы сразу же переходите в режим записи теста, записываете все выполняемые действия, и в конечном итоге они добавляются в конец ранее созданного и сохраненного скрипта.
Специальные кнопки со стрелками позволяют перемещать любое добавленное действие в нужную строчку. В нашем случае мы установим очистку поля калькулятора перед процедурой проведения необходимых вычислений.
Кнопки со стрелками
Кнопка Run Test позволяет запустить работу нашего теста и убедиться наконец-то в том, что все функционирует именно так, как и предполагалось заранее.
Процессы модификации ранее записанных тестов
Базовое отличие простых тестов от группы KDT в том, что вторые помогают проводить аналогичные операции, но на основе специального визуального редактора, который используется вместо системы написания программного кода. Также в KDT запросто можно использовать специальные циклы, поиски по названию, специальным свойствам, а также применять условные выражения для оригинальных блоков перехватов и исключений.
Давайте начнем с наиболее простых и понятных действий. К примеру, с процесса добавления информации в лог сообщений (Мессенджер).
В левой части панели инструментов KDT расположен блок Operations, с помощью которого можно добавлять в систему новые действия и тесты.
Здесь операции классифицированы на специальные логические группы:
Давайте сначала выполним очень простое действие: процесс вывода в лог сообщения «действие 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 как услуга – это не просто проверка общего функционала по отдельности, но и работа со многими составными частями на основе большого количества инструментов и методов.
