Смекни!
smekni.com

Тестирование программных продуктов (стр. 6 из 10)

Рассмотренный метод планирования на этапе автономных статистических испытаний модулей ПИ позволяет значительно уменьшить материальные и временные затраты на испытание программ. Ориентация на тот или иной подход к испытаниям зависит от типа испытываемого ПС.

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

Эта стадия наиболее длительная и наиболее трудоемкая. Основными ее задачами являются: планирование испытаний;

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

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

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

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

В стандарте IEEE 829—1983 (США) большое внимание уделено документированию процесса испытания ПП. Перечень документов, которые разрабатываются и ведутся в соответствии с планом испытания, приведен в разделе “Документирование”,

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

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

При оценке уровня завершенности испытаний ПС и достоверности полученных результатов часто возникают серьезные затруднения. Отметим следующие из них:

1) большинство ПС являются уникальными и либо не имеют аналогов для сравнения характеристик, либо имеют аналоги, характеристики которых неизвестны;

2) отсутствие общепринятых показателей, а также методов расчета требуемых и фактических значений приводит к тому, что в ТЗ на разработку ПС требования к характеристикам ПС либо фактически отсутствуют (в количественном выражении), либо не претендуют на полноту.

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

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

Не всякую ошибку можно быстро идентифицировать, поэтому в стандарте IEEE 829—1983 рекомендовано документировать в виде отчетов тест-инцидент все нестандартные события, происходящие во время испытания и требующие дополнительного анализа. Рекомендуется следующая структура этого отчета: идентификатор отчета тест-инцидент, аннотация, описание инцидента, влияние инцидента на последующий ход испытания. Последние два раздела являются основными. Описание инцидента должно включать следующие элементы: входные данные, ожидаемые и фактические результаты, отклонение от нормы, дата и время испытания, шаг процедуры испытания, среда функционирования, результаты попыток повторения условий эксперимента, испытатели, наблюдатели-регистраторы.

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

Критерий интенсивности обнаружения ошибок. Если считать, что во время одного эксперимента обнаруживается не более одной ошибки и каждая ошибка до начала следующего эксперимента устраняется, то можно предположить, что при благоприятном ходе отладки и испытания кривая зависимости: N = 1 — п/К, где п — количество обнаруженных и устраненных ошибок; К. — . количество экспериментов, будет асимптотически стремиться к единице (кривая 1 на рис. 17). Кривая 2 свидетельствует о неблагополучном ходе процесса.

Тогда в качестве критерия прекращения испытаний можно принять, например, следующее условие: N > 0,95 при обнаружении в последних двухстах экспериментах не более трех несущественных ошибок.

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

Критерий заданного значения средней наработки на отказ (критерий Дж. Д. Муса). Сделано два предположения. 1. Суммарное количество обнаруженных и устраненных дефектов в про

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

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

С—коэффициент сжатия тестов. Коэффициент С

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