# Процессы Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Архитектура Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Vision (Концепция) Проектное решение ESB Микросервисы и service mesh HTTP/REST RPC DDD Анализ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Сервисы DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux Тестирование Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Тестирование требований Тест-анализ и тест дизайн Интеграционное, API, E2E Тест план Метрики качества Автотесты Selenium XPATH Нагрузочное Данные Ресурсы MDM Big data Об информации SQL intro MongoDB intro Библиотека Системная инженерия Станислав Лем Экстраполяция в будущее Политэкономия Сознание, интеллект

/ АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps Gaming Библиотека ПРОЦЕССЫ ТЕСТИРОВАНИЕ: + ТЕСТИРОВАНИЕ + Тестирование требований - Тест-анализ и тест дизайн | Ресурсы | Тест-анализ | Тестовое покрытие | Трассировка требований и тест-кейсов | Риски качества | Риски тестирования | Тест дизайн | Тест-кейс | Методы разработки тестов + Импакт-анализ в тестировании + API, интеграционное и E2E + Тест план + Метрики качества + Android + Автоматизация + Selenium WebDriver + XPATH + Различные расчёты + Безопасность + Нагрузочное
Тест-анализ и тест дизайн
latest update of the page: 14-03-2024, 19:46 UTC
Ресурсы
Тест-анализ

Тест-анализ = процесс поиска и рассмотрения информации, необходимой для:

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

Исполняющему роль тест-аналитика необходимо (в общем случае):

  1. Знать, кто является причастными сторонами (т.н. стейкхолдерами) ко всей системе в целом и к конкретной её доработке: кто владелец проекта, владелец продукта, заказчики / клиенты, исполнители работ по проектированию решения, разработке, тестированию и сопровождению системы.
    Ибо крайне важно понимать, кто будет "поставщиком" информации, а кто будет потребителем наших информационных артефактов (например, проектные/продуктовые менеджеры и тестировщики). Это люди, с которыми вам потребуется взаимодействовать.
  2. Держать в голове для каких целей создан Продукт/Система, кто и каким образом будет его использовать.
  3. Выяснять суть реализации (всей системы или конкретной её доработки): какова архитектура, какие компоненты дорабатываются.
  4. Определять необходимое и возможное тестовое покрытие (что будем тестировать и на какую "глубину"), необходимые виды тестирования.
  5. Иметь и поддерживать Матрицу трассировки требований
  6. (совмещение роли тест-лида) Определять риски тестирования. Они способны серьёзно повлиять на оценку сроков тестирования.
  7. (опционально, но крайне желательно) Сохранять на своей странице в базе знаний по продукту всю важную информацию из добытой — контакты, ссылки, переписку, замечания, оценки, план своих работ, чек-листы и др. Ибо голова у вас всегда будет перегружена информацией, и вы будете забывать важное.

Тестовое покрытие

Тестовое покрытие = покрытие тестами требований к продукту/системе, выраженное в численном либо процентном соотношении. Тестовое покрытие является одной из основных метрик качества продукта.
Иногда под тестовым покрытием имеют в виду покрытие критериев приёмки, покрытие кода. Кто-то считает покрытие только автотестами.
Тестовое покрытие говорит о добротности тестирования, о степени доверия к производимому продукту, о наличие и масштабах "белых пятен", где выше риск пропуска ошибок.

Об определении покрытия картинкой:

скачать схему в формате diagrams.net (бывший draw.io)

Итак, мы прошли этап определения причастных сторон, ознакомились с документацией, держим в голове архитектуру, требования к системе, критерии приёмки доработок.
Теперь надо определиться с объёмом тестирования и видами тестирования...

На практике, ввиду жёсткой ограниченности по времени, чаще всего обходятся лишь составлением тестов, покрывающих критерии приёмки. Это жёсткий необходимый минимум по тестированию.
Если у вас так, то дальше этот раздел можно не читать, вы уже знаете что делать, любите, верите и практикуете.

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

  1. сущности (задействованные чаще всего, самые важные)
    , связи сущностей
    , модель их статусов/состояний
    , возможные действия с сущностями (CRUD, фильтрация, сортировка, поиск, экспорт, импорт, валидация, парсинг, копирование).
  2. бизнес-процессы, use cases (user scenarios, system scenarios), проходящие в продукте.
  3. входящую и исходящую интеграции, каким способом она происходит (ETL, RPC, REST API, file, MQ и т.д.) и с чем.
  4. ролевая модель — какие роли с какими правами; на какие бизнес-процессы, use cases и на работу с какими сущностями она распространяется.
  5. UI как те или иные виды экранных форм в web-, desktop-, mobile-приложении. Или даже TUI.
  6. CLI (command-line interface) и возможные команды приложению посредством командной строки.
  7. Варианты конфигурации приложения.

Теперь прикидываем какими видами тестирования с какими тест-сценариями можно покрыть всю разоблачённую феерию:

Вид тестирования Примеры тестов
Функциональное позитивное (в т.ч. безопасности)
  1. Тесты на основе уже определённых и описанных системными и бизнес-аналитиками критериев приёмки функций/свойств Системы;
  2. Позитивные проверки всего и вся:
    • E2E-тесты по бизнес-процессам, use case, user story
    • тесты на корректную работу системы с сущностями (данными)
    • UI-тесты
      • состояние и содержимое UI-элементов на странице
      • логика отображения и поведения UI-элементов
      • маски на полях, допустимая длина вводимых данных
    • (все вышеперечисленные) тесты в различных браузерах (если приложение кросс-браузерно)
    • API-тесты (не забывая проверять соблюдение SLA), в т.ч. на обратную совместимость API, если вы её гарантируете
    • интеграционные тесты, если в скоуп входит несколько Систем (сервисов). Часто совмещаются с API-тестами.
    • (все вышеперечисленные) тесты в различном окружении (если приложение кросс-платформенно)
    • тесты на команды приложению в CLI (при наличии такого интерфейса)
    • тесты на совместимость экспорта-импорта чего-либо, когда, например экспорт был выполнен в предыдущей версии, а импорт пытаемся сделать в новой версии
  3. Позитивные тесты безопасности:
    • возможность получения токенов, ключей, сертификатов в предусмотренных условиях с корректными запросами
    • E2E и UI-тесты под предусмотренными ролевой моделью ролями, работа с формами и сущностями (данными)
Функциональное негативное (в т.ч. безопасности)
  1. Тесты на основе уже определённых и описанных системными и бизнес-аналитиками критериев приёмки функций/свойств;
  2. попытка "скормить" данные не предусмотренного типа, не того который ожидается
  3. попытка "скормить" данные не в той структуре (не в том формате), которая ожидается
  4. попытка работать с несуществующими сущностями
  5. попытка работать с удалёнными сущностями
  6. попытка совершить переход сущности в состояние, не предусмотренное к достижению из текущего состояния
  7. попытка совершить переход сущности из текущего состояния в это же (проверяем что не совершается "лишних" действий, не появляются дубликаты данных, не происходит перезапись данных и т.п.)
  8. негативные тесты на безопасности:
    • невозможность получения токенов, ключей, сертификатов с некорректными условиями/запросами
    • невозможность работы с формами и сущностями (данными) от лица роли, доступа к ним для которой запрещена согласно ролевой модели
    • тестирование на проникновение
Нефункциональное:
  1. нагрузочное тестирование
  2. стресс-тестирование
  3. тестирование стабильности или надёжности
  4. тестирование выносливости
  5. объёмное тестирование
  6. тестирование установки
  7. тестирование удобства пользования
  8. тестирование на отказ и восстановление
  9. тестирование конфигураций
  10. тестирование совместимости
  11. тестирование безопасности
  1. Тесты на основе уже определённых и описанных системными и бизнес-аналитиками критериев приёмки
  2. обычные нагрузочные тесты, стресс-тесты, тесты на отказоустойчивость и т.п.
  3. обычные тесты на корректную работу (запуск) в различных предусмотренных конфигурациях
  4. обычные тесты на корректный запуск приложения в различном environment и ОС
  5. обычные тесты на установку приложения с соблюдением SLA
  6. симуляция недоступности БД в процессе работы
  7. симуляция потери данных в процессе работы (удаление файлов, сущностей в БД)
  8. симуляция потери доступа к транспорту
  9. симуляция недоступности необходимых для работы портов и ресурсов
  10. симуляция стопора в очереди в транспорте (недоступность Kafka/RabbitMQ, снижение пропускной способности)
  11. используются ли в межсервисном взаимодействии нужные протоколы, сертификаты, шифрование
  12. корректно ли замаскированы данные в БД
  13. ...
В итоге получаем своего рода наброски (drafts) тест-кейсов, которые дальше уже далее потребуется детализировать по шагам.
Уже становится ПРИМЕРНО виден объём возможного тестирования, можно ПРИМЕРНО прикинуть сколько времени займёт как тест-дизайн по этим черновикам (детализация тест-кейсов), так и время прохождения всех этих тестов.
Заодно можно прикинуть какие из этих тест-кейсов целесообразно пустить потом в автоматизацию.

Трассировка требований и тест-кейсов

Матрица трассируемости требований (Requirement Traceability Matrix) = двумерная таблица, содержащая соответствие требований (user/business requirements, software requirements) и подготовленных тест-кейсов (test cases).
Основное её предназначение в отображении степени покрытия требований тест-кейсами.

  • ID Бизнес-Требования (BR, Business Requirement) или Бизнес Варианта Использования (Business Use Case);
  • суть Бизнес-Требования;
  • (опционально) приоритет Бизнес-Требования;
  • (опционально) приёмочный критерий Требования (acceptance criteria);
  • (опционально) ID Функционального требования (FR, functional requirement) из Спецификации к Требованиям ПО (SRS) или ID Варианта Использования (UC, Use Case);
  • (опционально) описание Функционального требования или Варианта Использования;
  • ID тестового артефакта (Тест-кейса);
  • (опционально) ожидаемый результат Тест-кейса (expected result);
  • (опционально) номер Задачи на разработку из таск-трекера + её описание;
  • (опционально) логический блок / модуль, к которому принадлежит Задача/Требование;

Примеры Матриц Трассировки:

  • # Block of feature Issue for development Acceptance criteria Priority Test-case
    1 Create Creating User should be able to create new document High Test #1: Create document
    2 User should not be able to create new document, if he has role = "Reviewer" High Test #14: Reviewer should not be able to create new doc
    3 Print Document printing User should be able to print a document High Test #2: Print a document
    4 .doc, .pdf, .docx, .rtf formats of a document should be able to be printed High Test #4: Check-list for doc formats
    N ... ... ... Low / Medium / High link to TC
  • (скачать таблицу в формате XLSX)

Для каждого Бизнес-Требования будет одно или несколько Функциональных (Системных) Требований, его реализующих. Соответственно, каждое системное требование должно иметь критерии приёмки, которые должны быть покрыты тестами.

Пример рабочего процесса, в котором присутствует создание Матрицы Трассировки:

скачать схему в формате diagrams.net (бывший draw.io)

Если вы используете таск-трекер Jira (и её плагины Zephyr Scale (Zephyr Squad) — Test Management for Jira) для тестовой документации и систему управления требованиями Сonfluence, то JIRA-таски и Confluence-страницы можно привязывать к тест-кейсам, в JIRA-тасках создавать связи с тестовыми прогонами, и такая трассируемость позволяет:

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

Соотношение привязки Требования и Тест-кейса может быть:

  • 1 к 1 (атомарное требование, которое покрывается одним тест-кейсом, данный тест-кейс покрывает только это требование);
  • 1 к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают только это требование);
    когда одно требование в матрице трассируемости покрывается несколькими тестами, это может говорить об избыточности тестирования. В таком случае надо проанализировать, насколько требование атомарно.
  • n к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают это и другие требования).

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

Риск качества (Quality risk) — потенциальный вид ошибки, способ поведения системы, при котором она, вероятно, не соответствует обоснованным ожиданиям качества системы, имеющимся у пользователя или заказчика. Это потенциальный, а не обязательный результат.

Общие категории рисков качества
Функциональность Проблемы, в результате которых не работают конкретные функции
Нагрузка, производительность, объём Проблемы обработки ожидаемых пиковых нагрузок при параллельной работе нескольких пользователей
Надёжность, стабильность работы Проблемы, при которых система слишком часто зависает или долго не восстанавливается
Перегрузки, обработка ошибок и восстановление Проблемы, возникающие ввиду превышения допустимых пиковых нагрузок или из-за обработки недопустимых условий (например, побочный эффект от сознательного внесения ошибок)
Обработка времени и дат Ошибки в математических действиях с датами и временем, в их форматировании, в планируемых событиях и других операциях, зависящих от времени
Качество данных Ошибки в обработке, извлечении и хранении данных
Производительность проблемы с временем завершения задач при ожидаемой нагрузке
Локализация проблемы, связанные с локализацией продукта, в том числе в обработке страницы символов, языковой поддержке, в использовании грамматики, словаря, а также в сообщениях об ошибках и файлах помощи
Безопасность проблемы в защите системы и охраняемых данных от мошеннического и злонамеренного использования
Установка/перенос ошибки, которые препятствуют поставке системы
Документирование ошибки в руководствах по установке и работе с системой для пользователей и системных администраторов
Из этого также следует вывод о том, насколько важно изучить требования заказчика, придерживаться их и здравого смысла (заказчик не всегда прав, иногда полезно намекнуть ему о потенциальных рисках в результате реализации какого-либо из его легкомысленных требований).

Риски тестирования

Основные риски тестирования:

  1. Проектные — связанные с коммуникациями участников команды, инфраструктурой:
    - изменение скоупа тестирования после проверки основных тест-кейсов
    ...
  2. Продуктовые — связанные только с тестируемыми функциями и тестовыми средам:
    - отсутствие тестовых зон с заданной конфигурацей (медленные БД, (не)обезличенные БД, отсутствие каких-то тестовых данных)
    - недопустимое время на ожидание подготовки тестовых зон со стороны Администраторов / DevOps
    ...

Тест дизайн

Проектирование тестов (test design) = процесс проектирования и создания тест-кейсов (тестовых случаев/сценариев/дел, case — юр. "дело"), в соответствии с определёнными ранее критериями качества, целями тестирования, критериями приёмки.

Тест-кейс

Тестовый случай (Test Case) = артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Этимология слова case восходит к юридиспруденции. Case — дело, случай.
В тестировании мы, по-сути, с помощью тест-кейсов, предоставляющих нам свидетельства и факты, поддерживаем аргументы, обосновывая ими заявления о том, что проверяемая Система/ПО/Продукт соответствуют требованиям.

скачать схему в формате diagrams.net (бывший draw.io)

Исчерпывающий формат тест-кейса

  1. Название (subject)
  2. Описание (description) — что проверяем, некие важные подробности
  3. Трассировка (tracing) — ссылки на таск и страницу с требованиями к проверяемой тест-кейсом функциональности, юзкейс, юзерстори ссылки на бегрепорты по тест-кейсу
  4. Предусловия (preconditions), например:
    • Учётные записи и настройки ролей: имеется такая-то учётная запись, JWT, так-то настроена аутентификация и авторизация, учётной записи назначены такие-то права/роли.
    • Развёрнуто и настроено: развёрнуто A,B,C, перечисление критически важных для теста атрибутов конфигурации.
      Возможно, ссылка на репозиторий, регистр с контейнерами скрипты деплоя и инструкции при наличии
    • Данные: в Системах A,B,C (их БД) созданы такие-то экземпляры сущностей / имеются такие-то данные, которые понадобятся в процессе теста.
  5. "Тело" тест-кейса, обычно в виде таблицы такого вида:
    № п/п Действие Ожидаемый результат Результат
    1 Делаем вот это Видим вот это, это и это <успех / неудача, комментарий с подробностями фактического результата при неудаче>
    N ... ... ...
Методы разработки тестов

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

Причина / Следствие (Cause/Effect)

Простая проверка действий и их результата. Как правило, ввод комбинаций условий (Причин) для получения ответа от системы (Следствие).
Например, вы проверяете возможность добавлять клиента, используя определённую экранную форму. Пользователю необходимо заполнить несколько полей — "Имя", "Адрес", "Номер Телефона" — а затем нажать кнопку "Добавить". Это Причина. После нажатия кнопки "Добавить" система добавляет клиента в БД и показывает его номер на экране — это Следствие.
Примерный алгоритм:

  1. Выискиваем и связываем причины и следствия в спецификации
  2. Учитываем "невозможные" сочетания причин и следствий
  3. Составляем "таблицу решений", где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец это готовый тестовый сценарий
  4. Приоритизируем решения.

Тестирование смены состояний (State Transition Testing)

Когда в Системе есть сущности (объекты), которые могут принимать различные состояния, то неплохо бы проверить, что предусмотренные требованиями переходы возможны к осуществлению, а непредусмотренные — невозможны.
Пример:

скачать схему в формате diagrams.net (бывший draw.io)

Подробнее: Тестирование на основе диаграмм состояний сущности (2015).

Таблица решений (Decision Table Testing)

Способ компактного представления модели со сложной логикой. Устанавливает связь между условиями (входными параметрами) и результатом (действиями Системы). Определить/записать все условия. Просчитать возможное количество комбинаций условий. Заполнить комбинации. Записать действия. Убрать лишние комбинации.
Например:

Тестирование путей (Path Testing)

Часто под ним имеется в виду метод тестирования белого ящика Control Flow Testing (тестирование управляемого потока), в котором тест-кейсами покрываются все логические потоки ПО. Подробнее можно прочитать здесь:

Однако, его же можно использовать для покрытия тестами логики тестируемой системы, если у нас имеются BPMN-диаграммы и UML activity-диаграммы, описывающие процессы, проходящие в ней.
Количество сценариев будет зависеть от количества логических узлов ветвлений. Если условия ветвлений зависят от значений каких-то данных, то скорее всего, для каждого тест-сценария необходимо, опираясь на диаграмму, определить набор входных данных.
Очень упрощённо:


Посмотреть/послушать о такого рода применении метода можно здесь Где логика?! История тестирования одного микросервиса (Денис Кудряшов, Leroy Merlin, 2020), где докладчик скомбинировал этот метод с вышеупомянутой таблицей решений (Decision Table Testing).

Определение классов эквивалентности (Equivalence Partitioning)
и Анализ Граничных Значений (Boundary Value Analysis)

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

Попарное тестирование (Pairwise Testing)

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

Подробнее: ПОПАРНОЕ ТЕСТИРОВАНИЕ (PAIRWISE TESTING) (2018).

Предугадывание ошибки (Error Guessing)

Это когда тест-аналитик/тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "здесь пользователь должен ввести код". Тест-аналитик выдвигает предположения: "Что, если я не введу код?", "Что, если я введу неправильный код?" и так далее. Это и есть предугадывание ошибки.
Иногда, под этим методом имеется в виду своеобразная "чуйка" у хорошо знающего систему тест-аналитика/тестировщика, когда при проверке функциональности X он даже неосознанно (опыт!) решает "на всякий случай" проверить дополнительно ещё функциональность Y, где могут "всплывать" ошибки.
Тесно связано с понятием импакт-анализа.

Исчерпывающее тестирование (Exhaustive Testing)

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