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

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

Рис. 10.8. Взвешенная оценка подходов к сборке.

III. ИСПЫТАНИЕ ПРОГРАММНЫХ ПРОДУКТОВ (АНАЛИЗ).

ЦЕЛЬ И ОСОБЕННОСТИ ИСПЫТАНИИ.

Испытания являются важнейшим элементом управления качеством продукции. В соответствии с ГОСТ 16504—81 под испытанием промышленной продукции понимают экспериментальное определение количественных и/или качественных характеристик объекта испытания как результата воздействия на него; при его функционировании; при моделировании объекта и/или воздействия. Под испытанием программной продукции следует понимать экспериментальное определение количественных и/или качественных характеристик свойств продукции при ее функционировании в реальной среде и/или моделировании среды функционирования.

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

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

В соответствии с ГОСТ 19,004—80 под испытанием программ понимают установление соответствия программы заданным требованиям и программным документам. Это определение построено на предположении, что в техническом задании на разработку программы определены все требования (характеристики), обеспечение которых гарантирует пригодность программы к использованию по своему назначению. Но такое требование редко соблюдается на практике. В некоторых случаях, особенно в автоматизированных системах, ТЗ на ПС либо вообще не пишут, либо в них перечисляют лишь функции, которые возлагаются на ПС, без указания требований к другим потребительским свойствам. При отсутствии ТЗ на разработку ПС или полного и обоснованного перечня требований к характеристикам разрабатываемого ПС задача испытания ПС становится неопределенной и неконструктивной. Что значит установить соответствие программы заданным требованиям, если эти требования формально не заданы? Какая польза от установления такого соответствия, если эти требования заведомо “усечены” и не отражают основных потребительских свойств программы? Пользователю будет не легче, если программа функционирует плохо, но это в явном виде не противоречит требованиям ТЗ.

При наличии в ТЗ требуемых характеристик основных потребительских свойств ПИ приведенные определения термина “испытание” по цели испытания практически совпадают. Однако и в этом случае первое определение является более конструктивным, так как оно формулирует не только цель, но и основной метод проведения испытании — проверка ПИ, функционирующего в реальной или моделируемой, но близкой к реальной среде,

В зарубежной литературе, в том числе в стандартах на программное обеспечение, понятие “испытание” часто отождествляют с понятием “тестирование”. Например, в Std IEEE 829—1983 “Документация тестов программного обеспечения” (США) дано следующее определение тестирования: “...процесс активного анализа ПО на предмет обнаружения расхождения между реальными и требуемыми нормами ПО (т. е. наличия ошибок в программах) и с целью оценки характеристик элементов ПО”. Данное определение объединяет два приведенных определения термина “испытание” с той лишь разницей, что при принятой (см. определения) концепции поиск и локализация ошибок на являются явно выраженными целями испытания. С учетом высказанных соображений термин “тестирование”, используемый в зарубежной литературе, будем интерпретировать как испытание методом тестирования,

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

Основными видами испытания ПП являются предварительные, приемочные и эксплуатационные испытания, включая опытную эксплуатацию. Особенности их организации и проведения подробно рассмотрены в книге [18].

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

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

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

ТЕХНОЛОГИЧЕСКАЯ СХЕМА ИСПЫТАНИЯ.

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