Этот пост создан для пояснений контента, представлении себя и на какие уровни делится контент и что вы получаете взамен своим средствам.

Кто я такой?

Я — Виталий, инженер по автоматизации тестирования. Пишу преимущественно на JavaScript/Typescript. Имею инженерное образование по программированию.

Почему автоматизация тестирования?

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

Почему контент здесь платный?

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

Какие подписки есть?

Весь контент делится на 3 большие части:

• Нефункциональное тестирование — нагрузочное тестирование, база по нагрузочному тестированию, тестирование доступности. Все то, что относится к нефункциональным требованиям
• Функциональное тестирование — здесь собраны знания, касательно автоматизации тестирования, базы по автоматизации тестирования. Все то, что относится к функциональным требованиям
• Архитектор — знания, которые являются максимально полезными для широкого спектра людей. От менеджера по тестированию до архитектора по автоматизации. Это либо «задротский» либо менеджерский контент.

Будет ли контент дублироваться на твой телеграм?

Зависит от самого контента.

Какая разница между телеграм каналом и текущей площадкой?

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

Новости будут дублироваться на эту площадку?

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

Приветствую, любители нагрузки. Для истории прошлые выпуски:

• Новости Perfscale № 1
• Perfscale news #2: Fix Protocol, Magic metrics и MCP
• perfscale news #3 Websocket, Inference, NPM
• Perfscale news #4. GRPC, Fixed Triggers, Child Process
• Perfscale news #5. SQL, thresholds и оптимизации

Во-первых, хочется поблагодарить пользователя Aleksandr Lebedev (TG: @iamtechnomage) за приятного маскота! [Ссылка на первое упоминание маскота].

Во-вторых в этой ревизии будет довольно мало новостей, касательно Perfscale Platform. Из-за того, что я до сих пор борюсь с Linked Accounts.

И по традиции мы начинаем с 

Perfscale OSS (open source software)

Теперь версии 0.10.0. Github release.

GraphQL

Да, теперь вы можете нагружать ваши GraphQL сервисы. Появился шаг std/graphql@v1. Выглядит это следующим образом

steps:
  - name: fetch viewer
    use: std/graphql@v1
    with:
      url: 127.0.0.1:4000/graphql
      query: |
        query GetViewer($id: ID) {
          viewer(id: $id) { id name }
        }
      variables: { "id": "u-1" }
    check:
      status: 200
      duration_ms_lt: 250
    outputs: viewer

  - name: list widgets
    use: std/graphql@v1
    with:
      url: 127.0.0.1:4000/graphql
      query: |
        {
          widgets { id name }
        }
    outputs: widgets

  - name: rename widget
    use: std/graphql@v1
    with:
      url: 127.0.0.1:4000/graphql
      query: |
        mutation Rename($id: String!, $name: String!) {
          renameWidget(id: $id, name: $name) { id name }
        }
      # ${uuid} expands per execution — every rename sends a fresh name.
      variables: { "id": "w-1", "name": "renamed-${uuid}" }
    check:
      status: 200

Ну а конфигурация у вас достаточно простая.

vus: 5
duration: 30s

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

Приветствую, любители нагрузки. Для истории прошлые выпуски

• Новости Perfscale № 1
• Perfscale news #2: Fix Protocol, Magic metrics и MCP
• perfscale news #3 Websocket, Inference, NPM
• Perfscale news #4. GRPC, Fixed Triggers, Child Process

Итак, эту неделю открывают новости по OSS проекту — perfscale oss.

Perfscale OSS (open source software)

SQL

Да, вы не ослышались. Теперь даже в OSS движке вы можете написать что-то такое

# db.config.yaml
vus: 5
duration: 30s
variables:
  db_dsn: postgres://bench:secret@127.0.0.1:5432/bench

Ну а в самом тесте, что-то такое

steps:
  - name: connect
    uses: std/db-connect@v1
    with:
      driver: postgres
      dsn: "${{ vars.db_dsn }}"
      mode: persistent
    outputs: conn

  - name: begin tx
    uses: std/db-tx-begin@v1
    with: { id: "${{ conn.id }}" }

  - name: create bench table
    uses: std/db-query@v1
    with:
      id: "${{ conn.id }}"
      query: CREATE TABLE IF NOT EXISTS bench (id TEXT, payload TEXT)

  - name: insert row
    uses: std/db-query@v1
    with:
      id: "${{ conn.id }}"
      # The SQL text is never interpolated — values move through `params`.
      query: INSERT INTO bench (id, payload) VALUES ($1, $2)
      params: ["${{ vars.uid }}", "payload"]

  - name: read it back
    uses: std/db-query@v1
    with:
      id: "${{ conn.id }}"
      query: SELECT payload FROM bench WHERE id = $1
      params: ["${{ vars.uid }}"]
    check:
      duration_ms_lt: 50

  - name: commit
    uses: std/db-tx-commit@v1
    with: { id: "${{ conn.id }}" }

  - name: close
    uses: std/db-close@v1
    with: { id: "${{ conn.id }}" }

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

Thresholds

Теперь в поле after для конфигурации можно писать метрики качества. Причем, если у вас сценарий, допустим для http, но написали метрики для gprc например. То метрики качества будут проигнорированы. Зато при запуске той же конфигурации, но для gprc сценария — то алерты сработают как надо.

пример конфигурации

config:
  vus: 10
  duration: 1m
steps:
  - name: query
    use: std/db-query@v1
    with:
      id: ${{ conn.id }}
      query: SELECT * FROM orders WHERE created > $1
      params: ["2026-01-01"]
after:
  - name: slo gate
    use: std/thresholds@v1
    with:
      db_query_duration: ["p95<500", "max<2000"]
      db_query_failed: ["rate<0.05"]
      db_errors: ["count==0"]
    severity: fail # can be fail, pass, warn
    message: "checkout SLO"

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

Приветствую, любители нагрузки. Для истории прошлые выпуски

• Новости Perfscale № 1
• Perfscale news #2: Fix Protocol, Magic metrics и MCP
• perfscale news #3 Websocket, Inference, NPM

Эта неделя открывает долгожданные фичи, начнём с OSS части:

GRPC

В третьем выпуске я намекал, что после Websocket на очереди gRPC. Так вот — он здесь. Теперь perfscale умеет гонять не только REST, WebSocket и FIX, но и полноценный gRPC: unary, client/server streaming и bidi. Схема подтягивается либо через reflection, либо через descriptor-файл — на выбор.

Простой unary-вызов выглядит так:

steps:
  - uses: std/grpc@v1
    with:
      url: grpc://api.example.com:50051
      service: api.OrderService
      method: CreateOrder
      proto:
        reflection: true
      payload:
        customer_id: "cust-${seq}"
        items:
          - sku: "SKU-${rand(1000,9999)}"
            qty: "${rand(1,10)}"
    check:
      status: OK
      json: { order_id: "${exists}" }

А если вам нужен streaming — используйте отдельные шаги жизненного цикла, как и с Websocket:

• std/grpc-connect@v1 — устанавливает соединение
• std/grpc-send@v1 — отправляет сообщение в поток
• std/grpc-recv@v1 — читает до stopping rule (until_json, until_contains или количество)
• std/grpc-close@v1 — закрывает поток и соединение

Метрики, которые теперь доступны из коробки:

• grpc_req_duration — полный цикл unary-вызова (p50 / p95 / max)
• grpc_stream_duration — время жизни стрима
• grpc_msgs_sent / grpc_msgs_received — throughput по сообщениям
• grpc_streams_active — одновременно открытые стримы

Кстати, reflection работает не со всеми серверами (кому-то безопасность не позволяет), поэтому descriptor-файл через proto: { file: «service.pb» } — ваш план Б.

Child Process

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

Итак, оставляю прошлые недели для истории:

• perfscale news #1. Perfscale OSS, QUERY method
• perfscale news #2. Fix Protocol, Magic metrics и MCP

Эта неделя открывает супер фичи, начем с OSS части:

perfscale теперь версии 0.6 (github) — и сделано много чего. Начнем с …

NPM

С недавнего времени начал публиковать бинарники не только на github, но и на NPM. Так что теперь perfscale можно просто установить через команду

npm i -g @perfscale/exe 

Кстати, команда self-update учитывает тот факт, что бинарник был установлен через npm, и в случае нового релиза вы будете оповещены, что именно на npm вышла новая версия, что , как мне кажется, очень удобно.

Websocket

поддержка Websocket. Теперь вы можете запускать тесты на websocket и мы на шаг ближе к универсальному комбаину для любых видов нагрузочных тестов. (А впереди еще и gRPC, WebRTC и дургое… )

Простой тест выглядит так

steps:
  - uses: std/ws@v1
    with:
      url: wss://stream.example.com/feed
      messages:
        - send: '{"op":"subscribe","channel":"trades","id":"sub-${seq}"}'
          until_json: { type: trade }
    check:
      message_matches: { type: trade }

А также, если вам надо уметь управлять порядком вызовов(а не просто подключится -> отправить -> закрыть соединение) то в секции concepts можно найти вот такие шаги

std/ws-connect@v1 — Откывает коннект

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

Итак, прошлый выпуск новостей очень понравился аудитории, поэтому я продолжаю делится тем, что произошло с Perfscale.

Fix Protocol

Поскольку я работаю в FinTech кампании и мы тестируем FIX protocol то я не могу обойти стороной тот факт, что нам надо уметь нагружать FIX protocol. Поэтому скорость ввода данной фичи был вопросом времени.

Небольшое Предисловие по поводу FIX protocol:

Все брокеры(да, там где акции, котировки, и прочие заумные слова, о которых обычный и здоровый человек не особо вкурсе и слава богу), общаются по FIX протоколу. Этот протокол действует аж с 1992 года и в настоящее время у него 4 версия. Она же[прим. версия 4 FIX Protocol] и широко распространена. Да, TBank и МосБиржа и любая более-менее значимая биржа общаются по FIX protocol. Я в свое время рассказывал как работает FIX protocol на одном из митапов. Может когда-нибудь запишу видео о том, как он работает на пальцах.

Итак, возвращаясь к Fix protocol. В Perfscale я реализовал данный функционал и для теста test.yaml фаил выглядит так

steps:
 - uses: pro/fix@v1
  with:
   host: fix.venue.com
   port: 9823
   tls: true
   begin_string: FIXT.1.1
   sender_comp_id: CLIENT
   target_comp_id: VENUE
   heart_bt_int: 30
   messages:
    - MsgType: NewOrderSingle
     ClOrdID: order-1
     Symbol: EURUSD
     Side: 1
     OrderQty: 100000
     OrdType: 1

Но вы можете сказать: а что если хост, порт и прочие данные уже есть и они известны нам, не дублировать же в шагах данные каждый раз. Верно! Для этого я вынес для config.yaml шаг pro/fix-config@v1

before:
  - uses: std/http@v1
    with: { url: https://.../FIX44.xml }
    outputs: dict
  - uses: pro/fix-config@v1
    with:
      host: fix.venue.com
      port: 9823
      tls: true
      sender_comp_id: CLIENT
      target_comp_id: VENUE
      schema: "${{ dict.body }}"
    outputs: venue # сохраняем конфигурацию для переиспользования

В таком случае тот же тест сокращается в несколько раз

steps:
  - uses: pro/fix@v1
    with: 
     connection: "${{ config.venue }}"
messages:
  - MsgType: NewOrderSingle
    ClOrdID: "ord-${seq}"                 # уникальный на каждый ордер
    Symbol: "${choice(EURUSD|GBPUSD|USDJPY)}"
    Side: "${rand(1,2)}"
    OrderQty: "${rand(1000,100000)}"
    Price: "${randf(1.05,1.15,5)}"
    TransactTime: "${now}"
    _repeat: 100                          # 100 ордеров…
    _interval_ms: 50                      # …по одному каждые 50 мс

А что за seq, choice, и причие значения, спросите вы?

Поскольку тесты у нас могут быть динамическими(например цена выполнения) то без runtime функций помощников никуда. Пока что я стараюсь добавлять их точечно и аккуратно и их кол-во фиксировано

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

Сегодня в подборке новостей с полей Perfscale:

• Perfscale Open source
• Поддержка QUERY метода
• Подача в LvlUp венчурный фонд

Open Source

Итак, начнем с Open source. Часть движка я все-таки решил сделать открытым. Плюс выделил отдельную организацию в github — Perfscale/perfscale. Код я переводил с помощью ИИ, поэтому ошибки могут быть. Также, в рамках переезда я сделал бенчмаркинг, поскольку perfscale может запускать locust и k6(jmeter пока не переводил в open source) то и benchmark тоже собирается а еще он сравнивается с прошлым прогоном, чтобы отслеживать прогресс. Вот пример такой задачи, а выглядит это так.

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

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

QUERY HTTP метод.

Если вы читаете новости в телеграм канале haradkou_sdet, то наверняка видели новость про RFC 10008. Если кратко, то этот метод создан как раз для идемпотичных[прим. — неизменяемых] данных при одинаковых входных данных. Поскольку строка поиска имеет ограничение по длинне и туда можно зашить уязвимости. Теперь количество уязвимостей может быть гораздо больше :)

Так вот мы добавили поддержку QUERY для HTTP запросов. В YAML это выглядит как-то так