Автоматизация тестирования программного обеспечения

метки: Тестирование, Автоматизированный, Средство, Ошибка, Программа, Маршрут, Условие, Вершина

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

В области тестирования ПС исторически сложились непростые отноше-ния между тестировщиками и разработчиками ПС.

По образному выражению И. Винченко «…профессия тестировщика программного обеспечения, как и ее сестра — профессия инженера по качеству, а также „выросшая“ из них профессия инженера по автоматизации про-цессов тестирования, очень молода и зачастую овеяна мифами и подвержена влиянию предрассудков. Эта профессия, появившаяся в Соединенных Шта-тах Америки более 15 лет назад, даже там не пользуется большим уважением у программистов — „белой кости“ IТ-мира…».

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

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

Польку большинство дефектов выявляется вс.-таки на стадии тестирова-ния продукта, определяющим для экономии средств является автоматизация этой стадии внедрения. Компания Mercury провела опрос 1000 заказчиков и выяснила, что приблизительно 80% из них не используют средств автомати-зации при тестировании, предпочитая проводить его вручную. Из оставшейся доли абсолютное большинство — 80% компаний — применяют лишь простей-шие средства автоматизации тестирования при выполнении отдельных про-ектов. У 14% фирм развернуты специальные продукты тестирования и созда-на стандартная инфраструктура для этого. Ещ. 5% компаний внедрили сер-висы тестирования и образовали центры компетенции, агрегирующие луч-шие практики и осуществляющие обмен опытом между командами и проек-тами. И лишь у 1% заказчиков реализована система тотального контроля ка-чества и запущены централизованные сервисы тестирования, использующие единый жизненный цикл для всех проектов.

11 стр., 5462 слов

Разработка автоматизированной системы тестирования знаний ‘Русский ...

... синонимы [1]. Целью дипломной работы является разработка автоматизированной системы тестирования знаний по дисциплине «Русский язык». Для достижения цели дипломной работы необходимо решить следующие ... автоматизация тестирования не является стадией процесса тестирования, не следует за или перед каким-то этапом, а является процессом, пронизывающим большинство стадий процесса тестирования. Рассмотрим ...

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

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

2. Постановка задачи

Для заданного программного продукта (граф-программа решения квадратного уравнения, изображенная на рисунке 1) произвести комплексное фуцнкциональное и структурное тестирование.

Рисунок 1 — Алгоритм решения кубического уравнения

2.1 Описание объекта тестирования

Рассмотрим основные особенности графа:

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

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

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

Дуга — это ориентированное ребро.

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

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

3 . Функциональное тестирование

3.1 Выбор метода тестирования

Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс, позволяющий проверить на корректность отдельные модули исходного кода программы.

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

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

Unit (Элемент) — наименьший компонент, который можно скомпилировать.

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

Заглушки — заменяют недостающие компоненты, которые вызываются элементом и выполняют следующие действия:

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

White-box testing (тестирование методом «белого ящика») — для конструирования тестов используются внутренняя структура кода и управляющая логика. При этом существует вероятность, что код будет проверяться так, как он был написан, а это не гарантирует корректность логики.

Black-box testing (тестирование методом «черного ящика») — для конструирования тестов используются требования и спецификации ПО.

3.2 Классификация ошибочных ситуаций

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

Таблица 1 — Описание ошибочных ситуаций

№	Название	Описание	Методы	Примеры
	Ошибки способа обработки аргументов	Целевая операция имеет несколько вариантов работы, выбор которых зависит от значений аргументов. Ошибка состоит в отсутствии одного из вариантов работы или в выборе ошибочного для некоторых значений аргументов.	— domain testing; partition testing; тестирование граничных значений.	a. Операция вычисления абсолютной величины, работает по-разному для аргумента x >= 0 и для x < 0. Ошибка может состоять в том, что случай x < 0 совсем забыли написать. b. Операция вычисления произведения элементов массива. Ошибка может состоять в том, что пустые массивы обрабатываются неправильно — обычно произведение пустого множества чисел считают равным 1.
	Ошибки потока управления	Ошибка состоит в неправильном переходе или в неправильном условии перехода по потоку управления.	— flow graph testing; path testing.	a. Неправильный переход. b. Неверное условие. Вычисление суммы элементов массива. Ошибка в условии цикла может привести к неучету первого или последнего элементов.
	Ошибки потока управления между подсистемами	Похожи на ошибки потока управления, но ориентировано на системное, а не компонентное тестирование. Виды ошибок: неправильные переходы между компонентами программы; забыли реализовать некоторую операцию; забыли вставить использование некоторого компонента.	— transaction flow testing; use case based testing.	Набор текста вместо числа в некотором поле может приводит к падению программы.
	Ошибки потока данных	Неправильные зависимости между данными программы, пропущенные связи.	Data flow testing.	— Чтение «чужих» данных — Чтение несогласованных данных.
	Ошибки обработки формальных текстов	Ошибки состоят в нераспознавании или неправильной обработке некорректных текстов, отнесении правильных тестов к некорректным, неправильной обработке корректных текстов.	Syntax testing.	— компиляторы; интерпретаторы; обработчики запросов.
	Ошибки поведения, зависящего от состояния	Предполагается, что поведение программы существенно зависит ранее сделанных обращений к ней. Ошибки: переходы в неправильные состояния, неправильная работа в некотором состоянии.		Нажатие на кнопку «Возврат денег» в автомате для продажи газет может привести к выдаче денег, даже если человек до этого их не платил.

3.3 План модульного тестирования

Базой для модульного тестирования служат отдельные модули исходного кода программы. Пошаговый план модульного тестирования представлен в таблице 2.

Таблица 2 — План модульного тестирования

№	Название функционального модуля	Изображение на графе	Область значений	Используемые данные	Частота использования
	y1=al1+be1;		double	al1,be1
	y1=al1+be2;		double	al1,be2
	y1=al1+be3;		double	al1,be3
	y2=al2+be2;		double	al2,be2
	y2=al2+be3;		double	al2,be3
	y2=al2+be1;		double	al2,be1
	y2=al2+be3;		double	al2,be3
	y2=al2+be1;		double	al2,be1
	y2=al2+be2;		double	al2,be2
	Вычислительный модуль		double	y1,y2,y3
	y3=al3+be2;		double	al3,be2
	y3=al3+be3;		double	al3,be3
	y3=al3+be1;		double	al3,be1

3.4 Тестирование

Рассмотрим подробно тестирование вычислительного модуля dZ алгоритма решения кубического уравнения. Предположительно в данном модуле находится «редкая» ошибка. Задачей тестировщика является обнаружение этой ошибки.

3. 4.1 Локализация ошибочной области

Пр оцесс тестрования модуля начинается с локализации области, содержащей ошибку. Для этого проверим стандартную установку параметров тестирования, описанных выше: разрядность ЭВМ t=15, r=0; тестируемые параметры принадлежат диапазонам Х, Y.

Запустим процесс тестирования. Результат — пустой экран (Рисунок 2).

Рисунок 2 — Результат при t=15, r=0

Изменим параметры разрядной сетки — t=5, r=1. В результате появились ошибочные точки в исходных данных (Рисунок 3), часть из которых являются истинными ошибками, частично они могут быть «наведенными» мнимыми ошибками, связанными с ограничениями разрядной сетки.

Рисунок 3 — Результат при t=5, r=1

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

Переопределяем параметры окна, например, для нашего случая: Х[900;1100], Y[0;200] и запустим расчет.

#define LbX 900 //ЛЕВАЯ ГРАНИЦА X

#define RbX 1100 //ПРАВАЯ ГРАНИЦА X

#define LbY 0 //ЛЕВАЯ ГРАНИЦА Y

#define RbY 200 //ПРАВАЯ ГРАНИЦА Y

В результате получится картина, представленная на рисунке 4Рисунок 4.

Рисунок 4 — Результат при Х[900;1100], Y[0;200]

Полученную фигуру отцентрируем, для этого сместим окно по координате TF на 20 градусов.

#define LbX 920 //ЛЕВАЯ ГРАНИЦА X

#define RbX 1120 //ПРАВАЯ ГРАНИЦА X

#define LbY 0 //ЛЕВАЯ ГРАНИЦА Y

#define RbY 200 //ПРАВАЯ ГРАНИЦА Y

Получим фазовый портрет, представленный на рисунке Рисунок 5.

Рисунок 5 — Результат при LbX=920, RbX=1120, LbY=0, RbY=200

Теперь увеличим разрядную сетку ЭВМ: t=6, r=0, проведем испытания. Результаты представлены на рисунке 6.

Рисунок 6 — Результат при t=6, r=0

Теперь наведем окно поиска на перспективное скопление точек, представленных на рисунке 7Рисунок 7.

Рисунок 7 — Скопление точек

Эта процедура продолжается, пока параметр разрядности t не станет равен 15.

Результат:

• t =15, r=0;
• #define LbX 1021.954 445 715 //ЛЕВАЯ ГРАНИЦА X

#define RbX 1021.95 444 574 //ПРАВАЯ ГРАНИЦА X

#define LbY 0 //ЛЕВАЯ ГРАНИЦА Y

#define RbY 0.001 //ПРАВАЯ ГРАНИЦА Y

Примечание. Для больших t, т. е. , когда вектор ошибочных данных практически обнаружен, полезно распечатать координаты этой точки (Рисунок 8).

Рисунок 8 — Вывод точек

3. 4.2 Отладка программы

В ходе отладки вычислений в точке с координатами х=1021.95 444 572,у=0.0005 была обнаружена ошибка деления на ноль ( Рисунок 9).

Рисунок 9 — Исходный код программы. Подсвечена ошибка деления на ноль

3. 4.3 Заключение о типе и причине ошибки. Предложение по её исправлению.

В ходе выполнения лабораторной работы была выявлена ошибка деления на ноль, возникающая при значениях координаты X, близких к 1021.95 444 572.

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

3.5 Результаты модульного тестирования

тестирование программный граф

Результаты тестирования по каждому из модулей сведем в таблицу:

Таблица 3 — Результаты модульного тестирования

№	Название функционального модуля	Изображение на графе	Область значений	Используемые данные	Частота использования	Итог
	y1=al1+be1;		double	al1,be1
	y1=al1+be2;		double	al1,be2
	y1=al1+be3;		double	al1,be3
	y2=al2+be2;		double	al2,be2
	y2=al2+be3;		double	al2,be3
	y2=al2+be1;		double	al2,be1
	y2=al2+be3;		double	al2,be3		;
	y2=al2+be1;		double	al2,be1
	y2=al2+be2;		double	al2,be2
	Вычислительный модуль		double	y1,y2,y3		;
	y3=al3+be2;		double	al3,be2
	y3=al3+be3;		double	al3,be3
	y3=al3+be1;		double	al3,be1

4 . Структурное тестирование в вершинах ветвления

4.1 Описание метода структурного тестирования

Структурный подход в тестировании основан на анализе логики программы (стратегия «белого ящика»).

Существо подхода — в проверке каждого пути, каждой ветви алгоритма.

Методы структурного тестирования:

1 Метод покрытия операторов.

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

2 Метод покрытия решений (покрытия переходов).

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

3 Метод покрытия условий.

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

4 Критерий решений (условий).

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

5 Метод комбинаторного покрытия условий.

Критерием, который решает эти и некоторые другие проблемы, является комбинаторное покрытие условий. Он требует создания такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении выполнялись, по крайней мере, один раз. Набор тестов, удовлетворяющих критерию комбинаторного покрытия условий, удовлетворяет также и критериям покрытия решений, покрытия условий и покрытия решений/условий [«https:// «, 25].

4.2 Постановка задачи структурного тестирования

Структурное тестирование программы предполагает знание исходного текста программы, либо спецификации программы в виде потокового графа управления.

Рассмотрим основные особенности потокового графа:

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

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

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

Дуга — это ориентированное ребро.

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

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

При структурном тестировании программы используются так называемые структурные критерии, которые базируются на основных элементах графа управления программы: операторах, ветвях и путях.

Рассматривают 3 группы критериев:

• Тестирующие команды.
• Тестирующие ветви.
• Тестирующие пути.

Пусть вершина управляющего графа (уграфа) имеет три исходящих дуги, помеченных предикатами P1(X), P2(X), P3(X), как на рисунке 10.

Рисунок 10 -Граф управления Таблица 4 -План структурного тестирования

№	Название функционального модуля	Изображение на графе	Частота использования	Тупик	Естественное развитие	Конкуренция
	y1=al1+be1;
	y1=al1+be2;
	y1=al1+be3;
	y2=al2+be2;
	y2=al2+be3;
	y2=al2+be1;
	y2=al2+be3;
	y2=al2+be1;
	y2=al2+be2;
	Вычислительный модуль
	y3=al3+be2;
	y3=al3+be3;
	y3=al3+be1;

4.3 Тестирование

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

Существует два пути возникновения ошибок:

• Неверно составлены предикаты.
• Неверно организовано управление (неправильный граф программы).

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

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

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

Естественное развитие — запланированный режим работы вершины ветвления. В данном случае производится проверка на существование данных при которых управление переда? тся по одному из перечисленных направлений. В данном случае это

Формальная модель анализа уграфа программы основывается на исчислении предикатов первого порядка с сигнатурой, включающей отношения порядка. Это означает, что при построении предикатов используются алгебраические выражения, содержащие отношения порядка (<, >, =, ><, <=, >=).

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

Алгоритм метода структурного тестирования управляющих графов программы:

1. Записать исходное логическое выражение (проверяемый предикат).

2. Представить исходный предикат посредством базовых предикатов.

3. Заменить логические операции на теоретико-множественные.

4. Ввести индикаторные функции.

5. Записать решающую функцию для заданного в пункте 3 множества.

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

7. Если минимум функции меньше единицы, то логическое выражение выполняется хотя бы на одном наборе данных.

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

Необходимо проверить ситуацию естественного развития для первого направления Ситуация естественного развития для первого направления описывается следующим логическим условием:

Предположим, существует такой Х, что вышеприведенная формула истинна, тогда истинны в отдельности предикаты и, т. е. :

Тогда условие естественного развития для первого направления будет иметь следующий вид:

Пусть:

Тогда, используя теоретико-множественные операции, можно представить данное условие в виде:

Построим решающую функцию для выражений, , введя индикаторные функции:

Рассчитаем данную модель в пакете Matlab. На рисунке 11 представлено изображение решающей функции в виде изолиний.

Рисунок 11 — Изолинии решающей функции

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

4.4 Результаты структурного тестирования

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

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

Таблица 5 -Результаты структурного тестирования

№	Название функционального модуля	Изображение на графе	Частота использования	Тупик	Естественное развитие	Конкуренция
	y1=al1+be1;			;		;
	y1=al1+be2;			;		;
	y1=al1+be3;			;		;
	y2=al2+be2;			;		;
	y2=al2+be3;			;		;
	y2=al2+be1;			;		;
	y2=al2+be3;			;
	y2=al2+be1;			;		;
	y2=al2+be2;			;
	Вычислительный модуль			;		;
	y3=al3+be2;			;		;
	y3=al3+be3;			;		;
	y3=al3+be1;			;		;

5 . Структурное тестирование маршрутов

5.1 Описание метода структурного тестирования маршрутов

Для построения множества маршрутов в технологии ГСП применяется алгоритм частичного перебора маршрутов (АЧП).

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

Алгоритм частичного перебора схем маршрутов Введем понятие свободных вершин графа. Свободными вершинами графа G относительно схемы маршрута S будем называть вершины графа, не содержащиеся в схеме маршрута S, т. е. L (S) = V (G)V (S), где V (G) и V (S) — соответственно вершины графа и схемы маршрута.

Алгоритм частичного перебора использует следующие правила:

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

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

3. Если переход возможен, то схема маршрута Ї «расширяется» на один символ.

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

5. Если переход из текущей вершины в любую из свободных вершин (не содержащихся в схеме маршрута) невозможен, то происходит Ї «откат» по схеме маршрута на один символ назад.

6. При достижении концевой вершины алгоритм Ї «откатывает» на один символ назад.

7. Алгоритм завершает свою работу, если список свободных вершин корневой вершины исчерпан.

5.2 Постановка задачи структурного тестирования маршрутов

Схемы маршрутов для данного агрегата При использовании алгоритма ча

№	Схема маршрута	Частота использования	Итог
	0,2,3,4,6,9,17
	0,2,3,4,6,10,16
	0,2,3,4,7,11,17
	0,2,3,4,7,12,15
	0,2,3,4,8,13,16
	0,2,3,4,8,14,15
	0,2,3,5
	0,2,3,18,19

5.3 Тестирование

Рассмотрим процесс тестирования маршрутов на примере маршрута 0,2,3,4,6,9,17.

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

= (1)

В дальнейшем исследование выражения (1) с технической точки зрения ничем не отличается от использования «решающей» функции для тестирования вершин ветвления уграфа. Для (1) строится «решающая» функция F (X).

Задача проверки маршрута M сводится к оптимизационной задаче Xmin = arg minX F (X).

Если F (Xmin), то существуют такие сочетания данных предметной области, на которых реализуется тестируемый маршрут. Иначе маршрут не реализуем, и следует организовать поиск ошибки в тестируемой программе.

Следующий шаг — построение решающей функции.

Успешное прохождение по вышеприведенному маршруту выражается следующим предикатом:

Представим выражение через базовые предикаты:

(2)

(3)

Построим поэтапно решающую функцию для выражения (3):

1)

2)

3)

4)

5)

6)

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

X	F (X)
a	b	c	d
— 1.7440	— 1.2098	0.1675	0.1690	1.0003
— 1.0838	0.3154	— 0.0306	0.0010	0.9661
0.9268	— 0.0849	— 0.3386	0.0901	1.0008
— 1.0757	1.5126	— 0.7090	0.1108
4.6379	— 0.9696	0.0675	— 0.0016	0.8551
0.1585	1.1079	1.5652	— 1.3552	5.2372

При нескольких экспериментах с различными начальными условиями получилось несколько точек, минимум функций в которых примерно равен единице, например:

a	b	c	d
— 1.7440	— 1.2098	0.1675	0.1690
— 1.0838	0.3154	— 0.0306	0.0010
0.9268	— 0.0849	— 0.3386	0.0901
— 1.0757	1.5126	— 0.7090	0.1108

В результате оптимизации решающей функции было найдено решение X* = (-1.0757, 1.5126, -0.7090, 0.1108), причем F (X*) = 1, что подтверждает работоспособность алгоритма. На рисунках 2 и 3 в окрестностях найденной точки построены графики решающей функции.

Рисунок 11 — График «решающей функции» F (X)

Рисунок 12 — Изолинии «решающей функции» F (X)

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

5.4 Результаты структурного тестирования маршрутов

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

Таблица 7 — Результаты структурного тестирования маршрутов

№	Схема маршрута	Частота использования	Итог
	0,2,3,4,6,9,17
	0,2,3,4,6,10,16
	0,2,3,4,7,11,17
	0,2,3,4,7,12,15
	0,2,3,4,8,13,16		;
	0,2,3,4,8,14,15
	0,2,3,5
	0,2,3,18,19

6. Выводы

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

В ходе выполнения первого этапа — модульного тестирования — в модуле dZ была выявлена ошибка деления на ноль, возникающая при значениях координаты X, близких к 1021.95 444 572. Данная ошибка относится к классу ошибок способа обработки аргументов. Возможной причиной ошибки является недостаточная проработка алгоритма, в частности, упущена обработка исключительного случая.

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

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