Слайд 2State Transition Testing
ТЕСТИРОВАНИЕ СОСТОЯНИЙ И ПЕРЕХОДОВ
Слайд 3Спецификация
*1 сущность и 1 процесс
Слайд 4Слабое покрытие – пройти СТАТУС хотя бы раз
1) Draft > Canceled
2)
Draft > Active > Withdrawn
3) Draft > Active > Decision Made
Слайд 5Слабое покрытие – пройти каждый ПЕРЕХОД (стрелки) хотя бы раз
1) Draft
> Canceled
2) Draft > Active > Withdrawn > Re-submit
3) Draft > Active > Decision Made
3) Draft > Active > Decision Made > Active
Слайд 6Хорошее покрытие – проверить все СОБЫТИЯ хотя бы раз
1) Draft >
Canceled
2) Draft > Active > Withdrawn
3) Draft > Active > Withdrawn > Active
3) Draft > Active > Decision Made (Recruiter: Not a Fit)
4) Draft > Active > Decision Made (Recruiter: Not Selected)
5) Draft > Active > Decision Made (Recruiter: Hired)
6) 5) Draft > Active > Decision Made > Active
Слайд 7Идеальное покрытие – проверить все ПУТИ хотя бы раз
1) Draft >
Canceled
2) Draft > Active
3) Draft > Active > Withdrawn
4) Draft > Active > Decision Made (Recruiter: Not a Fit)
5) Draft > Active > Decision Made (Recruiter: Not Selected)
6) Draft > Active > Decision Made (Recruiter: Hired)
7) Draft > Active > Withdrawn > Active
8) Draft > Active > Decision Made > Active
9) + циклы
Слайд 9Улучшение техники
1) Роли
2) Действия + Стандартные действия (Редактирование, Удаление)
3) Условия (наличие
комментариев, есть вопросы к кандидату)
4) События (самой системы - таймер)
Слайд 14Cause-Effect graphing (Ishikawa diagram)
Слайд 19Random Testing:
Определить все возможные входные данные для компонента
Выбрать функцию распределения данных,
основываясь на ожидаемом или известном распределении входных значений
Входные данные для тест кейса выбираются случайно, согласно функции распределения входных значений
Формат тест кейса:
Входные значения
Ожидаемое поведение системы
Использованная функция распределения
Слайд 20White Box:
Control Flow Testing
1. Определить все возможные пути
выполнения кода в
компоненте
2. Выполнить тесты покрывающие
пути выполнения
Слайд 21White Box:
Data Flow Testing
Подход похож на Control Flow Testing,
только
рассматриваются
не логические ветвления программы,
а жизненный цикл переменных.
Слайд 22Непротиворечивость
1) Отсутствие проверок противоречащих требованиям или друг другу
2) Отсутствие дублирующих проверок
Слайд 23Содержимое проверок
Краткий, емкий, не повторяющийся Summary. Из Summary должно быть понятно,
что проверяется в рамках данного тест кейса
Есть Preconditions, если нужны. В них правильно указаны подготовительные действия и тестовые данные, необходимые для выполнения тест кейса
Четкие и понятные шаги. Четко определено действие, которое необходимо выполнить, понятно, как его выполнить, нет пропущенных или избыточных шагов
1 кейс (или 1 шаг) = 1 проверка = 1 ожидаемый результат
Четкий и понятный Expected Result. Указан результат, который можно проверить "здесь и сейчас" (например, в UI нельзя проверить, что "данные корректно записались в БД");
Слайд 24Название кейса\проверки
Check clicking compose button (пер. Проверить нажатие кнопки Compose)
-> Составление 1 документа из двух PDF документов
Check with allow pool == No (пер. Проверка с pool ==0) -> Добавление пользователя без возможности использования пула
Создание пользователя с отрицательным весом –> Невозможность создания пользователя с отрицательным весом
Слайд 31Оформление
Отсутствие ошибок правописания, ошибок в названиях полей, форм и других элементов
приложения
Аккуратный внешний вид
Следование единому шаблону документа (если есть)
Слайд 32Соблюдение процесса
В случае использования документа Excel шапка документа и информация по
билдам заполнена актуальными данными (кто тестировал, когда, какой тип теста, окружение, билд)
Нет проверок (тест кейсов) passed на которые залинкованы дефекты*
Нет проверок (тест кейсов) failed/blocked на которых нет залинкованных дефектов
Если проверка (тест кейс) в статусе blocked, то должно быть понятно каким именно дефектом она заблокирована
В случае использования документа Excel для failed проверок (тест кейсов) проставлены результаты = дефекту с наибольшим Severity*