Ускоряем и оптимизируем тесты

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

1. Проверка отдельных элементов на формах. Используется когда однотипные изменения форм выполнены в большом количестве форм
2. Проверка работы всех реквизитов формы. Используется для доработанных типовых форм чтобы понять, что форма заполняется.
3. Сценарное тестирование. Как правило создается цепочка документов, они последовательно проводятся. Проверяется состояние учетных регистров путем сверки с эталоном проводок одного из документов (как правило последнего в цепочке) или отчета.

Я расположил так не случайно, а по нарастанию сложности и ценности результат. Сценарные тесты сложны в первую очередь объемом необходимого тестового окружения. Некоторые сценарии могут состоять из последовательности 3-4 документов.

Если мы прикинем объем тестирования, то получим удручающие данные. Ручное тестирование не позволит в обозримых временных границах проверить хотя бы часть функционала.
При этом и автоматизированное может занимать длительное время если заранее не продумать сценарии и состав проверяемой функциональности. Самая большая проблема это дублирование объектов в различных сценариях. Открываются и заполняются одни те же формы ключевых объектов. Например документ ПТиУ требуется во многих сценариях. Чтобы проверить Принятие к учету ОС нужно сначала провести ПТиУ, а чтобы проверить модернизацию ОС или выбытие ОС нужна уже пара документов Принятие к учету ОС и ПТиУ.

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

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

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

Подход такой:
1. Разрабатываем тестовые сценарии вида 2 - заполнение форм документов. Используем для каждой формы одну комбинацию значений реквизитов и с общими тестовым окружением. Проверяем состояние заполненной формы, возможности записи и проведения.
2. Выделяем на формах элементы, которые влияют на поведение формы и встречаются в разных формах. Это кандидаты на тесты вида 1. В тестах вида 2 их не рассматриваем чтобы не усложнять сценарии.
3. Разрабатываем сценарные тесты. Минимизируем обращение к интерфейсу, используя "серверные" методы создания и заполнения объектов. В тесте сравниваем итоговое состояние учетных регистров с эталоном.