Тестирование программного обеспечения (лекция № 4)

1.

Тестирование программного обеспечения
Лекция №4.

2.

О чём сегодня будем говорить
Тестовые сценарии
Определение
Цели
Атрибуты
Жизненный цикл
Свойства качественных сценариев
Правила написания
Преимущества и недостатки
2

3.

Пример
# Шаги:
a=2
b=2
def test_addition():
# Шаг 1: вызов функции сложения
result = add(a, b)
print(result)
# Шаг 2: проверка результата
assert result == expected_result, "Результат не соответствует ожидаемому"
# Функция сложения
def add(a, b):
return a + b
# Ожидаемые результаты:
expected_result = 5
test_addition()

4.

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

5.

Тестовый сценарий – определение
• Высокоуровневый тест-кейс — тест-кейс без конкретных
входных данных и ожидаемых результатов. Как правило,
ограничивается общими идеями и операциями, схож по
своей сути с подробно описанным пунктом чек-листа.
• Низкоуровневый тест-кейс — тест-кейс с конкретными
входными данными и ожидаемыми результатами.
Представляет собой полностью готовый к выполнению
тест-кейс и является наиболее классическим видом тесткейсов.
5

6.

пример
import unittest
from selenium import webdriver
class TestRegistration(unittest.TestCase):
def setUp(self):
self.driver = webdriver.Chrome()
def test_registration(self):
self.driver.get("https://example.com/registration")
self.driver.find_element_by_name("username").send_keys("testuser")
self.driver.find_element_by_name("password").send_keys("testpassword")
self.driver.find_element_by_name("submit").click()
self.assertEqual(self.driver.title, "Регистрация успешна")
def tearDown(self):
self.driver.quit()

7.

пример
import unittest
from hashlib import sha256
def hash_password(password):
return sha256(password.encode()).hexdigest()
class TestHashPassword(unittest.TestCase):
def test_hash_password(self):
password = "testpassword"
hashed_password = hash_password(password)
self.assertEqual(hashed_password,
"hashed_password_value")

8.

Высокоуровневый тест-кейс:
Первый код является высокоуровневым тест-кейсом. Он проверяет
функциональность регистрации на веб-сайте, используя Selenium
WebDriver для имитации взаимодействия пользователя с вебприложением. Тест проверяет, что после заполнения формы
регистрации и отправки формы, страница регистрации успешно
загружается.
Низкоуровневый тест-кейс:
Второй код является низкоуровневым тест-кейсом. Он проверяет
конкретную функцию hash_password, которая хэширует пароль с
помощью алгоритма SHA-256. Тест проверяет, что функция возвращает
ожидаемое значение хэша для заданного пароля.

9.

Разница между этими двумя тестами заключается в уровне
абстракции и области покрытия:
Высокоуровневый тест работает на уровне веб-приложения
и проверяет функциональность регистрации, которая
включает в себя взаимодействие между несколькими
компонентами (веб-страница, форма, кнопка отправки).
Низкоуровневый тест работает на уровне отдельной
функции (hash_password) и проверяет ее поведение в
изоляции от остальной системы.

10.

Тестовый сценарий – определение
• Спецификация тест-кейса — документ, описывающий
набор тест-кейсов (включая их цели, входные данные,
условия и шаги выполнения, ожидаемые результаты) для
тестируемого элемента.
• Спецификация теста — документ, состоящий из
спецификации тест-дизайна, спецификации тест-кейса (test
case specification) и/или спецификации тест-процедуры
(test procedure specification).
• Тест-сценарий (test scenario, test procedure specification,
test script) — документ, описывающий последовательность
действий по выполнению теста (также известен как «тестскрипт»).
10

11.

Тестовый сценарий – Цели
• Структурировать и систематизировать подход к
тестированию.
• Вычислять метрики тестового покрытия и принимать меры
по его увеличению.
• Отслеживать соответствие текущей ситуации плану.
• Уточнить взаимопонимание между заказчиком,
разработчиками и тестировщиками.
• Хранить информацию для длительного использования и
обмена опытом между сотрудниками и командами.
• Проводить регрессионное тестирование и повторное
тестирование.
• Повышать качество требований.
• Быстро вводить в курс дела нового сотрудника, недавно
7
подключившегося к проекту.

12.

Тестовый сценарий – Атрибуты
• Номер — представляет собой уникальное значение,
позволяющее однозначно отличить один тест-кейс от
другого и используемое во всевозможных ссылках.
• Название — краткое описание сути проверки, упрощает и
ускоряет понимание основной идеи (цели) тест-кейса без
обращения к его остальным атрибутам. Является наиболее
информативным при просмотре списка тест-кейсов.
• Предварительные шаги — описание действий, которые
12

13.

Тестовый сценарий – Атрибуты
• Предварительные шаги — описание действий, которые
необходимо выполнить, но прямого отношения к проверке
они не имеют.
• Шаги — описание последовательности действий, которые
необходимо реализовать в процессе выполнения
тестового сценария.
• Ожидаемый результат — описание реакции приложения
по каждому шагу тест-кейса на действия, указанные в
атрибуте «шаги». Номер шага соответствует номеру
результата.
13

14.

Тестовый сценарий – Жизненный цикл
14

15.

Тестовый сценарий – Жизненный цикл
• Создан — типичное начальное состояние практически
любого артефакта. Тест-кейс автоматически переходит в
это состояние после создания.
• Запланирован — в этом состоянии тест-кейс находится,
когда он или явно включён в план ближайшей итерации
тестирования, или, как минимум, готов для выполнения.
• Не выполнен — нахождение тест-кейса в данном
состоянии означает, что он готов к выполнению, но ещё не
был выполнен.
15

16.

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

17.

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

18.

Тестовый сценарий – Жизненный цикл
• Заблокирован —по какой-то причине выполнение тесткейса невозможно (как правило, такой причиной является
наличие дефекта, не позволяющего реализовать некий
пользовательский сценарий).
• Закрыт —данное состояние показывает, что на данной
итерации тестирования все действия с ним завершены.
• Требует доработки — в это состояние (или из него) тесткейс может быть переведён, если в нём будет обнаружена
ошибка, если изменятся требования, по которым он был
написан, или наступит иная ситуация, не позволяющая
считать тест-кейс пригодным для выполнения и перевода в
иные состояния.
18

19.

Пример
Пример жизненного цикла тестового сценария.
Допустим, мы хотим протестировать функцию
регистрации пользователя в веб-приложении. Мы
создаем тестовый сценарий, который включает в себя
следующие шаги:
1. Открыть страницу регистрации пользователя
1.Ввести корректные данные пользователя (имя,
фамилия, адрес электронной почты, пароль)
2.Нажать кнопку "Зарегистрироваться"
3.Проверить, что пользователь успешно зарегистрирован

20.

Мы выполняем тестовый сценарий и обнаруживаем, что пользователь не может
зарегистрироваться, потому что пароль слишком короткий. Мы создаем дефект и
исправляем его. После исправления дефекта мы повторно выполняем тестовый
сценарий и проверяем, что пользователь успешно зарегистрирован.
Жизненный цикл тестового сценария в этом примере:
1. Создание тестового сценария
2. Определение цели тестирования: протестировать функцию регистрации
пользователя
3. Проверка тестового сценария на корректность и полноту
4. Проверка тестового сценария на актуальность: проверить, что тестовый сценарий
актуален
5. Выполнение тестового сценария: выполнить тестовый сценарий
6. Сбор результатов тестирования: собрать результаты тестирования
7. Анализ результатов тестирования: проанализировать результаты тестирования
8. Определение дефектов
9. Создание отчета о тестировании: создать отчет о тестировании
10. Исправление дефектов
11. Проверка исправленных дефектов
12. Обновление тестового сценария
13. Удаление тестового сценария

21.

Свойства качественных тестовых сценариев
• Правильный технический язык, точность и единообразие
формулировок.
• Баланс между специфичностью и общностью.
• Баланс между простотой и сложностью.
• «Показательность» (высокая вероятность обнаружения
ошибки)
• Последовательность в достижении цели.
• Отсутствие лишних действий.
• Неизбыточность по отношению к другим тест-кейсам.
21

22.

Свойства качественных тестовых сценариев
• Демонстративность (способность демонстрировать
обнаруженную ошибку очевидным образом).
• Прослеживаемость.
• Возможность повторного использования.
• Повторяемость.
• Соответствие принятым шаблонам оформления и
традициям.
22

23.

Рекомендации при написании шагов
тестового сценария
• начинайте с понятного и очевидного места, не пишите
лишних начальных шагов (запуск приложения, очевидные
операции с интерфейсом и т.п.);
• даже если в тест-кейсе всего один шаг, нумеруйте его;
• если вы пишете на русском языке, используйте безличную
форму, в английском языке imperative mood
(повелительное наклонение);
23

24.

Рекомендации при написании ожидаемых
результатов тестового сценария
• описывайте поведение системы так, чтобы исключить
субъективное толкование;
• пишите ожидаемый результат по всем шагам без
исключения;
• пишите кратко, но не в ущерб информативности;
• избегайте условных конструкций вида «если… то…».
24

25.

Рекомендации при написании шагов
тестового сценария
• соотносите степень детализации шагов и их параметров с
целью тест-кейса, его сложностью, уровнем и т.д. — в
зависимости от этих и многих других факторов степень
детализации может варьироваться от общих идей до
предельно чётко прописанных значений и указаний;
• ссылайтесь на предыдущие шаги и их диапазоны для
сокращения объёма текста (например, «повторить шаги 3–
5 со значением…»);
• пишите шаги последовательно, без условных конструкций
вида «если… то…».
25

26.

Пример
Предварительные условия:
• Веб-приложение доступно и работает корректно.
• Пользователь не зарегистрирован в системе.
Шаги:
1)Открыть страницу регистрации в веб-приложении.
2)Ввести валидные данные для регистрации:
• Имя пользователя (например, "testuser").
• Электронная почта (например, "testuser@example.com").
• Пароль (например, "testpassword").
• Подтверждение пароля (например, "testpassword").

27.

3)Нажать кнопку "Зарегистрироваться".
4)Подождать, пока страница регистрации не будет
обработана и не будет выведено сообщение об успешной
регистрации.
5) Проверить, что пользователь был успешно
зарегистрирован, проверив:
• Отображается сообщение об успешной регистрации.
• Пользователь может авторизоваться в системе с помощью
введенных данных.
• Пользователь может просматривать и редактировать
свою информацию в профиле.
Ожидаемый результат:
• Пользователь успешно зарегистрирован в системе.
• Пользователь может авторизоваться в системе с помощью
введенных данных.
• Пользователь может просматривать и редактировать
свою информацию в профиле.

28.

Преимущества тестовых сценариев
Преимущества
• Тестовые сценарии можно доверить выполнять новичку
или призванному на помощь коллеге из другого отдела,
который ничегошеньки о проекте не знает.
28

29.

Недостатки тестовых сценариев
Недостатки (вытекают один из другого):
• Очень много копирования текста.
• Сложно поддерживать.
• Неактуальное состояние.
29