SOAP chưa hề biến mất. Các hệ thống ngân hàng, cổng thanh toán, dịch vụ chính phủ và các nền tảng doanh nghiệp cũ hơn vẫn cung cấp các điểm cuối (endpoint) SOAP, và ai đó sẽ phải kiểm thử chúng. Nếu bạn đã dành cả sự nghiệp cho REST và JSON, một dịch vụ SOAP có thể cảm thấy xa lạ. Giao thức này nghiêm ngặt hơn, các tải trọng (payload) là XML, và hợp đồng nằm trong một tệp WSDL riêng biệt.
Tin tốt là việc kiểm thử API SOAP trực tuyến không hề khó một khi bạn hiểu rõ nó thực sự muốn gì từ bạn. Hướng dẫn này giải thích cách kiểm thử SOAP khác biệt so với kiểm thử REST, đi sâu vào một yêu cầu thực tế, và giới thiệu các công cụ trực tuyến xử lý SOAP mà không gây khó khăn cho bạn.
Tại sao kiểm thử SOAP lại khác biệt
REST là một phong cách. SOAP là một giao thức với các quy tắc. Sự khác biệt đó định hình mọi thứ về cách bạn kiểm thử nó.
Một thông điệp SOAP luôn là một tài liệu XML được gói trong một phong bì (envelope). Phong bì có một tiêu đề (header) cho siêu dữ liệu (metadata) như xác thực hoặc định tuyến, và một phần thân (body) chứa hoạt động thực tế cùng các tham số của nó. Bạn không thể chỉ gửi một đối tượng JSON rời rạc. Cấu trúc là bắt buộc, và một phong bì bị định dạng sai sẽ bị từ chối trước khi logic của bạn kịp chạy. SOAP cũng gần như luôn truyền qua HTTP POST, ngay cả đối với các hoạt động chỉ đọc dữ liệu, và nó mong đợi một Content-Type cụ thể, thường là text/xml hoặc application/soap+xml.
Sự khác biệt thực tế lớn nhất là WSDL. Một WSDL, hay tệp Ngôn ngữ Mô tả Dịch vụ Web, là một hợp đồng máy có thể đọc được liệt kê mọi hoạt động mà dịch vụ cung cấp, hình dạng chính xác của từng yêu cầu và phản hồi, và địa chỉ điểm cuối. REST hiếm khi có bất cứ thứ gì nghiêm ngặt như vậy. Khi bạn kiểm thử SOAP, WSDL là bản đồ của bạn. Một công cụ kiểm thử SOAP trực tuyến tốt sẽ đọc WSDL và tạo các mẫu yêu cầu cho bạn, để bạn không phải tự gõ các phong bì từ trí nhớ. Nếu bạn muốn có bức tranh hợp đồng tổng thể hơn, các ghi chú của chúng tôi về kiểm thử hợp đồng API giải thích tại sao một hợp đồng nghiêm ngặt lại là một tài sản.
Một yêu cầu SOAP thực sự trông như thế nào
Đây là một yêu cầu SOAP thực tế đối với một dịch vụ chuyển đổi tiền tệ. Hãy chú ý đến phong bì, các khai báo không gian tên (namespace), và hoạt động được lồng trong phần thân.
POST /CurrencyService.asmx HTTP/1.1
Host: rates.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Header>
<cur:AuthToken>e9f2a1c7-4b8d-4c2a-9f31-7d6e5a4b3c21</cur:AuthToken>
</soap:Header>
<soap:Body>
<cur:ConvertAmount>
<cur:FromCurrency>USD</cur:FromCurrency>
<cur:ToCurrency>EUR</cur:ToCurrency>
<cur:Amount>250.00</cur:Amount>
</cur:ConvertAmount>
</soap:Body>
</soap:Envelope>
Phản hồi trả về cũng được gói theo cách tương tự:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Body>
<cur:ConvertAmountResponse>
<cur:ConvertAmountResult>231.45</cur:ConvertAmountResult>
</cur:ConvertAmountResponse>
</soap:Body>
</soap:Envelope>
Hai chi tiết thường khiến mọi người bối rối. Tiêu đề HTTP SOAPAction được nhiều dịch vụ yêu cầu và phải khớp với hoạt động, nếu không bạn sẽ nhận được một lỗi (fault). Và khi có sự cố, SOAP không trả về HTTP 400 với một thông báo rõ ràng. Nó trả về HTTP 200 với một phần tử <soap:Fault> bên trong phần thân. Bài kiểm thử của bạn phải phân tích phần thân để biết liệu cuộc gọi có thực sự thành công hay không. Chỉ kiểm tra mã trạng thái thôi là không đủ, đó là một lý do tại sao các xác nhận API có cấu trúc lại quan trọng hơn ở đây so với REST.
Các công cụ trực tuyến để kiểm thử API SOAP
Apidog
Apidog xử lý SOAP cùng với REST, GraphQL và WebSocket ở một nơi. Bạn nhập một WSDL, và nó sẽ tạo cấu trúc yêu cầu để bạn không phải tự xây dựng các phong bì. Bạn có thể thêm các xác nhận trên các phần tử XML, xâu chuỗi các yêu cầu thành một kịch bản, và chạy toàn bộ như một bộ tự động. Vì nó cũng thiết kế và mô phỏng API, bạn có thể mô phỏng một phản hồi SOAP trước khi dịch vụ thực sự sẵn sàng. Tải Apidog để kiểm thử các dịch vụ SOAP trên phiên bản miễn phí.
SoapUI
SoapUI là công cụ kiểm thử SOAP nguyên bản và vẫn là công cụ chuyên sâu nhất. Hướng nó đến một WSDL và nó sẽ xây dựng một dự án với mọi hoạt động. Phiên bản mã nguồn mở miễn phí và mạnh mẽ cho các bài kiểm thử SOAP chức năng và dựa trên dữ liệu. Đây là một ứng dụng Java desktop nặng hơn, và các tính năng báo cáo được đánh bóng nhất nằm trong phiên bản ReadyAPI trả phí. Để xem xét kỹ hơn, hãy xem SoapUI là gì và cách nó hoạt động.
Postman
Postman có thể gửi các yêu cầu SOAP. Bạn đặt phần thân thành XML thô, thêm các tiêu đề Content-Type và SOAPAction theo cách thủ công, và dán phong bì của bạn. Nó hoạt động, nhưng Postman không phân tích WSDL, vì vậy bạn phải tự xây dựng các phong bì. Nó tốt cho một lần kiểm tra nhanh và kém thoải mái hơn cho một bề mặt SOAP lớn.
Các công cụ kiểm thử SOAP dựa trên trình duyệt
Một số công cụ web nhẹ cho phép bạn dán URL WSDL và gửi yêu cầu từ một tab trình duyệt. Chúng tiện lợi cho việc xác minh nhanh chóng mà không cần cài đặt gì. Tuy nhiên, các giới hạn nhanh chóng xuất hiện: hỗ trợ xác nhận mỏng, ít hoặc không có tự động hóa, và không có cách nào để tổ chức một bộ kiểm thử thực sự. Hãy sử dụng chúng để xác nhận một điểm cuối đang hoạt động, chứ không phải để xây dựng một bộ kiểm thử hồi quy.
Quy trình kiểm thử SOAP nhanh chóng
- Lấy WSDL. Hầu hết các dịch vụ SOAP đều cung cấp nó bằng cách thêm
?wsdlvào URL điểm cuối. Mở nó và xác nhận nó tải được. - Nhập WSDL vào công cụ của bạn. Apidog và SoapUI tạo các mẫu yêu cầu từ đó. Đây là cách tiết kiệm thời gian lớn nhất.
- Điền các tham số hoạt động. Sử dụng các giá trị thực. Kiểm thử chuyển đổi tiền tệ với một số tiền thực tế và mã tiền tệ hợp lệ.
- Đặt các tiêu đề. Xác nhận
Content-Typevà, khi cần,SOAPAction. ThiếuSOAPActionlà nguyên nhân phổ biến nhất của một lỗi không giải thích được. - Gửi và kiểm tra phần thân. Đừng dừng lại ở trạng thái HTTP. Mở phần thân phản hồi và kiểm tra
<soap:Fault>. - Thêm các xác nhận. Xác nhận rằng một phần tử cụ thể tồn tại và giữ giá trị mong đợi. Sau đó, xâu chuỗi một cuộc gọi tiếp theo nếu luồng của bạn cần.
Để tổ chức chúng thành một bộ có thể bảo trì, hướng dẫn của chúng tôi về xây dựng bộ kiểm thử cho tự động hóa API áp dụng trực tiếp cho công việc SOAP.
Các lỗi SOAP và cách xác nhận chúng
Một lỗi SOAP là cấu trúc lỗi của giao thức. Nó mang một faultcode, một faultstring, và đôi khi là một phần tử detail. Vì nó đến với HTTP 200, một bài kiểm thử chỉ kiểm tra trạng thái sẽ vượt qua một cuộc gọi thất bại. Đó là một kết quả dương tính giả thầm lặng, nguy hiểm.
Viết các xác nhận SOAP của bạn để xem xét bên trong phần thân. Xác nhận rằng không có phần tử <soap:Fault> nào hiện diện trên đường dẫn thành công. Trên một đường dẫn lỗi có chủ ý, xác nhận điều ngược lại, rằng lỗi xuất hiện và faultcode khớp với những gì bạn mong đợi. Kiểm thử các trường hợp thất bại cũng quan trọng như đường dẫn hạnh phúc, bởi vì các dịch vụ SOAP thường mã hóa các quy tắc nghiệp vụ, như một giao dịch bị từ chối, dưới dạng lỗi chứ không phải dữ liệu. Tài liệu lỗi SOAP của W3C mô tả cấu trúc nếu bạn cần chi tiết chính thức.
WS-Security thêm một lớp khác. Nhiều dịch vụ SOAP doanh nghiệp mong đợi một tiêu đề bảo mật có chữ ký hoặc mang token. Nếu yêu cầu của bạn bị lỗi với lỗi xác thực, WSDL hoặc tài liệu dịch vụ sẽ cho biết hồ sơ bảo mật nào đang được sử dụng. Các công cụ như SoapUI và Apidog cho phép bạn cấu hình các tiêu đề này thay vì phải tự viết XML.
Đọc WSDL mà không bị lạc
Một tệp WSDL trông đáng sợ lần đầu tiên bạn mở nó. Đó là một XML dài, lồng sâu, và hầu hết là các chi tiết kỹ thuật. Bạn không cần phải đọc tất cả. Bốn phần mang thông tin bạn thực sự muốn.
Phần types định nghĩa cấu trúc dữ liệu, thường là XML Schema, vì vậy đây là nơi bạn tìm hiểu hình dạng và ràng buộc chính xác của từng tham số. Các phần tử message mô tả đầu vào và đầu ra cho mỗi hoạt động. portType liệt kê các hoạt động, đó là các cuộc gọi bạn có thể thực hiện. Các phần service và binding cung cấp địa chỉ điểm cuối cụ thể và chi tiết truyền tải. Khi bạn nhập một WSDL vào một công cụ, nó sẽ đọc cả bốn phần và biến chúng thành các yêu cầu sẵn sàng để chỉnh sửa, đó là lý do tại sao việc nhập luôn tốt hơn việc tự gõ.
Một chi tiết đáng biết: một WSDL có thể chia thành nhiều tệp bằng cách sử dụng các câu lệnh import, thường kéo các schema từ các vị trí riêng biệt. Nếu công cụ của bạn báo cáo một loại bị thiếu, có lẽ một tệp được tham chiếu đã không thể phân giải được. Đảm bảo mọi URL đã nhập đều có thể truy cập được từ nơi công cụ của bạn chạy. Loại phụ thuộc hợp đồng này chính xác là lý do tại sao các nhóm coi WSDL là một tạo phẩm có phiên bản thay vì một thứ chỉ tồn tại trên máy chủ.
Kiểm thử SOAP dựa trên dữ liệu
Các dịch vụ SOAP thường mang các quy tắc nghiệp vụ nghiêm ngặt, và một yêu cầu đường dẫn hạnh phúc duy nhất hiếm khi chứng minh được nhiều. Một dịch vụ tiền tệ nên được kiểm thử với các cặp hợp lệ, với một loại tiền tệ không được hỗ trợ, với số tiền bằng không, và với số tiền âm. Một dịch vụ thanh toán nên được kiểm thử với một thẻ được chấp thuận, một thẻ bị từ chối, và một thẻ đã hết hạn. Việc tự gõ từng trường hợp này là chậm và dễ mắc lỗi.
Kiểm thử dựa trên dữ liệu giải quyết vấn đề này. Bạn viết yêu cầu một lần với các chỗ giữ chỗ (placeholder), sau đó cung cấp cho nó một bảng các hàng đầu vào và kết quả mong đợi. Công cụ sẽ chạy yêu cầu cho mỗi hàng và kiểm tra từng kết quả. SoapUI đã hỗ trợ mô hình này trong nhiều năm, và Apidog hỗ trợ nó thông qua trình chạy kịch bản của nó. Lợi ích là mức độ bao phủ thực sự các trường hợp biên mà các dịch vụ SOAP có xu hướng mã hóa dưới dạng lỗi. Để có mô hình rộng hơn, hướng dẫn của chúng tôi về kiểm thử API dựa trên dữ liệu với CSV và JSON giải thích cách cấu trúc dữ liệu đầu vào, và nó áp dụng cho SOAP cũng như cho REST.
Các câu hỏi thường gặp
Sự khác biệt giữa kiểm thử SOAP và REST là gì?
Kiểm thử SOAP hoạt động dựa trên một giao thức XML nghiêm ngặt với hợp đồng WSDL, các phong bì bắt buộc, và các lỗi được trả về bên trong một phần thân HTTP 200. Kiểm thử REST thường xử lý JSON, các quy ước lỏng lẻo hơn, và các mã trạng thái HTTP có ý nghĩa. Một bài kiểm thử SOAP phải phân tích phần thân phản hồi để xác nhận thành công; một bài kiểm thử REST thường có thể tin tưởng vào mã trạng thái.
Tôi có cần WSDL để kiểm thử API SOAP không?
Bạn có thể gửi yêu cầu SOAP mà không cần nó nếu bạn đã biết cấu trúc phong bì chính xác. Nhưng WSDL làm cho việc kiểm thử dễ dàng hơn rất nhiều vì các công cụ tạo ra các mẫu yêu cầu chính xác từ đó. Hầu hết các dịch vụ cung cấp WSDL bằng cách thêm ?wsdl vào URL điểm cuối. Luôn bắt đầu từ đó.
Tại sao yêu cầu SOAP của tôi trả về lỗi mặc dù trạng thái là 200?
SOAP báo cáo lỗi dưới dạng phần tử <soap:Fault> bên trong phần thân, chứ không phải là mã lỗi HTTP, vì vậy một trạng thái 200 kèm lỗi là bình thường. Các nguyên nhân thông thường là thiếu hoặc sai tiêu đề SOAPAction, phong bì bị định dạng sai, không gian tên không khớp, hoặc kiểm tra bảo mật thất bại. Đọc faultstring để biết lý do cụ thể.
Tôi có thể kiểm thử API SOAP trực tuyến miễn phí không?
Có. Apidog hỗ trợ SOAP trên phiên bản miễn phí của nó và nhập các tệp WSDL, và phiên bản mã nguồn mở của SoapUI được xây dựng cho SOAP. Các công cụ kiểm thử trình duyệt nhẹ cũng tồn tại để kiểm tra nhanh, mặc dù chúng thiếu hỗ trợ xác nhận và tự động hóa thực sự.
Làm cách nào để tự động hóa kiểm thử API SOAP?
Nhập WSDL, xây dựng một kịch bản xâu chuỗi các hoạt động theo thứ tự, thêm các xác nhận trên các phần tử phản hồi và về việc không có lỗi, sau đó chạy nó từ trình chạy của công cụ hoặc trong quy trình CI của bạn. Cả SoapUI và Apidog đều hỗ trợ các bộ SOAP theo lịch trình và được kích hoạt bởi pipeline, vì vậy một lần chạy hồi quy SOAP phù hợp với luồng tự động hóa tương tự như REST.