Как тестировать только то что нужно

в 8:30, , рубрики: Visual Studio, visual studio 2013, Блог компании Microsoft, тестирование, метки:

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

Инструментальная обработка кода и Test Impact.

Изменения, которые программисты вносят в код приложения, при наличии системы контроля версий и процесса непрерывной интеграции, могут быть четко идентифицированы. При этом если проводить тесты от билда к билду, то благодаря анализу информации Code Coverage ручных тестов и ее сохранению для каждого пройденного тестового плана, мы можем четко предсказать то какой тест сломался, а какие тесты вообще не затронуты изменениями, которые внесли программисты. Это на первый взгляд весьма фантастично, но тем не менее уже работает в связке с Team Foundation Server 2013 и Microsoft Test Manager 2013.

Подробный сценарий, чтобы все стало понятно.

Рассмотрим на примере калькулятора подробный сценарий. В Microsoft Test Manager у нас определен основной тестовый план, и для каждого PBI соответствующие тесты функций:
Как тестировать только то что нужно

В настройках тестов обязательно указано что при прогоне тестов у нас будет проводится анализ Test Impact:
Как тестировать только то что нужно

Дополнительно обязательно укажем эту же опцию в правилах сборки билда:
Как тестировать только то что нужно

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

У нас в плане 4 теста, умножение, деление, вычитание и сложение. В окне результатов видим что мы проверили все фичи нашего калькулятора и прошли все тесты плана:
Как тестировать только то что нужно

Вносим изменения в код

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

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

Помимо информации в отчете, тестировщик так же может получить список затронутых тестов прямо в Microsoft Test Manager. Прежде чем получить список рекомендованных тестов, назначим тестовому плану новый билд. При этом нам будет дана рекомендация по анализу перечня рекомендованных тестов:
Как тестировать только то что нужно

При этом у тестировщика есть возможность делать анализ рекомендованных тестов от билда к билду:
Как тестировать только то что нужно

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

Автор: dmandreev

Источник

Поделиться

* - обязательные к заполнению поля