Testy obciążenia, stresu i benchmarków

Testowanie wydajności wspomagane AI polega na tym, że agent kodujący pisze skrypty k6 do testów obciążenia i stresu na podstawie progów opóźnień ustalonych przez człowieka, uruchamia je przez serwer MCP k6 i szereguje wąskie gardła według podsumowania k6 oraz danych z bazy. Werdykt wydają progi k6 i porównanie z linią bazową w CI, nigdy interpretacja agenta.

Ta strona jest dla programistów i liderów technicznych, którzy odpowiadają za budżet opóźnień usługi. Twoje API do składania zamówień wytrzymuje na stagingu 500 żądań na sekundę. W dniu premiery ruch rośnie trzykrotnie, pula połączeń z bazą się wyczerpuje, p95 skacze ze 120 ms do 4 s i nikt nie potrafi wskazać commita, który zjadł zapas. Poniższy przepływ pracy znajduje ten limit, zanim zrobią to użytkownicy.

Co zyskujesz dzięki testom obciążenia z AI

• Serwer MCP k6 podłączony do Claude Code, Codeksa i Cursora, dzięki czemu agent sam waliduje i uruchamia swoje skrypty
• Pięć promptów do skopiowania: test obciążenia sterowany progami, test stresu szukający punktu załamania, ranking wąskich gardeł, pomiar front-endu pod obciążeniem i bramka porównania z linią bazową
• Workflow CI z dwiema bramkami: bezwzględnymi progami przez kod wyjścia k6 run i bramką względną, która oblewa pull request, gdy p95 pogorszy się o ponad 20% względem zapisanej linii bazowej
• Podział odpowiedzialności: ludzie ustalają progi i linię bazową, agent pisze skrypty i diagnozuje, k6 decyduje o wyniku
• Sytuacje, w których liczby z testów obciążenia wprowadzają w błąd, i sposób wyjścia z każdej z nich

Jak podłączyć k6 do agenta kodującego?

k6 to samodzielna binarka w Go, która uruchamia skrypty testowe w JavaScripcie. Zainstaluj ją według instrukcji instalacji k6 albo menedżerem pakietów (brew install k6). Nie uruchamiaj npm install k6: pakiet k6 w npm to niezwiązany placeholder w wersji 0.0.0.

Na k6 zainstaluj oficjalny serwer MCP od Grafany, grafana/mcp-k6. Daje agentowi cztery narzędzia: validate_script (jeden VU, jedna iteracja), run_script, list_sections i get_documentation. Serwer jest dystrybuowany jako binarka mcp-k6, obraz Dockera grafana/mcp-k6 albo podpolecenie k6 x mcp, które podłącza k6 x agent init, a nie jako pakiet npm, więc każdy „k6 MCP” uruchamiany przez npx traktuj jako nieoficjalny. Grafana oznacza mcp-k6 jako eksperymentalny (README, sprawdzone 2026-09-26; najnowsze wydanie v0.6.1), więc przypnij wersję, którą przetestowałeś.

Najszybciej skonfigurujesz wszystko podpoleceniem k6 x agent, które informacje o wydaniu k6 v2.1.0 opisują jako „Bootstrap an AI-assisted k6 testing workflow in any editor”. Wymaga k6 v2.1.0 lub nowszego (aktualnie: v2.3.0); starsze k6 zgłosi nieznane polecenie, a README mcp-k6 nadal opisuje k6 x mcp jako wymagające własnej kompilacji xk6. Uruchom k6 x, żeby wypisać wbudowane podpolecenia i potwierdzić, że są wśród nich agent i mcp, a potem uruchom je w katalogu głównym repozytorium:

# Podgląd plików, które zostaną zapisane, a potem zapis
k6 x agent init claude-code --dry-run
k6 x agent init claude-code        # inne cele: codex-cli, cursor, opencode, vscode-copilot, cline
k6 x agent status                  # co jest zainstalowane w tym projekcie
k6 x agent skills list             # lista skilli wbudowanych w binarkę k6

Polecenie podłącza edytor do wbudowanego w k6 serwera k6 x mcp, więc osobna binarka mcp-k6 nie jest potrzebna, i instaluje skille k6 (k6-load-test, k6-smoke-test, k6-trend-analysis, k6-test-maintenance i inne). Dla Claude Code są to .mcp.json, .claude/settings.local.json i .claude/skills/, dla Codeksa .codex/mcp.json i .codex/skills/, dla Cursora .cursor/mcp.json i .cursor/rules/. Codex (sprawdzone w v0.157.1) czyta serwery MCP z config.toml, a nie z .codex/mcp.json: uruchom codex mcp list, a jeśli brakuje k6, zarejestruj go poleceniem codex mcp add k6 -- k6 x mcp (albo -- mcp-k6). Jeśli wolisz zarejestrować samodzielny serwer ręcznie, zainstaluj binarkę raz (brew tap grafana/grafana && brew install mcp-k6 albo docker pull grafana/mcp-k6:latest) i dodaj ją w każdym narzędziu:

Claude Code

claude mcp add --scope user --transport stdio k6 -- mcp-k6

# Bez lokalnej binarki:
claude mcp add --scope user --transport stdio k6 -- docker run --rm -i grafana/mcp-k6

Codex

codex mcp add k6 -- mcp-k6

Polecenie zapisuje ten blok w ~/.codex/config.toml, który możesz też edytować bezpośrednio:

[mcp_servers.k6]
command = "mcp-k6"

Cursor

Dodaj serwer do pliku .cursor/mcp.json w projekcie (tego samego, który zapisuje k6 x agent init cursor):

{
  "mcpServers": {
    "k6": { "command": "mcp-k6" }
  }
}

Do wydajności front-endu dodaj serwer MCP Chrome DevTools (chrome-devtools-mcp w npm). Nagrywa ślady wydajności (performance_start_trace) i rozkłada je na wnioski (insights), np. rozbicie LCP, więc do tego zadania pasuje lepiej niż Playwright MCP. Jego narzędzie lighthouse_audit obejmuje dostępność, SEO i dobre praktyki, ale pomija wydajność, dlatego mierz śladem. Domyślnie wysyła statystyki użycia do Google; wyłączysz to flagą --no-usage-statistics.

Claude Code

claude mcp add chrome-devtools --scope user -- npx chrome-devtools-mcp@latest --no-usage-statistics

Codex

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --no-usage-statistics

Cursor

Dodaj serwer do .cursor/mcp.json w projekcie:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--no-usage-statistics"]
    }
  }
}

Kto o czym decyduje w pętli testów obciążenia?

Pętla wygląda tak samo w każdym narzędziu. Liczy się to, kto odpowiada za który krok, bo agent, który pisze test, uruchamia go i ocenia wynik, sam sobie wystawia ocenę.

1. Ty ustalasz cele. Opóźnienia p95 i p99, odsetek błędów i ruch, który usługa musi przetrwać, pochodzą z SLO albo od właściciela produktu, nie od agenta. Te liczby trafiają do thresholds w skrypcie.
2. Agent pisze skrypt na podstawie tych celów, a potem wywołuje validate_script, żeby błąd składni lub importu wyszedł po jednej iteracji, a nie po ośmiu minutach przebiegu.
3. Sprawdzasz kształt skryptu, nie każdą linię. Zweryfikuj cztery rzeczy: endpoint i metodę, czasy etapów, zgodność progów z tym, o co prosiłeś, oraz to, że host docelowy pochodzi ze zmiennej środowiskowej.
4. Agent uruchamia test na stagingu przez run_script i raportuje, które progi nie przeszły.
5. Agent szereguje wąskie gardła na podstawie podsumowania k6 oraz danych z bazy i APM z tego samego okna czasowego.
6. Werdykt należy do CI. k6 kończy się niezerowym kodem, gdy próg nie przejdzie, a skrypt porównujący oblewa build, gdy p95 pogorszy się względem linii bazowej. Każdą zmianę progów lub linii bazowej zatwierdza lider techniczny.

Wygeneruj test obciążenia z twoich progów opóźnień

Zacznij od jednego endpointu i liczb, które podajesz sam. Skrypt z twoimi liczbami sprawdzisz w minutę; „napisz test obciążenia” daje wiarygodnie wyglądający skrypt z wymyślonymi wartościami.

Prompt do skopiowania: test k6 dla jednego endpointu sterowany progami

Write a k6 script at tests/perf/checkout.js that load-tests
POST /api/checkout on our Node/Express + Postgres backend.

- Stages: ramp 0 -> 200 VUs over 2m, hold 200 VUs for 5m, ramp down over 1m.
- Body: realistic JSON with cartId and paymentMethod, taken from
  tests/perf/data/carts.json via SharedArray. No hardcoded single cart.
- Header: Authorization: Bearer ${__ENV.TOKEN}. Host: ${__ENV.BASE_URL}.
- Thresholds: http_req_duration p(95)<300 and p(99)<800,
  http_req_failed rate<0.01.
- check() that status is 200; sleep(1) think time per iteration.

Validate it with the k6 MCP validate_script tool first. Then run it
against BASE_URL with run_script and report: each threshold pass/fail,
actual p95 and p99, achieved requests per second, and dropped_iterations.
Do not change any threshold to make the run pass.

Wynik powinien wyglądać mniej więcej tak: konkretne etapy, twoje progi i nic zaszytego na sztywno, co powinno pochodzić ze środowiska.

import http from 'k6/http';
import { check, sleep } from 'k6';
import { SharedArray } from 'k6/data';

const carts = new SharedArray('carts', () => JSON.parse(open('./data/carts.json')));

export const options = {
  stages: [
    { duration: '2m', target: 200 },
    { duration: '5m', target: 200 },
    { duration: '1m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<300', 'p(99)<800'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const cart = carts[Math.floor(Math.random() * carts.length)];
  const res = http.post(`${__ENV.BASE_URL}/api/checkout`, JSON.stringify(cart), {
    headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${__ENV.TOKEN}` },
  });
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

Sposób wywołania różni się między narzędziami, prompt pozostaje ten sam.

Claude Code

Uruchom interaktywną sesję z zapisanym promptem jako pierwszą wiadomością:

claude "$(cat prompts/perf-checkout.txt)"

Zanim agent pierwszy raz wywoła run_script, upewnij się, że BASE_URL wskazuje staging. Test obciążenia przez pomyłkę wycelowany w produkcję to awaria, którą sam wywołałeś.

Codex

Uruchom sesję interaktywną z polityką zatwierdzeń on-request, w której model sam decyduje, kiedy zapytać cię przed wykonaniem polecenia:

codex -a on-request "$(cat prompts/perf-checkout.txt)"

Długich testów stresu nie trzymaj w sesji na laptopie: uruchamiaj je w zaplanowanym jobie CI na runnerze, który ma dostęp do stagingu.

Cursor

Wklej prompt do czatu Agenta z serwerem k6 włączonym w .cursor/mcp.json. W edytorze uruchamiaj tylko krótkie testy dymne; ośmiominutowy test obciążenia blokuje agenta, który czeka na wynik.

Zapisz prompt w prompts/perf-checkout.txt, żeby następna osoba wygenerowała ten sam test. Realistyczne dane koszyków i użytkowników opisuje strona strategie danych testowych i fixtures.

Znajdź punkt załamania testem stresu

Test obciążenia odpowiada na pytanie, czy usługa wytrzyma oczekiwany ruch. Test stresu odpowiada, przy jakim natężeniu przestaje wytrzymywać, i ta liczba trafia do planu pojemności. Zdefiniuj „awarię” przed przebiegiem, żeby test zwrócił liczbę, a nie wrażenie.

Użyj tu executora opartego na natężeniu napływu (arrival rate). Rampa VU pozwala przepustowości spadać, gdy rosną opóźnienia, więc test po cichu wysyła mniej ruchu dokładnie wtedy, gdy serwer ma problem.

Prompt do skopiowania: test stresu szukający punktu załamania

Write a k6 stress test at tests/perf/stress.js that finds the request
rate at which our API breaks.

- Use the ramping-arrival-rate executor: start at 50 iterations/s, add
  50 iterations/s every 2 minutes, up to 1,000 iterations/s.
  Set preAllocatedVUs and maxVUs high enough that dropped_iterations
  stays at 0 until the server, not k6, is the limit.
- Each iteration: GET /api/products, GET /api/products/{random id from
  tests/perf/data/products.json}, POST /api/orders.
- Tag each request with its endpoint name so the summary splits by endpoint.
- Breaking point = the first stage where p95 > 2s OR http_req_failed > 5%.
  Tag requests with the current stage (tagWithCurrentStageIndex from
  k6-utils) and add per-stage thresholds such as
  http_req_duration{stage:3}, so the breaking stage is measured, not
  inferred from the cumulative p95.
  Use thresholds with abortOnFail: true and delayAbortEval: '30s'.

After the run, give me a Markdown table per stage: target rate, achieved
rate, p50/p95/p99 per endpoint, error rate, dropped_iterations. Name the
stage that broke and which endpoint broke first.

Jeśli dropped_iterations rośnie wcześniej niż opóźnienia, generatorowi obciążenia zabrakło VU albo CPU, a „punkt załamania” należy do twojego laptopa. Zanim zaufasz tej liczbie, podnieś maxVUs albo przenieś przebieg na większą maszynę.

Która warstwa nasyciła się pierwsza?

Czerwony próg mówi, że usługa jest wolna. Nie mówi, czy przyczyną jest zapytanie, pula połączeń, CPU aplikacji czy wywołanie zewnętrzne. Ta diagnoza to miejsce, w którym agent naprawdę pomaga, pod warunkiem że dostanie dowody z tego samego okna czasowego i będzie musiał je cytować.

Prompt do skopiowania: ranking wąskich gardeł według dowodów

Below are three artifacts from one load test, 14:00-14:08 UTC:
1. The k6 end-of-test summary (JSON).
2. The Postgres slow-query log for that window (log_min_duration_statement=200).
3. Our pool config: pg Pool max=20, Express on 2 Node processes.

Tasks:
- Rank the top 5 contributors to p95 on POST /api/checkout.
- For each, classify it: query, pool exhaustion, application CPU,
  external call, or load generator. Quote the log line or metric
  that supports it. If the evidence does not support a claim, say
  "not supported by the data" instead of guessing.
- Explain why latency degrades non-linearly between the last healthy
  stage and the first failing one.
- Propose the single change with the best latency gain per hour of
  work, with the exact code or CREATE INDEX CONCURRENTLY statement,
  and the k6 run that would prove it worked.

Do not propose schema changes that need downtime.

Ostatnie zdanie promptu jest kluczowe: każda poprawka przychodzi z przebiegiem, który ją udowadnia. Wprowadź zmianę, uruchom ten sam skrypt i porównaj p95. Pętlę zamyka pomiar, a nie wyjaśnienie agenta.

Żeby powiązać nieudane progi z błędami i wolnymi transakcjami po stronie serwera, dodaj serwer MCP Sentry (zdalny, OAuth) i poproś agenta o zestawienie najwolniejszych transakcji z Sentry w oknie testu z porażkami k6:

Claude Code

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

Codex

codex mcp add sentry --url https://mcp.sentry.dev/mcp && codex mcp login sentry

Cursor

Dodaj zdalny serwer do .cursor/mcp.json i zaloguj się przez OAuth, gdy pojawi się prośba:

{
  "mcpServers": {
    "sentry": { "url": "https://mcp.sentry.dev/mcp" }
  }
}

Omijaj pakiet npm o nazwie sentry-mcp: to niezwiązany stub w wersji 0.0.1. Własny pakiet stdio Sentry to @sentry/mcp-server, przeznaczony dla Sentry hostowanego samodzielnie.

Większość nagłych skoków opóźnień w testach obciążenia prowadzi do zapytania, które było szybkie przy danych z seeda. Gdy ranking wskaże takie zapytanie, poproś agenta o benchmark z proponowanym indeksem i bez niego przy produkcyjnej liczbie wierszy (na przykład 1 mln i 10 mln), z wynikiem EXPLAIN (ANALYZE, BUFFERS) jako dowodem. Strojenie po stronie produkcji po wdrożeniu opisuje strona optymalizacja wydajności na produkcji.

Sprawdź Core Web Vitals, gdy API jest pod obciążeniem

p95 serwera może wyglądać dobrze, a strona nadal działa wolno, bo przeglądarka czeka na pracę, której API nie widzi. Mierz front-end w trakcie testu obciążenia, a nie na bezczynnym stagingu.

Prompt do skopiowania: wydajność strony pod obciążeniem API

Start `k6 run tests/perf/checkout.js` against BASE_URL in the background
from the shell (not run_script, which blocks until the run ends), and wait
for the hold stage (200 VUs). While it runs, use the Chrome DevTools MCP server to:

1. navigate_page to $BASE_URL/dashboard, then record three traces with
   performance_start_trace (reload and autoStop on, the defaults: each
   trace stops itself after about 5 s, so skip performance_stop_trace).
2. Right after each trace, before starting the next one, call
   performance_analyze_insight for the LCPBreakdown insight and any other
   insight that trace flags. It only reads the most recent trace.
3. Report LCP, CLS, and the longest main-thread tasks for each trace,
   the median of the three, and the LCP breakdown of the slowest trace.
4. Compare with one trace taken after the k6 run finishes.

Flag LCP > 2.5s or CLS > 0.1. For each flagged metric, name the request
or script that delayed it and whether it depends on an API the load test hits.

Ślad laboratoryjny nie mierzy INP, bo ta metryka wymaga prawdziwej interakcji użytkownika. INP bierz z danych terenowych w narzędziu RUM lub analitycznym, a tej kontroli używaj do LCP i przesunięć układu pod obciążeniem. Funkcjonalne testy w przeglądarce opisuje strona automatyzacja testów end-to-end.

Blokuj regresje wydajności w CI

Dwie bramki łapią dwa różne rodzaje problemów i potrzebujesz obu.

Bramka bezwzględna to thresholds w skrypcie. k6 run kończy się niezerowym kodem, gdy dowolny próg nie przejdzie, więc krokiem CI jest sam przebieg. Bramka względna łapie to, czego progi nie widzą: zmiana, która podwaja p95 z 90 ms do 180 ms, nadal przechodzi p(95)<300, choć zjada połowę zapasu. Do tego potrzebujesz zapisanej linii bazowej i porównania.

Prompt do skopiowania: bramka porównania z linią bazową

Build a performance regression gate for pull requests.

1. tests/perf/smoke.js: 10 VUs for 30s against ${__ENV.BASE_URL}, covering
   GET /api/products, GET /api/products/:id and POST /api/checkout.
   Tag requests with an endpoint tag and add a threshold per tag, such as
   'http_req_duration{endpoint:checkout}': ['p(95)<200'], so the summary
   contains a p95 for each endpoint. http_req_failed rate==0. Add a
   handleSummary() that writes summary.json.
2. scripts/perf-compare.mjs (Node, no dependencies): read perf/baseline.json
   and summary.json, compare p95 of http_req_duration per endpoint tag,
   print a Markdown table, and exit 1 if any endpoint's p95 is more than
   20% above baseline. Treat a missing endpoint in either file as a failure.
3. .github/workflows/perf.yml: on pull_request, start the app with
   docker compose up -d --wait, run the smoke test three times against
   http://localhost:3000, keep the median summary, then run perf-compare.
   permissions: contents: read. actions/checkout with persist-credentials: false.
   No secrets in this job.
4. A separate job on push to main that regenerates perf/baseline.json and
   opens a pull request with it. Give only that job contents: write and
   pull-requests: write. Never overwrite the baseline from a PR run.

Write unit tests for perf-compare.mjs covering: within band, over band,
missing endpoint, malformed JSON.

Workflow, który powinien powstać z tego promptu, wygląda tak. Testuje build z pull requesta uruchomiony na runnerze, więc wynik dotyczy właśnie tej zmiany:

.github/workflows/perf.yml

name: perf
on: pull_request
permissions:
  contents: read
jobs:
  smoke:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - uses: grafana/setup-k6-action@v1
      - run: docker compose up -d --wait
      - run: k6 run tests/perf/smoke.js
        env:
          BASE_URL: http://localhost:3000
      - run: node scripts/perf-compare.mjs perf/baseline.json summary.json

Powyższy workflow pokazuje jeden przebieg; prompt prosi o medianę z trzech, która tłumi szum runnera. Agent pisze bramkę, ale w samej bramce nie ma agenta. Dlatego werdykt jest powtarzalny: ten sam commit daje ten sam wynik i nikt nie musi czytać skryptu, żeby ufać czerwonemu lub zielonemu statusowi.

Dwie zasady odpowiedzialności sprawiają, że bramce można ufać:

• Objęcie perf/baseline.json i bloków thresholds regułą CODEOWNERS dla lidera technicznego. Agent poproszony o „zazielenienie CI” może poluzować próg albo odświeżyć linię bazową; wymagana recenzja zamienia to w widoczną decyzję. Tak samo obejmij scripts/perf-compare.mjs i .github/workflows/perf.yml i włącz „Require review from Code Owners”: przy pull_request zadanie uruchamia kopie obu plików z pull requesta, więc niezrecenzowana zmiana mogłaby sprawić, że porównanie zawsze kończy się kodem 0. Szerzej opisuje ten wzorzec strona ochrona wyroczni.
• Podział przebiegów według kosztu. Trzydziestosekundowy test dymny działa na każdym pull requeście. Pełny test obciążenia na stagingu działa co noc na main z zaplanowanego workflow, z tokenem stagingu o minimalnych uprawnieniach z magazynu sekretów. Test stresu działa raz w tygodniu i przed premierami. Wpięcie tego w pipeline opisuje strona pipeline’y CI/CD.

Kiedy liczby z testów obciążenia wprowadzają w błąd

Test wysyła mniej ruchu, gdy serwer zwalnia

Przy rampie VU i sekundzie przerwy między iteracjami 200 VU daje około 200 żądań na sekundę tylko wtedy, gdy odpowiedzi są szybkie. Gdy rosną opóźnienia, każdy VU czeka dłużej i przepustowość spada. Jak naprawić: czytaj osiągnięte natężenie w podsumowaniu i przejdź na constant-arrival-rate lub ramping-arrival-rate, gdy potrzebujesz stałego natężenia żądań.

Generator obciążenia nasyca się przed usługą

Jednej maszynie z k6 może zabraknąć CPU albo VU długo przed usługą, a ty „odkrywasz” wąskie gardło we własnym stanowisku testowym. Jak naprawić: sprawdź dropped_iterations i CPU generatora. Jeśli któraś wartość jest wysoka, podnieś maxVUs, użyj większego runnera albo rozłóż obciążenie na kilka maszyn.

p95 wygląda dobrze, a użytkownicy z p99 dostają timeouty

p95 równe 0,8 s przy p99 równym 12 s oznacza, że jedno żądanie na 100 zawodzi użytkownika, często to, które trzyma blokadę albo czeka na połączenie z puli. Jak naprawić: ustaw próg p99 na każdym krytycznym endpoincie i czytaj go w każdym raporcie.

Staging ma niewłaściwy wolumen danych

Zapytanie, które odpowiada natychmiast na 10 000 wierszy z seeda, na 10 milionach wierszy produkcyjnych może przejść na pełny skan sekwencyjny. Jak naprawić: testuj obciążenie na zanonimizowanym zbiorze o rozmiarze produkcyjnym i przed przyjęciem wyniku zrób benchmark podejrzanych zapytań przy produkcyjnej liczbie wierszy.

Bramka pull requesta przetestowała niewłaściwy build

Job PR, który kieruje k6 na wspólny staging, mierzy to, co jest tam wdrożone, a nie pull request. Jak naprawić: uruchamiaj build z PR na runnerze, tak jak workflow powyżej, a przebiegi na stagingu zostaw nocnemu jobowi na main.

Agent naprawił test zamiast usługi

Poproszony o naprawę nieudanego przebiegu agent może poluzować próg, skrócić etap utrzymania albo usunąć wolny endpoint ze skryptu. Jak naprawić: przeglądaj diff tests/perf/ w każdym pull requeście, który go dotyka, wymagaj zatwierdzenia CODEOWNERS dla progów i linii bazowej i wpisuj „do not change any threshold” w każdy prompt.

Wygenerowany wzorzec ruchu nie jest twoim ruchem

Model poproszony o „test obciążenia” wymyśla wiarygodną mieszankę żądań. Jak naprawić: podaj mu rzeczywisty kształt ruchu z analityki, na przykład „60% żądań to GET /api/products, szczyt przypada na 14:00 CET, sesja wykonuje 12 wywołań API w ciągu ośmiu minut”.

Identyczne przebiegi dają różne liczby

Współdzielone runnery CI są zaszumione. Jak naprawić: uruchamiaj test dymny trzy razy, oceniaj medianę i zachowaj pasmo 20%. Jeśli bramka nadal skacze, poszerz pasmo dla tego endpointu, zapisz uzasadnienie w pull requeście i uruchom test ponownie zamiast mergować na czerwonym statusie.

Gdy wynik wygląda na niemożliwy, przekaż agentowi pełne podsumowanie k6 i metryki zasobów generatora i poproś, żeby rozstrzygnął, czy to prawdziwe wąskie gardło serwera, czy artefakt testu, zanim eskalujesz problem.

Dokąd dalej z testowaniem wydajności

Testowanie z AI: przegląd Gdzie testy wydajności stoją wśród innych bramek weryfikacji.

Automatyzacja testów API Funkcjonalne testy API do uruchomienia przed testem obciążenia.

Ochrona wyroczni Nie pozwól agentom edytować kontroli, które oceniają ich pracę.

Pipeline'y CI/CD Wepnij bramki wydajności w pipeline dostarczania.

Monitoring i obserwowalność Porównaj przewidywania z testów obciążenia z produkcją.

Wstrzykiwanie błędów i awarii Testuj, jak usługa zawodzi, a nie tylko jak szybko działa.