Основные понятия

Техники тест дизайна

Техники тест дизайна

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

Основные техники тест дизайна:

  • Верификация - это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа.
  • Валидация - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. Верификация и валидация являются одними из техник тест дизайна.
  • Positive\ negative testing. Заключается в тестировании позитивных и негативных сценариев. Порядок тестирования такой: сначала проверяем позитивные сценарии, и только потом негативные. Позитивный тестовый случай использует только корректные данные и проверяет, что программа работает так, как и полагается, при условии, что пользователь вносит корректные данные и не выходит за рамки предусмотренного сценария поведения.
  • Эквивалентное разделение (Equivalence Partitioning - EP), классы эквивалентности (equivalent classes-EC) Например, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала - 0.
  • Анализ граничных Значений (Boundary Value Analysis – BVA) Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам и другим параметрам, имеющим ограничения. Чтобы удостовериться в правильности поведения программы при различных входных данных, в идеале следует протестировать все возможные значения для каждого элемента этих данных.

Чтобы уменьшить количество тестируемых значений, производится:

1. Разбиение множества всех значений входной переменной на подмножества (классы эквивалентности)

2. Тестирование одного любого значения из каждого класса

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

Таким образом, метод классов эквивалентности можно разделить на три этапа:

1. Тестирование разрешенных значений

2. Тестирование граничных значений

3. Тестирование запрещенных значений.

  • Причина/ Следствие (Cause/Effect - CE). Это ввод комбинаций условий (причин), для получения ответа от системы (следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как "Имя", "Адрес", "Номер Телефона" а затем, нажать кнопку "Добавить" - эта "Причина". После нажатия кнопки "Добавить", система добавляет клиента в базу данных и показывает его номер на экране - это "Следствие".
  • Предугадывание ошибки (Error Guessing - EG) Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.
  • Исчерпывающее тестирование (Exhaustive Testing - ET). Используется крайне редких случаях. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в результате, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.
  • Попарное тестирование (Pairwise testing). Метод классов эквивалентности применяется для тестирования каждого входного параметра по отдельности. Пусть наша программа принимает на вход десяток параметров. Дефекты, возникающие при определенном сочетании всех десяти параметров, довольно редки. Взаимное влияние параметров, о котором пользователь не знает - это дефект интерфейса (интерфейс интуитивно не понятен). Чаще всего будут встречаться ситуации, в которых один параметр влияет на один из оставшихся, т.е. самыми частыми будут дефекты, возникающие при определенном сочетании двух каких-то параметров. Таким образом, можно упростить себе задачу и протестировать все возможные значения для каждой из пар параметров. Такой подход называется попарным тестированием (pairwise testing). 
  • ADHOC testing. Это тестирование без подробных спецификаций, сопроводительных документов, тест плана и т.д. Другими словами, тестирование в полном хаосе. Преимущество такой техники в том, что нет необходимости в планировании и документации, наиболее важные ошибки находятся быстро, нет задержек со стартом проекта.
  • Дымовое (Smoke testing). Понятие дымовое тестирование пошло из инженерной среды: "При вводе в эксплуатацию нового оборудования ("железа") считалось, что тестирование прошло удачно, если из установки не пошел дым." В области же программного обеспечения, дымовое тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.

© 2021 QAstart.by