Назад в библиотеку

The Automatic Generation of Software Test Data Using Genetic Algorithms

Автоматизированная разработка тестовых наборов программного обеспечения с использованием генетических алгоритмов.

Автор:Harmen - Hinrich Sthamer

November 1995 University of Glamorgan



Основа различных автоматических методов тестирования

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

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

Существует два метода тестирования: черный ящик и белый ящик. Тестирование методом черного ящика. В функциональном тестировании, внутреннее строение и поведение программы остается неизвестным. Цель состоит в том, чтобы узнать зависимость выходной информации от подаваемых на вход сигналов в случае если программа работает не в соответствии со своей спецификацией. В этом подходе тестовые наборы для программного обеспечения строятся из её спецификаций, Beizer [1990], Инс [1987] и Фрэнкл и Вайс[1993].

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

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

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

Автоматизированный генератор тестовых наборов.

Всестороннее тестирование может проводиться только по автоматизации процесса тестирования, по утверждению Staknis [1990]. Преимущества - сокращение времени, сил, труда и стоимости тестирования программного обеспечения. Автоматизированные инструменты тестирования состоит в целом из инструментария тестирования и генератора тестовых данных. Инструменты статического анализа анализируют тестируемое ПО без выполнения кода, либо вручную, либо автоматически. Это ограниченный метод анализа для программ, содержащих ссылки на массив, указатель переменных и других динамических конструкций. Эксперименты показали, что такая оценка проверки кода (визуальный осмотр) является очень эффективной в поиске 30% до 70% от логического проектирования и кодирования ошибки в типичном программное обеспечение, DeMillo [1987]. Символическое выполнение и оценка типичных статических инструментов для генерации тестовых данных.

Множество автоматических генераторов тесов основаны на символическом запуске. Символическое исполнение обеспечивает функциональное представлениепути в программе и присваивает символические имена для входных значенийи оценивает путь, интерпретируя высказывания и предикаты на пути через эти символические имена. Символическое выполнение требует систематического вывода этих выражений, которые могут занимать много вычислительных усилий, , Fosdick and Osterweil [1976]. Значения всех переменных сохраняются в виде алгебраических выражений с точки зрения символических имен. Значение каждой переменной программы определяется в каждом узле графа потока как символическая формула (выражение), для которых остается неизвестным только значение входной переменной.Символическое выражение для переменной несет достаточно информации, чтобы, если числовые значения присваиваются входу, численное значение можно получить переменную, то это называется символическойоценки. Характеристики символического исполнения являются: Символические выражения создаются и показывают необходимые требования, чтобы выполнить определенный путь или филиала, Кларк [1976].В результате символического исполнения набор равенства и неравенстваограничений на входные переменные, эти ограничения могут быть линейными или нелинейными и определить подмножество входного пространства, что приведет к исполнению выбранного пути;

Некоторые ошибки в программе, легко определить по символическимвыходом программы, если программа должна вычислять математические формулы. В этом виде 2-4 событие, выход есть только для проверки в формуле, чтобы увидеть, что они совпадают. В отличие от статического анализа, динамической средства тестированиявключают выполнения тестируемого ПО и опираться на обратную связьпрограммного обеспечения (достигается контрольно-измерительных приборов) в целях получения тестовых данных. Меры предосторожности, чтобы гарантировать, что эти дополнительные инструкции имеют никакого влияния на логику оригинального программного обеспечения.Представитель этот метод описывается Gallagher и соавт. [1993], которые использовали приборы для получения информации для генерации тестовых данных системы о состоянии различных переменных, пути предикатов итестового покрытия.Штрафная функция оценивается с помощьюограничений значение отрасли предикат, насколько хороши данные текущеготеста в отношении филиала предикат. Есть три вида тестовых данныхгенераторов линейно, данные спецификации и случайные данные испытанийгенератора.

Тестовый набор проводится на тестируемого ПО, а выход сохраняется в качестве фактического выхода этого теста. Программа тестер должен рассмотреть выход и решает, является ли это правильным, сравниваяфактические показатели с ожидаемым выходом. Если вывод неверен,ошибка была обнаружена, программа должна быть изменена и испытанийдолжны начать все заново. Это приводит к регрессии тестированиявыполнения всех предыдущих тестовых данных, чтобы убедиться, чтопоправка, вносимая никаких новых ошибок. BCS SIGIST [1995], определенный регресс tesing как: Повторное предварительно протестированы следующие программымодификации, чтобы недостатки не были приняты или обнаружены в результате внесенных изменений. Для завершения тестирования, тестер вручную просмотреть и изучить вывод тестов на определить, являются ли они правильными.

Deason [1991] исследовали использование основанной на правилахтестирования методов с использованием целых и действительных переменных. Его система использует до испытания в качестве входных данных для генерации дополнительных испытаний. Генератор тестовых данных присваивает значения непосредственно входных переменных вусловиях постоянных и затем увеличивает и уменьшает их небольшого количества, чтобы приблизиться к границе.Ввод значений в два раза и два раза в результате гораздо быстрее движения через пространство поиска.Наконец один входной переменной в то время, установлено случайное число. В результате этого проекта является то, что основанная на правилах методвыполняется почти всегда лучше, чем случайные. Deason назвал свой метод многократного граничное условие покрытия, когда несколькоусловием покрытия означает, что данные испытаний осуществлять все возможные комбинации ОР2-5 условия (истинных и ложных) результатов в каждом решении. Граничная здесь означает, что тестовые данные должны быть как можно ближе к переключению условия от истинного к ложным. Он отметил, что это не возможно для генерации тестовых данных, котораявызывает выполнение всех филиалов в произвольной программы, то естьне существует алгоритма для решения общих нелинейных предикатов. Кроме того, его подход ограничен числовых типов, таких как целые типыданных.Правило подход всегда тот недостаток, что правила должны существовать для непредвиденных проблем, которые могут быть трудно реализовать. Если такой нормы не существует, генерации тестовых данныхможет закончиться в местном оптимальное решение, а не в глобальномрешение, которое будет проходить ветка.