Методологические основы

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

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

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

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

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

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

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

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

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

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

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

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