Тестирование информационных систем методов "белого ящика"

Размещено на http://www.allbest.ru/

2

Контрольная работа

Тестирование информационных систем методов «белого ящика»

Оглавление

Введение

Глава 1. Понятие тестирования информационных систем

Глава 2. Тестирование методом «белого ящика»

2.1 Методы тестирования на основе стратегии белого ящика

2.2 Особенности тестирования «белого ящика»

Список литературы

тест программа код белый ящик

Введение

Известно, что основной задачей первых трех десятилетий компьютерной эры являлось развитие аппаратных компьютерных средств. Это было обусловлено высокой стоимостью обработки и хранения данных. В 80-е годы успехи микроэлектроники привели к резкому увеличению производительности компьютера при значительном снижении стоимости.

Основной задачей 90-х годов XX и начала XXI века стало совершенствование качества компьютерных приложений, возможности которых целиком определяются программным обеспечением (ПО).

Современный персональный компьютер имеет производительность большой ЭВМ 80-х годов. Сняты практически все аппаратные ограничения на решение задач. Оставшиеся ограничения приходятся на долю ПО.

Чрезвычайно актуальными стали следующие проблемы:

· аппаратная сложность опережает наше умение строить ПО, использующие потенциальные возможности аппаратуры;

· наше умение строить программы отстает от требований к новым программам;

· нашим возможностям эксплуатировать существующие программы угрожает низкое качество их разработки.

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

· управление проектом в виде координации усилий проектной команды, направленных на достижение целей проекта оптимальным путем;

· постановка задачи в виде определения требований и последующих работ с ними;

· управление изменениями в проекте: изменение может касаться как непосредственно самих требований к системе, так и затрагивать организационную схему процесса, и могут порождаться либо самим Заказчиком (бизнес-аналитиком) либо являться следствием обнаруженных в ИС дефектов;

· разработка ПО, как непосредственное кодирование программной реализации функциональных требований и проектирование схем хранения и движения информации в ИС;

· тестирование ПО - процесс, решающий задачу верификации соответствия требований выдвинутых к ИС и их программной реализации;

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

Как видим, процесс разработки ИС состоит из нескольких взаимосвязанных модулей, которыми уже в свою очередь и оперируют авторы методологий и подходов, смещая приоритеты между направлениями или смешивая задачи нескольких направлений (предлагая, к примеру, осуществление задач тестирования в рамках деятельности по непосредственной разработке программной реализации и т.д.). Суть остается прежней - есть технологическая цепочка процессов разработки информационных систем, модули которого взаимозависимы и не могут функционировать в отрыве друг от друга.

Глава 1. Понятие тестирования информационных систем

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

С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными), с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам.

Программа - это аналог обычной формулы в математике.

Формула для функции f, полученной суперпозицией f1, f2, … fn - выражение, описывающее эту суперпозицию.

f=f1*f2*f3*…*fn

Если аналог f1, f2, … fn - операторы языка программирования, то их формула - программа.

Существует два метода обоснования истинности формул:

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

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

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

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

Отладка(debug, debugging) - процесс поиска, локализации и исправления ошибок в программе.

Термин «отладка» в отечественной литературе используется двояко: для обозначения активности по поиску ошибок (собственно тестирование), по нахождению причин их появления и исправлению, или активности по локализации и исправлению ошибок.

Тестирование - это процесс выполнения ПО системы или компонента в условиях анализа или записи получаемых результатов с целью проверки (оценки) некоторых свойств тестируемого объекта.

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

Тестирование - это контролируемое выполнение программы на конечном множестве тестовых данных и анализ результатов этого выполнения для поиска ошибок.

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

Шаги процесса задаются тестами.

Каждый тест определяет:

· Свой набор исходных данных и условий для запуска программы.

· Набор ожидаемых результатов работы программы.

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

Хорошим считают тестовый вариант с высокой вероятностью обнаружения еще не раскрытой ошибки. Успешным называют тест, который обнаруживает до сих пор не раскрытую ошибку.

Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.

Тестирование обеспечивает:

· Обнаружение ошибок.

· Демонстрацию соответствия функций программы ее назначению.

· Демонстрацию реализации требований к характеристикам программы.

· Отображение надежности как индикатора качества программы.

Тестирование не может показать отсутствие дефектов (оно может показывать только присутствие дефектов). Важно помнить это утверждение при проведении тестирования. Тестирование - важная часть любой программы контроля качества, а зачастую и единственная. Это печально, так как разнообразные методики совместной разработки позволяют находить больше ошибок, чем тестирование, и в то же время обходятся более чем вдвое дешевле в расчете на одну обнаруженную ошибку. Каждый из отдельных этапов тестирования (блочное тестирование, тестирование компонентов и интеграционное тестирование) обычно позволяют найти менее 50% ошибок. Комбинация этапов тестирования часто приводит к обнаружению менее 60% ошибок. Если у программиста спросить, какой из этапов разработки ПО менее всего похож на другие, он наверняка ответит: «Тестирование». По ряду описанных ниже причин большинство разработчиков испытывают при тестировании затруднения.

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

· Тестирование никогда не доказывает отсутствия ошибок. Отсутствие ошибок может указывать как на безупречность программы, так и на неэффективность или неполноту тестов.

· Тестирование не повышает качества ПО - оно указывает на качество программы, но не влияет на него.

Виды тестирования.

Тестирование - самая популярная методика повышения качества, подкрепленная многими исследованиями и богатым опытом разработки коммерческих приложений. Существует множество видов тестирования: одни обычно выполняют сами разработчики, а другие - специализированные группы. Виды тестирования перечислены ниже:

· Блочным тестированием называют тестирование полного класса, метода или небольшого приложения, написанного одним программистом или группой, выполняемое отдельно от прочих частей системы.

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

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

· Регрессивным тестированием называют повторное выполнение тестов, направленное на обнаружение дефектов в программе, уже прошедшей этот набор тестов.

· Тестирование системы - это выполнение ПО в его окончательной конфигурации, интегрированного с другими программными и аппаратными системами.

Фазы тестирования.

Реализация тестирования делится на три этапа:

1. Создание тестового набора (test suite) путем ручной разработки или автоматической генерации для конкретной среды тестирования (testing environment).

2. Прогон программы на тестах, управляемый тестовым монитором (test monitor, test driver) с получением протокола тестирования (test log).

3. Оценка результатов выполнения программы на наборе тестов с целью принятия решения о продолжении или остановке тестирования.

Глава 2. Тестирование методом «белого ящика»

Термин "белый ящик" означает, что при разработке тестовых случаев тестировщики используют любые доступные сведения о внутренней структуре или коде. Технологии, применяемые во время тестирования "белого ящика", обычно называют технологиями статического тестирования.

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

Тестовые процедуры, связанные с использованием стратегии белого ящика, используют управляющую логику процедур. Они предоставляют ряд услуг, в том числе:

· Дают гарантию того, что все независимые пути в модуле проверены по крайней мере один раз.

· Проверяют все логические решения на предмет того, истины они или ложны.

· Выполняют все циклы внутри операционных границ и с использованием граничных значений.

· Исследуют структуры внутренних данных с целью проверки их достоверности.

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

2.1 Методы тестирования на основе стратегии белого ящика

Ввод неверных значений. При вводе неверных значений тестировщик заставляет коды возврата показывать ошибки и смотрит на реакцию кода. Это хороший способ моделирования определенных событий, например переполнения диска, нехватки памяти и т.д. Популярным методом является замена alloc() функцией, которая возвращает значение NULL в 10% случаев с целью выяснения, сколько сбоев будет в результате. Такой подход еще называют тестированием ошибочных входных данных. При таком тестировании проверяется обработка как верных, так и неверных входных данных. Тестировщики могут выбрать значения, которые проверяют диапазон входных/выходных параметров, а также значения, выходящие за границу диапазона.

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

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

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

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

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

Исследование покрытия. При выборе инструмента для исследования покрытия важно, чтобы группа тестирования проанализировала тип покрытия, необходимый для приложения. Исследование покрытия можно провести с помощью различных технологий. Метод покрытия операторов часто называют С1, что также означает покрытие узлов. Эти измерения показывают, был ли проверен каждый исполняемый оператор. Данный метод тестирования обычно использует программу протоколирования (profiler) производительности.

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

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

2.2 Особенности тестирования «белого ящика»

Обычно тестирование «белого ящика» основано на анализе управляющей структуры программы. Программа считается полностью проверенной, если проведено исчерпывающее тестирование маршрутов (путей) ее графа управления.

В этом случае формируются тестовые варианты, в которых:

· Гарантируется проверка всех независимых маршрутов программы.

· Находятся ветви True, False для всех логических решений.

· Выполняются все циклы (в пределах их границ и диапазонов).

· Анализируется правильность внутренних структур данных.

Недостатки тестирования «белого ящика»:

· Количество независимых маршрутов может быть очень велико. Например, если цикл в программе выполняется k раз, а внутри цикла имеется n ветвлений, то количество маршрутов вычисляется по формуле

.

При n=5 и k=20 количество маршрутов m=10¹⁴. Примем, что на разработку, выполнение и оценку теста по одному маршруту расходуется 1 мс. Тогда при работе 24 часа в сутки 365 дней в году на тестирование уйдет 3170 лет.

· Исчерпывающее тестирование маршрутов не гарантирует соответствия программы исходным требованиям к ней.

· В программе могут быть пропущены некоторые маршруты.

· Нельзя обнаружить ошибки, появление которых зависит от обрабатываемых данных.

Достоинства тестирования «белого ящика» связаны с тем, что принцип «белого ящика» позволяет учесть особенности программных ошибок:

· Количество ошибок минимально в «центре» и максимально на «периферии» программы.

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

· При записи алгоритма программного обеспечения в виде текста на языке программирования возможно внесение типовых ошибок трансляции (синтаксических и семантических).

· Некоторые результаты в программе зависят не от исходных данных, а от внутренних состояний программы.

Каждая из этих причин является аргументом для проведения тестирования по принципу «белого ящика». Тесты, например, «черного ящика» не смогут реагировать на ошибки таких типов.

Способ тестирования базового пути.

Тестирование базового пути - это способ, который основан на принципе «белого ящика». Автор этого способа - Том МакКейб (1976).

Способ тестирования базового пути дает возможность:

· Получить оценку комплексной сложности программы.

· Использовать эту оценку для определения необходимого количества тестовых вариантов.

Тестовые варианты разрабатываются для проверки базового множества путей (маршрутов) в программе. Они гарантируют однократное выполнение каждого оператора программы при тестировании.

Потоковый граф.

Для представления программы используется потоковый граф. Перечислим его особенности.

· Граф строится отображением управляющей структуры программы. В ходе отображения закрывающие скобки условных операторов и операторов циклов рассматриваются как отдельные (фиктивные) операторы.

· Узлы (вершины) потокового графа соответствуют линейным участкам программы, включают один или несколько операторов программы.

· Дуги потокового графа отображают поток управления в программе (передачи управления между операторами). Дуга - это ориентированное ребро.

· Различают операторные и предикатные узла. Из операторного узла выходит одна дуга, а из предикатного - две дуги.

· Предикатные узлы соответствуют простым условиям в программе. Составное условие программы отображается в несколько предикатных узлов. Составным называют условие, в котором используется одна или несколько булевых операций.

· Замкнутые области, образованные дугами и узлами, называют регионами.

· Окружающая граф среда рассматривается как дополнительный регион.

Цикломатическая сложность.

Цикломатическая сложность - метрика программного обеспечения, которая обеспечивает количественную оценку логической сложности программы. В способе тестирования базового пути цикломатическая сложность определяет:

· Количество независимых путей в базовом множестве программы.

· Верхнюю оценку количества тестов, которое гарантирует однократное выполнение всех операторов.

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

Все независимые пути графа образуют базовое множество.

Свойства базового множества:

· Тесты, обеспечивающие его проверку гарантируют:

1. однократное выполнение каждого оператора;

2. выполнение каждого условия по True-ветви и по False-ветви.

· Мощность базового множества равна цикломатической сложности потокового графа.

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

Цикломатическая сложность вычисляется одним из трех способов:

· Цикломатическая сложность равна количеству регионов потокового графа.

· Цикломатическая сложность определяется по формуле
V(G)=E - N + 2, где E - количество дуг, N - количество узлов потокового графа.

· Цикломатическая сложность формируется по выражению V(G)=p+1, где p - количество предикатных узлов в потоковом графе G.

Шаги способа тестирования базового пути.

· На основе текста программы формируется потоковый граф:

1. нумеруются операторы текста.

2. производится отображение пронумерованного текста программы в узлы и вершины потокового графа.

· Определяется цикломатическая сложность потокового графа - по каждой из трех формул.

· Определяется базовое множество независимых линейных путей.

· Подготавливаются тестовые варианты, инициирующие выполнение каждого пути.

Каждый тестовый вариант формируется в следующем виде:

Исходные данные (ИД):

Ожидаемые результаты (ОЖ.РЕЗ.):

Исходные данные должны выбираться так, чтобы предикатные вершины обеспечивали нужные переключения - запуск только тех операторов, которые перечислены в конкретном пути, причем в требуемом порядке.

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

Важно отметить, что некоторые независимые пути не могут проверяться изолированно. Такие пути должны проверяться при тестировании другого пути (как часть другого тестового варианта).

Способы тестирования условий.

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

Рассмотрим используемую здесь терминологию.

Простое условие - булева переменная или выражение отношения.

Выражение отношения имеет вид

E1<оператор отношения>E2,

Где E1, E2 - арифметические выражения, а в качестве оператора отношения используется один из следующих операторов:

Составное условие состоит из нескольких простых условий, булевых операторов и круглых скобок. Будем применять булевы операторы OR, AND (&), NOT. Условия, не содержащие выражений отношения, называют булевыми выражениями.

Таким образом, элементами условия являются: булев оператор, булева переменная, пара скобок (заключающая простое или составное условие), оператор отношения, арифметическое выражение. Эти элементы определяют типы ошибок в условиях.

Если условие некорректно, то некорректен по меньшей мере один из элементов условия. Следовательно, в условии возможны следующие типы ошибок:

· Ошибка булева оператора (наличие некорректных/ отсутствующих/ избыточных булевых операторов).

· Ошибка булевой переменной.

· Ошибка оператора отношения.

· Ошибка арифметического выражения.

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

Целью тестирования условий является определение не только ошибок в условиях, но и других ошибок в программах. Если набор тестов для программы A эффективен для обнаружения ошибок в условиях, содержащихся в A, то вероятно, что это набор также эффективен для обнаружения других ошибок в A. Кроме того, если методика тестирования эффективна для обнаружения ошибок в условиях, то вероятно, что эта методика будет эффективна для обнаружения ошибок в программе.

Существует несколько методик тестирования условий.

Простейшая методика - тестирование ветвей. Здесь для составного условия С проверяется:

· каждое простое условие;

· True-ветвь;

· False-ветвь.

Другая методика - тестирование области определения в ней для выражения отношения требуется генерация 3-4 тестов. Выражение вида

Е1<оператор отношения>Е2

проверяется тремя тестами, которые формируют значение Е1 большим, чем Е2, равным Е2 и меньшим, чем Е2.

Если оператор отношения неправилен, а Е1 и Е2 корректны, то эти три теста гарантируют обнаружение ошибки оператора отношения.

Для определения ошибок в Е1 и Е2 тест должен сформировать значение Е1 большим или меньшим, чем Е2, причем обеспечить как можно меньшую разницу между этими значениями.

Способ тестирования потоков данных.

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

Работу любой программы можно рассматривать как обработку потока данных, передаваемых от входа в программу к ее выходу.

Пусть имеется потоковый граф программы с управляющими и информационными связями.

Под определением данных понимают действия, изменяющие элемент данных.

Использование данных - это применение элемента в выражении, где происходит обращение к элементу данных, но не изменение элемента.

Назовем DU-цепочкой (цепочкой определения-использования) конструкцию [x, i, j], где i, j - имена вершин; x определена в i-й вершине и используется в j-й вершине.

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

Шаги способа DU-тестирования:

· построение управляющего графа программы;

· построение информационного графа;

· формирование полного набора DU-цепочек;

· формирование полного набора отрезков путей в управляющем графе;

· построение маршрутов - полных путей на управляющем графе, покрывающих набор отрезков путей управляющего графа;

· подготовка тестовых вариантов.

Достоинства DU-тестирования:

· простота необходимого анализа операционно-управляющей структуры программы;

· простота автоматизации.

Недостаток DU-тестирования: трудности в выборе минимального количества максимально эффективных тестов.

Область использования DU-тестирования: программы со вложенными условными операторами и операторами цикла.

Тестирование циклов.

Цикл - наиболее распространенная конструкция алгоритмов, используемых в ПО. Тестирование циклов производится по принципу «белого ящика», при проверке циклов основное внимание обращается на правильность конструкций циклов.

Различают 4 типа циклов: простые, вложенные, объединенные, неструктурированные.

Простые циклы.

Для проверки циклов с количеством повторений n может использоваться один из следующих наборов тестов:

· прогон всего цикла;

· только один проход цикла;

· два прохода цикла;

· m проходов циклов, где m<n;

· n-1, n, n+1 проходов цикла.

Вложенные циклы.

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

Шаги тестирования:

· Выбирается самый внутренний цикл. Устанавливаются минимальные значения параметров всех остальных циклов.

· Для внутреннего цикла проводятся тесты простого цикла. Добавляются тесты для исключенных значений и значений, выходящих за пределы рабочего диапазона.

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

· Работа продолжается до тех пор, пока не будут протестированы все циклы.

Объединенные циклы.

Если каждый из циклов независим от других, то используется техника тестирования простых циклов. При наличии зависимости (например, конечное значение счетчика первого цикла используется как начальное значение счетчика второго цикла) используется методика вложенных циклов.

Неструктурированные циклы.

Неструктурированные циклы тестированию не подлежат. Этот тип циклов должен быть переделан с помощью структурированных программных конструкций.

Список литературы

1.Майерс Г. Искусство тестирования программ. М.: Финансы и статистика, 1982, 176 с.

2.Технологии разработки программного обеспечения: Учебник для вузов. 3-е изд./ С.А. Орлов. - СПб.: Питер, 2004. - 527 с.

3.Макгрегор Дж., Сайкс Д. Тестирование объектно-ориентированного программного обеспечения. К.: Диасофт, 2002. - 432 с.

4.Липаев В.В. Тестирование программ. М.: Радио и связь, 1986. - 296 с.

5.Борзов Ю.В., Уртанг Г.Б., Шимаров В.А. Выбор путей программы для построения тестов. УСиМ. - 1989. - N.6 - с.29-36

6.Карлбертсон Р., Браун К., Кобб Г. Быстрое тестирование. Изд. Вильямс 2002, 216 с.

7. Дастин Э., Рэшка Дж., Пол Дж. Автоматизированное тестирование программного обеспечения. Изд. Лори 2003, 310 с.

Размещено на Allbest.ru

...