Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Управление требованиями (M. Lines).doc
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
10.04 Mб
Скачать

Глава 8 «Дополнительная Спецификация» детально описывает этот тип требований.

Рисунок 1.6. Дополнительные требования извлекаются из функциональных особенностей, которые не могут быть отображены в сценариях использования.

Создание Тестовых Сценариев (Test Cases) из Сценариев Использования

Как только все требования собраны, мы должны разработать способ проверить, правильно ли они реализованы в конечном продукте. Тестовые сценарии (test cases) показывают тестерам, какие шаги должны быть сделаны для того, чтобы протестировать все требования. На этом шаге мы будем концентрироваться на создании тестовых сценариев из сценариев использования. Если мы не создали алгоритмы в процессе создания сценариев использования, мы должны определить их именно сейчас. Тестовые сценарии находятся на низшем уровне пирамиды, как показано на Рисунке 1.7.

Этот процесс детально описан в Главе 9 «Создание Тестовых Сценариев (Test Cases) из Сценариев Использования (Use Cases)».

Создание Тестовых Сценариев (Test Cases) из Дополнительной Спецификации

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

Рисунок 1.7. Тестовые сценарии (test cases) для тестирования сценариев использования (use cases).

Иногда нам необходимо «заимствовать» алгоритм (scenario), который был создан для тестирования сценариев использования (см. Рисунок 1.8). Например, для тестирования требования «Система должна запускаться с использованием браузеров Internet Explorer (IE) и Netscape», мы должны выбрать один алгоритм, желательно основной поток (Basic Flow) наиболее распространенного сценария использования. И затем протестировать полный алгоритм в браузере IE. После мы должны протестировать тот же алгоритм снова в браузере Netscape. Нет необходимости проходить в обоих браузерах все тестовые сценарии, созданные на предыдущем шаге. Просто выберите те, которые содержат немного зависящей от браузера функциональности.

Рисунок 1.8. Тестовые сценарии для тестирования дополнительных требований.

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

Проектирование Системы

Требования являются основой для проектирования системы, которое чаще всего сопровождается использованием Универсального Языка Моделирования – Unified Model Language (UML) [BOO98]. Многие инструменты, такие как Rational Rose, Rational Software Architect, Rational Data Architect и Rational Software Modeler, могут значительно способствовать созданию всех необходимых диаграмм.

Один из подходов заключается в одновременном создании диаграмм взаимодействия из алгоритмов и определении функциональности классов (см. Рисунок 1.9). Данный пункт детально описан в Главе 11 «Объектно-Ориентированное Проектирование».

Рисунок 1.9. Проектирование системы.