Глава 12: Планирование и документация 347

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

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

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

Документы для юридического использования

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

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

Подробнее этот вопрос рассматривается в главе 14.

Типы тестовых документов

В этом разделе описывается несколько типов документов, составляющих тестовые материалы. Многие из них основаны на стандарте ANSI/IEEE Standard 829-2983for Software Test Documentation, в котором предпринята попыт­ка определить универсальный набор документов для промышленного исполь­зования. О многих других спецификациях для тестовых документов пишет Шалмейер (Schulmeyer, 1987).

Стандарт 829-2983 можно за несколько долларов заказать по следующе­му адресу:

Computer Society of the IEEE P. O. Box 80452 Worldway Postal Center Los Angeles, CA 90080

Можно также позвонить в офис IEEE Standards Sales в Нью Джерси по телефону 201-981-0060.

В стандарте 829 ничего не говорится о том, в каких случаях необходим каждый из перечисленных в нем документов. Выбор комплекса докумен­

348 Часть и: Приемы и технологии тестирования

тов определяется нуждами проекта и личными предпочтениями его руко­водства, поэтому мы воздерживаемся от каких бы то ни было советов по этому поводу. Единственное, что можно сказать наверняка, — это то, что никто и никогда не станет составлять все перечисленные в стандарте до­кументы. Более того, форма и содержание этих документов также зависят от вашего выбора: если какой-либо из них показался вам полезным, это еще не значит, что нельзя опустить некоторые его составляющие. Стандарт никоим образом не должен вас связывать. Он описан в этой книге пото­му, что является хорошей основой, которую после тщательного анализа следует адаптировать к собственным нуждам. И последнее: не пытайтесь написать всю документацию до начала тестирования. Первый черновик тестового плана лучше написать заранее, остальное же гораздо эффектив­нее дорабатывать по ходу тестирования. Кроме того, полезно перед нача­лом тестирования распространить среди заинтересованного персонала комплекс приемочных тестов.

Тестовый план

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

• Идентификатор тестового плана. Это уникальное имя или номер плана. Такой идентификатор полезен при хранении документов в базе данных.

• Введение. В этом разделе приводятся ссылки на все связанные юри­дические документы и стандарты, а также плановые документы са­мого продукта.

• Тестируемые элементы. Речь идет о подлежащих тестированию программных компонентах — функциях, модулях, возможностях и т.п. Можно либо перечислить их прямо здесь, либо сослаться на соответствующий документ. Кроме того, в этот раздел включаются ссылки на спецификации (требования и проектные документы) и документацию к продукту (руководство пользователя, руководство по установке продукта и т.п.).

• Тестируемые функции. Снабдите их ссылками на спецификацию комплекса тестов.

• Нетестируемые функции. Какие именно и почему.

• Подход. Опишите общий подход к тестированию: кем оно выполня­ется, каковы основные видов планируемых работ, какие технологии и средства применяются для тестирования каждой из основных