Тестовая матрица MBUnit: задачи оптимизации - задачи в автоматизированных пользовательских тестах

Question

В настоящее время мы используем MBUnit как для модульного тестирования, так и для тестирования пользовательского интерфейса.Стоимость настройки тестирования пользовательского интерфейса для осей тестовой матрицы довольно высока (вход в систему, экземпляр браузера, переход на страницу и т. Д.).Чтобы избежать их настройки для каждого тестового примера, мы частично полагаемся на AssemblyFixture для управления некоторыми из них.

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

Мы могли бы поместить операторы if в тестовый код для проверки правильности комбинаций, но мы этого тоже не хотим.Он загрязняет тестовый код.

Как вы, ребята, делаете такую оптимизацию?или управление матрицей тестов?Есть ли лучшая практика в другой среде тестирования?

Answer 1

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

Недавно я принял понятие «поверхностных» и «глубоких» тестов пользовательского интерфейса, в которых каждый набор тестов выполняется в оптимизированной конфигурации, чтобы уменьшить различия в среде и ускорить работу. Например, контроллер входа заменен механизмом, который позволяет избежать накладных расходов на вход OAuth и жестко закодирован с фиксированными именами пользователей. Каталог продуктов пропускает поиск в базе данных и жестко запрограммирован с несколькими фиксированными элементами. Серверная часть электронной коммерции заменена для выполнения быстрых операций, которые принимают / отклоняют транзакции в зависимости от кредитной карты и суммы.

В «неглубокой» конфигурации я могу выполнять «глубокое» тестирование логики пользовательского интерфейса. Когда я переключаюсь на «глубокую» конфигурацию, она напоминает производственную, и я могу выполнять «поверхностное» тестирование полностью интегрированных компонентов, таких как вход в систему, каталог продуктов, поиск и т. Д.

Требуется сочетание различных стратегий тестирования.

Answer 2

Может быть ui-test-automation-best-практики вам пригодятся.В нем есть несколько примеров того, как повысить производительность автоматизации тестирования пользовательского интерфейса путем минимизации логинов и изменений контекста.