В предыдущей заметке описал, что такое отчет и обобщил структуру отчетов и тестовых сценариев.

Первая проблема была озвучена здесь: Борьба со сложностью кода UI-тестов

Одна из проблем автоматизированного тестирования это поддержка код автотестов. Зачастую исходный код сценария пишут одни люди, а поддерживают и запускают другие. Сложный и запутанный код теста сложно поддерживать и развивать. Поэтому при проектировании и разработке автотестов необходимо придерживаться определенных правил.

Ранее выделил следующие классы UI-тестов:

Самым очевидным решением является автоматизация тестирования после обновления доработанной конфигурации типовым решением. Из типовой приходит много изменений, а доработки равномерно распределены по конфигурации. Ручное тестирование такого большого объема изменений трудоёмко и неэффективно. Если такие обновления происходят регулярно, тогда важной становится задача регресс-тестирования. В первую очередь тестируются измененные типовые объекты, которые подвергаются встречным изменениям вендора и команды разработки. Определять такие объекты нужно регулярно при разработке. Подобные объекты можно включить в отдельную подсистему. Делать это может разработчик, выполняя кодирование, так и на этапе код-ревью или при подготовке релиза...

Начало: Разработка UI-тестов через запись действий пользователя. Часть 1., Разработка UI-тестов через запись действий пользователя. Часть 2.

Продолжаем эксперимент начатый в предыдущей заметке. Подключаем к проблеме технического специалиста и пробуем довести начатое до конца.

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

В предыдущих заметках долго рассуждал, что и как сделать сразу правильно что бы не было мучительно больно потом. Однако можно справедливо возразить, что это академический подход и он далек от реальности, в которой есть сжатые сроки и ограниченные ресурсы.

Когда начинаешь автоматизацию тестирования возникает "эффект чистого листа". Вроде все просто - есть система, которую нужно тестировать, у нее есть интерфейс, выбрал инструмент, с которым будешь тестировать, а дальше ничего не ограничивает - действуй.