Материал: Обеспечения Базовый курс (3е издание) Версия книги 2 от 17. 04. 2023

Свойства качественных тест-кейсов
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 142/301
Следующий пример тест-кейса не относится к нашему «Конвертеру файлов», но очень хорошо иллюстрирует эту мысль:
Плохо
Хорошо
1. Запустить приложение.
2. Выбрать в меню пункт «Файл».
3. Выбрать подпункт «Открыть».
4. Перейти в папку, в которой находится хотя бы один файл формата DOCX с тремя и более страницами.
1. Открыть DOCX-файл с тремя и более страни- цами.
И сюда же можно отнести ошибку с повторением одних и тех же приготовле- ний во множестве тест-кейсов (да, по описанным выше причинам в примерах мы снова вынужденно делаем так, как в жизни делать не надо). Куда удобнее объеди- нить тесты в набор
{146}
и указать приготовления один раз, подчеркнув, нужно или нет их выполнять перед каждым тест-кейсом в наборе.
Проблема с подготовительными (и финальными) действиями идеально решена в автоматизированном модульном тестировании
302
с использова- нием фреймворков наподобие JUnit или TestNG — там существует специ- альный «механизм фиксаций» (fixture), автоматически выполняющий ука- занные действия перед каждым отдельным тестовым методом (или их со- вокупности) или после него.
Неизбыточность по отношению к другим тест-кейсам. В процессе созда- ния множества тест-кейсов очень легко оказаться в ситуации, когда два и более тест-кейса фактически выполняют одни и те же проверки, преследуют одни и те же цели, направлены на поиск одних и тех же проблем. Способ минимизации количе- ства таких тест-кейсов подробно описан в главе «Виды и направления тестирова- ния
{67}
» (см. такие техники тестирования, как использование классов эквивалентно- сти
{94}
и граничных условий
{95}
).
Если вы обнаруживаете несколько тест-кейсов, дублирующих задачи друг друга, лучше всего или удалить все, кроме одного, самого показательного, или пе- ред удалением остальных на их основе доработать этот выбранный самый показа- тельный тест-кейс.
Демонстративность (способность демонстрировать обнаруженную
ошибку очевидным образом). Ожидаемые результаты должны быть подобраны и сформулированы таким образом, чтобы любое отклонение от них сразу же бро- салось в глаза и становилось очевидным, что произошла ошибка. Сравните вы- держки из двух тест-кейсов.
Выдержка из недемонстративного тест-кейса:
Шаги
Ожидаемые результаты
5.
Разместить в файле текст «Пример длин- ного текста, содержащего символы русского и английского алфавита вперемешку.» в ко- дировке KOI8-R (в слове «Пример» буквы
«р»
—
английские).
6.
Сохранить файл под именем «test. txt» и от- править файл на конвертацию.
7.
Переименовать файл в «test.txt».
6.
Приложение игнорирует файл.
7.
Текст принимает корректный вид в коди- ровке UTF-8 с учётом английских букв.
302
Unit testing (component testing). The testing of individual software components. [ISTQB Glossary]

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

Свойства качественных тест-кейсов
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 144/301
Пример прослеживаемого тест-кейса:
Требование
Модуль
Подмодуль
Шаги
Ожидаемые результаты
ДС-2.4
,
ДС-3.2
Стартер
Обработчик ошибок
Запуск с некоррект-
ными параметрами,
несуществующие
пути
1.
Запустить приложе- ние со всеми тремя параметрами, зна- чения которых ука- зывают на несуще- ствующие в файло- вой системе пути.
1.
В консоли отображаются нижеуказанные сообще- ния, приложение завер- шает работу. Сообщения a. SOURCE_DIR [
путь]: directory not exists or inaccessible. b. DESTINATION_DIR
[
путь]: directory not exists or inaccessible. c. LOG_FILE_NAME
[
имя]: wrong file name or inaccessible path.
Можно подумать, что этот тест-кейс затрагивает
ДС-2
и
ДС-3
целиком, но в поле «Требование» есть вполне чёткая конкретизация, к тому же указанные мо- дуль, подмодуль и сама логика тест-кейса устраняют оставшиеся сомнения.
Некоторые авторы также подчёркивают, что прослеживаемость тест-кейса связана с его неизбыточностью
{142}
по отношению к другим тест-кейсам (намного проще дать ссылку на один уникальный тест-кейс, чем выбирать из нескольких очень похожих).
Возможность повторного использования. Это свойство редко выполня- ется для низкоуровневых тест-кейсов
{121}
, но при создании высокоуровневых тест- кейсов
{120}
можно добиться таких формулировок, при которых:
• тест-кейс будет пригодным к использованию с различными настройками те- стируемого приложения и в различных тестовых окружениях;
• тест-кейс практически без изменений можно будет использовать для тести- рования аналогичной функциональности в других проектах или других обла- стях приложения.
Примером тест-кейса, который тяжело использовать повторно, может яв- ляться практически любой тест-кейс с высокой специфичностью.
Не самым идеальным, но очень наглядным примером тест-кейса, который может быть легко использован в разных проектах, может служить следующий тест- кейс:
Шаги
Ожидаемые результаты
Запуск, все параметры некорректны
1.
Запустить приложение, указав в качестве всех параметров заведомо некорректные значения.
1.
Приложение запускается, после чего выво- дит сообщение с описанием сути проблемы с каждым из параметров и завершает ра- боту.
Повторяемость. Тест-кейс должен быть сформулирован таким образом, чтобы при многократном повторении он показывал одинаковые результаты. Это свойство можно разделить на два подпункта:
• во-первых, даже общие формулировки, допускающие разные варианты вы- полнения тест-кейса, должны очерчивать соответствующие явные границы
(например: «ввести какое-нибудь число» — плохо, «ввести целое число в диапазоне от -273 до +500 включительно» — хорошо);
• действия (шаги) тест-кейса по возможности не должны приводить к необра- тимым (или сложно обратимым) последствиям (например: удалению данных, нарушению конфигурации окружения и т.д.) — не стоит включать в тест-кейс

Свойства качественных тест-кейсов
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 145/301 такие «разрушительные действия», если они не продиктованы явным обра- зом целью тест-кейса; если же цель тест-кейса обязывает нас к выполнению таких действий, в самом тест-кейсе должно быть описание действий по вос- становлению исходного состояния приложения (данных, окружения).
Соответствие принятым шаблонам оформления и традициям. С шабло- нами оформления, как правило, проблем не возникает: они строго определены име- ющимся образцом или вообще экранной формой инструментального средства управления тест-кейсами. Что же касается традиций, то они отличаются даже в раз- ных командах в рамках одной компании, и тут невозможно дать иного совета, кроме как «почитайте уже готовые тест-кейсы перед тем как писать свои».
В данном случае обойдёмся без отдельных примеров, т.к. выше и без того приведено много правильно оформленных тест-кейсов, а что касается нарушений этого свойства, то они прямо или косвенно описаны в главе «Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов»
{160}

Наборы тест-кейсов
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 146/301
2.4.6.
Наборы тест-кейсов
Терминология и общие сведения
Набор тест-кейсов (test case suite
303
, test suite, test set)
— совокупность тест-кейсов, выбранных с некоторой общей целью или по некоторому об- щему признаку. Иногда в такой совокупности результаты завершения од- ного тест-кейса становятся входным состоянием приложения для следую- щего тест-кейса.
Внимание! Из-за особенностей перевода очень часто вместо «набор тест- кейсов» говорят «тестовый сценарий». Формально это можно считать ошибкой, но это явление приобрело настолько широкое распространение, что стало вариантом нормы.
Как мы только что убедились на примере множества отдельных тест-кейсов, крайне неудобно (более того, это ошибка!) каждый раз писать в каждом тест-кейсе одни и те же приготовления и повторять одни и те же начальные шаги.
Намного удобнее объединить несколько тест-кейсов в набор или последова- тельность. И здесь мы приходим к классификации наборов тест-кейсов.
В общем случае наборы тест-кейсов можно разделить на свободные (поря- док выполнения тест-кейсов не важен) и последовательные (порядок выполнения тест-кейсов важен).
Преимущества свободных наборов:
• Тест-кейсы можно выполнять в любом удобном порядке, а также создавать
«наборы внутри наборов».
• Если какой-то тест-кейс завершился ошибкой, это не повлияет на возмож- ность выполнения других тест-кейсов.
Преимущества последовательных наборов:
• Каждый следующий в наборе тест-кейс в качестве входного состояния при- ложения получает результат работы предыдущего тест-кейса, что позволяет сильно сократить количество шагов в отдельных тест-кейсах.
• Длинные последовательности действий куда лучше имитируют работу ре- альных пользователей, чем отдельные «точечные» воздействия на приложе- ние.
Пользовательские сценарии (сценарии использования)
В данном случае речь НЕ идёт о use cases (вариантах использования), представляющих собой форму требований
{39}
. Пользовательские сцена- рии как техника тестирования куда менее формализованы, хотя и могут строиться на основе вариантов использования.
К отдельному подвиду последовательных наборов тест-кейсов (или даже неоформленных идей тест-кейсов, таких, как пункты чек-листа) можно отнести пользовательские сценарии
304
(или сценарии использования), представляющие со- бой цепочки действий, выполняемых пользователем в определённой ситуации для достижения определённой цели.
303
Test case suite (test suite, test set). A set of several test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one. [ISTQB Glossary]
304
A scenario is a hypothetical story, used to help a person think through a complex problem or system. [Cem Kaner,
«An Introduction to Scenario Testing
», http://kaner.com/pdfs/ScenarioIntroVer4.pdf
]

Наборы тест-кейсов
Тестирование программного обеспечения. Базовый курс.
© EPAM Systems, 2015–2023
Стр: 147/301
Поясним это сначала на примере, не относящемся к «Конвертеру файлов».
Допустим, пользователь хочет распечатать табличку на дверь кабинета с текстом
«Идёт работа, не стучать!» Для этого ему нужно:
1)
Запустить текстовый редактор.
2)
Создать новый документ (если редактор не делает это самостоятельно).
3)
Набрать в документе текст.
4)
Отформатировать текст должным образом.
5)
Отправить документ на печать.
6)
Сохранить документ (спорно, но допустим).
7)
Закрыть текстовый редактор.
Вот мы и получили пользовательский сценарий, пункты которого могут стать основой для шагов тест-кейса или целого набора отдельных тест-кейсов.
Сценарии могут быть достаточно длинными и сложными, могут содержать внутри себя циклы и условные ветвления, но при всём этом они обладают рядом весьма интересных преимуществ:
• Сценарии показывают реальные и понятные примеры использования про- дукта (в отличие от обширных чек-листов, где смысл отдельных пунктов мо- жет теряться).
• Сценарии понятны конечным пользователям и хорошо подходят для обсуж- дения и совместного улучшения.
• Сценарии и их части легче оценивать с точки зрения важности, чем отдель- ные пункты (особенно низкоуровневых) требований.
• Сценарии отлично показывают недоработки в требованиях (если становится непонятно, что делать в том или ином пункте сценария, — с требованиями явно что-то не то).
• В предельном случае (нехватка времени и прочие форс-мажоры) сценарии можно даже не прописывать подробно, а просто именовать — и само наиме- нование уже подскажет опытному специалисту, что делать.
Последний пункт проиллюстрируем на примере. Классифицируем потенци- альных пользователей нашего приложения (напомним, что в нашем случае «поль- зователь» — это администратор, настраивающий работу приложения) по степени квалификации и склонности к экспериментам, а затем дадим каждому «виду поль- зователя» запоминающееся имя.
Таблица 2.4.a — Классификация пользователей