Тест-анализ и тест дизайн
last update: 19-02-2021, 21:42
Тест-анализ
Тест-анализ = процесс поиска/рассмотрения того, что можно использовать для получения информации, необходимой для тестирования. Т.е. информации, необходимой для составления тест-кейсов - или test basis. И чаще всего test basis представляет собой набор документов, состоящий из требований, спецификаций, описания архитектуры, интеграционных интерфейсов и т.п.
Необходимо определить:
- Причастные стороны: Кто владелец проекта, владелец продукта, кто заказчики, клиенты, кто исполнители работ по проектированию, разработке, тестированию и сопровождению. Ибо нужно понимать к кому регулярно обращаться за информацией либо кому поставлять её (менеджеры, тестировщики).
- Цель проекта/доработки: для каких целей создан Продукт/Система, кто и каким образом будет использовать.
- Суть реализации: как работает Продукт/Система, какова архитектура Системы.
- Тестовое покрытие (что будем тестировать, в каких объёмах) и необходимые виды тестирования.
- Риски тестирования. Способны серьёно повлиять на оценку сроков тестирования.
- (опционально) матрицу трассировки требований
Тестовое покрытие
Итак, вы прошли этап определения причастных сторон, ознакомились с документацией по Проекту, получили описание архитектуры Продукта/Системы, требования к ней, критерии приёмки.
Теперь надо определиться с объёмом тестирования и видами тестирования.
Для начала проводим логическую декомпозицию Системы, определяя:
- сущности (задействованные чаще всего, самые важные), связи сущностей, состояния сущностей и правила перехода между ними, действия с сущностями (CRUD, фильтрация, сортировка, поиск, экспорт, иморт, валидация, парсинг, копирование).
- бизнес-процессы, use cases (user scenarios, system scenarios), проходящие в продукте.
- интеграция (ETL, RPC, REST API, file, MQ,...)
- ролевая модель -- какие роли с какими правами, на какие бизнес-процессы, use cases и на работу с какими сущностями она влияет
- UI как те или иные виды экранных форм в web-, desktop-, mobile-приложении.
- CLI (command-line interface)
- поддерживаемые конфигурации
Теперь прикидываем какими тест-сценариями это можно покрыть:
Вид тестирования |
Примеры тестов |
Функциональное позитивное (в т.ч. безопасности) |
-
Позитивные проверки всего и вся:
- E2E-тесты по бизнес-процессам и пользовательским сценариям
- тесты на проверку отдельной функциональности, тесты на корректную работу системы с сущностями (данными)
-
UI-тесты
- состояние и содержимое UI-элементов на странице
- логика отображения и поведения UI-элементов
- маски на полях, допустимая длина вводимых данных
- (все вышеперечисленные) тесты в различных браузерах (если приложение кросс-браузерно)
- API-тесты (не забывая проверять соблюдение SLA)
- интеграционные тесты, если в скоуп входит несколько Систем (сервисов). Часто совмещаются с API-тестами.
- (все вышеперечисленные) тесты в различном окружении (если приложение кросс-платформенно)
- тесты на команды приложению в CLI (при наличии такого интерфейса)
-
Позитивные тесты безопасности:
- возможность получения токенов, ключей, сертификатов в предусмотренных условиях с корректными запросами
- E2E и UI-тесты под предусмотренными ролевой моделью ролями, работа с формами и сущностями (данными)
|
Функциональное негативное (в т.ч. безопасности) |
- попытка "скормить" данные не предусмотренного типа, не того который ожидается
- попытка "скормить" данные не в той структуре (не в том формате), которая ожидается
- попытка работать с несуществующими сущностями
- попытка работать с удалёнными сущностями
- попытка совершить переход сущности в состояние, не предусмотренное к достижению из текущего состояния
- попытка совершить переход сущности из текущего состояния в это же (проверяем что не совершается "лишних" действий, не появляются дубликаты данных, не происходит перезапись данных и т.п.)
-
негативные тесты на безопасности:
- невозможность получения токенов, ключей, сертификатов с некорректными условиями/запросами
- невозможность работы с формами и сущностями (данными) от лица роли, доступа к ним для которой запрещена согласно ролевой модели
|
Нефункциональное:
|
- обычные нагрузочные тесты, стресс-тесты, тесты на отказоустойчивость и т.п.
- обычные тесты на корректную работу (запуск) в различных предусмотренных конфигурациях
- обычные тесты на корректный запуск приложения в различном environment и ОС
- обычные тесты на установку приложения с соблюдением SLA
- симуляция недоступности БД в процессе работы
- симуляция потери данных в процессе работы (удаление файлов, сущностей в БД)
- симуляция потери доступа к транспорту
- симуляция недоступности портов и ресурсов
- симуляция стопора в очереди в транспорте (недоступность Kafka/RabbitMQ, снижение пропускной способности)
|
В итоге получаем своего рода наброски тест-кейсов, которые дальше уже нужно будет детализировать по шагам.
Сразу виден объём возможного тестирования, можно примерно прикинуть сколько времени займёт как
тест-дизайн по этим черновикам, так и время прохождения всех этих тестов.
Заодно можно увидеть какие из этих тест-кейсов целесообразно пустить в
автоматизацию.
Трассировка требований и тест-кейсов
Матрица трассируемости требований (Requirement Traceability Matrix) = двумерная таблица, содержащая соответствие требований (user/business requirements, software requirements) и подготовленных тест-кейсов (test cases).
Основное её предназначение в отображении степени покрытия требований тест-кейсами.
Примеры Матриц Трассировки:
(скачать в формате XLSX)
В соответствии с лучшими практиками, Бизнес-Требования следует максимально декомпозировать и нумеровать в соответствии со следующим правилом: BR001, BR002 и т.д.
Для каждого Бизнес-Требования будет одно или несколько Функциональных Требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования также должны быть максимально декомпозированы.
Пример рабочего процесса, в котором присутствует создание Матрицы Трассировки:
скачать схему в формате diagrams.net (бывший draw.io)
Если вы используете таск трекер Jira (и её плагины Zephyr by Jira, TM4J by Adaptavist) для тестовой документации и систему управления требованиями Сonfluence, то все сущности синхронизируются и такая трассируемость позволяет:
- визуализировать актуальное состояние реализации;
- разбивать требования на более атомарные и структурировать их;
- отслеживать, есть ли требования, на которые еще не запланирована разработка (пропуск реализации);
- отслеживать, реализовано ли требование в данный момент;
- отслеживать, покрыто ли требование тест-кейсом (пропуск тестирования);
- наглядно отображать приоритизацию требований.
Соотношение привязки Требования и Тест-кейса может быть:
- 1 к 1 (атомарное требование, которое покрывается одним тест-кейсом, данный тест-кейс покрывает только это требование);
-
1 к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают только это требование);
когда одно требование в матрице трассируемости покрывается несколькими тестами, это может говорить об избыточности тестирования. В таком случае надо проанализировать, насколько требование атомарно.
- n к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают это и другие требования).
Программные комплексы для управления требованиями:
Риски качества
Риск качества (Quality risk) - потенциальный вид ошибки, способ поведения системы, при котором она, вероятно, не соответствует обоснованным ожиданиям качества системы, имеющимся у пользователя или заказчика. Это потенциальный, а не обязательный результат.
Общие категории рисков качества |
Функциональность |
Проблемы, в результате которых не работают конкретные функции |
Нагрузка, производительность, объём |
Проблемы обработки ожидаемых пиковых нагрузок при параллельной работе нескольких пользователей |
Надёжность, стабильность работы |
Проблемы, при которых система слишком часто зависает или долго не восстанавливается |
Перегрузки, обработка ошибок и восстановление |
Проблемы, возникающие ввиду превышения допустимых пиковых нагрузок или из-за обработки недопустимых условий (например, побочный эффект от сознательного внесения ошибок) |
Обработка времени и дат |
Ошибки в математических действиях с датами и временем, в их форматировании, в планируемых событиях и других операциях, зависящих от времени |
Качество данных |
Ошибки в обработке, извлечении и хранении данных |
Производительность |
проблемы с временем завершения задач при ожидаемой нагрузке |
Локализация |
проблемы, связанные с локализацией продукта, в том числе в обработке страницы символов, языковой поддержке, в использовании грамматики, словаря, а также в сообщениях об ошибках и файлах помощи |
Безопасность |
проблемы в защите системы и охраняемых данных от мошеннического и злонамеренного использования |
Установка/перенос |
ошибки, которые препятствуют поставке системы |
Документирование |
ошибки в руководствах по установке и работе с системой для пользователей и системных администраторов |
Из этого также следует вывод о том, насколько
важно изучить требования заказчика, придерживаться их и здравого смысла (заказчик не всегда прав, иногда полезно намекнуть ему о потенциальных рисках в результате реализации какого-либо из его легкомысленных требований).
Риски тестирования
Основные риски тестирования:
-
Проектные - связанные с коммуникациями участников команды, инфраструктурой:
- изменение скоупа тестирования после проверки основных тест-кейсов
...
-
Продуктовые - связанные только с тестируемыми функциями и тестовыми средам:
- отсутствие тестовых зон с заданной конфигурацей (медленные БД, (не)обезличенные БД, отсутствие каких-то тестовых данных)
- недопустимое время на ожидание подготовки тестовых зон со стороны Администраторов / DevOps
...
Тест дизайн
Проектирование тестов (test design) = процесс проектирования и создания тест-кейсов (тестовых случаев/сценариев/дел, case - юр. "дело"), в соответствии с определёнными ранее критериями качества, целями тестирования, критериями приёмки.
Тест-кейс
Тестовый случай (Test Case) = артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Этимология слова case восходит к юридиспруденции. Case - дело, случай.
В тестировании мы, по-сути, с помощью тест-кейсов, предоставляющих нам свидетельства и факты, поддерживаем аргументы, обосновывая ими заявления о том, что проверяемая Система/ПО/Продукт соответствуют требованиям.
скачать схему в формате diagrams.net (бывший draw.io)
Пример оформления: http://www.protesting.ru/documentation/test_case_example.zip
Методы разработки тестов
Определение классов эквивалентности (Equivalence Partitioning)
и Анализ Граничных Значений (Boundary Value Analysis)
- Если область определения параметра — диапазон, то имеет смысл выделение трёх классов эквивалентности: слева от диапазона (невалидные значения), сам диапазон (валидные значения) и справа от диапазона (снова невалидные). При выделении классов нужно использовать включающие границы с целью однозначности и точности: одно и то же значение не может относиться к двум классам одновременно.
Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
- Если область определения это набор неупорядоченных данных, то всегда можно выделить как минимум два класса — валидные и невалидные значения.
Полученное разбиение можно "дробить" дальше. Например, множество латинских букв можно разбить на два подмножества: латинница в верхнем и нижнем регистре соответственно.
Попарное тестирование (Pairwise Testing)
Метод, основывающийся на тестировании комбинаций, с учётом того, чтобы каждое значение всех параметров хотя бы единожды сочеталось в проверках с другими значениями остальных параметров. Метод сильно уменьшает объём тестирования, но увеличивает вероятность пропуска дефекта.
Пример "оптимизации" оптимизации количества тестов этим методом:
Подробнее: ПОПАРНОЕ ТЕСТИРОВАНИЕ (PAIRWISE TESTING) (2018).
Причина / Следствие (Cause/Effect)
Простая проверка базовых действий и их результата. Как правило, ввод комбинаций условий (причин) для получения ответа от системы (Следствие).
Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Пользователю необходимо заполнить несколько полей -- "Имя", "Адрес", "Номер Телефона" -- а затем нажать кнопку "Добавить". Это Причина. После нажатия кнопки "Добавить" система добавляет клиента в БД и показывает его номер на экране -- это Следствие.
Примерный алгоритм:
- Выискиваем и связываем причины и следствия в спецификации
- Учитываем "невозможные" сочетания причин и следствий
- Составляем "таблицу решений", где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец это готовый тестовый сценарий
- Приоритизируем решения.
Тестирование состояния сущностей (State Transition Testing)
Когда в Системе есть сущности (объекты), которые могут принимать различные состояния, то неплохо бы проверить, что предусмотренные требованиями переходы возможны к осуществлению, а непредусмотренные -- невозможны.
Пример:
скачать схему в формате diagrams.net (бывший draw.io)
Подробнее: Тестирование на основе диаграмм состояний сущности (2015).
Таблица решений (Decision Table Testing)
Способ компактного представления модели со сложной логикой. Устанавливает связь между условиями (входными параметрами) и результатом (действиями Системы). Определить/записать все условия. Просчитать возможное количество комбинаций условий. Заполнить комбинации. Записать действия. Убрать лишние комбинации.
Например:
Чуть подробнее: Decision Table Testing: Learn with Example
Тестирование путей (Path Testing)
Часто под ним имеется в виду метод тестирования белого ящика Control Flow Testing, в котором тест-кейсами покрываются все потоки и логические пути ПО. Подробнее можно прочитать здесь:
Однако, его же можно использовать для покрытия тестами логики тестируемой системы, если у нас имеются BPMN-диаграммы и UML activity-диаграммы, описывающие процессы, проходящие в ней.
Количество сценариев будет зависеть от количества логических узлов ветвлений. Если условия ветвлений зависят от значений каких-то данных, то скорее всего, для каждого тест-сценария необходимо, опираясь на диаграмму, определить набор входных данных.
Очень упрощённо:
Посмотреть/послушать о такого рода применении метода можно здесь
Где логика?! История тестирования одного микросервиса (Денис Кудряшов, Leroy Merlin, 2020), где докладчик скомбинировал этот метод с вышеупомянутой
таблицей решений (Decision Table Testing).
Предугадывание ошибки (Error Guessing)
Это когда тест-аналитик/тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест-аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.
Исчерпывающее тестирование (Exhaustive Testing)
Бескомпромиссный случай -- в пределах этой техники вы должны проверить реакцию Системы на все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода часто не представляется возможным, из-за огромного количества входных значений.