Тест - дизайн - этап тестирования ПО, на котором проектируются и создаются тестовые случаи в соответствии с определенными ранее критериями качества и целями тестирования.

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

Верификация - процесс оценки системы и ее компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этапа.

Валидация - определение соответсвия разрабатываемого ПО ожиданиям и потребностям прользователя, требованиям к системе.

Позитивное/негативное тестирование - заключается в проведении тестирования позитивных и негативных сценариев. Порядок тестирования: сначала позитивные сценарии, затем негативные. Позитивный тестовый случай использует только корректные данные и проверяет. что программа работает так, так полагается при условиях. что пользовтель вносит только правильные данные и не выходит за рамки предусмотренного сценария поведения.

Эквивалентное разделение/классы эквивалентности. Например, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала - 0.

Анализ граничных значений. Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничных значений может быть применен к полям, записям, файлам и другим параметрам, имеющим ограничения. Чтобы удостовериться в правильности поведения программы при различных входных данных, в идеале следует протестировать все возможные значения для каждого элемента этих данных.
Чтобы уменьшить количество тестируемых значений, производится:

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

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

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

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

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

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

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

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

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

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

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

ADHOK- тестирование. Это тестирование без подробных спецификаций, сопроводительных документов, тест плана и т.д. Другими словами, тестирование в полном хаосе. Преимущество такой техники в том, что нет необходимости в планировании и документации, наиболее важные ошибки находятся быстро, нет задержек со стартом проекта.

Дымовое тестирование. Понятие дымовое тестирование пошло из инженерной среды: "При вводе в эксплуатацию нового оборудования ("железа") считалось, что тестирование прошло удачно, если из установки не пошел дым." В области же программного обеспечения, дымовое тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.