Title: SFT.EXT.

05-06 Разработка тестов и тестовых сценариев Confidential

Saved: 26-Feb-2019 10:29

EPAM Systems, RD Dep.

Конспект и раздаточный материал

SFT.EXT.06-08 Разработка тестов и

тестовых сценариев

REVISION HISTORY

Approved
Ver. Description of Change Author Date
Name Effective Date

<1.0> Первая версия Святослав Куликов <24.07.2015>

<1.1> Согласование с книгой, Мария Федорова <26.02.2019>

Jira

This document contains privileged and/or confidential information and may not be disclosed,
Legal Notice
distributed or reproduced without the prior written permission of EPAM Systems.

© EPAM Systems, RD Dep., 2019 Page: 1/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

Содержание
1. Определения 3
2. Оформление тест-кейсов 7
3. Свойства качественных тест-кейсов 11
4. Процесс разработки тестов 15
5. Наборы тест-кейсов 15
6. Пример разработки тест-кейсов 16

© EPAM Systems, 2019 Page: 2/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

1. Определения
Чек-лист (checklist) – набор идей [для написания тест-кейсов].
Это документ, который описывает, что должно быть протестировано. При этом чек-лист
может быть абсолютно разного уровня детализации. Детализация будет зависеть от
требований к отчетности, уровня знаний продукта и сложности продукта. Чек-лист позволяет не
забыть про важные тесты, фиксировать результаты своей работы и отслеживать статистику по
статусу программного продукта.
Важно понять, что нет и не может быть никаких запретов и ограничений при разработке
чек-листов — главное, чтобы они помогали в работе. Иногда чек-листы могут даже выражаться
графически (например, с использованием ментальных карт или концепт-карт), хотя
традиционно их составляют в виде многоуровневых списков.
Важные свойства чек-листа:
• Логичность. Чек-лист пишется не «просто так», а на основе целей и для того,
чтобы помочь в достижении этих целей.
• Последовательность и структурированность. Со структурированностью всё
достаточно просто — она достигается за счёт оформления чек-листа в виде
многоуровневого списка. Что до последовательности, то даже в том случае, когда
пункты чек-листа не описывают цепочку действий, человеку всё равно удобнее
воспринимать информацию в виде неких небольших групп идей, переход между
которыми является понятным и очевидным.
• Полнота и неизбыточность. Чек-лист должен представлять собой аккуратную
«сухую выжимку» идей, в которых нет дублирования (часто появляется из-за
разных формулировок одной и той же идеи), и в то же время ничто важное не
упущено.
Разбивайте чек-листы на группы для:
• типичных пользовательских сценариев;
• различных уровней функционального тестирования;
• отдельных частей (модулей и подмодулей) приложения;
• отдельных требований, групп требований, уровней и типов требований;
• частей или функций приложения, наиболее подверженных рискам.

Тест (test) — набор из одного или нескольких тест-кейсов.

Поскольку среди всех прочих терминов этот легче и быстрее всего произносить, в
зависимости от контекста под ним могут понимать и отдельный пункт чек-листа, и отдельный
шаг в тест-кейсе, и сам тест-кейс, и набор тест-кейсов и… продолжать можно долго. Главное
здесь одно: если вы слышите или видите слово «тест», воспринимайте его в контексте.
Тест-кейс (test case) – набор входных данных, условий выполнения и ожидаемых
результатов, разработанный с целью проверки того или иного свойства или поведения
программного средства.
Под тест-кейсом также может пониматься соответствующий документ, представляющий
формальную запись тест-кейса. Иногда термин «test case» на русский язык переводят как
«тестовый случай».
Высокоуровневый тест-кейс (high level test case, logical test case) — тест-кейс без
конкретных входных данных и ожидаемых результатов.

© EPAM Systems, 2019 Page: 3/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

Как правило, ограничивается общими идеями и операциями, схож по своей сути с

подробно описанным пунктом чек-листа. Достаточно часто встречается в ин-теграционном
тестировании и системном тестировании, а также на уровне дымового тестирования. Может
служить отправной точкой для проведения исследовательского тестирования или для создания
низкоуровневых тест-кейсов.
Низкоуровневый тест-кейс (low level test case) — тест-кейс с конкретными входными
данными и ожидаемыми результатами.
Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является
наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать
именно такие тесты, т.к. прописать все данные подробно — намного проще, чем понять, какой
информацией можно пренебречь, при этом не снизив ценность тест-кейса.
Спецификация тест-кейса (test case specification) — документ, описывающий набор тест-
кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые
результаты) для тестируемого элемента (test item, test object).
Спецификация теста (test specification) — документ, состоящий из спецификации тест-
дизайна (test design specification), спецификации тест-кейса (test case specification) и/или
спецификации тест-процедуры (test procedure specification).
Тест-сценарий (test scenario, test procedure specification, test script) — документ,
описывающий последовательность действий по выполнению теста (также известен как «тест-
скрипт»).
Набор тест-кейсов (test suite, test set) – совокупность тест-кейсов, для тестирования
компонента или системы, выбранных таким образом, что состояние системы при завершении
одного теста чаще всего является состоянием (предварительным условием) для начала другого.
Цель написания тест-кейсов
• Структурировать и систематизировать подход к тестированию (без чего крупный проект
почти гарантированно обречён на провал).
• Вычислять метрики тестового покрытия (test coverage metrics) и принимать меры по его
увеличению (тест-кейсы здесь являются главным источником информации, без которого
существование подобных метрик теряет смысл).
• Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится
тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе
количества и т.д.).
• Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками
(тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем
это отражено в требованиях).
• Хранить информацию для длительного использования и обмена опытом между
сотрудниками и командами (или как минимум — не пытаться удержать в голове сотни
страниц текста).
• Проводить регрессионное тестирование и повторное тестирование (которые без тест-
кейсов было бы вообще невозможно выполнить).
• Повышать качество требований (мы это уже рассматривали: написание чек-листов и
тест-кейсов — хорошая техника тестирования требований).
• Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту.

© EPAM Systems, 2019 Page: 4/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

Статусы тест-кейса

Каждая компания может использовать свои собственные статусы тест-кейса в

зависимости от особенностей проекта. К примеру:

Не выполнен (untested) —нахождение тест-кейса в данном состоянии означает, что он

готов к выполнению, но ещё не был выполнен. В некоторых системах управления тест-кейсами
это состояние заменяет собой «запланирован» (planned, ready for testing) и «создан» (new).

Провален (failed) — данное состояние означает, что в процессе выполнения тест-кейса

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

Пройден успешно (passed) — данное состояние означает, что в процессе выполнения

тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и
фактических результатов его шагов.

Заблокирован (blocked) — данное состояние означает, что по какой-то причине

выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта,
не позволяющего реализовать некий пользовательский сценарий).
Не покрывается тестированием (Out of scope) — тест-кейс попадает под категорию не
тестируемых областей приложения (вспомните тест план и то, что в нем описываются части ПО,
которые не будут тестироваться).

© EPAM Systems, 2019 Page: 5/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

Задача Гленфорда Майерса о треугольнике

Программа на C (32-битный компилятор под Win32) производит чтение из командной
строки трёх целых чисел, которые интерпретируются как длины сторон треугольника. Далее
программа выводит в консоль сообщение о том, является ли треугольник неравносторонним,
равнобедренным или равносторонним.

Ответ Гленфорда Майерса

Запишите сами ☺

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

© EPAM Systems, 2019 Page: 6/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

Помните о рекомендуемой последовательности разработки и выполнения тест-кейсов:

● Простые позитивные.
● Простые негативные.
● Сложные позитивные.
● Сложные негативные.

Если остаётся время, занимайтесь исследовательским тестированием.

2. Оформление тест-кейсов

Общий вид тест-кейса

Оформление тест-кейса зависит от системы, в которой их ведут. Вышеуказанный вид

наиболее удобен, если тест-кейсы хранят в excel.

Пример из Jira:

© EPAM Systems, 2019 Page: 7/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

© EPAM Systems, 2019 Page: 8/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

Домашнее задание: Попробуйте ограниченную во времени бесплатную версию Jira для

создания тест-кейсов. https://www.atlassian.com/try

Детальнее про поля тест-кейса.

Идентификатор (identifier) представляет собой уникальное значение, позволяющее

однозначно отличить один тест-кейс от другого и используемое во всевозможных ссылках.
• Уникальный.
• Осмысленный (если позволяет ПО).

Приоритет (priority) показывает важность тест-кейса

• Показывает важность тест-кейса.
• Может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне
высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным
способом.
• Должен коррелировать с:
o важностью требования;
o потенциальной важностью дефекта, на поиск которого направлен тест-кейс.
o степенью риска, связанного с проверяемым тест-кейсом требованием, сценарием
или функцией.
Основная задача этого атрибута — упрощение распределения внимания и усилий
команды (более высокоприоритетные тест-кейсы получают их больше), а также упрощение
планирования и принятия решения о том, чем можно пожертвовать в некоей форс-мажорной
ситуации, не позволяющей выполнить все запланированные тест-кейсы.

© EPAM Systems, 2019 Page: 9/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

Кто выставляет приоритет и почему? Как он(а) принимает решение?

Запишите сами ☺

Связанное с тест-кейсом требование (requirement)

• Показывает то основное требование, проверке выполнения которого посвящён тест-
кейс.
• Наличие этого поля улучшает такое свойство тест-кейса как прослеживаемость.

Модуль и подмодуль приложения (module and submodule)

• Указывают на части приложения, к которым относится тест-кейс и позволяют лучше
понять его цель.
• Модуль и подмодуль приложения – это НЕ действия, это именно структурные части,
«куски» приложения. Сравните (на примере человека): «дыхательная система, лёгкие» –
это модуль и подмодуль, а «дыхание», «сопение», «чихание» – нет; «голова, мозг» – это
модуль и подмодуль, а «кивание», «думание» – нет. Как правило, иерархия модулей и
подмодулей создаётся как единый набор для всей проектной команды
• Наличие полей «Модуль» и «Подмодуль» улучшает такое свойство тест-кейса, как
прослеживаемость.

Заглавие (суть) тест-кейса (summary)

• Призвано упростить быстрое понимание основной идеи тест-кейса без обращения к его
остальным атрибутам. Т.е. должен кратко отображать цели, что проверяет тест кейс.
• Именно это поле является наиболее информативным при просмотре списка тест-кейсов.
• Заглавие всегда должно быть! У каждого тест-кейса! Ни при каких условиях
категорически не допускается наличие тест-кейсов без заглавий!

Исходные данные, приготовления (precondition, preparation, initial data, setup)

• Позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-
кейса, например, состояние базы данных, состояние файловой системы и её объектов и
т.д. Как вариант предусловия могут быть выполнение набора или одного тест-кейса,
который приводит приложение в определённое состояние.
• Если говорить, например, о подготовке окружающей среды, то всё, что описывается в
этом поле, готовится БЕЗ использования тестируемого приложения. Соответственно,
если здесь возникают проблемы, нельзя писать отчёт о дефекте, который был выявлен в
процессе прохождения данного тест-кейса (если причиной стало состояние БД, тоже
нужно писать о дефекте, но в БД). Аналогично, если условием появления дефекта
является тест-кейс из предусловия, то нужно писать отчет, именно к тому тест-кэйсу.

Шаги тест-кейса (steps) и ожидаемые результаты (expected results)

• Шаги тест-кейса описывают последовательность действий, которые необходимо
реализовать в процессе выполнения тест-кейса.
© EPAM Systems, 2019 Page: 10/16
Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

• Ожидаемые результаты по каждому шагу тест-кейса описывают реакцию приложения на

действия, описанные в поле «шаги тест-кейса».
• Номер шага соответствует номеру результата.

Язык написания тест-кейсов

• Начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск
приложения, очевидные операции с интерфейсом и т.п.);
• Используйте активный залог («open», «paste», «click»). В русском языке используйте
безличную форму (например, «открыть» вместо «откройте»).
• Описывайте объективно проверяемое поведение системы: «появляется окно…»,
«приложение закрывается».
• Используйте простой технический стиль.
• ОБЯЗАТЕЛЬНО указывайте ТОЧНЫЕ названия всех элементов приложения.
• Не объясняйте базовые понятия работы с ОС.
• Даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в
будущем случайно «приклеить» описание этого шага к новому тексту)
• Соотносите степень детализации шагов и их параметров с целью тест-кейса, его
сложностью, уровнем и т.д. — в зависимости от этих и многих других факторов степень
детализации может варьироваться от общих идей до пре-дельно чётко прописанных
значений и указаний;
• Ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста
(например, «повторить шаги 3–5 со значением…»);
• Пишите шаги последовательно, без условных конструкций вида «если… то…»
• Стандарты написания тест-кейсов очень важны в проектах, в которых их много и много
тестеровщиков. Должен быть Single writing style, иногда вплоть до того что кнопки
пишутся в двойных кавычках, дропдауны в одинарных, и тд.
• Категорически запрещено ссылаться на шаги из других тест-кейсов и другие тест-кейсы
целиком: если те, другие тест-кейсы будут изменены или удалены, ваш тест-кейс начнёт
ссылаться на неверные данные или в пустоту, а если в процессе выполнения те, другие
тест-кейсы или шаги приведут к возникновению ошибки, вы не сможете закончить
выполнение вашего тест-кейса.
• В ожидаемых результатах ВСЕГДА описывается КОРРЕКТНАЯ работа приложения. Нет и
не может быть ожидаемого результата в виде «приложение вызывает ошибку в
операционной системе и аварийно завершается с потерей всех пользовательских
данных». При этом корректная работа может заключатся в отображении сообщения об
ошибочных действиях пользователя.
В качестве ожидаемого результата может быть как конечный результат, так и результат
каждого шага. В последнем случае следует соблюдать нумерацию шагов и соответствующих
им ожидаемых результатов.

3. Свойства качественных тест-кейсов

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

© EPAM Systems, 2019 Page: 11/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

В случае излишней специфичности:

• при повторных выполнениях тест-кейса всегда будут выполняться строго одни и те же
действия, что снижает вероятность обнаружить ошибку;
• возрастает время создания и поддержки тест-кейса.

В случае излишней общности:

• тест-кейс сложен для начинающих тестировщиков;
• тест-кейс вполне может остаться невыполненным по ряду объективных и субъективных
причин.

• Здесь мы не привязаны к конкретным значениям.

• Мы знаем, как проверить результат.
• Мы сокращаем время написания и поддержки тест-кейса ссылкой на шаги 1-4.
• Мы перечислили значения, представляющие для нас особый интерес.

Баланс между простотой и сложностью

Простой тест-кейс оперирует одним объектом (или в нём явно виден главный объект), а
также содержит небольшое количество тривиальных действий
Сложный тест-кейс оперирует несколькими равноправными объектами и содержит
много нетривиальных действий.

Простота и сложность сами по себе ничем не плохи. Проблемы начинаются с излишней

© EPAM Systems, 2019 Page: 12/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

простотой и излишней сложностью.

Преимущества простых тест-кейсов:

• Их легко выполнять.
• Они понятны новичкам.
• Они упрощают диагностику ошибки.
• Они делают наличие ошибки очевидным.

Преимущества сложны тест-кейсов:

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

Следует постепенно повышать сложность тест-кейсов.

«Показательность» (высокая вероятность обнаружения ошибки).

© EPAM Systems, 2019 Page: 13/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

Последовательность в достижении цели. Отсутствие лишних действий. Суть этого

свойства выражается в том, что все действия в тест-кейсе направлены на следование единой
логике и достижение единой цели и не содержат никаких отклонений.

Неизбыточность по отношению к другим тест-кейсам. В процессе созда-ния множества

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

Демонстративность (способность демонстрировать обнаруженную ошибку очевидным

образом). Ожидаемые результаты должны быть подобраны и сформулированы таким образом,
чтобы любое отклонение от них сразу же бро-салось в глаза и становилось очевидным, что
произошла ошибка.

Прослеживаемость. Из содержащейся в качественном тест-кейсе информации должно

быть понятно, какую часть приложения, какие функции и какие требования он проверяет.
Частично это свойство достигается через заполнение соответствующих полей тест-кейса{121}
(«Ссылка на требование», «Модуль», «Подмодуль»), но и сама логика тест-кейса играет не
последнюю роль, т.к. в случае серьёзных нарушений этого свойства можно долго с удивлением
смотреть, например, на какое требование ссылается тест-кейс, и пытаться понять, как же они
друг с другом связаны.

Возможность повторного использования

Независимость
Независимые тест-кейсы не ссылаются ни на какие другие.
Связанные тест-кейсы явно или неявно (в рамках набора) ссылаются на другие (как
правило, на предыдущий).

Преимущества независимых тест-кейсов:

• Легко и просто выполнять.
• Могут работать даже после сбоя приложения на других тест-кейсах.
• Можно группировать любым образом и выполнять в любом порядке.

Преимущества связанных тест-кейсов и наборов тест-кейсов:

• Имитируют работу реальных пользователей.
Соответствие принятым шаблонам оформления и традициям.

Домашнее задание «на подумать»

Как отправить на сервер (по протоколу HTTP) файл с именем «%^##76 / // \ ^^ [ ] : .jpg»?
Этот файл ТОЧНО нельзя создать ни в одной файловой системе. Но отправить файл с
таким именем можно. Как?

© EPAM Systems, 2019 Page: 14/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

4. Процесс разработки тестов

1. Начинайте как можно раньше, ещё до выхода первого билда.

2. Разбивайте приложение на отдельные части/модули.
3. Для каждой области/модуля пишите чек-лист.
4. Пишите вопросы, уточняйте детали, добавляйте «косметику», используйте copy-paste.
5. Получите рецензию коллег-тестировщиков, разработчиков, заказчиков.
6. Обновляйте тест-кейсы, как только обнаружили ошибку или изменилась
функциональность.

5. Наборы тест-кейсов

Набор тест-кейсов (test case suite, test suite, test set) – совокупность тест-кейсов,
выбранных с некоторой общей целью или по некоторому общему признаку.
Иногда в такой совокупности результаты завершения одного тест-кейса становятся
входным состоянием приложения для следующего тест-кейса.
Внимание! Из-за особенностей перевода очень часто вместо «набор текст-кейсов»
говорят «тестовый сценарий», но это все же разные вещи.

Свободные наборы – порядок выполнения тест-кейсов не важен.

Последовательные наборы – порядок выполнения тест-кейсов важен.
Преимущества свободных наборов:
• Тест-кейсы можно выполнять в любом удобном порядке, а также создавать «наборы
внутри наборов».
• Если какой-то тест-кейс завершился ошибкой, это не повлияет на возможность
выполнения других тест-кейсов.

Преимущества последовательных наборов:

• Каждый следующий в наборе тест-кейс в качестве входного состояния приложения
получает результат работы предыдущего тест-кейса, что позволяет сильно сократить
количество шагов в отдельных тест-кейсах.
• Длинные последовательности действий куда лучше имитируют работу реальных
пользователей, чем отдельные «точечные» воздействия на приложение.

На практике последовательные наборы не рекомендуют использовать. Подумайте, как

повлияет использование последовательных наборов на автоматическое тестирование.

© EPAM Systems, 2019 Page: 15/16

Title: SFT.EXT.05-06 Разработка тестов и тестовых сценариев Confidential
Saved: 26-Feb-2019 10:29

6. Пример разработки тест-кейсов

1 2

3 4

5 6

7 8 Всё! ☺

© EPAM Systems, 2019 Page: 16/16