Презентация "Тестовая документация" по информатике – проект, доклад

Тестовая документация

Test Plan Test Suite Test Case Test Strategy

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

План тестирования

Стратегия: Как тестировать? Что именно? Как определять ошибки? Ресурсы: вычислительные, человеческие, временные Артефакты: документация, отчеты, отслеживание ошибок

Стратегия тестирования

Стратегия тестирования (Test Strategy) –набор идей, определяющих дизайн тестов. Стратегия тестирования является частью плана тестирования.

Test Suite – набор тест-кейсов для проверки определенной функциональности. Кроме собственно списка тестов может содержать информацию о целях тестирования, конфигурации, необходимом состоянии системы.

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

Структура тест-кейса

Название Предусловия Шаги для воспроизведения Ожидаемый результат Постусловия Также могут быть ID, приоритет, тип…

Пример 1

Пример 2

Проверка входа в аккаунт: Ввести в форме логина user:password Кликнуть Login Result: Произведен вход в систему. Вместо ссылки Login отображается ссылка Hello, User ведущая в раздел Account

Check List

Список того, что нужно проверить Менее подробный и формальный, чем тест-кейсы Быстрее создавать Не обеспечивают такой же уровень воспроизводимости результата

Пример

Матрица соответствия

Матрица соответствия – это двумерная таблица, содержащая соответствие требований продукта и подготовленных тест-кейсов. В заголовках колонок таблицы расположены требования, а в заголовках строк – тест-кейсы. На пересечении – отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.

Баг-репорт

Соответствующим образом оформленное сообщение об ошибке. Формат зависит от используемой системы управления ошибками (Bug Tracking System), но некоторые поля являются обязательными

Структура отчета об ошибке

ID Описание Проект Версия Компонент Priority, Severity Окружение На кого назначен Статус Шаги для воспроизведения Фактический результат Ожидаемый результат Прочая информация (скриншоты, логи и пр.)

Priority & Severity

Серьезность (Severity) – это атрибут, характеризующий влияние дефекта на работоспособность приложения. Block, crash, major, minor, trivial, feature Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправить дефект. Immediate, urgent, high, normal, low

Жизненный цикл бага

Открыт (Open) Назначен (Assigned) В процессе (In progress) Завершен (Resolved) Закрыт (Closed): fixed, won’t fix, feature, can’t reproduce etc Переоткрыт (Reopened)

Отчет по тестированию

Зависит от того, кому предназначен и какую информацию необходимо донести. Как вариант, может содержать: Расписание (кто и когда проводил) Результаты Что протестировано Сколько багов найдено Сколько из них новых Сколько из них регрессионных Сколько из них закрыто … Выводы о качестве продукта (можно в релиз, всё плохо, и т.д.) Список найденных багов с указанием статусов, серьезности и ответственных