Trang này được dịch từ tiếng Anh.
Công cụ cho nhà phát triển
Xây dựng công cụ kiểm thử và gỡ lỗi API
Kliv là công cụ xây dựng ứng dụng bằng AI. Mô tả công cụ kiểm thử và gỡ lỗi API mà đội của bạn cần — yêu cầu đã lưu, kiểm tra định kỳ, so sánh phản hồi, sự cố và rào chắn cho đối tác — và Kliv sẽ xây dựng nó.
Chỉ cần nhập ý tưởng của bạn vào ô văn bản và AI sẽ xây nó cho bạn
Kliv là gì?
Kliv không phải là một ứng dụng API client cài trên máy tính hay một dịch vụ lưu trữ collection dùng chung — đây là một AI xây dựng phần mềm thay cho bạn.
Bạn mô tả ứng dụng mình cần bằng lời văn thông thường, và Kliv sẽ xây dựng cơ sở dữ liệu, logic xử lý, giao diện, các tác vụ theo lịch và quy tắc truy cập. Bạn sở hữu toàn bộ kết quả và có thể thay đổi sau này chỉ bằng cách yêu cầu chỉnh sửa. Đây không phải một không gian làm việc dựng sẵn theo mẫu.
Trên trang này, ứng dụng đó là một không gian làm việc kiểm thử và gỡ lỗi API. Kliv xây dựng đủ loại ứng dụng web; ứng dụng này giúp một đội ghi nhớ các yêu cầu, chạy kiểm tra định kỳ, so sánh phản hồi và gắn sự cố với bằng chứng cụ thể.
Vì sao các collection yêu cầu dùng chung không mở rộng được
Một ứng dụng API client trên từng máy tính có thể hoạt động tốt cho một tích hợp và hai kỹ sư. Nhưng nó sẽ không còn hiệu quả khi có nhiều API đối tác, đồng nghiệp ở nhiều múi giờ khác nhau, và khách hàng hỏi liệu sự cố đến từ mã nguồn của bạn hay từ thay đổi phía đối tác.
Kliv xây dựng không gian làm việc này như một hệ thống lưu trữ trung tâm. Mỗi endpoint, yêu cầu đã lưu, kết quả kiểm tra định kỳ, bản so sánh phản hồi và sự cố đều là một dòng dữ liệu trong cơ sở dữ liệu dùng chung, có phân quyền và lịch sử tồn tại lâu hơn máy tính của một cá nhân.
Những thành phần cấu thành một yêu cầu
Năm loại bản ghi biến một yêu cầu đã lưu thành một quy trình gỡ lỗi hoàn chỉnh.
Bản ghi endpoint
URL gốc cho từng môi trường, kiểu xác thực, đầu mối liên hệ của đối tác, và nhật ký thay đổi bạn duy trì. Các yêu cầu và sự cố đều gắn với bản ghi này.
Yêu cầu đã lưu
Header, phần thân và các điều kiện kiểm tra như trạng thái mong đợi, cấu trúc mong đợi và ngưỡng độ trễ. Một yêu cầu trở thành một bài kiểm thử khi nó có điều kiện kiểm tra.
Lịch kiểm tra định kỳ
Các hàm phía máy chủ chạy lại yêu cầu đã lưu theo lịch, chẳng hạn mỗi mười lăm phút với staging và mỗi giờ với production. Một điều kiện kiểm tra thất bại sẽ mở một sự cố.
Sự cố
Một sự cố lưu giữ bản so sánh phản hồi, dòng thời gian, các merchant bị ảnh hưởng, và ai đã được thông báo vào lúc nào.
Rào chắn đối tác
Kỹ sư chỉ thấy những đối tác được giao cho mình. Giao diện trạng thái dành cho khách hàng chỉ hiển thị tích hợp của chính họ, không hơn.
Một ví dụ: đội tích hợp vận chuyển của Linh
Đây là cách một đội có thể sử dụng không gian làm việc kiểm thử API được xây dựng bằng Kliv. Đây chỉ là một ví dụ — bạn sẽ mô tả đối tác, yêu cầu, môi trường, điều kiện kiểm tra và quy tắc xử lý sự cố của riêng mình.
Một đối tác thay đổi phản hồi mà không báo trước
Một hãng vận chuyển triển khai lên staging và header phiên bản đổi từ 2.13 sang 2.14. Không có email, không có mục nào trong nhật ký thay đổi từ phía hãng vận chuyển.
Kiểm tra định kỳ phát hiện thay đổi cấu trúc
Kiểm tra định kỳ của Linh phát hiện payload theo dõi đơn hàng có thêm một trường và mất một trường khác. Endpoint vẫn trả về 200, nhưng điều kiện kiểm tra cấu trúc thất bại.
Sự cố được mở kèm bản so sánh khác biệt
Các merchant bị ảnh hưởng được xác định trực tiếp từ dữ liệu vì chỉ có hai merchant vận chuyển hàng qua hãng này. Mức độ nghiêm trọng không cần phải đoán.
Đội so sánh staging và production song song
Vào thứ Hai, yêu cầu đã lưu được chạy lại trên cả hai môi trường trong cùng một màn hình. Phạm vi thay đổi được xác định rõ, bản sửa lỗi chỉ là cập nhật ánh xạ dữ liệu, và toàn bộ quá trình điều tra nằm gọn trên một màn hình.
Khách hàng xem một dòng thời gian giới hạn theo phạm vi
Merchant thấy trang sự cố của riêng mình: điều gì đã thay đổi, đội biết vào lúc nào, và đã xử lý ra sao. Tích hợp của các merchant khác không hiển thị.
Mô tả không gian làm việc API bạn muốn xây dựng
Kliv xây dựng dựa trên mô tả của bạn, vì vậy hãy nêu rõ đối tác, môi trường, lịch trình, điều kiện kiểm tra, quy tắc xử lý sự cố và ai được xem gì. Bạn mô tả càng chi tiết, phiên bản đầu tiên càng sát với mong muốn.
Không gian làm việc API cho hãng vận chuyển
Yêu cầu đã lưu, kiểm tra định kỳ và sự cố cho đối tác vận chuyển.
“Xây dựng một không gian làm việc kiểm thử API cho các tích hợp vận chuyển của chúng tôi. Lưu yêu cầu theo từng hãng vận chuyển, lưu URL gốc cho staging và production, chạy kiểm tra staging mỗi 15 phút, chạy kiểm tra an toàn với production mỗi giờ, kiểm tra trạng thái 200, các trường theo dõi đơn hàng bắt buộc, và độ trễ dưới 800 mili giây, đồng thời mở sự cố kèm bản so sánh phản hồi đầy đủ và các merchant bị ảnh hưởng.”
Giám sát sandbox thanh toán
Theo dõi một đối tác thanh toán trước khi phát hành.
“Xây dựng một công cụ giám sát API thanh toán chạy lại các yêu cầu đã lưu cho authorization, capture, refund và xác minh webhook mỗi giờ trên môi trường sandbox. Kiểm tra cấu trúc phản hồi, trạng thái, và độ trễ dưới 500 mili giây, đồng thời mở một sự cố kèm bản so sánh khác biệt khi bất kỳ điều kiện kiểm tra nào thất bại.”
Cổng trạng thái cho khách hàng
Cho mỗi merchant lịch sử tích hợp riêng.
“Xây dựng một cổng trạng thái cho khách hàng, nơi mỗi merchant đăng nhập để xem thời gian hoạt động, sự cố và lịch sử kiểm tra định kỳ chỉ cho tích hợp của riêng mình. Gửi email cập nhật khi một sự cố được mở, đổi trạng thái hoặc được xử lý xong.”
Bên trong bộ điều khiển
Kiểm tra định kỳ là các tác vụ theo lịch. Mỗi lần kiểm tra là một hàm phía máy chủ chạy theo cron. Nó chạy lại yêu cầu đã lưu, đánh giá các điều kiện kiểm tra, và ghi kết quả thành một dòng dữ liệu.
Khóa của đối tác luôn ở phía máy chủ. Khóa sandbox và production được nền tảng lưu trữ và chèn vào khi chạy. Chúng không xuất hiện trong các collection xuất ra, trên máy tính cá nhân, hay trên wiki. Một kiểm tra staging không thể chạy với khóa production nếu bạn đánh dấu các môi trường riêng biệt.
Rào chắn là các quy tắc dữ liệu. Một kỹ sư được giao hai hãng vận chuyển sẽ chỉ nhận lại hai hãng đó từ cùng một bảng dữ liệu. Một khách hàng chỉ thấy giao diện trạng thái của riêng mình. Quy tắc bảo mật được áp dụng trước khi dữ liệu được trả về.
Vì đây là một ứng dụng thực thụ, nó có thể phát triển thêm các giao diện mà khách hàng có thể dùng: trang trạng thái cho merchant, bản tổng hợp kiểm tra định kỳ hàng tuần, và một agent trả lời câu hỏi như “API tỷ giá thay đổi lần gần nhất khi nào?” dựa trên chính lịch sử sự cố của bạn.
Kliv cũng viết các bài kiểm thử trong lúc xây dựng và có thể giữ lại việc xuất bản cho đến khi chúng vượt qua. Trang kiểm thử trình bày chi tiết về nguyên tắc đó.
Các câu hỏi thường gặp
Kliv chính xác là gì?
Kliv là công cụ xây dựng ứng dụng bằng AI. Bạn mô tả quy trình kiểm thử API mà mình cần, và Kliv xây dựng một ứng dụng thực thụ với yêu cầu đã lưu, lịch kiểm tra định kỳ, sự cố, bản so sánh khác biệt và giao diện giới hạn theo phạm vi.
Tôi nhận được một ứng dụng thực thụ hay chỉ là một mẫu dựng sẵn?
Một ứng dụng thực thụ. Endpoint, điều kiện kiểm tra, lịch trình, môi trường, sự cố và quy tắc truy cập của bạn được lưu trong một cơ sở dữ liệu xây dựng riêng cho quy trình của bạn.
Tôi có thể thay đổi ứng dụng sau khi nó được xây dựng không?
Có. Bạn có thể thêm đối tác, điều kiện kiểm tra, lịch trình, trường dữ liệu sự cố, giao diện cho khách hàng, hoặc môi trường mới chỉ bằng cách yêu cầu thay đổi bằng lời văn thông thường.
Kiểm tra định kỳ có thể chạy trên production mà không gây thiệt hại không?
Có. Bạn đánh dấu yêu cầu đã lưu nào an toàn với production. Các yêu cầu có tính ghi dữ liệu có thể được giữ cố định ở staging, và mỗi môi trường mang khóa riêng của mình.
Khách hàng có thể xem không gian làm việc này không?
Họ có thể xem một giao diện giới hạn theo phạm vi: tích hợp, sự cố, thời gian hoạt động và lịch sử kiểm tra định kỳ của riêng họ. Kỹ sư vẫn giữ toàn quyền truy cập bộ điều khiển đầy đủ.
Điều gì xảy ra khi một điều kiện kiểm tra thất bại lúc 3 giờ sáng?
Một dòng sự cố được tạo ra kèm bản so sánh phản hồi đính kèm. Email hoặc Slack có thể thông báo cho kỹ sư trực, và kiểm tra định kỳ vẫn tiếp tục chạy để ghi nhận quá trình khôi phục.
Chúng tôi có thể nhập các collection yêu cầu đã có sẵn không?
Có. Yêu cầu đã lưu là dữ liệu. Việc nhập chúng vào sẽ gắn thêm lịch trình, điều kiện kiểm tra, sự cố và quy tắc truy cập, thay vì để chúng nằm im dưới dạng tệp trên một máy tính cá nhân.
Nó có thể lưu trữ thông tin bí mật một cách an toàn không?
Khóa API luôn ở phía máy chủ và được chèn vào khi một kiểm tra định kỳ chạy. Chúng không cần được xuất ra cùng với định nghĩa yêu cầu.
Tôi có thể dùng tên miền riêng của mình không?
Có. Bộ điều khiển nội bộ và giao diện trạng thái cho khách hàng đều có thể chạy trên tên miền riêng của bạn.
Tôi có thể chuyển khỏi Kliv sau này không?
Có. Mã nguồn của ứng dụng được đồng bộ với kho Git riêng của bạn, vì vậy rời đi chỉ đơn giản là một lệnh git pull, không phải xây dựng lại từ đầu.
Tôi có cần một công cụ quản lý sự cố riêng không?
Không, không cần cho quy trình được mô tả ở đây. Sự cố có thể nằm trong cùng một ứng dụng với kiểm tra định kỳ, bản so sánh khác biệt và dòng thời gian hiển thị cho khách hàng.
Thêm trong danh mục này
Phát hiện thay đổi phiên bản trước khi khách hàng nhận ra
Mô tả cách đội của bạn kiểm thử API — đối tác, yêu cầu, kiểm tra định kỳ, điều kiện kiểm tra và rào chắn truy cập. Kliv xây dựng không gian làm việc ghi nhớ tất cả điều đó.
