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

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

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

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

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

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

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

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

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

Подробнее

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

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

Диаграмма состояния сущностей (State Transition Testing - STT)

TBD

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

TBD

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

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

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

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

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

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

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

Тест-кейс

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

(скачать схему в XML-формате draw.io)