В.В. Кулямин - Тестирование на основе моделей, страница 27

Это не всегда удается, но,по крайне мере, нужно отделить проверяемые требования от прочих.4. Уточнение, согласование и устранение противоречий и неполноты.При систематизации и формализации требований выявляется множество дефектов— недостаточно ясные и точные формулировки, противоречия между разнымитребованиями или пожеланиями различных заинтересованных лиц, неполнота —отсутствие необходимой информации о свойствах системы в каком-либо аспекте.Все эти дефекты необходимо устранить, часто привлекая для этого различныхзаинтересованных лиц, чтобы выяснить точное значение некоторой фразы илисогласовать их противоречивые интересы и привести к разумным компромиссамотносительно свойств системы.5. Финальная декомпозиция.После приведения требований в систему необходимо проанализироватьпервичную декомпозицию интерфейса системы и внести в нее необходимыеизменения, связанные с полученной более полной информацией о работеразличных функций и операций и об их зависимостях друг от друга.6.

Формализация требований в виде модели поведения.Часто параллельно систематизации и согласованию проводится формализациятребований — построение формально описанной модели поведения системы,включающей все ее аспекты, важные с точки зрения данного проекта. В рамкахUniTESK используются модели в виде расширенных автоматов, программныхконтрактов. Для описания сложных структур данных используются иерархическиеструктурные модели (по сути — описания типов данных в виде наборов их полей,также имеющих некоторые типы или являющихся ссылками) или грамматики,пополненные дополнительными атрибутами (но не атрибутные грамматики всмысле Кнута).Рассмотрим в качестве примера разработку модели поведения в виде программногоконтракта для интерфейса списка.

Его методы можно условно разделить на следующиегруппы: работа со списком как с целым (equals, hashCode, toString, toArray, clear, size,isEmpty) , методы перебора (iterator, listIterator), методы для работы с отдельнымиэлементами списка (add, contains, get, indexOf, lastIndexOf, remove, set), работа с коллекциямиэлементов (addAll, containsAll, removeAll, retainAll), работа с подсписками (subList).Для определения требований достаточно использовать имеющуюся документацию наинтерфейсList(http://java.sun.com/javase/6/docs/api/).Онаданавдостаточносистематизированном виде, поэтому задачи по выделению и систематизации требованийможно считать уже решенными.Чтобы построить модель поведения списка в виде программного контракта, необходимоопределить структуру состояния, содержащую информацию достаточную для описания всехограничений на его операции, а для каждой операции определить предусловие и постусловие(которые могут зависеть от текущего состояния).Для полного описания поведения почти всех операций списка необходимо знать полныйнабор его элементов и их индексы.

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

Оставим покаформализацию этой функциональности за рамками рассмотрения. С учетом этого упрощенияописание структуры состояния списка может быть сделано так.public specification class ListSpecification<E>{protected E[] items;...}Теперь опишем метод add(int index, E element). В документации на этот метод сказаноследующее.Вставляет указанный объект в список на указанную позицию. Элементы, находившиеся в списке наэтой позиции или после нее, сдвигаются на одну позицию вперед.Параметры:index – номер позиции, на которую нужно вставить указанный объект.element – объект, который нужно вставить.Создаваемые исключения:UnsupportedOperationException – создается, если этот метод не поддерживается данной реализациейсписка.ClassCastException – создается, если класс указанного объекты препятствует его вставке в список.NullPointerException – создается, если указанный объект равен null и данная реализация списка неможет хранить null в качестве элемента.IllegalArgumentException – создается, если указанный объект не может быть вставлен в данный список.IndexOutOfBoundsException – создается, если указана некорректная позиция (index < 0 || index > size()).Поскольку обращаться к этому методу можно в произвольной ситуации, его предусловиедолжно быть всегда выполнено.Кроме того, для простоты предположим, что исключения первых четырех видов невозникают — т.е.

тестируемая реализация поддерживает операцию add, может иметьэлементы любого типа, подходящего с точки зрения типа второго параметра этого метода иможет иметь null в качестве элемента. Это уже не произвольная реализация интерфейса List.Ниже приведена спецификация метода add, использующая два вспомогательных метода:для сравнения объектов, каждый из которых может быть равен null, и для сравненияучастков массивов.public static boolean equalObjects(E o1, E o2){returno1 == null && o2 == null|| o1 != null && o1.equals(o2);}public static boolean equalArrays(E[] first, int firstStart, E[] second, int secondStart, int number){for(int i = 0; i < number; i++)if(!equalObjects(first[i+firstStart], second[i+secondStart]))return false;return true;}public specification void add(int i, E o)throws IndexOutOfBoundsException{post{E[] oldItems = (E[])(pre items.clone());if(i < 0 || i > oldItems.length)returnthrown != null&& thrown instanceof IndexOutOfBoundsException&& items.length == oldItems.length&& equalArrays(items, 0, oldItems, 0, items.length);elsereturnthrown== null&& items[i] == o&& items.length == oldItems.length + 1&& equalArrays(items, 0,oldItems, 0, i)&& equalArrays(items, i+1, oldItems, i, oldItems.length-i);}}В постусловии используется оператор пре-выражения pre, результатом применениякоторого к некоторому выражению является значение этого выражения непосредственноперед началом работы описываемой операции.

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

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

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

При одном из них создаетсяисключение, а содержимое списка не изменяется, при другом исключения нет, адобавляемый элемент вставляется на указанное первым аргументом место. Различие междуэтими поведениями отражается в различных выражениях, использованных для их описанияпри вычислении результата постусловия.Чтобы явно выделить различные поведения или ветви функциональности, используетсяоператор оператора branch. Чтобы сделать покрытие той или иной ветви болееуправляемым, условия их выполнения должны зависеть только от входных данных метода —состояния списка при его вызове и значений параметров.После добавления указания ветвей функциональности постусловие метода addприобретает следующий вид.post{E oldItems[] = (E[])items.clone();if(i < 0 || i > oldItems.length){branch ExceptionalCase;returnthrown != null&& thrown instanceof IndexOutOfBoundsException&& items.length == oldItems.length&& equalArrays(items, 0, oldItems, 0, items.length);}else{branch NormalCase;returnthrown== null&& items[i] == o&& items.length == oldItems.length + 1&& equalArrays(items, 0,oldItems, 0, i)&& equalArrays(items, i+1, oldItems, i, oldItems.length-i);}Поскольку при выборе пути до оператора branch могут использоваться только пре-состояние объекта и значения входных параметров, удобно считать, что положение этогооператора соответствует точке вызова тестируемой операции.