Учебник по тестированию. Guide to Software Test Design
 Скачать 2.51 Mb.
|
|
Практика 1. Ни сайт "Браун и Дональдсон", ни Регистрационная система Государственного университета не содержат огромного количества комбинаций, пригодных для использования попарного тестирования. Поэтому для упражнений используйте технику ортогонального массива и/или технику 67 allpairs на двух других примерах, описанных ниже. Используя выбранную технику, определите набор тестов с попарными комбинациями. 1. Банк создал новую систему обработки данных, готовую к тестированию. У этого банка есть разные клиенты - обычные клиенты, важные клиенты, юр.лица и физ.лица; различные виды счетов - сберегательные, ипотечные кредиты, потребительские кредиты и коммерческие кредиты; плюс отделения банка работают в разных штатах, с разной спецификой проведения фин. операций - Калифорния, Невада, Юта, Айдахо, Аризона и Нью-Мехико. 2. В объектно-ориентированной системе объект класса "А" может передать сообщение, содержащее параметр Р, объекту класса "Х". Классы "B", "C" и "D" унаследованы от класса "А", поэтому тоже могут послать сообщение. Классы "Q", "R", "S" и "T" унаследованы от "P", поэтому могут быть переданы как параметры. Классы "Y" и "Z" унаследованы от класса "X" и могут получать данные. Литература Brownlie, Robert, et al. "Robust Testing of AT&T PMX/StarMAIL Using OATS, " AT&T Technical Journal, Vol. 71, No. 3, May/June 1992, pp. 41–47. Cohen, D.M., et al. "The AETG System: An Approach to Testing Based on Combinatorial Design. " IEEE Transactions on Software Engineering, Vol. 23, No. 7, July, 1997. Kaner, Cem, James Bach, and Bret Pettichord (2002). Lessons Learned in Software Testing: A Context-Driven Approach . John Wiley & Sons. Kuhn, D. Richard and Michael J. Reilly. "An Investigation of the Applicability of Design of Experiments to Software Testing, " 27th NASA/IEEE Software Engineering Workshop, NASA Goddard Space Flight Center , 4–6 December, 2002. http://csrc.nist.gov/staff/kuhn/kuhn-reilly-02.pdf Mandl, Robert. "Orthogonal Latin Squares: An Application of Experiment Design to Compiler Testing ," Communications of the ACM, Vol. 128, No. 10, October 1985, pp. 1054–1058. Phadke, Madhav S. (1989). Quality Engineering Using Robust Design . Prentice-Hall. Wallace, Delores R. and D. Richard Kuhn. "Failure Modes In Medical Device Software: An Analysis Of 15 Years Of Recall Data, " International Journal of Reliability, Quality, and Safety Engineering, Vol. 8, No. 4, 2001. 68 Глава 7. Тестирование состояний и переходов "Полковник Клетус Йорбвиль был одиноким страшно скучающим астронавтом в течение первых нескольких месяцев его дипломатической миссии на третьей планете системы Франгеликус XIV. Но все изменилось в тот день, когда он открыл, что его крошечный многоногий и бесконечно гостеприимный инопланетянин-хозяин оказался не только съедобным, но и замечательным на вкус, примерно как начинка , которая оставлена на сковороде, после того, как вы сделали булочки с корицей и поджарили их немного." Марк Силкокс Введение Диаграммы состояний и переходов, как и таблицы принятия решений – ещё один замечательный инструмент для фиксации определенных видов системных требований и для документирования внутреннего дизайна системы. Такие диаграммы документируют входящие события, которые обрабатываются системой так же, как системные ответы. В отличие от таблиц решений, они очень немного определяют с точки зрения правил обработки. Когда система должна помнить что-то о том, что случилось ранее или если возможен правильный и неправильный порядок операций, то диаграммы состояний и переходов – идеальный инструмент для фиксации такой информации. Эти диаграммы являются жизненно важными в наборе персональных инструментов тестировщика. К сожалению, многие аналитики, проектировщики, программисты и тестировщики не знакомы с этой методикой. Методика Диаграммы состояний и переходов Понятие "диаграмма состояний и переходов" проще объяснить на примере, чем с помощью формального определения. Поскольку ни "Браун и Дональдсон", ни "Регистрационная система Государственного университета" не содержат существенных требований, основанных на состояниях переходов, давайте рассмотрим другой пример. Чтобы приехать в Государственный университет, нам нужно забронировать авиабилет. Давайте позвоним для этого нашему любимому перевозчику (Grace L. Ferguson Airline & Storm Door Company). Мы сообщаем некоторую информацию, в том числе откуда и куда нам нужно лететь, даты и время вылета и прибытия в точку назначения. Агент бронирования, выступающий в роли связующего звена с системой бронирования авиакомпании, использует эту информацию, чтобы осуществить бронирование. Теперь бронирование находится в состоянии " Осуществлено". В дополнение, система создает и запускает таймер. Каждое бронирование имеет определенный промежуток времени, в течение которого оно должно быть оплачено. Эти правила зависят от пункта назначения, класса обслуживания, дат и так далее. Если время истекает до того, как бронирование оплачено, то система его отменяет. В нотации "состояние-переход" эта информация записана как: 69 Рисунок 7-1: Бронирование осуществлено Кружок представляет одно из состояний бронирования - в данном случае, состояние "Осуществлено". Стрелка указывает на переход в состояние "Осуществлено". Описание на стрелке "вводИнформации" - это событие, которое поступает в систему из внешнего мира. Команда после символа "/" обозначает действие системы, в данном случае стартТаймераОплаты. Чёрная точка указывает на стартовую позицию диаграммы. Иногда после выполнения бронирования, но (надеюсь) до истечения срока на таймере, бронирование оплачивают. Это действие представлено стрелкой, обозначенной "оплата". После оплаты бронирование переходит из состояния " Осуществлено" в состояние "Оплачено". Рисунок 7-2: Переход бронирования в состояние "Оплачено". Перед тем, как продолжить, дадим некоторым терминам более формальное определение: ● Состояние (изображается в виде круга) - это состояние, в котором система ожидает возникновения одного или нескольких событий. Состояния "помнят" информацию извне, полученную системой в прошлом, и определяют, как система должна реагировать на последующие события, когда они произойдут. Эти события могут служить причиной изменения состояния и/или вызывать действия. Состояние обычно представляется как значение одной или нескольких переменных в системе. ● Переход (изображается в виде стрелки) - это изменение состояния из одного в другое, произошедшее благодаря какому-то событию. 70 ● Событие (представлено надписью над стрелкой перехода) - что-то, что вызывает изменение состояния системы. Обычно это событие во внешнем мире, информация о котором вводится в систему через её интерфейс. Некоторые события генерируются внутри системы, например, истечение срока таймера или опустившееся до точки пополнения запасов количество предметов в наличии. События считаются мгновенными. События могут быть независимыми или причинно-связанными (событие B не может произойти прежде события А). Когда происходит событие, система может изменить свое состояние или остаться в том же состоянии и/или выполнить действие. События могут иметь параметры, связанные с ними. Например, "Плата денег" может означать оплату наличными, чеком, дебетовой картой или кредитной картой. ● Действие (представлено в виде команды, следующей за "/") - это операция, которая вызвана изменением состояния. Это может быть печать билета , отображение экрана , включение двигателя и т.д. Часто эти действия служат причиной создания каких-либо выходных значений системы. Обратите внимание, что действия происходят при переходах между состояниями. Сами состояния пассивны. ● Входная точка на диаграмме показана черной точкой, а точка выхода показана в виде значка "бычьего глаза". Такая нотация была создана Мили. Муром была определена альтернативная нотация, но она используются реже. Для более глубокого обсуждения диаграмм состояний и переходов посмотрите книгу М. Фаулера и К. Скотта " UML. Основы: Краткое руководство по стандартному языку объектного моделирования ". В ней рассматриваются более сложные вопросы, например, разделенные и вложенные диаграммы состояний и переходов. Обратите внимание, что диаграмма состояний и переходов представляет один конкретный объект (в данном случае Бронирование). Она описывает состояния бронирования, события, которые влияют на бронирование, переходы из одного состояния в другое, а также действия, которые инициируются бронированием. Распространенной ошибкой является смешивание различных объектов в одной диаграмме состояний и переходов. Например, смешивание бронирования и пассажира с событиями и действиями, соответствующими каждому. Из состоянии " Оплачено" бронирование переходит в состояние "Обилечено", когда выполняется команда печати (событие). Отмечу, что в дополнение к переходу в состояние "Обилечено", также система выдает Билет . 71 Рисунок 7-3: Переход бронирования в состояние "Обилечено". Из состояния "Обилечено" мы выдаем билет, который позволит зайти на борт самолета. Рисунок 7-4: Переход бронирования в состояние "Использовано". 72 После какого-нибудь другого действия или периода времени, не указанных на этой диаграмме, путь состояний и переходов заканчивается значком "бычьего глаза". Рисунок 7-5: Путь заканчивается. Показывает ли эта диаграмма все возможные состояния, события и переходы жизненного цикла бронирования ? Нет. Если заказ не оплачен в отведенное время (до истечения ТаймераОплаты), то он будет отменен из-за неуплаты. 73 Рисунок 7-6: Срок оплаты истек и бронирование отменено за неуплату. Теперь всё? Нет. Заказчики иногда отменяют свои заказы. Из состояния " Выполнено" заказчик (через агента бронирования) просит отменить заказ. Требуется новое состояние " Отменено заказчиком". 74 Рисунок 7-7: Отмена бронирования из состояния "Осуществлено". Кроме того, Бронирование может быть отменено из состояния " Оплачено". В этом случае надо выполнить возврат денег и выйти из системы. В результате снова будет состояние " Отменено заказчиком". 75 Рисунок 7-8: Отмена бронирования из состояния "Оплачено". И последнее дополнение. Заказчик может отменить бронирование из состояния " Обилечено". В этом случае должен быть сформирован возврат денег и следующим состоянием должно быть " Отменено заказчиком ". Но этого не достаточно. Авиакомпания произведет возмещение, но только тогда, когда получит от заказчика распечатанный билет. Это вводит еще одно обозначение - квадратные скобки [ ], которые содержат условие, которое может принимать одно из двух значений: истина (True) или ложь (False). Данное условие ведет себя как охранник, позволяющий переход, только если условие истинно. 76 Рисунок 7-9: Отмена бронирования из состояния "Обилечено". Отмечу, что диаграмма всё еще не завершена. Нет стрелки для перехода в "бычий глаз" из состояний "Отменено". Возможно, мы могли бы восстановить бронирование из состояния "Отменено (не оплачено)". Мы могли бы и дальше расширять диаграмму, включив выбор места, отмену рейса и другие значимые события, влияющие на бронирование, но для того, чтобы продемонстрировать технику, достаточно и этого. Как проиллюстрировано, диаграммы состояний и переходов выражают сложные системные правила и взаимодействия в очень компактной форме. Будем надеяться, что когда эта сложность существует, аналитики и проектировщики будут создавать диаграммы состояний и переходов к документу с системными требованиями и будут использовать их для проектирования. Таблицы состояний и переходов Диаграмма состояний и переходов - не единственный способ документирования поведения системы. Диаграммы, возможно, легче в понимании, но таблицы состояний и переходов могут быть проще в использовании на постоянной и временной основе. Таблицы состояний и переходов состоят из четырех столбцов - " Текущее состояние", "Событие", "Действие" и "Следующее состояние". Текущее состояние Событие Действие Следующее состояние 77 пусто вводИнформации стартТаймераОплат ы Осуществлено пусто оплата - пусто пусто печать - пусто пусто выдачаБилета - пусто пусто отмена - пусто пусто срокОплатыИстек - пусто Осуществлено вводИнформации - Осуществлено Осуществлено оплата - Оплачено Осуществлено печать - Осуществлено Осуществлено выдачаБилета - Осуществлено Осуществлено отмена - Отменено заказчиком Осуществлено срокОплатыИстек - Отменено (не оплачено) Оплачено вводИнформации - Оплачено Оплачено оплата - Оплачено Оплачено печать Билет Обилечено Оплачено выдачаБилета - Оплачено Оплачено отмена возвратДенег Отменено заказчиком Оплачено срокОплатыИстек - Оплачено Обилечено вводИнформации - Обилечено Обилечено оплата - Обилечено Обилечено печать - Обилечено 78 Обилечено выдачаБилета - Использовано Обилечено отмена возвратДенег Отменено заказчиком Обилечено срокОплатыИстек - Обилечено Использовано вводИнформации - Использовано Использовано оплата - Использовано Использовано печать - Использовано Использовано выдачаБилета - Использовано Использовано отмена - Использовано Использовано срокОплатыИстек - Использовано Отменено (не оплачено) вводИнформации - Отменено (не оплачено) Отменено (не оплачено) оплата - Отменено (не оплачено) Отменено (не оплачено) печать - Отменено (не оплачено) Отменено (не оплачено) выдачаБилета - Отменено (не оплачено) Отменено (не оплачено) отмена - Отменено (не оплачено) Отменено (не оплачено) срокОплатыИстек - Отменено (не оплачено) Отменено заказчиком вводИнформации - Отменено заказчиком Отменено заказчиком оплата - Отменено заказчиком Отменено заказчиком печать - Отменено заказчиком 79 Отменено заказчиком выдачаБилета - Отменено заказчиком Отменено заказчиком отмена - Отменено заказчиком Отменено заказчиком срокОплатыИстек - Отменено заказчиком Таблица 7-1: Таблица состояний и переходов для бронирования Преимущество таблицы состояний и переходов в том, что в ней перечисляются все возможные комбинации состояний и переходов, а не только допустимые. При крайне необходимом тестировании систем с высокой степенью риска, например авиационной радиоэлектротехники или медицинских устройств, может потребоваться тестирование каждой пары состояние-переход, включая те, которые не являются допустимыми. Кроме того, создание таблицы состояний и переходов часто извлекает комбинации, которые не были определены, задокументированы или рассмотрены в требованиях. Очень полезно обнаружить эти дефекты до начала кодирования. Ключевой момент Преимущество таблицы состояний и переходов в том, что в ней перечисляются все возможные комбинации состояний и переходов, а не только допустимые. Использование таблицы состояний и переходов может помочь обнаружить дефекты в реализации, которые позволяют недопустимые пути из одного состояния в другое. Недостатком таких таблиц является то, что, когда количество состояний и событий возрастает, они очень быстро становятся огромными. Кроме того, в таблицах, как правило, большинство клеток пустые. Создание тест-кейсов Информация в диаграммах состояний и переходов легко может быть использована для создания тестов. Определим четыре разных уровня покрытия: 1. Набор тестов, в котором все состояния будут посещены как минимум один раз. Этому требованию удовлетворяет набор из трех тестов, показанный ниже. Обычно это низкий уровень тестового покрытия. 80 Рисунок 7-10: Набор тестов, которые "посещают" каждое состояние. 2. Набор тестов, в котором все события выполнятся как минимум один раз. Следует отметить, что тест-кейсы, которые покрывают каждое событие, могут быть точно теми же, которые покрывают каждое состояние. Опять же, это низкий уровень покрытия. 81 Рисунок 7-11: Набор тестов, в котором все события выполняются по крайней мере один раз. 3. Набор тестов, в котором все пути будут пройдены как минимум один раз. Несмотря на то, что этот уровень является наиболее предпочтительным из-за его уровня покрытия, это может быть неосуществимо. Если диаграмма состояний и переходов содержит петли, то количество возможных путей может быть бесконечным. Например, дана система с двумя состояниями А и В, где А переходит в В и В переходит в А. Некоторые из возможных путей: A->B A->B->A A->B->A->B->A->B A->B->A->B->A->B->A A->B->A->B->A->B->A->B->A->B и так до бесконечности. Тестирование таких петель, как эта, может быть важным, если они могут привести к накоплению вычислительных ошибок или потери ресурсов (блокировки без соответствующего высвобождения данных, утечки памяти и т.д.). 4. Набор тестов, в котором все переходы будут осуществлены как минимум один раз. Этот уровень тестирования обеспечивает хороший уровень покрытия без порождения большого количества тестов. Этот уровень, как правило, один из рекомендованных. 82 |