Инженерия программного обеспечения. Тест-кейс

Основные понятия(1)
Инженерия ПЗ. Л. Егорова Е.В.
набор из одного или нескольких тест-кейсов.
ТЕСТ (TEST) —
ТЕСТ-КЕЙС (TEST CASE) —
набор входных данных, условий выполнения и ожидаемых результатов, разработанный с целью проверки того или иного свойства или поведения программного средства.
Под тест-кейсом также может
пониматься соответствующий документ,
представляющий формальную запись
тест-кейса.

Основные понятия(2)
Инженерия ПЗ. Л. Егорова Е.В.
тест-кейс без конкретных входных данных и ожидаемых результатов.
ВЫСОКОУРОВНЕВЫЙ ТЕСТ-КЕЙС (HIGH LEVEL TEST CASE) -
тест-кейс с конкретными входными данными и ожидаемыми результа-тами.
НИЗКОУРОВНЕВЫЙ ТЕСТ-КЕЙС
(LOW LEVEL TEST CASE) -

Основные понятия(3)
Инженерия ПЗ. Л. Егорова Е.В.
документ, описывающий набор тест-кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые ре-зультаты) для тестируемого элемента (test item, test object).
СПЕЦИФИКАЦИЯ ТЕСТ-КЕЙСА
(TEST CASE SPECIFICATION) -

Основные понятия(4)
Инженерия ПЗ. Л. Егорова Е.В.
документ, состоящий из специфи-кации тест-дизайна (test design specification), спецификации тест-кейса (test case specification) и/или спецификации тест-процедуры (test procedure specifi cation).
СПЕЦИФИКАЦИЯ ТЕСТА
(TEST SPECIFICATION) -

Основные понятия(5)
Инженерия ПЗ. Л. Егорова Е.В.
документ, описывающий после-довательность действий по выполнению теста (также известен как «тест-скрипт»).
ТЕСТ-СЦЕНАРИЙ
(TEST SCENARIO, TEST PROCEDURE SPECIFI CATION, TEST SCRIPT) -

Написание тест-кейсов позволяет:
Инженерия ПЗ. Л. Егорова Е.В.
Структурировать и систематизировать подход к тестированию (без чего крупный проект почти гарантированно обречён на провал).
Вычислять метрики тестового покрытия (test coverage metrics) и принимать меры по его увеличению.(
Отслеживать соответствие текущей ситуации плану.
Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками.
Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами.
Проводить регрессионное тестирование и повторное тестирование.
Повышать качество требований.
Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту.

Атрибуты(поля) тест-кейса
Инженерия ПЗ. Л. Егорова Е.В.

Основные понятия(6)
Инженерия ПЗ. Л. Егорова Е.В.
представляет собой уникальное значение, позволяющее одноз-начно отличить один тест-кейс от другого и
ИДЕНТИФИКАТОР (IDENTIFI ER)

Основные понятия(5)
Инженерия ПЗ. Л. Егорова Е.В.
показывает важность тест-кейса.
Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом.
Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от трёх до пяти.
ПРИОРИТЕТ (PRIORITY) -

Основные понятия(5)
Инженерия ПЗ. Л. Егорова Е.В.
важностью требования, пользовательс-кого сценария или функции, с которыми связан тест-кейс;
потенциальной важностью дефекта, на поиск которого направлен тест-кейс;
степенью риска, связанного с проверяе-мым тест-кейсом требованием, сценари-ем или функцией.
ПРИОРИТЕТ ТЕСТ-КЕЙСА МОЖЕТ КОРРЕЛИРОВАТЬ С:

Основные понятия(7)
Инженерия ПЗ. Л. Егорова Е.В.
показывает то основное требова-ние, проверке выполнения кото-рого посвящён тест-кейс (основ-ное — потому, что один тест-кейс может затрагивать несколько требований)
СВЯЗАННОЕ С ТЕСТ-КЕЙСОМ ТРЕБОВАНИЕ (REQUIREMENT)

Основные понятия(8)
Инженерия ПЗ. Л. Егорова Е.В.
указывают на части приложения, к которым относится тест-кейс, и позволяют лучше понять его цель.
МОДУЛЬ И ПОДМОДУЛЬ ПРИЛОЖЕНИЯ (MODULE AND SUBMODULE)
Модуль и подмодуль приложения - это
НЕ действия, это именно структурные части, «куски» приложения.

Основные понятия(9)
Инженерия ПЗ. Л. Егорова Е.В.
призвано упростить быстрое понимание основной идеи тест-кейса без обращения к его остальным атрибутам.
ЗАГЛАВИЕ (СУТЬ) ТЕСТ-КЕЙСА (TITLE)
Если инструмент управления тест-кейсами не требует писать заглавие, его ВСЁ РАВНО НАДО ПИСАТЬ.

Основные понятия(10)
Инженерия ПЗ. Л. Егорова Е.В.
позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса.
ИСХОДНЫЕ ДАННЫЕ, НЕОБХОДИМЫЕ ДЛЯ ВЫПОЛНЕНИЯ ТЕСТ-КЕЙСА (PRECONDITION, PREPARATION, INITIAL DATA, SETUP)
Всё, что описывается в этом поле, готовится БЕЗ использования тестируемого приложения, и таким образом, если здесь возникают проблемы, нельзя писать отчёт о дефекте в приложении

Основные понятия(11)
Инженерия ПЗ. Л. Егорова Е.В.
описывают последовательность действий, которые необходимо реализовать в процессе выполне-ния тест-кейса.
ШАГИ ТЕСТ-КЕЙСА (STEPS)

Общие рекомендации по написанию шагов(1):
Инженерия ПЗ. Л. Егорова Е.В.
начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск приложения, очевидные операции с интерфейсом и т. п.);
даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в будущем случайно «приклеить» описание этого шага к новому тексту);
если вы пишете на русском языке, используйте безличную форму (например, «открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»);
соотносите степень детализации шагов и их параметров с целью тест-кейса, его сложностью, уровнем и т. д.;
ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, «повторить шаги 3–5 со значением…»);
• пишите шаги последовательно, без условных конструкций вида «если… то…».

Инженерия ПЗ. Л. Егорова Е.В.
Категорически запрещено ссылать-ся на шаги из других тест-кейсов и другие тест-кейсы целиком.
Общие рекомендации по написанию шагов(2):

Основные понятия(12)
Инженерия ПЗ. Л. Егорова Е.В.
по каждому шагу тест-кейса опи-сывают реакцию приложения на действия, описанные в поле «шаги тест-кейса».
Номер шага соответствует номеру результата.
ОЖИДАЕМЫЕ РЕЗУЛЬТАТЫ (EXPECTED RESULTS)

Общие рекомендации по написанию ожидаемых результатов (1):
Инженерия ПЗ. Л. Егорова Е.В.
описывайте поведение системы так, чтобы исключить субъективное толкование (например, «приложение работает верно» — плохо, «появляется окно с надписью…» — хорошо);
пишите ожидаемый результат по всем шагам без исключения, если у вас есть хоть малейшие сомнения в том, что результат некоего шага будет совершенно тривиальным и очевидным (если вы всё же пропускаете ожидаемый результат для какого-то тривиального действия, лучше оставить в списке ожидаемых результатов пустую строку — это облегчает восприятие);
пишите кратко, но не в ущерб информативности;
• избегайте условных конструкций вида «если… то…».

Инженерия ПЗ. Л. Егорова Е.В.
В ожидаемых результатах ВСЕГДА описывается КОРРЕКТНАЯ работа приложения.
Общие рекомендации по написанию ожидаемых результатов (2):