Тестовые данные: генерируем и проверяем · QA Orbit
Перейти к содержимому
QA ORBIT
Новости Инструменты Библиотека Полезные сайты Курсы ИИ и тестирование
Войти
КурсыТренажёры3
Маршруты обучения
КурсыИИ для API, SQL и автотестовУрок 2
Программа курса

ИИ для API, SQL и автотестов

0 из 6 уроков пройдено
01API: контракт, права и проверяемый результат≈ 45 мин02Тестовые данные: генерируем и проверяем≈ 40 мин03SQL: проверяем JOIN, NULL и гранулярность≈ 50 мин04Автотесты: ревью ИИ-кода без случайных ожиданий≈ 45 мин05Оценка ИИ-процесса: сравниваем результат, а не впечатления≈ 40 мин06Итоговый проект: проверяем артефакты до передачи в работу≈ 75 мин
Учебные данные. Реальные навыки.
Урок 02 / 6 · 01 · Контракт и данные≈ 40 мин с практикой

Тестовые данные: генерируем и проверяем

Создаём воспроизводимые наборы с известными свойствами, а не случайную имитацию реальности.

В своём темпе
Что вы сможете после урока
  • Сформулировать контракт набора тестовых данных.
  • Независимо проверить длины, связи и ожидаемые классы.
  • Отличать синтетический набор от частично обезличенной выгрузки.

Два назначения учебных данных

OD-DATA-1 — самостоятельная SQLite-фикстура для связей и агрегации. Псевдоним t1 в ней не является тем же физическим объектом, что t1 в проектируемых API-кейсах. Для каждого упражнения явно указан источник; не смешивайте разные начальные состояния.

Данные — часть тестового оракула

Просьба «сгенерируй реалистичные данные» недостаточна для QA. Реалистичность не гарантирует границу, нужную связь или отрицательный случай. Сначала определите назначение: проверить длину title, отсутствие назначенного исполнителя или доступ двух участников к одному объекту. Затем опишите свойства набора и способ их независимой проверки. Подпись «ровно 80 символов» не является доказательством фактической длины.

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

Контракт набора OD-DATA-1

СвойствоЗачем нужноПроверка
Вера без задачНулевая группа SQLu3 должен остаться с 0
У t1 два комментарияУмножение строк при JOINСчётчик задач не должен стать 2
У t2 и t3 assignee=NULLОбработка отсутствующей связиIS NULL возвращает t2 и t3
У t4 title из пробеловРазвести draft и publishДлина 3, публикация запрещена
ID уникальны, ссылки валидныВоспроизводимость подготовкиПроверить ключи и связи

Детерминированный генератор

Вместо ручной длинной строки используйте выражение повторения и отдельный счётчик. OD-1 измеряет длину в кодовых точках: Array.from(value).length. Строковое length JavaScript считает единицы UTF-16; emoji может занимать две. Храните генератор рядом с фикстурой, чтобы получить её повторно. Для случайных данных фиксируйте seed и реализацию: одинаковое число само по себе не гарантирует одинаковую последовательность разных генераторов.

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

Независимая проверка граничной фикстуры

javascriptУчебный пример
const samples = [0, 1, 79, 80, 81].map(n => ({
  expectedCodePoints: n, title: '😀'.repeat(n)
}));
for (const row of samples) {
  if (Array.from(row.title).length !== row.expectedCodePoints) throw new Error('Bad fixture');
}
const ids = ['u1', 'u2', 'u3'];
if (new Set(ids).size !== ids.length) throw new Error('Duplicate id');

Сначала структура, потом смысл

Проверьте, что JSON разбирается, а SQL исполняется в новой учебной базе. Затем проверьте количество записей, уникальность ID, существование ссылок, распределение состояний, NULL и фактические длины. Маленький пример хорош тем, что его результат можно пересчитать вручную. Это независимый оракул для сложной выборки.

Свяжите каждую особую строку с тестовой целью. Без пользователя без задач набор не обнаружит потерю нулевой группы. Без двух комментариев у одной задачи не проявится удвоение счётчика. Эталонную таблицу не следует автоматически получать тем же непроверенным запросом, который вы оцениваете: это замкнёт проверку на самой себе. Сначала составьте прогноз по исходным строкам.

Контракт данных нужно поддерживать

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

У качественной учебной фикстуры нет обязанности притворяться настоящим клиентом. Её ценность в прозрачности каждой записи. На следующем уроке OD-DATA-1 поможет отделить ошибку LEFT JOIN от ошибки COUNT. Даже без ИИ вы можете завершить эту практику: все ошибочные утверждения и проверяемые свойства уже даны ниже.

Промпт для самостоятельной работы
ЗАДАЧА
Отревьюируй минимальные синтетические данные для SQL и API.

КОНТЕКСТ
OD-DATA-1; реальные пользователи и секреты запрещены.

ВХОДНЫЕ ДАННЫЕ
Проверь этот набор и объясни, какие свойства он обеспечивает:
-- OrbitDesk synthetic fixture OD-DATA-1. Use a NEW disposable SQLite database.
PRAGMA foreign_keys = ON;
CREATE TABLE users (id TEXT PRIMARY KEY, name TEXT NOT NULL, role TEXT NOT NULL);
CREATE TABLE tasks (id TEXT PRIMARY KEY, author_id TEXT NOT NULL REFERENCES users(id), title TEXT NOT NULL, state TEXT NOT NULL, assignee_id TEXT REFERENCES users(id));
CREATE TABLE comments (id TEXT PRIMARY KEY, task_id TEXT NOT NULL REFERENCES tasks(id), body TEXT NOT NULL);
INSERT INTO users VALUES ('u1','Анна','user'),('u2','Борис','user'),('u3','Вера','editor');
INSERT INTO tasks VALUES
 ('t1','u1','Проверить форму','published','u2'),
 ('t2','u1','Черновик','draft',NULL),
 ('t3','u2','SQL-проверка','published',NULL),
 ('t4','u2','   ','draft','u1');
INSERT INTO comments VALUES
 ('c1','t1','Проверено'),('c2','t1','Нужна правка'),
 ('c3','t3','Готово'),('c4','t2','Черновой комментарий');
Контрольные цели: пользователь без задач, задача с двумя комментариями, два NULL assignee, пробельный title в draft.

ОГРАНИЧЕНИЯ
Не используй производственные выгрузки. Дай уникальные ID и корректные связи. Для длин нужны генератор и проверка.

ОЖИДАЕМЫЙ ФОРМАТ
SQL или JSON; свойства набора; независимые проверки и ожидаемые контрольные результаты.

Используйте разрешённый ИИ-сервис. Не отправляйте рабочие секреты и персональные данные.

Источники и проверка фактов

ISTQB — CTFL v4.0, программа и материалыРазделы анализа и проектирования тестов; курс использует собственные учебные примеры, не является подготовкой к сертификации.SQLite — SELECTПоведение LEFT JOIN и различие условий ON и WHERE для строк без соответствия.ECMAScript — итератор строк и Array.fromИтерация по кодовым точкам Unicode; отличие от числа кодовых единиц UTF-16.

Авторский учебный материал · Редакция QA Orbit · версия 2026-10-28.1

Теперь применим это к задачеПопробуйте сами, прежде чем открывать разбор.
Предыдущий урокAPI: контракт, права и проверяемый результатСледующий урокSQL: проверяем JOIN, NULL и гранулярность
QA ORBIT

Проверяй. Понимай. Расти.

Пространство осмысленного тестирования.
ИсследуйтеНовостиИнструментыБиблиотека
РазвивайтесьКурсыТренажёрыМаршруты обученияИИ и тестирование
Оставайтесь на орбитеО проекте Полезные сайтыГлоссарий
© 2026 QA Orbit. Сделано с вниманием к деталям.
КонфиденциальностьУсловия использования Всегда есть что исследовать