Раздел IVтестирование программных средств

Тема 7 ВВЕДЕНИЕ В ТЕСТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ

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

Основные понятия

7.1.1 Терминология. Наиболее полно терминология в области тестирования описана в глоссарии [20], часто упоминаемые термины (тест-план, тест-кейз, баг-репорт, final report и др.) описаны в настоящем конспекте при первом их упоминании. Дополнительно будем использовать следующую терминологию:

Тестирование ПО (software testing) – процесс анализа программного средства (ПС) и сопутствующей документации с целью выявления дефектов и повышения качества программного продукта (ПП).

Качество ПП (quality, применительно к тестированию) – показатель степени соответствия ПП его требованиям. Качество ПП определяется качеством процесса его разработки.

Билд (build) – сборка программы. В большинстве своём программы пишутся несколькими программистами или даже несколькими командами программистов. Результат их работы за определённое ограниченное время собирается в сборку (билд). Потом программисты работают дальше, изменения (например, новые фичи или исправленные дефекты) накапливаются и их собирают в следующий билд и так далее. Без остановки. Вариант 2: Билд (build) – промежуточная версия ПС. Финальный билд часто называют релизом (release).

Функциональность (functionality): Способность программного продукта обеспечивать функции (features, фичи), которые соответствуют установленным и предполагаемым потребностям, при использовании ПО в определенных условиях [ISO 9126].

Фича – русифицированный вариант произношения английского слова feature (произносится «фиче», ударение на «и»). Это слово можно перевести как «особенность, характерная черта». В русском языке слово «фича» употребляется, в основном, применительно к программам или мобильным устройствам. Например: «Мой телефон умеет читать QR-коды. А в твоём телефоне есть такая фича?» То есть, обладает ли твой телефон данным функционалом (функцией)? Ещё один классический пример: это не баг, это фича. То есть: это не ошибка в программе, а одна из функций, в неё заложенных (см. рис. 7.1).

Рисунок 7.1– «Это не баг, это фича»

Дефект (баг, глюк, defect, bug) – любое несоответствие фактического и ожидаемого результата (согласно требованиям или здравому смыслу).

Ожидаемый результат (expected result) – такое поведение ПС, которое мы ожидаем в ответ на наши действия.

Тест-план (test plan) – часть проектной документации, описывающая и регламентирующая процесс тестирования.

Чек-лист (check-list) – набор идей тестов, документ, описывающий что должно быть протестировано. Зачем нужен чек-лист? Не забыть что-то протестировать. Что должно быть в чек-листе? Перечень проверок для тестирования какой-то области, свойства, характеристики приложения и т. д с требуемой степенью детализации.

Тест-кейс (test case) – набор входных данных, условий выполнения и ожидаемых результатов, разработанный с целью проверки того или иного свойства или поведения ПС.

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

Тестовый сценарий, тест-сьют, тестовый набор (test scenario, test-suite) – набор тест-кейсов, собранных в группу (последовательность) для достижения некоторой цели.

Качество ПП (quality, применительно к тестированию) – показатель степени соответствия ПП его требованиям. Качество ПП определяется качеством процесса его разработки.

7. 1.2 Тестовое покрытие. Тестовое покрытие (test coverage), оно же согласно [3] просто покрытие (coverage): уровень, выражаемый в процентах, на который определенный элемент покрытия был проверен набором тестов. Согласно [44] test coverage – это мера полноты тестирования для определенной стратегии, она же степень, до которой с помощью контрольных примеров проверяют требования к системе или программному продукту. Тестовое покрытие – это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода. Если рассматривать тестирование как «проверку соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов», то именно этот конечный набор тестов и будет определять тестовое покрытие. Чем выше требуемый уровень тестового покрытия, тем больше тестов будет выбрано, для проверки тестируемых требований или исполняемого кода.

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

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

· Покрытие требований (RequirementsCoverage) - оценка покрытия тестами функциональных и нефункциональных требований к продукту путем построения матриц трассировки (traceabilitymatrix).

· Покрытие кода (CodeCoverage) - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей ПО.

Различия между названными подходами:

Метод покрытия требований сосредоточен на проверке соответствия набора проводимых тестов требованиям к продукту.

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

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

Ограничения:

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

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

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

T_cov = (L_cov/L_total) • 100%, где:

T_cov – тестовое покрытие,

L_cov – количество требований, проверяемых тест кейсами,

L_total – общее количество требований.

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

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

T_cov = (L_tc/L_code) • 100%, где:

T_cov – тестовое покрытие,

L_tc – количество строк кода, покрытых тестами,

L_code – общее количество строк кода.

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

Для оценки качества тестирования кроме code coverage применяются также: 1. Количество тестов. 2. Количество строк кода в модульных тестах. 3. Суммарное время исполнения тестов и другие метрики. Наиболее важный показатель – code coverage. Общий coverage приложения является основным средством оценки полноты модульного тестирования, и иногда даже существует соглашение с заказчиком относительно его минимально допустимого уровня. Как правило, удовлетворительным считается coverage не ниже 75% или более, в зависимости от конкретного приложения. 100% coverage не является чем-то из ряда вон выходящим и достаточно легко достигается при использовании. Использовать coverage для оценки состояния модульных тестов следует осторожно. Эта метрика скорее позволяет выявить проблемы, чем указать на их отсутствие. Плохие значения coverage четко сигнализируют о том, что тестов в приложении недостаточно, в то время как, хорошие значения не позволяют сделать обратного вывода. Проблема состоит в том, что полнота тестов никак не связана с их корректностью. За рамками coverage остается также важный вопрос о диапазонах параметров функций. Тем не менее, coverage удобно применять, с одной стороны, для общего наблюдения за тестированием в проекте, а также для выявления не покрытых тестами участков кода.