Тестирование инф.систем. Ответы на вопросы к лекциям Понятие тестирования программного обеспечения
 Скачать 0.52 Mb.
|
«верный» и «неверный» отображенные в квадратных скобках с точки зрения нотации обозначают условия.В состоянии оплаты система будет отображать страницы, а покупатель вводить данные об оплате. Будет ли эта информация верна – снова условия, – которые определяют, может ли система завершить и подтвердить транзакцию. Как только транзакция подтверждена, пользователь может продолжить покупку либо пойти на другой сайт. Также заметим, что пользователь всегда может отменить транзакцию и уйти на другой сайт. Часто при разборе тестирования на основе состояний, возникает вопрос: «Как различить состояние, событие и действие?» Основные отличия следующие: в состоянии объект находится до тех пор, пока что-то не произойдет – что-то внешнее по отношению к самому объекту, обычно – вызывающее переход. В состоянии объект может существовать бесконечно долго; событие происходит либо сразу, либо в ограниченный, конечный период времени. Это что-то, что наступает, происходит вне, – и вызывает переход; действие – это ответ системы во время перехода. Действие, как и событие, либо мгновенно, либо требует ограниченного, конечного времени. Известно, что иногда одну ситуацию можно отразить по-разному, особенно когда одно состояние или действие может быть разбито на последовательность элементарных состояний, событий и действий. Чуть позже рассмотрим такой случай на примере разбиения состояния оплаты на подсостояния. И наконец, заметим, что, как было заявлено в самом начале, диаграмма нарисована с точки зрения клиента. Если изобразить ее с точки зрения системы, то она выглядела бы по-другому. Поддержание постоянной и единой точки зрения критично для изображения таких диаграмм, иначе будут происходить абсурдные вещи. Тестирование на основе состояний использует формальную модель, поэтому имеется формальная процедура для получения тестов из модели. Приведенный ниже список показывает процедуру, которую можно использовать для получения тестов, которые позволяют достигнуть покрытия состояний/переходов (т.е. «покрытие 0 переходов»). Введем правило для того, где тестовая процедура или шаг должны начинаться и где заканчиваться. В качестве примера утвердим, что тестовая процедура должна начинаться в начальном состоянии и может закончиться только в конечном состоянии. Причина использования слов «может» или «должен» для определения окончания в том, что в ситуациях, где начальное и конечное состояния – одно и то же, может потребоваться разрешить последовательности состояний и переходов, которые проходят через начальное состояние более чем один раз. Начиная с разрешенного состояния начала теста, определим последовательность комбинаций событий и условий, которые приводят к разрешенному состоянию окончания теста. Для каждого перехода, который происходит, зафиксируем ожидаемое действие, которое должна произвести система. Это ожидаемый результат. Когда проходим каждое состояние и каждый переход, помечаем его как покрытый. Простейший способ для этого – распечатать диаграмму переходов состояний и, используя карандаш или маркер, помечать каждый узел и стрелку по мере покрытия. Повторять шаги 2 и 3 до тех пор, пока не пройдены все состояния и все переходы. Иными словами, пока каждое состояние и переход не будут помечены карандашом или маркером. Такая процедура позволяет генерировать логические тестовые сценарии. Для создания именованных тестовых сценариев (тестовых сценариев низкого уровня) необходимо сгенерировать фактические входные и выходные данные. Здесь рассматривается создание логических тестовых сценариев для иллюстрации методики, но нужно помнить, что в определенной точке перед выполнением тестов должны быть созданы именованные тестовые сценарии. Посмотрим на этот процесс на примере приложения электронной коммерции, которое мы только что рассматривали. На рисунке 9 пунктирными линиями показаны покрытые состояния и переходы.  Рисунок 9 – Проверка покрытия 1 На рисунке 9 нужно отметить две вещи. Первое, это правило, которое гласит, что тест должен начинаться в начальном состоянии и заканчиваться в конечном. И второе, это то, какие шаги включены в тест: («просмотр», «пройти по ссылке», «отобразить», «добавить в корзину», «диалог выбора», «продолжить», «отобразить», «добавить в корзину», «диалог выбора», «посчитать», «диалог авторизации», «вход [неверный]», «ошибка», «вход [верный]», «диалог оплаты», «оплата [неверно]», «ошибка», «оплата [успешно]», «подтверждение», «продолжить покупку», «отобразить», «отмена», «выход»). Теперь проверим полноту покрытия, которое отслеживается на диаграмме переходов состояний. Как видно, покрыты все состояния и большинство переходов, но не все. Необходимо создать еще несколько тестов. На рисунке 10 изображено покрытие, которое было достигнуто путем дополнительных тестовых процедур, которые покрывают диаграмму переходов состояний: («просмотр», «пройти по ссылке», «отобразить», «добавить в корзину», «диалог выбора», «продолжить», «отобразить», «добавить в корзину», «диалог выбора», «посчитать», «диалог авторизации», «вход [неверный]», «ошибка», «вход [верный]», «диалог оплаты», «оплата [неверно]», «ошибка», «оплата [успешно]», «подтверждение», «продолжить покупку», «отобразить», «отмена», «выход»); («просмотр», «добавить в корзину», «диалог выбора», «отмена», «выход»); («просмотр», «добавить в корзину», «диалог выбора», «посчитать», «диалог авторизации», «отмена», «выход»); («просмотр», «добавить в корзину», «диалог выбора», «посчитать», «диалог авторизации», «вход [верный]», «диалог оплаты», «отмена», «выход»); («просмотр», «добавить в корзину», «диалог выбора», «продолжить», «отобразить», «добавить в корзину», «диалог выбора», «посчитать», «диалог авторизации», «вход [верный]», «диалог оплаты», «оплата [успешно]», «подтверждение», «уйти на другой сайт»). Рисунок 8 отражает проверку покрытия состояний и переходов. Процесс нельзя считать завершенным до тех пор, пока каждое состояние и каждый переход не помечены, как сделано на этом рисунке.  Рисунок 10 – Завершающая проверка покрытия Суперсостояния и подсостояния. В некоторых случаях полезно преобразовать отдельное состояние в суперсостояние, состоящее из двух или более подсостояний. На рисунке 11 можно увидеть, что состояние оплаты из примера расширено тремя подсостояниями.  Рисунок 11 – Суперсостояния и подсостояния Правило базового покрытия здесь простое. Покрыть все переходы в суперсостояние, все переходы из суперсостояния, все подсостояния и все переходы внутри суперсостояния. Заметим, что для нашего примера это увеличит число тестов, поскольку теперь имеется три перехода «отмена» из состояния «оплаты» в состояние «выход» вместо одного. Это также увеличит количество элементов в тестах, т.е. станет больше событий и действий, за счет того, что нужно убедиться, что протестированы как минимум три различных типа сущностей неверной оплаты. В чем разница между состоянием, событием и действием? • в состоянии объект находится до тех пор, пока что-то не произойдет – что-то внешнее по отношению к самому объекту, обычно – вызывающее переход. В состоянии объект может существовать бесконечно долго; • событие происходит либо сразу, либо в ограниченный, конечный период времени. Это что-то, что наступает, происходит вне, – и вызывает переход; • действие – это ответ системы во время перехода. Действие, как и событие, либо мгновенно, либо требует ограниченного, конечного времени. Что такое тестирование переходов состояний? Согласно глоссарию ISTQB, тестирование переходов состояний (state transition testing) – это разработка тестов методом черного ящика, в котором сценарии тестирования строятся на основе выполнения корректных и некорректных переходов состояний. Как построить таблицу переходов состояний? Для построения таблицы переходов состояний сначала нужно перечислить все состояния из диаграммы переходов состояний (см. рис. 12) из примера, который рассматривался в предыдущем разделе.  Рисунок 12 – Диаграмма переходов состояний для приложения электронной коммерции Дальше нужно перечислить все комбинации событий/условий из диаграммы переходов состояний. Далее создается таблица, в которой каждая строка соответствует комбинации состояния и каждого события/условия. Каждая строка имеет четыре поля: текущее состояние; событие/условие; действие; новое состояние. Для строк, где диаграмма переходов состояний определяет действие и новое состояние для заданных комбинаций текущего состояния и события/условия, можно заполнить эти два поля (действие и новое состояние) из диаграммы переходов состояний. Однако для остальных строк в таблице они не определены. Теперь можно идти к бизнес-аналитикам, проектировщикам системы или другим участникам и спросить: «Ну, что же должно произойти в каждой из этих ситуаций?» И скорее всего в ответ вы услышите: «А, такая ситуация не случится!». Но как тест-аналитик, вы знаете, что это значит. И теперь ваша задача показать, как это может случиться. На рисунке 13 изображена часть таблицы, которую можно создать для примера приложения электронной коммерции, который рассматривался в предыдущем разделе.
Рисунок 13 – Пример таблицы переходов состояний | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||