Документирование и оценка индустриального тестирования

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

1. Подать на вход три разных целых числа.
2. Запустить тестовое исполнение.
3. Проверить, соответствует ли полученный результат таблице [ссылка на документ1] с учетом поправок [ссылка на документ2].
4. Убедиться в понятности и корректности выдаваемой сопроводительной информации

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

1. Выдать на консоль имя или номер теста и время его начала
2. Вызвать продукт с фиксированными параметрами
3. Перенаправить вывод продукта в файл
4. Проверить возвращенное продуктом значение. Оно должно быть равно ожидаемому (эталонному) результату, эафиксированному в тесте.
5. Проверить вывод продукта, сохраненный в файле (п.3), на равенство заранее приготовленному эталону
6. Выдать на консоль результаты теста в виде вердикта PASS/FAIL и в случае FAIL - краткого пояснения, какая именно проверка не прошла
7. Выдать на консоль время окончания теста

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

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

1. Анализировать степень покрытия продукта тестами на основании описания тестового набора.
2. Для любой функции тестируемого продукта найти тесты, в которых функция используется.
3. Для любого теста определить все функции и их сочетания, которые данный тест использует (затрагивает).
4. Понять структуру и взаимосвязи тестовых файлов.
5. Понять принцип построения системы автоматизации тестирования

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

1. Наименование подсистемы, в которой обнаружен дефект.
2. Версия продукта (номер build ), на котором дефект был найден.
3. Описание дефекта.
4. Описание процедуры (шагов, необходимых для воспроизведения дефекта).
5. Номер теста, на котором дефект был обнаружен.
6. Уровень дефекта, то есть степень его серьезности с точки зрения критериев качества продукта или заказчика.

Занесенный в базу дефектов новый дефект находится в состоянии "New" . После того, как команда разработчиков проанализирует дефект, он переводится в состояние "Open" с указанием конкретного разработчика, ответственного за исправление дефекта. После исправления дефект переводится разработчиком в состояние "Resolved". При этом разработчик должен указать следующую информацию:

1. Причину возникновения дефекта.
2. Место исправления, как минимум, с точностью до исправленного файла.
3. Краткое описание того, что было исправлено.
4. Время, затраченное на исправление.

После этого тестировщик проверяет, действительно ли дефект был исправлен и если это так, переводит его в состояние "Verified". Если тестировщик не подтвердит факт исправления дефекта, то состояние дефекта изменяется снова на "Open".
Если проектная команда принимает решение о том, что некоторый дефект исправляться не будет, то такой дефект переводится в состояние "Postponed" с указанием лиц, ответственных за это решение, и причин его принятия.
Тестовый отчет
Тестовый отчет обновляется после каждого цикла тестирования и должен содержать следующую информацию для каждого цикла:

1. Перечень функциональности в соответствии с пунктами требований, запланированный для тестирования на данном цикле, и реальные данные по нему.
2. Количество выполненных тестов – запланированное и реально исполненное.
3. Время, затраченное на тестирование каждой функции, и общее время тестирования.
4. Количество найденных дефектов.
5. Количество повторно открытых дефектов.
6. Отклонения от запланированной последовательности действий, если таковые имели место.
7. Выводы о необходимых корректировках в системе тестов, которые должны быть сделаны до следующего тестового цикла.

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

Оценка качества тестов

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

1. Покрытие функциональных требований.
2. Покрытие кода продукта. Наиболее применимо для модульного уровня тестирования.
3. Покрытие множества сценариев.
4. Количество или плотность найденных дефектов. Текущее количество дефектов сравнивается со средним для данного типа продуктов с целью установить, находится ли оно в пределах допустимого статистического отклонения. При этом обнаруженные отклонения как в большую, так и в меньшую сторону приводят к анализу причин их появления и, если необходимо, к выработке корректирующих действий.
5. Соотношение количества найденных дефектов с количеством тестов на данную функцию продукта. Сильное расхождение этих двух величин говорит либо о неэффективности тестов (когда большое количество тестов находит мало дефектов) либо о плохом качестве данного участка кода (когда найдено большое количество дефектов на не очень большом количестве тестов).
6. Количество найденных дефектов, соотнесенное по времени, или скорость поиска дефектов. Если производная такой функции близка нулю, то продукт обладает качеством, достаточным для окончания тестирования и поставки заказчику.

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

1. Установить достаточность проверок, обеспечиваемых тестированием.
2. Проанализировать оптимальность покрытия или адекватность распределения количества планируемых тестов по функциональности продукта
3. Проанализировать оптимальность подхода к разработке кода, генерации кода, автоматизации тестирования.

Цели обзора тестового кода:

1. Установить соответствие тестового набора тестовой стратегии.
2. Проверить правильность кодирования тестов.
3. Оценить достигнутую степень качества кода, исходя из требований по стандартам, простоте поддержки, наличию комментариев и т.п.
4. Если необходимо, проанализировать оптимальность тестового кода с целью удовлетворения требований к быстродействию и объему.