Поделиться через

Разработка тестов на основе модели

  • Статья

Чтобы организовать тесты системы и компонентов, можно использовать требования и модели архитектуры. Такой подход позволяет обеспечить проверку требований, важных для пользователей и других заинтересованных лиц, и помогает быстро обновлять тесты при изменении требований. При использовании Microsoft Test Manager можно также поддерживать связи между моделями и тестами.

Сведения о том, какие версии Visual Studio поддерживают эти функции, см. в разделе "Поддержка версий" для средств архитектуры и моделирования.

Тестирование системы и подсистемы

Системное тестирование, также известное как приемочное тестирование, означает, соответствуют ли потребности пользователей. В ходе таких тестов проверяется видимое извне поведение системы, а не ее внутреннее строение.

Системные тесты особенно полезны при расширении или изменении системы. Благодаря им можно избежать появления ошибок при изменении кода.

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

При разработке новой системы можно начать создавать тесты сразу после начала разработки. Определение тестов перед разработкой каждой функции позволяет очень конкретно обсуждать требования.

При тестировании подсистемы те же принципы применяются к основным компонентам системы. Каждый компонент тестируется отдельно от других компонентов. В ходе тестов подсистем проверяется поведение, видимое в пользовательских интерфейсах или API компонента.

Наследование системных тестов от модели требований

Вы можете создать и поддерживать отношение между системными тестами и моделью требований. Чтобы установить это отношение, нужно создать тесты, соответствующие основным элементам модели требований. Visual Studio позволяет поддерживать это отношение, предоставляя возможность создавать ссылки между тестами и частями модели. Дополнительные сведения о моделях требований см. в разделе "Требования для пользователей модели".

Создание тестов для каждого варианта использования

При использовании Microsoft Test Manager можно создать группу тестов для каждого варианта использования, определенного в модели требований. Например, если есть вариант использования "Заказ еды", включающий компоненты "Создание заказа" и "Добавление пункта в заказ", можно создавать тесты как для общего, так и для более подробного варианта использования.

Возможно, окажутся полезными приведенные ниже рекомендации.

  • Для каждого варианта использования необходимо создать несколько тестов — для главных путей и исключительных результатов.

  • При описании варианта использования в модели требований важнее определить его постусловие (то есть достигаемую цель), чем подробно описать процедуры, выполняемые пользователем для достижения этой цели. Например, постусловием варианта использования "Заказ еды" может стать приготовление еды рестораном для клиента и оплата заказа клиентом. Постусловие — это критерий, который должен проверяться в ходе тестов.

  • Каждый тест должен основываться на отдельном предложении постусловия. Например, следует создать отдельные тесты для уведомления ресторана о заказе и для приема платежа от клиента. Такое разделение имеет указанные ниже преимущества.

    • Изменения в разных аспектах требований часто происходят независимо. Если создать отдельные тесты для разных аспектов таким способом, обновлять тесты при изменении требований будет легче.

    • Если план разработки реализует один аспект варианта использования перед другим, в ходе разработки можно включать тесты по отдельности.

  • При создании тестов нужно отделить выбор данных теста от кода или скрипта, определяющего, было ли выполнено постусловие. Например, тест простой арифметической функции может иметь следующий вид: входное значение 4; проверить, равно ли выходное значение 2. Вместо этого создайте следующий скрипт: выберите входное значение, умножьте выходное значение на себя и проверьте, совпадает ли результат с первоначальным входным значением. Этот подход позволит изменять входные данные теста, не изменяя его основную часть.

Связывание тестов и вариантов использования

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

  1. В Test Manager создайте требование и создайте на нем набор тестов.

    Требование, которое вы создаете, является рабочим элементом в Team Foundation Server. Это может быть рабочий элемент "История пользователя", "Требование" или "Вариант использования" в зависимости от шаблона процесса, используемого в проекте с Team Foundation. Дополнительные сведения см. в статье о средствах Agile и управлении проектами Agile.

  2. Свяжите рабочий элемент "требование" с одним или несколькими вариантами использования в модели.

    На схеме вариантов использования щелкните правой кнопкой мыши вариант использования и щелкните ссылку на рабочий элемент.

  3. Добавьте в набор тестов тестовые случаи, которые проверяют варианты использования.

    Как правило, каждый рабочий элемент "пользовательская История" или "требование" связан в модели с несколькими вариантами использования, и каждый вариант использования связан с несколькими пользовательскими Историями или требованиями. Это объясняется тем, что каждая пользовательская История или требование охватывает набор задач, связанных с разработкой нескольких вариантов использования. Например, на ранних итерациях проекта можно разработать базовую пользовательскую Историю, в которой клиент сможет выбирать товары из каталога и заказывать их доставку. На более поздней итерации можно составить Историю, в которой пользователь оплачивает заказ после получения, а поставщик получает деньги после отправки товаров. Каждая История добавляет предложение в постусловие варианта использования "Заказ товаров".

    Вы можете создать отдельные связи от требований к предложениям постусловия, записав эти предложения в отдельных комментариях на схеме вариантов использования. Каждый комментарий можно связать с рабочим элементом "требование", а затем связать комментарий с вариантом использования на схеме.

Создание тестов на основе типов требований

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

Разрабатывать тесты нужно с использованием этих типов требований. Такой подход позволяет легко связывать изменения в требованиях при их обсуждении с необходимыми изменениями в тестах. Это, в свою очередь, позволяет обсуждать тесты и ожидаемые результаты непосредственно с пользователями и другими заинтересованными лицами. Следовательно, потребности пользователей можно удовлетворять вне процесса разработки. Кроме того, так можно избежать непреднамеренной разработки тестов для возможных изъянов в разработке.

При проведении тестов вручную такой подход подразумевает использование в скриптах тестов словаря модели требований. При проведении автоматических тестов такой подход предполагает использование схем классов требований в качестве основы тестового кода и создание функций доступа и обновления для связи модели требований с кодом.

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

Инвариантное правило такого рода регулирует не только все варианты использования, определенные в настоящее время, но и любые другие варианты использования, которые будут определены в дальнейшем. Поэтому рекомендуется записать и тестировать его отдельно от любых вариантов использования.

Наследование тестов подсистемы от моделей

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

К каждому крупному компоненту можно применять те же принципы, что и ко всей системе. В крупном проекте каждый компонент может иметь собственную модель требований. В более мелких проектах можно создать модель архитектуры или высокоуровневую структуру, чтобы показать основные компоненты и взаимодействия между ними. Дополнительные сведения см. в разделе "Модель архитектуры приложения".

В любом случае можно установить отношение между элементами модели и тестами подсистем так же, как между моделью требований и системными тестами.

Изолирование компонентов с предоставленными и требуемыми интерфейсами

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

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

Преимуществом тестирования с использованием макетов является возможность разрабатывать компонент, даже если разработка других компонентов, службами которых он будет пользоваться, не завершена.

Поддержание отношений между тестами и моделью

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

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

С точки зрения тестирования модель требований представляется краткой версией тестов. Поэтому на протяжении проекта необходимо поддерживать отношение между тестами и моделью.

Присоединение тестовых вариантов к элементам модели

Если в проекте используется диспетчер тестов, можно связать тесты с элементами в модели. Это позволяет быстро находить тесты, на которые влияет изменение требований, и помогает отслеживать, в какой степени было удовлетворено требование.

Тесты можно связать со всеми видами элементов. Далее приводятся некоторые примеры.

  • Свяжите вариант использования с выполняющими его тестами.

  • Запишите предложения постусловия варианта использования (или цель) в комментариях, связанных с вариантом использования, а затем свяжите тесты с каждым из этих комментариев.

  • Запишите инвариантные правила в комментариях на схемах классов или схемах деятельности и свяжите их с тестами.

  • Свяжите тесты со схемой деятельности или с отдельными действиями.

  • Свяжите набор тестов с компонентом или подсистемой, которую он тестирует.

  1. В Test Manager создайте требование и создайте на нем набор тестов.

    Требование, которое вы создаете, является рабочим элементом в Team Foundation Server. Это может быть рабочий элемент "История пользователя", "Требование" или "Вариант использования" в зависимости от шаблона процесса, используемого в проекте с Team Foundation. Дополнительные сведения см. в статье о средствах Agile и управлении проектами Agile.

  2. Свяжите рабочий элемент "требование" с одним или несколькими элементами в модели.

    На схеме моделирования щелкните правой кнопкой мыши элемент, комментарий или связь, а затем щелкните ссылку на рабочий элемент.

  3. Добавьте в набор тестов тестовые случаи, проверяющие требование, которое выражено в элементе модели.

Связанный контент