Skip to content

Latest commit

 

History

History
125 lines (101 loc) · 18.4 KB

test-dizain-i-tekhniki-test-dizaina-test-design-and-software-testing-techniques.md

File metadata and controls

125 lines (101 loc) · 18.4 KB
Raw

Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques)

Проектирование теста (test design): Процесс перевода общих причин тестирования в конкретные тестовые условия и тестовые сценарии. (ISTQB)

Причина тестирования (test objective): Причина или цель разработки и выполнения теста. (ISTQB)

Тестовое условие (test condition): Объект или событие в компоненте или системе, которое должно быть проверено одним или несколькими тестовыми наборами. Например: функция, транзакция, свойство, атрибут качества или структурный элемент. (ISTQB)

Тест-дизайн - важный этап STLС, а именно деятельность по получению и определению тестовых примеров из test objectives и test conditions. Проще говоря, цель тест-дизайна - создать максимально эффективный набор кейсов, покрывающий наиболее важные аспекты тестируемого ПО, т.е. минимизировать количество тестов, необходимых для нахождения большинства серьезных ошибок.

Одним из наиболее важных аспектов теста является то, что он проверяет, выполняет ли система то, что она должна делать. Copeland говорит: “По сути, тестирование - это процесс сравнения того, что есть с тем, что должно быть”. Если мы просто введем какие-то данные и подумаем, что это было весело, я предполагаю, что с системой, вероятно, все в порядке, потому что она не крашнулась, но действительно ли мы ее тестируем? Beizer называет это «детским тестированием» (kiddie testing). Мы можем не знать каждый раз, какой правильный ответ в деталях, и иногда мы все равно можем получить некоторую выгоду от этого подхода, но на самом деле это не проверка. Чтобы знать, что система должна делать, нам нужен источник информации о правильном поведении системы - это называется «оракул» или тестовый оракул (test oracle). После того, как заданное входное значение было выбрано, тестировщику необходимо определить, каким будет ожидаемый результат ввода этого входа, и задокументировать его как часть тестового примера.

Давайте проясним. Требования или пользовательские истории с критериями приемлемости (формы test basis) определяют, что вы должны тестировать (test objects and test conditions), и исходя из этого, вы должны выяснить способ тестирования, то есть спроектировать тестовые примеры. Один из наиболее важных вопросов заключается в следующем: какие факторы влияют на успешный дизайн теста? Если вы читаете разные блоги, статьи или книги, вы найдете примерно следующее:

  • Время и бюджет, доступные для тестирования;
  • Соответствующие знания и опыт вовлеченных людей;
  • Определен целевой уровень покрытия (измерение уровня достоверности (measuring the confidence level));
  • Способ организации процесса разработки программного обеспечения (например, водопад или гибкая разработка);
  • Устанавливается соотношение методов создания тестов (например, ручных и автоматических);

Это неправда! Без достаточного времени и бюджета вы, вероятно, вообще не начнете ни одного проекта. Если у вас нет квалифицированных специалистов по тестированию программного обеспечения, включая дизайн тестов, то, вероятно, вы тоже не начнете проект. Однако, хороший дизайн теста включает три предварительных условия:

  • Полная спецификация (Complete specification)(test bases);
  • Анализ рисков и сложности (Risk and complexity analysis);
  • Исторические данные ваших предыдущих разработок;

Требуются некоторые пояснения. Полная спецификация не означает безошибочную спецификацию, так как во время разработки теста можно найти и исправить множество проблем (предотвращение дефектов). Это только означает, что у нас есть все необходимые требования или в Agile разработке у нас есть все эпики, темы и пользовательские истории с критериями приемлемости (acceptance criteria). Существует минимальная ценность в одновременном рассмотрении затрат на тестирование и затрат на исправление дефектов, и цель хорошего тест-дизайна - выбрать подходящие методы тестирования, приближающиеся к этому минимуму. Это можно сделать, проанализировав сложность, риски и используя исторические данные. Таким образом, анализ рисков неизбежен для определения тщательности тестирования. Чем выше риск использования функции / объекта, тем более тщательное тестирование необходимо. То же самое можно сказать и о сложности кода. Для более рискованного или сложного кода мы должны сначала применить больше НЕкомбинаторных методов проектирования тестов вместо одного чисто комбинаторного.

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

Еще одно важное замечание. Критерии выбора тестов и адекватности тестовых данных различны. Первый - неотъемлемая часть любой техники тест-дизайна. Второй проверяет набор тестов. В результате процесса разработки тестов создаются независимые от реализации тестовые примеры, которые проверяют требования или пользовательские истории. Напротив, тесты, которые создаются на основе отсутствия покрытия по выбранным критериям адекватности тестовых данных, подтверждают проблемы, зависящие от реализации; однако это НЕ дизайн теста, это создание теста. Очень важно использовать метод «сначала тестирование» (test-first method), т. е. дизайн теста должен быть отправной точкой разработки. Дизайн тестов также очень эффективен для предотвращения дефектов, если он применяется до внедрения.

Итак, хороший процесс тест-дизайна выглядит так:

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

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

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

  • Тест аналитик (test analyst) - определяет "ЧТО тестировать?":
    • Исследует продукт:
      • Понимание цели создания продукта;
      • Какими способами цель должна достигаться;
      • Какие и основные и вспомогательные возможности предоставляет продукт пользователям;
      • Оценка, правильно ли понял разработчик заказчика.
    • Составляет логическую карту продукта: Интеллект - карта - это техника представления любого процесса, события, мысли или идеи в систематизированной визуальной форме;
    • Разбивает программный продукт на основные части:
      • Система расчленяется только по одному, постоянному для всех уровней признаку (Они должны отвечать на один и тот же вопрос, по отношению к своему родителю);
      • Вычленяемые подсистемы должны взаимно исключать друг друга, а в сумме - характеризовать систему;
      • На каждом уровне рекомендуется использовать не более 7 подсистем;
    • Расставляет приоритеты для тестирования:
      • Требования клиента;
      • Степень риска;
      • Сложность системы;
      • Временные ограничения;
  • Тест дизайнер - определяет "КАК тестировать?";

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

Техники тест-дизайна (Software testing techniques)

  • Cтатические (Static):
    • Reviews:
      • Неформальное ревью (Informal review)
      • Прохождение (Walkthrough)
      • Техническое ревью (Technical Review)
      • Инспекция (Inspection)
    • Статический анализ (Static Analysis):
      • Поток данных (Data Flow)
      • Поток управления (Control Flow)
      • Путь (Path)
      • Стандарты (Standards)
  • Динамические (Dynamic):
    • Белый ящик (White-box, Structure-Based)
      • Выражение (Statement)
      • Решение (Decision)
      • Ветвь (Branch)
      • Условие (Condition)
      • Конечный автомат (FSM)
    • Основанные на опыте (Experience-based):
      • Предугадывание ошибки (Error Guessing - EG);
      • Исследовательское тестирование (Exploratory testing);
      • Ad-hoc testing;
      • Attack Testing;
    • Черный ящик (Black-box, Specification-based):
      • Эквивалентное Разделение (Equivalence Partitioning - EP)
      • Анализ Граничных Значений (Boundary Value Analysis - BVA)
      • Комбинаторные техники (Combinatorial Test Techniques)
      • Переходы между состояниями (State transition)
      • Случаи использования (Use case testing)
      • Domain testing
      • Decision Table Testing
      • Classification Tree Method
      • Cause-Effect Graphing
      • Scenario Testing
      • Random Testing
      • Syntax Testing
      • Check List Based Testing
      • Risk-Based Testing
      • User Journey Test

Источники:

Доп. материал: