8.7 Заключение

В зависимости от области применения, требования к программному обеспечению могут быть расположены либо в Спецификации Сценариев Использования (Use Cases Specification), либо в Дополнительной Спецификации (Supplementary Specification). Дополнительные требования вместе со сценариями использования содержат в себе все требования к программному обеспечению. Большинство дополнительных требований – нефункциональные. Они относятся к удобству использования, надежности, производительности, способности к сопровождению и ограничениям на дизайн системы.

Наиболее распространенный метод сбора дополнительных требований – интервью и анкетирование с использованием предустановленного набора вопросов. Список упорядочивает требования согласно выбранной классификации, такой как FURPS+[GRA92].

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

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

Ссылки

[EEL01] Eeles, Peter. Capturing Architectural Requirements, Rational Edge, 2001.

[LAU02] Lauesen, Soren. Software Requirements: Styles and Techniques, Boston: Addison-

Wesley, 2002.

[MCC80] McCall, J.A., and M. Matsumoto. Software Quality Metrics Enhancements, Rome Air

Development Center, 1980.

[ISO91] ISO/IEC TR 9126, Information Technology, software product evaluation, quality

characteristics and guidelines for their use. International Organization for Standardization,

Geneva, 1991.

[GRA92] Grady, Robert. Practical Software Metrics for Project Management and Process

Improvement, Upper Saddle River, NJ: Prentice Hall, 1992.

[RUP04] Rational Unified Process, Version 2003.06.13, IBM, 2003.

[CUA91a] Systems Application Architecture Common User Access Guide to User Interface

Design, SC34-4289, IBM Corporation, 1991.

[CUA91b] Systems Application Architecture Common User Access Advanced Interface Design

Reference, SC34-4290, IBM Corporation, 1991.

Глава 9

Создание Тестовых Сценариев

(Test Cases) из

Сценариев Использования

(Use Cases)

Эта глава описывает, как создавать функциональные тестовые сценарии (test cases) из сценариев использования (use cases). Во многих проектах не уделяется достаточного внимания важности этого шага. Часто тестерам отдают распечатанную версию Спецификации Сценариев Использования (Use Case Specification), а затем они проводят тестирование вручную. Однако если мы проигнорируем формальное создание тестовых сценариев, мы можем придти к тому, что будет покрыта не вся область тестирования, в то время как многие тесты будут дублироваться.

Здесь представлен формальный метод, способствующий достижению довольно хорошего покрытия области тестирования с использованием разумного количества тестовых сценариев. Этот подход представил Jim Heumann [HEU01a] [HEU01b]. Подход требует создания сценариев (алгоритмов). Алгоритмы были представлены в Главе 7 «Создание Сценариев Использования (Use Cases)». Тестовые сценарии располагаются одним уровнем ниже сценариев (алгоритмов), как показано на Рисунке 9.1.

Так как эта глава представляет новый тип документов, не определенный в стандартных шаблонах RequisitePro, пункт 9.3 показывает, как создавать новый тип документов в RequisitePro. Если мы хотим избежать любых дополнительных усилий по созданию и настройке нового типа требований и нового типа документов, мы можем связать требования с тестовыми сценариями в инструменте управлением тестированием (например, ClearQuest Test Manager). Тем не менее, создание нового типа - процесс очень быстрый и несложный, и я считаю, что стоит хранить все в среде RequsitePro.

Рисунок 9.1. Извлечение тестовых сценариев (test cases) из сценариев (алгоритмов, scenarios).

9.1 Создание Тестовых Сценариев

Когда у нас есть все сценарии (алгоритмы), полученные в Главе 7, нам нужно создать тестовые сценарии. Этот процесс включает в себя четыре шага:

1. Определение переменных для каждого шага сценариев использования.

2. Определение существенно разных вариантов для каждой переменной.

3. Комбинирование вариантов для тестирования в тестовые сценарии.

4. Определение значений переменным.

Последующие пункты описывают детали каждого шага.

Шаг 1: Определение Переменных для Каждого Шага Сценариев Использования

Первым делом нам нужно определить все входные переменные во всех шагах в представленном сценарии (алгоритме). Например, если на некотором шаге пользователь вводит свой идентификатор и пароль, это две переменных. Первая переменная - Идентификатор, вторая – Пароль. Переменной также может быть выбор, который пользователь должен сделать (такой как выбор рейса из списка).

Приведем переменные из сценария использования Бронирование рейса:

• В3. Турист вводит информацию о рейсе.

  • Аэропорт вылета

  • Дату вылета

  • Аэропорт прибытия

  • Дату прибытия

  • Число путешествующих взрослых

  • Число путешествующих детей

• В5. Турист выбирает рейс.

  • Рейс вылета

• В7. Турист выбирает рейс прибытия.

• Рейс прибытия

• В10. Пользователь предоставляет Идентификатор и Пароль для покупки билета.

• Идентификатор

• Пароль

• В11. Турист предоставляет информацию пассажира.

• Имя

• Фамилия

• Пол

• Дата рождения

• В13. Турист выбирает места.

• Места

• В14. Турист предоставляет информацию по кредитной карте и расчетный адрес.

• Тип кредитной карты

• Номер кредитной карты

• Дата окончания срока действия

• Название карты

• Адрес

• Город

• Штат

• Почтовый индекс

• Страна

Количество переменных может зависеть от введенных на предыдущем шаге значений. На шаге В3 Число путешествующих взрослых = 2, Число путешествующих детей = 1. Тогда шаг В11 будет содержать три набора данных – по одному на каждого пассажира. Если на шаге В5 выбранный рейс имеет остановку, на шаге В13 места должны быть указаны для каждого отрезка полета.

Шаг 2: Определение Существенно Различных Вариантов для Каждой Переменной

Варианты считаются «существенно разными», если они могут вызывать различное поведение системы.

Например, если мы выберем Идентификатор, который предполагается быть длиной до 10-ти символов, следующие приведенные значения будут существенно разными:

• Alex - слишком короткий и мы ожидаем появления сообщения об ошибке.

• Alexandra – верный Идентификатор.

• Alexandrena – слишком длинный, и мы ожидаем, что система не позволит нам вводить слишком длинный Идентификатор.

Однако, Alexandria или JohnGordon различны не существенно, т.к. оба являются верными идентификаторами, вызывающими одно поведение системы.

Ниже приведены некоторые особые случаи.

Вариант может считаться существенно другим, если:

• Он вызывает другой ход процесса (обычно альтернативный поток).

Пример: Ввод неверного пароля вызовет Альтернативный Поток 2.

• Он вызывает другое сообщение об ошибке.

Пример: Если адрес электронной почты слишком длинный, сообщение должно быть: «E-mail должен быть не более 50-ти символов».

Пример: Если адрес электронной почты не содержит символа «@», сообщение должно быть: «Неверный E-mail адрес».

• Он вызывает другой вид пользовательского интерфейса.

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

• Он вызывает различный набор значений списков.

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

Это требования создает три существенно разных варианта:

• США

• Канада

• Любая другая страна

• Он является исходными данными для бизнес-правил.

Пример: Если заказ сделан после 18:00, а пользователь выбрал «Overnight Shipment», будет выдано информационное сообщение о том, что заказ прибудет послезавтра.

Бизнес-правило образует два варианта:

• Ночная Доставка, заказ поступил до 18:00.

• Ночная Доставка, заказ поступил после 18:00.

• Он является условием ограничения.

Пример: Пароль должен быть не менее 6-ти символов.

В этом случае мы должны протестировать следующее:

• Пароль с пятью символами.

• Пароль с шестью символами

• Что-то должно быть изменено вместо использования значения по умолчанию.

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

Это создает два различных варианта:

• Хранить установленное по умолчанию название организации, обслуживающей кредитную карту.

• Изменить установленное по умолчанию название организации на другое.

• Формат ввода точно не определен и может быть интерпретирован разными способами.

Пример: поле ввода номера телефона должно принимать текст в свободной форме.

Номера телефонов разными лицами пишутся по-разному:

• Использования скобок: (973) 123-4567

• Использование тире: 973-123-4567

• Использование пробелов: 973 123 4567

• Без пробелов: 9731234567

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

• Стандартные варианты могут быть разными для разных стран.

Формат даты срока окончания действия кредитной карты может быть разным для США и Европы.

• Если Вы тестируете номера, Вы можете проверить следующие существенно разные варианты:

• Стандартный номер, верный с точки зрения приложения.

• Ноль

• Отрицательный номер

• Наибольшее значение, которое только может быть введено (99999999999999 – столько девяток, сколько может поместиться в поле для ввода).

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

• Выбор прямого рейса

• Выбор рейса с одной остановкой

• Выбор рейса с двумя остановками

• Выбор рейса, прибывающего на следующий день

• Выбор рейса, прибывающего через два дня после даты вылета

Если Вы удивляетесь, каким образом возможен последний вариант, проверьте вечерние рейсы из США в Австралию.

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

• Дата прибытия позже даты вылета (стандартный случай).

• Дата прибытия равна дате вылета (условие ограничения – правильность зависит от времени рейсов).

• Дата прибытия раньше даты вылета (ошибка).

• Не указаны даты (ошибка).

В зависимости от специфики правил Airline Reservation System, мы можем добавить еще вариант, например «Дата прибытия более чем на один год позже даты вылета».

Определим несколько вариантов, нужных для тестирования в основном потоке сценария использования Бронирования рейса:

• В3. Турист вводит информацию о рейсе.

  • Аэропорт вылета

Верный код аэропорта

Верный город и штат

Верный город и страна

Неверный код аэропорта

Несуществующий код аэропорта

Пустое поле

• Дату вылета

Верная дата в будущем, установленная вручную

Верная дата в будущем, установленная из календаря

Дата в прошлом

Сегодняшняя дата

Февраль 30 или 31 число

Пустое поле

• Аэропорт прибытия

Верный код аэропорта

Верный город и штат

Верный город и страна

Неверный код аэропорта

Несуществующий код аэропорта

Пустое поле

• Дату прибытия

Приемлемая дата, одна неделя позже даты вылета

Приемлемая дата, установленная из календаря

Дата, равная дате вылета

Дата в будущем раньше даты вылета

Дата в прошлом

Февраль 30 или 31 число

• Число путешествующих взрослых

0

1

2

Максимально допустимое

• Число путешествующих детей

0 (с числом взрослых = 0)

0 (с числом взрослых > 0)

1 (с числом взрослых = 0)

1 (с числом взрослых > 0)

• В5. Турист выбирает рейс.

  • Рейс вылета

Любой прямой рейс

Рейс с одной остановкой

Рейс с максимальным количеством остановок

Самый дешевый рейс

Рейс, прибывающий на следующий день (если такой есть)

Рейс, прибывающий через два дня (если такой есть)

• В7. Турист выбирает рейс прибытия.

• Рейс прибытия

То же самое, что и для рейса вылета

• В10. Пользователь предоставляет Идентификатор и Пароль для покупки билета.

• Идентификатор

Верный идентификатор пользователя

Идентификатор, содержащие недопустимые символы

Несуществующий идентификатор пользователя

Пустое поле

• Пароль

Правильный пароль пользователя (с правильным идентификатором)

Неправильный пароль (с правильным идентификатором)

Верный пароль (с неверным идентификатором)

Пароль, содержащий недопустимые символы

Пустое поле

• В11. Турист предоставляет информацию пассажира.

• Имя

Верное имя

Длинное имя (максимально допустимое количество символов)

На один символ больше чем допустимо

Один символ

Пустое поле

• Фамилия

Стандартная фамилия

Длинная фамилия (максимально допустимое количество символов)

Фамилия, содержащая апостроф (например Д’Артаньян)

На один символ больше чем допустимо

Один символ

Пустое поле

Два слова с пробелом между ними

• Пол

М

Ж

• Дата рождения

Верная дата

Дата в будущем

Слишком поздняя дата для взрослого

Слишком ранняя дата для ребенка

Неверная дата

• В13. Турист выбирает места.

• Места

Оставить значение по умолчанию

Место у окна

Место в середине

Место у прохода

Два места рядом

Два места отдельно

Одно место при наличии двух пассажиров

• В14. Турист предоставляет информацию по кредитной карте и расчетный адрес.

• Тип кредитной карты

Один вариант для каждой кредитной карты

• Номер кредитной карты

Верный номер для данного типа

Неверный номер для данного типа

Неверный номер для любой карты

Номер, содержащий буквы

Номер, содержащий специальные символы

Пустое поле

• Дата окончания срока действия

Верная дата в будущем

Дата в прошлом

Неверная дата для верной карты

Неверная дата

• Название карты

Оставить значение по умолчанию (имя пассажира)

Ввести новое значение

Верное имя, но не владельца этой карты

Пустое поле

Максимальное количество допустимых букв

• Адрес

Верный адрес

Максимальное количество допустимых символов

Пустое поле

Верный адрес, но не расчетный адрес для этой карты

• Город

Верный город

Максимальное количество допустимых символов

Пустое поле

• Штат

Верный штат

Штат не выбран

• Почтовый индекс

Верный код

Недопустимые символы

Четырехзначный код

Шестизначный код

Пустое поле

• Страна

США

Верная страна, но не США

Несуществующая страна, максимальное количество допустимых символов

Пустое поле

Шаг 3: Комбинирование Вариантов для Тестирования в Тестовые Сценарии

Предыдущий пункт определил все существенно разные варианты, нужные для тестирования. Теперь нам нужно скомбинировать их в последовательность шагов тестового сценария. Один из способов это сделать – создать Матрицу Распределения Тестовых Сценариев (Test Case Allocation Matrix). Строки этой матрицы содержат все переменные для всех шагов, требующие ввода данных он пользователя. Первая колонка содержит номер шага, вторая – название переменной, а остальные – тестовые сценарии. Вы можете назвать их Т1, Т2, и т.д. Вам нужно оценить, насколько много тестовых сценариев нужно для охвата данного сценария (алгоритма). Жестким вариантом оценки будет максимальное количество существенно различных вариантов, определенное для переменной. Не проблема, если Вы допустите ошибку при оценке, т.к. Вы можете добавить или удалить колонку при заполнении матрицы. Обычно типичный сценарий охватывают от пяти до семи тестовых сценариев. Тем не менее, иногда в особых случаях требуется больше тестовых сценариев. Нам нужно создать матрицу для сценария, выбранного для тестирования. Таблица 9.1. показывает Матрицу Распределения Тестовых Сценариев для основного потока сценария использования Бронирование рейса.

Таблица 9.1. Матрица Распределения Тестовых Сценариев со Всеми Переменными для Сценария использования Бронирование Рейса.

Шаг	Переменная	Т1	Т2	Т3	Т4	Т5	Т6
В3	Аэропорт вылета
В3	Дата вылета
В3	Аэропорт прибытия
В3	Дата прибытия
В3	Число путешествующих взрослых
В3	Число путешествующих детей
В5	Рейс вылета
В7	Рейс прибытия
В10	Идентификатор
В10	Пароль
В11	Имя
В11	Фамилия
В11	Пол
В11	Дата рождения
В11	Имя второго пассажира
В11	Фамилия второго пассажира
В11	Пол второго пассажира
В11	Дата рождения второго пассажира
В11	Имя третьего пассажира
В11	Фамилия третьего пассажира
В11	Пол третьего пассажира
В11	Дата рождения третьего пассажира
В13	Места рейса вылета для первого отрезка пути
В13	Места рейса вылета для второго отрезка пути
В13	Места рейса вылета для третьего отрезка пути
В13	Места рейса прибытия для первого отрезка пути
В13	Места рейса прибытия для второго отрезка пути
В13	Места рейса прибытия для третьего отрезка пути
В14	Тип кредитной карты
В14	Номер кредитной карты
В14	Дата окончания срока действия
В14	Название карты
В14	Адрес
В14	Город
В14	Штат
В14	Почтовый индекс
В14	Страна

Для каждой строки введите все необходимые для тестирования варианты. В первой строке - переменная Аэропорт вылета. В каждой колонке мы введем различные варианты для тестирования, как показано в Таблице 9.2.

Таблица 9.2. Ввод Выбранных Вариантов в Матрице Распределения Тестовых Сценариев.

Шаг	Переменная	Т1	Т2	Т3	Т4	Т5	Т6
В3	Аэропорт вылета	Верный код аэропорта	Верный город и штат	Верный город и страна	Неверный код аэропорта	Несуществующий код аэропорта	Пустое поле

Некоторые из этих вариантов неверны, т.к. мы выполняем «негативное тестирование» чтобы увидеть, отображает ли система правильные сообщения об ошибках (или не позволяет пользователю вводить неправильные данные). Чтобы не разрушать тестовый сценарий, мы добавим дополнительные пустые строки, где мы введем несколько верных вариантов для всех значений в предыдущей строке, на которые система должна ответить отказом. Для второго набора вариантов используйте приемлемые комбинации всех верных вариантов из предыдущей строки, а также наиболее популярные варианты. Например, у переменной Аэропорт вылета есть три верных варианта: Верный код аэропорта, Верный город и штат, Верный город и страна. Мы можем использовать все три в строке со вторым набором вариантов. Однако, т.к. зарубежные страны используют аэропорт вылета менее чаще, чем свой аэропорт, и т.к. мы уже протестировали этот вариант в Т3, для второго набора вариантов в Т6 мы выбрали верный код аэропорта (см. Таблицу 9.3). Тем не менее, для Аэропорта прибытия мы выбрали второй раз Верный город и страна, т.к. чаще всего мы не знаем код аэропорта и потому указываем город и штат (см. Таблицу 9.4). Когда у нас встречается несколько раз один и тот же вариант, для каждого из них мы можем позже выбрать различные значения (см. пункт «Шаг 4: Определение Значений Переменным»). Например, Верный код аэропорта может быть EWR в тестом сценарии Т1, LAX в Т4 и JFK в Т6.

Таблица 9.3. Второй Выбор для Неверных Вариантов.

Шаг	Переменная	Т1	Т2	Т3	Т4	Т5	Т6
В3	Аэропорт вылета	Верный код аэропорта	Верный город и штат	Верный город и страна	Неверный	Несуществующий	Пустое поле

Таблица 9.4. Варианты для Аэропорта Прибытия (Предыдущие Строки не Показаны).

Шаг	Переменная	Т1	Т2	Т3	Т4	Т5	Т6
В3	Аэропорт вылета	Верный код аэропорта	Верный город и штат	Верный город и страна	Неверный	Несуществующий	Пустое поле
					Верный код аэропорта	Верный код и штат	Верный город и страна

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

Таблица 9.5. Заполнение Последующих Строк в Матрице Распределения Тестовых Сценариев.

Шаг	Переменная	Т1	Т2	Т3	Т4	Т5	Т6
В3	Аэропорт вылета	Верный код аэропорта	Верный город и штат	Верный город и страна	Неверный	Несуществующий	Пустое поле
					Верный код аэропорта	Верный код и штат	Верный город и страна
В3	Дата вылета	Верная дата (вручную)	Верная дата (из календаря)	Прошлая	Текущая	Неверная	Пустое поле
				Верная, через год		Верная дата (вручную)	Верная дата (из календаря)

Часто нам нужно проверять варианты, установленные нами несколько шагов назад. Например, при установке даты прибытия, нам нужно быть уверенными, что эти варианты соответствуют датам вылета, установленным ранее (см. Таблицу 9.6). Также, при установке числа пассажиров, нам нужно рассмотреть разные комбинации количества взрослых и детей, как показано в Таблице 9.7. Вариант 0/0 не допустим, так что в качестве второго выбора мы добавили 1/max, чтобы добавить случай с максимально допустимым числом детей. Случай 0/1 возможно вызовет сообщение, объясняющее условия, при которых ребенок может путешествовать без сопровождения взрослых.

Таблица 9.6. Варианты для Даты Прибытия.

Шаг	Переменная	Т1	Т2	Т3	Т4	Т5	Т6
В3	Дата вылета	Верная дата (вручную)	Верная дата (из календаря)	Прошлая	Текущая	Неверная	Пустое поле
				Верная, через год		Верная дата (вручную)	Верная дата (из календаря)
				Верная, через неделю	Верная дата, (из календаря)		Верная дата (вручную)

Таблица 9.7. Варианты для Количества Взрослых и Детей.

Шаг	Переменная	Т1	Т2	Т3	Т4	Т5	Т6
В3	Число путешествующих взрослых	1	2	0	1	0	Максимально допустимое
				1
В3	Число путешествующих детей	0	1	0	2	1	1
				Максимально допустимое

Иногда число вариантов для тестирования меньше, чем число колонок, как показано в Таблице 9.8. Заполните оставшиеся ячейки наиболее популярными вариантами или немного другими, но верными вариантами.

Таблица 9.8. Варианты для Идентификатора и Пароля.

Шаг	Переменная	Т1	Т2	Т3	Т4	Т5	Т6
В10	Идентификатор пользователя	Верный	Неверный	Несуществующий	Пустое поле	Верный, максимально допустимое кол-во символов
			Верный	Верный	Верный
В10	Пароль	Правильный	Неправильный	Неверный	Пустое поле	Неправильный
			Правильный	Правильный	Правильный

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

Таблица 9.9. Семь Вариантов для Фамилии (Седьмой Вариант Перемещен на Строку Вторых Вариантов).

Шаг	Переменная	Т1	Т2	Т3	Т4	Т5	Т6
В11	Фамилия	Стандартная	Максимальная длина	С апострофом	Длиннее чем допустимо	Один символ	Пустое поле
					Два слова		Стандартная

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

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

Таблица 9.10. Заполнение Информации о Пассажире в Зависимости от Числа Пассажиров в Определенном Тестовом Сценарии

Шаг	Переменная	Т1	Т2	Т3	Т4	Т5	Т6
В3	Число путешествующих взрослых	1	2	0	1	0	Максимальное
				1
В3	Число путешествующих детей	0	1	0	2	1	1
				Максимальное
			Правильное	Правильное	Правильное	Правильное
В11	Имя	Стандартное	Максимальное	Длиннее чем допустимо	Один символ	Пустое поле	С пробелом
				Стандартное		Стандартное
В11	Фамилия	Стандартная	Максимальная	С апострофом	Длиннее чем допустимо	Один символ	Пустое поле
					Два слова		Стандартное
В11	Пол	М	Ж	Пустое поле	М	Ж	Пустое поле
				М			Ж
В11	Дата Рождения	Верная	Будущая	Неверная	Прошлый год	Более 20 лет назад	Верная
			Верная	Верная	Верная	Верная
В11	Имя второго пассажира		Стандартное	Максимальное	Длиннее чем допустимо		Пустое поле
					Один символ		С пробелом
В11	Фамилия второго пассажира		Максимальная	С апострофом	Длиннее чем допустимо		Пустое поле
					Один символ		Два слова
В11	Пол второго пассажира		М	Ж	Пустое поле		М
					Ж
В11	Дата рождения второго пассажира		Будущая	Неверная	Прошлый год		Верная
			Верная	Верная	Верная
В11	Имя третьего пассажира		Максимальное	С пробелом	Стандартное		Стандартное
В11	Фамилия третьего пассажира		Максимальная	С апострофом	Два слова		Стандартная
В11	Пол третьего пассажира		М	Ж	М		Ж
В11	Дата рождения третьего пассажира		Верная	Верная	Верная		Верная
В11	Имя четвертого пассажира			Верное			Верное
В11	Фамилия четвертого пассажира			В Верное			Верное
В11	Пол четвертого пассажира			Ж			М
В11	Дата рождения четвертого пассажира			Верная			Верная
В11	Имя пятого пассажира			Верное			Верное
В11	Фамилия пятого пассажира			В Верное			Верное
В11	Пол пятого пассажира			М			Ж
В11	Дата рождения пятого пассажира			Верная			Верная
В11	Имя шестого пассажира			Верное			Верное
В11	Фамилия шестого пассажира			В Верное			Верное
В11	Пол шестого пассажира			Ж			М
В11	Дата рождения шестого пассажира			Верная			Верная

Таблица 9.11. Заполнение Мест в Зависимости от Числа Пассажиров в Определенном Тестовом Сценарии и Числа Остановок в Выбранном Рейсе.

Шаг	Переменная	Т1	Т2	Т3	Т4	Т5	Т6
В3	Число путешествующих взрослых	1	2	0	1	0	Максимальное
				1
В3	Число путешествующих детей	0	1	0	2	1	1
				Максимальное
			Правильное	Правильное	Правильное	Правильное
В5	Рейс вылета	Прямой	1 ост.	Макс. кол-во остановок	Самый дешевый	Прибытие на след. день	Прибытие через 2 дня
В7	Рейс прибытия	Прямой	1 ост.	Макс. кол-во остановок	Самый дешевый	Прибытие на след. день	Прибытие через 2 дня
В13	Места в рейсе вылета для 1отрезка пути	Окно	3 места рядом	По умолчанию	2 места вместе, 3-е в след. ряду	У прохода	Только 2 места выбраны
В13	Места в рейсе вылета для 2отрезка пути		Только 1 место выбрано	Все места около окна в разных рядах
В13	Места в рейсе вылета для 3отрезка пути			По умолчанию

Шаг 4: Определение Значений Переменных

На четвертом шаге Вы заменяете неопределенные варианты, такие как «очень длинная фамилия» или «длинный номер телефона с ext. (дополнительным номером)» на действительные значения, например «Georgiamistopolis» и «011-48 (242) 425-3456 ext. 1234» соответственно.

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

Для тестового Сценария 1 сценария использования Бронирование рейса, матрица тестового сценария показана в Таблице 9.12. В дополнении к строкам из Матрицы Распределения Тестовых Сценариев мы добавили строки, представляющие действия. Например, В3 Поиск рейсов означает, что мы выбираем действие, инициирующее поиск рейсов. Обычно это подразумевает нажатие мышкой на кнопке с названием соответствующего действия. Однако на этой стадии мы пытаемся избегать решений о том, будет ли это нажатие на кнопку, ссылку или опцию меню. Позже дизайнер пользовательского интерфейса решит, что лучше использовать в данном случае.

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

Таблица 9.12. Тестовый Сценарий.

Шаг	Переменная	Т1	Ожидаемый результат	Фактический результат	Удачный/ неудачный	Комментарии
В3	Аэропорт вылета	EWR	Принято
В3	Дата вылета	39166	Принято
В3	Аэропорт прибытия	LAX	Принято
В3	Дата прибытия	39179	Принято
В3	Число путешествующих взрослых	1	Принято
В3	Число путешествующих детей	0	Принято
В3	Поиск рейсов	Поиск рейсов	Список рейсов
В5	Рейс вылета	Выбор прямого рейса	Список рейсов
В7	Рейс прибытия	Выбор прямого рейса	Экран входа в систему
В10	Идентификатор	Пользователь 1	Принято
В10	Пароль	Пароль	Принято
В10	Вход в систему	Вход в систему	Экран пользователя
В11	Имя	John	Принято
В11	Фамилия	Smith	Принято
В11	Пол	M	Принято
В11	Дата рождения	Верная	Принято
В11	Подтверждение	Подтверждение	Экран выбора мест
В11	Места в рейсе вылета	Окно	Принято
В11	Подтверждение	Подтверждение	Экран выбора мест
В11	Места в рейсе прибытия	Окно	Принято
В14	Подтверждение	Подтверждение	Экран выбора мест
В14	Тип кредитной карты	Visa	Принято
В14	Номер кредитной карты	4123456789012340	Принято
В14	Дата окончания срока действия	01/01/2009	Принято
В14	Название карты	John Smith	Принято
В14	Адрес	1 Main St.	Принято
В14	Город	New York	Принято
В14	Штат	NY	Принято
В14	Почтовый индекс	10001	Принято
В14	Страна	USA	Принято
В14	Подтверждение	Подтверждение	Номер подтверждения

Этот документ будет отдан тестерам. Тестер будет идти по колонкам 2 и 3, и записывать результаты в колонки 5 и 6.

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

9.2 Бизнес-правила

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

Достаточно часто требование не поступает ни от заказчика, ни от пользователя. Если Вы спросите заказчика, насколько большим должно быть поле фамилии, он может сказать, что ему неважно и попросить Вас решить это. В этом случае, определение длины переменной – это больше стадия проектирования, чем стадия требований.

Мы назовем такой тип требований бизнес-правилами. Их отделение от остальных требований обеспечивает дополнительную гибкость, т.к. бизнес-правила могут меняться со временем. Например, Номер Счета при разработке системы был 8 цифр, а год спустя сменился на 9.

Существует вопрос в том, где бизнес-правила должны быть документально оформлены. Один из вариантов – добавить этот тип требований в пункт Special Requirements (Специальные Требования) в документ Сценариев Использования (Use Cases). Это возможно, если эти правила относятся к сценариям использования. Другой вариант – это справочник или словарь данных.

Еще одна неплохая возможность - создать отдельный документ Business Rules (BR, Бизнес-Правила). Вы можете определить BR как отдельный тип требований. Тогда шаг сценария использования может иметь такую формулировку: «Система проверяет Информацию Счета согласно BRnnn», где nnn – это номер бизнес-правила. Таким образом, бизнес-правила включаются в контекст, что очень полезно для разработчиков. Используя подход OOAD (Object Oriented Analysis and Design – Объектно-Ориентированный Анализ и Проектирование), они знают, в каком методе для конкретного класса нужна проверка.

9.3 Создание Нового Типа Документов

Тестовый Сценарий (Test Case) не является частью стандартного шаблона RequisitePro. Нам нужно создать новый тип документов. Выполните следующие действия:

1. Создайте требуемый шаблон документа в Microsoft Word.

2. Сохраните его как шаблон с расширением .dot, например testcases.dot.

3. Создайте текстовый файл, содержащий три линии:

   • Title (Заголовок).

   • Description (Описание).

   • Name (Название файла, содержащего шаблон).

4. Сохраните текстовый файл с тем же названием, что и шаблон, но с расширением .def, например testcases.def.

Пример .def файла:

Test Cases Outline

The outline to be used for deriving Test Cases from Use Cases.

testcases.dot

5. Положите .dot и .def файлы в каталог ProgramFiles\Rational\RequisitePro\outlines.

6. Откройте диалоговое окно Project Properties (Свойства Проекта), нажав правой кнопкой мышки на названии проекта и выбрав Properties (Свойства), либо выделив название проекта и выбрав File>Properties (Файл>Свойства).

7. Выберите закладку Document Types (Типы Документа).

8. Нажмите кнопку Add (Добавить).

9. Заполните поля диалогового окна Document Type (Тип Документа), как показано на Рисунке 9.2:

Name (Название): Это название появится в списке доступных типов документов в диалоговом окне New Documents (Новые Документы) когда документ будет создаваться.

Description: Любое описание, отражающее смысл.

File Extension: Вы можете выбрать любое расширение, но по смыслу (например TCD для документа Test Case Design - Проектирование Тестовых Сценариев).

Рисунок 9.2. Определение нового типа документов.

10. Выберите Default Requirement Type (Тип Требования по Умолчанию).

Если Вы уже добавили Test Case (Тестовый Сценарий) в список типов документов, используемых в проекте (с помощью описанного в пункте 9.3 метода), выберите его в списке.

Если Вы еще не создали требование тестового сценария, выполните следующие действия для его создания:

а. Нажмите кнопку New (Новый).

б. Заполните поля диалогового окна Requirement Type (Тип Требования), как показано на Рисунке 9.3:

Name (Название): Test Case.

Requirement Tag Prefix (Префикс Требования): TC.

Requirement Color (Цвет Требования): Оставьте по умолчанию Синий (Blue), или выберите другой.

Requirement Style (Стиль Требований): Оставьте по умолчанию Двойное Подчеркивание (Double Underline), или выберите другой.

11. Выберите из списка Outline, Name название шаблона (он был определен в первой линии файла testcases.txt).

12. Нажмите ОК в диалоговом окне Document Type (Тип Документа).

Рисунок 9.3. Добавление нового типа требований.

9.4 Добавление Сценариев (Алгоритмов) и Тестовых Сценариев

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

Создание Новой Папки

Создадим новую папку. Мы можем создать отдельные папки для сценариев (алгоритмов) и тестовых сценариев, либо одну папку для хранения обоих документов.

Для создания новой папки выполните следующие действия:

1. Правой кнопкой мышки нажмите на названии проекта и выберите New >Package (Новая>Папка).

2. Заполните поля диалогового окна, как показано на Рисунке 9.4.

3. Нажмите ОК.

Рисунок 9.4. Создание новой папки.

Создание Документа

Сейчас мы можем создать документ в этой папке. Выполните следующие действия:

1. Правой кнопкой мышки нажмите на папке Scenarios и Test Cases и выберите New>Document (Новый>Документ).

В Document Type (Тип Документа), выберите из списка название, которое было назначено в диалоговом окне Document Type (Тип Документа - см. Рисунок 9.2).

2. Используйте документ как шаблон для создания тестовых сценариев.

Рисунок 9.5. Настройка свойств документа.

Добавление Требований из Explorer (Проводника)

Пункт 5.4 описывает, как можно извлечь требования из документа. Данный же пункт описывает, как добавлять требования из Explorer (Проводника):

1. Правой кнопкой мышки нажмите на папке Supplementary Requirements (Дополнительные Требования) и выберите New>Requirement (Новое>Требование).

2. Заполните поля диалогового окна Requirement Properties (Свойства Требования), как показано на Рисунке 9.6:

Type (Тип): Выберите SC:Scenario из списка.

Name (Название): Вы можете назвать сценарий, используя номер сценария использования и последовательность потоков (например UC1, A6, A7).

Рисунок 9.6. Заполнение диалогового окна Requirement Properties (Свойства Требования) для сценариев.

Введенный сценарий появится в Explorer (Проводнике), как показано на Рисунке 9.7.

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

SC1 TC5 (сценарий 1, тестовый сценарий 5).

Либо можем включить номер сценария использования в название:

UC1, SC1, TC5 (сценарий использования 1, сценарий (алгоритм) 1, тестовый сценарий 5).

Рисунок 9.7. Сценарии (алгоритмы) в Explorer (Проводнике).

9.5 Установка Трассировки

Соответствие между сценариями использования (use cases) и сценариями (алгоритмами, scenarios) – это отношение одно-ко-многим или многие-ко-многим в зависимости от того, что мы сохранили в качестве требований сценария использования. Если мы сохранили полный сценарий использования, один сценарий использования будет соответствовать многим сценариям (одному или более). Если мы сохранили каждый поток или каждый шаг как отдельное требование, отношения между сценариями использования и сценариями будут многие-ко-многим.

Как было рассмотрено в предыдущих главах, для установки трассировки (связи) нам нужно создать Матрицу Трассировки (Traceability Matrix, см. Рисунок 9.8). Затем мы можем установить трассировку путем расстановки стрелок в определенные ячейки, как показано на Рисунке 9.9.

Рисунок 9.8. Диалоговое окно View Properties (Свойства Представления) для создания Матрицы Трассировки (Traceability Matrix) между сценариями использования (use cases) и сценариями (алгоритмами, scenarios).

Рисунок 9.9. Трассировка между сценариями использования (use cases) и сценариями (алгоритмами, scenarios).

Другой путь установки трассировки (связей) – это настройка ее из диалогового окна Requirement Properties (Свойства Требования). Создадим тестовый сценарий из Explorer (Проводника) таким же образом, как мы создавали сценарии. Для установки трассировки при создании требования выполните следующие действия:

1. В диалоговом окне Requirement Properties (Свойства Требования), как показано на Рисунке 9.10, выберите закладку Traceability (Трассировка).

Рисунок 9.10. Диалоговое окно Requirement Properties (Свойства Требования) для тестовых сценариев.

2. Нажмите Add (Добавить) напротив поля From (Из), как показано на Рисунке 9.11.

Рисунок 9.11. Диалоговое окно Requirement Properties (Свойства Требования) для тестовых сценариев.

3. Выберите сценарий, из которого трассируется тестовый сценарий, как показано на Рисунке 9.12.

Рисунок 9.12. Установка трассировка из диалогового окна.

4. Нажмите ОК в диалоговом окне Trace From Requirement(s).

После настройки трассировки (связей) между сценариями и тестовыми сценариями мы можем создать Дерево Трассировки (Traceability Tree), показывающее все пути перехода требования от сценариев использования, к тестовым сценариям, как показано на Рисунке 9.13. Создание Дерева Трассировки было рассмотрено в Главе 6 «Разработка Документа Концепции (Vision)».

Рисунок 9.12. Дерево Трассировки (Traceability Tree) из сценариев использования.