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

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

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

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

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

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

1. задачи испытаний на каждой фазе, последовательность развития фаз;

2. используемые специальные испытательные средства;

3. количество необходимого машинного времени на каждой фазе испытаний;

4. конфигурация общего технического и программного обеспечения;

5. оцениваемые свойства, критерии оценки, способы их получения;

6. процедуры контроля хода испытания;

7. процедуры регистрации, сбора, обработки и обобщения результатов испытания;

8. условия (критерии) начала и завершения каждой фазы испытаний.

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

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

Методики проведения испытаний

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

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

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

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

4. ПС испытывают в реальной среде функционирования;

5. ПС испытывают в статистически моделируемой среде функционирования, адекватной реальной среде.

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

Например, подход 1 может оказаться предпочтительным, если диапазон входных данных обозрим, сравнительно легко анализируется и систематизируется, и неприемлемым — в противном случае.

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

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