SoapUI - Hướng dẫn nhanh

SOAP là từ viết tắt của Simple Object Access Protocol. Nó được xác định bởi World Wide Web Consortium (W3C) tạihttps://www.w3.org/TR/2000/NOTE-SOAP-20000508 như sau -

SOAP là một giao thức nhẹ để trao đổi thông tin trong một môi trường phân tán, phi tập trung. Nó là một giao thức dựa trên XML bao gồm ba phần: một phong bì xác định một khuôn khổ để mô tả những gì trong một thông điệp và cách xử lý nó; một tập hợp các quy tắc mã hóa để thể hiện các thể hiện của kiểu dữ liệu do ứng dụng xác định; và một quy ước đại diện cho các cuộc gọi và phản hồi thủ tục từ xa.

SOAP - Các tính năng quan trọng

Sau đây là một số tính năng quan trọng của SOAP.

  • Nó là một giao thức truyền thông được thiết kế để giao tiếp qua Internet.

  • Nó có thể mở rộng HTTP cho nhắn tin XML.

  • Nó cung cấp vận chuyển dữ liệu cho các dịch vụ Web.

  • Nó có thể trao đổi tài liệu hoàn chỉnh hoặc gọi một thủ tục từ xa.

  • Nó có thể được sử dụng để phát một tin nhắn.

  • Nó độc lập với cả nền tảng và ngôn ngữ.

  • Đây là cách XML để xác định thông tin nào được gửi và cách thức.

  • Nó cho phép các ứng dụng khách dễ dàng kết nối với các dịch vụ từ xa và gọi các phương pháp từ xa.

Mặc dù SOAP có thể được sử dụng trong nhiều hệ thống nhắn tin và có thể được gửi qua nhiều giao thức truyền tải, trọng tâm ban đầu của SOAP là các cuộc gọi thủ tục từ xa được vận chuyển qua HTTP. Các khung công tác khác như CORBA, DCOM và Java RMI cung cấp chức năng tương tự như SOAP, nhưng các thông báo SOAP được viết hoàn toàn bằng XML và do đó độc nhất không phụ thuộc vào nền tảng và ngôn ngữ.

Thông báo SOAP là một tài liệu XML thông thường chứa các phần tử sau:

  • Envelope- Xác định phần bắt đầu và phần cuối của tin nhắn. Nó là một yếu tố bắt buộc.

  • Header- Chứa bất kỳ thuộc tính tùy chọn nào của thông báo được sử dụng để xử lý thông báo, ở điểm trung gian hoặc ở điểm cuối cuối cùng. Nó là một yếu tố tùy chọn.

  • Body- Chứa dữ liệu XML bao gồm thông điệp được gửi đi. Nó là một yếu tố bắt buộc.

  • Fault - Phần tử Lỗi tùy chọn cung cấp thông tin về các lỗi xảy ra trong khi xử lý thông báo.

Tất cả các phần tử này được khai báo trong không gian tên mặc định cho phong bì SOAP -

https://www.w3.org/2001/12/soap-envelope

Không gian tên mặc định cho kiểu dữ liệu và mã hóa SOAP là -

https://www.w3.org/2001/12/soap-encoding

Note- Tất cả các thông số kỹ thuật này có thể thay đổi. Do đó, hãy liên tục cập nhật cho mình các thông số kỹ thuật mới nhất có sẵn trên trang web W3.

SOAP - Cấu trúc thông báo

Khối sau mô tả cấu trúc chung của thông báo SOAP:

<?xml version = "1.0"?> 
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">  
   <SOAP-ENV:Header> 
      ... 
      ... 
   </SOAP-ENV:Header>  
   <SOAP-ENV:Body> 
      ... 
      ... 
      <SOAP-ENV:Fault> 
         ... 
         ... 
      </SOAP-ENV:Fault>  
   </SOAP-ENV:Body>  
</SOAP_ENV:Envelope>

REST là từ viết tắt của Chuyển trạng thái đại diện. Nó có thể được định nghĩa là một phong cách kiến ​​trúc của việc thiết kế phần mềm. REST không phải là một thông số kỹ thuật hoặc tiêu chuẩn W3C. Do đó, làm việc với RESTful Services sẽ dễ dàng hơn. Nó không yêu cầu bất kỳ khung đặc tả phần mềm trung gian nào.

REST - Các tính năng quan trọng

Sau đây là một số tính năng quan trọng của REST.

  • Nó dựa trên giao thức truyền thông không trạng thái, client-server, cacheable - hầu như trong mọi trường hợp, HTTP đều được sử dụng.

  • Nó là sự thay thế nhẹ nhàng của WebService và RPC (Cuộc gọi thủ tục từ xa) như SOAP-WSDL.

  • Nó đại diện cho mọi thứ trong ID hoặc URI duy nhất.

  • Nó sử dụng các phương thức HTTP tiêu chuẩn, chẳng hạn như GET, POST, PUT, DELETE.

  • Nó liên kết các nguồn với nhau.

  • Tài nguyên REST có thể có nhiều đại diện.

  • Mọi thông tin được đặt tên đều được coi là Tài nguyên. Ví dụ: Một hình ảnh, một người, một tài liệu, tất cả đều có thể được coi là một ví dụ về tài nguyên và được biểu diễn dưới dạng một ID hoặc một URI duy nhất.

  • Bản thân World Wide Web, dựa trên HTTP, có thể được xem như là kiến ​​trúc dựa trên REST.

Các dịch vụ REST độc lập với Nền tảng và Ngôn ngữ. Vì nó dựa trên các tiêu chuẩn HTTP nên nó có thể dễ dàng hoạt động khi có tường lửa. Giống như WebServices, REST không cung cấp bất kỳ bảo mật sẵn có, quản lý phiên, đảm bảo QoS nhưng chúng có thể được thêm vào bằng cách xây dựng trên HTTP. Để mã hóa, REST có thể được sử dụng trên HTTPS.

SoapUI là một công cụ có thể được sử dụng để kiểm tra cả chức năng và phi chức năng. Nó không giới hạn ở các dịch vụ web, mặc dù nó là công cụ thực tế được sử dụng trong việc kiểm tra các dịch vụ web.

SoapUI - Các tính năng quan trọng

Sau đây là một số tính năng quan trọng của SoapUI.

  • Nó có khả năng thực hiện vai trò của cả khách hàng và dịch vụ.

  • Nó cho phép người dùng tạo các bài kiểm tra chức năng và phi chức năng một cách nhanh chóng và hiệu quả bằng cách sử dụng một môi trường duy nhất.

  • Nó được cấp phép theo các điều khoản của Giấy phép Công cộng GNU Leaser (LGPL).

  • Nó hoàn toàn được thực hiện bằng cách sử dụng nền tảng JAVA.

  • Nó hỗ trợ Windows, Mac, nhiều phương ngữ Linux.

  • Nó cho phép người thử nghiệm thực hiện các thử nghiệm chức năng, hồi quy, tuân thủ và tải tự động trên các API Web khác nhau.

  • Nó hỗ trợ tất cả các giao thức và công nghệ tiêu chuẩn để kiểm tra tất cả các loại API.

SoapUI có thể được sử dụng để kiểm tra thử nghiệm RESTful API và SOAP Web Service hoàn chỉnh. Nó hỗ trợ Kiểm tra chức năng, Kiểm tra hiệu suất, Kiểm tra khả năng tương tác, Kiểm tra hồi quy, Kiểm tra tải và hơn thế nữa.

Nó thân thiện với người dùng cũng như dễ dàng chuyển đổi kiểm thử chức năng thành kiểm thử phi chức năng như kiểm tra tải, kiểm tra căng thẳng.

SoapUI có 5 khía cạnh sau:

  • Thử nghiệm chức năng
  • Kiểm tra bảo mật
  • Kiểm tra tải
  • Giao thức và Công nghệ
  • Tích hợp với các công cụ khác

Hãy cùng tìm hiểu thêm về từng khả năng này.

Thử nghiệm chức năng

  • SoapUI cho phép người thử nghiệm viết các thử nghiệm API chức năng trong SoapUI.

  • SoapUI hỗ trợ tính năng Kéo-Thả để tăng tốc độ phát triển tập lệnh.

  • SoapUI hỗ trợ gỡ lỗi các bài kiểm tra và cho phép người kiểm tra phát triển các bài kiểm tra theo hướng dữ liệu.

  • SoapUI hỗ trợ nhiều môi trường giúp dễ dàng chuyển đổi giữa các môi trường QA, Dev và Prod.

  • SoapUI cho phép tạo tập lệnh nâng cao (người thử nghiệm có thể phát triển mã tùy chỉnh của họ tùy thuộc vào các tình huống).

Kiểm tra bảo mật

  • SoapUI thực hiện toàn bộ quá trình quét lỗ hổng bảo mật.

  • SoapUI ngăn SQL Injection để bảo mật cơ sở dữ liệu.

  • SoapUI quét các lỗi tràn ngăn xếp gây ra bởi các tài liệu có kích thước lớn.

  • SoapUI quét để tìm tập lệnh trên nhiều trang web, xảy ra khi các thông số dịch vụ được hiển thị trong thông báo.

  • SoapUI thực hiện quét fuzzing và quét ranh giới để tránh hành vi thất thường của các dịch vụ.

Kiểm tra tải

  • SoapUI phân phối các bài kiểm tra tải trên n số tác nhân LoadUI.

  • SoapUI mô phỏng thử nghiệm tải trong thế giới thực và khối lượng lớn một cách dễ dàng.

  • SoapUI cho phép báo cáo tùy chỉnh nâng cao để nắm bắt các thông số hiệu suất.

  • SoapUI cho phép giám sát hiệu suất hệ thống từ đầu đến cuối.

Giao thức & Công nghệ

SoapUI hỗ trợ một loạt các giao thức -

  • SOAP - Giao thức truy cập đối tượng đơn giản
  • WSDL - Ngôn ngữ Định nghĩa Dịch vụ Web
  • REST - Chuyển trạng thái đại diện
  • HTTP - Giao thức truyền siêu văn bản
  • HTTPS - Giao thức truyền siêu văn bản được bảo mật
  • AMF - Định dạng Thông báo Hành động
  • JDBC - Kết nối cơ sở dữ liệu Java
  • JMS - Dịch vụ nhắn tin Java

Tích hợp với các công cụ khác

  • Dự án Apache Maven
  • HUDSON
  • JUnit
  • Apache - Ant và hơn thế nữa….

SoapUI là một công cụ phiên bản miễn phí mã nguồn mở với các tính năng cơ bản để kiểm tra, trong khi SoapUI NG Pro là một công cụ thương mại hóa có các tính năng nâng cao về báo cáo, chức năng theo hướng dữ liệu và hơn thế nữa.

So sánh

Bảng sau đây so sánh và đối chiếu các tính năng khác nhau của SoapUI và SoapUI NG Pro.

Đặc trưng SoapUI SoapUI NG Pro
Supported Technologies
XÀ BÔNG TẮM Đúng Đúng
WSDL / WADL Đúng Đúng
NGHỈ NGƠI Đúng Đúng
JMS Đúng Đúng
AMF Đúng Đúng
JDBC Đúng Đúng
HTTP Đúng Đúng
General Features
Ứng dụng độc lập Đúng Đúng
Hỗ trợ đa môi trường Không Đúng
Giấy phép nổi Không Đúng
Bảo hiểm WSDL Không Đúng
Phạm vi yêu cầu / phản hồi Không Đúng
Xác nhận tin nhắn Đúng Đúng
Kiểm tra cấu trúc lại Không Đúng
Chạy nhiều bài kiểm tra Đúng Đúng
Kiểm tra theo hướng nguồn dữ liệu Không Đúng
Thư viện kịch bản Không Đúng
Báo cáo đơn vị Không Đúng
Các bước kiểm tra thủ công Đúng Đúng
Reporting
Báo cáo Junit Không Đúng
Báo cáo Xuất dữ liệu Không Đúng
Báo cáo HTML WSDL Đúng Đúng
Mức độ phù hợp của bộ thử nghiệm Không Đúng
Phạm vi trường hợp thử nghiệm Không Đúng
Phạm vi khẳng định Không Đúng
Phạm vi ghi tin nhắn Không Đúng

SoapUI là một công cụ đa nền tảng. Nó hỗ trợ các hệ điều hành Windows, Linux và Mac.

Điều kiện tiên quyết

  • Processor - Bộ xử lý 32-bit hoặc 64-bit 1GHz trở lên.

  • RAM - Bộ nhớ RAM 512MB.

  • Hard Disk Space - Ổ cứng trống tối thiểu 200MB để cài đặt.

  • Operating System Version - Windows XP trở lên, MAC OS 10.4 trở lên.

  • JAVA - JAVA 6 trở lên.

Quá trình tải xuống

Step 1- Truy cập www.soapui.org và nhấp vào Tải xuống SoapUI.

Step 2- Nhấp vào 'Get It' để tải xuống SoapUI Open Source. Nó sẽ bắt đầu tải xuống tệp .exe 112MB trong hệ thống. Chờ cho đến khi quá trình tải xuống hoàn tất.

Quá trình cài đặt

Step 1 - Sau khi tải xuống, chạy tệp .exe với tên “Run as administrator”.

Windows sẽ bắt đầu quá trình thiết lập như thể hiện trong ảnh chụp màn hình sau.

Step 2 - Sau khi thiết lập xong, cửa sổ tiến trình hiển thị màn hình sau, nhấn Next.

Step 3 - Chấp nhận thỏa thuận cấp phép và nhấp vào Tiếp theo.

Step 4- Chọn thư mục cài đặt hoặc giữ nguyên làm đường dẫn mặc định do hệ thống chọn. Bấm tiếp.

Step 5- Chọn các thành phần mà bạn muốn cài đặt. Bấm tiếp.

Step 6 - Chấp nhận Thỏa thuận Cấp phép cho HermesJMS và nhấp vào Tiếp theo.

Step 7 - Chọn thư mục đích để lưu các bài hướng dẫn và nhấn Next.

Step 8 - Chọn vị trí thư mục menu bắt đầu hoặc giữ nguyên vị trí mặc định và nhấp vào 'Tiếp theo'.

Step 9 - Bật hộp kiểm 'tạo biểu tượng trên màn hình' và nhấp vào 'Tiếp theo'.

Bây giờ, cài đặt bắt đầu. Sẽ mất một vài phút để hoàn thành.

Step 10 - Sau khi hoàn tất cài đặt, nhấp vào Kết thúc trong trình hướng dẫn sau.

Khi nhấp vào Kết thúc, SoapUI được khởi chạy.

  • Thanh menu
  • Thanh công cụ
  • Thanh điều hướng dự án
  • Thuộc tính không gian làm việc
  • Bảng nhật ký

Quá trình cấu hình

Bước đầu tiên là tạo một không gian làm việc có thể chứa nhiều dự án.

Step 1 - Vào File → New Workspace.

Step 2 - Thêm tên vùng làm việc và bấm OK.

Step 3 - Bây giờ, chọn đường dẫn nơi xml không gian làm việc sẽ được lưu.

Step 4 - Chọn đường dẫn và nhấp vào Lưu.

Không gian làm việc được tạo như thể hiện trong ảnh chụp màn hình sau. Thuộc tính không gian làm việc cũng được trưng bày.

WSDL là viết tắt của Ngôn ngữ Mô tả Dịch vụ Web. Đây là một định dạng tiêu chuẩn để mô tả một dịch vụ web. WSDL được phát triển chung bởi Microsoft và IBM. WSDL được phát âm là 'wiz-xỉn' và được đánh vần là 'WSD-L'.

WSDL ─ Lược sử

WSDL 1.1 đã được Ariba, IBM và Microsoft gửi dưới dạng Ghi chú W3C để mô tả các dịch vụ cho Hoạt động XML của W3C trên các giao thức XML vào tháng 3 năm 2001.

WSDL 1.1 chưa được World Wide Web Consortium (W3C) xác nhận, tuy nhiên nó vừa phát hành bản nháp cho phiên bản 2.0 sẽ là một khuyến nghị (một tiêu chuẩn chính thức) và do đó được W3C xác nhận.

WSDL ─ Những điểm cần lưu ý

WSDL là một giao thức dựa trên XML để trao đổi thông tin trong một môi trường phân tán và phi tập trung. Một số tính năng khác của WSDL như sau:

  • Các định nghĩa WSDL mô tả cách truy cập một dịch vụ web và những hoạt động mà nó sẽ thực hiện.

  • Nó là một ngôn ngữ để mô tả cách giao tiếp với các dịch vụ dựa trên XML.

  • Nó là một phần không thể thiếu của Universal Description, Discovery và Integration (UDDI), một cơ quan đăng ký kinh doanh trên toàn thế giới dựa trên XML.

  • WSDL là ngôn ngữ mà UDDI sử dụng.

Sử dụng WSDL

WSDL thường được sử dụng kết hợp với SOAP và Lược đồ XML để cung cấp các dịch vụ web qua Internet. Một chương trình khách kết nối với một dịch vụ web có thể đọc WSDL để xác định những chức năng nào khả dụng trên máy chủ. Bất kỳ kiểu dữ liệu đặc biệt nào được sử dụng đều được nhúng vào tệp WSDL ở dạng Lược đồ XML. Sau đó máy khách có thể sử dụng SOAP để thực sự gọi một trong các hàm được liệt kê trong WSDL.

Hiểu WSDL

WSDL chia các dịch vụ web thành ba phần tử cụ thể, có thể nhận dạng và có thể được kết hợp hoặc sử dụng lại sau khi được xác định.

Ba yếu tố chính của WSDL có thể được định nghĩa riêng biệt là:

  • Types
  • Operations
  • Binding

Một tài liệu WSDL có nhiều phần tử khác nhau, nhưng chúng nằm trong ba phần tử chính này, có thể được phát triển thành các tài liệu riêng biệt và sau đó chúng có thể được kết hợp hoặc sử dụng lại để tạo thành các tệp WSDL hoàn chỉnh.

Trong hướng dẫn này, chúng tôi đang làm theo WSDL CurrencyConverter: http://www.webservicex.net

Định dạng và các phần tử

WSDL CurrencyConverter sẽ giống như sau:

WSDL ─ Loại cổng

Phần tử <portType> kết hợp nhiều phần tử thông báo để tạo thành một hoạt động một chiều hoặc khứ hồi hoàn chỉnh. Ví dụ: một <portType> có thể kết hợp một yêu cầu và một thông báo phản hồi thành một thao tác yêu cầu / phản hồi duy nhất. Điều này thường được sử dụng nhất trong các dịch vụ SOAP. Một portType có thể xác định nhiều hoạt động.

Thí dụ

  • Phần tử portType xác định một hoạt động duy nhất, được gọi là ConversionRate.
  • Hoạt động bao gồm một thông báo đầu vào duy nhất ConversionRateHttpPostIn.
  • Thao tác cho thông báo Đầu ra là ConversionRateHttpPostOut.

Các mô hình hoạt động

WSDL hỗ trợ bốn mô hình hoạt động cơ bản -

Một chiều

Dịch vụ nhận được một tin nhắn. Do đó, hoạt động có một yếu tố đầu vào duy nhất. Ngữ pháp cho hoạt động một chiều là:

<wsdl:definitions .... >  
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Yêu cầu ─ Phản hồi

Dịch vụ nhận một tin nhắn và gửi phản hồi. Do đó, hoạt động có một phần tử đầu vào, tiếp theo là một phần tử đầu ra. Để đóng gói lỗi, một phần tử lỗi tùy chọn cũng có thể được chỉ định. Ngữ pháp cho thao tác phản hồi yêu cầu là:

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Solicit ─ Hồi đáp

Dịch vụ gửi tin nhắn và nhận phản hồi. Do đó, hoạt động có một phần tử đầu ra, tiếp theo là một phần tử đầu vào. Để đóng gói lỗi, một phần tử lỗi tùy chọn cũng có thể được chỉ định. Ngữ pháp cho thao tác phản hồi gợi ý là:

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Thông báo

Dịch vụ sẽ gửi một tin nhắn. Do đó, hoạt động có một phần tử đầu ra duy nhất. Sau đây là ngữ pháp cho thao tác thông báo:

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

WSDL ─ Ràng buộc & Dịch vụ

Các <binding>phần tử cung cấp chi tiết cụ thể về cách một hoạt động portType thực sự sẽ được truyền qua dây.

  • Các liên kết có thể được cung cấp thông qua nhiều phương tiện truyền tải bao gồm HTTP GET, HTTP POST hoặc SOAP.

  • Các ràng buộc cung cấp thông tin cụ thể về giao thức nào đang được sử dụng để chuyển các hoạt động của portType.

  • Các ràng buộc cung cấp thông tin nơi đặt dịch vụ.

  • Đối với giao thức SOAP, ràng buộc là <soap: binding> và truyền tải là các thông báo SOAP trên giao thức HTTP.

  • Bạn có thể chỉ định nhiều ràng buộc cho một portType.

Dịch vụ

Các <service>phần tử xác định các cổng được hỗ trợ bởi dịch vụ web. Đối với mỗi giao thức được hỗ trợ, có một phần tử cổng. Phần tử dịch vụ là một tập hợp các cổng.

Máy khách dịch vụ web có thể tìm hiểu những điều sau từ phần tử dịch vụ:

  • Nơi truy cập dịch vụ,
  • Thông qua cổng nào để truy cập dịch vụ web và
  • Các thông điệp truyền thông được xác định như thế nào.

Phần tử dịch vụ bao gồm phần tử tài liệu để cung cấp tài liệu mà con người có thể đọc được.

<wsdl:service name = "CurrencyConvertor">
   <wsdl:port name = "CurrencyConvertorSoap" binding = "tns:CurrencyConvertorSoap">
      <soap:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorSoap12"binding = "tns:CurrencyConvertorSoap12>
      <soap12:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorHttpGet" binding = "tns:CurrencyConvertorHttpGet">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:portname = "CurrencyConvertorHttpPost"binding = "tns:CurrencyConvertorHttpPost">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port> 
</wsdl:service>

Dự án SoapUI là điểm trung tâm trong tất cả các thử nghiệm SoapUI. Sau khi dự án được tạo, người dùng có thể tạo và chạy các thử nghiệm chức năng, thử nghiệm tải, tạo dịch vụ giả và hơn thế nữa.

Trong chương này, chúng ta sẽ thảo luận về hai điều - Làm thế nào để -

  • Tạo một dự án SOAP
  • Thêm WSDL

Tạo một dự án SOAP

Step 1 - Trong trình điều hướng ở bên trái màn hình, nhấp chuột phải vào “Dự án” và chọn “Dự án SOAP mới”.

Hoặc vào File và chọn New Soap Project.

Khi được chọn, một cửa sổ bật lên mới sẽ mở ra - Dự án xà phòng mới.

Step 2 - Project Name: Nhập tên dự án - đó là trường nhập của người dùng. Initial WSDL: Nó không phải là bắt buộc. Nó phụ thuộc vào người dùng. Người dùng có thể cung cấp WSDL hoặc thêm sau khi tạo Dự án.

Trong trường hợp này, chúng tôi tạo một dự án và thêm WSDL sau.

Step 3- Bấm OK. Nó sẽ tạo một dự án mới và sẽ hiển thị trên bảng điều hướng bên trái.

Thêm WSDL

Dự án SOAP dựa trên WSDL. Không cần thiết phải bắt đầu bằng cách nhập WSDL, nhưng nó giúp việc kiểm tra dễ dàng hơn vì WSDL chứa tất cả thông tin cần thiết để kiểm tra một dịch vụ web như thông tin về các yêu cầu và phản hồi, những gì chúng chứa và hơn thế nữa, điều này giúp đơn giản hóa việc kiểm tra SoapUI.

Step 1 - Để thêm WSDL, nhấp chuột phải vào tên Dự án (SOAP - Ví dụ) và chọn Thêm WSDL.

Khi chọn, trình hướng dẫn WSDL được hiển thị.

Step 2 - WSDL Location: Nhập WSDL dưới dạng http://www.webservicex.com hoặc duyệt nó từ máy tính.

Step 3- Ngay sau khi WSDL được nhập, 3 hộp kiểm - Tạo Yêu cầu, Tạo TestSuite, Tạo MockServices sẽ được bật. Dựa trên yêu cầu, người dùng có thể chọn một hoặc nhiều hộp kiểm.

Theo mặc định, hộp kiểm Tạo yêu cầu được chọn.

Step 4- Bấm OK. WSDL được thêm thành công trong Dự án. Nó có thể được xác minh bằng cách quan sát bảng điều hướng bên trái. Bên trong dự án, có nhiều hoạt động và các yêu cầu được thêm vào theo WSDL.

Xem chi tiết

Để biết thêm chi tiết của Dự án, nhấp đúp vào Tên Dự án, nó sẽ mở ra một cửa sổ mới với nhiều chi tiết khác nhau.

Trong tab Tổng quan, nhiều thông tin khác nhau được cung cấp như -

  • File Path - Nó hiển thị vị trí của xml dự án đã lưu.

  • Interface Summary - Tên giao diện và WSDL liên kết với nó.

  • Test Summary - Nó hiển thị các bộ thử nghiệm, các trường hợp thử nghiệm, các bước thử nghiệm, các xác nhận được thêm vào dự án.

Người dùng có thể nhấp đúp vào Tên giao diện để xem chi tiết giao diện. Nó sẽ mở ra một cửa sổ mới và hiển thị thông tin liên quan đến WSDL. Chúng rất hữu ích để duyệt và kiểm tra WSDL.

Trong tab Tổng quan, nó liệt kê các Định nghĩa WSDL, các phần Định nghĩa và Chi tiết hoạt động.

Tương tự, Service Endpoints liệt kê các chi tiết của các điểm cuối.

Trong tab Nội dung WSDL, tất cả các chi tiết của WSDL ở định dạng XML / lược đồ được cung cấp như trong ảnh chụp màn hình sau.

TestSuitelà một tập hợp các Test Case có thể được sử dụng để nhóm các test chức năng thành các đơn vị logic. Bất kỳ số lượng TestSuites nào cũng có thể được tạo bên trong dự án SoapUI để hỗ trợ các kịch bản thử nghiệm lớn.

Tạo TestSuite

Step 1 - Trong một dự án, nhấp chuột phải vào giao diện (bên cạnh tên dự án) và sau đó nhấp vào 'Tạo TestSuite'.

Ở đây, SOAP - Ví dụ là tên Dự án trong khi CurrencyConvertorSoap và CurrencyConvertorSoap12 là giao diện.

Step 2- Một trình hướng dẫn mới sẽ mở ra. Chọn các lựa chọn dựa trên yêu cầu.

Step 3 - Sau khi lựa chọn xong, bấm OK.

Step 4- Đánh dấu vào hộp chọn Generate LoadTest. Điều này sẽ tạo ra một LoadTest cho mỗi TestCase được tạo trong TestSuite này.

Step 5 - Nhập tên TestSuite vào trình hướng dẫn mới rồi bấm OK.

TestSuite đã tạo hiển thị trong bảng điều hướng như thể hiện trong ảnh chụp màn hình sau.

Step 6- Nhấp đúp vào Tên TestSuite, và cửa sổ TestSuite mở ra ở bảng bên phải. Vì không có TestCases nào được thêm vào, nó sẽ trống.

Các thuộc tính của TestSuite có thể được nhìn thấy ở cuối Bảng điều hướng. Các thuộc tính tùy chỉnh mới có thể được thêm vào ở cấp TestSuite.

TestCase là một tập hợp các Bước kiểm tra được tập hợp để kiểm tra một số khía cạnh cụ thể của (các) dịch vụ web. Người dùng có thể thêm n số TestCases vào TestSuite và thậm chí mô-đun hóa chúng để gọi lẫn nhau trong các tình huống thử nghiệm phức tạp.

Tạo TestCase

Step 1- Trong một TestSuite, người dùng có thể thêm nhiều trường hợp thử nghiệm. Nhấp chuột phải vào Bộ thử nghiệm và chọn “Trường hợp thử nghiệm mới”.

Step 2 - Nhập tên của TestCase và nhấp vào OK.

TestCase đã tạo hiện không có bước kiểm tra nào. TestCase được bổ sung với 0 TestSteps cho tất cả các loại thử nghiệm có sẵn. Sau khi các Bước kiểm tra được thêm vào, các số trong dấu ngoặc sẽ tự động thay đổi. TestStep chức năng sẽ chuyển sang 'Các bước kiểm tra' trong khi Bước kiểm tra hiệu suất sẽ chuyển sang 'Kiểm tra tải' và một Bước kiểm tra bảo mật sẽ chuyển sang 'Kiểm tra bảo mật'.

Step 3- Nhấp đúp vào Tên TestCase và cửa sổ TestCase mở ra ở bảng điều khiển bên tay phải. Vì không có Bước kiểm tra nào được thêm vào, nó sẽ trống như trong ảnh chụp màn hình sau.

TestSteps là "khối xây dựng" của các bài kiểm tra chức năng trong SoapUI. Chúng được thêm vào TestCase và được sử dụng để kiểm soát luồng thực thi và xác thực chức năng của (các) dịch vụ web sẽ được kiểm tra.

Chèn TestStep

Step 1- Nhấp chuột phải vào TestSteps. Thêm Bước và chọn một Bước kiểm tra thích hợp từ danh sách. Ví dụ: nếu người dùng phải kiểm tra REST WebService, người dùng sẽ chọn Yêu cầu kiểm tra REST.

Step 2 - Thêm TestStep để xác thực yêu cầu SOAP đã nhập bằng cách chọn TestSteps → Add Step → SOAP Request.

Step 3 - Nhập tên của TestStep và nhấp vào OK trong trình hướng dẫn.

Khi nhấp vào 'OK', một hộp thoại bật lên để chọn thao tác sẽ gọi. Tất cả các thao tác được liệt kê và người dùng có thể chọn thao tác mà họ muốn gọi.

Có hai hoạt động sẽ được liệt kê. Cả hai Hoạt động đều giống nhau ngoại trừ phiên bản SOAP được sử dụng.CurrencyConvertorSoap sử dụng SOAP phiên bản 1.1 trong khi, CurrencyConvertorSoap12 sử dụng phiên bản SOAP 1.2.

Step 4 - Chọn cái đầu tiên - CurrencyConvertorSoap và bấm OK.

Trong khi thêm TestCase, có thể thêm các xác nhận tiêu chuẩn khác nhau. Các xác nhận cũng được gọi là các điểm kiểm tra / điểm xác nhận của yêu cầu / phản hồi SOAP.

Step 5 - Hãy để chúng tôi tạo TestCase với tùy chọn mặc định có nghĩa là tạo TestStep KHÔNG có bất kỳ điểm xác thực nào sau đây -

  • Xác minh xem thông báo phản hồi có phải là SOAP hay không khi thực hiện kiểm tra.
  • Xác minh xem giản đồ phản hồi có hợp lệ không.
  • Xác minh xem phản hồi SOAP có chứa FAULT không.

Step 6 - Khi nhấp vào OK, ảnh chụp màn hình XML yêu cầu sau sẽ bật lên.

Số bước kiểm tra hiện được tăng lên thành một khi một TestStep chức năng được thêm vào. Tương tự, khi thêm các TestSteps tải và bảo mật, số tương ứng sẽ tự động tăng lên dựa trên số bước được thêm vào.

Yêu cầu thiết lập

Tại đây, chúng ta sẽ thực hiện chuyển đổi đơn vị tiền tệ từ INR sang USD.

  • Từ Tiền tệ - INR
  • ToCurrency - USD

Tiếp theo, nhập các đầu vào này vào vị trí của dấu hỏi sẽ được gửi dưới dạng XML yêu cầu. Sau khi đặt các giá trị đó vào các thẻ XML tương ứng, hãy nhấp vào nút 'Gửi yêu cầu' để kiểm tra phản hồi.

Phản ứng

Sau khi gửi yêu cầu, yêu cầu dịch vụ web được máy chủ web xử lý và gửi lại phản hồi như thể hiện trong ảnh chụp màn hình sau.

Bằng cách đọc câu trả lời, có thể kết luận rằng 1 đơn vị INR = 0,0147 đơn vị USD.

Yêu cầu HTTP

Các bản tin SOAP được vận chuyển bằng giao thức HTTP. Để xem yêu cầu HTTP, hãy nhấp vào RAW tại cửa sổ Yêu cầu SoapUI (bên trái).

Yêu cầu được đăng lên máy chủ web. Do đó, phương thức POST của Http được sử dụng.

Yêu cầu SOAP được chuyển trong phần nội dung của bản tin http, được hiển thị như sau.

POST http://www.webservicex.com/currencyconvertor.asmx HTTP/1.1 
Accept-Encoding: gzip,deflate 
Content-Type: text/xml;charset = UTF-8 
SOAPAction: "http://www.webserviceX.NET/ConversionRate" 
Content-Length: 353 
Host: www.webservicex.com 
Connection: Keep-Alive 
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

Phản hồi HTTP

Nhấp vào Tab 'RAW' trong Cửa sổ phản hồi SOAP-UI để hiểu cách phản hồi được gửi qua HTTP.

Sau khi xử lý yêu cầu, mã phản hồi http (200) được hiển thị có nghĩa là nó đã thành công. Máy chủ web đã xử lý nó thành công.

Phản hồi SOAP được gửi trở lại máy khách như một phần của nội dung thông báo HTTP.

HTTP/1.1 200 OK 
Cache-Control: private, max-age = 0 
Content-Type: text/xml; charset = utf-8 
Content-Encoding: gzip 
Vary: Accept-Encoding 
Server: Microsoft-IIS/7.0 
X-AspNet-Version: 4.0.30319 
X-Powered-By: ASP.NET 
Date: Sun, 22 Jan 2017 19:39:31 GMT 
Content-Length: 316

Các mã HTTP sau được sử dụng để gửi phản hồi bởi máy chủ Web và rất hữu ích để gỡ lỗi.

Mã HTTP Sự miêu tả

1xx:

Informational - Điều này có nghĩa là một yêu cầu đã được nhận và có một quá trình tiếp tục.

2xx:

Success - Hành động đã được tiếp nhận, hiểu và chấp nhận thành công.

3xx:

Redirection - Điều này có nghĩa là phải thực hiện thêm hành động để hoàn thành yêu cầu.

4xx:

Client Error - Điều này có nghĩa là yêu cầu chứa cú pháp sai hoặc không thể thực hiện được.

5xx:

Server Error - Máy chủ không thực hiện được yêu cầu hợp lệ.

Thuộc tính là một khía cạnh trung tâm của thử nghiệm nâng cao hơn với SoapUI. Các thuộc tính Kiểm thử chức năng được sử dụng để tham số hóa việc thực thi và chức năng của các thử nghiệm.

  • Các thuộc tính có thể được sử dụng để giữ các điểm cuối của dịch vụ, giúp dễ dàng thay đổi các điểm cuối thực tế được sử dụng trong quá trình thực thi thử nghiệm.

  • Các thuộc tính có thể được sử dụng để lưu giữ thông tin xác thực, giúp dễ dàng quản lý các thông tin này ở vị trí trung tâm hoặc tệp bên ngoài.

  • Các thuộc tính có thể được sử dụng để chuyển và chia sẻ id phiên trong quá trình thực thi thử nghiệm, vì vậy nhiều bước thử nghiệm hoặc trường hợp thử nghiệm có thể chia sẻ các phiên giống nhau.

Xác định thuộc tính

Các thuộc tính có thể được xác định ở nhiều cấp độ trong một dự án.

  • Các thuộc tính phổ biến ở cấp độ dự án có thể được xác định ở cấp độ Dự án.

  • Tương tự, các thuộc tính cụ thể của TestSuite và TestCase có thể được xác định ở các cấp độ tương ứng của chúng.

  • Thuộc tính cụ thể của dự án được xác định trong tab Thuộc tính tùy chỉnh.

Ví dụ: một thuộc tính “ToCurrency” có thể được xác định ở cấp Dự án bằng cách nhấp vào biểu tượng "+" và nhập Tên và Giá trị thuộc tính.

Truy cập tài sản

Một thuộc tính có thể được truy cập ở bất kỳ đâu trong Dự án bằng cách sử dụng Mở rộng Thuộc tính.

Cấu trúc sẽ là -

  • $ {# Project # PropertyName} - Dành cho cấp độ dự án

  • $ {# TestSuite # PropertyName} - Đối với cấp Test Suite

  • $ {# TestCase # PropertyName} - Đối với cấp độ Test Case

  • $ {TestStepName # PropertyName} - Đối với cấp độ Bước kiểm tra

  • $ {# MockService # PropertyName} - Đối với thuộc tính MockService

  • $ {# Global # PropertyName} - Đối với thuộc tính Toàn cục, được tìm thấy trong tab Tệp → Tùy chọn → Thuộc tính chung. Thuộc tính này có thể được sử dụng trên tất cả các dự án

  • $ {# System # PropertyName} - Đối với Thuộc tính Hệ thống, được tìm thấy trong Trợ giúp → Thuộc tính hệ thống

  • $ {# Env # PropertyName} - Đối với biến môi trường

Cấu trúc tương tự có thể được đặt tại Request XML để nhận giá trị của thuộc tính cụ thể trong thời gian chạy.

Một thuộc tính cũng có thể được coi là một biến trong chương trình máy tính. Nếu người dùng muốn xác định một thứ gì đó cũng có thể được sử dụng ở một nơi khác, thì Thuộc tính rất hữu ích. Các thuộc tính cũng có thể định nghĩa động nhưng nó phụ thuộc vào tập lệnh Groovy.

Đôi khi có yêu cầu trích xuất một số giá trị từ một thông báo phản hồi và đưa nó vào (các) yêu cầu tiếp theo. Trong trường hợp như vậy, chúng ta cần có một cơ chế để lấy ra một giá trị xác định và chuyển nó cho các phần tử khác của dự án. SoapUI hỗ trợ chức năng như vậy thông qua Bước kiểm tra chuyển thuộc tính.

Thêm chuyển tài sản

Step 1 - Chọn TestCase hoặc TestStep, nhấp chuột phải → Thêm bước → Chuyển thuộc tính.

Step 2 - Nhập tên TestStep và Click OK.

Step 3 - Bước RateTransfer được thêm vào và một trình hướng dẫn mới sẽ mở ra.

Step 4- Nhấp vào biểu tượng Thêm thuộc tính mới chuyển + ở góc trên cùng bên trái trong cửa sổ chuyển thuộc tính. Nó sẽ được nhắc nhập tên để chuyển. Nhập Tỷ lệ và nhấp vào OK.

Chuyển giao tài sản

Sau khi chuyển khoản được tạo, SourceTarget panescần chỉ định các biểu thức XPath có liên quan để trích xuất và thay thế các giá trị thuộc tính. Trong hộp thả xuống bên cạnh Nguồn, các mức khác nhau của dự án SoapUI được liệt kê có thể được sử dụng làm nguồn chuyển tài sản. Theo mặc định, TestStep gần nhất sẽ được hiển thị.

Trong trường hợp này, nó là Request – INR to USDBước kiểm tra. Danh sách thả xuống bên cạnh Thuộc tính hiển thị thuộc tính nguồn được sử dụng trong quá trình chuyển, có thể là yêu cầu, phản hồi hoặc điểm cuối dịch vụ.

Step 1- Chọn Phản hồi và chuyển đến Ngôn ngữ đường dẫn. Người dùng có thể chọn XPath, Xquery hoặc Jason để xác định thuộc tính. Trong trường hợp này, hãy chọn XPath.

Step 2 - Để lấy phần khai báo của source xml, nhấp vào ns và chỉ định XPath.

Step 3- Chỉ định mục tiêu mà giá trị trích xuất từ ​​biểu thức XPath ở trên sẽ được chuyển. Ngăn đích được sử dụng ở cuối cửa sổ chuyển thuộc tính cho điều đó.

Step 4 - Chuyển giá trị trích xuất của ConversionRateResult từ phản hồi của bước RequestINRtoUSD.

Target - Thuộc tính

Property - ConversionRate (một thuộc tính mới được thêm vào, ban đầu nó không có bất kỳ giá trị nào).

Step 5 - Sau khi trường hợp thử nghiệm chạy thành công, thuộc tính “ConversionRate” sẽ được cập nhật dựa trên phản hồi.

Sau đây là ảnh chụp màn hình ban đầu.

Sau đây là ảnh chụp màn hình sau khi chạy thành công.

Tương tự, Target có thể là một XML yêu cầu tiếp theo. Nếu Target là yêu cầu SOAP, chúng ta cần cung cấp XPath để xác định thuộc tính đích.

Ngăn nhật ký lưu trữ thông tin đầy đủ về giao dịch giữa máy khách và máy chủ. Người dùng sẽ có thể xem các tab khác nhau của ngăn nhật ký. Chúng ta sẽ thảo luận về các ngăn nhật ký được sử dụng phổ biến nhất khi làm việc với SoapUI trong chương này.

Nhật ký SoapUI

Nhật ký SoapUI hiển thị thông tin phản hồi từ máy chủ web. Thông tin tương tự được lưu trữ trong tệp soapui.log của thư mục cài đặt SOAP-UI trong thư mục 'bin'.

Nhật ký HTTP

Nhật ký HTTP hiển thị tất cả quá trình chuyển gói HTTP. Tất cả thông tin trong 'RAW' được hiển thị trong nhật ký HTTP.

Nhật ký lỗi

Nhật ký lỗi hiển thị tất cả các lỗi gặp phải trong toàn bộ phiên dự án. Thông tin tương tự có sẵn trong 'soapui-error.log' có trong thư mục 'bin' của vị trí đã cài đặt SoapUI.

Nhật ký bộ nhớ

Tab này giám sát mức tiêu thụ bộ nhớ và hiển thị nó ở dạng biểu đồ như trong ảnh chụp màn hình sau. Nó thực sự hữu ích khi một hoạt động đòi hỏi nhiều bộ nhớ được thực hiện.

Khẳng định có thể được hiểu là một điểm kiểm tra hoặc một điểm xác nhận. Khi một yêu cầu được gửi đến một máy chủ web, một phản hồi sẽ được nhận. Cần phải xác thực phản hồi có chứa dữ liệu như mong đợi hay không. Để xác nhận phản hồi, SoapUI có một tính năng xác nhận.

Điểm cần lưu ý

  • Các xác nhận được sử dụng để xác thực thông điệp mà TestStep nhận được trong quá trình thực thi.

  • Nó so sánh một phần của thông báo hoặc toàn bộ thông báo với một số giá trị mong đợi.

  • Bất kỳ số lượng xác nhận nào cũng có thể được thêm vào TestStep, mỗi xác nhận xác nhận một số khía cạnh và nội dung khác nhau của thông báo phản hồi.

  • Sau khi TestStep thực thi, tất cả các xác nhận của nó được áp dụng cho phản hồi đã nhận và nếu bất kỳ phản hồi nào không thành công thì TestStep được đánh dấu là không thành công trong dạng xem TestCase.

  • Mục nhập không thành công hiển thị trong nhật ký thực thi thử nghiệm.

Loại khẳng định

SoapUI hỗ trợ một loạt các xác nhận để đáp ứng.

Sau đây là danh sách các xác nhận được hỗ trợ bởi SoapUI.

Quả quyết Sự miêu tả
Property Content
Chứa đựng Kiểm tra sự tồn tại của chuỗi được chỉ định. Nó cũng hỗ trợ biểu thức chính quy.
Không chứa Kiểm tra sự không tồn tại của chuỗi được chỉ định. Nó cũng hỗ trợ biểu thức chính quy.
Kết hợp XPath Sử dụng biểu thức XPath để chọn nút đích và các giá trị của nó. So sánh kết quả của một biểu thức XPath với một giá trị mong đợi.
Kết hợp XQuery Sử dụng biểu thức Xquery để chọn nội dung từ thuộc tính đích. So sánh kết quả của một biểu thức XQuery với một giá trị mong đợi.
Compliance, Status, Standards
HTTP DOwnload All Resource Tải xuống tất cả các tài nguyên được gọi là tài liệu HTML (hình ảnh, tập lệnh, v.v.) và xác nhận rằng tất cả chúng đều có sẵn. Áp dụng cho bất kỳ thuộc tính nào có chứa HTML.
Mã trạng thái HTTP không hợp lệ Kiểm tra xem TestStep đích có nhận được kết quả HTTP với mã trạng thái không trong danh sách các mã đã xác định hay không. Có thể áp dụng cho bất kỳ TestStep nào nhận thông báo HTTP.
Không phải lỗi SOAP Xác nhận rằng tin nhắn nhận được cuối cùng không phải là Lỗi SOAP. Áp dụng cho các Bước kiểm tra SOAP.
Tuân thủ giản đồ Xác thực rằng thông báo nhận được cuối cùng tuân thủ với định nghĩa lược đồ WSDL hoặc WADL được liên kết. Áp dụng cho các bước kiểm tra SOAP và REST. URL định nghĩa lược đồ hỗ trợ Mở rộng thuộc tính (ví dụ: $ {# System # my.wsdl.endpoint} / services / PortType? Wsdl).
Lỗi SOAP Xác thực rằng tin nhắn nhận được cuối cùng là Lỗi SOAP. Áp dụng cho SOAP TestSteps Yêu cầu SOAP - xác nhận rằng yêu cầu nhận được cuối cùng là Yêu cầu SOAP hợp lệ. Chỉ áp dụng cho các Bước kiểm tra MockResponse.
Phản hồi SOAP Xác nhận rằng phản hồi nhận được cuối cùng là Phản hồi SOAP hợp lệ. Chỉ áp dụng cho các Bước TestRequest SOAP.
Mã trạng thái HTTP hợp lệ Kiểm tra xem TestStep mục tiêu có nhận được kết quả HTTP với mã trạng thái trong danh sách các mã đã xác định hay không. Có thể áp dụng cho bất kỳ TestStep nào nhận thông báo HTTP.
Yêu cầu địa chỉ WS Xác thực rằng yêu cầu nhận được cuối cùng có chứa các tiêu đề định địa chỉ WS hợp lệ. Chỉ áp dụng cho MockResponse TestSteps.
Phản hồi địa chỉ WS Xác thực rằng phản hồi nhận được cuối cùng có chứa Tiêu đề định địa chỉ WS hợp lệ. Chỉ áp dụng cho các Bước TestRequest SOAP.
Trạng thái bảo mật WS Xác thực rằng thư nhận được cuối cùng có chứa các tiêu đề WS-Security hợp lệ. Áp dụng cho các bước kiểm tra SOAP.
Script
Xác nhận tập lệnh Cho phép người dùng thực thi tập lệnh tùy chỉnh để thực hiện xác thực do người dùng xác định. Chỉ áp dụng cho TestSteps (tức là không phải thuộc tính)
SLA
SLA phản hồi Xác thực nếu thời gian phản hồi của phản hồi nhận được cuối cùng nằm trong giới hạn đã xác định. Áp dụng cho các Bước kiểm tra tập lệnh và Bước kiểm tra gửi yêu cầu và nhận phản hồi.
JMS
Trạng thái JMS Xác nhận rằng yêu cầu JMS của TestStep đích được thực thi thành công. Áp dụng cho Yêu cầu các Bước kiểm tra với điểm cuối JMS.
Thời gian chờ JMS Xác nhận rằng câu lệnh JMS của TestStep mục tiêu không kéo dài hơn thời lượng đã chỉ định. Áp dụng cho Yêu cầu các Bước kiểm tra với điểm cuối JMS.
Security
Tiếp xúc thông tin nhạy cảm Xác minh xem thông báo phản hồi không tiết lộ thông tin nhạy cảm về hệ thống đích. Chúng tôi có thể sử dụng xác nhận này cho các Bước kiểm tra REST, SOAP và HTTP.
JDBC
Trạng thái JDBC Xác thực rằng yêu cầu JDBC của TestStep đích đã thực thi thành công. Chỉ áp dụng cho JDBC TestSteps.
Thời gian chờ của JDBC Xác thực rằng câu lệnh JDBC của TestStep mục tiêu không mất nhiều thời gian hơn thời lượng được chỉ định. Chỉ áp dụng cho JDBC TestSteps.

Trong SoapUI, người dùng phải đối mặt với nhiều vấn đề chung chung có thể được giải quyết với một chút cảnh giác. Một số vấn đề phổ biến nhất sau đây là:

Issue- Không gian tên được định nghĩa sai. Sử dụng không gian tên chính xác. Không gian tên phải là URL nơi đặt dịch vụ web.

Solution - Nếu lỗi xảy ra trong khi phát triển một xác nhận kịch bản, hãy sử dụng 'log.info' để in nội dung của các biến.

Issue - Nếu mã lỗi được nhận dưới dạng XML phản hồi, thì có thể do đầu vào không hợp lệ.

Solution - Xác minh đầu vào của XML yêu cầu.

Example - Trong trình chuyển đổi tiền tệ, nếu đầu vào của 'FromCurrency' là '123' không tồn tại, thì đầu ra sẽ ném mã lỗi là 'SOAP-Client', có nghĩa là sự cố xảy ra với tham số đang được chuyển từ phía khách hàng.

Yêu cầu

Phản ứng

Issue - Không phù hợp với phản hồi hiện tại khi sử dụng XPath hoặc XQuery.

Solution -

  • Sử dụng cú pháp đúng trong khi xác định XPath hoặc XQuery.
  • Xác minh dấu hai chấm được sử dụng và không dấu chấm trong khi khai báo không gian tên.
  • Đảm bảo rằng XPath và XQuery là chính xác.

Kiểm tra hiệu suất là một trong những điểm kiểm tra quan trọng phổ biến nhất trong kiểm tra Dịch vụ Web. Kiểm tra hiệu suất được định nghĩa là tạo hoặc mô phỏng tải một cách giả tạo và đo lường cách môi trường xử lý nó.

Điều này có nghĩa là nó không nhất thiết phải là cách một hệ thống hoạt động dưới tải cao, nó cũng có thể là cách nó hoạt động dưới tải cơ bản hoặc tải dự kiến. Nó thậm chí không cần phải có cấu trúc, tự động hoặc được tạo trong TestWare như SoapUI; Đơn giản chỉ cần refresh trình duyệt web lặp đi lặp lại rất nhanh cũng là một Load Test.

Các loại kiểm tra hiệu suất

Sau đây là các loại Kiểm tra Hiệu suất -

  • Baseline Testing - Kiểm tra cách một hệ thống hoạt động dưới mức tải dự kiến ​​hoặc bình thường và tạo ra một đường cơ sở để so sánh các loại thử nghiệm khác.

  • Load Testing- Bao gồm việc tăng tải và xem cách hệ thống hoạt động dưới mức tải cao hơn. Trong quá trình Kiểm tra tải, người dùng có thể theo dõi thời gian phản hồi, thông lượng, tình trạng máy chủ và hơn thế nữa. Mục tiêu của Load Testing không phải là phá vỡ môi trường mục tiêu.

  • Soak Testing - Mục tiêu của thử nghiệm là đảm bảo không có hành vi không mong muốn nào xuất hiện trong một khoảng thời gian dài hơn.

  • Scalability Testing- Kiểm thử khả năng mở rộng rất giống với Kiểm thử tải, tuy nhiên thay vì tăng số lượng yêu cầu, nó làm tăng kích thước hoặc độ phức tạp của các yêu cầu được gửi. Ví dụ: gửi yêu cầu lớn, tệp đính kèm lớn hoặc yêu cầu lồng nhau sâu.

Các khía cạnh chính trong dịch vụ web

Hai khía cạnh nổi bật trong các đặc điểm độc đáo của hiệu suất Dịch vụ Web.

Khía cạnh đầu tiên

Về phía máy chủ, quá trình xử lý XML / JSON đang diễn ra, cả phân tích cú pháp XML / JSON và tuần tự hóa . Điều thường thất bại đầu tiên là việc xử lý các tải trọng. Lý do của sự thất bại có thể gấp nhiều lần; nó có thể là trong nền tảng, các điểm yếu của máy chủ ứng dụng hoặc nó có thể là một vấn đề triển khai dưới dạng các WSDL phức tạp không cần thiết. Nó cũng có thể có nghĩa là mã đang thực hiện yêu cầu đối với cơ sở dữ liệu chậm phản hồi.

Testing Aspect- Sự phức tạp của việc phân tích cú pháp tải trọng XML / JSON có nghĩa là cần phải tập trung nhiều hơn vào Kiểm tra khả năng mở rộng. Điều đó cũng có nghĩa là các WSDL cần được kiểm tra chặt chẽ. Nếu các yêu cầu và phản hồi phức tạp hoặc lớn hơn hoặc nếu chúng bao gồm các tệp đính kèm lớn, thì nên tập trung vào việc nhấn mạnh sự phức tạp và xem cách nó hoạt động khi tải.

Khía cạnh thứ hai

Một yếu tố khác thường xuyên gặp phải là bảo mật. Các trang web bảo mật đằng sau HTTPS có hiệu suất thấp hơn đáng kể và trong thử nghiệm Dịch vụ web, chúng tôi có thể thêm một lớp WSSecurity vào lớp bảo mật HTTP, làm giảm hiệu suất nhiều hơn.

Testing Aspect- Vấn đề phương tiện bảo mật, cần tập trung thực hiện thử nghiệm các yêu cầu đã được bảo mật. Nếu toàn bộ Dịch vụ Web được bảo mật, điều đó có nghĩa là Kiểm tra tải quan trọng hơn, đặc biệt nếu sử dụng WS-Security và xử lý mã thông báo.

Load testinglà một hình thức kiểm tra hiệu suất cụ thể được tiến hành để đánh giá hành vi của hệ thống dưới một tải cụ thể. Trong SoapUI, chúng tôi thường sử dụng thuật ngữ "thử nghiệm tải" cho tất cả các loại thử nghiệm phi chức năng, tuy nhiên SoapUI hỗ trợ tất cả các loại đánh giá hiệu suất của các dịch vụ web như tải, căng thẳng và độ bền.

Điểm cần lưu ý

  • Kiểm tra tải khá độc đáo trong SoapUI; một trường hợp kiểm thử chức năng cho phép tạo và sửa đổi các bài kiểm tra hiệu suất một cách nhanh chóng.

  • Điểm khác biệt chính là các bài kiểm tra hiệu suất trong SoapUI thường được tạo ra từ các bài kiểm tra chức năng hiện có. Điều này cho phép nhanh chóng tạo các bài kiểm tra hiệu suất nâng cao.

  • Hiệu suất Dịch vụ Web có thể được xác nhận trong các tình huống tải khác nhau. Duy trì xác thực chức năng để thấy rằng chúng không bị hỏng khi tải, chạy một số thử nghiệm tải đồng thời để xem chúng ảnh hưởng đến nhau như thế nào và hơn thế nữa.

Tạo thử nghiệm tải

Step 1 - Nhấp chuột phải vào Function Test Case và chọn New Load Test.

Step 2 - Nhập tên của Load Test và nhấp OK trong trình hướng dẫn hộp thoại.

Load Test sẽ mở ra và Load Test được tạo như trong ảnh chụp màn hình sau.

Thực hiện kiểm tra tải

Khi một Thử nghiệm tải mới được tạo, nó được định cấu hình sẵn để chạy trong 60 giây (trên cùng bên phải) với 5 luồng bằng chiến lược Tải đơn giản.

Sửa đổi các giá trị này theo yêu cầu và Chạy. Note - Người dùng nên biết về cấu hình và khái niệm Load Testing.

Người dùng sẽ thấy bảng thống kê ở giữa, bắt đầu bằng việc thu thập dữ liệu và sau 60 giây sẽ có một LoadTest hoàn thành.

Thêm một xác nhận

Step 1 - Trong trình soạn thảo LoadTest, chọn tab LoadTest Assertion ở cuối trình soạn thảo.

Step 2 - Nhấp vào nút Add Assertion trong thanh menu LoadTest Assertion để thêm một xác nhận.

Step 3- Hộp thoại Add Assertion sẽ mở ra. Chọn Bước Tối đa. Chọn Tối đa đặt Thời gian tối đa tính bằng mili giây mà phản hồi được phép thực hiện, nếu thời gian vượt quá thời gian chúng tôi đã đặt, kiểm tra sẽ không thành công. Bấm OK.

Step 4- Cửa sổ TestStep Max Assertion sẽ mở ra. Như đã thấy trong ảnh chụp màn hình sau, chúng tôi cho phép phản hồi tối đa là một giây, 1000 mili giây. Đừng sửa đổi bất cứ điều gì. Nhấp vào Ok.

Xác nhận Bước Tối đa bây giờ sẽ được thêm thành công.

Step 5- Bây giờ chạy thử nghiệm lại. Nếu các câu trả lời mất quá nhiều thời gian, bạn sẽ thấy các số trong cột lỗi sẽ được cộng lại nhanh chóng.

Dịch vụ web là một tập hợp các giao thức và tiêu chuẩn mở được sử dụng để trao đổi dữ liệu giữa các ứng dụng hoặc hệ thống. Các ứng dụng phần mềm được viết bằng nhiều ngôn ngữ lập trình khác nhau và chạy trên nhiều nền tảng khác nhau có thể sử dụng các dịch vụ web để trao đổi dữ liệu qua các mạng máy tính như Internet theo cách tương tự như giao tiếp giữa các quá trình trên một máy tính. Khả năng tương tác này (ví dụ: giữa Java và Python, hoặc các ứng dụng Windows và Linux) là do việc sử dụng các tiêu chuẩn mở.

Các dịch vụ web dựa trên Kiến trúc REST được gọi là Dịch vụ Web RESTful. Các dịch vụ web này sử dụng các phương thức HTTP để triển khai khái niệm kiến ​​trúc REST. Dịch vụ web RESTful thường xác định URI (Định danh tài nguyên đồng nhất), là dịch vụ cung cấp biểu diễn tài nguyên như JSON và một tập hợp các phương thức HTTP.

Tất cả các khả năng kiểm tra REST của SoapUI đều dựa trên một biểu diễn logic được gọi là dịch vụ REST. Chúng ta không nên nhầm lẫn điều này với thuật ngữ "dịch vụ" ở đây, vì nó không phải là một triển khai dịch vụ mà là một ánh xạ của dịch vụ RESTful đang được gọi. Chúng tôi có thể thêm nhiều Dịch vụ REST nhất có thể vào một dự án SoapUI. Mỗi dịch vụ đại diện cho một dịch vụ RESTful cụ thể. Chúng như sau:

  • REST - Thiết lập dự án

  • REST - WADL

  • REST - Yêu cầu

  • REST - Phản hồi

  • REST - Phương thức HTTP

SoapUI cho phép quản lý hoạt động cơ sở dữ liệu bằng cách sử dụng TestStep được gọi là Yêu cầu JDBC.

Step 1 - Nhấp chuột phải vào TestStep và chọn Thêm Bước → Yêu cầu JDBC.

Step 2 - Nhập tên bước và nhấn OK.

Bước JDBC được thêm vào. Bấm đúp vào bước và trình hướng dẫn JDBC sẽ mở ra.

Để tạo kết nối JDBC, người dùng cần cung cấp Trình điều khiển và Chuỗi kết nối hợp lệ. Các tham số này được sử dụng để xác định loại cơ sở dữ liệu và tạo kết nối để sử dụng cơ sở dữ liệu.

Đối với MySQL, trình điều khiển cơ sở dữ liệu có thể com.mysql.jdbc.Driver. Tương tự, đối với cơ sở dữ liệu khác, có một trình điều khiển được xác định trước có thể được tìm thấy trong phần tài liệu của cơ sở dữ liệu.

Step 3 - Chuỗi kết nối phải ở định dạng sau -

Jdbc:mysql://[host]:[port]/[database]?[property][=value]

Ở đây, thuộc tính là tên người dùng và mật khẩu cùng với các thông số khác cần thiết để kết nối với cơ sở dữ liệu.

Ví dụ,

jdbc:mysql://localhost:8089/xxx_DB?user=root&password=root

Step 4- Nhấp vào Kiểm tra kết nối. Khi kết nối thành công, nó sẽ hiển thị SUCCESS, nếu không, hãy cung cấp thông tin chi tiết về lỗi.

JDBC có phần thuộc tính Thêm riêng có thể được sử dụng như một biến trong Truy vấn SQL.

Hãy xem nó hoạt động như thế nào -

Giả sử, Truy vấn SQL cần thực hiện trong bước JDBC là Chọn * từ Tiền tệ trong đó CurrencyCode = 'xxx'.

Trong trường hợp này, Mã tiền tệ có thể được thay đổi dựa trên yêu cầu đầu vào. Nếu người dùng cung cấp một giá trị được mã hóa cứng, bước JDBC sẽ không thực thi đối với những đơn vị tiền tệ được cung cấp theo yêu cầu.

Để vượt qua các tình huống như vậy, JDBC hỗ trợ thuộc tính thêm, nơi Mã thuộc tính có thể được xác định và nó sẽ tiếp tục thay đổi bằng cách sử dụng Bước chuyển thuộc tính.

Truy vấn SQL sẽ chạy dựa trên giá trị hiện tại của Mã thuộc tính và Truy vấn SQL sẽ tham số hóa mã CurrencyCode =:.

Nhấp vào Thêm thuộc tính + và tên là Mã và cung cấp giá trị hoặc để trống để sử dụng bước Chuyển thuộc tính để cung cấp.

Yêu cầu JDBC cũng có thể sử dụng hầu hết các xác nhận với các Bước kiểm tra yêu cầu SOAP. Trong SoapUI, hầu hết các xác nhận này độc lập với TestSteps. Do đó, các xác nhận như Chứa và Khớp XPath có thể được sử dụng với JDBC Request TestStep.

Bằng cách nhấp vào Add an assertion ở menu trên cùng của JDBC Request TestStep, người dùng có thể tìm hiểu những xác nhận nào được TestStep hỗ trợ.

Ngoài các xác nhận chung chung, có hai xác nhận cụ thể của JDBC Request TestStep -

JDBC Timeout - Xác nhận này có thể được sử dụng để xác minh xem truy vấn SQL hiện tại có được thực thi trong giá trị thuộc tính Thời gian chờ truy vấn được chỉ định hay không.

JDBC Status - Để kiểm tra xem câu lệnh SQL có được thực thi thành công hay không, chúng ta có thể sử dụng xác nhận Trạng thái JDBC.

Để đặt Thời gian chờ truy vấn, hãy cung cấp giá trị tương ứng của Thời gian chờ truy vấn thuộc tính ở phía bên trái của màn hình. Xin lưu ý rằng nó chấp nhận giá trị tính bằng mili giây (mili giây).