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

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

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

1. Проведение испытаний программы до тех пор, пока не будут испытаны все сегменты и ветви и пока программа не будет правильно функционировать во всех контрольных примерах.

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

3. Идентификация набора входных данных G,-, логического пути L/ и функционального требования F/, соответствующих каждому контрольному примеру.

4. Выявление всех функциональных требований, не проверяемых непосредственно с помощью имеющихся контрольных примеров, создание для них специальных примеров.

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

6. Использование случайной выборки входов в соответствии с функциональным разрезом для уменьшения числа остаточных ошибок, не выявленных в предшествующих испытаниях.

Шаг 1 является необходимым этапом испытаний, проводимых с целью обнаружить все ошибки. Шаг 2 в значительной мере позволяет решить проблему устранения новых ошибок, вносимых в процессе исправления допущенных ранее. Для его реализации требуется лишь незначительное по сравнению с шагом 1 увеличение числа контрольных примеров, а может и не потребоваться вообще. Шаги 3 и 4 отражают действия, гарантирующие проверку выполнения функциональных требований к программному обеспечению, что необходимо делать в любом правильно организованном процессе испытаний. Реализация шага 5 обеспечивает выявление всех известных типичных ошибок, а шаг 6 гарантирует уменьшение числа остаточных ошибок и одновременно дает возможность измерить надежность программы.

Глава 7

Организация сбора данных о надежности

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

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

7.1. Установленные факты

Разрабатываемые проекты систем программного обеспечения являются потенциальными источниками огромного объема полезной информации, которая в