К дипломному проекту icon

К дипломному проекту



страницы: 1   2   3   4   5   6   7
вернуться в начало
скачать
^

7.2Критерии полноты на основе структуры входных данных


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

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

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

  • Разделение значений по определенным правилам, касающимся их структуры. Например, целые числа обычно представляются в двоично-дополнительном формате, все отрицательные имеют первый (последний) бит, равный 1, в отличие от неотрицательных. Поэтому разбиение на положительные и отрицательные можно обосновать структурой представления числа в машине. Можно делить целые числа на большие и небольшие по абсолютной величине в соответствии с тем, есть ли хотя бы один бит равный 1 среди первых 16. То есть, числа >= 65536 по абсолютной величине объявляются большими, а меньшие — небольшими.

Для определения классов эквивалентных сложных данных обычно используют их структуру и классы эквивалентности данных простых типов, из которых они построены. Так, определяя разбиения на классы для объектов, у которых два целочисленных поля, достаточно естественно объявить эквивалентными объекты, у которых соответствующие поля имеют один знак или одновременно равны 0 — получается всего 9 классов таких объектов.

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

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

^ Метрика покрытия правил — доля правил грамматики, использованных для построения тестовых данных, среди всех ее правил.

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

Пример. Пусть входной документ программы соответствует следующей грамматике.

Doc ::= A | B ;

A ::= ( “X” | “Y” | “Z” ) (“::”)? “!”

B ::= “O” (A)*

В этом случае один входной документ вида “OX!” покрывает все правила — для его построения используется и корневое правило, и правило для B, и правило для A.

Чтобы покрыть все альтернативы в правиле A, достаточно использовать такие входные данные: “X::!”, “Y!”, “Z!”. Здесь первая альтернатива раскрыта всеми возможными способами. Вторая альтернатива — наличие или присутствие “::” — тоже. Для правила B достаточно “O” и “OX!”, если считать, что опциональный список (A)? достаточно раскрыть на глубину 1. Чтобы список можно было отличить от опционального символа, можно

раскрыть его на глубину 2, использовав, например, “O”, “OX!” и “OX!Z!”. Таким образом, набор данных “X::!”, “Y!”, “Z!”, “O”, “OX!”, “OX!Z!” покрывает все альтернативы во всех правилах.
^

7.3Критерии полноты на основе требований


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

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

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

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

Например, пусть в требованиях к системе есть такая фраза.

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

В ней можно выделить следующие утверждения:

  • «Оператор может прочесть данные записи о клиенте»

  • «Оператор может добавить запись о клиенте»

  • «Оператор может удалить запись о клиенте, если работает с ней один»

  • «Оператор может модифицировать запись о клиенте, если работает с ней один»

  • «Если несколько операторов работает с записью о клиенте, только один может ее удалить»

  • «Если несколько операторов работает с записью о клиенте, только один может ее модифицировать»


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

Часто встречающийся случай — оформление требований в виде набора правил (или бизнес-правил). В этом случае метрикой покрытия правил считают долю проверенных тестами правил среди всех имеющихся.

Это позволяет определить метрики покрытия условий правил примерно так же, как это делается для покрытия условий, используемых в коде. Можно использовать аналоги метрик покрытия элементарных условий, условий и ветвлений, комбинаций условий или MC/DC. Использовать аналог метрики покрытия коротких дизъюнктов нельзя, если только мы не уверены, что в коде эти же условия используются ровно в этом же порядке, что практически никогда не выполнено.

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

7.4Критерии полноты на основе предположений об ошибках


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

В рамках этого метода для языка программирования, на котором написана тестируемая программа, определяется достаточно полный набор операторов мутации. Каждый такой оператор изменяет текст программ, например, удаляя определенную инструкцию, вставляя новую инструкцию, заменяя переменные в выражениях на другие переменные того же типа или на константные выражения того же типа, заменяя операторы арифметических действий +, –, *, / друг на друга, заменяя операторы логических операций друг на друга и пр. Важно, что после применения любого из операторов мутации синтаксически и семантически корректная программа остается корректной.

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

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

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

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




оставить комментарий
страница6/7
Дата18.11.2011
Размер0,85 Mb.
ТипДиплом, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы: 1   2   3   4   5   6   7
Ваша оценка этого документа будет первой.
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Документы

наверх