Разработка тестов из модели
Чтобы организовать тесты системы и компонентов, в Microsoft Visual Studio Ultimate можно использовать требования и модели архитектуры. Такой подход позволяет обеспечить тестирование важных для пользователей и других заинтересованных лиц требований и помогает быстро обновлять тесты при изменении требований. Если используется Microsoft Test Manager, можно также поддерживать ссылки между моделями и тестами.
Тестирование системы и подсистемы
Тестирование системы, также называемое приемочное тестирование, проводится для того, чтобы проверить, удовлетворяются ли потребности пользователей. В ходе таких тестов проверяется видимое извне поведение системы, а не ее внутреннее строение.
Системные тесты особенно полезны при расширении или изменении системы. Благодаря этим тестам можно избежать появления ошибок при изменении кода.
Планируя изменение или расширение системы, рекомендуется вначале выполнить набор системных тестов в существующей системе. После этого можно расширить или скорректировать эти тесты для проверки новых требований, внести изменения в код и повторно выполнить полный набор тестов.
При разработке новой системы можно начать создавать тесты сразу после начала разработки. Определение тестов перед разработкой каждой функции позволяет очень конкретно обсуждать требования.
Тестирование подсистемы позволяет применить те же принципы к основным компонентам системы. Каждый компонент тестируется отдельно от других компонентов. В ходе тестирований подсистем проверяется поведение, видимое в пользовательских интерфейсах или API компонента.
Дополнительные сведения о выполнении тестов см. в разделе Тестирование приложения.
Наследование системных тестов от модели требований
Можно создать и поддерживать отношение между системными тестами и моделью требований. Чтобы установить эту связь, нужно создать тесты, соответствующие основным элементам модели требований. Visual Studio Ultimate позволяет поддерживать эту связь, предоставляя возможность создавать ссылки между тестами и частями модели. Дополнительные сведения о моделях требований см. в разделе Моделирование требований пользователей.
Создание тестов для каждого варианта использования
При использовании Microsoft Test Manager можно создать группу тестов для каждого варианта использования, определенного в модели требований. Например, если имеется вариант использования "Заказ еды", включающий компоненты "Создание заказа" и "Добавление пункта в заказ", можно создавать тесты как для общего, так и для более подробного варианта использования. Дополнительные сведения о вариантах использования см. в разделе UML-схемы вариантов использования: правила работы.
Возможно, окажутся полезными следующие рекомендации.
Для каждого варианта использования необходимо создать несколько тестов — для главных путей и исключительных выходных результатов.
При описании варианта использования в модели требований важнее определить его постусловие (то есть достигаемую цель), чем подробно описать процедуры, выполняемые пользователем для достижения этой цели. Например, постусловием варианта использования "Заказ еды" может стать подготовка еды рестораном для клиента и оплата заказа клиентом. Постусловие — это критерий, который должен проверяться в ходе тестов.
Каждый тест должен основываться на отдельном предложении постусловия. Например, нужно создать отдельные тесты для уведомления ресторана о заказе и для приема платежа от клиента. Подобное разделение обладает следующими преимуществами.
Изменения в разных аспектах требований часто происходят независимо. Если создать отдельные тесты для разных аспектов таким способом, обновлять тесты при изменении требований будет легче.
Если план разработки реализует один аспект варианта использования перед другим, в ходе разработки можно включать тесты по отдельности.
При создании тестов нужно отделить выбор результатов теста от кода или скрипта, определяющего, было ли выполнено постусловие. Например, тест простой арифметической функции может иметь следующий вид: входное значение —4; проверить, что выходное значение — 2. Вместо этого необходимо создать следующий скрипт: выберите входное значение, умножьте выходное значение на себя и проверьте, что результат совпадает с первоначальным входным значением. Этот подход позволит изменять входные данные теста, не изменяя его основную часть.
Связывание тестов и вариантов использования
Если для разработки и выполнения тестов используется Менеджер тестирования, можно организовать тесты по следующим рабочим элементам: требованию, варианту использования, описанию функциональности пользователей. В модели эти рабочие элементы можно связать с вариантами использования. Это позволит быстро отслеживать изменения требований в тестах и фиксировать выполнение каждого варианта использования.
Связывание тестов с вариантом использования
В Менеджер тестирования создайте требование и набор тестов на основе этого требования. Сведения об этом см. в разделе Создание плана тестирования на основании требований или сведений, полученных от пользователей.
Создаваемое требование является рабочим элементом в Team Foundation Server. В зависимости от того, какой шаблон процесса используется в проекте в Team Foundation, это может быть один из следующих рабочих элементов: описание функциональности пользователей (user story), требование или вариант использования. Дополнительные сведения см. в разделе Планирование и отслеживание проектов.
Свяжите рабочий элемент "требование" с одним или несколькими вариантами использования в модели.
На схеме вариантов использования щелкните вариант использования правой кнопкой мыши, затем выберите Связать с рабочим элементом. Дополнительные сведения см. в разделе Практическое руководство. Связывание элементов модели с рабочими элементами.
Добавьте в набор тестов тестовые случаи, которые проверяют варианты использования.
Как правило, каждый рабочий элемент "описание функциональности пользователей (user story)" или "требование" связан в модели с несколькими вариантами использования, и каждый вариант использования связан с несколькими описаниями функциональности пользователей (user story) или требованиями. Это объясняется тем, что каждое описание функциональности пользователей (user story) или требование покрывает набор задач, разрабатывающих несколько вариантов использования. Например, на ранних итерациях проекта можно разработать базовое описание функциональности пользователей (user story), в котором клиент сможет выбирать товары из каталога и заказывать их доставку. На более поздней итерации можно составить описание функциональности, в котором пользователь оплачивает заказ после получения, а поставщик получает деньги после отправки товаров. Каждое описание функциональности добавляет предложение в постусловие варианта использования "Заказ товаров".
Можно создать отдельные связи от требований к предложениям постусловия, записав эти предложения в отдельных комментариях на схеме вариантов использования. Каждый комментарий можно связать с рабочим элементом "требование", а затем связать комментарий с вариантом использования на схеме.
Создание тестов на основе типов требований
Типы модели требований (то есть классы, интерфейсы и перечисления) описывают понятия и отношения, используемые пользователями для анализа своего бизнеса и предоставления сведений о нем. Сюда не входят типы, имеющие отношение только к внутреннему строению системы.
Разрабатывать тесты нужно с использованием этих типов требований. Такой подход позволяет легко связывать изменения в требованиях с необходимыми изменениями в тестах при обсуждении изменений в требованиях. Это, в свою очередь, позволяет обсуждать тесты и ожидаемые результаты непосредственно с пользователями и другими заинтересованными лицами. Следовательно, потребности пользователей можно удовлетворять вне процесса разработки; кроме того, так можно избежать непреднамеренной разработки тестов для возможных изъянов в разработке.
При проведении ручных тестов такой подход подразумевает использование в сценариях теста словаря модели требований. При проведении автоматических тестов такой подход предполагает использование схем классов требований в качестве основы тестового кода и создание функций методов доступа и средств обновления для связи модели требований с кодом.
Например, модель требований может включать типы "меню", "пункт меню" и "заказ" и связи между ними. Эта модель представляет сведения, которые хранятся и обрабатываются системой заказа еды, но не дает представления о сложностях ее реализации. В рабочей системе может существовать несколько разных реализаций каждого типа — в базах данных, пользовательских интерфейсах и API. В распределенной системе может существовать несколько вариантов каждого экземпляра, одновременно хранимых в разных частях системы.
Чтобы протестировать такой вариант использования, как "Добавление пункта в заказ", нужно включить в метод теста код, аналогичный следующему.
Order order = … ; // set up an order
// Store prior state:
int countBefore = order.MenuItems.Count;
// Perform use case:
MenuItem chosenItem = …; // choose an item
AddItemToOrder (chosenItem, order);
// Verify part of postcondition:
int countAfter = order.MenuItems.Count;
Assert (countAfter == countBefore = 1);
Обратите внимание, что этот метод теста использует классы модели требований. Ассоциации и атрибуты реализуются в виде свойств .NET.
Для этого свойства классов должны быть определены в качестве функций только для чтения или методов доступа, которые осуществляют доступ к системе, чтобы извлечь сведения о ее текущем состоянии. Методы, имитирующие такие варианты использования, как AddItemToOrder, должны провести систему через API или через слой под его пользовательским интерфейсом. Конструкторы тестовых объектов, таких как Order и MenuItem, также должны обеспечить создание системой соответствующих элементов в системе.
Многие методы доступа и средства обновления уже будут доступны через обычный API приложения. Однако для проведения тестов может потребоваться создать некоторые дополнительные функции. Эти дополнительные методы доступа и средства обновления иногда называются инструментированием теста. Так как они зависят от внутреннего строения системы, ответственность за предоставление этих методов и средств лежит на разработчиках системы, а тест-инженеры создают код тестов, используя модель требований.
При создании автоматических тестов можно использовать обычные тесты для упаковки методов доступа и средств обновления. Дополнительные сведения см. в разделе Создание автоматического теста, запускающегося в виде исполняемого файла с помощью обычных тестов.
Тесты для бизнес-правил
Некоторые требования не связаны непосредственно ни с одним вариантом использования. Например, в DinnerNow клиенты могут выбирать из нескольких меню, но все выбранные элементы одного заказа должны быть из одного меню. Это бизнес-правило может быть выражено в виде инвариантного правила о связях между заказами, меню и пунктами в модели классов требований.
Инвариантное правило такого рода регулирует не только все варианты использования, определенные в настоящее время, но и любые другие варианты использования, которые будут определены в дальнейшем. Следовательно, рекомендуется записать его отдельно от любых вариантов использования и тестировать его отдельно от них.
Инвариантное бизнес-правило можно записать в качестве комментария в схеме классов. Дополнительные сведения см. в разделе UML-схемы классов: правила работы.
Связь тестов с бизнес-правилом обеспечивается связыванием комментария с рабочим элементом "требование" или "описание функциональности пользователей (user story)", которые, в свою очередь, можно связать с набором тестов в Менеджер тестирования. Дополнительные сведения см. в разделе Подключение тестовых случаев к элементам моделей.
Производительность и другие требования к качеству обслуживания можно указать в комментариях к варианту использования, действию или схемам последовательностей. Их также можно связать с рабочими элементами "требования" и их наборами тестов.
Схемы последовательностей и активности для тестов
Если требования или модели архитектуры включают схемы последовательностей или схемы активности, можно создавать тесты, непосредственно следующие за схемами.
В некоторых случаях рекомендуется разрабатывать тесты, которые динамически выбирают разные пути через ветви и петли на схеме.
Пытайтесь проверять состояние системы после каждого сообщения или действия. Для этого может потребоваться дополнительное инструментирование.
Наследование подсистемных тестов от моделей
При высокоуровневой разработке крупной системы можно идентифицировать компоненты или подсистемы. Они представляют собой части, которые можно проектировать отдельно, или части, находящиеся на разных компьютерах. Также они могут являться допускающими повторное использование модулями, которые можно перекомпоновывать различными способами. Дополнительные сведения см. в разделе UML-схемы компонентов: правила работы.
К каждому крупному компоненту можно применять те же принципы, что и ко всей системе. В крупном проекте каждый компонент может иметь собственную модель требований. В более мелких проектах можно создать модель архитектуры или высокоуровневую структуру, чтобы показать основные компоненты и взаимодействия между ними. Дополнительные сведения см. в разделе Моделирование архитектуры программной системы.
В любом случае можно установить отношение между элементами модели и подсистемными тестами так же, как между моделью требований и системными тестами.
Изолирование компонентов с предоставленными и требуемыми интерфейсами
Рекомендуется идентифицировать все зависимости между компонентом и другими частями системы или внешних служб и представить их в виде требуемых интерфейсов. Выполнение этих действий, как правило, приводит к некоторым изменениям, после которых компонент становится более изолированным и легко отделяется от остальных компонентов.
Преимуществом такой изолированности является то, что при тестировании этого компонента можно заменять службы, которыми этот компонент обычно пользуется, макетами объекта. Это компоненты, настраиваемые для тестирования. Макет компонента предоставляет необходимый компоненту интерфейс в ответ на запросы с имитированными данными. Макеты компонентов являются частью полного окружения теста, которое можно подключить ко всем интерфейсам компонента.
Преимуществом тестирования с использованием макетов является возможность разрабатывать данный компонент, даже если разработка других компонентов, службами которых он будет пользоваться, не завершена.
Поддержание отношений между тестами и моделью
В обычном проекте, выполняющем итерацию каждые несколько недель, перед началом каждой итерации проводится пересмотр требований. На встрече обсуждаются функции, которые должны быть предоставлены в следующей итерации. Чтобы облегчить обсуждение разрабатываемых понятий, сценариев и последовательностей действий, можно использовать модель требований. Заинтересованные лица из сферы бизнеса задают приоритеты, разработчики проводят оценки, тест-инженеры следят, чтобы ожидаемое поведение каждой функции было правильно зафиксировано.
Создание тестов — самый эффективный способ определить требование и убедиться, что человек хорошо понимает, что необходимо. Однако на составление тестов уходит много времени, поэтому на этапе определения спецификации рекомендуется воспользоваться более быстрым способом, то есть создавать модели.
С точки зрения тестирования модель требований представляется краткой версией тестов. Следовательно, на протяжении проекта необходимо поддерживать отношение между тестами и моделью.
Присоединение тестовых случаев к элементам моделей
Если в проекте используется Менеджер тестирования, можно связать тесты с элементами модели. Это позволяет быстро находить тесты, на которые влияет изменение требований, и помогает отслеживать, в какой степени было удовлетворено требование.
Тесты можно связать со всеми видами элементов. Далее представлено несколько примеров.
Свяжите вариант использования с выполняющими его тестами.
Запишите предложения постусловия варианта использования (или цель) в комментарии, связанные с вариантом использования, затем свяжите тесты с каждым из этих комментариев.
Запишите инвариантные правила в комментарии в схемах классов или схемах активности и свяжите их с тестами.
Свяжите тесты со схемой активности или с отдельными действиями.
Свяжите набор тестов с компонентом или подсистемой, которую он тестирует.
Связь тестов с элементом модели или отношением
В Менеджер тестирования создайте требование и набор тестов на основе этого требования. Сведения об этом см. в разделе Создание плана тестирования на основании требований или сведений, полученных от пользователей.
Создаваемое требование является рабочим элементом в Team Foundation Server. В зависимости от того, какой шаблон процесса используется в проекте в Team Foundation, это может быть один из следующих рабочих элементов: описание функциональности пользователей (user story), требование или вариант использования. Дополнительные сведения см. в разделе Планирование и отслеживание проектов.
Свяжите рабочий элемент "требование" с одним или несколькими элементами в модели.
В схеме моделирования щелкните элемент, комментарий или отношение правой кнопкой мыши, затем выберите Связать с рабочим элементом. Дополнительные сведения см. в разделе Практическое руководство. Связывание элементов модели с рабочими элементами.
Добавьте в набор тестов тестовые случаи, проверяющие требование, которое выражено в элементе модели.
См. также
Основные понятия
Разработка моделей для программного проектирования
Моделирование требований пользователей