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

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

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

При необходимости проводитсяуточнение или исправление первичной декомпозиции, после чего часть уже выполненныхработ во определению требований, критериев полноты или разработке тестов бываетнеобходимо переделать в соответствии с внесенными изменениями.Рассмотрим небольшой пример. Пусть необходимо разработать тесты для классов,реализующих коллекции в пакете java.util библиотеки JDK. Всего в этом пакете 19интерфейсов, 59 классов (14 из них — абстрактные, т.е. предназначенные для созданияклассов-наследников на их основе), 1 перечислимый тип и 21 класс исключений.

Помимоколлекций, эти классы реализуют работу с датами, временем и таймерами, сгеографическими и национальными настройками системы, с наборами конфигурационныхсвойств, простейшие операции с регулярными выражениями, а также предоставляют базовыеклассы для образца «Подписчик». Непосредственно к коллекциям имеют отношение 16интерфейсов, 27 классов и 3 класса исключений.Анализ имеющейся документации (http://java.sun.com/javase/6/docs/api/) дает следующуюдополнительную информацию.• Вместо интерфейса Enumeration рекомендуется использовать Iterator, хотяпоследний более специфичен.

По-видимому, первый интерфейс оставлен, восновном, для обеспечения совместимости со старыми программами,написанными до появления Java 1.2.• Устаревшим также считается классы Dictionary (вместо него нужно использоватьинтерфейс Map).• Классы Hastable и Vector очень похожи по выполняемым функциям на HashMap иArrayList. Даже отличающиеся по имени их методы имеют аналогичнуюфункциональность. Единственное важное отличие — все методы первых двухклассов синхронизованы. Это означает, что они рассчитаны на корректную работуи при асинхронных обращениях к их объектам из различных потоков. Однако,если такие свойства не важны, можно совсем не использовать эти классы.Рассмотрим теперь отдельно разработку тестов для списков.

Список — линейноупорядоченная коллекция объектов, предоставляющая доступ ко всем своим элементам поих индексам. Из классов и интерфейсов коллекций в java.util к спискам относятся одининтерфейс List и 5 классов, реализующих его. Два класса — AbstractList иAbstractSequentialList — являются абстрактными, их методы доступны только черезнаследников (например, ArrayList и LinkedList). Класс Vector считается уже устаревшим,поэтому тесты для него могут не понадобиться.Класс ArrayList в дополнение к методам интерфейса List предоставляет только методыуправления вместимостью (capacity) массива, на основе которого построен данный список.Класс LinkedList содержит дополнительные методы работы с первым и последнимэлементами.

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

Кроме того, этитребования систематизируются и оформляются в виде модели поведения системы.Определение требований и их формализация разбиваются на следующие задачи.1. Определение источников требований.Прежде, чем начинать выделять отдельные требования, необходимо выявить всевозможные их источники. К таким источникам относятся следующие.• Проектная и пользовательская документация на систему.• Архитекторы, проектировщики и разработчики данной системы.• Бизнес-аналитики, эксперты в данной предметной области, опытныепользователи и руководители, технологи в организациях-заказчиках иконтролирующих организациях.• Стандарты, относящиеся к данной предметной области.• Другие аналогичные системы и их документация.2.

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

Требования должны быть классифицированы по обязательности ихвыполнения — как минимум нужно отделять обязательные от опциональных.Нужно стремиться привести требования в проверяемый вид — чтобы обладающийопределенной квалификацией человек мог по некоторым результатам работысистемы уверенно утверждать, выполнены они или нет. Это не всегда удается, но,по крайне мере, нужно отделить проверяемые требования от прочих.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 существенно отличается от других — для описания его поведения нужноиметь дополнительную структуру подсписков, построенных на основе данного. Вдокументации сказано, что такие подсписки являются только представлением, «другимвзглядом» на данные исходного списка, т.е.