ЛЕКЦИЯ 13. Лекция 13 верификация, тестирование и оценивание корректности программных компонентов
 Скачать 200.7 Kb.
|
|
Требования к характеристикам системы Требования к характеристикам программного средства > Приемо-сдаточные испытания программного продукта на соответствие требованиям к характеристикам системы Верификация спецификации требований к программному средству требованиям к системе <- -> Квалификационное тестирование программного средства в реальном времени Верификация требований к функциональным компонентам требованиям к программному средству <- > Тестирование программ функциональных компонентов в реальном времени Верификация текстов программ спецификациям требований к модулям Тестирование программ функциональных компонентов в статике I Тестирование программных модулей Рис. 13.5 Задача тестирования спецификаций состоит в проверке полноты и взаимного соответствия функций, предписываемых программным и информационным компонентам требованиями разных иерархических уровней (см. п. 13.1). Кроме того, задачи тестирования включают проверку соответствия описаний информации на входах и выходах взаимодействующих программных модулей и групп программ, а также с описаниями информационных модулей в базе данных. В результате тестирования спе- 385 Лекция 13. Верификация, тестирование и оценивание корректности компонентов цификаций должна быть обеспечена их корректность и согласованность в пределах обобщенного описания требований к функциям всего ПС и взаимодействия всех его составных частей. Тестирование взаимосвязей целесообразно проводить, начиная от спецификации требований комплекса или группы программ. Последовательно по иерархическим уровням должно прослеживаться обеспечение программ верхнего уровня реализованными функциями программ нижних уровней, предписанными программными спецификациями. Одновременно проверяется полнота выполнения этих функций спецификациями информационных модулей (см. рис. 13.2). Процесс тестирования программных модулей состоит в проверке корректности обработки модулями поступающей информации и получающихся на выходе данных в соответствии с функциями, представленными в спецификациях требований. Должна быть проверена корректность структуры модулей и примененных конструктивных элементов: циклов, блоков, переключателей и т.д. Так как на этом этапе тестирования участвует наибольшее число специалистов, зачастую не очень высокой квалификации, особое значение приобретают методики тестирования и регламентирование применения средств автоматизации. Проверке подлежат маршруты обработки информации в каждом модуле и правильность их реализации в зависимости от исходных данных. Полнота теста определяется критериями выделения маршрутов для тестирования и степенью покрытия тестами требований спецификаций и возможных маршрутов исполнения программы. На каждом выделенном маршруте должна проверяться корректность выполняемых вычислений при некоторых фиксированных исходных данных. При этом выявляются ошибки неполного состава или некорректности условий при реализации частных маршрутов обработки данных, а также некоторые ошибки преобразования переменных. Для каждого выделенного маршрута по тексту программы формируется набор условий, определяющих его реализацию и используемый при создании соответствующего теста. Такое представление маршрутов позволяет упорядоченно контролировать достигнутый уровень проверки маршрутов и в некоторой степени предохраняет от случайного пропуска отдельных нетестировавшихся маршрутов. Автономное тестирование функциональных компонентов с исполнением программ предназначено для проверки корректности решения отдельных достаточно крупных функциональных задач. На этом этапе про- 386 13.3. Технологические этапы и стратегии систематического тестирования программ веряется корректность управляющих и информационных связей между группами модулей, а также корректность реализации требований в процессе обработки информации в группе программ. При этом значительно возрастает сложность тестируемых объектов и соответственно — размеры и сложность тестов. Вследствие этого возрастают требования к автоматизации тестирования и затраты на его выполнение. Детерминированным тестированием должны проверяться структура группы программ и основные маршруты обработки информации. В ряде случаев результаты следует получать методами стохастического тестирования. Интеграционное тестирование составляет объединение программного кода, соответствующего двум или большему количеству программных модулей, и тестирование полученного в результате кода. Это должно гарантировать, что вместе они работают, как требуется, до полной интеграции и тестирования кода каждого функционального компонента. Так как отдельные модули могут включать другие модули, некоторая часть интеграции и тестирования модулей может происходить в процессе модульного тестирования. Тестовые варианты должны покрывать все требования проекта уровня функциональных компонентов ПС. После этого следует выполнять все необходимые изменения ПС, связанные с коррекцией дефектов, выявленных в процессе верификации, а также повторное тестирование в необходимом объеме и модифицировать файлы разработки ПС и другие программные продукты, основываясь на результатах интеграционного тестирования. Тестирование функциональных компонентов в составе программных средств в процессе разработки комплексов программ и оценки полноты тестирования осуществляются преимущественно по степени выполнения требуемых функций и по характеристикам достигаемой корректности и качества функционирования ПС в целом (см. рис. 13.2). Значительную помощь в повышении качества сложных, критических ПС может оказать систематизация видов тестирования и упорядоченное их проведение при разработке. Эти виды тестирования должны быть ориентированы на дифференцированное выявление определенных классов дефектов. Для каждого вида тестирования целесообразно разрабатывать методику его выполнения с указанием проверяемых компонентов, контролируемых параметров, ожидаемых и эталонных результатов. Кроме того, при заключительных испытаниях или сертификации должно проводиться интегральное тести- 387 Лекция 13. Верификация, тестирование и оценивание корректности компонентов рование при максимально широком варьировании тестов в условиях, соответствующих нормальной и форсированной эксплуатации. Тестирование полноты решения функциональных задач при типовых исходных данных предназначено для обнаружения дефектов функционирования в нормальных, штатных условиях, определенных требованиями технического задания на базовую версию ПС. Первичным эталоном являются цели и задачи создания программного продукта. Некоторая часть тестов может содержать детерминированные исходные данные, для анализа которых часто применяются различные системы графического отображения. Особое внимание целесообразно обращать на варианты тестов, позволивших обнаружить ошибки. Для этих условий следует проводить дополнительное тестирование. Тестирование функционирования программ в критических ситуациях по условиям и логике решения задач {стрессовое тестирование отказоустойчивости) проводится при исполнении программ в нештатных ситуациях, которые редко реализуются, но важны для обеспечения качества и надежности функционирования системы обработки информации. Для разработки таких тестов создаются сценарии критических сочетаний значений исходных данных и условий решения задач, при которых необходимо проверить функционирование программ и можно ожидать искажения результатов и отказы. Такие стрессовые, нештатные сочетания подготавливаются вручную или предусматривается их реализация в составе данных имитаторов стохастических тестов в реальном времени. Особая важность проверки в критических ситуациях определяется опасностью проявления таких ошибок при функционировании ПС в реальных условиях. Поэтому при тестировании активно применяются имитаторы внешней среды, автоматически подготавливающие исходные данные, и средства контроля, реагирующие на аномальные результаты исполнения тестируемых программ. Основные этапы систематического тестирования и испытаний крупного комплекса программ реального времени и его компонентов представлены на рис. 13.6. При тестировании и испытаниях корректности функциональных компонентов комплексов программ выделены этапы: — комплексирование модулей и тестирование автономных функциональных групп программ в статике без взаимодействия с другими компонентами и, возможно, без подключения к операционной системе реального времени; 388 13.3. Технологические этапы и стратегии систематического тестирования программ
Рис. 13.6 389 Лекция 13. Верификация, тестирование и оценивание корректности компонентов Сложность тестирования компонентов на этих этапах в значительной степени обусловлена несинхронным процессом их разработки и отладки отдельными специалистами в коллективах. Первично спланированная логика сопряжения между собой отдельных компонентов и подключения их к операционной системе не всегда выполняется из-за задержек в разработке и автономной отладке некоторых из них. Целесообразная последовательность тестирования определенных компонентов может нарушаться неготовностью к сопряжению с ними других взаимодействующих программ. Для обеспечения имитации объектов внешней среды и других взаимодействующих групп программ на этих этапах используются преимущественно детерминированные контрольные задачи или частные генераторы соответствующих тестов. Эти генераторы тестов целесообразно разрабатывать и оформлять как отдельные модули или группы программ, функционирующие на той же технологической ЭВМ и в той же операционной среде, что и отлаживаемые компоненты. Совместно с ними также реализуются и функционируют частные специализированные программы для обработки и обобщения отдельных результатов тестирования соответствующих групп программ. После комплексирования основных, функциональных компонентов начинаются их тестирование и испытания в составе ПС в целом. Для них наиболее характерны следующие этапы квалификационного тестирования и испытаний ПС в реальном времени (см. рис. 13.6):
На всех этапах тестирования, кроме операций непосредственной проверки функционирования программ, можно выделить еще две важные группы работ. Первая группа — это работы по методическому обеспечению процессов тестирования и по созданию средств автоматизированной генерации тестов. Вторая группа работ должна обеспечивать возможность обработки результатов тестирования и корректной оценки достигнутых характеристик качества функционирования программ. 390 13.4. Процессы тестирования структуры программных компонентов Средства генерации тестов и обработки результатов тестирования можно разделить на три вида (см. рис. 13.6). Одни и те же средства автоматизации тестирования в статике обычно обеспечивают отладку групп программ как автономно, так и во взаимодействии с другими компонентами. Средства, имитирующие внешнюю среду в реальном времени, чаще всего ориентированы на тестирование как функциональных компонентов, так и ПС в целом. Еще один вид генераторов тестов в той или иной степени использует реальные объекты внешней среды. Первоначально такими объектами являются имитирующие стенды с участием реального функционирования операторов-пользователей (см. лекцию 14). Затем источниками тестов могут быть комплексы реальной аппаратуры внешних объектов или их аппаратурные аналоги. Рассмотренная схема ориентирована на тестирование и испытания комплекса программ, размещаемого на единой аппаратной платформе. При создании распределенных систем клиент-сервер возникают дополнительные, весьма сложные задачи тестирования. Программные средства, размещенные на аппаратных платформах клиентов и серверов, необходимо первоначально тестировать автономно по представленной выше полной программе, а затем дополнительно их взаимодействие. Это взаимодействие клиентской и серверной частей программного комплекса должно быть подготовлено автономным тестированием всей системы телекоммуникации и гарантированием ее качества. После этого следует повторить последние три этапа комплексного тестирования в реальном времени, представленные на рис. 13.6, но уже при полном взаимодействии обоих функциональных компонентов системы клиент-сервер. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||