Что умеет SaveTest: ссылки и вложения в тест-кейсах
2026-06-25 12:00
Что умеет SaveTest: ссылки и вложения в тест-кейсах — меньше потерь контекста, больше пользы в прогоне Когда тестировщик открывает кейс, ему почти всегда нужно что-то рядом со сценарием, например, требование из трекера, макет, API-документация, связанный баг-репорт, эталонный скриншот, лог или пример входного файла. Сам по себе тест-кейс может быть написан корректно, но без этого контекста проверка быстро превращается в поиск по чатам, вкладкам браузера и старым комментариям.
Для одного сценария это выглядит как мелочь. Но если команда готовит регресс, принимает новую функциональность или подключает к проекту нового специалиста, такие мелочи начинают съедать рабочее время. Тестировщик тратит силы не на проверку, а на восстановление картины. Где актуальное требование, какой макет использовать, какой файл загрузить, по какому примеру сверять результат?
В SaveTest эту задачу закрывают две простые функции: Ссылки — быстрые переходы к внешним ресурсам, связанным с конкретным тест-кейсом. Вложения — файлы, которые помогают выполнить проверку, воспроизвести сценарий или разобраться в результате.
Их задача сделать ее самодостаточной. Исполнитель открывает сценарий и сразу видит не только шаги, но и весь рабочий контекст, который нужен для нормального прогона.
Что дают ссылки и вложения команде Ссылки полезны, когда к кейсу нужно привязать внешний источник:
задачу или требование в трекере;
дизайн-макет;
API-спецификацию;
связанную документацию;
баг-репорт;
описание бизнес-правила.
Вложения нужны там, где важен сам файл или артефакт:
эталонные скриншоты и видео;
примеры входных файлов;
логи и дампы для воспроизведения;
тестовые JSON, XML, CSV;
дополнительные инструкции для редких сценариев.
На практике это снижает время на ориентацию перед прогоном и уменьшает риск, что проверка пойдет по устаревшему или неполному контексту. Особенно это заметно на ручных регрессах, приемке изменений и в командах, где один специалист пишет кейс, а другой потом его выполняет.
Классический проект в SaveTest: как добавить ссылки и вложения В классическом проекте SaveTest ссылки и вложения добавляются прямо в карточке тест-кейса через интерфейс платформы. Логика привычная: открыть кейс, перейти в редактирование, добавить нужные материалы и сохранить изменения.
1. Добавляем ссылки в тест-кейс Откройте нужный тест-кейс в реестре и перейдите в режим редактирования. В секции ссылок нажмите «Добавить ссылку».
Далее заполните поля:
Название — понятное имя ссылки, например Требование PAY-184, Макет экрана оплаты, Swagger Orders API;
URL — полный адрес ресурса.
После этого сохраните изменения. Если к кейсу нужно добавить несколько ссылок, повторите действие через кнопку «Добавить ссылку». Ненужные или устаревшие ссылки удаляются в той же секции через действие удаления в строке.
Здесь важно не экономить на названии. Ссылка 1 или документ мало помогают исполнителю. Хорошее название сразу объясняет, зачем этот ресурс нужен в прогоне.
2. Добавляем вложения в тест-кейс В режиме редактирования откройте секцию вложений и нажмите «Загрузить файл». Выберите файл в системном окне и сохраните кейс. После загрузки файлы доступны прямо в карточке тест-кейса: их можно просмотреть, скачать или удалить, если они больше не нужны.
Отдельный плюс — встроенный предпросмотрщик вложений. Он позволяет открыть файл прямо в интерфейсе SaveTest без скачивания на локальную машину. Например, для текстовых вложений можно сразу посмотреть содержимое, скопировать нужный фрагмент и продолжить проверку без лишних переключений.
Простой пример: в кейсе на проверку ошибки оплаты можно хранить эталонный скриншот сообщения и текстовый лог запроса. Исполнитель не ищет эти материалы отдельно — они лежат рядом со сценарием.
Git-проект: как добавить ссылки и вложения через визуальный редактор VS Code Если в классическом проекте ссылки и вложения добавляются через веб-интерфейс SaveTest, то в Git-проекте команда работает с теми же сущностями, но в другой технической модели. Данные сохраняются в YAML и попадают в репозиторий вместе с тест-кейсами. Для команд, которые ведут тестовую базу как код, это принципиально. Ссылки, вложения и сами сценарии можно ревьюить через привычный Git-процесс, смотреть историю изменений и обновлять связанные материалы в одном коммите.
В плагине SaveTest для VS Code обе функции поддерживаются и в структуре тест-кейса, и в визуальном сценарии редактирования.
Подготовка
Откройте test-suite.yaml из каталога tests/test-case/.
Нажмите иконку визуального редактора в правом верхнем углу файла или выполните команду SaveTest: Открыть визуальный редактор
После этого выберите нужный тест-кейс в дереве.
1. Добавляем ссылки Через визуальный редактор процесс выглядит так:
Такой формат удобен тем, что связь кейса с требованиями, макетами или документацией становится частью репозитория. Ее видно на ревью, можно отследить в истории изменений и обновить вместе со сценарием.
2. Добавляем вложения Через визуальный редактор:
Откройте блок вложений в карточке кейса.
Добавьте файл или несколько файлов.
Проверьте, что вложения появились в кейсе.
Сохраните изменения.
Прикрепленные файлы автоматически попадают в папку: tests/attach/ Вручную копировать их туда не нужно. Расширение само положит файл в каталог и пропишет путь в тест-кейсе. В YAML вложения отображаются в массиве attachments: attachments: - name: "payment-error-example.png" type: "image/png" path: "tests/attach/payment-error-example.png" - name: "request-log.txt" type: "text/plain" path: "tests/attach/request-log.txt"
Если YAML редактируется вручную, можно использовать команду редактора SaveTest: Вставить вложение Она добавляет шаблон для блока attachments, чтобы не собирать структуру руками.
Как это выглядит на реальном сценарии Представим тест-кейс на проверку ошибки при неуспешной оплате. Шаги могут быть описаны корректно: открыть корзину, выбрать способ оплаты, отправить запрос, проверить сообщение об ошибке. Но для качественного выполнения проверки тестировщику обычно нужен дополнительный набор материалов.
Например, к такому кейсу можно добавить ссылки: links: - name: "Требование PAY-184" value: "https://tracker.example.com/PAY-184" - name: "Макет ошибки оплаты" value: "https://www.figma.com/file/xxxx/payment-error" - name: "Документация платежного API" value: "https://api.example.com/docs/payments"
В результате исполнитель получает полный рабочий набор: сценарий, требование, макет, API-контекст, пример ответа и эталонный результат. Это особенно полезно, когда кейс выполняет не автор, а другой участник команды, который не участвовал в обсуждении задачи.
Best practices: как не превратить кейсы в свалку артефактов Ссылки и вложения помогают только тогда, когда команда использует их аккуратно. Если прикреплять к кейсам все подряд, тестовая база быстро зарастет устаревшими скриншотами, битыми URL, тяжелыми файлами и артефактами без понятного назначения. Рабочие правила простые:
Оставляйте в кейсе только те ссылки, которые действительно нужны исполнителю на прогоне или ревью. Если ресурс не помогает выполнить проверку или понять ее смысл, лучше не добавлять его в карточку.
Используйте говорящие названия: не link, file, document, а Требование PAY-184, Эталонный скриншот ошибки, Пример CSV для импорта.
Для вложений придерживайтесь единого нейминга. Хорошее имя файла должно быть понятно без открытия: payment-error-reference.png или import-invalid-csv-example.csv работают лучше, чем image-final-2.png.
Не храните устаревшие скриншоты после изменения интерфейса. Если UI поменялся, обновляйте не только шаги, но и связанные вложения.
Не дублируйте один и тот же тяжелый файл в десятках кейсов. В таких ситуациях лучше использовать единый актуальный источник или аккуратную ссылку на общий артефакт.
При изменении требований обновляйте ссылки и вложения в том же изменении, где правите тест-кейс. Для Git-проектов это особенно удобно: сценарий, ссылки и артефакты можно провести через один коммит и одно ревью.
Типичные ошибки Чаще всего проблемы возникают не из-за инструмента, а из-за отсутствия договоренностей внутри команды:
Добавили URL, но не проверили доступность. У автора ссылка открывается, а у исполнителя нет прав.
Загрузили вложение без контекста. Файл есть, но непонятно, к какому шагу или условию он относится.
Оставили старый скриншот после изменения интерфейса. Формально вложение есть, но фактически оно вводит тестировщика в заблуждение.
Перегрузили кейс файлами, которые не помогают выполнению проверки. Чем больше лишнего шума в карточке, тем сложнее найти действительно нужный артефакт.
Такие ошибки хорошо ловятся на ревью тест-кейсов. Проверять стоит не только шаги, предусловия и ожидаемый результат, но и связанные материалы.
С чего начать в команде Не обязательно сразу приводить всю тестовую базу к идеальному состоянию. Лучше начать с критичных и часто выполняемых сценариев. Для каждого критичного кейса добавьте минимум одну ссылку на источник требований. Для кейсов с визуальными проверками — актуальный эталонный скриншот. Для сценариев с загрузкой файлов — пример входного файла. Для сложных интеграционных проверок — ссылку на API-документацию или пример запроса.
Через один-два спринта эффект обычно становится заметен: меньше уточнений в чатах, быстрее стартуют ручные прогоны, новым участникам проще входить в контекст, а тест-кейсы становятся не просто формальным описанием проверки, а полноценными рабочими артефактами.