Twoja aplikacja działa doskonale z dziesięcioma użytkownikami. Co się stanie w dniu sprzedaży z dziesięcioma tysiącami? Testowanie obciążenia a testowanie warunków skrajnych opisuje dwa różne sposoby odpowiedzi na to pytanie, a pomieszanie ich prowadzi do testów, które nie dowodzą tego, co myślisz.

W tym przewodniku wyjaśniono, co pokazuje każdy z nich, powiązane typy testów i sposób odczytywania wyników. We ran the small percentile calculation below on Python 3.13, with simulated numbers. The k6 scripts are illustrative examples that we did not execute, and the user counts and targets are invented, so replace them with your own. Przeprowadzaj te testy tylko na systemach, które posiadasz lub masz pozwolenie na testowanie, ponieważ duży ruch może wyglądać jak atak i powodować rzeczywiste awarie.

Krótka odpowiedź

A load test asks: can we handle the traffic we expect, and meet our targets while doing it? A stress test asks: how much can we take before we fail, how do we fail, and how quickly do we recover?

Pomyśl o moście. A load test drives the expected number of trucks across and confirms that it is fine. A stress test keeps adding weight to learn its limit, and whether it gives warning first. Fortunately, software is cheaper to break than a bridge.

Testowanie obciążenia i testowanie warunków skrajnych obok siebie

Co to jest testowanie obciążenia?

Testowanie obciążenia symuluje realistyczny oczekiwany ruch i mierzy zachowanie systemu. Wymaga celu, z którym będzie można przeprowadzić testy, na przykład: „przy 500 jednoczesnych użytkownikach 95% żądań realizacji transakcji kończy się w ciągu 800 ms, a liczba błędów wynosi poniżej 1%.

Oto jak może to wyglądać jako skrypt K6. Testy k6 są napisane w JavaScript i thresholds zamieniają Twoje cele na wynik pozytywny lub negatywny:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

sleep ma znaczenie. Bez zastanowienia każdy wirtualny użytkownik w sposób ciągły obciąża serwer, generując znacznie większy ruch niż ta sama liczba prawdziwych osób.

Co to są testy warunków skrajnych?

Testy warunków skrajnych celowo wykraczają poza oczekiwane poziomy. Nie próbujesz przejść. Chcesz uzyskać odpowiedzi na pytania takie jak:

• Na jakim poziomie wydajność zaczyna się pogarszać?
• Który komponent zawiedzie pierwszy: baza danych, serwery aplikacji czy połączenie strony trzeciej?
• Czy kończy się niepowodzeniem z wyraźnymi błędami, czy też ulega awarii i utracie danych?
• Czy samoczynnie się regeneruje, gdy ruch spada?

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

Często zapomina się o tym ostatnim etapie zdrowienia, a może on być najcenniejszy. System, który dobrze radzi sobie z awariami, ale nigdy nie odzyskuje sprawności bez ręcznego ponownego uruchomienia, nadal oznacza awarię, którą ktoś może naprawić w środku nocy. W idealnym przypadku system pod ekstremalnym obciążeniem powinien przerywać pracę w kontrolowany sposób, zwracając wyraźne 503 odpowiedzi zamiast przekraczać limit czasu.

Spike, moczenie i inne typy

Testy obciążeniowe i obciążeniowe należą do szerszej rodziny testów wydajnościowych:

Testy namaczania wychwytują problemy, których krótkie testy nigdy nie zauważą. A small memory leak can look harmless for twenty minutes, and only bring the service down after two days. Testy szczytowe są dostosowane do wydarzeń takich jak wyprzedaże błyskawiczne, podczas których ruch nie rośnie stopniowo.

Metryki, które mają znaczenie

Dlaczego średnie wprowadzają w błąd

Averages hide the slow requests that real people complain about. Aby to pokazać, wygenerowaliśmy 100 symulowanych czasów reakcji, z czego 95 było szybkich (80 do 200 ms), a 5 bardzo wolnych (2,5 do 4 sekund), a następnie obliczyliśmy typowe statystyki:

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

Przyjrzyj się uważnie tym liczbom. Średnia 302 ms nie opisuje nikogo. Typical requests took about 150 ms, while the slow ones took over 3 seconds. Even p95 looks healthy at 199 ms, and only p99 reveals the problem. A figure like p95 means 95% of requests were this fast or faster.

A jeden procent żądań nie jest rzadkością. If a page makes 50 requests, a slow p99 affects a large share of page views. Set targets on the percentiles that matter to you, and look at several together.

Narzędzia

Każdy z nich może uruchamiać zarówno testy obciążeniowe, jak i obciążeniowe. Pick the one that fits your team’s skills, rather than chasing a feature list. To use one in your pipeline, see what is CI/CD.

Jak zaplanować badanie

1. Set goals. Use real analytics to find your peak traffic, and define targets.
2. Choose journeys. Model realistic user behaviour, such as browse, search and checkout, in realistic proportions. Naciśnięcie tylko strony głównej niewiele daje.
3. Use a realistic environment. A tiny staging server cannot predict production. Zanotuj wszelkie różnice.
4. Prepare data. Use realistic volumes, because a query that is fast on 100 rows may crawl on 10 million.
5. Warn people. Tell your operations team and any third parties, and do not load test a payment provider by accident. W stosownych przypadkach próbuj usług zewnętrznych.
6. Start small. Run a small smoke test first to confirm that your script works.
7. Monitor everything. Without server metrics, you will see that it slowed down, but not why.
8. Repeat. Run it again after each fix, and keep a baseline to compare against.

Odczytanie wyników

Databases are a common bottleneck, so if queries are the issue, read our guide to SQL query optimization. That final row of the table is an important trap: always check the health of the machine generating the load as well.

Typowe błędy

• Confusing users with requests. Be clear whether a target means concurrent users or requests per second.
• Leaving out think time. This inflates traffic and gives misleading results.
• Testing too late. A week before launch leaves no time to fix architecture problems.
• Using a single endpoint. Real traffic mixes reads, writes and searches.
• Caching hides everything. Identical repeated requests may only test your cache, so vary the data.
• Testowanie jednokrotne. Wydajność zmienia się z każdą wersją, dlatego regularnie przeprowadzaj testy.

Podsumowanie

Przeprowadź testy obciążenia, aby potwierdzić, że możesz obsłużyć oczekiwany ruch, oraz testy warunków skrajnych, aby dowiedzieć się, co się dzieje, gdy nie jest to możliwe. Start small: choose your most important user journey, set one clear target, and run a short test against staging with monitoring on. That first run usually teaches you something, and you can build from there.

Najczęstsze pytania

Ucz się dalej