1 г 5 i 5 6 7 8 9 Wll K)J3 т ?7Wi9 2021.ZZ3?Al

Системные fiemHcmpauuit.

В йейсшЬии

испытания

Проверка рактоспосоЁнасти / Приемочные испытания

Период тестирования, нед

Рис. 3.8. Ошибки в системе программного обеспечения, обнаруженные прн тестировании (Проект 3).

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

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

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

3.2.3. Отдельные этапы разработки как источник ошибок

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

- определение требований; проектирование;

- кодирование программ;

- техническое обслуживание, или сопровождение (связанное с исправлением выявленных ошибок).

Для реализации попытки определения первопри* чины каждой ошибки казалось заманчивым сначала тщательно проанализировать каждый тип ошибок, а затем приписать ему наиболее вероятный источник. Этот путь и был реализован при исследовании данных по Проекту 3, так как при регистрации ошибок не предпринималось никаких мер по определению их источников на этапе испытаний. Результаты проделанной работы представлены в табл. 3.7, где все 2019 ошибок, исправление которых потребовало внесения изменений в исходный текст программ Проекта 3, даны с учетом разбиения на классы. В качестве возможных источников ошибок рассматривались только этапы проектирования. Это было вызвано тем, что для Проекта 2 и Проекта 3 отсутствовали достоверные данные об ошибках, внесенных в программы в процессе исправления ранее обнаруженных ошибок, а ошибки, обусловленные спецификациями, были отнесены за счет проектирования, поскольку спецификации были откорректированы, утверждены и зафиксированы до начала проектирования и оставались неизменными на протяжении всех последующих этапов разработки.

Распределение ошибок между проектированием и кодированием для Проекта 2 могло быть получено только потому, что этап проектирования сопровождался очень подробной документацией, включавшей даже блок-схему на уровне исходного текста. Эта документация передавалась заказчику для проверки и согласования еще до начала этапа кодирования но каждой модификации Проекта 2. Задача программистов состояла в реализации согласованных проектных решений в виде текстов программ на выбранном входном языке. В связи с тем, что Проект 2 постоянно модифицировался, использовались мощные средства ведения документации в соответствии с текущим состоянием разработок. Одним из таких средств была система последовательного обновления документации DUT. Каждая ошибка в программах Проекта 2,