Стр: 143/301
Выдержка из демонстративного тест-кейса:
Шаги Ожидаемые результаты 5.
Разместить в файле текст «Ё╥╔═┼╥
╘┼╦╙╘┴.» (Эти символы представляют со-
бой словосочетание «Пример текста.» в коди-
ровке KOI8-R, прочитанной как CP866).
6.
Отправить файл на конвертацию.
6.
Текст принимает вид: «Пример текста.»
(кодировка UTF8).
В первом случае тест-кейс плох не только расплывчатостью формулировки
«корректный вид в кодировке UTF-8 с учётом английских букв», там также очень
легко допустить ошибки при выполнении:
•
забыть сконвертировать вручную входной текст в KOI8-R;
•
не заметить, что в первый раз расширение начинается с пробела;
•
забыть заменить в слове «Пример» буквы «р» на английские;
•
из-за расплывчатости формулировки ожидаемого результата принять оши-
бочное, но выглядящее правдоподобно поведение за верное.
Второй тест-кейс чётко ориентирован на свою цель по проверке конвертации
(не содержит странной проверки с игнорированием файла с неверным расшире-
нием) и описан так, что его выполнение не представляет никаких сложностей, а лю-
бое отклонение фактического результата от ожидаемого будет сразу же заметно.
Прослеживаемость. Из содержащейся в качественном тест-кейсе информа-
ции должно быть понятно, какую часть приложения, какие функции и какие требо-
вания он проверяет. Частично это свойство достигается через заполнение соответ-
ствующих полей тест-кейса
{124}
(«Ссылка на требование», «Модуль», «Подмодуль»),
но и сама логика тест-кейса играет не последнюю роль, т.к. в случае серьёзных
нарушений этого свойства можно долго с удивлением смотреть, например, на какое
требование ссылается тест-кейс, и пытаться понять, как же они друг с другом свя-
заны.
Пример непрослеживаемого тест-кейса:
