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

Приприменении этой техники по набору контрактов и критерию полноты строится автоматнаямодель, проход по всем переходам которой гарантирует достижение заданного критерия.Такая редукция выполняется следующим образом.1. Выделение целей тестирования.На первом шаге для каждой операции перечисляются выделяемые критериемполноты тестирования ситуации — это и есть цели тестирвоания.В нашем случае перечень этих ситуаций такой.• Метод add.o пустой список и корректный индекс;o пустой список и некорректный индекс;o непустой список и корректный индекс;o непустой список и некорректный индекс.•Метод remove.o пустой список;o список с одним элементом и корректный индекс;o список с одним элементом и некорректный индекс;o список с двумя или более элементами и корректный индекс;o список с двумя или более элементами и некорректный индекс.• Метод indexOfo пустой список;o список с одним элементом и аргумент в списке;o список с одним элементом и аргумента нет в списке;o список с двумя или более элементами и аргумент в списке;o список с двумя или более элементами и аргумента нет в списке.Эти ситуации представляются как ограничения, вырезающие из областиопределения операции подобласти в пространстве возможных состояний системыи аргументов операции.2.

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

Этимножества образуют разбиение всех состояний на классы эквивалентности.ПараметрыОбласть определенияОбласти, соответствующиеразличным ситуациямСостоянияРисунок 1. Построение обобщенных состояний и действий.Полученные так множества состояний — обобщенные состояния — являютсякандидатами на роль состояний автомата, моделирующего систему. Действия вэтом автомате соответствуют всем возможным ситуациям. Проход по всем егопереходам будет означать, что все исходные ситуации проверены.В нашем примере такими пересечениями проекций ситуаций являютсяследующие обобщенные состояния.• Пустой список.• Список с одним элементом (произвольным).• Список с двумя или более элементами.3.

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

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

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

Чтобы егоудалить совсем, придется различать списки с различным числом элементов.Заметьте, что в полученном автомате никак не учитывается. Какие именноэлементы находятся в списке — важно только их число.Действия в этом автомате соответствуют исходным ситуациям (аналогичныедействия в различных состояниях можно обозначать одним способом).• Добавить элемент с корректным индексом.• Добавить элемент с некорректным индексом.• Удалить элемент с корректным индексом.• Удалить элемент с некорректным индексом.• Найти индекс первого вхождения элемента, отсутствующего в списке.• Найти индекс первого вхождения элемента, присутствующего в списке.4.

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

Эти параметры можно сделать параметрами теста, чтобы по одному итому же описания можно было строить тесты различной сложности.В примере тестирования списка «уводящей от начального состояния» операциейявляется добавление элементов. Достаточно запретить его при достижениинекоторого максимально возможного в тесте количества элементов N. Чтобыпокрыть все исходные ситуации, достаточно, чтобы N было не меньше двух.B,D,E0B,D,EA1CB,D,EAC2B,D,EA3CB,D,EA4CB,D,EA5CB,D,EA6CB,D,EA7CB,D,EA8CB,D,EACA — add(), Normal caseB — add(), Exceptional caseC — remove(), Normal caseD — remove(), Exceptional caseE — indexOf(), все случаиРисунок 2. Граф состояний автомата, моделирующего список, для значения параметра 9.Осталось оформить неявное описание такого автомата в виде тестового сценария.public scenario class ListTest{ListSpecification<Object> list = mediator VectorAdapter<Object>(target = new Vector()); // инициализируем используемый адаптерint maxSize = 9;Object[] objPool = new Object[] { new Object(), null };public static void main(String[] args) // метод запуска теста{ListTest test = new ListTest();// устанавливаем используемый алгоритм обходаtest.setExplorer(new jatva.exploration.DFSExplorer());test.run(); // выполняем тест}// блок, задающий вычисление текущего состоянияstate { return list.items.length; }scenario add(){if(list.items.length < maxSize) // добавляем элементы не всегда{iterate(int i = 0; i < maxSize; i++)iterate(Object o : objPool)list.add(i, o);}}scenario remove(){iterate(int i = 0; i < maxSize; i++)list.remove(i);}scenario indexOf(){iterate(Object o : objPool)list.indexOf(o);}}9Анализ результатов тестированияПри анализе результатов необходимо выполнить следующие действия.1.

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

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

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

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