Система обеспечения качества интерфейса Youzan

предисловие

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

Давайте посмотрим на техническую архитектуру интерфейса Youzan и на то, что необходимо для обеспечения качества на каждом уровне:

Техническая архитектура Youzan Node разделена на бизнес-уровень, базовый уровень структуры, общий компонент и базовый уровень службы.Наше ежедневное внимание уделяется базовой структуре, общим компонентам и коду бизнес-уровня. Бизнес-уровень Node выполняет две функции: во-первых, предоставляет клиентский уровень для рендеринга страниц, который используется для взаимодействия с пользователями на стороне C, включая стили, поведение, js и т. д., а во-вторых, предоставляет сервисы данных. завершить инкапсуляцию интерфейса, ориентированного на сторону C.

Для каждого из различных слоев мы делаем несколько вещей для обеспечения качества, в том числе:

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

О работе по обеспечению качества этих размеров поговорим отдельно.

1. Автоматизация пользовательского интерфейса

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

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

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

1. Выбор кадра

-- puppeteer^[1], которая представляет собой библиотеку Node, поддерживаемую Chrome, основанную на протоколе DevTools для запуска браузеров Chrome или Chromium и поддерживающую как безголовые, так и безголовые режимы. Официальный сайт предоставляет очень богатую документацию, которую легко изучить.

Существует много видов фреймворков автоматизации пользовательского интерфейса, в том числе selenium и phantom; после сравнения выясняется, что puppeteer относительно легкий, и для его использования требуется только добавить пакет npm; он основан на методе, управляемом событиями, который более стабилен и имеет лучшую производительность, чем ожидание опроса селена; Кроме того, он изначально поддерживается хромом и может предоставлять все API-интерфейсы, поддерживаемые хромом. В то же время наш бизнес-сценарий должен охватывать только хром, поэтому это лучший выбор.

-- mocha^[2] + mochawesome^[3], mocha — это относительно распространенная среда тестирования, поддерживающая такие функции ловушек, как beforeEach, before, afterEach, after, утверждение утверждения, набор тестов, оркестровка вариантов использования и т. д.
mochawesome — это сторонний плагин для среды тестирования mocha, который поддерживает создание красивых отчетов в формате html/css.

Существует также множество тестовых фреймворков js на выбор, таких как mocha, ava, Jtest и т. д. Mocha выбран потому, что он более гибкий, и многие конфигурации можно комбинировать со сторонними библиотеками.Например, отчет объединяет mochawesome для генерации красивые html-отчеты; утверждения можно использовать с переопределением powser -assert.

2. Сценарии

• Базовая библиотека пакетов
  • Инкапсулировать процесс инициализации браузеров на стороне компьютера и на стороне h5.
  • Инкапсулируйте унифицированную обработку входа в систему на стороне компьютера и на стороне h5.
  • Инкапсулировать модель страницы и модель компонента
  • Унифицированный метод работы для инкапсуляции компонентов загрузки, компонентов даты, компонентов выбора и т. д.
  • Инкапсулирует такие методы, как input, click, hover, tap, scrollTo, hover, isElementShow, isElementExist, getElementVariable и т. д.
  • Обеспечить унифицированную поддержку получения элементов страницы и методов работы по форме "html-тег >> текст страницы"
  • Инкапсулируйте baseTest и добавьте унифицированные операции после начала и окончания варианта использования.
  • Инкапсулируйте утверждения, увеличьте журнал утверждений
• вариант использования в бизнесе
  • Установить базовую библиотеку
  • Оркестрация бизнес-кейсов

3. Выполнить логику

• Исполнение по среде
  • Добавить триггер изменения кода среды перед запуском, автоматическое выполнение онлайн-среды
• Мониторинг изменений исходного кода
  • Добавьте веб-хук gitlab для мониторинга исходного кода разработки и автоматического выполнения его в среде перед запуском при слиянии мастера.
  • Добавьте веб-хук gitlab для автоматического запуска в производственной среде при отслеживании изменений в тестовом примере.
• Ежедневное выполнение по расписанию
  • Добавьте crontab для регулярного запуска онлайн-среды каждый день.

2. Тест интерфейса

Тест интерфейса в основном направлен на серверный уровень Node.Согласно нашей спецификации разработки, Node не выполняет сложную бизнес-логику, но необходимо один раз преобразовать интерфейс dubbo, предоставляемый сервисным приложением, или объединить несколько интерфейсов dubbo для обеспечения один для http-интерфейса данных рендеринга h5/applet, процесс преобразования приводит к получению, объединению и преобразованию различных данных, формируя новый сквозной интерфейс. В настоящее время автоматизация интерфейса службы сама по себе не может гарантировать полное покрытие интерфейса верхнего уровня, поэтому мы также проводим автоматизированное тестирование интерфейса Node. Чтобы использовать единую тестовую среду в тесте, мы используем java для запроса http-интерфейса, предоставляемого Node, а затем, когда все варианты использования написаны, как судить о качестве теста интерфейса? Охватывает ли он полностью всю бизнес-логику? В настоящее время необходим эффективный метод для получения охвата теста, чтобы проверить, какие сценарии не охвачены тестом интерфейса, чтобы лучше обнаруживать и заполнять пробелы.

istanbul^[4]Это простой в использовании инструмент покрытия js в отрасли, который использует хуки загрузки модулей для расчета покрытия операторов, строк, методов и ветвей, чтобы прозрачно увеличить покрытие при выполнении тестовых случаев. Он поддерживает все типы покрытия js, включая модульное тестирование, функциональное тестирование на стороне сервера и тестирование браузера.

Однако варианты использования нашего интерфейса написаны на Java-коде и достигают сервера Node через HTTP-запросы, а не модульные тесты js или функциональные тесты браузера.Как мы можем получить покрытие интерфейса Node?

Решение состоит в том, чтобы увеличить параметр покрытия: --handle-sigint.Запустите службу, добавив параметр --handle-sigint.Когда служба получит сигнал SIGINT (SIGINT связан с Ctrl+C в linux), она уведомит Стамбул для создания покрытия. Эта команда хорошо работает для нас и, таким образом, формирует модель покрытия нашего интерфейса:

1. istanbule --handle-sigint 启动服务
2. 执行测试用例
3. 发送 SIGINT结束istanbule，得到覆盖率

В конце концов, наша проблема покрытия интерфейса Node была решена и построена автоматически с помощью непрерывной интеграции jenkins.

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

verbose: false
instrumentation:
    root: .
    extensions:
        - .js
    default-excludes: true
    excludes:['**/common/**','**/app/constants/**','**/lib/**']
    embed-source: false
    variable: __coverage__
    compact: true
    preserve-comments: false
    complete-copy: false
    save-baseline: false
    baseline-file: ./coverage/coverage-baseline.json
    include-all-sources: false
    include-pid: false
    es-modules: false
reporting:
    print: summary
    reports:
        - lcov
    dir: ./coverage
    watermarks:
        statements: [50, 80]
        lines: [50, 80]
        functions: [50, 80]
        branches: [50, 80]
    report-config:
        clover: {file: clover.xml}
        cobertura: {file: cobertura-coverage.xml}
        json: {file: coverage-final.json}
        json-summary: {file: coverage-summary.json}
        lcovonly: {file: lcov.info}
        teamcity: {file: null, blockName: Code Coverage Summary}
        text: {file: null, maxCols: 0}
        text-lcov: {file: lcov.info}
        text-summary: {file: null}
hooks:
    hook-run-in-context: false
    post-require-hook: null
    handle-sigint: false
check:
    global:
        statements: 0
        lines: 0
        branches: 0
        functions: 0
        excludes: []
    each:
        statements: 0
        lines: 0
        branches: 0
        functions: 0
        excludes: []

3. Модульное тестирование

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

Сценарий с одним тестом тестировал две платформы:

• Jest^[5]
• ava^[6]

Рекомендуемым решением является Jest, который поддерживает утверждение режима Matchers; поддерживает тестирование моментальных снимков, которое может проверить правильность HTML-кода, отображаемого кодом класса компонента; поддерживает различные моки, включая реализацию фиктивного метода, фиктивный таймер, зависимые от фиктивных модули и т. д. .; поддерживает Стамбул, вы можете легко получить покрытие.

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

4. Базовая сигнализация изменения библиотеки

Мы выполнили модульные тесты для базовых служб и базовых компонентов, описанных выше, но модульные тесты не могут полностью гарантировать, что изменения в базовой библиотеке полностью корректны.С введением новой версии базовой библиотеки на бизнес-уровне ошибки будут быть дополнительно введены в бизнес-уровень и, в конечном итоге, влиять на обычное использование C-конечными пользователями. Так как же обеспечить получение комплексной отдачи каждый раз, когда бизнес-уровень представляет новую версию базовой библиотеки? Как сделать так, чтобы студенты бизнес-тестов были более чувствительны к основным изменениям в библиотеке? В ответ на эту ситуацию мы решили сделать небольшой инструмент для изменения базовой версии библиотеки. Идея реализации следующая:

1. 对比一次 master 代码的提交或 merge 请求，判断 package.json 中是否有特定基础库版本变更
2. 将对应基础库的前后两个版本的代码对比发送到测试负责人
3. 根据 changelog 判断此次回归的用例范围
4. 增加 gitlab webhook，只有合并到合并发布分支或者 master 分支的代码才触发检查

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

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

Пять, сторожевая тревога

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

sentry^[7]— это инструмент отслеживания ошибок с открытым исходным кодом, который помогает разработчикам отслеживать и исправлять сбои в режиме реального времени.

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

После изменения поза с использованием часового выглядит так:

• Глобальная информация о часовом сообщается и фильтруется
  • Тип ошибки: TypeError или ReferenceError
  • Ошибка возникает для пользователей> 1k
  • Ошибка в js файле
  • Магазины с ошибками > 2
• Увеличьте активную отчетность об аномальных процессах основного бизнеса

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

6. Деловая сигнализация

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

Бизнес-оповещения — это часть, которая может наиболее быстро реагировать на проблемы в производственной среде.Если оповещение появляется после выпуска, мы выбираем как можно скорее откатить его, чтобы обеспечить стабильность в сети.

7. Технические характеристики

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

• спецификация выпуска
  • Несколько ежедневных выпусков слияния веток
  • Ограничить время выпуска
  • Стандартизируйте процесс выпуска
  • Организация основных контрольных точек самопроверки
• Библиотека базовых вариантов использования
  • Регулярные обновления различных вариантов использования P0 для бизнеса
  • Варианты использования проекта регулярно обновляются в библиотеке вариантов использования бизнес-регрессии.
  • Онлайн-сценарии проблем своевременно обновляются до библиотеки вариантов использования регрессии.

В настоящее время процедуры тестирования внешнего интерфейса, которые вам нравятся, в основном такие.Конечно, некоторые из обычных усилий не были полностью выполнены.Например, добавление сравнения структуры возвращаемого значения в тесте интерфейса, добавление теста набора онлайн-интерфейса или страницы^[8]; Обучение дизайну кейсов для самотестирования для разработчиков и т. д. Также изучается множество новых функций, таких как доступ к механизму сравнения трафика, направление онлайн-трафика в предзапусковую среду и проведение сравнительных тестов перед запуском кода, добавление снимков экрана для автоматизации пользовательского интерфейса, изучение автоматизации пользовательского интерфейса для небольших программ, и Т. Д.

Ссылка на ссылку:

• [1] GitHub.com/Google CHROM…
• [2] Уууу, эта лошадь plus.com/package/rubbing…
• [3] Уууу, эта лошадь plus.com/package/rubbing…
• [4] GitHub.com/got война потеряна/…
• [5] GitHub.com/Facebook/Сумма…
• [6] github.com/avajs/ava
• [7] docs.sentry.io
• [8] Specialties.youzan.com/youzan-о, где...