Могут быть различные уровни адекватного тестирования, который охватывает случаи от отсутствия тестирования до исчерпывающего тестирования, когда выполняется прогон всех возможных тестовых случаев. Объем необходимого тестирования следует определять исходя из краткосрочных и долгосрочных целей проекта и в соответствии с особенностями разрабатываемого ПП. Покрытие - это мера полноты использования возможностей программного компонента тестовым набором.
Например, одна из мер - задействована ли каждая строка программного кода продукта хотя бы один раз при прогоне данного тестового набора. Другая мера - количество требований спецификации, проверенных данным тестовым набором. Если требования сформулированы в терминах случаев использования, то покрытие измеряется количеством случаев использования и числом сценариев, построенных для каждого случая использования.
Анализ рисков в процессе тестирования применяется для определения уровня детализации и времени, затрачиваемого на тестирование конкретного компонента. Например, на тестирование классов, более важных для приложения, отводится больше времени.
Все ответы на поставленные вопросы и многое другое фиксируется в документе – Тест план.
1. Перечень тестовых ресурсов.
2. Перечень функций и подсистем, подлежащих тестированию.
3. Тестовую стратегию:
o Анализ функций и подсистем с целью определения слабых мест, требующих исчерпывающего тестирования, то есть участков функциональности, где появление дефектов наиболее вероятно.
o Определение стратегии выбора входных данных для тестирования. Поскольку в реальных применениях множество входных данных программного продукта практически бесконечно, выбор конечного подмножества для проведения тестирования является сложной задачей. Для ее решения могут быть применены методы покрытия классов входных и выходных данных, анализ крайних значений, покрытие случаев использования и тому подобное. Выбранная стратегия должна быть обоснована и задокументирована.
|
|
o Определение потребности автоматизации процесса тестирования. При этом решение об использовании существующей, либо о создании новой автоматизированной системы тестирования должно быть обосновано, а также продемонстрирована оценка затрат на создание новой системы или на внедрение уже существующей.
4. График (расписание) тестовых циклов.
5. Указание конкретных параметров аппаратуры и программного окружения.
- Определение тестовых метрик, которые необходимо собирать и анализировать, таких как покрытие набора требований, покрытие кода, количество и уровень серьезности дефектов, объем тестового кода и т.п.
Тест план (Test Plan) - это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Тест план должен как минимум отвечать на следующие вопросы:
· Что надо тестировать?
o описание объекта тестирования: системы, приложения, оборудование
· Что будете тестировать?
o список функций и описание тестируемой системы и её компонент в отдельности
· Как будете тестировать?
|
|
o стратегия тестирования, а именно: методологии, виды тестирования и их применение по отношению к тестируемому объекту, приоритеты, автоматизация и пр.
· Когда будете тестировать?
o последовательность проведения работ: фазы, циклы тестирования, процедура тестирования - подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки
· Где будете тестировать?
o Окружение тестируемой системы – описание
o Необходимое для тестирования оборудование и программные средства
o …
- Кто будет тестировать?
o Роли и обязанности
o Имена и фамилии
o ….
· Критерии начала тестирования:
o готовность окружения
o готовность тест кейсов
o законченность разработки требуемого функционала
o выполнение юнит-тестов
o билд построен и удовлетворяет определенным критериям
o и т.п.
o...
· Критерии окончания тестирования:
o результаты тестирования удовлетворяют определенным критериям
o требовния к количеству открытых багов выполнены (определяются заранее)
o и т.п....
· Критерии передачи системы для приемочного тестирования:
o Приемочные тесты – где хранятся и когда выполняются
o Процедура приемки
o …
· Какие риски существую и как мы ими будет управлять?
o Риски и их разрешение
· Метрики и отчеты:
o Продуктовые метрики – кто собирает, с какой периодичностью…
o Отчеты - кто создает, кому отправляет, и т.п.
· Расписание билдов
· …..
Виды тест планов
Чаще всего на практике приходится сталкиваться со следующими видами тест планов:
1. Мастер Тест План (Master Plan or Master Test Plan)
2. Тест План (Test Plan)
|
|
3. План Приемочных Испытаний (Product Acceptance Plan) - документ, описывающий набор действий, связанных с приемочным тестированием: стратегия, дата проведения, ответственные и т.д.
4. План автоматизации (Test Automation Plan) - документ, описывающий набор действий, связанных с автоматизацией тестированием: стратегия, правила, ответственные и т.д.
Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является "живым" документом, который постоянно претерпевает изменения, отражающие реальное положение вещей на проекте.
В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения.
Тест план должен пройти ревью. В этом процессе должны участвовать:
- Тест Лид (как автор)
- Тестеры
- Менеджер Проекта
- Заказчик
- Представитель отдела Обеспечения качества (QA)
Test Case («тест- кейс», «тестовый случай», «тест»)
Тестовый случай (Test Case) – это
– минимальный элемент тестирования (всего одна верификация\проверка)
– совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части
– описание определенных действий и условий, которые необходимы для того, чтобы выявить тот или иной баг
Описание Тестового случая (Test Case)
Хороший тест
– Существует обоснованная вероятность выявления тестом ошибки
– Не является избыточным в наборе тестов
– Наилучший в своей категории
– Не слишком сложный и не слишком простой
– Описаны условия, шаги и ожидаемый результат: однозначно, понятно
– Объемы входных данных не должны быть очень большими (если этого не требуется специально)
Тестовая матрица (Test Matrix) – документ, собержащий описание тестовых случаев и результатов их выполнения.
Оценка качества тестов
Тесты нуждаются в контроле качества так же, как и тестируемый продукт. Поскольку тесты для продукта являются своего рода эталоном его структурных и поведенческих характеристик, закономерен вопрос о том, насколько адекватен эталон. Для оценки качества тестов используются различные методы, наиболее популярные из которых кратко рассмотрены ниже.
Тестовые метрики
Существует устоявшийся набор тестовых метрик, который помогает определить эффективность тестирования и текущее состояние продукта. К таким метрикам относятся следующие:
1. Покрытие функциональных требований.
2. Покрытие кода продукта. Наиболее применимо для модульного уровня тестирования.
3. Покрытие множества сценариев.
4. Количество или плотность найденных дефектов. Текущее количество дефектов сравнивается со средним для данного типа продуктов с целью установить, находится ли оно в пределах допустимого статистического отклонения. При этом обнаруженные отклонения как в большую, так и в меньшую сторону приводят к анализу причин их появления и, если необходимо, к выработке корректирующих действий.
5. Соотношение количества найденных дефектов с количеством тестов на данную функцию продукта. Сильное расхождение этих двух величин говорит либо о неэффективности тестов (когда большое количество тестов находит мало дефектов) либо о плохом качестве данного участка кода (когда найдено большое количество дефектов на не очень большом количестве тестов).
6. Количество найденных дефектов, соотнесенное по времени, или скорость поиска дефектов. Если производная такой функции близка к нулю, то продукт обладает качеством, достаточным для окончания тестирования и поставки заказчику.