Hầu hết các lỗi API không phải là những điều quá lạ lẫm. Chúng thường là một trường bị thiếu, một mã trạng thái sai, thời gian chờ khi tải cao, hoặc một thay đổi gây hỏng được triển khai vì không ai kiểm tra hợp đồng. Thử nghiệm ad-hoc (ngẫu hứng) đôi khi vô tình phát hiện ra một số lỗi này. Một chiến lược sẽ phát hiện chúng một cách có chủ đích.
Một chiến lược kiểm thử API là một kế hoạch xác định bạn kiểm thử cái gì, ở lớp nào và khi nào trong chu trình phân phối. Nó quyết định những kiểm tra nào chạy ở mỗi lần commit, những kiểm tra nào chạy hàng đêm và những kiểm tra nào chạy trước khi phát hành. Nó cho bạn biết nên dành công sức vào đâu để có được độ phủ cao nhất với chi phí bảo trì thấp nhất.
Chiến lược kiểm thử API thực sự có nghĩa là gì
Một chiến lược trả lời bốn câu hỏi trước khi bạn viết một dòng kiểm chứng (assertion) nào.
Bạn kiểm thử cái gì? Các endpoint và luồng mang lại giá trị kinh doanh. Một API thanh toán cần độ phủ cao hơn một endpoint kiểm tra sức khỏe hệ thống (health-check). Hãy xếp hạng theo rủi ro và lưu lượng truy cập, không phải theo mức độ dễ dàng để truy cập endpoint đó.
Ở lớp nào? Một số kiểm tra thuộc về một yêu cầu đơn lẻ. Những kiểm tra khác cần hai hoặc ba dịch vụ giao tiếp với nhau. Đặt mọi kiểm tra ở lớp cao nhất sẽ làm bộ kiểm thử của bạn chậm và dễ vỡ.
Khi nào nó chạy? Các kiểm tra nhanh chạy ở mỗi lần push. Các kiểm tra chậm chạy theo lịch trình hoặc trước khi phát hành. Việc trộn lẫn hai loại này có nghĩa là phản hồi của bạn sẽ chậm hoặc độ phủ của bạn sẽ mỏng.
Điều gì được coi là thành công? Một bài kiểm tra chỉ kiểm tra phản hồi 200 gần như không cho bạn biết điều gì. Hãy xác định mã trạng thái, lược đồ, giá trị trường và thời gian phản hồi mà bạn mong đợi.
Khi bạn có thể trả lời bốn câu hỏi này cho API của mình, bạn đã có một chiến lược. Phần còn lại của hướng dẫn này sẽ đi sâu vào chi tiết.
Tại sao một chiến lược tốt hơn kiểm thử Ad-Hoc
Kiểm thử ad-hoc có nghĩa là bạn gửi một yêu cầu, nhìn nhanh phản hồi, và tiếp tục. Nó hiệu quả cho một buổi demo. Nhưng nó sẽ sụp đổ trên một dịch vụ thực tế vì ba lý do.
Nó không lặp lại. Người tiếp theo không thể chạy lại kiểm tra thủ công của bạn, vì vậy các lỗi hồi quy sẽ lặp lại. Một bài kiểm thử tự động đã lưu sẽ chạy theo cùng một cách mọi lúc.
Nó thiên về kịch bản thành công (happy path). Khi bạn kiểm thử bằng tay, bạn kiểm thử những gì bạn mong đợi sẽ hoạt động. Bạn hiếm khi gửi một payload bị lỗi định dạng, một token hết hạn, hoặc một danh sách 10.000 mục. Đó là những trường hợp thường gây lỗi trong môi trường sản phẩm.
Nó không thể mở rộng. Một dịch vụ có 40 endpoint và 5 môi trường là 200 kiểm tra thủ công cho mỗi lần phát hành. Không ai làm điều đó bằng tay, vì vậy độ phủ giảm khi API phát triển. Một chiến lược đánh đổi chi phí thiết lập một lần để có độ phủ lặp lại: bạn viết các bài kiểm thử một lần, và chúng chạy trên mọi thay đổi mà không cần bạn can thiệp.
Kim tự tháp kiểm thử API
Kim tự tháp kiểm thử là một nguyên tắc chung về số lượng bài kiểm thử cần viết ở mỗi lớp. Rộng ở đáy, hẹp ở đỉnh.
/\
/ \ Kiểm thử end-to-end / luồng công việc (ít, chậm, giá trị cao)
/----\
/ \ Kiểm thử tích hợp / hợp đồng (một số, tốc độ trung bình)
/--------\
/ \ Kiểm thử đơn vị / yêu cầu đơn lẻ (nhiều, nhanh, rẻ)
/____________\
Lớp dưới cùng: kiểm tra yêu cầu đơn lẻ. Mỗi bài kiểm tra truy cập một endpoint và kiểm chứng phản hồi. Chúng nhanh, rẻ để viết và dễ gỡ lỗi. Khi một bài thất bại, bạn biết chính xác endpoint nào bị lỗi. Hầu hết các bài kiểm thử của bạn nằm ở đây.
Lớp giữa: kiểm tra tích hợp và hợp đồng. Chúng xác minh rằng các dịch vụ đồng ý về hình dạng dữ liệu mà chúng trao đổi, và rằng một yêu cầu chạm vào hai hoặc ba hệ thống trả về kết quả đúng. Chúng chậm hơn vì liên quan đến nhiều thành phần di chuyển hơn, nhưng chúng bắt được những lỗi mà kiểm tra yêu cầu đơn lẻ bỏ lỡ.
Lớp trên cùng: luồng công việc end-to-end. Chúng chạy một hành trình người dùng đầy đủ qua nhiều endpoint: tạo một đơn hàng, thanh toán, kiểm tra trạng thái. Chúng mang lại sự tự tin cao nhất và tốn kém nhất để duy trì, vì vậy hãy giữ chúng ít và dành cho các đường dẫn quan trọng.
Sai lầm mà các nhóm mắc phải là đảo ngược kim tự tháp: một đống kiểm thử end-to-end chậm và gần như không có kiểm thử nhanh nào. Điều đó khiến bạn có các vòng phản hồi dài và các lỗi không ổn định. Hãy đẩy độ phủ xuống kim tự tháp bất cứ khi nào một lớp thấp hơn có thể bắt được cùng một lỗi.
Các loại kiểm thử và khi nào áp dụng từng loại
Một chiến lược hoàn chỉnh sử dụng nhiều loại kiểm thử, mỗi loại nhắm vào một loại lỗi khác nhau. Dưới đây là những gì mỗi loại kiểm tra và khi nào nên sử dụng.
Kiểm thử chức năng
Kiểm thử chức năng xác minh rằng một endpoint hoạt động đúng như mô tả trong đặc tả của nó. Gửi một yêu cầu hợp lệ, kiểm chứng mã trạng thái, lược đồ phản hồi và giá trị các trường. Đây là nền tảng của bộ kiểm thử của bạn và là điều đầu tiên cần tự động hóa trên bất kỳ endpoint mới nào. Để tìm hiểu sâu hơn, hãy xem kiểm thử chức năng API.
Một kiểm tra chức năng cho một endpoint người dùng trông như thế này:
GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>
Các kiểm chứng:
- Trạng thái là
200. - Body khớp với lược đồ
User. idbằng42.emaillà một chuỗi email hợp lệ.
Kiểm thử tích hợp
Kiểm thử tích hợp kiểm tra xem các endpoint có hoạt động cùng nhau hay không và liệu API của bạn có giao tiếp chính xác với các thành phần phụ thuộc của nó hay không: cơ sở dữ liệu, nhà cung cấp thanh toán, dịch vụ hạ nguồn. Một kiểm thử chức năng có thể thành công trên một thành phần phụ thuộc giả lập (mocked dependency) nhưng vẫn thất bại khi thành phần thực sự được kết nối. Kiểm thử tích hợp thu hẹp khoảng cách đó. Phương pháp đầy đủ được trình bày trong kiểm thử tích hợp API.
Kiểm thử hồi quy
Kiểm thử hồi quy chạy lại bộ kiểm thử hiện có của bạn sau mỗi thay đổi để xác nhận rằng bạn không làm hỏng thứ gì đó từng hoạt động. Đây là lúc một bộ kiểm thử tự động, đã lưu phát huy tác dụng. Bạn không viết các kiểm thử hồi quy mới; bạn chạy các kiểm thử bạn đã có, theo lịch trình và trước khi phát hành. Xem kiểm thử hồi quy để biết cách cấu trúc điều này.
Kiểm thử hợp đồng
Kiểm thử hợp đồng xác minh rằng nhà cung cấp và người tiêu dùng của một API đồng ý về hình dạng chính xác của yêu cầu và phản hồi. Nó phát hiện các thay đổi gây lỗi (một trường đổi tên, một thay đổi kiểu, một endpoint bị loại bỏ) trước khi chúng đến tay người tiêu dùng. Nếu bạn phát hành một API mà các nhóm hoặc khách hàng khác phụ thuộc vào, kiểm thử hợp đồng không phải là tùy chọn. Chi tiết có trong kiểm thử hợp đồng API.
Kiểm thử tải và hiệu năng
Kiểm thử tải đo lường cách API của bạn hoạt động dưới lưu lượng truy cập đồng thời: thời gian phản hồi ở phân vị thứ 95, tỷ lệ lỗi, thông lượng và điểm mà nó bắt đầu suy giảm. Chạy nó trước khi ra mắt, trước một đợt tăng lưu lượng truy cập dự kiến và định kỳ để phát hiện sự suy thoái chậm. Đây là một lĩnh vực riêng biệt với kiểm thử chức năng và sử dụng các công cụ khác nhau; xem các công cụ kiểm thử tải để biết các tùy chọn.
Kiểm thử bảo mật
Kiểm thử bảo mật kiểm tra xem API của bạn có từ chối những gì nó nên từ chối hay không: các yêu cầu không có token, các yêu cầu có phạm vi sai, các nỗ lực tấn công tiêm mã (injection attempts), và truy cập dữ liệu của người dùng khác. Mỗi endpoint chạm vào dữ liệu nhạy cảm cần ít nhất các kiểm tra xác thực và ủy quyền. Bộ kỹ thuật đầy đủ có trong kiểm thử bảo mật API.
Dưới đây là một hướng dẫn sơ bộ về thời điểm mỗi loại chạy:
| Loại kiểm thử | Phát hiện | Chạy khi |
|---|---|---|
| Chức năng | Trạng thái, lược đồ, hoặc giá trị sai | Mỗi lần commit |
| Tích hợp | Luồng dịch vụ-dịch vụ bị lỗi | Mỗi lần commit hoặc hàng đêm |
| Hồi quy | Hành vi hiện có bị lỗi mới | Mỗi lần commit và trước phát hành |
| Hợp đồng | Các thay đổi gây lỗi đối với giao diện | Mỗi lần commit trên nhà cung cấp |
| Tải | Chậm và lỗi dưới lưu lượng | Trước khi ra mắt và theo lịch trình |
| Bảo mật | Xác thực, tiêm mã, lộ dữ liệu | Trước khi phát hành và theo lịch trình |
Các trường hợp tích cực, tiêu cực và biên
Đối với mỗi endpoint, hãy bao gồm ba loại đầu vào. Bỏ qua loại thứ hai và thứ ba là lỗ hổng phổ biến nhất trong một bộ kiểm thử thực tế.
Các trường hợp tích cực gửi đầu vào hợp lệ và mong đợi thành công. Một yêu cầu tạo người dùng với một body được định dạng tốt sẽ trả về 201 và bản ghi mới. Những trường hợp này xác nhận endpoint hoạt động.
Các trường hợp tiêu cực gửi đầu vào không hợp lệ và mong đợi một lỗi rõ ràng, chính xác. Một trường bắt buộc bị thiếu nên trả về 400, không phải 500. Một yêu cầu không có token nên trả về 401. Một yêu cầu cho một bản ghi mà bạn không sở hữu nên trả về 403 hoặc 404, không bao giờ là bản ghi đó. Kiểm thử tiêu cực xác minh việc xử lý lỗi của bạn, đây là nơi API thường xuyên bị lộ hoặc gặp sự cố nhất.
Các trường hợp biên đẩy giới hạn của đầu vào hợp lệ: một danh sách trống, độ dài chuỗi tối đa cho phép, một số không, một số âm, một tên Unicode, một dấu thời gian tại ranh giới đổi giờ tiết kiệm ánh sáng ban ngày. Những trường hợp này tìm thấy các lỗi sai số (off-by-one) và lỗi tràn bộ nhớ (overflow bugs).
Một quy tắc vững chắc: đối với mỗi kiểm thử tích cực, hãy viết ít nhất một kiểm thử tiêu cực. Nếu endpoint tạo đơn hàng của bạn có một kiểm thử theo kịch bản thành công và không có kiểm thử nào cho số lượng âm hoặc thiếu ID khách hàng, độ phủ của bạn mỏng hơn vẻ ngoài của nó.
POST /api/orders HTTP/1.1
Content-Type: application/json
{ "customerId": "c_123", "quantity": -5 }
Dự kiến: trạng thái 400, body chứa một lỗi xác thực rõ ràng chỉ định quantity. Nếu điều này trả về 201 hoặc 500, bạn đã tìm thấy một lỗi mà kiểm thử theo kịch bản thành công sẽ không bao giờ bắt được.
Dữ liệu kiểm thử và môi trường
Các bài kiểm thử chỉ đáng tin cậy khi dữ liệu và môi trường mà chúng chạy được.
Sử dụng dữ liệu kiểm thử chuyên dụng. Đừng kiểm thử dựa trên bản ghi sản xuất và đừng phụ thuộc vào một hàng cụ thể tồn tại. Tạo dữ liệu mà bài kiểm thử của bạn cần, hoặc gieo một dữ liệu cố định đã biết vào đầu lần chạy. Đối với các đầu vào thực tế, đa dạng, một trình tạo dữ liệu tiết kiệm hàng giờ; xem cách tạo dữ liệu kiểm thử API thực tế.
Làm cho các bài kiểm thử độc lập. Mỗi bài kiểm thử nên thiết lập trạng thái riêng của nó và dọn dẹp sau khi chạy. Một bài kiểm thử phụ thuộc vào bài kiểm thử trước đó đã chạy là một bài kiểm thử sẽ thất bại theo thứ tự ngẫu nhiên. Khi bạn cần truyền một giá trị từ yêu cầu này sang yêu cầu tiếp theo (một ID, một token), hãy thực hiện rõ ràng trong kịch bản, không phải thông qua trạng thái toàn cục dùng chung.
Cô lập môi trường. Giữ riêng các môi trường cho phát triển cục bộ, CI, staging và production. Lưu trữ URL cơ sở, token và các cài đặt khác cho mỗi môi trường để cùng một bài kiểm thử chạy ở bất kỳ đâu bằng cách hoán đổi một biến. Hiểu sự khác biệt giữa sandbox và môi trường kiểm thử đầy đủ giúp bạn chọn mục tiêu phù hợp; xem sandbox vs môi trường kiểm thử.
Tham số hóa với các biến. Không bao giờ mã hóa cứng một host hoặc một bí mật trong một bài kiểm thử. Tham chiếu một biến môi trường để cùng một kịch bản chạy trên môi trường cục bộ, staging và CI mà không cần chỉnh sửa.
Shift Left: Kiểm thử sớm hơn, không chỉ nhiều hơn
Shift left có nghĩa là di chuyển kiểm thử sớm hơn trong chu trình phân phối, gần hơn với thời điểm mã được viết. Phát hiện lỗi càng muộn, chi phí sửa càng cao. Một sự không khớp lược đồ được phát hiện ở giai đoạn thiết kế là một chỉnh sửa mất năm phút. Cùng một sự không khớp đó được phát hiện trong sản xuất là một sự cố.
Ba động thái thực tế giúp bạn chuyển kiểm thử sang trái:
Thiết kế hợp đồng trước. Xác định lược đồ yêu cầu và phản hồi của API trước khi bạn xây dựng endpoint. Giờ đây, bạn có thể tạo các bài kiểm thử và mock từ hợp đồng đó và bắt đầu kiểm thử giao diện trước khi triển khai.
Kiểm thử dựa trên một mock khi backend chưa hoàn thiện. Công việc giao diện người dùng và tích hợp không cần phải chờ endpoint thực sự. Một máy chủ mock được xây dựng từ lược đồ cho phép người tiêu dùng kiểm thử phía của họ song song.
Chạy các kiểm tra nhanh ở mỗi lần commit. Các kiểm thử chức năng và hợp đồng chạy trong vài giây thuộc về vòng lặp nội bộ của nhà phát triển, không phải một lô chạy hàng đêm. Nhà phát triển càng sớm thấy một kiểm thử thất bại, chi phí sửa càng rẻ.
Trường hợp đầy đủ cho điều này nằm trong kiểm thử shift-left trong phát triển API. Lợi ích rất đơn giản: lỗi ít tốn kém hơn khi bạn tìm thấy chúng sớm hơn.
Tự động hóa kiểm thử trong CI
Một chiến lược chỉ thực sự hiệu quả nếu nó chạy mà không cần bạn can thiệp. Mục tiêu là một pipeline chạy bộ kiểm thử của bạn ở mỗi lần push, chặn việc hợp nhất nếu thất bại và tạo ra một báo cáo mà bạn có thể đọc được.
Một pipeline CI điển hình cho kiểm thử API có ba giai đoạn:
- Ở mỗi lần push: chạy các kiểm thử chức năng và hợp đồng nhanh. Thất bại bản dựng nếu bất kỳ kiểm chứng nào thất bại. Đây là cổng của bạn.
- Hàng đêm hoặc trước khi phát hành: chạy các bộ kiểm thử tích hợp và end-to-end chậm hơn, cộng với kiểm tra tải và bảo mật.
- Luôn luôn: xuất bản một báo cáo có thể đọc được bằng máy (JUnit XML là định dạng phổ biến) để bảng điều khiển CI của bạn hiển thị số lượng thành công và thất bại.
Một công việc GitHub Actions tối thiểu chạy bộ kiểm thử API ở mỗi lần push trông như thế này:
name: api-tests
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- name: Run API tests
run: npm test
Lệnh chính xác phụ thuộc vào công cụ của bạn. Mẫu chung là giống nhau ở mọi nơi: kiểm tra mã, thiết lập môi trường chạy, chạy bộ kiểm thử, và để một mã thoát khác 0 làm thất bại bản dựng. Để biết cách xử lý CI đầy đủ, bao gồm bộ nhớ đệm, bí mật môi trường và báo cáo, hãy xem cách tự động hóa kiểm thử API trong CI/CD.
Apidog phù hợp với chiến lược như thế nào
Chiến lược trên là không phụ thuộc công cụ. Bạn có thể xây dựng nó từ các công cụ riêng biệt để thiết kế, kiểm thử, mock và tài liệu. Chi phí của điều đó là sự trôi lệch: đặc tả, các bài kiểm thử và mock không đồng bộ, và bạn phải dành thời gian để điều chỉnh chúng.
Apidog hợp nhất điều đó vào một nơi. Bạn thiết kế hợp đồng API, viết các kịch bản kiểm thử dựa trên nó, tạo mock từ cùng một lược đồ và xuất bản tài liệu, tất cả từ một nguồn đáng tin cậy duy nhất. Bởi vì các bài kiểm thử và mock đến từ cùng một hợp đồng, kiểm thử hợp đồng và kiểm thử shift-left không còn là công việc phụ trội: chúng là mặc định.
Đối với nửa CI của chiến lược, Apidog CLI chạy các kịch bản và bộ kiểm thử đã lưu của bạn mà không cần giao diện người dùng. Nó là một gói Node, vì vậy nó có thể được đưa vào bất kỳ bước CI nào có thể chạy Node.
Cài đặt nó:
npm install -g apidog-cli
Chạy một kịch bản hoặc bộ kiểm thử đã lưu trong CI. Lệnh chạy dựa trên cờ (flag-based); bạn truyền ID mục tiêu, ID môi trường và các trình báo cáo bạn muốn:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <scenarioOrSuiteId> \
-e <environmentId> \
-r cli,html,junit
--access-tokenxác thực lần chạy. Lưu token dưới dạng bí mật CI và tham chiếu nó dưới dạng biến môi trường.-tlà ID của kịch bản, thư mục hoặc bộ kiểm thử bạn muốn chạy.-elà ID môi trường, vì vậy cùng một bộ kiểm thử chạy trên staging hoặc CI bằng cách hoán đổi giá trị này.-rchọn một hoặc nhiều trình báo cáo từcli,html,jsonvàjunit. Đầu rajunitcấp dữ liệu cho bảng điều khiển CI của bạn;htmlcung cấp báo cáo dễ đọc cho con người.
Đối với một lần chạy dựa trên dữ liệu, trỏ CLI vào một tệp dữ liệu hoặc một ID dữ liệu kiểm thử đã lưu:
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <scenarioId> \
-e <environmentId> \
-d ./data/users.csv \
-r cli,junit
Thêm --upload-report để đẩy báo cáo lên đám mây, hoặc --branch để chạy trên một nhánh cụ thể. CLI chạy các kịch bản và bộ kiểm thử Apidog đã lưu. Nó không phải là một trình gửi yêu cầu tương tác và không phải là một trình tạo tải, vì vậy hãy ghép nối nó với một công cụ tải chuyên dụng cho lớp hiệu năng của kim tự tháp của bạn.
Danh sách kiểm tra chiến lược khởi đầu
Nếu bạn đang xây dựng một chiến lược từ đầu, hãy thực hiện danh sách này theo thứ tự.
- [ ] Xếp hạng các endpoint của bạn theo rủi ro và lưu lượng truy cập. Ưu tiên các endpoint hàng đầu trước.
- [ ] Viết một kiểm thử chức năng tích cực cho mỗi endpoint đã xếp hạng.
- [ ] Thêm ít nhất một kiểm thử tiêu cực cho mỗi endpoint (thiếu xác thực, đầu vào không hợp lệ).
- [ ] Thêm các kiểm thử trường hợp biên cho các endpoint chấp nhận danh sách, số hoặc văn bản tự do.
- [ ] Thêm kiểm thử hợp đồng cho bất kỳ API nào mà các nhóm hoặc khách hàng khác sử dụng.
- [ ] Thêm kiểm thử tích hợp cho các luồng giao tiếp giữa hai hoặc nhiều dịch vụ.
- [ ] Thiết lập các môi trường riêng biệt với các biến và bí mật riêng cho từng môi trường.
- [ ] Sử dụng dữ liệu kiểm thử được tạo hoặc gieo; giữ các kiểm thử độc lập.
- [ ] Chạy các kiểm thử nhanh ở mỗi lần push trong CI; làm thất bại bản dựng nếu có lỗi.
- [ ] Lên lịch cho các bộ kiểm thử chậm (tích hợp, tải, bảo mật) chạy hàng đêm hoặc trước khi phát hành.
- [ ] Xuất bản báo cáo JUnit để hiển thị số lượng thành công và thất bại.
- [ ] Xem lại bộ kiểm thử khi API thay đổi; xóa các kiểm thử cho các endpoint đã bị loại bỏ.
Bạn không cần tất cả những điều này ngay từ ngày đầu. Hãy bắt đầu với các kiểm thử chức năng và tiêu cực trên các endpoint có rủi ro cao nhất, đưa chúng vào chạy trong CI, và từ đó phát triển bộ kiểm thử ra ngoài.
Câu hỏi thường gặp
Sự khác biệt giữa chiến lược kiểm thử API và kế hoạch kiểm thử là gì?
Một chiến lược là cách tiếp cận cấp cao: bạn sử dụng loại kiểm thử nào, ở lớp nào và khi nào chúng chạy. Một kế hoạch kiểm thử là tài liệu cụ thể cho một bản phát hành hoặc tính năng cụ thể: các endpoint, trường hợp, dữ liệu và tiêu chí thành công chính xác. Chiến lược ổn định; kế hoạch thay đổi theo từng bản phát hành.
Nên có bao nhiêu bài kiểm thử ở mỗi lớp của kim tự tháp?
Không có tỷ lệ cố định, nhưng hình dạng quan trọng hơn con số. Hầu hết các bài kiểm thử nên là các kiểm tra yêu cầu đơn lẻ nhanh ở lớp dưới cùng, ít kiểm thử tích hợp và hợp đồng hơn ở giữa, và chỉ một vài kiểm thử luồng công việc end-to-end ở trên cùng. Nếu các kiểm thử lớp trên cùng chậm của bạn nhiều hơn các kiểm thử lớp dưới cùng nhanh, hãy cân bằng lại.
Tôi có cần kiểm thử hợp đồng nếu tôi đã có kiểm thử chức năng không?
Có, nếu các nhóm hoặc khách hàng khác sử dụng API của bạn. Kiểm thử chức năng kiểm tra xem một endpoint có hoạt động đúng cách hay không. Kiểm thử hợp đồng kiểm tra xem giao diện của nó có thay đổi theo cách làm hỏng người tiêu dùng hay không. Một thay đổi có thể giữ cho một endpoint hoạt động nhưng vẫn làm hỏng tất cả những người gọi nó.
Tôi nên chạy kiểm thử tải bao lâu một lần?
Chạy chúng trước bất kỳ lần ra mắt hoặc đợt tăng lưu lượng truy cập dự kiến nào, và theo lịch trình (hàng tuần hoặc hàng tháng) để phát hiện sự suy thoái hiệu suất. Kiểm thử tải chậm và tốn tài nguyên, vì vậy chúng không thuộc về mỗi lần commit. Giữ các lớp nhanh trong CI và chạy tải riêng biệt.
Tôi có thể tự động hóa toàn bộ chiến lược trong CI không?
Các phần lặp lại được, có. Các kiểm thử chức năng, tích hợp, hợp đồng và hồi quy chạy sạch sẽ trong một pipeline và kiểm soát các lần hợp nhất của bạn. Kiểm thử tải và bảo mật thường chạy theo lịch trình riêng vì chúng chậm hơn hoặc cần hạ tầng chuyên dụng. Một trình chạy kiểm thử không giao diện người dùng như Apidog CLI bao gồm nửa CI bằng cách thực thi các kịch bản đã lưu của bạn ở mỗi lần push.