Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Feature]: API request performance metrics and percentile assertions in Playwright Test

Đang mở
  • Có gì không ổn?
#43,709 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
playwright, typescript
Lĩnh vực
performance, testing

Hướng nghiên cứu

Start by reading the @playwright/test request fixture and APIRequestContext implementation, then trace how workers aggregate results and how terminal and HTML reporters report outcomes. The issue proposes request timing, cross-worker percentile aggregation, failure rates, per-operation thresholds, and CI failure behavior, but does not identify files or settle API details; done means measured values and threshold outcomes appear in reports and failing thresholds produce a non-zero exit code.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

🚀 Feature Request

I use @playwright/test for API testing through its request fixture / APIRequestContext. The existing fixtures, authentication, assertions and reporting work well, and I would like to reuse these tests to detect API performance regressions.

Specifically, I would like opt in request performance metrics and aggregate assertions similar to the following k6 capabilities:

  • Latency distributions: minimum, maximum, mean, median, p90, p95 and p99 across repeated requests
  • Request counts and throughput: total requests and achieved requests per second.
  • Failure rates: failed requests as a proportion of total requests, including HTTP failures, network errors and timeouts.
  • Aggregate thresholds: conditions such as p(95)<300, p(99)<750 and rate<0.01, evaluated after collecting samples.
  • Per-operation metrics: stable names for requests so /products/123 and /products/456 can be aggregated as the same operation, with separate thresholds for different endpoints.
  • Reporting and CI integration: measured values, sample counts and threshold outcomes in terminal/HTML reports, with a non-zero exit code when a threshold fails.

For example, k6 allows:

thresholds: {
  http_req_duration: ['p(95)<300', 'p(99)<750'],
  http_req_failed: ['rate<0.01'],
}
Example

The following is illustrative proposed syntax, rather than a requirement for the exact API

export default defineConfig({
	// ...rest of the config,

	// e.g. a proposed configuration
	  performance: {
	    thresholds: {
	      'list-products': {
	        duration: ['p(95)<300', 'p(99)<750'],
	        failureRate: ['rate<0.01'],
	      },
	    },
	  },
});

import { test, expect } from '@playwright/test';

test('list products', async ({ request }) => {
  const response = await request.get('/products', {
    // Proposed option: record this request under a stable operation name.
    performance: { name: 'list-products' },
  });

  expect(response.ok()).toBeTruthy();

  const body = await response.json();
  expect(Array.isArray(body.products)).toBeTruthy();
});

After all repetitions complete, Playwright would aggregate the request samples across workers within the project and evaluate the thresholds.

For example, a run could pass every functional assertion but fail its performance criteria because the measured p95 was 340 ms against a 300 ms threshold. The report would show both outcomes.

Measurement behaviour
  • Measure individual API requests, excluding test setup and assertions.
  • Combine measurements across workers and repetitions before calculating percentiles.
  • Include failed requests and timeouts in the failure rate.
  • Show the number of requests measured alongside the results.
  • Evaluate performance thresholds at the end of the run and fail the run if they are exceeded.

The exact timing boundaries and handling of retries could follow documented defaults.

Motivation

Currently, achieving this requires custom timing, sample collection, aggregation, percentile calculations, threshold evaluation and reporter integration, or maintaining a separate suite in another tool.

workers and repeatEach help execute repeated requests, but do not provide these statistical helpers or aggregate performance assertions.

An initial implementation could focus on API performance regression testing using existing execution controls. More advanced load-generation features, such as virtual users, ramp-up stages and target arrival rates, could be considered separately.

Ngôn ngữ chính
TypeScript
Star
98.5k
Fork
6.7k
Merge trung bình
15 giờ 42 phút
Pull request đã merge (30 ngày)
313

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/playwright

Tất cả issue của microsoft/playwright

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.