Фирма

«Инрэко ЛАН»

Все описанное ниже основывается на книге Рекса Блэка «Advanced Software Testing».В этой серии статей мы рассматриваем три методики тестирования бизнес-логики, которые зачастую более полезны по сравнению с эквивалентным разбиением и анализом граничных значений. В первых трех статьях были рассмотрены таблицы альтернатив, которые полезны при тестировании транзакционных ситуаций. Также были рассмотрены прецеденты, в которых предусловия и постусловия помогают отделить поток событий от предыдущего и последующего потоков.

Тестирование на основе состояний и диаграммы переходов состояний

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

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

Иными словами, существует некий статус-кво, и система находится в текущем состоянии. Затем происходит некоторое событие, которое система должна обработать. На обработку этого события может влиять одно или более условий. Комбинация событий и условий вызывают срабатывание перехода: или из текущего состояния в новое, или из текущего снова в текущее состояние. В случае перехода система предпринимает одно или более действий.

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

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

Еще один потенциально более жесткий критерий покрытия требует, чтобы каждая последовательность переходов длины N и меньше была покрыта как минимум одним тестом. N может быть равно 1, 2, 3, 4 и больше. Это называется «Покрытием переходов Чау» (“Chow’s switch coverage”), по имени профессора Чау, разработавшим методику, или «Покрытием N-1 переходов» - по достигнутому уровню покрытия. Если покрыть все переходы единичной длины, тогда «Покрытие N-1 переходов» означает «покрытие 0 переходов». Следует заметить, что это тоже нижний уровень покрытия, который рассматривался выше. Если покрыть все переходы длины 1 и 2, тогда «Покрытие N-1 переходов» означает «покрытие 1 перехода». Это, естественно, более высокий уровень покрытия по сравнению с нижним.

Но «покрытие 1 перехода» необязательно выше уровнем, чем покрытие каждой строки. Это потому, что таблица переходов ведет к тестированию комбинаций событий/условий, чего не происходит в диаграмме переходов состояний. Так называемые «переходы» в «Покрытии N-1 переходов» получаются из диаграммы переходов, а не таблицы.

Все это приводит в небольшое замешательство тех, кто недостаточно изучил материал Базового уровня Программы обучения ISTQB по разработке тестов. И это общая проблема тех, кто выбрал «бессистемные» курсы для обучения. Нет поводов волноваться, чуть позже все станет понятным.

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

Глоссарий ISTQB

Тестирование переходов состояний (state transition testing): Разработка тестов методом черного ящика, в котором сценарии тестирования строятся на основе выполнения корректных и некорректных переходов состояний.



Рис. 1. Пример диаграммы переходов состояний.

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

Прежде всего, нужно заметить, что слева имеется небольшой элемент в виде кружка и стрелки с названием «начальное состояние». Такая нотация показывает, что с точки зрения клиента транзакция начинается с просмотра веб-сайта. Можно переходить по ссылкам и просматривать каталог товаров, оставаясь в состоянии просмотра. Стрелка в виде петли над состоянием просмотра отражает как раз такой процесс. Узлы в виде прямоугольников со скругленными углами представляют состояния. Стрелки отражают переходы.

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

Альтернативно, покупатель может выбрать оформление покупки. В этом случае он входит в состояние авторизации. Он вводит регистрационную информацию. К этой информации применимо условие: верна ли регистрационная информация. Если не верна, то система отображает ошибку, и пользователь остается в состоянии авторизации. Если верна, то система отображает первую страницу в диалоге оплаты. Заметим, что «верный» и «неверный» отображенные в квадратных скобках с точки зрения нотации обозначают условия.

В состоянии оплаты система будет отображать страницы, а покупатель вводить данные об оплате. Будет ли эта информация верна – снова условия, – которые определяют, может ли система завершить и подтвердить транзакцию. Как только транзакция подтверждена, пользователь может продолжить покупку либо пойти на другой сайт. Также заметим, что пользователь всегда может отменить транзакцию и уйти на другой сайт.
Часто при разборе тестирования на основе состояний, люди спрашивают: «Как различить состояние, событие и действие?» Основные отличия следующие:

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

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

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

Тестирование на основе состояний использует формальную модель, поэтому имеется формальная процедура для получения тестов из модели. Приведенный ниже список показывает процедуру, которую можно использовать для получения тестов, которые позволяют достигнуть покрытия состояний/переходов (т.е. «покрытие 0 переходов»).

  1. Введем правило для того, где тестовая процедура или шаг должны начинаться и где заканчиваться. В качестве примера утвердим, что тестовая процедура должна начинаться в начальном состоянии и может закончиться только в конечном состоянии. Причина использования слов «может» или «должен» для определения окончания в том, что в ситуациях, где начальное и конечное состояния – одно и то же, может потребоваться разрешить последовательности состояний и переходов, которые проходят через начальное состояние более чем один раз.
  2. Начиная с разрешенного состояния начала теста, определим последовательность комбинаций событий и условий, которые приводят к разрешенному состоянию окончания теста. Для каждого перехода, который происходит, зафиксируем ожидаемое действие, которое должна произвести система. Это ожидаемый результат.
  3. Когда проходим каждое состояние и каждый переход, помечаем его как покрытый. Простейший способ для этого – распечатать диаграмму переходов состояний и, используя карандаш или маркер, помечать каждый узел и стрелку по мере покрытия.
  4. Повторять шаги 2 и 3 до тех пор, пока не пройдены все состояния и все переходы. Иными словами, пока каждое состояние и переход не будут помечены карандашом или маркером.

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

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


Рис. 2. Проверка покрытия 1.

На рисунке 2 нужно отметить две вещи. Первое, это правило, которое гласит, что тест должен начинаться в начальном состоянии и заканчиваться в конечном.

И второе, это то, какие шаги включены в тест: («просмотр», «пройти по ссылке», «отобразить», «добавить в корзину», «диалог выбора», «продолжить», «отобразить», «добавить в корзину», «диалог выбора», «посчитать», «диалог авторизации», «вход [неверный]», «ошибка», «вход [верный]», «диалог оплаты», «оплата [неверно]», «ошибка», «оплата [успешно]», «подтверждение», «продолжить покупку», «отобразить», «отмена», «выход»).

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


Рис. 3. Завершающая проверка покрытия.

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

  1. («просмотр», «пройти по ссылке», «отобразить», «добавить в корзину», «диалог выбора», «продолжить», «отобразить», «добавить в корзину», «диалог выбора», «посчитать», «диалог авторизации», «вход [неверный]», «ошибка», «вход [верный]», «диалог оплаты», «оплата [неверно]», «ошибка», «оплата [успешно]», «подтверждение», «продолжить покупку», «отобразить», «отмена», «выход»);
  2. («просмотр», «добавить в корзину», «диалог выбора», «отмена», «выход»);
  3. («просмотр», «добавить в корзину», «диалог выбора», «посчитать», «диалог авторизации», «отмена», «выход»);
  4. («просмотр», «добавить в корзину», «диалог выбора», «посчитать», «диалог авторизации», «вход [верный]», «диалог оплаты», «отмена», «выход»);
  5. («просмотр», «добавить в корзину», «диалог выбора», «продолжить», «отобразить», «добавить в корзину», «диалог выбора», «посчитать», «диалог авторизации», «вход [верный]», «диалог оплаты», «оплата [успешно]», «подтверждение», «уйти на другой сайт»).

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

Суперсостояния и подсостояния

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

Рис. 4. Суперсостояния и подсостояния.

Правило базового покрытия здесь простое. Покрыть все переходы в суперсостояние, все переходы из суперсостояния, все подсостояния и все переходы внутри суперсостояния.

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

Андрей Конушин, ведущий инженер-тестировщик

Метки: тестирование

Комментарии  

#1 @лаяла 21.01.2019 10:22
Убило написанное:"Все это приводит в небольшое замешательство тех, кто недостаточно изучил материал Базового уровня Программы обучения ISTQB по разработке тестов". Впаривают какую то методологию по описанию системы, как будто любой тестировщик не может подобное нарисовать карандашом на бумаге, так как это всего лишь описание работы посредством графом состояний...
Цитировать

Добавить комментарий