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

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

Роли, ответственные за тест дизайн:

  • Тест-аналитик -- определяет "ЧТО тестировать?"
  • Тест-дизайнер -- определяет "КАК тестировать?"

Тест-кейс

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

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

Пример оформления: http://www.protesting.ru/documentation/test_case_example.zip

Методы разработки тестов

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

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

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

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


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

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

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

Тестирование состояния сущностей (State Transition Testing - STT)

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

скачать схему в формате diagrams.net (бывший draw.io)
Подробнее: Тестирование на основе диаграмм состояний сущности (2015).

Деревья классификации (Classification Tree - CT)

TBD

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

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

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

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

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

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

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