![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Подготовка документа, содержащего определения требований
• Документ, содержащий определения требований, составлен на естественном языке, вполне понятном заказчикам, пользователям, коллективам разработчиков и специалистам по тестированию
• Воспользуйтесь статическим тестированием для проверки полноты, непротиворечивое™,
•) Пересмотр требований осуществимости и контролепригодноститребований и подтвердите, что требования удовлетворяют потребностям пользователя
-• На стадию проектирования
Рис. 13.1. Процесс формулирования требований
В главе 2 упоминалось о том, что определениям требований присущи следующие характеристики:
• Каждое требование должно быть снабжено уникальным идентификатором, чтобы можно было однозначно ссылаться на него при планировании тестового покрытия, при проектировании тестовых случаев и в отчетах по результатам тестирования.
• Требования должны быть представлены с точки зрения пользователя системы. Системные и приемочные испытания должны быть.спроектированы на основе определений требований, следовательно, эти определения должны быть сфор мулированы в перспективе системного уровня. Этот принцип препятствует по явлению требований, затрагивающих внутренние свойства системы и требую щих детальных знаний программного кода для успешного тестирования. Такие требования должны возникать на поздних стадиях разработки и охватываться модульным тестированием и проверкой взаимодействия и функционирования компонентов системы.
• Должны быть включены как функциональные (functional), так и нефункциональные (nonfunctional) требования. Функциональные требования суть требования, описывающие услуги и функции, которые должна выполнять разрабатываемая сис тема. Нефункциональные требования описывают ограничения, накладываемые на работу системы, например, количество одновременно работающих пользо вателей, и стандарты, которым должна соответствовать система.
• Документ определения требований должен находится под управлением конфи гурациями. Это, по меньшей мере, означает, что данный документ подпадает под управление версиями и что все версии документа должны быть помещены в безопасное хранилище, подобное, например, каталогу, содержимое которого обычно дублируется. Если требования подвергаются изменениям, мы должны иметь возможность проследить, чтобы соответствующие изменения были вне сены в тестовые случаи системных и приемочных испытаний.
Структура документа определения требований может основываться на специфи кациях, определенных в стандарте IEEE Standard 830: The IEEE Guide to Software Require ments Specifications (дополнительные сведения по применению этого стандарта можнонайти в главе 2).
Сейчас мы предлагаем приступим к изучить пример документа определения тре бований, который был подготовлен для вымышленного набора инструментальных средств управления тестированием (Test Management Toolkit, ТМТ). Это приложение позволяет менеджерам и инженерам, специалистам в области тестирования управ лять планами тестирования, отчетами о дефектах, результатами тестирования, а так же другой информацией, связанной с тестированием программного обеспечения. ТМТ представляет собой Web-приложение, благодаря чему несколько географически удаленных пользователей могут одновременно участвовать в нескольких проектах по тестированию. Проект разработки приложения ТМТ приводится в качестве приме ра, который рассматривается на протяжении всей третьей части книги. В следующей главе содержится пример плана тестирования, который основан на требованиях к приложению ТМТ, определенных в данной главе. Определение требований ТМТ TMT-RD-10
Идентификатор документа: TMT-RD-10
Версия: 0.8
Автор: Крис Браун (Chris Brown)
|