Стратегии тестирования программных модулей кратко

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

При тестировании программных модулей используются 2 стратегии отладки:1. от структуры; 2. от данных.
При первой стратегии за основу принимается структура модуля, построенная по тексту программы в виде направленного графа. В графе выделяются и упорядочиваются маршруты исполнения программы и условия, при которых они могут быть реализованы. Эти условия используются для подготовки тестовых наборов, каждый из которых должен реализоваться по маршруту, принятому за эталон при подготовке теста. Отклонения использования теста от первоначально выбранного маршрута — ошибка. Она может быть локализована либо в первичной структуре ПМ, либо в реализации конкретного маршрута при данном тесте на входе. После устранения ошибок несоответствия используемых и выбранных маршрутов для каждого из них проверяется процесс обработки данных и выявляются ошибки в результате их преобразования. Завершается отладка при полном покрытии графа программы протестированными маршрутами или при полном использовании ресурсов, выделенных на отладку. Данная стратегия имеет преимущества при тестировании логических программ с малой долей вычислений.
При второй стратегии за основу принимаются конкретные тестовые значения, которые подготавливаются путем анализа переменных и предикатов в тексте программы. При каждом тесте программа исполняется по определенному маршруту, который регистрируется. По мере отладки отмечаются проверенные операторы и оценивается полнота покрытия тестами всех компонент в маршрутах тестирования. Накопление реализованных маршрутов позволяет воспроизвести полную структуру программы и контролировать степень проверки каждой компоненты. При такой стратегии трудно оценить степень проверки основных маршрутов использования программы, без использования структурного графа, построенного по исходному тесту. Данная стратегия имеет + при сравнительно простой структуре программы и преобладании в ней вычислительных операторов.
На каждом маршруте внимание акцентируется на вычислительной части программы. При этом существует риск пропустить сочетание предикатов, определяющих непроверенные маршруты, из этого следует, что почти в всегда целесообразно совместное применение двух стратегий.
Программы со сложной логической структурой и малой вычислительной частью сначала лучше тестировать по 1 стратегии, а для маршрутов с вычислительными операторами использовать анализ потоков данных.
Программы, имеющие простую структуру и содержащие большой объем вычислений, сначала используют 2 стратегию, а завершаются отладкой по 1 стратегии.
Восходящие и нисходящие тестирования
При восходящем тестировании сначала поверяются программные модули нижних иерархических модулей. К ним последовательно подключаются вызывающие их модули. В этих модулях отладка то же начинается с простейших конструкций и маршрутов обработки информации. При этом последовательно усложняются используемые методы отладки и типы выявленных ошибок.
Основные трудности при такой стратегии состоят в непрерывном обновлении и повышении числа тестовых наборов по мере подключения компонент более высокого уровня. При этом углубляется тестирование компонент нижних уровней, это приводит к повышению их качества.
При нисходящем тестировании отладка начинается с программ организации вычислительного процесса. Об этом говорит сайт https://intellect.icu . Сначала тестируется управляющее ядро комплекса программ и программ решения функциональных задач, размещенных на высших иерархических уровнях. К ним последовательно подключены компоненты более низких уровней. Эта стратегия эффективна, если имеется набор проверенных программных модулей. Преимуществом этой стратегии является сохранение и последовательное развитие тестовых исходных данных по мере подключения компонент.
Этапы и задачи тестирования программных компонент
Наиболее характерными являются задачи тестирования следующих объектов:
1. Формализованная спецификация требований на программные и информационные модули, на группы программ и программные комплексы.
2. Программные модули запрограммированы и подготовлены к отладке на уровне исходных текстов программ и на уровне объектных кодов программ.
3. Группы программных модулей (компоненты), решающие небольшие законченные функциональные задачи.
1. Основная цель тестирования спецификации состоит в проверке полноты и взаимного соответствия функций, предписываемых программным и информационным компонентам разных уровней. Кроме того, проверяется соответствие описаний информации на входных и выходных взаимодействиях программных модулей в БД. Такое тестирование целесообразно проводить по нисходящему методу, начиная со спецификации компонента или группы программ.
Тестирование согласованности интерфейсов спецификациях программных компонент применяют для обнаружения ошибок в описаниях переменных и передачах управления при взаимодействии модулей и групп программ. По структурной схеме комплекса программ устанавливается перечень последовательно вызываемых модулей и проверка корректности описаний вызовов в программных спецификациях. Для каждого входа переменной составляется ее наименование и описание спецификации данного модуля описаниям операций тех моделей где используется эта переменная.
2. Основная задача тестирования и отладки функций программных модулей состоит в проверке корректности обрабатываемой модулями поступающей информации и получается на выходных данных в соответствии с функциями представленными в спецификациях. Должна быть проверенна корректность структуры модулей и примененных конструктивных компонент. Проверке подлежат маршруты обработки информации в каждом модуле и правильность их реализации в зависимости от исходных данных. Полнота теста определяется степенью покрытия возможных маршрутов исполнения программы. Тестирование вычислений и преобразование данных программными модулями служит для обнаружения ошибок в вычислительной части программы. Эталонами служат результаты предварительных расчетов по файлам заложен в модули. Тестирование программных модулей целесообразно проводить на упорядоченных наборах данных с учетом степени их влияния на выходные результаты. С этой точки зрения можно выделить 2 вида обработки данных:
1. способность полностью изменять область определения результатов;
2. изменяющий результаты в пределах некоторой ограниченной области определения.
Первому виду обработки соответствуют исходные данные в критических точках и на границах областей изменения переменных. При таких критических значениях может изменятся маршрут исполнения программы, следовательно возможны наибольшие изменения результатов, следовательно тестирование обработки данных прежде всего должно быть направленно на проверку исполнения программ при значениях переменных, влияющих на выбор маршрута и логику функционирования программы.
Второму виду обработки соответствуют данные об ограниченной (неограниченной) области определения, которая может делиться на некоторые множества соприкасающихся областей. Изменение данных внутри такой области не влияет на маршрут исполнения программы. Для проверки функционирования программы достаточно использовать при тестировании только несколько значений внутри и вблизи границ области.
Тестирование полноты функций, выполняемых модулями, предназначено для выявления ошибок в разработке программы относительно функций, заданных программной спецификацией. Тестированию подлежит реализация всех функций, определенных спецификацией, и характеристики межмодульного интерфейса. При проверке корректности выполнения функций используются результаты, предшествующие тестированию структуры и вычислению в модулях. Для проверки неконтролируемой функции создаются специальные тесты. С целью охватить все возможные варианты исходных данных в т.ч. аномальные при различных искажениях.
3. Тестирование программных компонент предназначено для проверки корректности решения достаточно крупных автономных функциональных задач. На этом этапе проверяется корректность проверяющих и информационных связей между группами модулей, а также корректность вычисляемых функций в процессе обработки информации в группе программ.
Тестирование структуры группы программ используется для выявления ошибок соответствия реального структурного построения группы и ее спецификации. Проверяется правильность вызова программных модулей (ПМ) и возвратов управления при их взаимодействии в отлаживаемой группе. Технология тестирования структуры групп программ подобна технологии тестирования ПМ.
Тестирование межмодульного интерфейса в группе программ предназначено для обнаружения ошибок информационной связи между модулями в группе. Проверяются также связи через глобальные данные, подготавливаемые и используемые другими функциональными группами программ при взаимодействии с отлаживаемой группой. Каждая переменная (массив) должны проверяться на тождественность описаний в текстах программ взаимодействия модулей, а также на соответствие исходным программным спецификациям. Тестирование потоков данных производится преимущественно на уровне взаимодействия ПМ. Все реализованные информационные интерфейсы компонент в группе и с внешней средой д.б. сопоставлены со спецификациями.
Тестирование по выполнению ограничений по использованию памяти и допустимой длительности сип-ия группы программ предназначено для выявления ошибок использования реальных ресурсов компьютера разрабатываемой функциональной группой программ. Наиболее сложным является тестирование использования ресурсов производительности компьютера в реальном времени.
Тестирование полноты решения функциональной задачи группой программ служит для завершающего группы программ и обнаружения ошибок, оставшихся после предыдущих видов тестирования. Тестирование производится в соответствии со спецификацией требований на группу программ. Особое значение имеют тесты для проверки программ в особых точках значений исходных параметров и сочетаниях при критических условий в данных. Тестирование завершается регистрацией полученных результатов и оформляется протоколом тестирования.
Тестирование полноты и корректности документации предназначено для обнаружения ошибок соответствия реализации программы всей сопровождающей ее конструкторской и эксплутационной документации. Большая часть предшествующего тестирования программных компонент производится с использованием не полностью формализованной конструкторской и эксплутационной документации. Что позволяет частично проверить ее корректность. Данная группа тестов является завершающей и предназначена для регистрации качества официальной документации на программные компоненты. Наиболее полно в документации должны проверяться все контрольные примеры, сопровождающие инструкцию по эксплуатации, кроме того, осуществляться проверка соответствия документации стандартам и проектированием оформлением программы.

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