Критерии покрытия кода программы тестами

– критерий, отображающий добротность тестирования. Характеризует полноту охвата тестами программного кода либо требований к нему.
Основной подход к оцениванию – формирование тестового пула. Значение тестового покрытия кода находится в прямой зависимости от количества отобранных вариантов проверки к нему.
Многозадачность и универсальность современного софта обусловливает невозможность организации тестового покрытия с показателем в 100%. Так что для максимального охвата тестируемого кода, разработаны особые приёмы и инструменты.
Существуют три подхода для оценки качества и выражения тестового покрытия в численном представлении в зависимости от области проверки: покрытие требований, покрытие кода и покрытие на базе анализа потока управления. Подробнее о каждом.

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

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

Net Core Unit Testing. Code coverage (покрытие кода)

Результат выражается в процентах.

Расшифровка переменных:
Tcov — тестовое покрытие;
Lcov – число отобранных для тестирования требований;
Ltotal – полное число заявленных требований.

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

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

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

Tcov = (Ltc/Lcode) * 100%
Результат выражается в процентах.

Переменные:
Tcov – тестовое покрытие;
Ltc – число охваченных проверкой строк кода;
Lcode – суммарное количество строк кода.

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

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

Вкатываемся в тестирование кода

Тестирование потоков управления (Control Flow Testing)

О метриках тестирования: code coverage для тестировщиков

Как известно из книги «Путеводитель для путешествующих автостопом по галактике», ответ на главный вопрос жизни, вселенной и всего такого — 42. Процент покрытия кода по линиям на одном из моих проектов — 81, дает ли эта цифра ответ на главный вопрос тестирования «cколько тестов достаточно для определения качества продукта»?

В течении своей работы в айти-сфере и тестировании я видела мало команд и проектов, где тестировщики реально используют code coverage в своей работе. Связано это на мой взгляд с двумя вещами:

1. Тем, что тестируем мы прежде всего требования;
2. Далеко не все понимают, как считать и использовать покрытие.

Интересующимся предлагаю свой взгляд на эти 2 пункта.

Требования vs код

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

Пример 1

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

Что значит невозможно выполнить операцию?

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

Это значило, как минимум, следующие случаи:
1. Соединение с сервером БД не может быть установлено;
2. Соединение с сервером БД установлено, выполнение запроса вызвало оракловую ошибку;
3. Соединение с сервером БД было установлено, запрос начал выполняться и завис — тут был баг. Приложение ждало ответа примерно минут 5, потом в логи летел эксепшн и больше оно эти данные записать не пыталось.

Пара остальных не стоило внимания по разным причинам.

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

Пример 2

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

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

Покрытие = 80. А качество?

Количество не означает качество. Оценка покрытия кода напрямую не связана с качеством продукта, но связана опосредованно.
На одном отчетном совещании я заявила, что покрытие кода у нас увеличилось до 82% по линиям и 51% по условиям, после чего руководством мне был задан вопрос: «А что это значит? Это хорошо или плохо?» Закономерный вопрос, действительно: сколько надо, чтобы было хорошо?

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

К вопросу об «это нормально»: качественная оценка непокрытого кода и ведет в моем понимании к адекватному использованию code coverege. Смотреть важно то, что вы не покрыли, а не сколько. Если это java-код и методы toString(), equals() или ветви с exception, которые сложно воспроизвести интеграционно, ну так и ладно, пусть будет 80% покрытия реальной бизнес-логики. «Лишний» код многие инструменты умеют фильтровать и не считать.
Если сомнения в белых пятнах все-таки остаются, возможно посчитать общее покрытие интеграционными тестами и юнит — разработчики наверняка учли многое что труднодоступно для интеграционных тестов.

Однако есть одно «но». Что, если покрытие кода низкое? 20%, 30%? Где-то я читала забавный факт, что покрытие 50% и меньше (по линиям и условиям, как мне помнится) означает тот уровень тестового покрытия, при котором результат работы приложения будет такой же, как и при отсутствии тестирования вообще. Т.е. там могут быть баги, может не быть багов, с тем же успехом вы могли его и не тестировать.

Другое объяснение — много мертвого кода, что маловероятно.

А у нас нет автотестов

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

А смысл?

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

Разберем по порядку, куда конкретно нужно будет потратить ресурсы, если вы решите попробовать считать code coverage:

1. Выбор тула, подходящего под ваше приложение
2. Инструментирование билдов (в том числе конфигурация code coverage тула и фильтация «ненужного» для оценки кода)
3. Построение отчета о покрытии после прогона тестов
4. Анализ покрытия

Пункты 1 и 2 можно отдать разработчикам, могие из них знакомы-слышали-встречались с общеизвестными тулами и тем более смогут построить собственный билд. Построение отчетов, как правило, делается одной командой в командной строке или автоматически, если вы используете CI (у меня это делал jenkins, он же публиковал отчет).
Самое затратное — это четвертый пункт. Основная трудность тут в том, что для адекватной оценки надо уметь читать код, либо садиться рядом с разработчиком, чтобы он объяснял, что значит этот кусок, и как это воспроизвести. Это требует определенной квалификации от тест-инженера и рабочего времени 1 или 2 человек.

Стоит ли оно того — решать команде и ее руководителям. В проектах, где требования слабо формализованы, либо баги возникают необъяснимым для тестеров образом, возможно это может помочь хотя бы понять направление куда копать.
Еще одна категория — проекты, которые предполагают очень hight-level black box тестирование. Это прежде всего тестирование через UI или внешний API систем, внутри которых содержится куча логики, работающей по своим законам, т.е. извне вы не можете ее затронуть или ей управлять, а значит не можете нормально протестировать. Анализ покрытия в таких проектах создаст аргументированную необходимость переходить к более «низким» уровням тестирования: модульным, покомпонентным, тестированию на заглушках и т.п.
Хорошо работает накопленное покрытие кода в цифрах: на графиках можно увидеть моменты, когда вливается новый код, а тесты еще не подоспели; если уровень покрытия был высоким, потом стал снижаться, но предыдущего уровня так и не достиг — где-то может быть хорошее белое пятно недошедших до тестирования требований, и т.д.

Пожалуй, это все, что я хотела сказать на сегодня.

Напоследок limitations и out of scope

1. Я постаралась описать в общих словах подход к этом вопросу, не вдаваясь во многие технические подробности. Говоря о «покрытии» 80% я говорю о неком общем или усредненном покрытии, не имея в виду конкретных метрик — покрытия линий, условий и проч. Выбор конкретных метрик — это отдельный интересный вопрос.
2. Мой опыт в основном связан с java-кодом и инструментами для него, я не работала в этом ключе с другими технологиями, знаю, что есть тулы для C++, но пока попробовать их в деле не удалось.
3. Серьезный анализ покрытия стоит проводить на стабильных билдах и стабильно работающих тестах, иначе сложно будет сказать что явилось причиной пропусков- упавшие тесты, критичные баги или действительно что-то пропущено

• тестирование
• code coverage
• метрики тестирования

Источник: habr.com

Что такое тестовое покрытие (test coverage)?

Какой была ваша первая зарплата в QA и как вы искали первую работу? Мега-обсуждение в нашем телеграм-канале.

Определения

Тестовое покрытие (test coverage) — количественная мера плотности покрытия требований или кода. Покрытие требований выражается в процентном отношении покрытых требований к их общему количеству.

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

Тестовое покрытие vs покрытие кода

Эти понятия часто путают, ввиду их логической близости. Однако:

• Покрытие кода тестами чаще относится к юнит-тестированию; показывает, насколько юнит-тесты покрывают все части кода; за покрытие кода отвечают разработчики
• Тестовое покрытие обычно подразумевает тестирование требований (хотя бы по одному разу); тестовое покрытие — сфера ответственности тестировщиков

Покрытие кодаТестовое покрытие (покрытие требований)

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

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

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

Иногда считается, что требование покрыто, если хотя бы один тестировщик задействован в его тестировании. Или, если выполнены все тест-кейсы, связанные с этим требованием.

Виды тестового покрытия

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

Если 80 тестов написано и всего 6 требований «отработаны» ими — то, хотя 80% объема тестирования выполнено, 4 требования остались не покрыты. Это покрытие уровня выполнения.

Если лишь 90 тестов, относящихся к 8 из 10 требований, имеют прикрепленных тестировщиков, значит тестовое покрытие по прикреплению составляет 80% (8 из 10 требований).

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

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

Цели

• Определить требования, не покрытые тест-кейсами
• Создать новые и более качественные тест-кейсы
• Создать количественные метрики покрытия как непрямой техники контроля качества (и оценки работы тестировщиков)
• Определить «бесполезные» тест-кейсы, не повышающие покрытие

Как повышается тестовое покрытие

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

Преимущества тестового покрытия

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

Недостатки

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

Хорошие практики

• Команда должна хорошо понимать масштаб проекта и его состояние в данный момент
• Применять матрицу отслеживания требований (RTM)
• Тщательно контролировать присвоение задач и их выполнение

Как обеспечить оптимальное тестовое покрытие

• Каждый тестировщик в QA-команде должен быть заранее информирован о требованиях и будущих процедурах
• Придерживаться приоритетов и сосредоточиться на главном
• Знать, что изменилось в новом релизе, чтобы отработать эти изменения
• Постоянно совершенствовать автоматизацию в проекте
• Умело пользоваться средствами управления тестированием (test management systems)
• Распределение задач — направить лучших тестировщиков на важные задачи; а неопытных новичков на второстепенные
• Делать чеклисты задач (и других активностей) при нехватке времени (то есть всегда)
• Если команда работает по DevOps/Scrum/BA, плотнее общаться с разработчиками
• Поддерживать порядок в системе управления тестированием и баг-трекинговой системе

Еще советы

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

О типах тестового покрытия с практической точки зрения

Покрытие продукта

В этом подходе внимание команды сфокусировано на том, какие части продукта были протестированы, а какие остались.

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

Пример 2. Тестируют продукт — приложение Блокнот для ПК. Есть требования:

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

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

Покрытие рисков

Немаловажный аспект в QA: продукт не может считаться протестированным с точки зрения покрытия рисков, пока они не устранены.

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

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

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

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

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

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

Формула тестового покрытия

В общем случае, нужно две вещи:

• Количество строк исходного кода
• Количество строк кода, покрытых тест-кейсами

Нужно поделить второе на первое и умножить на 100. Эта простая «древняя» формула дает понятие о тестовом покрытии. Например, если есть 100 строчек кода компонента, и 50 строчек покрыты имеющимися тест кейсами, тестовое покрытие составляет 50%.

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

Выше видим тестовое покрытие в репорте.

Инструменты оценки тестового покрытия

ИнструментЧем хорош

Smartbear Zephyr	Легкая интеграция с Jira, Jenkins, Confluence
Xray	Автоматизированная матрица сверки требований
TestRail	Опции сравнения результатов в разных тестовых окружениях
PractiTest	Реюзабельность, настраиваемый интерфейс
ReQTest	Уведомления по назначению дефектов
TestPad	Удобная работа с тестовыми артефактами
TestMonitor	Простой интерфейс и управление тестированием, особенно дефектами
Qase	Быстрый
TestLink	Удобное управление и логи событий по каждому действию с тестовыми артефактами
Tarantula	Матрица отслеживания с показом причин задержки по отдельному дефекту

Источник: testengineer.ru