Выбрать правильный уровень проверки
Не всякую логику стоит проверять через экран. Расчёт суммы удобнее тестировать отдельно от интерфейса, взаимодействие с сервером через соответствующий программный слой, а несколько ключевых пользовательских путей целиком. Экранные тесты особенно полезны там, где важна связь элементов: ввод данных, переход между страницами, появление результата. Чем длиннее путь, тем больше возможных причин сбоя. Поэтому один сценарий лучше посвятить одной понятной цели, а подготовку данных отделить от действий, которые действительно проверяются.
Зафиксировать исходное состояние
Перед запуском нужно знать версию приложения, платформу, состояние учётной записи и набор тестовых данных. Используют отдельную тестовую среду и вымышленные сведения, чтобы проверка не затрагивала реальные заказы и личные данные. Полезно явно описать, должен ли пользователь быть авторизован и какие разрешения уже предоставлены. Очистка состояния тоже требует осторожности: нельзя удалять данные с личного устройства ради удобства сценария. Для воспроизводимости предпочтительны специально подготовленные тестовые устройства или эмуляторы с контролируемым окружением.
Находить элементы и ждать события
Координаты кнопки меняются при другом размере экрана, ориентации или системном масштабе текста. Устойчивые идентификаторы и доступные имена обычно лучше передают смысл элемента, чем его положение. Ожидание фиксированного числа секунд также ненадёжно: иногда оно слишком долгое, иногда недостаточное. Более точный подход состоит в ожидании конкретного состояния с ограниченным временем, например доступности кнопки или появления сообщения. Средства автоматизации связывают команды теста с механизмами платформы через драйверы. Поэтому проблемы поиска элемента следует отличать от проблем соединения с устройством.
Проверять результат и сохранять свидетельства
Тест успешен не потому, что последняя кнопка нажалась. Требуется утверждение о результате: элемент появился, значение изменилось, запрещённое действие не выполнено. Сообщение об ошибке должно показывать, что ожидалось и что наблюдалось. Снимок экрана, журналы приложения и сведения об устройстве помогают воспроизвести сбой, но не должны содержать реальные секреты. Повторный запуск, который иногда проходит, указывает на нестабильность, а не автоматически оправдывает приложение. Причиной может быть гонка состояний, недостаточная изоляция данных или настоящая редкая ошибка продукта.
Попробуйте на практике
На бумаге спроектируйте автоматическую проверку добавления заметки в вымышленном мобильном приложении.
- Опишите исходное состояние: пустой список, тестовое устройство, локальное хранение и отсутствие сетевой зависимости.
- Задайте шаги открытия формы, ввода уникального заголовка и сохранения; рядом укажите смысловые признаки нужных элементов.
- Для каждого перехода запишите наблюдаемое условие ожидания вместо фиксированной паузы.
- Добавьте проверки появления ровно одной заметки с нужным текстом и сохранения результата после повторного открытия списка.
- Придумайте два сбоя и перечислите свидетельства, которые позволят отличить ошибку приложения от ошибки сценария.
Как проверить результат. Проверка имеет однозначное начальное состояние и итог, не зависит от координат и содержит отдельное объяснение для каждого возможного сбоя.
Частые вопросы
Можно ли одним сценарием покрыть всё приложение?
Технически длинный маршрут возможен, но его падение трудно диагностировать. Небольшие независимые проверки обычно проще поддерживать, а несколько сквозных сценариев дополняют их.
Нужно ли проверять только на эмуляторе?
Эмулятор удобен для воспроизводимых запусков. Реальные устройства нужны для особенностей оборудования и поведения, которые виртуальная среда воспроизводит не полностью. Состав проверок зависит от риска.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.