Keploy mang đến cho bạn điều mà hầu hết các công cụ kiểm thử không thể: tạo thử nghiệm không cần nỗ lực từ lưu lượng truy cập thực tế. Bạn chỉ cần trỏ nó vào ứng dụng đang chạy của mình, nó sẽ theo dõi lớp mạng và trả về các trường hợp thử nghiệm cùng với các mock cho các phụ thuộc của bạn. Không SDK, không mã thử nghiệm. Điều đó thực sự hữu ích, và đó cũng là lý do tại sao mọi người bắt đầu tìm kiếm một giải pháp thay thế Keploy ngay khi thiết lập của họ không phù hợp với mô hình.nút
Keploy là gì
Keploy là một nền tảng mã nguồn mở (Apache-2.0) để tạo các sandbox kiểm thử biệt lập cho kiểm thử API, tích hợp và end-to-end. Nó có hai quy trình làm việc.
Đầu tiên là ghi và phát lại (record and replay). Keploy nắm bắt các tương tác API thực và các phụ thuộc của chúng (truy vấn cơ sở dữ liệu, cuộc gọi mạng, sự kiện streaming) ở lớp mạng bằng cách sử dụng eBPF. Sau đó, nó phát lại chúng một cách có tính xác định trên máy của bạn hoặc trong CI. Từ lưu lượng truy cập đã ghi lại đó, nó tự động tạo cả các trường hợp thử nghiệm và các mock/stub cho mọi phụ thuộc mà yêu cầu đã chạm tới. Vì việc ghi lại xảy ra ở lớp eBPF, nên nó không cần mã và không phụ thuộc ngôn ngữ. Bạn không thay đổi gì trong ứng dụng của mình.
Các lệnh ngắn gọn:
curl --silent -O -L https://keploy.io/install.sh && source install.sh
keploy record -c "CMD_TO_RUN_APP"
keploy test -c "CMD_TO_RUN_APP" --delay 10
Quy trình làm việc thứ hai là tạo thử nghiệm bằng AI. Keploy có thể xây dựng các bộ thử nghiệm API đã được xác thực từ thông số OpenAPI, bộ sưu tập Postman, lệnh cURL hoặc một điểm cuối trực tiếp, với việc dọn dẹp tự động và mocking các phụ thuộc.
Nó bao gồm một stack rộng: Go, Java, Node.js, Python, Rust, C#, C/C++, và TypeScript; gRPC, GraphQL, HTTP/REST, Kafka, và RabbitMQ; PostgreSQL, MySQL, MongoDB, và Redis. Toàn bộ thông tin có trong tài liệu Keploy và kho lưu trữ GitHub của Keploy.
Tại sao các nhóm tìm kiếm một giải pháp thay thế Keploy
Keploy mạnh mẽ, nhưng mô hình này có những đánh đổi.
- eBPF dựa vào Linux và các đặc quyền cao. Việc nắm bắt lớp mạng cần một nhân Linux và quyền để gắn các thăm dò. Điều đó ổn trên một trình chạy CI Linux. Nó gây ra nhiều khó khăn hơn trên một máy tính xách tay bị khóa hoặc một máy dev Windows/macOS.
- Các thử nghiệm đã ghi cần được quản lý. Các thử nghiệm được tạo từ lưu lượng truy cập thực tế mang theo bất cứ điều gì lưu lượng đó mang theo: dấu thời gian, token, ID dùng một lần, nhiễu. Bạn cần xem xét và cắt tỉa trước khi chúng trở thành một bộ ổn định.
- Đây là việc tạo thử nghiệm, không phải một nền tảng hoàn chỉnh. Keploy tạo và phát lại các thử nghiệm. Nó không phải là nơi bạn thiết kế API, viết tài liệu, chạy một máy chủ mock cho các nhóm front-end, hoặc cộng tác trên một hợp đồng API chung.
- Một số nhóm muốn các bộ đã tạo sẵn. Các thử nghiệm đã ghi mô tả những gì đã xảy ra. Chúng không mô tả những gì nên xảy ra. Nếu bạn muốn các xác nhận bạn đã viết có chủ đích, được kiểm soát phiên bản và dễ đọc sau một năm, các thử nghiệm đã ghi là một điểm khởi đầu, không phải đích đến.
Không có điều nào trong số này làm cho Keploy sai. Nó cho bạn biết phải tìm kiếm gì ở một sự thay thế. Vậy đây là những lựa chọn thay thế, với ưu và nhược điểm trung thực.
1. Apidog CLI (tốt nhất cho các bộ được tạo sẵn, có thể duy trì bên trong một nền tảng đầy đủ)
Apidog là một nền tảng API tất cả trong một bao gồm thiết kế, gỡ lỗi, mocking, tài liệu và kiểm thử. Apidog CLI (apidog run) thực thi các kịch bản kiểm thử và các bộ sưu tập bạn tạo trong ứng dụng, từ terminal hoặc CI/CD của bạn.
Trong khi Keploy nắm bắt hành vi, Apidog yêu cầu bạn thiết kế nó. Bạn xây dựng một kịch bản một lần, thêm các xác nhận bạn kiểm soát và chạy nó ở mọi nơi. CLI thực hiện kiểm thử hướng dữ liệu với -d (CSV hoặc JSON), chuyển đổi môi trường với -e, xuất báo cáo ở định dạng CLI, HTML và JSON, và đẩy báo cáo lên đám mây với --upload-report. Nó có thể nhập OpenAPI và quản lý các điểm cuối, lược đồ, nhánh và yêu cầu hợp nhất như mã. Apidog cũng có tính năng tạo trường hợp thử nghiệm bằng AI từ lược đồ API và các điểm cuối của bạn, được tạo bên trong ứng dụng, đây là điểm trùng lặp với tính năng tạo dựa trên đặc tả của Keploy.
Đây là điểm mấu chốt, bởi vì hai công cụ này thuộc các loại khác nhau. Apidog không nắm bắt lưu lượng truy cập trực tiếp qua eBPF, và nó không tự động tạo thử nghiệm bằng cách ghi lại các cuộc gọi sản xuất cộng với các mock cơ sở dữ liệu. Khả năng ghi và phát lại từ lưu lượng truy cập thực tế đó là điểm mạnh khác biệt của Keploy. Nếu việc nắm bắt hành vi thời gian chạy không cần mã là toàn bộ công việc, Apidog không phải là một sự thay thế cho nó. Nếu bạn muốn một bộ thử nghiệm có thể duy trì cùng với thiết kế, mocking và tài liệu ở một nơi, đó chính là nơi Apidog phù hợp.
Bắt đầu với hướng dẫn đầy đủ về Apidog CLI, sau đó là hướng dẫn cài đặt. Đối với các quy trình làm việc sâu hơn, có kiểm thử hướng dữ liệu, báo cáo kiểm thử, đường ống CI/CD và GitHub Actions. Khía cạnh AI được đề cập trong tạo trường hợp thử nghiệm dựa trên AI và tạo tập lệnh thử nghiệm từ OpenAPI. Nếu bạn đang cân nhắc trực tiếp hai công cụ này, hãy xem Apidog CLI vs Keploy và hướng dẫn di chuyển.
Ưu điểm: Các thử nghiệm được tạo sẵn, dễ đọc, thân thiện với phiên bản. Vòng đời đầy đủ (thiết kế, mock, tài liệu, kiểm thử). Chạy hướng dữ liệu, nhiều định dạng báo cáo, sẵn sàng cho CI. Tạo thử nghiệm bằng AI từ đặc tả của bạn. Nhược điểm: Không có tính năng nắm bắt lưu lượng eBPF và không có tính năng tự động mock từ lưu lượng truy cập thực. Bạn tạo kịch bản thay vì ghi lại chúng. Không có công cụ kiểm tra cú pháp OpenAPI độc lập trong CLI.
2. Postman / Newman
Postman là máy khách API được biết đến rộng rãi nhất, và Newman là trình chạy CLI của nó. Bạn xây dựng các yêu cầu và tập lệnh kiểm thử trong Postman, sau đó chạy bộ sưu tập không giao diện với Newman trong CI.
Đây là công cụ gần nhất với mô hình bộ được tạo sẵn. Nếu nhóm của bạn đã sử dụng Postman, Newman là con đường ít kháng cự nhất cho các lần chạy dòng lệnh và đường ống.
Ưu điểm: Hệ sinh thái lớn, giao diện người dùng quen thuộc, định dạng bộ sưu tập trưởng thành, cộng đồng mạnh mẽ. Nhược điểm: Các thử nghiệm là các đoạn mã JavaScript được gắn vào các yêu cầu, lan rộng khi các bộ sưu tập phát triển. Các lần chạy hướng dữ liệu và báo cáo thủ công hơn so với trong một CLI được xây dựng có mục đích. Giống như Apidog, nó không ghi lại hành vi thời gian chạy thực theo cách Keploy làm. Xem so sánh song song trong Apidog CLI vs Newman.
3. Hoppscotch CLI
Hoppscotch là một máy khách API mã nguồn mở, nhẹ, và CLI của nó chạy các bộ sưu tập đã lưu của bạn từ terminal. Nó rất phù hợp cho các nhóm nhỏ và các dự án mã nguồn mở muốn một cái gì đó nhanh chóng và miễn phí mà không cần cài đặt nặng nề.
Ưu điểm: Mã nguồn mở, nhẹ, dễ bắt đầu, tốt cho các lần chạy bộ sưu tập đơn giản. Nhược điểm: Ít tính năng kiểm thử, báo cáo và vòng đời nâng cao hơn so với các nền tảng lớn hơn. Giống như các công cụ kiểm thử được tạo sẵn khác, không có tính năng nắm bắt lưu lượng hoặc mocking phụ thuộc từ các lần chạy thực tế. So sánh trong Apidog CLI vs Hoppscotch CLI.
4. Schemathesis (kiểm thử mờ dựa trên thuộc tính)
Schemathesis là một loại công cụ khác, và đó chính là điểm mấu chốt. Thay vì chạy các thử nghiệm bạn đã viết, nó đọc lược đồ OpenAPI hoặc GraphQL của bạn và tạo ra một loạt các đầu vào để thăm dò các sự cố, vi phạm lược đồ và hành vi không xác định. Đây là kiểm thử mờ dựa trên thuộc tính, không phải kiểm thử dựa trên ví dụ.
Nó trả lời một câu hỏi mà cả Keploy lẫn các công cụ bộ được tạo sẵn đều không trả lời tốt: API của tôi có chịu được các đầu vào mà tôi chưa bao giờ nghĩ đến để thử không? Nhiều nhóm chạy Schemathesis cùng với bộ chính của họ chứ không phải thay thế nó.
Ưu điểm: Tìm ra các trường hợp biên mà con người bỏ lỡ. Hướng lược đồ, vì vậy nó mở rộng theo đặc tả của bạn. Mạnh mẽ để củng cố và tuân thủ hợp đồng. Nhược điểm: Fuzzing làm xuất hiện nhiễu mà bạn phải xử lý. Nó xác thực dựa trên lược đồ, vì vậy một phản hồi sai nhưng hợp lệ có thể lọt qua. Nó là một sự bổ sung, không phải một chiến lược kiểm thử hoàn chỉnh. Để biết nó phù hợp ở đâu, hãy xem công cụ kiểm thử hợp đồng và mocking và tổng hợp các công cụ tự động hóa kiểm thử API rộng hơn.
5. Ghi-phát lại và mocking kiểu VCR / Mountebank
Đây là danh mục gần với Keploy nhất về tinh thần. Các công cụ VCR dựa trên thư viện (VCR cho Ruby, vcrpy cho Python và các công cụ tương tự) ghi lại các tương tác HTTP vào các tệp "cassette" và phát lại chúng trong các thử nghiệm. Mountebank là một công cụ độc lập ghi lại và tạo stub các phụ thuộc dịch vụ qua mạng.
Nếu sức hấp dẫn của Keploy là "nắm bắt các cuộc gọi thực và phát lại chúng", thì những công cụ này mang lại cho bạn một phần của điều đó mà không cần eBPF. Sự khác biệt rất quan trọng: VCR ghi lại ở lớp máy khách HTTP bên trong mã của bạn (bạn thêm thư viện), và Mountebank nằm ở vị trí proxy. Cả hai đều không nắm bắt các truy vấn cơ sở dữ liệu hoặc hành vi phụ thuộc ở cấp độ kernel như cách eBPF của Keploy làm. Chúng ghi lại HTTP cấp ứng dụng, không phải toàn bộ bức tranh thời gian chạy.
Ưu điểm: Ghi-phát lại thực sự cho HTTP mà không yêu cầu Linux/eBPF. Tồn tại các tùy chọn trưởng thành, được hiểu rõ, cụ thể theo ngôn ngữ. Nhược điểm: Tích hợp cấp mã (VCR) hoặc một proxy bạn vận hành (Mountebank). Chỉ ở lớp HTTP, vì vậy không có tính năng nắm bắt cơ sở dữ liệu hoặc phụ thuộc streaming. Cần thiết lập nhiều hơn so với thăm dò không mã của Keploy. Xem lược đồ OpenAPI và tạo dữ liệu mock cho khía cạnh mocking.
Bảng so sánh
| Công cụ | Cách tiếp cận | Tự động nắm bắt lưu lượng thực | Mock DB/phụ thuộc từ lưu lượng | Nền tảng API đầy đủ | Giấy phép |
|---|---|---|---|---|---|
| Keploy | Ghi-phát lại eBPF + tạo thử nghiệm AI | Có (eBPF, không mã) | Có | Không (chỉ tạo thử nghiệm) | Apache-2.0 |
| Apidog CLI | Các kịch bản được tạo sẵn + tạo thử nghiệm AI từ đặc tả | Không | Không | Có | Thương mại (có bản miễn phí) |
| Postman / Newman | Các bộ sưu tập được tạo sẵn + thử nghiệm JS | Không | Không | Một phần | Thương mại (có bản miễn phí) |
| Hoppscotch CLI | Các bộ sưu tập được tạo sẵn | Không | Không | Một phần | Mã nguồn mở |
| Schemathesis | Kiểm thử mờ dựa trên thuộc tính từ lược đồ | Không | Không | Không | Mã nguồn mở |
| VCR / Mountebank | Ghi-phát lại HTTP + tạo stub | Chỉ HTTP | Chỉ HTTP | Không | Mã nguồn mở |
Cách chọn
Chọn công cụ phù hợp với nhu cầu, không phải theo cường điệu.
- Bạn muốn nắm bắt hành vi thời gian chạy thực tế không cần mã, bao gồm các mock cơ sở dữ liệu, và bạn chạy trên Linux. Keploy là công cụ phù hợp. Không có giải pháp thay thế nào tái tạo việc nắm bắt eBPF trên các phụ thuộc DB và streaming. Hãy thành thật với bản thân: nếu đó là yêu cầu, đừng chuyển đổi.
- Bạn muốn một phiên bản ghi-phát lại một phần mà không cần eBPF, ở lớp HTTP. Các thư viện kiểu VCR hoặc Mountebank sẽ giúp bạn đạt được điều đó với một số thiết lập.
- Bạn muốn các thử nghiệm mà bạn tự tạo, đọc và duy trì, cộng với thiết kế, mocking và tài liệu ở một nơi. Apidog CLI là lựa chọn phù hợp nhất, và nó bổ sung tính năng tạo thử nghiệm bằng AI từ đặc tả của bạn. Postman/Newman và Hoppscotch CLI là các lựa chọn thử nghiệm được tạo sẵn nhẹ hơn.
- Bạn muốn củng cố một API chống lại các đầu vào mà không ai lường trước. Thêm Schemathesis vào bất cứ thứ gì bạn đang chạy.
Đối với hầu hết các nhóm, câu trả lời thực sự là hai công cụ, không phải một. Nắm bắt hoặc kiểm thử mờ để tìm ra những gì bị hỏng, sau đó tạo một bộ có thể duy trì để khóa hành vi. Đó là quy trình làm việc mà Apidog được xây dựng cho, và bạn có thể tải xuống Apidog và chạy các kịch bản đã tạo sẵn từ CLI trong vài phút. Nếu Keploy là điểm xuất phát của bạn, phân tích các giải pháp thay thế Keploy tốt nhất và Keploy là gì cung cấp cho bạn toàn bộ thông tin cơ bản.
nút