лекции, страница 12

Есть два основных способаопределения такой эквивалентности.•Выделение разных подтипов данных одного типа на основе практических соображений.Например, ряд соображений позволяет разделить целые числа на положительные,отрицательные и 0. Следуя другим соображениям можно разбить их на четные инечетные числа.Для числа типа double можно определить такие возможности: 0, целое, с небольшимколичеством цифр в дробной части (<= 2), например, 0.5 или 0.25, с большимколичеством цифр в дробной части, например, 9.38752635549⋅10–7. Кроме того, можновыделить положительные и отрицательные числа, а также превосходящие и непревосходящие 1 по абсолютной величине.•Разделение значений по определенным правилам, касающимся их структуры.Например, целые числа обычно представляются в двоично-дополнительном формате,все отрицательные имеют первый (последний) бит, равный 1, в отличие отнеотрицательных.

Поэтому разбиение на положительные и отрицательные можнообосновать структурой представления числа в машине. Можно делить целые числа набольшие и небольшие по абсолютной величине в соответствии с тем, есть ли хотя быодин бит равный 1 среди первых 16. То есть, числа >= 65536 по абсолютной величинеобъявляются большими, а меньшие — небольшими.Числа с плавающей точкой имеют более сложную структуру. В представлении числаформата double используется 64 бита. Первый бит — знак S, следующие 11 битпредставляют экспоненту E, оставшиеся 52 бита — мантиссу M. Само число при этомсчитается равным (–1)S⋅(252+M)/252⋅2(E-1023), если экспонента не равна 0 или 2047.Если экспонента равна 0, соответствующие числа называются денормализованными ивычисляются по другой формуле — (–1)S⋅M/252⋅2-1023.

Если экспонента равна 2047, топри нулевой мантиссе получаются представления для положительной и отрицательнойбесконечностей, а при ненулевой — для специального значения NaN, котороеобозначает неопределенный результат.Таким образом, как специальные классы чисел с плавающей точкой можно выделить 0,–0 (есть такое специальное число!), положительные и отрицательныеденормализованные, положительные и отрицательные нормализованные числа,положительную и отрицательную бесконечность и множество значений NaN.Для определения классов эквивалентных сложных данных обычно используют ихструктуру и классы эквивалентности данных простых типов, из которых они построены.

Так,определяя разбиения на классы для объектов, у которых два целочисленных поля,достаточно естественно объявить эквивалентными объекты, у которых соответствующиеполя имеют один знак или одновременно равны 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!” покрывает все альтернативы во всехправилах.Можно определить более сложные метрики покрытия комбинаций альтернатив, нообычно они на практике дают слишком большое количество необходимых тестов.Критерии полноты на основе требованийБазовая идея метрик покрытия на основе требований — если два теста проверяютвыполнения одних и тех же ограничений, определенных в требованиях, скорее всего, онилибо оба обнаружат ошибку, либо оба выполнятся успешно.

Поэтому их можно считатьэквивалентными.Это неправда, как и базовая идея структурных критериев, но тоже позволяет ввестидостаточно удобные метрики покрытия.Обычно требования оформляются в виде неформального текста, организованногоиерархически, т.е. с выделенными пунктами и подпунктами. В этом случае можноопределить метрику покрытия требований как долю проверяемых тестовым наборомнаиболее детальных выделенных пунктов требований среди тех, которые вообще можнопроверить (иногда часть таких требований невозможно проверить вообще, либо за время,ограниченное рамками проекта).Более формальное определение можно дать метрике покрытия утверждений. Для ееопределения из требований выделяются элементарные проверяемые утверждения,выполнение каждого которых, вообще говоря, не связано с выполнением остальных.Метрика определяется как доля проверенных в тестах таких утверждений по отношению ковсем.Например, пусть в требованиях к системе есть такая фраза.«Система должна поддерживать выполнение операций чтения, добавления, удаления имодификации записи о клиенте, причем, при параллельной работе нескольких операторовтолько один из них в своей сессии может удалять и модифицировать уже имеющуюсязапись».В ней можно выделить следующие утверждения:•«Оператор может прочесть данные записи о клиенте»•«Оператор может добавить запись о клиенте»•«Оператор может удалить запись о клиенте, если работает с ней один»•«Оператор может модифицировать запись о клиенте, если работает с ней один»•«Если несколько операторов работает с записью о клиенте, только один может ееудалить»•«Если несколько операторов работает с записью о клиенте, только один может еемодифицировать»Соответственно, измерять полноту покрытия тестов можно отношением количествапроверенных из этих утверждений к общему числу выделенных.Часто встречающийся случай — оформление требований в виде набора правил (илибизнес-правил).

В этом случае метрикой покрытия правил считают долю проверенныхтестами правил среди всех имеющихся.Например, система управления лифтами может описываться следующими правилами.1. Если нажимается внешняя кнопка вызова лифта на каком-то этаже, этот вызовпомещается в общее множество вызовов.2. Если нажимается внутренняя кнопка вызова лифта на какой-то этаж, кабинапомещает этот вызов в свое множество обслуживаемых.3. Если препятствий к закрытию дверей кабины нет в течение двух секунд, дверизакрываются.4. Если кабина прибывает на один из этажей, вызовы с которых есть у нее вмножестве обслуживаемых, она останавливается и открывает двери.5. Если двери закрылись и обслуживаемых или общих вызовов нет, кабина стоит наместе и направление ее движения не определено.6.

Если двери закрылись и есть обслуживаемые вызовы, направления движениякабины совпадает с предыдущим, если этаж не крайний (первый или последний), ипротивоположно, если этаж крайний.7. Если двери закрылись, определено направление движения, и есть общие вызовы сэтажа по этому направлению, кабина выбирает ближайший из них по разницеэтажей, добавляет его в свое множество обслуживаемых и удаляет из общего.8. Если двери закрылись и направление движения не определено, но есть общиевызовы, кабина выбирает ближайший к ней по разнице этажей, добавляет его всвое множество обслуживаемых и удаляет из общего, после чего направлениедвижение кабины определяется направлением на этот этаж.Как видно, правила часто могут быть представлены в виде выражений «Если выполненоA, то сделать B», где A — некоторое составное условие в терминах предметной области, B— некоторое множество действий.Это позволяет определить метрики покрытия условий правил примерно так же, как этоделается для покрытия условий, используемых в коде.