Nếu nhóm của bạn bắt đầu với Keploy, có lẽ bạn yêu thích một điều về nó: bạn chạy ứng dụng của mình, truy cập một vài endpoint, và các bài kiểm tra đã xuất hiện. Không cần viết các khẳng định, không cần tự tay tạo các phụ thuộc giả. Keploy thu thập lưu lượng truy cập thực ở lớp mạng và phát lại chúng cho bạn.
Vậy tại sao bất cứ ai lại muốn chuyển khỏi Keploy? Thông thường, điều đó xuất phát từ một nhu cầu khác. Các bài kiểm tra được ghi lại rất tuyệt vời để phát hiện các lỗi hồi quy trong những gì đã xảy ra, nhưng chúng khó đọc, khó xem xét và khó quản lý trong toàn bộ nhóm. Đến một lúc nào đó, bạn muốn có những bài kiểm tra mà một kỹ sư mới có thể mở trong một yêu cầu kéo (pull request), hiểu ngay lập tức và thay đổi có chủ đích. Bạn muốn dữ liệu kiểm thử mà bạn kiểm soát, các môi trường bạn chuyển đổi bằng một cờ (flag), và các máy chủ giả (mock server) mà bạn thiết kế thay vì những cái được tạo ra từ một bản ghi.
Hai mô hình khác biệt, được so sánh một cách trung thực
Keploy và Apidog có điểm chung ở từ "kiểm thử API", nhưng chúng thuộc các loại công cụ khác nhau. Giả vờ rằng chúng giống nhau sẽ là một điều không tốt cho bạn.
Keploy là một nền tảng mã nguồn mở để tạo các môi trường kiểm thử biệt lập (isolated test sandboxes). Điểm đặc trưng của nó là ghi lại và phát lại (record and replay): sử dụng eBPF ở lớp mạng, nó thu thập các cuộc gọi API thực và các phụ thuộc của chúng (truy vấn cơ sở dữ liệu, dịch vụ hạ nguồn, sự kiện streaming) mà không cần SDK hay thay đổi mã. Từ lưu lượng truy cập được thu thập đó, nó tự động tạo các trường hợp kiểm thử (test cases) và các mock cho những phụ thuộc đó. Nó cũng có một đường dẫn tạo kiểm thử bằng AI để xây dựng các bộ kiểm thử từ thông số kỹ thuật OpenAPI, bộ sưu tập Postman, lệnh cURL hoặc một endpoint trực tiếp. Vì việc thu thập diễn ra ở lớp eBPF, nó không phụ thuộc vào ngôn ngữ và dựa vào Linux cùng với các đặc quyền nâng cao. Bạn có thể đọc mã nguồn trên GitHub.
Apidog là một nền tảng API tất cả trong một: thiết kế, gỡ lỗi, tạo mock, tài liệu hóa và kiểm thử tại một nơi. CLI của Apidog (apidog run) thực thi các kịch bản kiểm thử và bộ sưu tập mà bạn đã tạo, từ terminal của bạn và trong CI/CD. Nó hỗ trợ kiểm thử dựa trên dữ liệu, chuyển đổi môi trường, nhiều định dạng báo cáo và báo cáo đám mây. Apidog cũng có tính năng tạo trường hợp kiểm thử bằng AI, nhưng nó hoạt động từ sơ đồ API và các endpoint của bạn bên trong ứng dụng, chứ không phải bằng cách ghi lại lưu lượng truy cập sản xuất.
Đây là điều trung thực bạn cần biết trước khi lên kế hoạch bất cứ điều gì: Apidog không thu thập lưu lượng truy cập trực tiếp qua eBPF, và nó không tự động tạo các bài kiểm thử bằng cách ghi lại các cuộc gọi sản xuất cùng với các mock phụ thuộc. Đó là điểm mạnh đặc biệt của Keploy. Nếu việc thu thập khi chạy (runtime capture) là cốt lõi của quy trình làm việc của bạn, hãy giữ Keploy cho công việc đó. Những gì bạn đạt được khi chuyển sang Apidog là các bài kiểm thử được thiết kế, dễ xem xét, có thể dùng chung trong nhóm và một nền tảng bao quát toàn bộ vòng đời API.
| Cách tiếp cận của Keploy | Cách tiếp cận của Apidog |
|---|---|
keploy record thu thập lưu lượng truy cập thực qua eBPF |
Nhập bề mặt API của bạn dưới dạng OpenAPI, Postman hoặc cURL |
| Các bài kiểm thử tự động tạo từ các cuộc gọi đã thu thập | Tạo trường hợp kiểm thử bằng AI từ spec, cộng với các kịch bản bạn tự viết |
keploy test --delay 10 phát lại các bản ghi |
apidog run thực thi các kịch bản đã viết trong CI |
| Các mock phụ thuộc được thu thập từ lưu lượng truy cập DB/mạng thực | Các máy chủ mock mà bạn thiết kế và kiểm soát |
| Dữ liệu kiểm thử được tích hợp vào bản ghi | Kiểm thử dựa trên dữ liệu qua -d (CSV/JSON) mà bạn duy trì |
| Môi trường ngầm định từ lần chạy đã ghi | Các môi trường rõ ràng được chuyển đổi bằng -e |
| Linux/eBPF, đặc quyền nâng cao | Chạy ở bất cứ đâu CLI chạy, bao gồm các trình chạy CI tiêu chuẩn |
Hãy đọc bảng đó như một hướng dẫn dịch thuật, chứ không phải một bảng điểm tính năng. Mỗi khả năng của Keploy ánh xạ tới một bước tạo tác có chủ đích trong Apidog. Bạn đang đổi "công cụ tự tìm ra từ lưu lượng truy cập" lấy "bạn mô tả điều gì là đúng đắn".
Bước 1: Thu thập bề mặt API của bạn dưới dạng một spec
Keploy bắt đầu từ một ứng dụng đang chạy. Apidog bắt đầu từ một mô tả API của bạn. Vì vậy, nhiệm vụ đầu tiên là có được mô tả đó.
Nếu bạn đã phát hành tài liệu OpenAPI, bạn đã hoàn thành. Chỉ vào đó và tiếp tục. Nếu bạn chưa có, bạn có một vài lựa chọn, tất cả đều tạo ra thứ có thể nhập được:
- Tạo OpenAPI từ framework của bạn (hầu hết các framework hiện đại đều có trình xuất hoặc thư viện phát ra nó).
- Xuất một bộ sưu tập Postman nếu nhóm của bạn đã có sẵn.
- Thu thập các lệnh cURL bạn sử dụng để truy cập từng endpoint.
Một tác dụng phụ tuyệt vời: nếu bạn có các bản ghi Keploy, các yêu cầu được thu thập là một danh sách thực tế về các endpoint nào thực sự được gọi và với các payload nào. Sử dụng chúng như một danh sách kiểm tra để spec của bạn bao phủ cùng một phạm vi, mặc dù bạn sẽ không nhập chính các bản ghi đó.
Bước 2: Nhập vào Apidog
Tải Apidog, tạo một dự án và nhập tệp OpenAPI, bộ sưu tập Postman hoặc các lệnh cURL của bạn. Apidog đọc spec và điền vào các endpoint, sơ đồ yêu cầu, tham số và mô hình phản hồi. Giờ đây bạn có một định nghĩa có cấu trúc cho mỗi endpoint, cùng một bề mặt mà Keploy đang truy cập, nhưng dưới một dạng mà bạn có thể chỉnh sửa, tạo phiên bản và chia sẻ.
Đây cũng là lúc sự khác biệt giữa các nền tảng xuất hiện. Các endpoint được nhập đó không chỉ là các đối tượng kiểm thử. Chúng là tài liệu trực tiếp, các yêu cầu có thể gỡ lỗi và là cơ sở cho các máy chủ mock, tất cả chỉ từ một lần nhập. Để xem hướng dẫn từng bước về chuỗi công cụ, hướng dẫn đầy đủ về Apidog CLI bao gồm toàn bộ quá trình thiết lập.
Bước 3: Tạo một bộ kiểm thử khởi đầu, sau đó viết các kịch bản thực tế
Đây là nơi bạn có thể lấy lại một phần tốc độ mà bạn yêu thích ở Keploy. Tính năng tạo trường hợp kiểm thử bằng AI của Apidog đọc sơ đồ và các endpoint đã nhập của bạn, sau đó phác thảo các trường hợp kiểm thử cho bạn: các yêu cầu hợp lệ, giá trị biên và các phản hồi lỗi phổ biến dựa trên spec. Đó là một điểm khởi đầu mạnh mẽ và giúp bạn bắt đầu nhanh chóng. Nếu bạn muốn xem điều này so sánh như thế nào giữa các công cụ, bài tổng hợp về các công cụ tạo trường hợp kiểm thử AI tốt nhất sẽ đặt nó vào ngữ cảnh.
Hai lưu ý trung thực. Thứ nhất, các trường hợp do AI phác thảo (trong Apidog hoặc Keploy) cần một người kiểm tra lại. Coi kết quả đầu ra như một bản nháp, loại bỏ những gì không phù hợp và thắt chặt các khẳng định. Thứ hai, đây là việc tạo từ một spec, không phải từ hành vi thời gian chạy, vì vậy nó sẽ không biết về một sự cố đặc biệt chỉ xuất hiện dưới dữ liệu sản xuất thực tế. Đó chính xác là khoảng trống mà việc thu thập của Keploy đã lấp đầy, và đó là khoảng trống bạn chấp nhận khi chuyển sang các bài kiểm thử được thiết kế.
Sau đó, bạn viết các kịch bản quan trọng. Một kịch bản liên kết các yêu cầu thành một luồng thực tế: tạo người dùng, đăng nhập bằng token được trả về, lấy hồ sơ, cập nhật nó, xóa nó. Bạn khẳng định các mã trạng thái, các trường phản hồi và cách dữ liệu chuyển từ bước này sang bước tiếp theo. Đây là công việc mà Keploy đã thực hiện một cách ngầm định bên trong một bản ghi. Thực hiện nó một cách rõ ràng tốn nhiều công sức hơn ban đầu, và nó sẽ mang lại lợi ích mỗi khi ai đó đọc, xem xét hoặc thay đổi bài kiểm thử sau này. Hướng dẫn về cách viết trường hợp kiểm thử với sự hỗ trợ của AI giúp bạn cân bằng giữa việc tạo tự động và viết tay.
Bước 4: Thiết lập môi trường và đầu vào dựa trên dữ liệu
Một bản ghi mang theo một bộ giá trị từ một lần chạy. Các bài kiểm thử đã viết nên chạy trên bất kỳ môi trường nào với bất kỳ tập dữ liệu nào.
Xác định các môi trường trong Apidog (local, staging, production) với các URL cơ sở, token và biến riêng của chúng. Khi chạy, bạn chọn một môi trường bằng -e. Đối với dữ liệu kiểm thử, hãy đính kèm tệp CSV hoặc JSON và Apidog sẽ chạy mỗi kịch bản một lần cho mỗi hàng, vì vậy một kịch bản đăng nhập bao gồm hàng chục tổ hợp thông tin đăng nhập. Bạn trỏ đến tệp bằng -d. Hướng dẫn kiểm thử dựa trên dữ liệu trình bày chi tiết các định dạng tệp và ràng buộc biến.
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-d ./test-data/login-cases.csv
Đây là một nâng cấp cụ thể so với một bản ghi cố định. Dữ liệu kiểm thử của bạn là một tệp bạn sở hữu, xem xét trong các yêu cầu kéo và mở rộng khi các trường hợp ngoại lệ mới xuất hiện.
Bước 5: Chạy trong CI với apidog run
Lệnh thay thế keploy test trong pipeline của bạn là apidog run. Nó thực thi các kịch bản bạn đã viết, áp dụng môi trường và tệp dữ liệu đã chọn, và xuất báo cáo. Bạn có thể tạo đầu ra CLI, HTML và JSON, và đẩy kết quả lên đám mây bằng --upload-report để có một liên kết có thể chia sẻ.
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-r html,cli \
--upload-report
Việc kết nối điều này vào pipeline của bạn có hình dạng giống như bất kỳ bước kiểm thử CI nào: cài đặt CLI, truyền token và ID kịch bản của bạn, làm cho bản dựng thất bại nếu có mã thoát khác không. Hướng dẫn pipeline CI/CD và hướng dẫn GitHub Actions trình bày chi tiết YAML chính xác, và hướng dẫn báo cáo kiểm thử giải thích cách đọc đầu ra mà nhóm của bạn thực sự sẽ xem.
Bước 6: Xây dựng các máy chủ mock mà bạn kiểm soát
Keploy cung cấp cho bạn các mock miễn phí bằng cách thu thập lưu lượng truy cập phụ thuộc trong quá trình ghi. Apidog đi theo hướng khác: bạn thiết kế mock. Vì bạn đã nhập sơ đồ của mình, Apidog có thể tạo một máy chủ mock từ đó, trả về các phản hồi ví dụ thực tế dựa trên các loại trường và quy tắc bạn đặt. Bạn quyết định độ trễ, các trường hợp lỗi và các payload chính xác.
Sự đánh đổi tương tự như mọi nơi khác trong hướng dẫn này. Các mock được thu thập phản ánh những gì các phụ thuộc của bạn thực sự đã làm; các mock được thiết kế phản ánh những gì bạn quyết định chúng nên làm. Đối với kiểm thử hợp đồng (contract testing) và CI ổn định, các mock được thiết kế có xu hướng thắng thế vì chúng không thay đổi theo sản xuất. Nếu bạn muốn tìm hiểu sâu hơn, hãy xem các công cụ kiểm thử hợp đồng và tạo mock và tạo dữ liệu mock từ sơ đồ OpenAPI.
Những gì bạn giữ lại và những gì bạn từ bỏ
Hãy trung thực với nhóm của bạn về cả hai mặt của sự thay đổi này.
Bạn từ bỏ tính năng thu thập tự động. Không có keploy record theo dõi lưu lượng truy cập thực, không có mock phụ thuộc được tạo ra từ các lần chạy sản xuất, không có phép thuật eBPF không cần mã. Nếu khả năng đó là cốt lõi đối với bạn, hãy giữ Keploy trong bộ công cụ cho công việc đó. Hai công cụ có thể cùng tồn tại.
Bạn có được các bài kiểm thử giống như tài liệu, các môi trường bạn chuyển đổi bằng một cờ (flag), dữ liệu kiểm thử bạn sở hữu và xem xét, các máy chủ mock bạn thiết kế, và một nền tảng duy nhất để thiết kế, gỡ lỗi, tài liệu hóa và kiểm thử. Chi phí là có thật (viết kịch bản tốn nhiều công sức hơn ghi lại), và lợi ích là khả năng duy trì mà toàn bộ nhóm của bạn có thể thực hiện. Cuộc khảo sát rộng hơn về các công cụ tự động hóa kiểm thử API đặt những sự đánh đổi này vào ngữ cảnh, và cách kiểm thử API bằng Apidog là một bài đọc thực hành tốt tiếp theo.
Nếu bạn đang cân nhắc hai công cụ này cạnh nhau, so sánh Apidog và Keploy sẽ phân tích từng tính năng, và nếu Keploy không phù hợp với nhóm của bạn, bài tổng hợp về các lựa chọn thay thế Keploy tốt nhất rất đáng xem xét.
Câu hỏi thường gặp
Apidog có thể nhập các bản ghi Keploy hiện có của tôi không? Không trực tiếp. Các bản ghi Keploy là các bản thu khi chạy, và Apidog hoạt động từ các spec API. Con đường thực tế là thu thập bề mặt API của bạn dưới dạng OpenAPI (hoặc Postman/cURL) và nhập nó. Sử dụng các bản ghi Keploy của bạn làm danh sách kiểm tra các endpoint cần bao gồm.
Apidog có ghi lại lưu lượng truy cập trực tiếp và tự động tạo mock cơ sở dữ liệu của tôi như Keploy không? Không. Apidog không thu thập lưu lượng truy cập qua eBPF và không tự động tạo các mock phụ thuộc từ các lần chạy thực tế. Đó là điểm mạnh đặc biệt của Keploy. Apidog tạo các bài kiểm thử và mock từ sơ đồ của bạn, và bạn viết các kịch bản dựa trên đó.
Điều gì thay thế keploy record và keploy test? Không có cái tương đương với record. Thay vào đó, bạn nhập một spec, tạo một bộ khởi đầu bằng AI, viết các kịch bản và chạy chúng bằng apidog run thay cho keploy test.
Có đáng để bỏ thêm công sức viết kịch bản để di chuyển từ Keploy không? Nếu bạn muốn các bài kiểm thử dễ đọc, dễ xem xét trong các yêu cầu kéo, và được quản lý chung trong một nhóm, thì có. Nếu nhu cầu cốt lõi của bạn là thu thập hành vi thời gian chạy thực tế không cần công sức bao gồm các mock phụ thuộc, Keploy vẫn làm tốt hơn, vì vậy hãy giữ nó cho công việc đó.
Tôi có thể chạy cả hai công cụ cùng lúc không? Có. Nhiều nhóm sử dụng Keploy để kiểm tra hồi quy dựa trên việc thu thập và Apidog cho các bộ kiểm thử end-to-end được thiết kế, tài liệu và mock. Chúng giải quyết các vấn đề khác nhau.
Bắt đầu từ đâu
Chọn một dịch vụ. Xuất spec OpenAPI của nó, nhập vào Apidog, để AI phác thảo một vài trường hợp kiểm thử, sau đó viết một kịch bản thực tế với một môi trường và một tệp dữ liệu nhỏ. Chạy nó bằng apidog run và kết nối nó vào CI. Một khi vòng lặp đó cảm thấy tốt, hãy mở rộng ra. Bạn sẽ đánh đổi sự tiện lợi của việc ghi lại lấy các bài kiểm thử mà toàn bộ nhóm của bạn có thể đọc, thay đổi và tin cậy. Để tìm hiểu sâu hơn về CLI, hãy bắt đầu với hướng dẫn cài đặt và hướng dẫn kiểm thử REST API bằng dòng lệnh.