Стр: 232/301
Создадим чек-лист и здесь же пропишем
примерное количество тест-кейсов
на каждый пункт из предположения, что мы будем проводить достаточно глубокое
тестирование этого требования:
•
Все параметры корректные {1 тест-кейс}.
•
Несуществующий/некорректный путь для:
o
SOURCE_DIR {3
тест-кейса};
o
DESTINATION_DIR {3
тест-кейса}.
•
Недопустимое имя файла LOG_FILE_NAME {3 тест-кейса}.
•
Значения SOURCE_DIR и DESTINATION_DIR являются корректными име-
нами существующих каталогов, но DESTINATION_DIR находится внутри
SOURCE_DIR {3
тест-кейса}.
•
Недопустимые/несуществующие имена объектов ФС указаны в более чем
одном параметре {5 тест-кейсов}.
•
Значения SOURCE_DIR и DESTINATION_DIR не являются корректными/су-
ществующими именами каталогов, и при этом DESTINATION_DIR находится
внутри SOURCE_DIR {3 тест-кейса}.
У нас получилось примерно 22 тест-кейса. Также давайте для большей пока-
зательности примера предположим, что часть тест-кейсов (например, 10) уже была
создана ранее.
Теперь сведём полученные данные в таблицу 2.6.a, где также отразим коли-
чество проходов. Этот показатель появляется из соображения, что некоторые тест-
кейсы будут находить дефекты, что потребует повторного выполнения тест-кейса
для верификации исправления дефекта; в некоторых случаях дефекты будут от-
крыты заново, что потребует повторной верификации. Это относится лишь к части
тест-кейсов, потому количество проходов может быть дробным, чтобы оценка была
более точной.
Количество проходов для тестирования новой функциональности в общем
случае можно грубо оценивать так:
•
Простая функциональность: 1–1.5 (не все тесты повторяются).
•
Функциональность средней сложности: 2.
•
Сложная функциональность: 3–5.
Таблица 2.6.a — Оценка количества создаваемых и выполняемых тест-кейсов
