Введение

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

Тестирование реализации

Рассмотрим следующую диаграмму состояний:

Рис. 1: Диаграмма состояний кондиционера

Идеи тестов могут быть такими:

• В состоянии простоя возникает событие перегрева
• В состоянии простоя возникает событие переохлаждения
• В состоянии охлаждение-запуск возникает событие работы компрессора
• В состоянии охлаждение-готово возникает событие работы вентилятора
• В состоянии охлаждение-работа возникает событие OK
• В состоянии охлаждение-работа возникает событие неисправности
• В состоянии охлаждение-работа возникает событие устранения неисправности
• В состоянии нагрева возникает событие OK
• В состоянии нагрева возникает событие неисправности

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

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

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

Как в описанном выше примере убедиться, что событие устранения неисправности приводит к переходу из неисправного состояния в состояние простоя? Можно ограничиться тем, что поверить тому, что индикатор неисправности более не горит, но будет лучше понизить температуру до момента включения нагрева или повысить ее до включения охлаждения. Если это произойдет, то вероятно, переход был выполнен правильно. Если ничего не происходит, то скорее всего устройство так и осталось в неисправном состоянии.

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

Прочие конструкции диаграммы состояний

Диаграммы состояний - это не только дуги и стрелки. Далее приведен список конструкций диаграммы состояний и показано их влияние на список идей тестов.

Действия при событии, при входе и при выходе

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

Сторожевые условия

Сторожевые условия - это булевские выражения. Создание идей тестов для сторожевых условий описано в документе Рекомендация по рабочему продукту: идеи тестов для булевских выражений и граничных условий.

В нашем примере для перехода из состояния простоя в состояние переохлаждения есть сторожевое условие [время перезапуска >= 5 мин]. Это приводит к двум идеям тестов:

• В состоянии простоя возникает событие переохлаждения, когда время перезапуска равно пяти минутам
• В состоянии простоя возникает событие переохлаждения, когда время перезапуска меньше пяти минут (переход запрещен)

В обоих случаях в тестах должно быть проверено, что переход ведет в правильное состояние.

Внутренние переходы

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

Вложенные состояния

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

Параллельные подсостояния

Тестирование параллелизма выходит за рамки тестирования разработчиками.

Отложенные события

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

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

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

Хронологические состояния

Пример хронологического состояния:

Рис. 2: Пример хронологического состояния

Переход в хронологическое состояние представляет три фактических перехода и тем самым три идеи тестов:

• Событие резервного копирования в состоянии Команда приводит к состоянию Сбор данных
• Событие резервного копирования в состоянии Команда приводит к состоянию Копирование
• Событие резервного копирования в состоянии Команда приводит к состоянию Очистка

Цепочечные состояния

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

Тестирование проекта

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

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

Рис. 3: Диаграмма состояний кондиционера

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

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

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

Тестирование взаимодействия

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

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