Ответ
Ожидаемый результат (expected result) — это эталон корректного поведения системы. Его источники иерархичны:
1. Первичные (формальные) источники:
- Требования (SRS/User Stories): Функциональные и нефункциональные спецификации.
- Техническая документация: API-спецификации (Swagger/OpenAPI), схемы баз данных.
- Макеты и дизайн-системы (UI): Для проверки визуального соответствия.
2. Вторичные и практические источники:
- Общение с командой: Уточнение у аналитика (BA), разработчика (Dev) или владельца продукта (PO).
- Анализ работы системы: Изучение поведения существующей (legacy) системы или аналогов.
- Эталонные данные/скриншоты: Для регрессионного и визуального тестирования.
Пример для API-теста на Python (pytest):
import requests
def test_get_user_by_id():
# 1. Ожидаемый результат взят из спецификации OpenAPI
expected_user_schema = {
"type": "object",
"properties": {
"id": {"type": "integer"},
"name": {"type": "string"},
"email": {"type": "string", "format": "email"}
},
"required": ["id", "name", "email"]
}
# 2. Конкретные ожидаемые данные из тестового сценария
expected_data = {
"id": 1,
"name": "Leanne Graham",
"email": "Sincere@april.biz"
}
# Выполнение запроса и проверка
response = requests.get("https://jsonplaceholder.typicode.com/users/1")
actual_data = response.json()
# Проверка структуры (соответствие схеме)
assert validate_schema(actual_data, expected_user_schema)
# Проверка значений
assert actual_data == expected_dataВажно: При отсутствии формальных требований ожидаемый результат должен быть согласован и зафиксирован (например, в тест-кейсе), чтобы избежать разночтений.
Ответ 18+ 🔞
Давай разберем эту тему, пока не начали друг другу мозги ебать на ретроспективе. Ожидаемый результат — это, по сути, святой грааль, на который мы молимся, когда проверяем, не накосячила ли система. Без него тестирование превращается в "ну, вроде работает, а хули".
Откуда же этот эталон брать, чтобы не высосать из пальца? Всё иерархично, как в хорошем борделе.
1. Официальные бумажки, от которых никуда не деться:
- Требования (SRS/User Stories): Там, в идеальном мире, должно быть прописано, что кнопка "Отправить" делает именно "отправляет", а не "стирает всё к хуям".
- Техническая документация: Твои лучшие друзья — сваггеры, схемы АПИ и БД. Там черным по белому: такой-то эндпоинт возвращает JSON с такими-то полями. Не вернул? Пиздец, а не тест.
- Макеты (UI): Чтобы дизайнер не пришел с криком "я тебя породил, я тебя и убью", когда отступ слева 15px, а не 14.
2. Реальная жизнь, где всё через жопу:
- Общение с командой: Когда в требованиях хуйня написана, идешь к аналитику, девопсу или продакту и начинаешь выбивать из них конкретику. "Чё должно-то быть, блядь?" — главный вопрос.
- Легаси-система: Если тестируешь старый функционал, смотри, как оно работает сейчас. Часто это и есть де-факто требование, хоть и кривое.
- Скриншоты и данные прошлых прогонов: Для регресса — святое. Было так — должно остаться так. Изменилось? Либо баг, либо тебе просто не сказали, что переделали.
Смотри, как это в коде выглядит, на простом примере:
import requests
def test_get_user_by_id():
# 1. Ожидаемая структура (схема) из той самой тех.доки (Swagger)
expected_user_schema = {
"type": "object",
"properties": {
"id": {"type": "integer"},
"name": {"type": "string"},
"email": {"type": "string", "format": "email"}
},
"required": ["id", "name", "email"] # Вот эти три поля ОБЯЗАТЕЛЬНЫ, блядь!
}
# 2. Конкретные ожидаемые значения из тест-кейса или требований
expected_data = {
"id": 1,
"name": "Leanne Graham",
"email": "Sincere@april.biz"
}
# Дёргаем АПИшку
response = requests.get("https://jsonplaceholder.typicode.com/users/1")
actual_data = response.json() # Что нам в реальности прилетело
# Проверяем, что структура ответа не ёбнулась
assert validate_schema(actual_data, expected_user_schema)
# Проверяем, что значения именно те, что мы ждали
assert actual_data == expected_dataИ главное правило, которое спасёт от пиздеца: если формальных требований нет — ты должен этот самый ожидаемый результат согласовать и записать. Хоть в тест-кейсе, хоть на салфетке. Потому что иначе получится "я думал, оно должно считать, а ты думал — нет". А потом выясняется, что оба думали неправильно, а система работает как бог на душу положит.