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

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

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

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

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

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

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

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

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

Разработка адаптеров (если нужно).Если интерфейс тестируемой системы несколько отличается от того интерфейса еемодели поведения, для преобразования вызовов между этими двумя интерфейсамииспользуются тестовые адаптеры.Тестовые адаптеры бывают разных видов, в зависимости от двух факторов: вкакую сторону они выполняют преобразование (из модели в реализацию илиобратно), и какого рода связи с моделью и с реализацией (тестируемой системой)они используют.Модельно-реализационные адаптеры выполняют преобразование обращений измодельного интерфейса в реализационный, а результаты операций илиасинхронного возникающие события преобразую обратно — из реализационноговида в модельный.Реализационно-модельные адаптеры производят все преобразования только изреализационного вида в модельный.Модельно-реализационный адаптер может оформляться в виде класса,наследующего модельный класс и использующего классы тестируемой системы.Адаптеры, переводящие события из реализации в модель, наоборот, удобнееделать реализующими какие-то интерфейсы тестируемой системы ииспользующими модельные классы для сохранения информации о передаваемыхими событиях.Например, модельно-реализационный адаптер, реализующий описанный впредыдущей лекции класс спецификации списка через java.util.Vector можетвыглядеть примерно так.public mediator class VectorAdapter<E>implements ListSpecification<E>{implementation Vector target;public mediator void add(int i, E o)throws IndexOutOfBoundsException{implementation { target.insertElementAt(o, i); }update{E[] newItems = new E[items.length + 1];System.arraycopy(items, 0, newItems, 0, i);newItems[i] = o;System.arraycopy(items, i, newItems, i+1, items.length-i+1);items = newItems;}}...}В приведенном примере в блоке update выполняется экстраполяция новогосостояния модели в текущей ситуации.

Если же, например, можно использоватьрезультаты методов size и getElementAt как достоверные сведения о текущемсостоянии вектора, можно вместо блоков update в каждом из методов-адаптеровнаписать один общий блок update для всего класса.public mediator class VectorAdapter<E>implements ListSpecification<E>{...update{if(target == null) items = new E[];else{items = new E[target.size()];for(int i = 0; i < target.size(); i++)items[i] = target.getElementAt(i);}}...}6. Прогоны и отладка тестов.Ну, и наконец, в рамках этого этапа необходимо оформить тесты и отладить их.Разберем построение автоматного теста для списка, спецификации которого описаны впредыдущей лекции. Напомним, что для его тестирования выбран критерий полноты,требующий проверить работу списка в нормальных и исключительных ситуациях дляметодов add и remove, для метода indexOf — при наличии аргумента в списке и при егоотсутствии.

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