Тестовое покрытие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tcov = (Lcov/Ltotal) * 100%

где: Tcov  - тестовое покрытие Lcov  - количество требований, проверяемых тест кейсами Ltotal  - общее количество требований

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

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

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

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

Tcov = (Ltc/Lcode) * 100%

где: Tcov  - тестовое покрытие Ltc  - кол-ва строк кода, покрытых тестами Lcode  - общее кол-во строк кода.

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

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

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

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

блок процесса - одна точка входа и одна точка выхода

точка выбора - одна точка входа, две и более точки выхода

точка соединения (обращение к П/П - две и более точек входа, одна точка выхода

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

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

Уровень

Название

0

Описание

--

1

Тестируй все, что протестируешь, пользователи протестируют все остальное

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

2

3

Каждый оператор должен быть выполнен как минимум один раз.

Покрытие альтернатив / Покрытие ветвей

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

Покрытие условий

4

Каждое условие, имеющее TRUE и FALSE на выходе, выполнено как минимум один раз.

Покрытие путей

Все пути должны быть проверены

Пример:

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

Элемент

Тип элемента

Тип обращения

Требования

combobox

Контактное лицо

editbox

Набор данных:

1. Консультация

2. Проведение тестирования

3. Размещение рекламы

4. Ошибка на сайте

*  - на процесс выполнения операции приема заявок не влияет.

• Обязательное для заполнения
• Максимально 25 символов
• Использование цифр и спец символов не допускается

Контактный телефон

editbox

Сообщение

text area

Отправить

• Обязательное для заполнения

button

2. Допустимые символы "+" и цифры

3. "+" можно использовать только в начале номера

4. Допустимые форматы:

начинается с плюса - 11-15 цифр +31612361264 +375291438884

без плюса - 5-10 цифр, например: 0613261264 2925167

1. Обязательное для заполнения

2. Максимальная длина 1024 символа

Состояние:

1. По умолчанию - не активна (Disabled)

2. После заполнения обязательных полей становится активна (Enabled)

Действия после нажатия

1. Если введенные данные корректны - отправка сообщения

2. Если введенные данные НЕ корректны - валидационное сообщение

Анализ требований

Читаем, анализируем требования и выделяем для себя следующие особенности:

• какие из полей обязательные для заполнения?
• имеют ли поля ограничения по длине или по размерности (границы)?
• какие из полей имеют специальные форматы?

Определение набора тестовых данных

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

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

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

Выбор тестовых данных для каждого отдельно взятого поля

1. Поле  Тип обращения . Так как все данные не изменяют сам процесс выполнения приема заявки, берем любую (1-ю) позицию в листе с ожидаемым результатом ОК. Но т.к. реализовано поле как лист, имеет также смысл рассмотреть и граничные условия, т.е. берем первый и последний элементы. Итого: 1-я и последняя позиции в листе. Ожидаемый результат при использовании - ОК.

2. Поле  Контактное лицо . Это обязательное поле размером от 1 до 25 символов (включая границы). Проверка на обязательность добавляет к тестовым данным пустое значение. Проведем анализ граничных условий, получим набор: 0, 1, 2, 24, 25 и 26 символов. Пустое значение (0 символов) уже было добавлено при анализе обязательности поля для ввода,

Если его добавить второй раз, произойдет дублирование тестовых данных, которое не приведет к нахождению новых дефектов, а значит повторное добавление в домен не имеет смысла). В связи с тем, что значения 2 и 24 символа являются, с нашей точки зрения, некритичными, их можно не добавлять. В итоге получаем, что минимальный набор данных для тестирования поля - это строки 1 и 25 - ОК, и 0 (пустое значение), 26 символов - N OK.

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

• для номеров с плюсом получим номера с 10, 11, 12 и 14, 15, 16 цифрами

10 и 16 - NOK, а 11, 12, 14, 15 - OK Выделим, что 11, 12, 14, 15 входят в один класс эквивалентности. Поэтому при тестировании мы можем использовать любое из них, но так как 11 и 15 - это границы интервала, то их пропускать нельзя. Следовательно мы можем уменьшить набор значений до двух, исключив 12 и 14, а оставив 11 и 15 для проверки граничных условий. Итого имеем: 11 и 15 цифр - OK, (+12345678901, +123456789012345) 10 и 16 цифр - NOK; (+1234567890, +1234567890123456)

• 10 и 16 - NOK, а 11, 12, 14, 15 - OK Выделим, что 11, 12, 14, 15 входят в один класс эквивалентности. Поэтому при тестировании мы можем использовать любое из них, но так как 11 и 15 - это границы интервала, то их пропускать нельзя. Следовательно мы можем уменьшить набор значений до двух, исключив 12 и 14, а оставив 11 и 15 для проверки граничных условий. Итого имеем: 11 и 15 цифр - OK, (+12345678901, +123456789012345) 10 и 16 цифр - NOK; (+1234567890, +1234567890123456)