Реактивные интерфейсы уже более 5 лет являются отраслевым стандартом в мире Frontend-разработки.
В этой статье будет продемонстрировано применение некоторых идей из этой области для решения задач автоматизации пользовательского интерфейса.
Проблемы
Возможно, самая простая вещь в задачах автоматизации тестирования — это сама автоматизация тестирования.Гораздо больше времени и сил тратится на решение сопутствующих задач, таких как:
- Унификация тестового дизайна
- Автоматизация проверки
- Поддержка автоматизации
Унификация тестового дизайна
Как правило, тест-кейсы пишутся на естественном языке аналитиками или QA-инженерами, без каких-либо формальных правил и обозначений.Крайне редко можно наблюдать ситуацию, когда тест-дизайн осуществляется в соответствии с правилами тест-дизайна.
Другими словами, из названия кейса непонятно, что именно он проверяет и как он проверяет: в одном кейсе большое количество различных проверок, много дублирования и отсутствие иерархической структуры.
Это объясняется тем, что человеку быстрее и удобнее написать одно большое дело, а не множество мелких.
Ситуация усугубляется, когда над проектом работают сразу несколько тест-дизайнеров: каждый из них будет описывать тестируемое поведение немного по-разному.
Прежде чем приступить к автоматизации, автоматизатор должен унифицировать дизайн теста, привести его к единому виду и структурировать.
Без этих шагов автоматизация подобна нанесению краски на поверхность, покрытую пылью.
Создаётся только видимость готовой работы, но вскоре всё приходится переделывать, ведь автоматизация в этом случае создаёт больше проблем, чем решает.
Автоматизация проверки
Автоматизация начинает приносить реальную пользу только тогда, когда она сделана очень хорошо.Важно, чтобы все условия проверялись именно так, как написано, а не так, как было бы удобнее реализовать.
Приведу пример: представьте себе таблицу со списком строк, последний столбец которой содержит кнопку «удалить».
Нам нужно проверить, удаляется ли строка из таблицы при нажатии этой кнопки.
«Простой» вариант автоматизации в этом случае — получить количество строк до и после удаления, а затем сравнить, уменьшилось ли количество на одну строку.
Тогда как правильно было бы получить модель таблицы до и после удаления и получить строку, которая будет удалена, а затем сравнить модели таблиц, чтобы убедиться, что удаляется именно нужная строка, а остальное остается неизменным.
В первом, простом варианте мы потенциально можем пропустить несколько ошибок, например, ошибку, при которой будет удалена не та строка, по которой был нажат. Такие ситуации — когда автотест неправильно проверяет семантику действия — случаются довольно часто, и их обязательно нужно исправлять.
В противном случае автоматизации нельзя доверять, и регрессию придется выполнять вручную.
Поддержка автоматизации
Поддержка и сопровождение автотестов — одна из самых болезненных тем в этой сфере.Я неоднократно сталкивался с ситуацией, когда на адаптацию автоматизированных тестов уходит гораздо больше человеко-часов, чем на внесение изменений в код разработки.
Автотесты отстают и не успевают адаптироваться к изменениям.
На практике это выглядит так: запускается регрессия, запускаются автотесты, некоторые из которых проваливаются, их начинают анализировать/редактировать/перезапускать.
И этот процесс требует больше ресурсов, чем запуск всей регрессии вручную.
Но прогон приходится делать, и специалисты по автоматизации вынуждены делать это вручную.
Чтобы избежать этих проблем, дизайн автотестов должен быть разработан с учетом возможности будущих адаптаций, а именно, не должно быть нарушения принципа DRY. Должна существовать иерархия зависимостей и последовательность запуска.
Все проблемы с селекторами (в UI-тестах) и атомарными функциями должны отображаться на этапе Smoke тестов.
Одним из возможных решений перечисленных выше проблем являются декларативные подходы к автоматизации, о которых речь пойдет ниже.
Модельно-ориентированное тестирование (MBT)
MBT — это декларативный подход к проектированию тестов.Предполагается, что разработчику системы автоматизации необходимо описать модель приложения, на основе которой тестовая среда будет генерировать необходимые тесты.
Методика, при которой тесты генерируются, а не создаются вручную, называется ДДТ.
ДДТ (Data Driven Testing) – техника тестовый дизайн, когда один метод действует как параметризованный шаблон.MBT является расширением DDT: при DDT тестовые данные описываются вручную, а при MBT они генерируются на основе модели.Тесты генерируются из набора данных, примененных к шаблонному методу.
MBT для тестов Rest API
Вполне можно взять за образец для тестов Rest API Объекты DTO запросы, добавляя в их поля некоторую метаинформацию о семантике этих полей, например:- Поле обязательное
- Список допустимых значений (для перечислений)
- Максимальное/минимальное значение (для чисел)
- Максимальная длина строки
После чего можно реализовать алгоритм генерации положительных и отрицательных тестов.
В этой статье мы не будем подробно рассматривать вопросы, связанные с тестами API. Давайте сосредоточимся на UI-тестах.
ОБТ для UI-тестов
Логику взаимодействия UI удобно описывать графовой моделью, вершинами которой будут страницы тестируемого приложения, а ребрами — действия, по которым будут осуществляться переходы с одной страницы на другую.Для случаев, когда на странице присутствуют элементы ввода, и существует несколько различных состояний, в которых приложение может находиться в пределах одной страницы (в зависимости от действий, выполняемых пользователем), удобно использовать MVVM.
МВВМ (Model View — View Model) или Reactive UI — это подход к реализации пользовательского интерфейса, при котором изменения модели автоматически применяются к Вид .Итак, модель для UI-тестов удобно описывать в двух обозначениях в зависимости от функционала.Для этого код View должен содержать ассоциации между значениями элементов пользовательского интерфейса и атрибутами модели.
Когда изменение навигации/состояния происходит при нажатии на элементы пользовательского интерфейса, мы используем графики.
Когда пользовательский ввод осуществляется через MVVM.
Графики и навигация
Для реализации возможности автоматической навигации по страницам приложения необходимо, чтобы среда тестирования могла определять текущую страницу и находить кратчайший путь от текущей страницы до требуемой.Представим себе архитектуру одного из возможных решений, где мы выбираем Котлин (это не важно, здесь подойдет любой современный язык).
Теги: #Тестирование веб-сервисов #Тестирование ИТ-систем #автоматизация тестирования #mvvm #проектирование на основе моделей #mbtinterface PathBuilder { fun findPath(from: Page, to: Page): Collection<NavEdge> } interface Navigator { val pages: MutableList<Page> val pathBuilder: PathBuilder fun register(page: Page) = pages.add(page) val current: Page get() = pages.firstOrNull { it.isPresent }
-
Авогадро Закон
19 Oct, 24 -
Mail.ru Вошла В Автомобильный Бизнес
19 Oct, 24 -
Почему Клавиатуры Ноутбуков Не Разделяются?
19 Oct, 24
