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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ос­новные этапы систематического тестирования и испытаний крупного комплекса программ реального времени и его компонентов представлены на рис. 13.6. При тестиро­вании и испытаниях корректности функциональных компонентов комплексов программ выделены этапы:

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

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

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

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

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

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

- по данным моделирующего стенда или генераторов тестов, имитирующих отдельные объекты внешней среды;

- с имитаторами отдельных объектов внешней среды и с реаль­ными воздействиями от операторов-пользователей;

- в полностью адекватной реальной или имитированной внешней среде и с реальными воздействиями от операторов-пользователей (см. лекцию 14).

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

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

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