Добавил:
выбрасываю тут свой мусор, надеюсь, что он кому-то может пригодится... Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
OOP-KONEChNYJ.docx
Скачиваний:
20
Добавлен:
03.12.2023
Размер:
7.72 Mб
Скачать

49. Назначение правила разработки тестовых случаев (test case) и тестовых комплектов

Основная единица: Test Case – набор условий, при котором тестировщик будет определять: удовлетворять или не удовлетворять определенному перечню специализаций.

Test Case – профессиональная документация тестирования, описывающая последовательность действий, направленная на проверку некоторого функционала.

Любой Test Case включает в себя:

  1. уникальный индентификатор

  2. название

  3. предусловия

  4. шаги

  5. Определенный результат

Должен приводить к результату:

  1. Фактический результат – тест пройден

  2. Отрицательный результат – ожидаемый результат не совпадает с фактическим

  3. Вызвано исключение, не обрабатываемое в коде– тест не прошел

Test Case должны быть незавсимыми.

Есть 4 приоритета TestCase 1-4, 1 - наивысший:

Наивысший приоритет – приоритет, который связан с критической функциональностью.

Test Suit – тысты, кот. Описаны в документации.

Test Plan – описывает какие работы д/б выполнены.

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

Под тест кейсом понимается структура вида:

Action > Expected Result > Test Result

Пример:

Action

Expected Result

Test Result

(passed/failed/blocked)

Open page "login"

Login page is opened

Passed

Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:

  • Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.

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

Каждый тест кейс должен иметь 3 части:

  • PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.

  • Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям

  • PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)

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

Соседние файлы в предмете Объектно-ориентированное программирование