Руководство по инструментам архитектуры Visual Studio. Сценарий – мне необходимо выполнить валидацию архитектуры системы

Валидация архитектуры системы

Увеличить

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

Этот сценарий проверки можно разделить на три отдельные слабо связанные сценария:

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

Валидация UML модели

Соображения

Каждый этап процесса разработки имеет свои собственные цели тестирования и глубину тестового покрытия. Глубина особенно зависит от рисков: высокая вероятность ошибок требует лучшего тестового покрытия.

Цели тестирования особенно направленны на выявление ошибок, которые могут быть найдены в каждой фазе («как можно скорее»).

• Во время модульного тестирования проверяется внутренняя логика модуля.
• Интеграционные системные тесты должны показать, что модули «понимают» друг друга.
• Системные тесты должны продемонстрировать, что система соответствует функциональным требованиям, которые были согласованы.
• Наконец, приемо-сдаточные тесты рассматривают, как система вписывается в среду, в которой она будет работать.

Смотрите также Acceptance Test Guidance of the Patterns and Practices Group для дополнительной информации.

Среды валидации

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

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

Увеличить

Валидация архитектуры

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

Для получения дополнительной информации см.  Use Cases and Testing Ли Коупленда.

Записывайте ваши ошибка как рабочий элемент Ошибка в TFS.

«Бизнес тесты, которые направляют разработку системы являются системными приемочными тестами (также известными как тесты заказчика). Эти тесты разрабатываются на основе требований и само написание этих тестов может определить отсутствующие или неоднозначные требования. Когда мы (владелец продукта часто вместе с кем-то из команды разработчиков продукта) готовим эти тесты до начала разработки, мы можем быть уверены, что команда разработчиков продукта понимает, что им нужно разработать. Это известно, как Acceptance Test-Driven Development.

См.  Разработка тестов из модели в библиотеке MSDN для получения дополнительной информации.

Пошаговое руководство

В этом сценарии хорошей отправной точкой для тестирования являются варианты использования, которые описывают различные субъекты и как они используют систему для достижения конкретных целей. Модель вариантов использование, которая представлена в Visual Studio 2012 в UML Model Explorer, обеспечивает четкое видение всех субъектов и варианты использования в проекте. Это идеальное место, с которого можно начать проверку.

UML Model Explorer

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

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

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

В качестве примера проверки синтаксиса варианта использования: вы можете проверить, что имя каждого варианта использования является целью основной субъекта, выраженной в виде фразы в активной форме.

Увеличить

Проверка вариантов использования

В вышеприведенной диаграмме вариантов использования имя диаграммы является непрозрачным. Имя варианта использования следует писать как цель основного субъекта в активной форме. Как мы видим, что это явно не так, и поэтому тестировщик должен зарегистрировать ошибку в этом варианте использования. В Visual Studio 2010 мы можем сделать это, выполнив следующие действия:

• Выберите вариант использования
• Щелкните правой кнопкой мыши
• Выберите создать новый рабочий элемент Ошибка
• Заполните информацию об ошибке.

Увеличить

Создание рабочего элемента, связанного с вариантом использования

В результате будет форма ошибки, пример которой приведен ниже:

Увеличить

Новый рабочий элемент Ошибка

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

Использование UML-модели для тестирования

Соображения

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

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

В Microsoft Visual Studio Ultimate можно использовать требования и модели архитектуры, чтобы помочь вам организовать тесты для вашей системы и ее компонентов. Эта практика помогает обеспечить проверку требований, которые важны для пользователей и других заинтересованных сторон, и поможет вам быстро обновлять тесты при изменениях требований. Если вы используете Microsoft Test Manager, вы также можете поддерживать связи между моделями и тестами.

Как описано в приведенной выше цитате из библиотеки MSDN, можно связать тестовые сценарии, созданные в Microsoft Test Manager, к UML-модели Visual Studio.

Валидация ключевых принципов проектирования и соображения

Соображения

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

Одной из очень хорошей отправной точкой для архитектурных проверок будет Microsoft P&P Application Architecture Guide 2.0. Это руководство содержит контрольные списки, которые определяют некоторые основные принципы и наилучшие практики прочного архитектурного дизайна.

Некоторые из этих правил, которые мы можем найти в этом руководстве, это:

• Разделение проблем
• Принцип персональной ответственности
• Принцип уменьшения знания
• Не повторять себя
• Минимизировать авансовый дизайн
• Держите шаблоны проектирования непротиворечивыми в каждом слое.
• Не дублировать функциональность в приложении.
• Предпочитать композицию наследованию
• Создать стиль кодирования и именования для разработки
• Использование абстракция для реализации слабой связанности между слоями.
• Быть четким в коммуникации слоев друг с другом
• Не смешивать различные типы компонентов в одном и том же логическом слое
• Держать пересекающийся код максимально абстрагируемым от бизнес-логики приложения

Валидация слоев

Хотя не все выше упомянутые архитектурные проверки могут проверяться на основе диаграммы слоя (или UML-диаграммы в Visual Studio) существует множество архитектурных проверок, которые могут.

Ручная валидация проектирования системы

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

Увеличить

Диаграмма компонентов

Когда мы имеем обе из этих конструкций в одном месте, функциональное и компонентное проектирование, мы можем воспроизводить деятельность через интерфейсы диаграммы компонентов. Это обеспечивает путь валидации выше упомянутых принципов дизайна. Визуализация этого потока через интерфейсы компонентов в схеме последовательности дает нам хорошее описание для валидации и коммуникации. Из схемы компонентов в Visual Studio можно создать линии жизни из компонентов:

Увеличить

Диаграмма последовательности

На рисунке ниже показана ручная валидация проектирования:

• Используемые сценарии можно найти на диаграмме вариантов использования  , которые описывают действия, которые происходят на/в системе.
• Диаграмма активности  может использоваться для визуализации сценариев, которые могут быть основаны на схеме вариантов использования как своего рода реализация варианта использования. Тестировщики используют диаграмму активности для разработки тестовых сценариев с помощью техник проектирования тестов для создания нужного количества и типов для этих сценариев. Эти же сценарии можно использовать для проверки нашего проектирования компонентов, который закрывает общий цикл.
• Диаграмма компонентов  является статическим представлением вашей системы, тогда как диаграмма последовательности является динамическим. Диаграмма последовательности визуализирует поток и последовательность действий, которые происходят в системе.
• Диаграммы последовательности может использоваться для валидации системы и проектирования компонентов, принимая сценарий, сценарий требования и создавая последовательность действий в диаграмме последовательности  .

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