Kiến trúc kiểm thử theo tầng

Dùng tầng thấp nhất có thể chứng minh rủi ro một cách ổn định và nhanh chóng. Kiến trúc tốt không được xác định bằng tỷ lệ test pyramid cố định; mục tiêu là giảm feedback chậm, dễ flake nhưng vẫn giữ đủ bằng chứng end-to-end cho hành trình quan trọng.

flowchart BT
    S[Static checks] --> U[Unit tests]
    U --> C[Component tests]
    C --> K[API và contract tests]
    K --> I[Integration tests]
    I --> E[Selective E2E tests]
    E --> P[Production checks]
    X[Exploratory testing] -. tìm rủi ro chưa biết .-> C
    X -.-> K
    X -.-> E
    N[Security performance resilience accessibility] -. đi xuyên các tầng .-> S
    N -.-> P

Mục đích của từng tầng

Tầng	Dùng tốt nhất cho	Ví dụ PeopleFlow
Static	Tìm rủi ro code, dependency, secret, license và configuration mà không chạy sản phẩm	SAST, dependency và IaC scan
Unit	Chứng minh nhanh business rule xác định	Thuế, làm tròn, số ngày phép
Component	Test một service với hạ tầng thật có kiểm soát	Payroll service với Testcontainers và banking API giả lập
Contract	Bảo vệ khả năng tương thích của API và event	REST schema của payroll và Kafka event contract
API/service	Kiểm tra hành vi, authorization, lỗi, boundary, retry và idempotency	Khởi tạo payroll run và ngăn tham chiếu chéo tenant
Integration	Xác minh dependency thật và luồng dữ liệu	Payroll sang accounting; Kafka sang data mart
Selective E2E	Chứng minh một số hành trình quan trọng qua UI	Tạo nhân viên và hoàn tất lần trả lương đầu tiên
Exploratory	Khám phá rủi ro chưa biết và trải nghiệm khó hiểu	Approval flow mơ hồ hoặc câu hỏi chính sách bất thường
Production check	Phát hiện lỗi configuration và drift an toàn	Synthetic login, reconciliation, AI-quality monitoring

Thiết kế automation dễ bảo trì

flowchart LR
    A[Test specification] --> B[Domain workflow]
    B --> C[Interface adapter]
    C --> D[Ứng dụng và dependency]
    E[Test data và fixture] --> B
    F[Environment configuration] --> C
    G[Execution orchestration] --> A
    D --> H[Evidence log trace report]

Tách business intent khỏi UI selector, HTTP client, database query, Kafka adapter và AI evaluator. Cô lập test data theo tenant và run ID. Tránh fixed sleep; hãy chờ một trạng thái quan sát được. Flaky test phải có owner và hạn sửa; quarantine không được che giấu control critical.

Ví dụ API: POST /payroll-runs

• Payroll specialist có thể bắt đầu một run.
• Employee nhận 403.
• Dùng lại idempotency key không tạo thêm run.
• Retry sau timeout không tạo payment trùng.
• Tenant này không thể tham chiếu employee của tenant khác.
• Final state và audit evidence vẫn đúng sau partial failure.

Quay lại trang chính