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

Определение задач и рамок тестируемой системы.В рамках этой задачи нужно определить, что представляет собой тестируемаясистема (system under test, SUT), для чего она предназначена — какие основныезадачи решает. Также важно, из каких частей она состоит — что входит, а что невходит в нее, какие именно части нужно тестировать, можно ли их отделить отдругих частей/других систем при проведении тестирования, и как.2. Определение набора проверяемых функций и свойств.Нужно выяснить, полный список функций (функция, feature — это некотораяуслуга, предоставляемая системой), которые необходимо протестировать, а такжесписок других свойств, которые необходимо проверять.

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

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

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

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

К таким свойствам относятсятребуемый вид тестирования (проверяется ли только базовая функциональность,основные способы использования или сложные сценарии работы, используются линекорректные входные данные или нет), наличие или отсутствие работы свнутренним состоянием, высокая или низкая сложность входных данных и частисостояния системы, связанной с данной группой, наличие или отсутствиезависимостей от других групп, важность или несущественность (отсутствиевозможности) асинхронных взаимодействий с системой в рамках данной группы.В соответствии с выявленными особенностями выбирается наиболее подходящийи эффективный набор техник построения тестов в рамках технологии и видовтестов, которые будут разрабатываться для данной группы.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. Систематизация требований.После выделения набора требований их необходимо превратить в некоторуюсистему — каждое требование должно иметь уникальный идентификатор, чтобына него можно было ссылаться в дальнейшем, должны быть выявлены связи междуотдельными требованиями — одни из них могут уточнять другие или являться ихследствием.

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