уровень покрытия кода тестами показывает

Тестирование

Раздел: Тестирование > Тест дизайн > Тестовое Покрытие

Тестовое Покрытие (Test Coverage)

Если рассматривать тестирование как «проверку соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов», то именно этот конечный набор тестов и будет определять тестовое покрытие:

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

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

Существуют следущие подходы к оценке и измерению тестового покрытия:

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

Покрытие требований (Requirements Coverage)

Расчет тестового покрытия относительно требований проводится по формуле:

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

Покрытие кода (Code Coverage)

Расчет тестового покрытия относительно исполняемого кода программного обеспечения проводится по формуле:

В настоящее время существует инструментарий (например: Clover), позволяющий проанализировать в какие строки были вхождения во время проведения тестирования, благодаря чему можно значительно увеличить покрытие, добавив новые тесты для конкретных случаев, а также избавиться от дублирующих тестов. Проведение такого анализа кода и последующая оптимизация покрытия достаточно легко реализуется в рамках тестирования белого ящика (white-box testing) при модульном, интеграционном и системном тестировании; при тестировании же черного ящика (black-box testing) задача становится довольно дорогостоящей, так как требует много времени и ресурсов на установку, конфигурацию и анализ результатов работы, как со стороны тестировщиков, так и разработчиков.

Тестовое покрытие на базе анализа потока управления

Фундаментом для тестирования потоков управления является построение графов потоков управления (Control Flow Graph), основными блоками которых являются:

Для тестирования потоков управления определены разные уровни тестового покрытия:

Таблица 1. Уровни тестового покрытия

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

[1] A practitioner’s Guide to Software Test Design. Lee Copeland

[2] Стандартный глоссарий терминов, используемых в тестировании программного обеспечения Версия 2.0 (от 4 декабря 2008), Подготовлен ‘Glossary Working Party’ International Software Testing Qualifications Board

Источник

Понятие тестового покрытия

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

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

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

Подобные критерии в сфере тестирования программного обеспечения именуются QA метриками.

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

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

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

Тестовое покрытие — это «плотность» покрытия тестами выполняемого программного кода ПО или требований к нему.

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

Но, стоит понимать, что до полного покрытия «дойти» не выйдет, поскольку протестировать все 100% наполненности ПО никогда не получится!

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

Разберем каждый подход по отдельности.

Покрытие требований

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

Данная метрика исчисляется по следующей формуле: Тестовое покрытие = (количестов требований, покрытых тест-кейсами/общее количество требований)x100%.

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

Каждая взаимосвязь, создающаяся между тест-кейсами и пунктами требований, именуется матрицей трассировки.

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

Есть требования, которые могут содержать лишние тест кейсы.

Покрытие программного кода

Следующая метрика основана на демонстрации того, сколько строк программного кода могут задействоваться во время процесса запуска тест-кейсов.

Логика метрики обсчитывается по такой формуле: Тестовое покрытие = (количество строк кода, покрытых тест-кейсами/общее количество строк кода)x100%.

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

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

Проверочное покрытие на основе проанализированных данных потока управления

Еще один метод тестирования ПО с полноценным доступом к программному коду, но он помогает выполнить проверку путей внедрения программы.

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

Для того, чтобы проверить потоки управления, стоит выстроить их график, так называемый Control Flow Graph.

Итоги

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

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

Источник

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

Чтобы определить, какая часть кода проекта в действительности тестируется закодированными тестами, такими как модульные тесты, можно воспользоваться возможностью покрытия кода в Visual Studio. Для обеспечения эффективной защиты от ошибок тесты должны выполнять («покрывать») большую часть кода.

Анализ покрытия кода может применяться и к управляемому (CLI), и к неуправляемому (машинному) коду.

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

Требования

Функция проверки объема протестированного кода доступна только в выпуске Visual Studio Enterprise.

Анализ покрытия кода

В меню Тестирование выберите Анализ покрытия кода для всех тестов.

Анализ объема протестированного кода также можно запустить из окна средства обозревателя тестов.

Чтобы изменить цвета или использовать полужирный шрифт, последовательно выберите Сервис > Параметры > Среда > Шрифты и цвета > Параметры для: текстовый редактор. В разделе Отображаемые элементы настройте параметры для элементов покрытия, например Области вне покрытия кода.

Если результаты показывают низкое покрытие, проверьте, какие части кода не обрабатываются, и напишите несколько дополнительных тестов для их покрытия. Команды разработчиков обычно стремятся покрыть около 80 % кода. В некоторых случаях допустимо более низкое покрытие. Например, более низкое покрытие допустимо, когда некоторый код создается из стандартного шаблона.

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

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

Отчеты в блоках или строках

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

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

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

Управление результатами по объемам протестированного кода

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

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

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

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

Чтобы просмотреть результаты предыдущего сеанса, щелкните Импортировать результаты покрытия кода, перейдите к папке TestResults в своем решении и импортируйте файл COVERAGE.

Цвета отображения покрытия могут быть неверными, если исходный код был изменен с момента создания файла COVERAGE.

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

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

Объединение результатов различных запусков

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

Например, предположим, что при выполнении теста со входными данными «2» обнаружилось, что покрыто 50 % определенной функции. А при повторном выполнении теста со входными данными «-2» вы видите, что проверены остальные 50 % функции. Теперь можно объединить результаты двух тестовых запусков, чтобы в отчете и представлении расцветки покрытия было видно, что покрыто 100 % данной функции.

Щелкните Экспортировать результаты покрытия кода, чтобы сохранить результаты операции слияния.

Ограничения объединения

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

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

При объединении результатов тестов проекта ASP.NET результаты отдельных тестов будут отображаться, но не объединяться. Это относится только к самим артефактам ASP.NET: результаты всех других сборок будут объединяться.

Исключение элементов из результатов покрытия кода

Иногда требуется исключить конкретные элементы в коде из результатов покрытия, например, если код создан из текстового шаблона. Добавьте атрибут System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute в любой из таких элементов кода: класс, структура, метод, свойство, метод задания свойства или метод получения свойства, событие.

Исключение класса не исключает его производные классы.

Исключение элементов в машинном коде C++

Чтобы исключить неуправляемые (машинные) элементы в коде C++, используйте следующий код.

Используйте следующие макросы:

ExclusionName — любое уникальное имя.

FunctionName — полное имя функции. Оно может содержать знаки подстановки. Например, чтобы исключить все функции класса, напишите MyNamespace::MyClass::*

SourceFilePath — локальный путь или путь UNC к CPP-файлу. Оно может содержать знаки подстановки. В следующем примере исключаются все файлы из определенного каталога: \\MyComputer\Source\UnitTests\*.cpp

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

Исключения можно поместить в файл кода модульного теста или в файл кода приложения.

Чтобы исключить функции в коде C++/CLI, примените атрибут [System::Diagnostics::CodeAnalysis::ExcludeFromCodeCoverage] к функции. Эта процедура не отличается от C#.

Включение или исключение дополнительных элементов

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

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

Анализ покрытия кода в Azure Pipelines

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

Анализ объема протестированного кода в командной строке

Для выполнения тестов из командной строки используйте vstest.console.exe. Объем протестированного кода является параметром служебной программы vstest.console.exe.

Запустите командную строку разработчика Visual Studio.

В ОС Windows в меню Пуск выберите Visual Studio 2017 > Developer Command Prompt for VS 2017 (Командная строка разработчика для VS 2017).

В ОС Windows в меню Пуск выберите Visual Studio 2019 > Developer Command Prompt for VS 2019 (Командная строка разработчика для VS 2019).

В командной строке выполните следующую команду:

Диагностика

Если вы не видите результаты проверки объема протестированного кода, см. статью Устранение неполадок в объеме протестированного кода.

Источник

Покрытие программного кода

19.1. Проверка домашнего задания

19.2. Понятие покрытия

19.2.1. Покрытие программного кода

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

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

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

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

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

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

19.2.2. Уровни покрытия

19.2.2.1. По строкам программного кода (Statement Coverage)

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

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

Другой особенностью данного метода является зависимость уровня покрытия от структуры программного кода. На практике часто не требуется 100% покрытия программного кода, вместо этого устанавливается допустимый уровень покрытия, например 75%. Проблемы могут возникнуть при покрытии следующего фрагмента программного кода:

19.2.2.2. По веткам условных операторов (Decision Coverage)

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

В отличие от предыдущего уровня покрытия данный метод учитывает покрытие условных операторов с пустыми ветками.

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

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

полное покрытие по веткам может быть достигнуто при помощи двух тестовых примеров:

Источник