Фирма

«Инрэко ЛАН»

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

Таблицы переходов состояний

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

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

Рис. 1. Диаграмма переходов состояний для приложения электронной коммерции

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

  • Текущее состояние;
  • Событие/условие;
  • Действие;
  • Новое состояние.

Для строк, где диаграмма переходов состояний определяет действие и новое состояние для заданных комбинаций текущего состояния и события/условия, можно заполнить эти два поля (действие и новое состояние) из диаграммы переходов состояний. Однако для остальных строк в таблице они не определены.

Теперь можно идти к бизнес-аналитикам, проектировщикам системы или другим участникам и спросить: «Ну, что же должно произойти в каждой из этих ситуаций?»

И скорее всего в ответ вы услышите: «А, такая ситуация не случится!». Но как тест-аналитик, вы знаете, что это значит. И теперь ваша задача показать, как это может случиться.

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

  • Просмотр;
  • Выбор;
  • Авторизация;
  • Оплата;
  • Подтверждение;
  • Выход.

Также имеется 11 условий/событий:

  • Пройти по ссылке;
  • Добавить в корзину;
  • Продолжить;
  • Выписать;
  • Вход [Неверный];
  • Вход [Верный];
  • Оплата [Успешно];
  • Оплата [Неверно];
  • Отмена;
  • Продолжить покупку;
  • Уйти на другой сайт.


Рис. 2. Пример таблицы переходов состояний

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

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

  1. Начнем с набора тестов (включая правила начального и конечного состояния), полученных из диаграммы переходов состояний, дающей покрытие состояний/переходов.
  2. Построим таблицу переходов состояний и убедимся, что тесты покрывают все «определенные» строки (определены действие и новое состояние). Если они не покрывают, то либо неверно сгенерирован существующий набор тестов, либо неверно построена таблица переходов состояний, либо неверна диаграмма переходов состояний. Нельзя продолжать до тех пор, пока проблема не найдена и не устранена, включая создание таблицы переходов состояний или набора тестов заново, если потребуется.
  3. Выберем тесты, покрывающие состояние, для которого в таблице существует одна или более «неопределенных» строк. Изменим тесты и попытаемся создать комбинацию событий/условий для «неопределенной» строки. Заметим, что действие в этом случае не определено.
  4. По мере изменения тестов, помечаем строки как покрытые. Проще всего сделать это, взяв распечатанную версию таблицы и, используя карандаш или маркер, помечать каждую строку по мере покрытия.
  5. Повторяем шаги 3 и 4 пока все строки не будут покрыты.

Такая процедура создает логические тестовые сценарии.

Существующий тест:

  • (просмотр, добавить в корзину, диалог выбора, выписать, диалог авторизации, вход [верный], диалог оплаты, отмена, выход)
  • Измененные тесты
  • (просмотр, попытка: продолжить, неопределенное действие, добавить в корзину, диалог выбора, выписать, диалог авторизации, вход [верный], диалог оплаты, отмена, выход)
  • (просмотр, попытка: выписать, неопределенное действие, добавить в корзину, диалог выбора, выписать, диалог авторизации, вход [верный], диалог оплаты, отмена, выход)
  • Можно создать еще 6 измененных тестов, но приводить их здесь не будем…

Не пытайтесь покрыть «неопределенные» комбинации событий/условий более чем для одного состояния в любом тесте, поскольку вы наверняка не знаете, останется ли система пригодной для тестирования после этого!

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

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

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

Также можно заметить, что в каждый тест включена только одна «неопределенная» комбинация событий/условий. Почему? Это разновидность правила эквивалентного разбиения, согласно которому нельзя создавать «некорректные» тестовые сценарии, которые включают более одного «некорректного» тестового данного. В нашем случае каждая строка представляет собой «некорректные» тестовые данные. Если попытаться покрыть две строки одним тестом, то мы не можем быть уверены, что система останется пригодной для тестирования после первого «некорректного» тестового данного.

Мы пометили действие как «неопределенное». Какое поведение системы в этих условиях можно считать идеальным? Лучше, если «неопределенные» события/условия будут проигнорированы, или – еще лучше – отклонены с осмысленным сообщением об ошибке. После этого система должна функционировать нормально. В отсутствие какого-либо решения бизнес-аналитика, спецификации требований, проектировщиков системы или другого влиятельного специалиста, я вправе принять позицию, когда любой иной исход считается дефектом, включая непонятные сообщения об ошибках наподобие «То, что только что произошло, - не могло произойти». Это не выдуманная история. На одном из курсов девушка сказала, что она видела своими глазами именно такое сообщение в ответ на попытку ввести некорректные данные.

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

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

Комментарии  

#1 QATesting 03.12.2012 20:44
Благодарю за данную статью. Если интересно, то на нашем сайте появился практический разбор описанной техники: http://qatesting.ru/blog/articles/2012/12-03-state-transition-testing-wordsteps
Цитировать
#2 Юлий 12.04.2018 09:12
А где же ссылки на предыдущие статьи?
Цитировать
#3 Станислав 23.05.2018 16:27
Юлий, вот они:
1. https://inrecolan.ru/blog/andrey-konushin/330-testing1
2. https://inrecolan.ru/blog/andrey-konushin/340-testing2
3. https://inrecolan.ru/blog/andrey-konushin/343-testing3
4. https://inrecolan.ru/blog/andrey-konushin/360-testing4
Цитировать

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