Keploy: ghi lưu lượng thật, phát lại thành kiểm thử tích hợp cho hệ thống bán lẻ
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Keploy trong một phút: ghi lại lưu lượng thật, phát lại thành bài kiểm thử
Keploy là công cụ kiểm thử API và tích hợp hướng tới lập trình viên. README mô tả nó ghi lại các lời gọi API, truy vấn cơ sở dữ liệu và sự kiện streaming, rồi phát lại chúng thành bài kiểm thử cùng dữ liệu giả lập (mock). Phía dưới, công cụ dùng eBPF, một cơ chế của nhân Linux cho phép gắn đoạn mã quan sát vào hệ thống, để bắt lưu lượng ở tầng mạng, nên người dùng không phải thêm SDK hay sửa mã ứng dụng. [1]
Công cụ đáng xem khi hệ thống có nhiều dịch vụ phụ thuộc cơ sở dữ liệu, hàng đợi hoặc API ngoài và viết tay mock quá tốn công. Chưa nên dùng khi lưu lượng ghi lại chứa dữ liệu cá nhân chưa được che, hoặc ứng dụng dùng giao thức chưa được hỗ trợ.
Một điểm cần nói trước: README vừa mô tả công cụ mã nguồn mở vừa nhắc tới các khả năng gắn với dịch vụ đám mây, hỗ trợ doanh nghiệp và console. Nguồn đã đọc không phân tách rõ từng khả năng thuộc phần nào, nên khuyến nghị của chúng tôi là chỉ lập kế hoạch dựa trên những gì chạy được từ mã nguồn Apache-2.0 và kiểm chứng trong thử nghiệm. [1][2]
Mock viết tay lệch khỏi thực tế nhanh hơn mã nguồn thay đổi
Kiểm thử đơn vị nhanh nhưng không chạm tới nơi lỗi tích hợp hay xảy ra: truy vấn trả về cột khác, API đối tác đổi định dạng. Nhóm thường dựng sẵn cơ sở dữ liệu thật, tốn hạ tầng, hoặc viết mock thủ công, dễ lệch dần khỏi hành vi thật.
Keploy đặt vấn đề theo hướng khác: lấy chính các tương tác thật làm nguồn của bài kiểm thử và mock. README nhấn mạnh việc ghi lại cả cơ sở dữ liệu như Postgres, MySQL, MongoDB, hàng đợi như Kafka, RabbitMQ và API bên ngoài, rồi phát lại một cách tất định để chạy kiểm thử mà không cần dựng lại hạ tầng. [1] Mức độ tất định thực tế phụ thuộc từng giao thức nên phải đo.
Rủi ro đi kèm: bài kiểm thử chỉ phản ánh những gì đã từng được gọi, nên nhánh hiếm chưa từng chạy sẽ không có trong bộ kiểm thử.
Bên trong tác tử: hook eBPF, proxy ghi lại và nhà giám sát parser
Tài liệu gói hooks cho biết đây là mã Go ở không gian người dùng, chịu trách nhiệm nạp các hook và bản đồ (map) eBPF, đồng thời khởi động một proxy trên cổng xác định để bắt các lời gọi đi ra của ứng dụng. [7] Tài liệu proxy mô tả tiếp: đó là tiến trình mà các hook eBPF chuyển hướng kết nối TCP của ứng dụng tới; nhiệm vụ là chuyển tiếp byte trong suốt giữa ứng dụng và đích thật (cơ sở dữ liệu, API) trong khi quan sát lưu lượng để tạo mock. [4]
Phiên bản kiến trúc V2 của proxy chia trách nhiệm khá chặt. Thành phần relay là bên duy nhất ghi lên socket thật, đóng dấu thời gian tại ranh giới lời gọi hệ thống và sao một bản dữ liệu qua kênh có giới hạn cho parser. FakeConn là kết nối chỉ đọc, cố ghi sẽ trả lỗi để parser không thể vô tình làm hỏng lưu lượng. Supervisor bao mỗi lần gọi parser bằng cơ chế bắt panic, bộ canh treo dựa trên hoạt động với ngân sách mặc định 60 giây, và giới hạn bộ nhớ. [4]
Tài liệu nêu bảy bất biến an toàn, trong đó đáng chú ý là: byte phải tới đúng đích theo thứ tự hoặc kết nối chết theo thời gian chờ của chính đối phương, không bao giờ do Keploy; lỗi parser không được ảnh hưởng đường đi của byte; có thể rơi về chuyển tiếp thô bất cứ lúc nào; mock dở dang bị loại và được báo cáo; có công tắc tắt. [4] Hai thế hệ kiến trúc cùng tồn tại trong giai đoạn triển khai V2, nên cần biết parser của giao thức mình dùng thuộc thế hệ nào. [4]
Đường đi của một giao dịch: từ lệnh record đến mocks.yaml rồi test
Theo README, bước ghi bắt đầu bằng lệnh keploy record kèm lệnh chạy ứng dụng; bước kiểm thử dùng keploy test với cùng lệnh, có tham số delay để chờ ứng dụng khởi động, và chạy offline không cần phụ thuộc bên ngoài. [1] Trong lúc ghi, kết nối đi ra của ứng dụng bị hook chuyển vào proxy, proxy chuyển tiếp tới đích thật và đồng thời đưa bản sao cho parser của giao thức tương ứng để tạo mock. [4][7]
Mock được lưu thành tệp. Tài liệu biến môi trường cho biết định dạng mặc định là mocks.yaml, dễ đọc và dễ so sánh trong review; có thể chọn định dạng nhị phân gob, trong đó tài liệu nêu mức tiết kiệm khoảng 28 phần trăm CPU ở tác tử ghi khi thông lượng cao, nhưng không dễ grep hay diff và không đảm bảo tương thích giữa các phiên bản Go. [6] Mock YAML đưa được vào quy trình xem xét mã, nhưng cũng đưa dữ liệu nhạy cảm bị ghi lại vào kho mã nếu không che.
Khi phát lại, mỗi mock có vòng đời riêng, xem phần mở rộng bên dưới. Nếu một đoạn lưu lượng bị mất giữa chừng, tài liệu proxy cho biết mock không đầy đủ bị loại và ghi thành cảnh báo, kèm số đếm trong tóm tắt bản ghi; test case đã lưu trước đó có thể thiếu mock và thất bại khi phát lại với lỗi không có mock. [4] Vì vậy phải đọc tóm tắt ghi trước khi tin bộ kiểm thử.
Những gì có căn cứ trong tài liệu, tách khỏi lời quảng bá
Có căn cứ trực tiếp trong README: ghi và phát lại lời gọi API, truy vấn cơ sở dữ liệu và sự kiện streaming; không cần sửa mã nhờ eBPF; danh sách giao thức và hạ tầng thường được ảo hóa, gồm gRPC, GraphQL, HTTP, Kafka, RabbitMQ, PostgreSQL, MySQL, MongoDB, Redis; tích hợp CI/CD như Jenkins và GitHub Actions hoặc chạy trong cụm Kubernetes. [1] Tài liệu proxy xác nhận có parser riêng cho từng giao thức, và tài liệu vòng đời mock liệt kê cách phân loại cho HTTP, MySQL, Postgres, Mongo, Redis, gRPC và Kafka. [4][5]
Tài liệu biến môi trường mô tả các nút chỉnh cụ thể: KEPLOY_MOCK_FORMAT chọn yaml hoặc gob; PPROF_PORT bật net/http/pprof trên localhost, và tài liệu ghi rõ nút này áp dụng cho bản OSS còn bản doanh nghiệp dùng biến khác. [6] Điều đó cho thấy có bản doanh nghiệp tách biệt.
Phần chưa thể xác nhận là nhóm khả năng sau trong README: sinh thêm kiểm thử bằng AI từ schema OpenAPI, báo cáo thống nhất, console, đóng băng thời gian, Mock Registry và tính độ phủ. Các liên kết trỏ ra trang ngoài hoặc app.keploy.io, và tệp đã đọc không cho biết phần nào có trong mã nguồn mở tại commit này. [1] Xem chúng là khả năng cần kiểm chứng.
Ba vòng đời mock: vì sao kiểm thử chạy riêng lẻ qua nhưng chạy cả lô thì hỏng
Tài liệu vòng đời mock giải thích một lỗi rất thực tế. Mỗi mock thuộc một trong ba vòng đời: phiên (nhãn config, dùng lại giữa các bài test, ví dụ bắt tay xác thực MySQL hay HELLO của Redis), kết nối (dùng lại trong một mã kết nối, ví dụ chuẩn bị câu lệnh Postgres) và theo từng test (bị xóa khỏi kho sau khi khớp, như truy vấn dữ liệu). [5]
Lý do tồn tại: hai kiểu hỏng chỉ lộ ra ở quy mô lớn. Một là rò rỉ chéo, bài test B khớp nhầm mock của bài test A nên từng bài qua nhưng chạy cả lô theo thứ tự khác thì hỏng. Hai là câu lệnh chuẩn bị biến mất, khi bài test sau tham chiếu câu lệnh đã chuẩn bị ở bài trước trên cùng kết nối. [5]
Trang tài liệu tự ghi trạng thái đang tiến hành trong kế hoạch thống nhất vòng đời mock, nên chi tiết có thể thay đổi. [5] Với đội đánh giá, đây vừa là tín hiệu kỹ thuật nghiêm túc vừa là cảnh báo về độ chín: hành vi phát lại ở giao thức mình dùng cần được thử riêng.
Ai hưởng lợi, ai nên đứng ngoài
Đội backend có nhiều dịch vụ, nhiều kho dữ liệu và bộ kiểm thử tích hợp tốn kém là đối tượng chính. README nhấn mạnh nó dành cho người phát triển và cả người làm QA, với độ phủ câu lệnh, nhánh, schema API và ca sử dụng nghiệp vụ. [1]
Không phù hợp với đội chưa có kiểm thử đơn vị cơ bản, vì Keploy bổ sung chứ không thay thế. Không phù hợp nếu dịch vụ dùng giao thức mà bộ parser chưa phủ: README ghi chú một số phụ thuộc không mã nguồn mở vì giao thức và cách phân tích chưa được công khai, và không được hỗ trợ trong bản doanh nghiệp. [1]
Cần thận trọng với môi trường chạy: các tài liệu đã đọc không liệt kê phiên bản nhân tối thiểu hay yêu cầu đặc quyền cho eBPF, nên đội hạ tầng phải xác nhận trước khi cam kết lịch thử nghiệm.
Tình huống giả định: hồi quy cho API đơn hàng, tồn kho và bảo hành của chuỗi bán lẻ điện máy
Đây là đề xuất, không phải trường hợp đã xảy ra. Hãy hình dung một chuỗi bán lẻ điện máy có vài chục cửa hàng. Hệ thống thương mại gồm dịch vụ đơn hàng, tồn kho theo kho, tích điểm khách hàng, kích hoạt bảo hành điện tử và cổng thanh toán. Trước mỗi đợt khuyến mãi lớn, đội kỹ thuật phải kiểm tra hồi quy các luồng như đơn trả góp, đổi trả, chuyển hàng giữa kho. Dịch vụ dùng cơ sở dữ liệu quan hệ và hàng đợi sự kiện, đúng loại hạ tầng mà README liệt kê. [1]
Đề xuất: chạy tác tử Keploy ở môi trường staging khi nhân viên kiểm thử thao tác các kịch bản chuẩn như đặt hàng, hủy đơn, kích hoạt bảo hành để tạo test và mock, rồi chạy bộ này trong CI cho từng lần thay đổi dịch vụ đơn hàng, mà không cần dựng lại cơ sở dữ liệu thật. [1] Phải dùng dữ liệu tổng hợp hoặc dữ liệu đã che cho tên, số điện thoại, địa chỉ của khách, vì mock YAML nằm trong kho mã và được xem xét như văn bản. [6] Các tình huống đổi giờ, như khuyến mãi theo khung giờ, cần thiết kế riêng vì khả năng đóng băng thời gian trong README chưa xác minh được. [1]
Phạm vi nên giới hạn ở hai hoặc ba luồng giá trị cao. Cổng thanh toán và dữ liệu thẻ không nên đưa vào lưu lượng ghi; chỉ dùng môi trường thử của nhà cung cấp. Đội pháp chế cần xác nhận việc xử lý dữ liệu cá nhân trong mock theo quy định hiện hành của Việt Nam trước khi lưu trữ.
Triển khai và vận hành: tác tử, kho mock và công tắc khẩn cấp
Theo README, cài đặt bằng một dòng lệnh tải tập lệnh cài đặt từ keploy.io. [1] Khuyến nghị riêng của bài viết: tải về, rà soát và ghim phiên bản thay vì chạy thẳng tập lệnh từ mạng.
Về vận hành, tài liệu đưa ra vài công cụ chẩn đoán cụ thể: biến KEPLOY_DISABLE_PARSING bằng 1 hoặc tín hiệu SIGUSR1 là công tắc tắt phân tích, được kiểm tra với mỗi kết nối mới; PPROF_PORT bật pprof trên localhost; GOMEMLIMIT_MB đặt giới hạn mềm cho bộ nhớ của tác tử ghi. [4][6]
Cấu hình ưu tiên tệp keploy.yml hơn biến môi trường, trừ trường hợp được ghi chú, và biến môi trường có phạm vi toàn tiến trình nên dễ rò sang các lần chạy khác trong cùng shell. [6] Vòng đời mock cũng cần quy trình: ghi lại, xem tóm tắt số mock bị loại, rồi mới đưa vào kho. [4][5]
Bảo mật: dữ liệu ghi lại là rủi ro lớn nhất
Rủi ro hàng đầu nằm ở nội dung được ghi, không phải ở công cụ. Proxy nằm trên đường đi của lưu lượng giữa ứng dụng và cơ sở dữ liệu, nên mock có thể chứa mật khẩu, mã xác thực, dữ liệu khách hàng. Tài liệu vòng đời mock cho thấy bắt tay xác thực như AUTH của Redis hay SCRAM của Mongo được phân loại và lưu như mock phiên, tức là chúng thuộc dữ liệu cần xử lý cẩn thận. [5] Các tài liệu đã đọc không nhắc chức năng che dữ liệu tự động, nên đội cần tự kiểm tra.
Về an toàn của chính tác tử, tài liệu proxy mô tả thiết kế để lỗi parser không làm hỏng byte đi qua, có giới hạn bộ nhớ và canh treo. [4] Đó là thiết kế được ghi, không phải bằng chứng đã chạy ổn trong sản xuất. Khuyến nghị tối thiểu: chỉ ghi ở staging, tách quyền truy cập tác tử, kiểm soát ai đọc được kho mock.
Chính sách bảo mật của dự án hướng người báo lỗi gửi email tới địa chỉ liên hệ, và nêu rằng hiện chưa có chương trình bug bounty. [3] Đội dùng nên tự theo dõi bản phát hành và không giả định có cam kết thời gian xử lý.
Giấy phép Apache 2.0 và ranh giới với phần thương mại
Tệp LICENSE tại commit khảo sát là Apache License 2.0 với dòng bản quyền 2022 Keploy Inc. Giấy phép cho phép dùng, sao chép, sửa đổi và phân phối, kèm cấp quyền sáng chế theo điều khoản; người phân phối phải giữ thông báo bản quyền và ghi nhận thay đổi theo các điều kiện trong văn bản. Điều 6 nói rõ giấy phép không cấp quyền dùng tên thương mại, nhãn hiệu hay tên sản phẩm của bên cấp phép. [2]
Giấy phép áp dụng cho mã tại commit này, không tự động bao phủ các dịch vụ đám mây, console, Mock Registry hay bản doanh nghiệp mà README nhắc tới, vì các nguồn đã đọc không nêu điều khoản cho chúng. [1][2] README còn ghi chú rằng một số phụ thuộc không phải mã nguồn mở. [1] Cây tệp của kho có tệp CLA nhưng chúng tôi chưa đọc nên không nhận xét về điều khoản đóng góp.
Vì dự án có cả bản OSS lẫn bản doanh nghiệp, cách an toàn là coi mô hình là lõi mở kèm sản phẩm thương mại, và yêu cầu nhà cung cấp trả lời bằng văn bản về ranh giới trước khi phụ thuộc vào bất kỳ khả năng nào chỉ thấy trong tài liệu quảng bá. [1][6]
Chi phí và nguồn lực: ít tiền giấy phép, nhiều công kiểm soát dữ liệu
Giấy phép Apache 2.0 không thu phí, nên chi phí chủ yếu là con người và hạ tầng. [2] Về nhân lực: một kỹ sư kiểm thử hoặc backend dẫn dắt thử nghiệm, một người am hiểu nghiệp vụ để chọn kịch bản, một người phụ trách bảo mật dữ liệu để xác định trường nào cần che. Về hạ tầng: máy Linux cho môi trường staging, runner CI có thể chạy tác tử, và dung lượng lưu mock; kho mock YAML tăng theo số kịch bản.
Giả định lập ngân sách: chỉ thử trên hai hoặc ba luồng, dùng dữ liệu tổng hợp, chạy bản OSS. Cần dự phòng thời gian cập nhật mock và điều tra phát lại thất bại; tài liệu vòng đời mock cho biết lỗi có thể do phân loại mock chứ không phải lỗi ứng dụng. [5]
Không có giá bản doanh nghiệp trong nguồn đã đọc và bài viết không đoán. Nếu cân nhắc các khả năng kèm dịch vụ, cần báo giá trực tiếp từ nhà cung cấp, và tính tới việc README dành riêng một mục cho yêu cầu demo và hỗ trợ doanh nghiệp. [1]
So sánh phương án: ghi lại lưu lượng, viết mock tay, hay dựng hạ tầng thật
Phương án dựng hạ tầng thật bằng container cho mỗi lần kiểm thử cho độ trung thực cao nhưng chậm và tốn tài nguyên khi có nhiều dịch vụ. Phương án viết mock tay, hoặc dùng thư viện mock theo từng ngôn ngữ, linh hoạt nhưng đòi hỏi bảo trì liên tục. Kiểm thử hợp đồng giữa dịch vụ chỉ kiểm tra giao diện. Keploy chọn hướng thứ tư: ghi hành vi thật ở tầng mạng và phát lại. [1]
Ghi và phát lại mạnh ở chỗ không cần sửa mã và dùng được cho nhiều ngôn ngữ, nhưng bộ kiểm thử gắn với đúng tương tác đã ghi; khi hợp đồng đổi chủ ý, phải ghi lại. Kiểm thử hợp đồng và hạ tầng thật vẫn có chỗ cho những gì ghi lại không bao phủ.
Bài viết không so sánh hiệu năng với công cụ cụ thể nào vì nguồn không có dữ liệu. Khuyến nghị: chạy Keploy cạnh phương án hiện tại trên cùng một dịch vụ rồi so sánh số lỗi hồi quy phát hiện được và công bảo trì.
Hạn chế và những lúc không nên dùng
Thứ nhất, độ chín của từng giao thức không đồng đều. Tài liệu proxy ghi hai thế hệ kiến trúc cùng tồn tại, và tài liệu vòng đời mock ghi trạng thái đang tiến hành, kèm đề nghị người dùng báo cáo khi bộ ghi phân loại sai. [4][5] Thứ hai, mock dở dang bị loại, nghĩa là bản ghi có thể thiếu những tương tác mà ta tưởng đã có, nên cần đọc báo cáo sau mỗi lần ghi. [4]
Thứ ba, định dạng gob không có cam kết tương thích giữa các phiên bản Go, nên không phù hợp để lưu dài hạn. [6] Thứ tư, một số phụ thuộc không mã nguồn mở và không được hỗ trợ ở bản doanh nghiệp. [1] Thứ năm, yêu cầu nhân và đặc quyền chưa được nêu.
Không nên dùng khi chưa có cách kiểm soát dữ liệu nhạy cảm, khi cần cam kết bảo mật có thời hạn từ nhà cung cấp, hoặc khi hệ thống phụ thuộc giao thức ngoài phạm vi hỗ trợ. [3] Lời giới thiệu về độ phủ trong README không phải kết quả đo trên hệ thống của đơn vị.
Kế hoạch thử nghiệm sáu tuần cho dịch vụ đơn hàng
Tuần một và hai, chuẩn bị: chọn một dịch vụ, xác nhận môi trường Linux và quyền cần thiết cho tác tử, lập danh sách trường dữ liệu phải che, và xác định giao thức dịch vụ dùng so với danh sách trong README. [1] Tiêu chí qua: đội hạ tầng xác nhận bằng văn bản chạy được tác tử ở staging, và danh sách giao thức đều có parser.
Tuần ba và bốn, ghi và phát lại: ghi năm đến mười kịch bản giá trị cao, đọc tóm tắt số mock bị loại sau mỗi lần ghi, rồi phát lại ít nhất hai lần với thứ tự khác nhau để phát hiện rò chéo. [4][5] Tiêu chí qua: không còn mock bị loại ở kịch bản chính, kết quả phát lại ổn định, mọi thất bại truy được nguyên nhân.
Tuần năm, đưa vào CI cho một nhánh: đo thời gian chạy bộ test so với bộ tích hợp hiện tại và số lần thất bại không do lỗi ứng dụng. Tuần sáu, đánh giá bảo mật: kho mock không chứa dữ liệu thật, quyền truy cập được rà soát.
Tiêu chí dừng: phát hiện dữ liệu nhạy cảm không che được, tỷ lệ thất bại không rõ nguyên nhân cao so với số lần chạy, hoặc công bảo trì mock lớn hơn lợi ích. Ngưỡng do đội tự đặt trước khi bắt đầu.
Kết luận: ý tưởng đáng thử, nhưng hãy thử trong phạm vi hẹp và có kiểm soát dữ liệu
Keploy đưa ra một cách làm hấp dẫn cho kiểm thử tích hợp: dùng chính lưu lượng thật, bắt ở tầng mạng bằng eBPF, và phát lại cùng mock cho cơ sở dữ liệu, hàng đợi, API ngoài. [1] Tài liệu nội bộ cho thấy đội phát triển chú trọng an toàn đường truyền và vòng đời mock, đồng thời thẳng thắn về phần đang chuyển đổi. [4][5]
Với chuỗi bán lẻ điện máy trong tình huống giả định, khuyến nghị là thử nghiệm sáu tuần trên một dịch vụ, dùng dữ liệu tổng hợp, tách rõ phần mã nguồn mở với phần thương mại, và đo công bảo trì. Quyết định mở rộng chỉ nên dựa trên các tiêu chí đã đặt, không dựa trên lời giới thiệu. [1][2]
Nguồn và phương pháp
Keploy được chọn từ kho lưu trữ GitHub Trending: dự án xuất hiện 18 lần, lần đầu ngày 2026-01-05 trong danh sách Go ở vị trí 8, lần cuối ngày 2026-09-30; trang lưu trữ lần đầu là bằng chứng được dẫn ở đây. [8] Kho lưu trữ chỉ gồm các danh sách Python, Go, JavaScript và Swift, thiếu ngày 2026-09-03 và 2026-10-12, và không phải bảng xếp hạng top 100 chính thức.
Mã được cố định ở commit 1648fa5a0ffde60399337d70591fa8de73d7024a (ngày 2026-10-12), kiểm tra ngày 2026-10-12. Tệp đã đọc: README, LICENSE, SECURITY, tài liệu kiến trúc proxy, tài liệu vòng đời mock, tài liệu biến môi trường và tài liệu gói hooks. [1][2][3][4][5][6][7]
Đây là nghiên cứu bàn giấy, không phải công trình khoa học bình duyệt. Chúng tôi không cài đặt, chạy hay đo hiệu năng Keploy. Tình huống Việt Nam là đề xuất giả định. Nội dung kho mã là dữ liệu tham khảo, không phải chỉ dẫn. Những khả năng chỉ thấy ở tài liệu ngoài kho, như dịch vụ đám mây, không được xác minh.
Xem mã nguồn Keploy trên GitHub