Lecture03 (Лекции в ПДФ), страница 5

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

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

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

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

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

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

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

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

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

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

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

Абстрактный тип данных, класс или компонент может быть описан алгебраическикак система с операциями, удовлетворяющими определенным соотношениям на ихрезультаты.Например, тип списка элементов типа T с операциями получения числа элементов,добавления элемента в заданное место списка, удаления элемента из заданного места иполучения элемента, находящегося в определенном месте, описывается так.[].size() = 0[X.size()] ≡ [X](i <= X.size()) => X.add(i, o).size() = X.size()+1(i < X.size()) => X.remove(i).size() = X.size()–1(i < X.size()) => [X.get(i)] ≡ [X](i, j <= X.size() & i < j) => [X.add(i, o1).add(j, o2)] ≡ [X.add(j–1, o2).add(i, o1)](i <= X.size()) => [X.add(i, o1).add(i, o2)] ≡ [X.add(i, o2).add(i+1, o1)](i <= X.size()) => [X.add(i, o).remove(i)] ≡ [X](i, j <= X.size() & i < j) => [X.add(i, o).remove(j)] ≡ [X.remove(j–1).add(i, o)](i, j <= X.size() & i > j) => [X.add(i, o).remove(j)] ≡ [X.remove(j).add(i, o)](i <= X.size()) => X.add(i, o).get(i) = o(i, j <= X.size() & i < j) => X.add(i, o).get(j) = X.get(j-1)(i, j <= X.size() & i > j) => X.add(i, o).get(j) = X.get(j)(i, j < X.size()-1 & i < j) => [X.remove(i).remove(j)] ≡ [X.remove(j+1).remove(i)](i, j < X.size() & i <= j) => X.remove(i).get(j) = X.get(j+1)(i, j < X.size() & i > j) => X.remove(i).get(j) = X.get(j)Терм в данной системе — любая конечная цепочка операций, примененная к [].