Проблемы оптимизации производительности тестовой матрицы MBUnit в автоматизированных тестах пользовательского интерфейса - PullRequest
0 голосов
/ 18 марта 2011

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

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

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

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

Ответы [ 2 ]

1 голос
/ 19 марта 2011

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

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

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

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

1 голос
/ 18 марта 2011

Может быть, статья ui-Test-Automation-Best-Practices будет полезна для вас. В нем есть несколько примеров того, как повысить производительность автоматизации тестирования пользовательского интерфейса путем минимизации входов в систему и изменения контекста.

...