Технологические этапы и стратегии систематического тестирования программ

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

Лекция 13. Верификация, тестирование и оценивание корректности компонентов

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

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

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

13.3. Технологические этапы и стратегии систематического тестирования программ

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

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

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

При систематическом восходящем тестировании, прежде всего, проверяются программные компоненты и/или модули нижних иерархических

Лекция 13. Верификация, тестирование и оценивание корректности компонентов

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

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

С учетом особенностей применения методов и технологических этапов ЖЦ программных компонентов ниже в данном разделе последовательно рассматриваются задачи восходящего тестирования следующих объектов:

— формализованных спецификаций требований на программные и информационные модули, на группы программ и на программные комплексы;

13.3. Технологические этапы и стратегии систематического тестирования программ

— программных модулей, запрограммированных и подготовленных к тестированию на уровне исходных текстов программ и на уровне объектных кодов реализующей ЭВМ;

— автономных групп программных модулей и компонентов, решающих законченные функциональные задачи;

— функциональных компонентов в составе программных средств.