Một nhóm có thể xây dựng phần mềm hoàn toàn phù hợp với đặc tả của nó nhưng vẫn cho ra đời một sản phẩm sai. Họ cũng có thể xây dựng đúng sản phẩm trên nền mã nguồn đầy lỗi. Hai thất bại này có tên gọi: thất bại đầu tiên là vấn đề xác minh (verification), thất bại thứ hai là vấn đề xác nhận (validation). Nhầm lẫn giữa hai điều này là cách các quy trình chất lượng trở nên bận rộn nhưng không hiệu quả.
Hướng dẫn này sẽ định nghĩa rõ cả hai thuật ngữ, trình bày sự khác biệt và chỉ ra vị trí của từng thuật ngữ trong quy trình kiểm thử API với Apidog.
Xác minh (Verification) là gì?
Xác minh đặt câu hỏi: chúng ta đang xây dựng sản phẩm đúng cách chưa?
Nó kiểm tra xem một phần mềm có tuân thủ đặc tả, thiết kế và các tiêu chuẩn của nó hay không. Xác minh so sánh công việc với ý định đã được ghi lại. Nó không hỏi liệu ý định đó có đúng hay không; nó chỉ hỏi liệu việc triển khai có khớp với ý định đó hay không.
Xác minh diễn ra liên tục, trong suốt quá trình phát triển, chứ không phải ở cuối. Các hoạt động xác minh điển hình bao gồm:
- Đánh giá mã (Code review) và kiểm tra từng bước (walkthrough)
- Phân tích tĩnh (Static analysis) và sửa lỗi cú pháp (linting)
- Đánh giá thiết kế và kiến trúc
- Kiểm tra lược đồ (schema) và hợp đồng (contract)
- Kiểm thử đơn vị (Unit test) để xác nhận một hàm thực hiện đúng những gì chữ ký của nó cam kết
Đặc điểm chính là xác minh chủ yếu mang tính nội bộ. Nó so sánh một thành phần với một thành phần khác: mã nguồn với thiết kế, phản hồi với lược đồ, triển khai với đặc tả. Không cần người dùng thực sự. Nếu đặc tả nói rằng điểm cuối (endpoint) trả về 201 kèm tiêu đề Location, xác minh sẽ xác nhận nó thực hiện đúng như vậy.
Xác nhận (Validation) là gì?
Xác nhận đặt câu hỏi: chúng ta có đang xây dựng đúng sản phẩm không?
Nó kiểm tra xem phần mềm có thực sự đáp ứng nhu cầu người dùng và giải quyết vấn đề thực sự hay không, bất kể đặc tả đã nói gì. Xác nhận so sánh công việc với thực tế và mục đích sử dụng, chứ không phải với một tài liệu.
Xác nhận thường diễn ra muộn hơn, khi đã có thứ gì đó mà người dùng hoặc bên liên quan có thể sử dụng. Các hoạt động xác nhận điển hình bao gồm:
- Kiểm thử chấp nhận người dùng (User acceptance testing - UAT)
- Chương trình thử nghiệm beta và kiểm thử khả năng sử dụng
- Kiểm thử đầu cuối (End-to-end testing) các quy trình làm việc hoàn chỉnh
- Trình diễn và phê duyệt của các bên liên quan
Đặc điểm chính là xác nhận hướng ra bên ngoài. Nó hỏi liệu sản phẩm hoàn chỉnh có hữu ích và đúng trong ngữ cảnh sử dụng hay không. Một API có thể vượt qua mọi kiểm tra xác minh, tuân thủ hoàn hảo đặc tả OpenAPI của nó, nhưng vẫn thất bại trong xác nhận vì bản thân đặc tả đã giải quyết sai vấn đề; mô hình phân trang không thể sử dụng được, hoặc luồng xác thực không phù hợp với cách các client thực sự tích hợp.
Xác nhận (Validation) so với Xác minh (Verification): sự khác biệt
| Khía cạnh | Xác minh (Verification) | Xác nhận (Validation) |
|---|---|---|
| Câu hỏi cốt lõi | Chúng ta có đang xây dựng đúng cách không? | Chúng ta có đang xây dựng đúng sản phẩm không? |
| So sánh với | Đặc tả, thiết kế, tiêu chuẩn | Nhu cầu người dùng, sử dụng thực tế |
| Thời điểm | Liên tục, trong suốt quá trình phát triển | Sau này, khi có thể sử dụng được |
| Phương pháp điển hình | Đánh giá, phân tích tĩnh, kiểm thử đơn vị, kiểm tra lược đồ | Kiểm thử chấp nhận, beta, kiểm thử đầu cuối, trình diễn |
| Hướng | Hướng nội: thành phần so với thành phần | Hướng ngoại: sản phẩm so với thực tế |
| Phát hiện | Lỗi, sai lệch đặc tả, trôi hợp đồng | Yêu cầu sai, không phù hợp, lỗ hổng khả năng sử dụng |
| Chi phí bỏ qua | Mã lỗi nhưng phù hợp với đặc tả tốt | Sản phẩm hoàn thiện nhưng giải quyết sai vấn đề |
Hai khái niệm này không thể thay thế cho nhau và cũng không cái nào thay thế cái kia. Xác minh mạnh mẽ nhưng xác nhận yếu sẽ cho bạn một sản phẩm không có lỗi nhưng không ai muốn. Xác nhận mạnh mẽ nhưng xác minh yếu sẽ cho bạn một ý tưởng đúng được triển khai trên mã nguồn không ổn định. Bạn cần cả hai, được áp dụng đúng thời điểm.
Một cách ghi nhớ đơn giản: xác minh là kiểm thử dựa trên tài liệu, xác nhận là kiểm thử dựa trên mục đích.
Điều này thể hiện như thế nào trong kiểm thử API
API làm cho sự phân biệt này trở nên cụ thể, vì một API có một đặc tả rõ ràng, có thể đọc được bằng máy: định nghĩa OpenAPI hoặc lược đồ của nó. Đặc tả đó là cơ sở để xác minh.
Xác minh cho một API có nghĩa là kiểm tra việc triển khai so với hợp đồng đó:
- Mỗi điểm cuối (endpoint) có trả về các mã trạng thái đã được ghi lại không? Đảm bảo tính nhất quán của các mã này là một nguyên tắc riêng; hãy xem các mã trạng thái HTTP mà REST API nên sử dụng.
- Mọi phản hồi có khớp với lược đồ đã ghi lại, với tên trường và kiểu dữ liệu chính xác không?
- Các tham số bắt buộc có được thực thi chính xác như đã chỉ định không?
- Định dạng lỗi có khớp với hình dạng lỗi đã ghi lại không?
Đây cũng là nơi kiểm thử hợp đồng API tồn tại. Một kiểm thử hợp đồng là xác minh thuần túy: nó xác nhận nhà cung cấp vẫn tôn trọng thỏa thuận mà người tiêu dùng phụ thuộc. Các khẳng định API về trạng thái, lược đồ và tiêu đề là đơn vị công việc xác minh.
Xác nhận cho một API có nghĩa là kiểm tra xem API có thực sự phục vụ người tiêu dùng của nó hay không:
- Một client có thể hoàn thành một quy trình làm việc đầu cuối thực sự, đăng nhập, tạo, cập nhật, xóa, mà không cần các giải pháp tạm thời khó chịu không?
- Dữ liệu mà API trả về có thực sự trả lời các câu hỏi mà nhà phát triển client đặt ra không?
- Mô hình xác thực có thực tế cho các tích hợp hiện có không?
- Các ví dụ được ghi lại có phản ánh cách API thực sự được sử dụng không?
Một kịch bản kiểm thử API liên kết nhiều yêu cầu thành một hành trình người dùng hoàn chỉnh gần với xác nhận hơn; một kiểm tra lược đồ điểm cuối đơn lẻ là xác minh. Cả hai đều thuộc về bộ kiểm thử. Hiểu về kịch bản kiểm thử so với trường hợp kiểm thử giúp bạn nhận ra mình đang làm việc ở lớp nào.
Apidog phù hợp ở đâu
Apidog hỗ trợ cả hai khía cạnh của sự phân biệt này vì nó giữ thiết kế, kiểm thử và tài liệu API trong một không gian làm việc duy nhất.
Đối với xác minh, thiết kế API chính là đặc tả. Khi bạn xây dựng một kiểm thử, bạn khẳng định các phản hồi dựa trên cùng lược đồ định nghĩa API, do đó xác minh không có bản sao thứ hai của hợp đồng để bị lệch đi. Các khẳng định lược đồ, khẳng định trạng thái và kiểm tra hợp đồng đều chạy dựa trên nguồn dữ liệu đáng tin cậy. Chạy chúng trên mỗi commit thông qua CI; tự động hóa kiểm thử API trong CI/CD làm cho xác minh trở nên liên tục, điều này chính xác là khi nó nên xảy ra.
Đối với xác nhận, các kịch bản kiểm thử Apidog liên kết nhiều điểm cuối thành các quy trình làm việc hoàn chỉnh. Bạn có thể xây dựng một kịch bản đăng ký người dùng, đăng nhập, tạo tài nguyên và xác nhận kết quả, sau đó chạy nó theo cách một client thực sự sẽ làm. Bài tập đầu cuối đó là cách bạn kiểm tra xem API có giải quyết được vấn đề thực sự hay không, chứ không chỉ là mỗi điểm cuối khớp với dòng của nó trong đặc tả.
Chức năng báo cáo hoàn tất vòng lặp. Apidog tạo kết quả theo từng bước, vì vậy một kiểm tra xác minh thất bại (lỗi không khớp lược đồ) và một kiểm tra xác nhận thất bại (quy trình làm việc đa bước bị lỗi) đều hiển thị rõ ràng, riêng biệt và có thể theo dõi được.
Tải Apidog để thiết lập cả xác minh cấp hợp đồng và xác nhận cấp quy trình làm việc cho API của bạn.
Một ví dụ thực tế
Hãy hình dung một nhóm đang xây dựng API thanh toán. Đặc tả nói rằng POST /payments chấp nhận một số tiền và một loại tiền tệ, trả về 201 với một payment_id, và từ chối các loại tiền tệ không hợp lệ bằng mã 400.
Xác minh trên API này diễn ra suôn sẻ. Đánh giá mã xác nhận bộ xử lý (handler) khớp với thiết kế. Các khẳng định lược đồ xác nhận mọi phản hồi có các trường và kiểu dữ liệu được ghi lại. Các kiểm thử hợp đồng xác nhận hình dạng lỗi 400 chính xác như đã chỉ định. Các kiểm tra mã trạng thái đều vượt qua. Theo mọi tiêu chí xác minh, API được xây dựng đúng cách.
Sau đó, client thực tế đầu tiên tích hợp. Họ phát hiện ra rằng API chấp nhận số tiền dưới dạng số dấu phẩy động (floating-point number), vì vậy 0.1 + 0.2 làm tròn thành một giá trị không khớp với hóa đơn của khách hàng. Đặc tả nói “amount: number.” Việc triển khai đã tuân thủ hoàn hảo. Đặc tả đã sai; tiền không bao giờ nên là một số float. Xác minh không thể phát hiện ra điều này, vì xác minh chỉ kiểm tra việc triển khai so với đặc tả, và cả hai đều đồng ý.
Xác nhận phát hiện ra nó. Ngay khi một client thực hiện một thanh toán đầu cuối thực sự và đối chiếu nó với một hóa đơn, lỗi làm tròn sẽ xuất hiện. Giải pháp không phải là báo cáo lỗi mã; đó là một thay đổi đặc tả, số tiền trở thành các đơn vị nhỏ dạng số nguyên. Đó là dấu hiệu của một phát hiện xác nhận: câu trả lời không phải là “sửa mã để khớp với đặc tả,” mà là “bản thân đặc tả đã sai.”
Đây là lý do tại sao cả hai đều quan trọng. Xác minh đã đưa ra một triển khai hoàn hảo của một hợp đồng bị lỗi. Xác nhận, bằng cách sử dụng API theo cách người tiêu dùng thực tế, là điều duy nhất vạch trần hợp đồng là vấn đề.
Danh sách kiểm tra thực tế
Đối với bất kỳ bản phát hành API nào, hãy chạy cả hai cột:
Xác minh (so với đặc tả):
- Mọi điểm cuối đều trả về các mã trạng thái đã được ghi lại
- Mọi phản hồi đều tuân thủ lược đồ của nó
- Các tham số bắt buộc được thực thi
- Các phản hồi lỗi khớp với hình dạng đã ghi lại
- Các kiểm thử hợp đồng vượt qua cho tất cả các điểm cuối hướng đến người tiêu dùng
Xác nhận (so với mục đích):
- Một client mới có thể hoàn thành quy trình làm việc cốt lõi từ đầu đến cuối
- Dữ liệu trả về trả lời các câu hỏi thực tế của client
- Luồng xác thực hoạt động với các mô hình tích hợp thực tế
- Các ví dụ được ghi lại khớp với cách sử dụng thực tế
- Các bên liên quan xác nhận API giải quyết được vấn đề dự kiến
Nếu chỉ cột đầu tiên vượt qua, bạn có một triển khai đúng của một thiết kế có thể sai. Nếu chỉ cột thứ hai vượt qua, bạn có ý tưởng đúng trên mã nguồn không ổn định. Phát hành tự tin có nghĩa là cần cả hai.
Các câu hỏi thường gặp
Xác minh hay xác nhận được thực hiện trước? Xác minh bắt đầu trước và chạy liên tục, vì bạn có thể kiểm tra mã nguồn so với đặc tả ngay khi mã nguồn tồn tại. Xác nhận diễn ra khi có một sản phẩm có thể sử dụng được để kiểm tra với các nhu cầu thực tế.
Kiểm thử có giống với xác nhận không? Không. Kiểm thử bao gồm cả hai. Kiểm thử đơn vị và kiểm tra lược đồ là xác minh; kiểm thử chấp nhận và kiểm thử đầu cuối là xác nhận. Thuật ngữ “kiểm thử” bao trùm toàn bộ phạm vi.
Phần mềm có thể vượt qua xác minh nhưng thất bại trong xác nhận không? Có, và điều này khá phổ biến. Việc triển khai khớp hoàn hảo với đặc tả, nhưng đặc tả đã giải quyết sai vấn đề. Sản phẩm đó được xác minh nhưng chưa được xác nhận.
Điều này áp dụng như thế nào cho kiểm thử hợp đồng API? Kiểm thử hợp đồng là xác minh. Nó xác nhận một API vẫn tôn trọng thỏa thuận đã ghi lại với người tiêu dùng. Nó không xác nhận rằng thỏa thuận đó là đúng; đó là công việc của xác nhận.
Cái nào tìm thấy nhiều lỗi hơn? Xác minh tìm thấy nhiều lỗi hơn về số lượng, vì nó chạy liên tục và phát hiện các sai lệch nhỏ sớm. Xác nhận tìm thấy ít vấn đề hơn nhưng tốn kém hơn, vì một lỗi xác nhận thường có nghĩa là một yêu cầu hoặc thiết kế đã sai, chứ không chỉ là mã nguồn.
Tự động hóa có thể bao gồm cả hai không? Tự động hóa xử lý xác minh tốt: kiểm tra lược đồ, kiểm thử hợp đồng và khẳng định trạng thái chạy trên mỗi commit. Xác nhận khó tự động hóa hoàn toàn hơn vì nó phụ thuộc vào đánh giá về sự phù hợp với thực tế, mặc dù các kiểm thử quy trình làm việc đầu cuối tự động hóa một phần đáng kể của nó.