данных, особенными значениями и значениями, выходящими за допустимые границы;

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

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

Задачи контроля процедур обработки данных ввода-вывода и манипулирования данными:

- убедиться, что входные данные берутся из соответствующих участков памяти;

- убедиться, что входные данные передаются на хранение в надлежащие области памяти и в требуемом формате;

- убедиться в правильности преобразования всех данных;

- убедиться в правильности реакции программы на некорректные данные;

- убедиться, что данные не теряются и не разрушаются.

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

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

облегчения детального исследования свойств алгоритмов.

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

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

184 Глава 4

-- -,

подтверждение правильности функционирования программного обеспечения в системной среде (систерлные испытания) и рабочие прогоны имеют свои coecTBeH-* ные конкретные цели, однако на каждом из этих этапов выявляются ошибки, которые должны были быть об*. наружены на предыдущих этапах. Представляется, что такое положение дел является неизбежным независимо от усилий, которые были затрачены на испытания по плану и фактически на предыдущих этапах Данные, полученные для Проекта 3, показывают, что только 27% общего числа ошибок (потребовавших изменения программ) были обнаружены своевременно* Общеизвестно, что настоящим бедствием для разработчиков программного обеспечения является постоянное нарушение сроков. Как правило, существу-! ют различные факторы, которые работают против раз-: работчиков. Чаще всего это такие фа1СТоры, которыми сами разработчики либо не могут управлять совеем* либо могут управлять лишь в незначительной степени (например, наличные ресурсы, изменение внешни.1г требований и непредвиденные технические проблемы). Результатом этого является то или иное уплотнение графика, и при этом обычно страдают работы, связанные с испытаниями, которым в планах не уделяется должного внимания. Так, например, в Проекте 3 были запланированы тщательные стендовые испытания подпрограмм, а также проверка сопряжений ня уровне функций и подсистем. Однако график работ оставался фиксированным, несмотря на непрерывное возникновение технических трудностей. Жесткое требование проведения аттестационных испытаний под-, систем и системы в целом независимой группой ) испытаний к установленному графиком сроку, несомнен-: но, положительно сказалось на темпе разработки и ка.< честве программного изделия, но вместе с тем это привело и к форсированию этапа проверки сопряжений и привлечению дополнительного персонала, что естественно, вызвало увеличение интенсивности пото-

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