Лекция
Привет, Вы узнаете о том , что такое этапы системного тестирования, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое этапы системного тестирования, стратегии систематического тестирования , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..
Исходным эталоном для тестирования любой программы являются требования технического задания и/или спецификации требований заказчика и потенциального пользователя, предъявляемые к создаваемым программам. Подобные документы должны устанавливать состав, содержание и значения результатов, которые должен получать пользователь при определенных условиях и исходных данных. Любое отклонение результатов функционирования программы от предъявляемых к ней требований и сформированных по ним эталонов следует квалифицировать как ошибку или дефект в программе.
Эталонные значения параметров и характеристик результатов тестирования для вычислительных программ получать относительно проще, прежде всего потому, что требуется значительно меньшее количество контрольных величин. Промежуточные значения результатов можно определять интерполяцией или вообще пропускать, опираясь на предположение о гладкости вычисляемых функций, т.е. необязательна подготовка эталонов при абсолютно всех комбинациях исходных данных. При том же объеме тестируемой программы подготовка эталонных значений для логических программ усложняется, прежде всего, вследствие их комбинаторного характера и увеличения необходимого числа тестовых значений. В этом случае тесты, в принципе, необходимо рассчитывать для всех возможных сочетаний исходных данных, так как каждое из них может полностью изменять область определения и смысловое значение результирующих величин.
На математических моделях или прототипах, реализуемых на ЭВМ, наиболее эффективно получать эталонные значения и требуемые характеристики функционирования сложных программ. Возможно создание моделей двух типов: на базе более сложных и более точных алгоритмов, которые, например, не могут быть реализованы на объектной ЭВМ вследствие ограниченных ресурсов, и на базе упрощенных, обобщенных моделей для более быстрого получения эталонных значений. Модели второго типа, естественно, характеризуются меньшей потенциальной точностью результатов, однако, благодаря снижению сложности, в них менее вероятны ошибки.
Результаты функционирования реальных программ, являющихся предшественниками-прототипами или пилотными проектами разрабатываемой версии ПС, для использования в качестве эталонов при тестировании требуют обеспечения идентичности и повторяемости исходных данных, используемых проверяемыми программами при получении эталонных значений. На завершающих стадиях создания ПС формализация эталонных значений в ряде случаев не доводится до конца и в качестве эталона выступает неформализованное представление разработчика или заказчика. Во всех случаях целесообразно фиксировать и сохранять значения используемые в качестве тестовых эталонов для обеспечения повторяемости сеансов тестирования.
При сравнении результатов функционирования проверяемых программ на соответствие эталонам следует использовать критерии оценки допустимых отклонений от эталонов и решений о степени корректности программы. Величина допусков зависит от типа проверяемого алгоритма, метода и этапа проверки корректности программ. Для простых логических алгоритмов, реализующих некоторые схемы принятия решений, при анализе результатов тестирования обычно используется детерминированный критерий абсолютной идентичности проверяемых и эталонных решений при одинаковых исходных данных. В вычислительных алгоритмах и при проверке сложных логических алгоритмов сравнение с эталоном приходится осуществлять статистически.
Выделение и стратегия упорядочения компонентов для тестирования в крупных ПС зависит от их архитектуры и реального состава готовых к использованию компонентов. При нисходящем тестировании от требований оно начинается с программ организации вычислительного процесса. Первоначально тестируются управляющее ядро комплекса программ и программы решения функциональных задач, размещенные на высших иерархических уровнях, на соответствие исходным требованиям технического задания. К ним последовательно, по мере готовности, подключаются компоненты более низких иерархических уровней. Такая стратегиясверху вниз эффективна, когда имеется достаточно полный набор готовых апробированных программных компонентов и/или модулей, ранее отработанных в версиях подобных или пилотных программных комплексов.
Если некоторые программы нижних уровней не разработаны или недостаточно протестированы, то вместо них временно могут подключаться программные имитаторы — «заглушки». В результате при тестировании на начальных этапах проверяются модели функциональных групп программ или комплекса с некоторым числом имитаторов программных компонентов. Преимуществом такой стратегии тестирования является сохранение и последовательное развитие тестовых исходных данных по мере подключения компонентов. Однако тестирование групп программ с заглушками может требовать больших затрат на обнаружение простейших ошибок во вновь разработанных и подключаемых модулях, если они до этого автономно недостаточно тестировались.
При систематическом восходящем тестировании, прежде всего, проверяются программные компоненты и/или модули нижних иерархических
уровней в функциональной группе программ, к которым последовательно подключаются вызывающие их модули. В этих модулях тестирование также начинается с простейших конструкций, переменных и маршрутов обработки информации. Соответственно последовательно усложняются используемые методы тестирования и типы выявляемых при этом ошибок. Последовательное наращивание компонентов в комплексе программ снизу вверх позволяет проверять работоспособность таких групп в их естественном исполнении, без подмены и имитации компонентов нижних уровней. Основные трудности при такой стратегии состоят в необходимости непрерывного обновления и увеличения числа тестовых наборов по мере подключения каждого нового компонента более высокого уровня. Одновременно углубляется тестирование компонентов нижних иерархических уровней, что способствует систематическому повышению их качества.
Нисходящее и восходящее тестирование отличаются не только схемой анализа модулей или небольших компонентов, но также принципиальными целями всего процесса тестирования крупных комплексов программ. Об этом говорит сайт https://intellect.icu . Основная цель нисходящего тестирования — верифицировать требования к модулям и программным компонентам, а также добиться их качества при автономном тестировании каждого из них вне реального времени. Тем самым в процессе декомпозиции должно быть обеспечено требуемое качество компонентов и их соответствие исходным требованиям. При восходящем тестировании главная задача — обеспечить укрупнение, интеграцию и корректное взаимодействие всех компонентов для полного решения задач требуемым комплексом программ. При этом предполагается достаточно высокое качество подготовленных ранее компонентов. Представленные в данной главе фрагменты этих базовых процессов тестирования схематично объединены на рис. 13.5. Подобную схему полезно иметь в виду при планировании стратегии тестирования крупных ПС.
С учетом особенностей применения методов и технологических этапов ЖЦ программных компонентов ниже в данном разделе последовательно рассматриваются задачи восходящего тестирования следующих объектов:
— формализованных спецификаций требований на программные и информационные модули, на группы программ и на программные комплексы;
программных модулей, запрограммированных и подготовленных к тестированию на уровне исходных текстов программ и на уровне объектных кодов реализующей ЭВМ;
автономных групп программных модулей и компонентов, решающих законченные функциональные задачи;
функциональных компонентов в составе программных средств.
Требования к характеристикам системы
Рис. 13.5
Задача тестирования спецификаций состоит в проверке полноты и взаимного соответствия функций, предписываемых программным и информационным компонентам требованиями разных иерархических уровней (см. п. 13.1). Кроме того, задачи тестирования включают проверку соответствия описаний информации на входах и выходах взаимодействующих программных модулей и групп программ, а также с описаниями информационных модулей в базе данных. В результате тестирования спецификаций должна быть обеспечена их корректность и согласованность в пределах обобщенного описания требований к функциям всего ПС и взаимодействия всех его составных частей. Тестирование взаимосвязей целесообразно проводить, начиная от спецификации требований комплекса или группы программ. Последовательно по иерархическим уровням должно прослеживаться обеспечение программ верхнего уровня реализованными функциями программ нижних уровней, предписанными программными спецификациями. Одновременно проверяется полнота выполнения этих функций спецификациями информационных модулей (см. рис. 13.2).
Процесс тестирования программных модулей состоит в проверке корректности обработки модулями поступающей информации и получающихся на выходе данных в соответствии с функциями, представленными в спецификациях требований. Должна быть проверена корректность структуры модулей и примененных конструктивных элементов: циклов, блоков, переключателей и т.д. Так как на этом этапе тестирования участвует наибольшее число специалистов, зачастую не очень высокой квалификации, особое значение приобретают методики тестирования и регламентирование применения средств автоматизации.
Проверке подлежат маршруты обработки информации в каждом модуле и правильность их реализации в зависимости от исходных данных. Полнота теста определяется критериями выделения маршрутов для тестирования и степенью покрытия тестами требований спецификаций и возможных маршрутов исполнения программы. На каждом выделенном маршруте должна проверяться корректность выполняемых вычислений при некоторых фиксированных исходных данных. При этом выявляются ошибки неполного состава или некорректности условий при реализации частных маршрутов обработки данных, а также некоторые ошибки преобразования переменных. Для каждого выделенного маршрута по тексту программы формируется набор условий, определяющих его реализацию и используемый при создании соответствующего теста. Такое представление маршрутов позволяет упорядоченно контролировать достигнутый уровень проверки маршрутов и в некоторой степени предохраняет от случайного пропуска отдельных нетестировавшихся маршрутов.
Автономное тестирование функциональных компонентов с исполнением программ предназначено для проверки корректности решения отдельных достаточно крупных функциональных задач. На этом этапе проверяется корректность управляющих и информационных связей между группами модулей, а также корректность реализации требований в процессе обработки информации в группе программ. При этом значительно возрастает сложность тестируемых объектов и соответственно — размеры и сложность тестов. Вследствие этого возрастают требования к автоматизации тестирования и затраты на его выполнение. Детерминированным тестированием должны проверяться структура группы программ и основные маршруты обработки информации. В ряде случаев результаты следует получать методами стохастического тестирования.
Интеграционное тестирование составляет объединение программного кода, соответствующего двум или большему количеству программных модулей, и тестирование полученного в результате кода. Это должно гарантировать, что вместе они работают, как требуется, до полной интеграции и тестирования кода каждого функционального компонента. Так как отдельные модули могут включать другие модули, некоторая часть интеграции и тестирования модулей может происходить в процессе модульного тестирования. Тестовые варианты должны покрывать все требования проекта уровня функциональных компонентов ПС. После этого следует выполнять все необходимые изменения ПС, связанные с коррекцией дефектов, выявленных в процессе верификации, а также повторное тестирование в необходимом объеме и модифицировать файлы разработки ПС и другие программные продукты, основываясь на результатах интеграционного тестирования.
Тестирование функциональных компонентов в составе программных средств в процессе разработки комплексов программ и оценки полноты тестирования осуществляются преимущественно по степени выполнения требуемых функций и по характеристикам достигаемой корректности и качества функционирования ПС в целом (см. рис. 13.2). Значительную помощь в повышении качества сложных, критических ПС может оказать систематизация видов тестирования и упорядоченное их проведение при разработке. Эти виды тестирования должны быть ориентированы на дифференцированное выявление определенных классов дефектов. Для каждого вида тестирования целесообразно разрабатывать методику его выполнения с указанием проверяемых компонентов, контролируемых параметров, ожидаемых и эталонных результатов. Кроме того, при заключительных испытаниях или сертификации должно проводиться интегральное тестирование при максимально широком варьировании тестов в условиях, соответствующих нормальной и форсированной эксплуатации.
Тестирование полноты решения функциональных задач при типовых исходных данных предназначено для обнаружения дефектов функционирования в нормальных, штатных условиях, определенных требованиями технического задания на базовую версию ПС. Первичным эталоном являются цели и задачи создания программного продукта. Некоторая часть тестов может содержать детерминированные исходные данные, для анализа которых часто применяются различные системы графического отображения. Особое внимание целесообразно обращать на варианты тестов, позволивших обнаружить ошибки. Для этих условий следует проводить дополнительное тестирование.
Тестирование функционирования программ в критических ситуациях по условиям и логике решения задач {стрессовое тестирование отказоустойчивости)проводится при исполнении программ в нештатных ситуациях, которые редко реализуются, но важны для обеспечения качества и надежности функционирования системы обработки информации. Для разработки таких тестов создаются сценарии критических сочетаний значений исходных данных и условий решения задач, при которых необходимо проверить функционирование программ и можно ожидать искажения результатов и отказы. Такие стрессовые, нештатные сочетания подготавливаются вручную или предусматривается их реализация в составе данных имитаторов стохастических тестов в реальном времени. Особая важность проверки в критических ситуациях определяется опасностью проявления таких ошибок при функционировании ПС в реальных условиях. Поэтому при тестировании активно применяются имитаторы внешней среды, автоматически подготавливающие исходные данные, и средства контроля, реагирующие на аномальные результаты исполнения тестируемых программ.
Основные этапы систематического тестирования и испытаний крупного комплекса программ реального времени и его компонентов представлены на рис. 13.6. При тестировании и испытаниях корректности функциональных компонентов комплексов программ выделены этапы:
— комплексирование модулей и тестирование автономных функциональных групп программ в статике без взаимодействия с другими компонентами и, возможно, без подключения к операционной системе реального времени;
тестирование функциональных групп программ в статике с учетом взаимодействия с некоторыми другими важнейшими компонентами и с базой данных;
тестирование отдельных программных компонентов в реальном времени во взаимодействии с другими функциональными компонентами и с основными компонентами операционной системы и базы данных.
Рис. 13.6
Сложность тестирования компонентов на этих этапах в значительной степени обусловлена несинхронным процессом их разработки и отладки отдельными специалистами в коллективах. Первично спланированная логика сопряжения между собой отдельных компонентов и подключения их к операционной системе не всегда выполняется из-за задержек в разработке и автономной отладке некоторых из них. Целесообразная последовательность тестирования определенных компонентов может нарушаться неготовностью к сопряжению с ними других взаимодействующих программ.
Для обеспечения имитации объектов внешней среды и других взаимодействующих групп программ на этих этапах используются преимущественно детерминированные контрольные задачи или частные генераторы соответствующих тестов. Эти генераторы тестов целесообразно разрабатывать и оформлять как отдельные модули или группы программ, функционирующие на той же технологической ЭВМ и в той же операционной среде, что и отлаживаемые компоненты. Совместно с ними также реализуются и функционируют частные специализированные программы для обработки и обобщения отдельных результатов тестирования соответствующих групп программ.
После комплексирования основных, функциональных компонентов начинаются их тестирование и испытания в составе ПС в целом. Для них наиболее характерны следующие этапы квалификационного тестирования и испытаний ПС в реальном времени (см. рис. 13.6):
по данным моделирующего стенда или генераторов тестов, имитирующих отдельные объекты внешней среды;
с имитаторами отдельных объектов внешней среды и с реальными воздействиями от операторов-пользователей;
в полностью адекватной реальной или имитированной внешней среде и с реальными воздействиями от операторов-пользователей (см. лекцию 14).
На всех этапах тестирования, кроме операций непосредственной проверки функционирования программ, можно выделить еще две важные группы работ. Первая группа — это работы по методическому обеспечению процессов тестирования и по созданию средств автоматизированной генерации тестов. Вторая группа работ должна обеспечивать возможность обработки результатов тестирования и корректной оценки достигнутых характеристик качества функционирования программ.
Средства генерации тестов и обработки результатов тестирования можно разделить на три вида (см. рис. 13.6). Одни и те же средства автоматизации тестирования в статике обычно обеспечивают отладку групп программ как автономно, так и во взаимодействии с другими компонентами. Средства, имитирующие внешнюю среду в реальном времени, чаще всего ориентированы на тестирование как функциональных компонентов, так и ПС в целом. Еще один вид генераторов тестов в той или иной степени использует реальные объекты внешней среды. Первоначально такими объектами являются имитирующие стенды с участием реального функционирования операторов-пользователей (см. лекцию 14). Затем источниками тестов могут быть комплексы реальной аппаратуры внешних объектов или их аппаратурные аналоги.
Рассмотренная схема ориентирована на тестирование и испытания комплекса программ, размещаемого на единой аппаратной платформе. При созданиираспределенных систем клиент-сервер возникают дополнительные, весьма сложные задачи тестирования. Программные средства, размещенные на аппаратных платформах клиентов и серверов, необходимо первоначально тестировать автономно по представленной выше полной программе, а затем дополнительно их взаимодействие. Это взаимодействие клиентской и серверной частей программного комплекса должно быть подготовлено автономным тестированием всей системы телекоммуникации и гарантированием ее качества. После этого следует повторить последние три этапа комплексного тестирования в реальном времени, представленные на рис. 13.6, но уже при полном взаимодействии обоих функциональных компонентов системы клиент-сервер.
Данная статья про этапы системного тестирования подтверждают значимость применения современных методик для изучения данных проблем. Надеюсь, что теперь ты понял что такое этапы системного тестирования, стратегии систематического тестирования и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.
Комментарии
Оставить комментарий
Качество и тестирование программного обеспечения. Quality Assurance.
Термины: Качество и тестирование программного обеспечения. Quality Assurance.