Частое тестирование на ранних этапах разработки

Перехват ошибок на ранних стадиях проекта представляет собой наименее затратный способ обеспечения качества программного обеспечения.Как пишут Кент Бек (Kent Beck) и Синтия Андрес (Cynthia Andres), "в разработке программного обеспечения существует следующая дилемма: дефекты обходятся дорого, но устранение дефектов также обходится дорого.Однако большинство дефектов в итоге превышают средства, которые были бы затрачены на их предотвращение". (Объяснен объект экстремального программирования: Изменение объятия Рекомендации) и средства могут помочь команде свернуть затраты и предотвращение исправлению ошибок, обслуживая качества проекта в течение своего жизненного цикла.

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

В данном разделе содержатся следующие рекомендации.

• Создавайте набор автоматических модульных тесто для каждого класса и для API каждого крупного компонента.Команда должна тратить около 40 % своего рабочего времени на создание модульных тестов.Дополнительные сведения см. в разделе Создание автоматических тестов с помощью Microsoft Test Manager.

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

• Создайте политики возврата, которые напоминают участникам команды о необходимости выполнить модульные тесты перед возвратом кода.Дополнительные сведения см. в разделе Add Check-in Policies.

• Настройте непрерывное или ночное построение, выполняющее полный набор тестов.

• Осуществляйте мониторинг тестового покрытия, чтобы обеспечить тестирование всего кода.Целевой показатель покрытия — не менее 70 %.Дополнительные сведения см. в разделе Отчет "Разрывы при тестировании" в формате Excel (гибкая разработка).

• Выполняйте ручные тесты в конце каждого спринта.

Используя интеграцию между Microsoft Test Manager, Visual Studio Application Lifecycle Management (ALM) и Visual Studio Team Foundation Server, команда может управлять тестовыми действиями и масштабировать их на ранних этапах проекта.Дополнительные сведения см. в разделе Тестирование приложения.

Содержание раздела

• Стратегия тестирования

• Планирование тестирования

• Приемочное тестирование

• Модульное тестирование

• Разработка через тестирование и раннее тестирование

• Ручное и автоматическое тестирование

• Отчеты о результатах тестирования

Стратегия тестирования

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

Факторы, требующие внимания при внедрении гибкого тестирования

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

Для применения гибких методов тестирования необходимо, во-первых, рассмотреть историю своего приложения и используемую командой систему.Методы гибкого тестирования можно применять как к новым, так и к существующим приложениям.С помощью Microsoft Test Manager можно создать план тестирования для проекта в целом и план тестирования для каждого спринта в проекте.Эти планы тестирования позволяют команде организовать тестовые случаи в наборы тестов, что облегчает назначение приоритетов выполняемым тестам и понимание их результатов.Дополнительные сведения см. в разделе Создание тестов для невыполненной работы по продукту, пользовательских историй или требований.С помощью Visual Studio ALM команда может группировать тестовые случаи в наборы тестов следующими способами:

• создание статической группы тестовых случаев и управление этой группой;

• использование запроса для создания динамической группы тестовых случаев (т. е. поиска тестовых случаев по приоритету) и управления этой группой;

• добавление описания функциональности пользователя или требования в тестовый план, тестовые случаи в котором связаны с требованием;

• копирование существующего набора тестов из другого плана тестирования.

Дополнительные сведения см. в разделе Группировка тестовых случаев в наборы тестов.

Во-вторых, команда должна принять во внимание тестируемость кода.Для этого необходимо иметь представление об архитектуре и шаблонах приложения.Если используются такие шаблоны, как Model View Controller (MVC), Model View ViewModel (MVVM) или Model View Presenter (MVP), можно изолировать определенные функции и выполнять функциональные тесты без негативного влияния тестирования пользовательского интерфейса.Однако в реальности такая ситуация имеет место не всегда.Например, нельзя изолировать функциональность частей приложения, подвергаемых рефакторингу, а к некоторым областям кода можно получить доступ только через пользовательский интерфейс или обработчики сетевых событий.Для значительного улучшения качества тестирования необходимо увеличить процент кода для тестирования.Дополнительные сведения об этих шаблонах см. в разделе ASP.NET Model View Controller (MVC).

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

Управление жизненным циклом тестирования

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

1. Поставьте четкие цели тестирования и согласуйте их со всеми участниками проекта.Основываясь на этих целях, определите свою стратегию тестирования.Например, можно использовать следующую стратегию: "Тесты должны выполняться перед каждым возвратом, покрытие модульных тестов должно составить 70 %, для каждого пользовательского описания функциональности необходимо создать хотя бы один автоматический тест".

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

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

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

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

5. Выполняйте наборы тестов и содержащиеся в них тестовые случаи на протяжении спринта.Начинайте выполнять тесты на ранних этапах спринта и продолжайте добавлять тестовые случаи в наборы тестов.Для идентификации важных тестовых условий и ситуаций можно применять произвольное тестирование и часто проводить беседы внутри команды.

6. Убедитесь, что все приемочные тесты для конкретного пользовательского описания функциональности были пройдены, прежде чем устанавливать статус Завершить.

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

• Код формирует построения.

• На код влияют определенные работы, планы тестирования и качество построений.

• На планы тестирования, наборы тестов и тестовые случаи влияют запланированные цели и другие аспекты проекта, не показанные на рисунке.

• Изменения в коде могут влиять на тестовые случаи.

Исправление ошибок

1. Необходимо как можно раньше исправлять ошибки.Серьезная ошибка не позволяет реализовать затронутые пользовательские описания функциональности.

2. Создавайте рабочие элементы ошибок для всех ошибок, обнаруженных на этапе тестирования или при выполнении других действий.Обозначьте важность ошибки, чтобы указать, насколько сильно она затрагивает пользовательские описания функциональности.Высокая важность ошибки (0 или 1) указывает, что не реализованы важные пользовательские описания функциональности или пользователям приходится выполнять значительную программную эмуляцию для получения этой функциональности.Низкая важность (например, 3) указывает, что пользователи все-таки могут решать поставленные задачи без дополнительных усилий.

3. Работайте с другими участниками команды для выработки плана действий по каждой ошибке.

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

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

Планирование тестирования

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

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

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

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

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

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

Определение приемочных тестов перед спринтом

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

Построение модульных тестов в ходе спринта

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

Концентрация тестирования на наиболее часто используемых областях

Для определения возможных критических областей необходимо понимать, какие места в ПО характеризуются высокой вариативностью.Пользовательский ввод, среда, в которой выполняется ПО, сеть и оборудование — примеры переменных конфигурации, позволяющих команде выявить в ПО критические области.Если условие возникает редко или если условий, которые могут иметь место во время теста, очень много, ценность теста снижается, за исключением случаев, когда дефект имеет очень серьезные потенциальные последствия.Как правило, желательно изолировать функциональность, когда это возможно.Также большую важность имеет тестирование ситуаций, имеющих значительное влияние на работу ПО.Дополнительные сведения об управлении конфигурациями с помощью Microsoft Test Manager см. в разделе Конфигурации тестов — указание платформ тестирования.

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

Приемочное тестирование

Приемочные тесты проверяют пользовательские описания функциональности.Эти тесты позволяют не только гарантировать успешное создание необходимого клиенту продукта на протяжении жизненного цикла проекта, но и установить доверительные отношения с клиентом и продемонстрировать принятую на себя ответственность.Дополнительные сведения см. на следующей веб-странице: Acceptance Test Engineering Guide.

Начало приемочного тестирования

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

Миграция от ручных тестов к автоматическим

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

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

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

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

Ручные тесты, определенные в начале спринта, могут помочь в создании автоматических тестов.И с ручными, и с автоматическими тестами связаны определенные затраты, поскольку ручные тесты должны выполняться человеком, а автоматические тесты необходимо обновлять при изменении кода или ситуации взаимодействия пользователя с ПО.Дополнительные сведения см. в разделе Ручное и автоматическое тестирование далее в этом разделе.

Кто выполняет приемочные тестовые случаи

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

С помощью Microsoft Test Manager команда может, выполняя каждый приемочный тестовый случай, делать видеозапись экрана с результатами теста.Таким образом можно получить визуальный "протокол" результатов тестов, а также предъявлять результаты клиентам.Этим удобно пользоваться, когда создавать требуемые конфигурации (например, многосерверные конфигурации) затруднительно.

Определение приемочных тестовых случаев и пользовательских описаний функциональности

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

Модульное тестирование

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

Роль модульных тестов в эволюции структуры приложения

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

Организация модульных тестов

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

Управление вариативностью модульных тестов без внесения изменений в тестовый код

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

Visual Studio Professional Test предоставляет возможности для написания модульных тестов и закодированные тесты пользовательского интерфейса.Дополнительные сведения см. в разделах Практическое руководство. Создание модульного теста, управляемого данными и Практическое руководство. Создание закодированного теста пользовательского интерфейса, управляемого данными.

Разработка через тестирование и раннее тестирование

Разработка через тестирование (test-driven development, TDD) — это дисциплина проектирования и программирования, согласно которой каждая строка кода пишется в ответ на тест, написанный программистом непосредственно перед кодированием."Стать потребителем реализуемого кода" — очень мощная концепция, позволяющая поддерживать у разработчика реалистичные ожидания в отношении того, как будет использоваться и как должен быть спроектирован код.

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

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

2. Убедитесь, что новый тест дает сбой, чтобы проверить, что он работает.

3. Создайте код, который позволит пройти тест.

4. Выполните тест, чтобы убедиться в его успешном завершении.

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

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

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

8. Осуществите возврат кода реализации и модульных тестов.

Команды, заинтересованные в преимуществах методов раннего тестирования, могут начать с создания ручных тестов (или ручных приемочных тестов).Эти ручные тесты можно автоматизировать путем создания закодированного теста пользовательского интерфейса.Дополнительные сведения см. в разделе Практическое руководство. Создание закодированного теста пользовательского интерфейса путем записи тестируемого приложения. Для проверки реализуемой функциональности также можно создавать интеграционные тесты, основанные на платформе модульных тестов Visual Studio ALM.Группы тестовых случаев, создаваемые на ранних этапах итерации, выполняются на ранних этапах итерации — для проверки функциональности и для поиска ошибок.Эти наборы тестов и тестовые случаи можно продолжить выполнять в качестве тестов регрессий в течение всего жизненного цикла проекта.Это позволяет убедиться, что ошибки, найденные на ранних этапах итерации, и проверенная тогда же функциональность не были затронуты изменениями, внесенными в проект позднее.

Использование модульных тестов для непрерывной интеграции

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

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

Использование виртуализации для управления тестовыми конфигурациями

Для выполнения модульных тестов можно создать набор сред управляемых hyper-v изображения в Microsoft Test Manager. Дополнительные сведения о выполнении автоматических тестов из плана тестирования с помощью Microsoft Test Manager см. в разделе Практическое руководство. Выполнение автоматических тестов в лабораторной среде с помощью Microsoft Test Manager.

Ручное и автоматическое тестирование

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

Существует несколько факторов, которые следует учитывать при принятии решения о распределении ручных и автоматических тестовых случаев.

Влияние навыков заинтересованных лиц на распределение типов тестов

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

Участники команды, работающие с кодом, могут создавать закодированные тесты пользовательского интерфейса, основанные на ручных тестах или не зависящие от каких-либо других тестов.Для получения дополнительной информации см. How to: Generate a Coded UI Test by Recording the Application Under Test.Закодированный тест пользовательского интерфейса сохраняются участниками команды, имеющие возможность управлять и разрабатывать код проекта.

Преобразование ручных тестов в автоматические тесты или создание автоматических тестов с самого начала

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

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

Типы тестов, всегда проводимых автоматически

Модульные тесты

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

Нагрузочные тесты

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

Дополнительные сведения о нагрузочном тестировании с помощью Visual Studio ALM см. на следующей странице веб-сайта Майкрософт: Основные сведения о нагрузочных тестах.

Тесты непрерывной интеграции

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

Типы тестов, которые могут быть автоматизированы

Конфигурационные тесты

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

Тесты пользовательского интерфейса

В Visual Studio ALM предусмотрены возможности создания автоматических тестов непосредственно для пользовательского интерфейса.Дополнительные сведения о создании закодированных тестов пользовательского интерфейса см. в разделе Практическое руководство. Создание закодированного теста пользовательского интерфейса.

Тесты установки

С помощью лабораторных возможностей Microsoft Test Manager можно настроить набор конфигураций для проверки правильности работы программ установки разрабатываемых приложений.

Возможные препятствия автоматизации

Возможности команды

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

Дополнительные сведения о создании автоматических тестов с помощью Visual Studio Professional Test см. в разделе Создание автоматических тестов с помощью Microsoft Test Manager.

Обновление кода

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

Проектирование кода

Платформы разработки кода, такие как MVC и MVVM в ASP.NET, помогают участникам команды писать код со степенью изоляции, необходимой для проверки различных частей кода.Код, тесно привязанный к пользовательскому интерфейсу, сложно тестировать, поскольку это может требовать взаимодействия пользователя с элементами управления пользовательского интерфейса.

Преимущества ручных тестовых случаев

Ручные тестовые случаи обеспечивают следующие преимущества.

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

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

• Начинать писать ручные тестовые случаи очень легко на ранних этапах проекта, еще до написания какого-либо кода.Это важно в процессе определения приемочных тестов.

• При использовании Visual Studio Professional Test, тестовых случаев может состоять из общих шагов, которые помогут сэкономить время, аналогичные тесты и позволяют команде для повторного использования в одну версию подмножества теста.Использование общих шагов также упрощает изменение тестовых случаев, поскольку при внесении изменения в общие шаги автоматически изменяются все тестовые случаи, в которых фигурируют эти шаги.Дополнительные сведения о создании и использовании общих шагов см. в разделе How to: Share Common Test Case Steps Using Shared Steps;

• Ручные тестовые случаи могут служить в качестве средства коммуникации на ранних этапах проекта или спринта.

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

• при использовании Visual Studio ALM при выполнении ручных тестов можно собирать метрики покрытия кода.

Недостатки ручных тестовых случаев

Ручным тестовым случаям свойственны следующие недостатки:

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

• выполнение наборов тестов, включающих ручные тестовые случаи, требует, чтобы человек физически выполнял шаги тестов и отчитывался о результатах.Этот процесс может занимать немало времени и, следовательно, может потребовать либо увеличения количества участников команды, занимающихся тестами, либо увеличения времени, затрачиваемого на выполнение набора тестов.С помощью Visual Studio Professional Test, команда может использовать "перемотка вперед ручное тестирование", в которые записываются действия во время тестирования, который затем можно выполнить в последующих тестовых запусках.

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

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

Преимущества автоматических тестовых случаев

Автоматические тестовые случаи обеспечивают следующие преимущества:

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

• автоматические тесты могут выполняться без участия человека;

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

• автоматические тесты можно запускать на нескольких конфигурациях с помощью Microsoft Test Manager;

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

Недостатки автоматических тестовых случаев

Автоматическим тестовым случаям свойственны следующие недостатки.

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

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

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

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

Отчеты о результатах тестирования

С точки зрения гибкой разработки формирование отчетов и запрашивание в Team Foundation Server текущего уровня качества (в виде количества ошибок или агрегированных метрик) — это часть цикла обратной связи, позволяющего команде проводить итерации и вносить изменения в код, план проекта и план тестирования.Для получения дополнительной информации см. Отчет "Ход выполнения плана тестирования".

Также можно отследить ход выполнения плана тестирования с помощью функции результатов плана тестирования в Microsoft Test Manager.Результаты плана тестирования включают диаграммы и числовые статистические данные по, без изменений, переданных с ошибкой, и активных тестов.Кроме того, результаты плана тестирования включают подробные диаграммы, указывающие типы сбоев и данные разрешения.Результаты плана тестирования можно фильтровать для включения или исключения определенных наборов тестов в плане тестирования.Также можно просматривать результаты для отдельных тест-инженеры в команде тестирования.Для получения дополнительной информации см. Практическое руководство. Просмотр результатов плана тестирования с помощью диспетчера Microsoft Test Manager.

Уровни тестирования, отчеты о результатах которых должна получать команда

С помощью Visual Studio Test Professional и Team Foundation Server, команда может понять состоянии планирования и выполнения тестов.В Team Foundation Server осуществляется хранение планов тестирования, наборов тестов, тестовых случаев, результатов тестов и прочих связанных данных, создаваемых в процессе тестирования.Можно визуализируют процесс тестирования и проверки качества при одновременном использовании Microsoft Test Manager с отчетом и запросами рабочего элемента в Team Foundation Server. Можно использовать Microsoft Test Manager для запроса для ошибок во многих различных состояниях.Ошибки, помеченные другими участниками команды как исправленные, должны находиться в состоянии "Разрешено".Для проверки исправленных ошибок можно использовать последующие построения.Сведения о проверке исправления ошибки см. в разделе Практическое руководство. Проверка исправленных ошибок с помощью Microsoft Test Manager.