Анализ схемы автоматически генерируемого тестового сценария

тестовое задание

Текст: Ютинг

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

Концепция

Самая ежедневная работа инженера по тестированию автоматизации интерфейса — это написание сценариев тестирования автоматизации интерфейса Итак, что самое скучное и утомительное в процессе написания кода?

Болевые точки

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

  • Различные требования, но высокая надежность и повторяемость некоторых вариантов использования в бизнесе.

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

Тратить 30% своего дня на написание сценариев, не требующих особых размышлений, недостаточно автоматизировать!

решение

  • Разобрать документ

  • Отсортируйте скрипты, подходящие для автоматической генерации

  • Сгенерируйте эту часть скрипта с помощью инструмента

ожидаемый гол

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

Упражняться

Автоматически получать информацию об интерфейсе

Анализировать структуру и содержимое скрипта автоматизации интерфейса

Диаграмма структуры автоматической тестирования скрипта

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

Правила здесь не должны быть слишком сложными, вы можете сначала выбрать часть с простой логикой, в основном мы выбираем следующие две части

  • Класс интерфейса, время работы составляет 30%~50%, особенности: специфическая структура, данные с других платформ

Схема структуры класса интерфейса

  • В части варианта использования рабочее время составляет 30–50%, а характеристики: частота повторения выше примерно 80%, и можно описать логику генерации.

диаграмма вариантов использования

Разобрать интерфейсный документ

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

Ниже приводится анализ и сравнение различий между следующими инструментами для разбора файлов интерфейса: .

Классификация Swagger RAP WIKI
описывать Фреймворк для создания, описания, вызова и визуализации веб-сервисов RESTful. Инструмент управления визуальным интерфейсом Гипертекстовая система для совместной работы нескольких человек.
Формат json json html
Технические характеристики Конкретная структура и тип каждого параметра и возвращаемого значения имеют единую спецификацию. То же, что чванство Вам нужно договориться самостоятельно
Стоимость Непосредственно встраивается в проект, путем написания комментариев во время разработки, документация по интерфейсу генерируется автоматически, а стоимость низкая. Его нужно разрабатывать вручную по правилам платформы, а стоимость высока. Необходимость соблюдения согласованных спецификаций, ручной ввод, высокая стоимость

Если позволяют условия, вы можете принять во внимание стоимость разработки и сложность анализа файла интерфейса, чтобы определить, какую платформу использовать для управления интерфейсом.

Наш проект представляет собой смесь Swagger и WIKI.Поскольку WIKI в основном встречается в ежедневных тестах, для анализа WIKI в первые дни использовался инструмент-краулер Python BeautifulSoup.htmlстраница

                                
  1. from bs4 import BeautifulSoup

  2. soup = BeautifulSoup (html_doc)

  3. title_string = soup. title.string

  4. # 后面继续解析其他需要用到的接口内容

скопировать код

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

  1. Полностью по искусственному ограничениям написать правила не летать

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

  3. Получить точную информацию о местоположении в html гораздо сложнее, чем в json, а совместимость плохая.

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

  1. {

  2.    "swagger": "2.0",

  3.    "host": "xxx",

  4.    "basePath": "/",

  5.    "tags":[

  6.        {"name":"xxx-controller","description":"xxx"},

  7.        ...

  8.    ],

  9.    "paths": {

  10.        "<接口地址1>": { ... },

  11.        "<接口地址2>": { ... },

  12.        ...

  13.    },

  14.    "definitions": {

  15.        "<实体类1>": { ... },

  16.        "<实体类2>": { ... },

  17.        ...

  18.    }

  19. }

скопировать код

После получения json-результата следующим образом можно получить требуемый контент прямо на пути обработки словаря.

  1. graph LR

  2. json-->ApiObj

скопировать код

Для разбора и генерации кода swagger.json также предоставляются некоторые библиотеки swagger-codegen.(java), Из-за ограничений языка программирования мы использовали python для самостоятельного разбора

Теперь у нас есть информация, необходимая для генерации кода.

Автоматически генерировать код

инструмент генерации кода

  1. class CodeGeneratorBackend():

  2.    def begin(self, tab="\t"):

  3.        self.code = []

  4.        self.tab = tab

  5.        self.level = 0

  6.    def end(self):

  7.        # return string.join(self.code, "")

  8.        return "".join(self.code)

  9.    def write(self, string):

  10.        self.code.append(self.tab * self.level + string)

  11.    def indent(self):

  12.        self.level = self.level + 1

  13.    def dedent(self):

  14.        if self.level == 0:

  15.            raise SyntaxError("internal error in code generator")

  16.        self.level = self.level - 1

  17. """调用方法,开始生成代码"""    

  18. c = CodeGeneratorBackend()

  19. c.begin(tab="    ")  # 定义缩进方式

  20. c.write("def function(self):\n")

  21. c.indent()  # 缩进

  22. # 方法体

  23. c.dedent()  # 回退上一次缩进

скопировать код

Правила генерации сценария части класса интерфейса

Поскольку наш интерфейс хранится в структуре класса, мы можем перемещаться и заменять его в соответствии с интерфейсом объекта API текущего скрипта.

Правила генерации кода для частей варианта использования интерфейса

прецедент особого значения

Вариант использования для генерации специальных значений, таких как 0, None, пустая строка для каждого параметра

Тип параметра позиционирования

Через тип, заданный параметром интерфейса, сгенерируйте значение, соответствующее типу, и некоторые значения, которые не соответствуют типу параметра (надежность), и сгенерируйте вариант использования после назначения.Следующий пример кода

Целевые определенные параметры ключевых слов

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

  • При столкновении с параметрами, подобными времени начала и времени окончания, вы можете создать вариант использования, который сравнивает два параметра времени до и после текущего времени, и вариант использования, который сравнивает два параметра времени до и после.

Правила генерации должны согласовываться с некоторыми базовыми принципами разработки.Кроме того, нам нужно обобщать больше в ежедневном тестировании, выяснять те варианты использования с фиксированными правилами и находить способы обнаружения и создания таких вариантов использования.

Тип интерфейса местоположения

  • Интерфейс запроса: может генерировать запрос с одним параметром, запрос с комбинированным параметром, запрос с полным параметром и другие варианты использования.

  • Интерфейс класса обновления: может генерировать одно обновление для каждого параметра, комбинированное обновление, полное обновление и другие варианты использования.

Инструмент презентации автоматически генерирует тестовые сценарии

Блок-схема фреймворка

Расширяемость инструмента

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

  • Шаблон кода является расширяемым. Разные команды имеют разные стили спецификации кода и базовые шаблоны. Стиль сгенерированного шаблона можно настроить, что повышает гибкость инструмента.

  • Поддерживает преобразование нескольких типов данных и может быть расширен для создания объектов API, словарей параметров или других шаблонов данных в будущем.

Результаты и наблюдение

Повышение эффективности

На примере запроса купона было добавлено/обновлено около 10 интерфейсов (около 150 параметров запроса параметров, 100 возвращаемых параметров), включая несколько типов добавлений, удалений, изменений и запросов, а также время, необходимое для написания и отладки скрипты до и после использования инструмента Сравнить следующим образом:

Типы описание рабочей нагрузки без инструментов использовать инструменты Повышение эффективности
класс интерфейса около 250 параметров 2 дня/чел. в течение 1 часа 94%
пример использования надежности Около 1000 вариантов использования 2 дня/чел. 1 день/чел. 50%
средний --- --- --- 74%

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

Фокус-тест

  • Сокращение усилий по написанию сценариев увеличивает время, затрачиваемое на размышления о тестировании продукта, уточнении вариантов использования, проверке покрытия и т. д.

унифицированная спецификация

  • Унифицируйте ввод класса интерфейса и напишите спецификации, что удобно команде для поддержки и понимания сценария.

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

Инструмент рефакторинга

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


Последующие точки оптимизации итерации

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

  • Путем фактического вызова интерфейса, получения результатов, повышения точности автоматического создания ожидаемых результатов варианта использования и экономии времени на корректировку некоторых ожидаемых результатов.

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

Рекомендуемое чтение

Научите вас, как разработать загрузчик Webpack

Android.Arch.Paging: новые параметры загрузки страниц

Анализ собственного сетевого уровня React

Как реализовать привязку данных в VM framework

Узнайте об эффективном выполнении автоматизированных тестов