структура документации тестирования (1)

1. Структура документации тестирования и V-модель разработки ПО

2. Содержание

1.
2.
3.
4.
5.
6.
7.
8.
9.
Цель и задачи
V-модель разработки ПО
Преимущества
Недостатки
План тестирования
Тестовый отчет
Матрица соответствия
Лист проверки
Самоконтроль

3. Цель и задачи

Целью данного занятия является ознакомление с основной
структурой документации при проведении тестирования
Задачи:
1) Определение плана тестирования
2) Формирование тестового отчета
3) Формирование матрицы соответствия
4) Оформление листа проверки

4. Общее

• V-модель - это методология разработки программного
обеспечения, которая представляет собой графическое
изображение жизненного цикла разработки программного
обеспечения.
• В V-модели все этапы разработки отображаются как ступени
на левой стороне буквы “V”, а связанные с ними этапы
тестирования - на правой стороне. Графическое
изображение показывает, что каждый этап разработки имеет
соответствующий этап тестирования.
• Ключевое преимущество V-модели заключается в том, что
она предоставляет четкую структуру, которая облегчает
управление проектом и повышает его качество. Недостатком
является то, что V-модель может быть неудобной для

5. V-модель разработки ПО

• Каждый этап разработки ПО
сопровождается
соответствующими этапами
разработки тестов и
выполнением тестирования.

6. V-модель разработки ПО

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

7. V-модель разработки ПО

• Написание кода ПО приводит нас к последовательному
усложнению тестируемого объекта: модуль → комбинация
модулей → функциональное требование.
• Таким образом, мы получаем наборы тестов для всестороннего
разноуровнего тестирования.

8. Преимущества модели V

• Улучшенное управление рисками: благодаря тщательному анализу
требований и тестированию на ранних этапах разработки, модель V
помогает снизить риски, связанные с разработкой программного
обеспечения.
• Уменьшение затрат на исправление ошибок: раннее выявление и
исправление ошибок на более ранних этапах разработки позволяет
сэкономить значительные затраты на исправление ошибок на более
поздних этапах.

9. Преимущества модели V

• Улучшенное управление проектами: Модель V предоставляет
четкий план и структурированный процесс разработки, что облегчает
управление проектом и снижает вероятность неожиданных проблем.
• Улучшенное качество продукта: благодаря тщательному анализу
требований и более раннему выявлению ошибок, модель V помогает
создать продукт высокого качества.
• Улучшенная коммуникация: Модель V обеспечивает более
эффективную коммуникацию между членами команды разработки,
заказчиком и другими участниками процесса разработки.

10. Преимущества модели V

• Улучшенное тестирование: благодаря подробному тестированию
на всех уровнях разработки, модель V позволяет создать
программное обеспечение, которое работает точно так, как должно
работать.
• Более
предсказуемый
процесс
разработки:
Модель
V
обеспечивает более предсказуемый процесс разработки и
управления проектом, что позволяет достигать целей проекта в срок
и в рамках бюджета.
В целом, модель V является хорошим выбором для разработки программного
обеспечения, который требует высокой надежности и стабильности, а также тесного
сотрудничества с заказчиком.

11. Недостатки модели V

• Жесткость: Модель V не гибкая, и не учитывает изменения,
которые могут происходить во время разработки. Это может
привести к трудностям, если необходимо внести значительные
изменения в проект.
• Отсутствие фокуса на клиенте: Модель V в целом ориентирована
на выполнение требований, определенных заказчиком, но не всегда
учитывает потребности и ожидания конечных пользователей.
• Высокие затраты на начальный анализ и планирование: Модель V
требует значительных усилий на начальном этапе, так как все
требования и проектные документы должны быть определены и
подробно описаны на ранних этапах разработки.

12. Недостатки модели V

• Сложности с изменением: Модель V предназначена для линейного
процесса разработки, что затрудняет процесс внесения изменений в
проект на более поздних этапах.
• Недостаточная поддержка командной работы: В модели V слишком
большое внимание уделяется разделению процесса на различные
этапы, что может привести к проблемам в командной работе и
снижению производительности.
• Сложности с тестированием: В модели V тестирование выполняется
на отдельных этапах разработки, что может привести к пропуску
некоторых ошибок и сложностей с интеграцией компонентов в
целом.
В целом, модель V может не подходить для проектов, которые требуют большой гибкости
и частых изменений, а также для проектов с низкой степенью определенности
требований.

13. Основные документы тестирования.

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

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

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

Основные вопросы, которые план тестирования должен раскрыть:
• Что необходимо тестировать: включает в себя абсолютно все аспекты ПО,
которые могут быть протестированы.
• Что будет тестироваться: подмножество пунктов из первого вопроса,
которые будут протестированы. Из первого вопроса исключаются аспекты,
исходя из анализа сроков, бюджета, приоритетов и пр. В идеальном случае
множество первого и второго вопросов совпадают.
• Как будет проходить тестирование: выбор стратегии тестирования (ручное
тестирование, написание автоматических тестов, подбор групп пользователей
для тестирования и др.).
• Когда будет проходить тестирование: сроки тестирования для каждого
компонента ПО.
• Критерии окончания тестирования: результат, который должен быть
получен в результате тестирования (отчет, список ошибок, каким способом
представлены эти документы и др.).

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

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

17. План тестирования включает в себя:

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

18. План тестирования включает в себя:

Тестовую стратегию, включающую:
– Анализ функций и подсистем;
– Определение стратегии выбора входных данных
для тестирования;
– Определение потребности в автоматизированной
системе тестирования и дизайн такой системы.

19. План тестирования включает в себя:

• Расписание тестовых циклов.
• Фиксацию тестовой конфигурации: состава и конкретных
параметров аппаратуры и программного окружения.
• Определение списка тестовых метрик, которые на тестовом
цикле необходимо собрать и проанализировать.

20. Типы тестирования по виду подсистемы или продукта:

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

21. Типы тестирования по виду подсистемы или продукта:

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

22. Типы тестирования по способу выбора входных значений:

• Функциональное тестирование, при котором проверяется:
– Покрытие функциональных требований.
– Покрытие сценариев использования.
• Стрессовое тестирование, при котором проверяются
экстремальные режимы использования продукта.

23. Типы тестирования по способу выбора входных значений:

• Тестирование граничных значений.
• Тестирование производительности.
• Тестирование на соответствие стандартам.
• Тестирование совместимости с другими программноаппаратными комплексами.
• Тестирование работы с окружением.
• Тестирование работы на конкретной платформе

24. Тестовый отчет

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

25. Матрица соответствия требований

• Матрица соответствия требований (traceability matrix,
трассируемость требования в тестах) — это двумерная таблица,
содержащая соответствие функциональных требований ПО и
подготовленных тестовых сценариев.
• В заголовках колонок таблицы расположены требования, а в
заголовках строк — тестовые сценарии.
• Матрица соответствия требований используется
руководителями тестирования ПО для валидации покрытия
продукта тестами и является неотъемлемой частью тестплана.

26. Лист проверки

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

27. Самоконтроль

• Что такое план тестирования?
• Что такое матрица соответствия?
• Что такое лист проверки?