Часть I. Процесс быстрого тестирования. поэтому полезно разбить требования на категории

поэтому полезно разбить требования на категории. Пример набора таких категорий представлен следующим списком:

• Функциональные средства. Этот набор требований определяет, какие функ­ции должен выполнять данный программный продукт на системном или поль­ зовательском уровне. Для ясности может быть указано, чего ие должен делать данный продукт.

• Интерфейсы. Эта категория требований описывает входы, получаемые извнешних систем, и выходы, направляемые во внешние системы. Накладывают­ ся ли на эти интерфейсы какие-то ограничения, связанные с форматами дан­ ных и носителями информации?

• Данные. Эти требования описывают входные и выходные данные системы.Какой при этом используется формат? Какие данные нужно сохранять? Какой объем данных поступает в систему и из системы, и с какой скоростью передачи? С какой точностью должны выполняться вычисления?

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

• Пользователи и человеческий фактор. Эта категория требований предъявля­ется к тем, кто будет работать с системой в смысле их квалификации и опыта. Они также определяют необходимый уровень удобства и простоты использо­ вания программного продукта, например, сколько отдельных действий требу­ ется для выполнения рутинной операции в системе? Насколько отчетливо вы­ ражена обратная связь после каждого действия?

• Физическая среда. Эта категория требований определяет, где должно функ­ционировать оборудование. Установлено ли оборудование более чем в одном месте? Имеют ли место ограничения по температуре, влажности или другие ог­ раничения, связанные с окружающей средой?

• Безопасность. Эта категория требований описывает, как осуществляется дос­туп к системе и как осуществляется управление ее данными. Данная категория является подходящим местом для описания, как должны дублироваться систем­ ные данные. Как часто следует выполнять дублирование? На каких носителях сохраняются дублированные данные?

• Документация. Эта категория требований связана с документацией и тем, должна ли она быть представлена в печатном виде или выдается в интерактив­ ном режиме. Кроме того, здесь же определяется категория лиц, для которых эта документация предназначена.

• Устранение неисправностей. Эта категория требований описывает, как сис­тема реагирует на возникновение неисправностей. Будет ли система обнару­ живать неисправность и выдавать аварийные сигналы? Какой должна быть

средняя длительность промежутка времени между двумя неисправностями? Ка­ ким должно быть максимальное время простоя?

и Сопровождение. Эти требования определяют, как производится устранениепроблем, обнаруженных в системе, как усовершенствованные версии системы поставляются заказчику и как пользователи должны переходить на усовершен­ ствованную версию системы.

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

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

Примеры требований. Пример, содержащий несколько функциональныхтребований, приводится на рис. 2.4. Этот пример относится к гипотетическому про­ дукту, который мы будем " разрабатывать" на протяжении практически всей книги. Указанный демонстрационный программный продукт, который мы назовем ком­ плектом ТМТ (Test Management Toolkit — инструментальные средства управления тестами), представляет собой приложение, предназначенное для тестовых групп, которым необходимы автоматизированные инструментальные средства для под­ держки планирования тестирования, разработки тестовых случаев и выполнения тестов. Определение требований к комплекту ТМТ можно найти в третьей части книги.

Требования, представленные на рис. 2.4, касаются некоторых ключевых свойств программного продукта.