Каталог решений - Практические кейсы и примеры создания сценарных тестов с использованием фреймворка Тестирование 3.0

Правила создания хороших сценарных тестов

Для нашей компании использование сценарных тестов – палочка-выручалочка, которая неоднократно спасала нас от проблемных ситуаций. У нас создано 100 сценарных тестов и 400 файлов в библиотеке.

Мы уже около трех лет активно используем свою систему тестирования, и за это время у нас накопилось экспертное мнение, которым я хочу поделиться.

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

Рисуем бизнес-процесс

Когда вы делаете сценарный тест – начните с визуализации того, что вы будете делать, в виде схемы бизнес-процесса:

• Во-первых, писать сценарий, не нарисовав хотя бы в голове, как это все выглядит – большой минус и большая проблема. Если вы работаете в команде, вы не сможете ни с кем поделиться тем, что и как вы делаете.

• Во-вторых, схема бизнес-процесса – это документация, которую вы можете использовать.

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

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

В чем преимущество использования схем бизнес-процессов, что нам это дает?

Если у вас есть хорошо нарисованная схема – 50% решенной задачи.

Мы используем порядка 20 схем, эти схемы легко изменяются под вторичный процесс. Например, есть процесс продаж: создали заказ, отгрузили и оплатили. А есть продажа с использованием предоплаты. Схемы похожие, меняются чуть-чуть. Если есть одна – нарисовать на ее основе другую элементарно. Чем больше схем — тем быстрее создавать новые.

На схеме бизнес-процесса мы видим:

• основных участников процесса, кто и что будет делать;

• последовательность действий и взаимодействия, которые происходят между участниками;

• мы также визуально легко декомпозируем схему – разбиваем на участки и блоки, которые решают определенную логическую задачу;

• также видно, что передается из одного блока в другой блок;

• если мы хотим, чтобы сценарий был гибким – нам нужны параметры и так далее.

Ограничение сценарных тестов – не используем для генерации начальных данных

Я часто встречаюсь с тем, что сценарные тесты используются для генерации данных. Никогда так не делайте!

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

• Загрузка из макетов выполняется мгновенно (по сравнению алгоритмом через пользовательский интерфейс), а сценарный тест может выполняться и выполняется во много раз дольше.

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

На слайде показана схема запуска пакетов тестов — проверка продукта.

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

• первым этапом идет загрузка макетов с начальными данными – она выполняется две-три минуты;

• и дальше вперемешку идет параллельный запуск сценарных и юнит-тестов.

В результате мы значительно экономим ресурсы и нервы.

Ограничение сценарных тестов: не должны зависеть от окружения

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

• При создании теста вы можете передавать в него параметром какой-нибудь GUID. И если у вас изменилась база, или вы попробовали запустить на другой конфигурации – например, мы знаем, что ERP и УТ в части бизнес-процесса продаж идентичны – то в случае, если тест для ERP завязан на окружение, то вы его, скорее всего, не сможете запустить на УТ. Из-за этого у вас уменьшается гибкость и увеличиваются затраты на поддержание тестов. Поэтому избавляйтесь от завязки на GUID и управляйте окружением через параметры.

• Еще один немаловажный факт, с которыми мы столкнулись в процессе тестирования – тесты, которые вы пишете, должны многократно запускаться в одной и той же базе. Этого можно добиться двумя способами – откатом созданных данных, как, например, в «Тестере». Или использование имитации обычного поведения пользователя — создание эталонной цепочки с «нуля» и при ее выполнении поиск документов по номерам, справочников по наименованиям — делать так как бы искал обычный пользователь. И старайтесь не использовать хуки — по типу запросов к базе данных и т.п. Этот подход используется в «Тестировании 3.0», я его позже покажу на примерах.

Для снижения зависимости хрупкости в нашем механизме мы используем некоторые готовые шаги (приведем часть наиболее часто используемых):

• Параметры. Можно задавать различные текстовые параметры во вкладке “Параметры” и далее использовать их внутри сценария при поиске окон, элементов списков выбора, ввода текстовой информации и др. Для этого достаточно в свойствах шага в текстовое описание добавить слово «&Параметр». К примеру, для заголовка окна напишите так: «Заказ клиента &НомерДокумента от *», где «НомерДокумента» — параметр хранящий номер требуемого документа, а литерал «&» указывает компилятору на то что используется параметр из таблицы для подстановки данных. О практической демонстрации поговорим чуть ниже.
   

• Загрузка/сохранение параметров через файл или базу данных. Для данной задачи используется шаг “Память” с типом “Вспомнить”, “Запомнить”, “Забыть” и источником — временный файл, файл из каталога или база данных “Тестирование 3.0”.

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

• Поддержка командной строки для запуска сценария. Позволяет интегрировать в любую систему CI и передать основные параметры для запуска сценария: путь к базе, наименование сценария, поиск отчетов. Более подробно они расписаны по ссылке — Описание параметров командной строки

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

Создадим один «большой» сценарный тест

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