Lợi nhuận:
- Khả năng tiến hành kiểm tra API chuyên sâu với sự hỗ trợ trí tuệ nhân tạo ở mã trạng thái, lược đồ/hợp đồng, quy tắc kinh doanh và các lớp phủ định/ủy quyền
- Khả năng tạo lược đồ JSON từ phản hồi mẫu và tránh sự tự tin giả tạo khi chỉ nhìn vào mã trạng thái với xác thực loại và bắt buộc
- Khả năng kiểm tra các tình huống bảo mật như ủy quyền và IDOR bằng dữ liệu tổng hợp và chỉ nhằm mục đích phòng thủ trong phạm vi ủy quyền
Hầu hết các phần mềm hiện đại đều giao tiếp với nhau trong nền thông qua API (Giao diện lập trình ứng dụng - giao diện nơi hai phần mềm giao tiếp theo một hợp đồng cụ thể). Khi một ứng dụng di động thêm mặt hàng vào giỏ hàng, nó thực sự sẽ gửi yêu cầu tới API trên máy chủ. Kiểm tra API kiểm tra xem cuộc trò chuyện này có chính xác, an toàn và nhất quán hay không, bất kể giao diện; Nó nhanh hơn, ổn định hơn và sâu hơn so với kiểm tra giao diện người dùng. Trí tuệ nhân tạo (AI) rất hiệu quả trong thử nghiệm API: nó tạo ra các thử nghiệm từ định nghĩa API, trích xuất lược đồ phản hồi (hợp đồng xác định cấu trúc của dữ liệu), liệt kê các trường hợp biên. Nhưng một lần nữa, cảnh báo trọng tâm lại được áp dụng: AI không biết các quy tắc kinh doanh thực sự của API của bạn; có xu hướng tạo ra các thử nghiệm hời hợt chỉ xác nhận "200 đã được trả lại". Công việc của bạn là đảm bảo quá trình kiểm tra xác minh hợp đồng thực tế và logic nghiệp vụ.
Trong phần này, bạn sẽ tìm hiểu cách thiết lập các thử nghiệm API chuyên sâu, được AI hỗ trợ bằng các phương pháp tiếp cận như Postman, REST Assured và xác thực lược đồ.
Các lớp thử nghiệm API
Xem xét thử nghiệm API ở nhiều độ sâu khác nhau, với AI trợ giúp khác nhau ở mỗi lớp:
1. Mã trạng thái và phản hồi cơ bản. Yêu cầu có trả về mã trạng thái HTTP dự kiến không (200/201 nếu thành công, 400/401/404 nếu có lỗi)? Đây là lớp bề mặt nhất; AI sản xuất dễ dàng nhưng một mình lại tạo ra sự tin tưởng sai lầm.
2. Xác nhận lược đồ/hợp đồng. Cấu trúc của phản hồi có phù hợp với hợp đồng không - các trường dự kiến có hiện diện không, loại của chúng có đúng không, các trường bắt buộc có bị thiếu không? AI có thể tạo Lược đồ JSON — tiêu chuẩn xác định cấu trúc của tài liệu JSON — từ một phản hồi mẫu và các thử nghiệm có thể xác thực dựa trên lược đồ đó. Điều này mạnh mẽ hơn nhiều so với việc viết thủ công một xác nhận dựa trên trường.
3. Xác thực quy tắc kinh doanh. Giá trị thực ở đây: "Đối với đơn hàng 1000 TL, trường giảm giá phải là 100", "không thể hủy đơn hàng đã hủy nữa". AI sẽ chỉ xác minh những điều này nếu bạn đưa ra quy tắc cho nó; Nếu bạn không cho nó, nó sẽ nhảy.
4. Tiêu cực và an ninh. 401 cho mã thông báo không hợp lệ, 403 để truy cập dữ liệu của người khác, xóa 400 cho nội dung xấu. Kiểm tra ủy quyền (xác minh rằng người dùng chỉ có thể truy cập dữ liệu của riêng họ) là trọng tâm của bảo mật API và được thực hiện vì mục đích phòng thủ.
Mẹo: Đừng yêu cầu kiểm tra mà không yêu cầu AI "xác thực không chỉ mã trạng thái mà còn cả lược đồ phản hồi và các quy tắc kinh doanh đó". Nếu không, bạn sẽ chỉ còn lại các bài kiểm tra có nội dung "200 được trả về, đã đạt" nhưng không nhận thấy API trả về dữ liệu bị hỏng.
Dấu nhắc yếu / Dấu nhắc mạnh
Yếu: "Viết bài kiểm tra cho API này."
Mạnh: "Viết các bài kiểm tra REST được đảm bảo (Java) cho điểm cuối POST /đơn hàng. Thỏa thuận: ProductId và số lượng là bắt buộc trong nội dung; 201 và {orderId, Total, chiết khấu, trạng thái} được trả về khi thành công. Quy tắc kinh doanh: Giảm giá 10% trên 1000 TL; 400 nếu số lượng<=0; 401 nếu mã thông báo không hợp lệ; 403 khi thấy đơn đặt hàng của người dùng khác. Kiểm tra: (1) mã trạng thái, (2) lược đồ JSON phản hồi xác thực, (3) quy tắc kinh doanh chiết khấu, (4) ràng buộc mọi xác nhận với quy tắc kinh doanh rõ ràng; đừng chỉ kiểm tra 200/201.”
Lời nhắc mạnh mẽ cung cấp hợp đồng, quy tắc kinh doanh, tình huống bảo mật và kỳ vọng xác thực lược đồ.
Thử nghiệm hợp đồng: ngăn chặn sự chia tay giữa các đội
Trong kiến trúc vi dịch vụ (cấu trúc trong đó ứng dụng được chia thành các dịch vụ nhỏ độc lập với nhau và giao tiếp với API), việc thay đổi định dạng phản hồi của một dịch vụ sẽ âm thầm phá vỡ các dịch vụ khác được kết nối với nó. Thử nghiệm hợp đồng - thử nghiệm xác minh rằng hợp đồng API giữa dịch vụ của nhà cung cấp và dịch vụ tiêu dùng không bị phá vỡ ở cả hai bên - sẽ sớm phát hiện ra những vi phạm như vậy. Ý tưởng là thế này: người tiêu dùng xác định hình thức phản hồi mà họ mong đợi từ nhà sản xuất như một “hợp đồng”; Với mỗi thay đổi, nhà sản xuất sẽ kiểm tra xem nó có còn tuân thủ thỏa thuận này hay không. Vì vậy, khi tên hoặc loại trường thay đổi, người tiêu dùng sẽ thông báo cho quy trình trước khi nó gặp sự cố.
AI tăng tốc hai nhiệm vụ trong bối cảnh này: soạn thảo hợp đồng phản ánh kỳ vọng của người tiêu dùng từ phản hồi API hiện có và đánh dấu trước điều khoản hợp đồng nào mà một thay đổi có thể phá vỡ. Nhưng bản thân hợp đồng là một quyết định kinh doanh: chuyên gia xác định lĩnh vực nào thực sự quan trọng, những thay đổi nào sẽ phá vỡ khả năng tương thích ngược - người tiêu dùng cũ vẫn tiếp tục làm việc. AI viết hợp đồng; Bạn là người phê duyệt nó.
Mẹo: Việc xóa một trường hoặc thay đổi loại trường trong API hầu như luôn là một thay đổi có thể xảy ra. Việc thêm các trường mới thường là an toàn. Việc yêu cầu AI phân loại một thay đổi là “phá vỡ hoặc an toàn” sẽ cung cấp quy trình kiểm tra bảo mật nhanh chóng trước khi phát hành.
Người đưa thư hay dựa trên mã?
tiêu chí
Người đưa thư/Newman
REST được đảm bảo/mã (Java, C#, JS)
học tập
Dễ dàng, trực quan
Yêu cầu kiến thức về mã
Kiểm soát phiên bản
Bộ sưu tập JSON
Trực tiếp trong mã nguồn
logic phức tạp
Bị giới hạn (tập lệnh JS)
Toàn bộ sức mạnh lập trình
Tích hợp CI/CD
với Newman
Phụ thuộc trực tiếp vào việc xây dựng
Xác thực lược đồ
Với kịch bản thử nghiệm
Mạnh mẽ với thư viện
quy mô đội
nhỏ/trung bình
lớn, trưởng thành
AI tạo mã cho cả hai; Hãy rõ ràng cái nào bạn muốn.
Bốn mẫu có thể sao chép
1) Kiểm tra API dựa trên hợp đồng:
Vai trò của bạn: kỹ sư kiểm tra API cấp cao. Viết bài kiểm tra cho điểm cuối sau bằng [công cụ/ngôn ngữ]: [phương thức + đường dẫn]. Hợp đồng: [các trường bắt buộc, mã thành công, cấu trúc phản hồi]. Quy tắc kinh doanh: [quy tắc]. Lớp kiểm tra: (1) mã trạng thái (2) xác thực lược đồ phản hồi (3) mỗi quy tắc kinh doanh (4) phủ định + ủy quyền. Liên kết từng xác nhận với điều khoản quy tắc/hợp đồng liên quan.
2) Tạo lược đồ từ phản hồi mẫu:
Tạo Lược đồ JSON từ phản hồi API mẫu bên dưới. Chỉ định các trường, loại bắt buộc, ràng buộc định dạng (ngày, email, phạm vi số). Sau đó đưa ra một ví dụ kiểm tra để xác nhận lược đồ này. Câu trả lời mẫu: [dán JSON]
3) Kịch bản tiêu cực và ủy quyền:
Tạo các trường hợp kiểm thử tiêu cực và bảo mật cho điểm cuối[điểm cuối]. Bao gồm: trường bị thiếu/bắt buộc, loại sai, giá trị quá lớn, mã thông báo không hợp lệ/hết hạn, truy cập vào tài nguyên trái phép (IDOR - truy cập vào hồ sơ của người khác bằng cách thay đổi ID), giới hạn tỷ lệ. Chỉ định mã trạng thái dự kiến và nội dung lỗi cho từng trường hợp. Lưu ý: sẽ chỉ được thử nghiệm trên API của riêng tôi, được ủy quyền.
4) Kiểm soát giả tin cậy:
Hãy xem thử nghiệm API này. Kiểm tra này có phát hiện được không nếu máy chủ trả về mã trạng thái chính xác nhưng FALSEbody/data? Nếu không, hãy thêm xác thực quy tắc kinh doanh và lược đồ. Kiểm tra: [dán kiểm tra]
ba trường hợp nhỏ
Trường hợp 1 - Sức mạnh của việc xác thực lược đồ. Một nhóm chỉ kiểm tra mã trạng thái trong các thử nghiệm mà họ tạo ra bằng AI. Trong một phiên bản, API bắt đầu trả về nhầm trường tổng dưới dạng văn bản ("1200"); các bài kiểm tra vẫn xanh vì nó vẫn trả về 200. Ứng dụng di động bị lỗi. Sau khi thêm xác thực loại bằng mẫu "Tạo lược đồ từ phản hồi mẫu", lỗi tương tự ngay lập tức được phát hiện.
Trường hợp 2 - Khoảng cách quyền hạn (IDOR). Một chuyên gia đã chạy thử nghiệm IDOR giữa “kịch bản tiêu cực và ủy quyền” do AI tạo ra: Anh ta yêu cầu ID đơn đặt hàng của người dùng B bằng mã thông báo của người dùng A. API trả về dữ liệu 200 và B – một lỗ hổng ủy quyền nghiêm trọng. Thử nghiệm phòng thủ này đã đóng rò rỉ dữ liệu trước khi nó đi vào hoạt động.
Trường hợp 3 - Bỏ qua quy tắc kinh doanh. AI đã tạo ra 8 bài kiểm tra cho điểm cuối giảm giá; tất cả đều đang kiểm tra 200, không ai xác minh số tiền chiết khấu. Chuyên gia đã thêm các quy tắc kinh doanh vào lời nhắc và yêu cầu sao chép chúng. Các thử nghiệm mới cho thấy mức chiết khấu đã được tính không chính xác ở giới hạn 1000 TL (mức chiết khấu cũng được áp dụng cho 999). Kiểm soát hợp đồng là chưa đủ; Kiểm soát quy tắc kinh doanh là phải.
Những lỗi thường gặp
- Chỉ cần nhìn vào mã trạng thái. Nói “200 đã về và đã qua”; không thấy thân hư hoại (tin giả).
- Bỏ qua xác nhận lược đồ. Không kiểm tra loại trường và nghĩa vụ; thay đổi loại diễn ra âm thầm.
- Yêu cầu thử nghiệm mà không cung cấp quy tắc kinh doanh. AI không biết các quy tắc; nó chỉ tạo ra sự kiểm soát kỹ thuật.
- Quên các kịch bản tiêu cực và quyền lợi. Các lỗ hổng bảo mật (IDOR, truy cập trái phép) chỉ được phát hiện bằng các thử nghiệm này.
- Sử dụng mã thông báo và dữ liệu thực/sản xuất. Sử dụng phương tiện chuyên dụng và dữ liệu tổng hợp để thử nghiệm; Không nhét chìa khóa thật vào xe.
- Kiểm tra bảo mật trái phép. Chỉ chạy thử nghiệm ủy quyền trên API của riêng bạn và khi được phép.
Tóm lại
Kiểm thử API xác minh giọng nói của các phần mềm một cách nhanh chóng và sâu sắc, bất kể giao diện. AI; kiểm tra hợp đồng rất hiệu quả trong việc tạo lược đồ JSON và các tình huống tiêu cực/bảo mật từ phản hồi mẫu. Nhưng những thử nghiệm hời hợt chỉ kiểm tra mã trạng thái sẽ mang lại sự tự tin giả tạo. Yêu cầu tất cả bốn lớp: mã trạng thái, xác thực lược đồ, quy tắc kinh doanh, phủ định và ủy quyền. Đưa ra các quy tắc kinh doanh và hợp đồng ngay lập tức; Thực hiện kiểm tra bảo mật với dữ liệu tổng hợp và chỉ khi được ủy quyền.
Nhiệm vụ ứng dụng
Chọn điểm cuối API từ dự án của riêng bạn. Yêu cầu AI viết các bài kiểm tra bốn lớp với mẫu “thử nghiệm API dựa trên hợp đồng”. Sau đó, thêm xác thực loại/thực thi bằng "tạo lược đồ từ phản hồi mẫu" và áp dụng "kiểm tra độ tin cậy giả". Chạy ít nhất một kịch bản IDOR/ủy quyền trong môi trường thử nghiệm của riêng bạn. Báo cáo mọi vi phạm hợp đồng hoặc quy tắc kinh doanh mà bạn phát hiện; Nếu bạn không thể tìm thấy bất kỳ câu trả lời nào, hãy chạy thử nghiệm đối với một phản hồi có chủ ý bị cắt xén để chứng minh rằng nó đã đúng.
danh sách kiểm tra
- [ ] Tôi đã đề cập đến bốn lớp thử nghiệm (trường hợp, lược đồ, quy tắc kinh doanh, phủ định/ủy quyền).
- [ ] Tôi đã đưa rõ ràng hợp đồng và các quy tắc kinh doanh cho AI.
- [ ] Tôi thiết lập các thử nghiệm xác thực lược đồ phản hồi (trường, loại, mệnh lệnh).
- [ ] Tôi đã thử ít nhất một kịch bản ủy quyền/IDOR một cách phòng thủ.
- [ ] Tôi đã sử dụng môi trường thử nghiệm và dữ liệu tổng hợp thay vì mã thông báo/dữ liệu thực.
- [ ] Tôi đã chứng minh bằng "kiểm tra độ tin cậy giả" rằng mọi bài kiểm tra đều phát hiện được phản hồi sai.