Tran Thi Van @tranthivan1991

Đã đăng vào thg 2 23, 2017 7:00 SA 72 phút đọc

10.6K

Tìm hiểu về SOAPUI và thực hiện test Webservice

Bài đăng này đã không được cập nhật trong 7 năm

Nguồn: https://www.soapui.org/ https://viblo.asia/p/hoc-kiem-thu-api-trong-10-phut-6BAMYkjnvnjz

I. Kiểm thử API

1. Kiểm thử API là gì?

Để thảo luận thử nghiệm API, chúng ta cần biết API là gì và nó hoạt động như thế nào. API là một tập hợp các chức năng phần mềm, thủ tục có thể được sử dụng bởi các phần mềm khác. API được dùng để kết nối giữa các ứng dụng với nhau. Nó là lớp chuyên xử lý các thao tác của người dùng, nhận request từ người dùng, xử lý và gửi yêu cầu tới database, sau đó lấy dữ liệu từ database gửi ngược lại người dùng ở tầng giao diện. Ví dụ, website Google có thể có API cho các chức năng khác nhau như search, translate, calendar,... Một API có cấu trúc như sau: http://<servername>/v1/export/Publisher/Standard_Publisher_Report?format=csv API gồm nhiều phương thức, chủ yếu có 4 phương thức phổ biến sau: • GET: Truy xuất một tài nguyên, nhận dữ liệu từ server và hiển thị • POST: Tạo một tài nguyên trên server • PUT: Thay đổi trạng thái một tài nguyên hoặc cập nhật nó • DELETE: Huỷ bỏ hoặc xoá một tài nguyên Vậy kiểm thử API là: • Kiểm thử không cần giao diện (GUI). • Lập trình mô phỏng dữ liệu và điều khiển theo kịch bản. • Kiểm thử tập trung vào chức năng, không phụ thuộc vào hành vi hay kinh nghiệm của người dùng.
Tại sao kiểm thử API lại quan trọng? Kiểm thử API có những lợi thế đáng kể sau: • Ngăn ngừa sớm những lỗi có thể xảy ra ở ứng dụng Nếu một API có những lỗi không được phát hiện, nó có thể không chỉ phá huỷ một ứng dụng duy nhất mà có thể là cả một hệ thống. Ở tầng giao diện ứng dụng thường sẽ chặn những dữ liệu không hợp lệ, cho nên khi gửi đến server dữ liệu nhận được thường đã hợp lệ. Tuy nhiên, nếu dùng thủ thuật một số dữ liệu không hợp lệ vẫn có thể vượt qua kiểm soát của giao diện, đến khi lưu vào database sẽ làm sai những ràng buộc, có thể gây nên những lỗi nghiêm trọng cho hệ thống. Vì vậy kiểm thử API giúp kiểm tra lại một lần nữa, sàng lọc lại những dữ liệu không hợp lệ bị lọt lưới từ tầng giao diện. • Kiểm thử API đang trở thành loại kiểm thử rất phổ biến so với các kiểm thử khác. Theo dõi biều đồ bên dưới, có thể thấy kiểm thử API tăng lên rất nhanh trong 10 năm qua.

• Tiết kiệm thời gian Với kiểm thử API chúng ta có thể thực hiện song song để giảm thời gian kiểm thử. Do đó có thể tiết kiệm lên đến 5 lần so với các loại kiểm thử khác. • Ngôn ngữ độc lập Dữ liệu được trao đổi thông qua XML hoặc JSON và mọi ngôn ngữ đều có thể sử dụng. Ví dụ, khi nhận được một respone ở định dạng JSON thì bạn có thể dễ dàng phân tích dữ liệu với Java, Objective-C, C# hoặc bất kỳ ngôn ngữ nào. • Dễ dàng tích hợp Kiểm thử API yêu cầu một ứng dụng để tương tác với API. Để có thể kiểm thử một API, ban cần: • Sử dụng tool kiểm thử để điều khiển API • Viết các câu lệnh để kiểm thử API

2. Thiết lập môi trường kiểm thử API

• Kiểm thử API khác với các loại kiểm thử khác vì giao diện(GUI) chưa có, nên bạn buộc phải thiết lập môi trường khởi tạo mà gọi API với các tham số yêu cầu và sau đó kiểm tra kết quả trả về. • Vì vậy để thiết lập môi trường kiểm thử cho API là khá phức tạp. • Cơ sở dữ liệu và server nên được cấu hình như yêu cầu của ứng dụng. • Sau khi tất cả các thiết lập đã hoàn tất, Các API Function nên được gọi để kiểm tra xem API có hoạt động hay không  Các loại đầu ra của một API Đầu ra của API có thể là:

Bất kỳ kiểu dư liệu nào
Trạng thái(Pass hoặc Fail)
Gọi tới một hàm API khác Ví dụ: Đây là một hàm API cần phải nhập hai số nguyên Long add(int a, int b) Các số được nhập vào như là tham số đầu vào. Đầu ra nên là tổng của hai số nguyên. Đây là đầu ra cần phải kiểm tra với kết quả dự kiến. Cách gọi cần phải thực hiện là: add (1234, 5656) Ngoại lệ càn phải xử lý nếu số nhập vào vượt quá giới hạn của sô nguyên (integer) Trạng thái(Pass hoặc Fail) Xem xét các hàm API dưới đây:
Lock()
Unlock()
Delete() Chúng trả về bất kỳ giá trị như True (trong trường hợp thành công) hoặc False (trong trường hợp lỗi) như là đầu ra. Sẽ cần nhiều hơn một test case, có thể gọi các hàm trong các đoạn mã và sau đó kiểm tra các thay đổi trong cơ sở dữ liệu hoặc giao diện của ứng dụng. Gọi tới một hàm API/Event khác

Trong trường hợp này, chúng ta gọi một hàm API mà sẽ chuyển đến gọi một hàm khác. Ví dụ - Hàm API đầu tiên có thể sử dụng để xóa một bản ghi chỉ định trong một bảng và hàm này sẽ gọi một hàm khác để REFRESH cơ sở dữ liệu.

3. Các test case cho kiểm thử API:

Các test case cho kiểm thử API được dựa trên: • Dữ liệu trả về dựa trên điều kiện đầu vào: Điều này tương đối dễ dàng kiểm tra, như đầu vào có thể được xác định và kết quả có thể được xác thực. • Không trả về gì cả: Khi không có giá trị trả về, hành vị của API trên hệ thống có thể được kiểm tra • Kích hoạt một vài API/event/interrupt: Nếu đầu ra của một API kích hoạt các event hoặc interrupt, thì các listeners của event và interrupt nên đươc kiểm tra • Cập nhật cấu trúc dữ liệu: Cập nhật cấu trúc dữ liệu sẽ có một vài kết quả hoặc ảnh hưởng lên hệ thống, và chúng nên được kiểm tra • Chỉnh sửa các tài nguyên(resources) nhất định: Nếu API gọi chỉnh sửa một vài tài nguyên thì nó nên được xác nhận bằng cách truy cập vào các tài nguyên tương ứng
Các phương pháp tiếp cận kiểm thử API Dưới đây là các điểm có thể giúp người dùng thực hiện các hướng kiểm thử API:

Hiểu các chức năng của chương trình API và định nghĩa rõ phạm vi của phần mềm
Áp dụng các kỹ thuật kiểm thử như lớp tương đương (equivalence classes), phân tích giá trị biên (boundary value analysis) và đoán lỗi (error guessing) và viết test case cho API
Các tham số truyền vào cho API cần được lập kế hoạch và định nghĩa thích hợp
Chạy các test case và so sánh giữa kết quả mong muốn và kết quả thực tế

4. Sự khác nhau giữa API testing và Unit testing

Unit testing	API testing
Lập trình viên thực hiện	Tester thực hiện
--------	--------
Từng chức năng được kiểm thử	Các chức năng liên quan đến nhau cần được kiểm thử
--------	--------
Lập trình viên có thể truy cập vào source code	Tester không thể truy cập vào source code
--------	--------
Phải kiểm tra cả UI	Chỉ kiểm tra các hàm API
--------	--------
Chỉ các chức năng đơn giảm được kiểm thử	Tất cả các chức năng được kiểm thử
--------	--------
Giới hạn phạm vi	Phạm vi rộng hơn
--------	--------
Thường được chạy trước khi build	Thường được chạy sau khi build
--------	--------

5. Những điều cần kiểm tra trong kiểm thử API

Kiểm thử API nên được thực theo các phương pháp kiểm thử trong quy trình phát triển phần mềm: • Discovery testing: Kiểm tra các API khi truy cập các tài nguyên và xem các API truy cập các tài nguyên, có được các quyền xem, xóa và sửa hợp lệ hay không • Usability testing: Loại kiểm thử này kiểm tra xem API có làm đúng chức năng và thân thiện hay không. và API được tích hợp tốt trên các nền tảng khác hay không (nếu test mobile) • Security testing: Loại kiểm thử này bao gồm các loại xác thực được yêu cầu và xem các dữ liệu nhạy cảm có được mã hóa thông qua HTTP hoặc cả hai hay không • Automated testing: Kiểm thử API được nâng cao trong việc tạo ra các đoạn mã hoặc công cụ mà có thể chạy API thường xuyên • Documentation: Đội kiểm thử phải đảm bảo rằng các tài liệu thích hợp và cung cấp đầy đủ các thông tin để tương tác với API. Tài liệu nên là một phần khi bàn giao

6. Cách thực hành tốt cho kiểm thử API:

• Test case nên được nhóm theo loại kiểm thử (straight-line cases, boundary cases, null inputs, ...). Điều này sẽ làm người sau dễ đọc và dễ bảo trì hơn khi làm việc với một test case cụ thể nào đó. • Thêm một loạt các kiểm tra để kiểm tra chịu tải của hệ thống. • Kiểm tra trường hợp thất bại: liên tục gọi đến API đến khi bị Fail hoặc kết quả trả ra không nhất quán. • Trên mỗi test case, nên bao gồm cả phần khai báo các API được gọi • Các tham số lựa chọn nên được liệt kê dầy đủ trong các test case • Nên đặt độ ưu tiên cho các API được gọi để dễ dàng test hơn • Mỗi test các nên được khép kín, độc lập và tránh ít phục thuộc • Nên tránh kiểm tra xâu chuỗi (test chaining) trong quá trình phát triển . Các thử nghiệm (n+1) sẽ dựa trên các thử nghiệm trước đó, việc này là thiếu chặt chẽ và sẽ làm tăng chi phí bảo trì. • Đặc biệt chú ý khi thực hiện xử lý các chức năng gọi một lần Delete, Closewindow(), CloseHandle(),... • Gọi trình tự nên được thực hiện và lập kế hoạch tốt • Để đảm bảo hoàn thành các kiểm thử, tạo test case cho tất cả các tổ hợp đàu vào có thể có của API • Ném bất cứ điều gì bạn có thể vào các API để kiểm tra nó xử lý các vấn đề không lường trước được và chịu tải như thế nào. • Thêm sáng tạo cho test case, để đảm bảo bao quát toàn bộ kiểm thử, cần tạo test case cho tất cả các tổ hợp đầu vào có thể có của API.

7. Lập kế hoạch kiểm thử: Kiểm thử API cần những gì?

Trước khi bắt tay vào kiểm thử API, bạn nên suy nghĩ về những gì sẽ được test và thực hiện nó như thế nào. Tùy thuộc vào yêu cầu, bạn có thể cần tạo tài liệu kỹ thuật hoặc tài liệu thiết kế, và nó nên được review bởi các đồng nghiệp của mình. Tài liệu này sẽ sử dụng trong suốt quá trình kiểm thử cũng như nâng cấp của bạn. Thiết lập một môi trường kiểm thử: cấu hình databasse và server cho các yêu cầu của ứng dụng, đáp ứng các thông số cần thiết của API. Sau khi thiết lập xong môi trường kiểm thử, các API cần được gọi để đảm bảo API được hoạt động trước khi thực hiện những kiểm thử chi tiết hơn.

Bạn cần phải sắp xếp thời gian cho các kiểm thử API cần có. Bắt đầu bằng cách tự hỏi những câu hỏi sau: • Đối tượng mục tiêu của bạn là ai? người sử dụng API là ai? • Các API thường sử dụng môi trường gì? • Bạn đang kiểm thử ở khía cạnh nào? • Kiểm thử cho vấn đề gì? • Ưu tiên kiểm tra cho cái nào? • Những gì sẽ xảy ra trong trường hợp bình thường? • Những khả năng nào có thể xảy ra trong trường hợp bất thường? • Những gì được định nghĩa là Pass/ Fail? dữ liệu đầu ra mong muốn dữ liệu là gì? chuỗi hành động là gì? • API có thể tương tác với API nào khác không? • Ai trong team sẽ phụ trách thử nghiệm này?
Sau khi đã xác định ranh giới giữa kiểm thử và yêu cầu, bạn cần phải quyết định kiểm thử của mình cần dùng loại nào là phù hợp. Dưới đây là một trong những loại kiểm thử phổ biến được dùng để kiểm thử API: • Functionality testing - Kiểm tra các API có thực hiện đúng chức năng của nó hay không. • Usability testing - Kiểm tra API có dễ dàng để làm việc không. • Reliability testing - Kiểm tra khi API được liên tục gọi đến và vẫn trả ra một kết quả như trước không. • Load testing - Kiểm tra API có thể xử lý một lượng lớn các cuộc gọi hay không. • Creativity testing - Kiểm tra xem API có thể sử dụng theo nhiều cách khác nhau không. • Security testing - Kiểm tra API có đạt yêu cầu bảo mật, bao gồm: xác thực, cấp phép và kiểm soát truy cập hay không. • Proficiency testing - Kiểm tra API có làm tăng những gì nhà phát triển có thể làm được không. • API documentation testing - Kiểm tra các tài liệu API có đảm bảo đầy đủ, chi tiết và dễ dàng để dử sụng API không.
Mỗi kiểm thử chắc chắn sẽ khác nhau nhưng đây là những ví dụ kiểm thử API phổ biến: • Kiểm tra giá trị API trả về dựa trên điều kiện đầu vào. • Xác minh xem có API nào không trả ra bất cứ điều gì hay trả ra kết quả sai không. • Xác minh xem các API có gây nên một số sự kiện khác hoặc gọi API khác không. • Xác minh xem liệu API có cập nhật bất kỳ cấu trúc dữ liệu nào không.

8. Các loại lỗi mà kiểm thử API tìm ra:

• Lỗi do xử lý các lỗi điều kiện tạo ra • Các cờ chưa sử dụng • Thiếu hoặc lặp các chức năng • Các vấn đề về độ tin cậy. Khó khăn trong việc két nối và nhận được phản hồi từ API. • Các vấn đề về bảo mật • Vấn đề về xử lý đa luồng • Vấn đề về hiệu năng. Thời gian API phản hồi rất cao • Lỗi/cảnh báo không đúng • Xử lý không đúng các giá trị đối số hợp lệ • Cấu trúc dữ liệu trả về không chính xác(JSON hoặc XML)

9. Các tool cho kiểm thử API

Kiểm thử API và Unit đều là kiểm tra về source code nên các công cụ tương tự có thể sử dụng cho cả hai • SOAPUI • Runscope • Postman • Curl • Cfix • Check • CTESK • dotTEST • Eclipse SDK tool- Automated API testing

II. Automation test tool SOAPUI

SOAPUI là một automation test tool rất mạnh cho việc kiểm thử Kiểm thử Web Service với SoapUI

1. Tổng quan về Web Service

• Sơ đồ tương tác giữa User và Web Service:
• Nền tảng của WS:

WSDL - Web Service Description Language: WSDL là ngôn ngữ được sử dụng để mô tả đầy đủ về Web Service theo chuẩn XML như các phương thức, kiểu dữ liệu,… dựa trên XML schema.
SOAP - Simple Object Access Protocol: SOAP là một chuẩn giao thức được định nghĩa bởi W3C, là giao thức sử dụng XML để định nghĩa dữ liệu thông qua HTTP. SOAP là cách mà Web Service sử dụng để truyền tải dữ liệu. Vì dựa trên XML nên SOAP là một giao thức không phụ thuộc platform cũng như bất kỳ ngôn ngữ nào.
UDDI - Universal Description, Discovery and Integration

WEB SERVICE VÀ WEB SITE KHÁC NHAU NHƯ THẾ NÀO? Web Site cung cấp dữ liệu được trình bày trên trình duyệt theo những định dạng mà con người có thể đọc được như ngôn ngữ tự nhiên, hình ảnh, âm thanh… Web Site về cơ bản là những trang HTML chứa dữ liệu được định dạng để con người có thể đọc được khi chúng được trình diễn trên trình duyệt Web. Web Service cung cấp các dịch vụ cho các ứng dụng phần mềm khác. Dựa trên việc nhận 1 yêu cầu từ các ứng dụng này, nó tạo ra 1 phản hồi. Yêu cầu này có thể chứa dữ liệu đầu vào cho các dịch vụ để xử lý và dựa trên dữ liệu nhập vào mà dịch vụ đó trả về kết quả. Kết quả trả về bởi các Web Service thường chỉ có ý nghĩa với các phần mềm, tức là chúng được tổ chức theo những định dạng thường khó đọc đối với con người. Các định dạng kết quả phổ biến là XML và JSON. Chúng là những định dạng dễ phân tích và sử dụng hiện nay. Chúng ta có thể hiểu đơn giản như sau:  Web Site => trả về thông tin, dữ liệu => cho người  Web Service => trả về thông tin, dữ liệu => cho ứng dụng, phần mềm khác. 1 Web Site có thể có hoặc không sử dụng Web Service.  Ví dụ về Web Site: Chúng ta có thể truy cập đến website https://www.google.com.vn/maps và sử dụng nó để tìm kiếm địa chỉ của chúng ta trên bản đồ.  Ví dụ về Web Service: Chúng ta đã xây dựng website của riêng mình, và trên website đó chúng ta muốn hiển thị địa chỉ của những người đã truy cập vào website của chúng ta. Trong trường hợp này, chúng ta có thể gọi 1 Web Service được cung cấp bởi Google Maps, truyền địa chỉ đến Web Service đó và nó sẽ trả về 1 bản đồ. Và giờ chúng ta có thể hiển thị bản đồ đó trên website của chúng ta.

1.1. CÁC LOẠI WEB SERVICE

Có 2 loại Web Service khác nhau là:  SOAP (Simple Object Access Protocol)  ReST (Representational State Transfer) ReST và SOAP là tập các đặc tả thông tin được dùng trong việc thực hiện các Web Service. Chúng là những giao thức thông điệp được dùng để trao đổi thông tin giữa 2 chương trình. Việc trao đổi thông tin này là 1 chiều.  SOAP (SIMPLE OBJECT ACCESS PROTOCOL) SOAP là Web Service được xây dựng dựa trên XML. Nó sử dụng XML như 1 cơ chế cho việc trao đổi thông tin (1 chiều) giữa 2 chương trình (hay 2 điểm) trên tầng vận chuyển. SOAP được phát triển bởi Microsoft để thay thế cho 2 công nghệ không thành công trước đó là DCOM (Distributed Component Object Model) và CORBA (Common Object Request Broker Architecture). 2 công nghệ này thất bại do chúng sử dụng các thông điệp nhị phân, thay cho việc sử dụng thông điệp XML như của SOAP. Dù cho việc đàm phán và truyền tải thông điệp của SOAP không dựa trên bất cứ giao thức vận chuyển cụ thể nào nhưng HTTP (Hyper Text Transfer Protocol) hay SMTP (Simple Mail Transfer Protocol) là 2 giao thức vận chuyển phổ biến nhất được dùng với SOAP. Tương tự, SOAP không dựa trên bất kỳ ngôn ngữ lập trình hoặc hệ điều hành cụ thể nào miễn là chúng hiểu XML và thông điệp SOAP. Ví dụ, 1 chương trình chạy trên hệ điều hành Windows như Windows 7 có thể giao tiếp với 1 chương trình khác chạy trên hệ điều hành Linux. SOAP sẽ sử dụng XML và HTTP. Thông điệp SOAP gồm 3 phần: envelope, header và body như trong hình bên dưới.

SOAP Message Architecture  SOAP:envelope Phần tử gốc của thông điệp SOAP, cho biết những gì có trong thông điệp SOAP và làm sao để xử lý chúng. Ứng dụng dựa vào SOAP:envelope và dễ dàng quyết định những gì có thể là thông điệp SOAP. Nó cũng giúp ứng dụng nhận diện phiên bản SOAP được sử dụng.  SOAP:header SOAP:header là 1 phần tử tùy chọn của thông điệp SOAP. Phần tử này chứa các thông tin cụ thể của ứng dụng. Những thông tin này là những thông tin liên quan đến thông điệp SOAP và có thể là bất cứ gì như là phương thức chứng thực hoặc phương thức thanh toán .v.v… Mặc dù là 1 phần tử tùy chọn, nhưng nếu có thì SOAP:header nên là phần tử con đầu tiên của SOAP:envelope.  SOAP:body SOAP:body là phần tử bắt buộc không giống như SOAP:header. Phần này chứa tất cả thông tin liên quan đến việc gọi và phản hồi của web service. Nội dung của thông điệp SOAP nằm ở phần này.
Thông điệp SOAP có định dạng như sau:

<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<!-- Header elements. -->
</soap:Header>
<soap:Body>
<!-- Body elements. -->
</soap:Body>
</soap:Envelope>

Thông điệp SOAP có thể đi qua tường lửa và proxy mà không thực hiện bất kỳ thay đổi trên thông điệp. XML được dùng để tạo các yêu cầu và nhận phản hồi trong SOAP có thể trở nên cực kỳ phức tạp. Trong vài ngôn ngữ lập trình, chúng ta cần xây dựng các ngôn ngữ này 1 cách thủ công. Tuy nhiên, những ngôn ngữ khác có thể sử dụng các đường tắt mà SOAP cung cấp; điều đó giúp chúng ta giảm được công sức khi tạo các yêu cầu và phân tích các phản hồi. Thực tế là khi làm việc với các ngôn ngữ .NET, chúng ta thậm chí không bao giờ thấy XML. Do đó, khó khăn trong việc sử dụng SOAP phụ thuộc 1 mức độ lớn vào ngôn ngữ lập trình mà ta sử dụng. 1 trong những chức năng quan trọng nhất của SOAP là xử lý lỗi. Nếu có 1 vấn đề với yêu cầu, phản hồi sẽ chứa thông tin lỗi mà chúng ta có thể dùng để giải quyết lỗi đó.  REST ( REPRESENTATIONAL STATE TRANSFER) REST là 1 thành viên mới trong gia đình Web Service. REST cung cấp khả năng truy cập và thực hiện dễ dàng 1 Web Service với mục đích là hướng đến khả năng làm việc tốt nhất của Web Service trên môi trường Web. Các Web Service dựa trên REST được sử dụng chủ yếu cho việc xây dựng các ứng dụng client-server trên HTTP. Trong REST, mỗi tài nguyên được xác định và truy cập bởi 1 URI duy nhất và dữ liệu và chức năng hình thành nên 1 tài nguyên. REST định nghĩa tập các tác vụ và các tài nguyên tương ứng với các tác vụ này. Thay vì sử dụng XML cho các yêu cầu/phản hồi, nó dựa trên 1 URI duy nhất và đó là lý do tại sao REST được xem như 1 sự thay thế “nhẹ cân” cho SOAP. Khi nó dựa trên URI như 1 bộ định danh tài nguyên, các tác vụ CRUD chuẩn của HTTP (GET, PUT, POST, DELETE, HEAD) có thể được thực hiện trên URI/tài nguyên đó. SOAP chỉ cung cấp phản hồi ở định dạng XML trong khi REST không chỉ sử dụng XML. Dù các định dạng XML và HTML thường được sử dụng cho các phản hồi REST, REST còn có thể cung cấp các phản hồi theo các định dạng JSON (Javascript Object Notation), CSV(Command Seperated Value), và RSS (Really Simple Syndication). REST là dịch vụ hạng nhẹ thay thế cho phần lớn các cơ chế như SOAP và RPC (Remote Procedure Call) nhưng nó không có sự khuyến nghị của W3C. REST đơn giản, độc lập với ngôn ngữ và nền tảng và hoạt động dựa trên HTTP nên cũng có thể được sử dụng qua tường lửa. Ví dụ về REST:

Request: (URL – http://abc.com/) GET / Accept: application/json+userdb
Response :
200 OK Content-Type: application/json+userdb { "version": "1.0", "links": [ { "href": "/category", "rel": "list", "method": "GET" }, { "href": "/category", "rel": "create", "method": "POST" } ] }

1.2. SOAP VS REST

Để xem xét và lựa chọn giải pháp nào phù hợp, trước tiên chúng ta phải hiểu được khái niệm và bản chất, sự khác nhau hai công nghệ này.

Chúng ta cùng xem xét 10 điểm khác nhau chính: STT SOAP REST

SOAP là một giao thức REST là một cách thiết kế kiến trúc
SOAP là từ viết tắt của Simple Object Access Protocol(Giao thức truy cập đối tượng đơn giản) REST viết tắt của REpresentational State Transfer
SOAP can't use REST because it is a protocol REST có thể dùng các web services sử dụng SOAP vì nó có thể dùng bất kỳ giao thức nào như HTTP, SOAP
SOAP cung cấp các giao diện dịch vụ(services interfaces) cho các thành phần bên ngoài sử dụng REST sủ dụng đỉa chỉ URI để cung cấp các dịch vụ
JAX-WS là java API cài đặt web services theo giao thức SOAP JAX-RS là java API cài đặt web services theo kiến trúc RESTful
SOAP định nghĩa các chuẩn và quy tắc chặt chẽ REST không định nghĩa nhiều chuẩn như SOAP
SOAP sử dụng băng thông và tài nguyên nhiều hơn REST REST sử dụng băng thông và tài nguyên ít hơn SOAP
SOAP định nghĩa chuẩn bảo mật của riêng nó RESTful kế thừa chuẩn bảo mật tầng vận tải của giao thức mạng
SOAP chỉ hỗ trợ định dạng dữ liệu XML REST hỗ trợ các định dạng dữ liệu khác nhau như text, HTML, XML, JSON
SOAP ít được dùng hơn REST REST được ưa chuộng hơn SOAP
Được thiết kế để dùng trong tính toán phân tán Thương không được dùng trong môi trường tính toán phân tán
Tin cậy hơn Ít tin cậy hơn – chẳng hạn, HTTP DELETE có thể trả về trạng thái OK ngay cả khi tài nguyên không được xóa
Hỗ trợ hầu hết các chuẩn bảo mật, tin cậy và giao dịch Sử dụng tốt với các giao thức như: HTTP, SSL. Các phương thức DELETE và PUT thường bị vô hiệu hóa bởi tường lửa hoặc vấn đề bảo mật
SOAP hỗ trợ cả hai giao thức SMTP và HTTP REST gắn với giao thức HTTP

SOAP:  Độc lập ngôn ngữ, nền tảng và giao thức vận chuyển.  Làm việc tốt với các môi trường doanh nghiệp phân tán.  Đã được chuẩn hóa.  Khả năng mở rộng cao.  Có cơ chế xử lý lỗi.  Tự động hoàn toàn khi được dùng với những sản phẩm ngôn ngữ nhất định (ví dụ như những ngôn ngữ lập trình trong .NET).
REST:  Độc lập ngôn ngữ, nền tảng. REST chỉ hoạt động trên giao thức vận chuyển HTTP.  Không đòi hỏi các công cụ chi phí cao để tương tác với các Web Service.  Hiểu quả (SOAP sử dụng XML cho tất cả thông điệp, REST có thể sử dụng các định dạng thông điệp nhỏ hơn).  Nhanh (không yêu cầu xử lý mở rộng).  Gần gũi hơn với các công nghệ Web so với SOAP.

2. SOAP UI

• SoapUI là một sản phẩm của hãng SmartBear, SOAP UI là công cụ kiểm thử mã nguồn mở API hàng đầu, cho phép bạn dễ dàng thực hiện kiểm thử tự động chức năng, kiểm thử hồi quy và kiểm thử tải trên các Web API khác nhau. SOAP UI hỗ trợ tất cả các chuẩn giao thức và công nghệ để test tất cả các loại API. Ngoài ra SOAP UI còn cho phép chúng ta thực hiện thử nghiệm phi chức năng như kiểm thử hiệu suất và kiểm thử bảo mật. Giao diện SOAP UI đơn giản, thân thiện, dễ sử dụng. • Một số tính năng quan trọng của SoapUI: 1. Kiểm thử chức năng:  Một công cụ mạnh mẽ cho phép tester viết Functional API Tests trong SoapUI  Hỗ trợ tính năng kéo-thả mà làm tăng tốc độ phát triển script  Hỗ trợ gỡ lỗi và cho phép tester phát triển data driven tests. 2. Kiểm thử bảo mật:  Ngăn chặn SQL Injection để bảo đảm cơ sở dữ liệu  Thực hiện Fuzzing scan và Boundary scan để tránh những hành vi thất thường của các dịch vụ. 3. Kiểm thử tải:  Kiểm thử khả năng chịu tải của một ứng dụng web sử dụng loadUI. Sau khi thực hiện kiểm tra tải, LoadUI sẽ tạo ra một bản báo cáo, giúp xác định liệu các ứng dụng có thể chịu tải nặng hay không.  Kiểm thử khả năng chịu tải của một ứng dụng web sử dụng loadUI  Mô phỏng mức độ cao và kiểm thử tải thực tế một cách dễ dàng.  Cho phép tùy chỉnh báo cáo chi tiết để nắm bắt các thông số hiệu suất. 4. Hỗ trợ các giao thức và công nghệ:

3. Cài đặt SoapUI

• B1: Download SoapUI free version: http://sourceforge.net/projects/soapui/files/ hoặc http://soapui.org/downloads/soapui/open-source.html Chọn phiên bản cho hệ điều hành của bạn và tải về bộ cài soapUI. • B2. Thực hiện cài đặt o Chạy file cài đặt: o Trong Setup Winrar click vào nút Next để chuyển sang trình hướng dẫn cấp giấy phép. Chấp nhận các điều khoản và điều kiện, chọn thư mục mà soapUI có thể truy xuất các tập tin hỗ trợ và cài đặt. Nhấn Next để chọn các component. Xem ảnh chụp màn hình dưới đây để bạn tham khảo:
 Trong ảnh chụp màn hình, chúng ta có thể thấy một số các thành phần ngoài soapUI: o Source component: Có chứa mã nguồn hoàn chỉnh cho các công cụ soapUI. Bạn có thể cài đặt thành phần này và phân tích mã nguồn soapUI. o Tutorials component: Cung cấp các hướng dẫn. o HermesJMS component: Sử dụng cho việc gửi và nhận tin nhắn thông qua Java Messaging Service, được cấu hình trong trường hợp của các dịch vụ liên quan kiểm tra JMS.  Để cài đặt HermesJMS component, lựa chọn chấp nhận các điểu khoản. Vì vậy, hãy nhấp vào nút Next.  Sau khi hoàn thành, cuối cùng sẽ hiển thị cửa sổ này:

 Nhấn vào nút "Finish" để hoàn tất quá trình cài đặt và khới động soapUI.

4. Làm việc với SOAP Project: Tạo Project, Test Suite, Test Case

** a. Tạo SoapUI Project:** • B1. Mở ứng dụng SoapUI • B2. Nhấn New Project SOAP từ menu File hoặc nhấn phím tắt CTRL + N. • B3. Nhập tên Project và url WSDL hợp lệ • B4. Các thiết lập còn lại có thể được để lại mặc định và sau đó nhấp OK để hoàn tất

• Khi URL được WSDL xử lý thành công, SOAP Project sẽ được tạo ra:

• Bạn có thể double click vào Project để thấy cửa sổ overview của project để xem các thông tin chi tiết của nó • Bạn có thể double click vào Interface để xem overview của Interface. Nó đưa ra nhiều thông tin về WSDL. Điều này rất hữu dụng cho việc truy xuất và kiểm tra một WSDL Demo: Tạo request tới Web Service • B1. Tạo New Request tới Web Service

• B2. Double click vào request. Nó sẽ hiển thị SOAP request dưới dạng XML. Nhập chuyển đổi giữa 2 loại tiền tệ: FromCurrency và ToCurrency  Click nút
• Sau khi click nút Run, SoapUI sẽ gửi request tới web service chuyển đổi tiền tệ cùng với các thông số đầu vào được cung cấp trong yêu cầu. Sau đó, web service sẽ nhận được các thông số đầu vào và xử lý chúng. Sau khi thực hiện, server sẽ gửi response cho SoapUI. Response XML sẽ được hiển thị cửa sổ bên o Đôi khi các response có thể chứa các thông báo lỗi. Ví dụ, trong khi xử lý yêu cầu đầu vào, xảy ra trường hợp down server hoặc mất kết nối Internet, trong thời gian đó, chúng ta sẽ nhận được một response là một exception. o Ví dụ, để test một negative scenario, chúng ta hãy nhập US cho << >> FromCurrency và VND cho << >> ToCurrency và gửi request tới web service. Response nhận được như hình dưới đây:
b. Tạo Test suite: • B1. Trong project hiện tại, chúng ta có thể tạo ra Test suite bằng cách click chuột phải vào thư mục gốc của project -> New Testsuite hoặc nhấn phím tắt Ctrl + T: • Đặt tên Testsuite và nhấn OK, Test suite sẽ được hiện thị bên thanh navigator:

c. Tạo Testcase • B1. Tạo Testcase trong Testsuite bằng cách ấn chuột phải vào Testsuite, chọn New Testcase hoặc nhấn Ctrl + N • B2. Đặt tên testcase và ấn OK để tạo testcase. Testcase được tạo gồm Test steps, Load tests và Security tests được hiển thị trên thanh navigator như sau

• Chúng ta có thể chèn test step bằng cách nhấn chuột phải vào test case và lựa chọn một test step thích hợp như hình dưới đây. Ví dụ với Test Soap Request:
• Nhập thông tin đầu vào chuyển đổi giữa 2 loại tiền tệ: FromCurrency và ToCurrency

5. Làm việc với Rest project:

a. Tạo project:

B1. Mở ứng dụng SoapUI
B2. Nhấn New Project REST từ menu File hoặc nhấn phím tắt CTRL + ALT + N.
B3. Nhập tên Project và url WADL hợp lệ (nếu có)
B4. Các thiết lập còn lại có thể được để lại mặc định và sau đó nhấp OK để hoàn tất

=> Khi URL được xử lý thành công, REST Project sẽ được tạo ra:  Demo: Tạo request tới Web Service • B1. Tạo New Request tới Web Service

• B2. Double click vào request. Nó sẽ hiển thị REST request. Nhập parameter hợp lệ ** Click nút ** • Sau khi click nút Run, SoapUI sẽ gửi request tới web service cùng với các thông số đầu vào được cung cấp trong yêu cầu. Sau đó, web service sẽ nhận được các thông số đầu vào và xử lý chúng. Sau khi thực hiện, server sẽ gửi response cho SoapUI. Response Json sẽ được hiển thị cửa sổ bên

b. Tạo Test suite: • B1. Trong project hiện tại, chúng ta có thể tạo ra Test suite bằng cách click chuột phải vào thư mục gốc của project -> New Testsuite hoặc nhấn phím tắt Ctrl + T: • Đặt tên Testsuite và nhấn OK, Test suite sẽ được hiện thị bên thanh navigator:

• Chúng ta có thể chèn test step bằng cách nhấn chuột phải vào Test Steps và lựa chọn một test step thích hợp như hình dưới đây. Ví dụ với Test Soap Request:

• Nhập thông tin đầu vào chuyển đổi giữa 2 loại tiền tệ: FromCurrency và ToCurrency

** Click nút ** Sau khi click nút Run, Response trả ra là chuỗi Json

6. Kết nối CSDL Oracal với SOAPUI

Vào link để download thư viện điều khiển Database Oracal https://www.soapui.org/jdbc/reference/jdbc-drivers.html#_ga=1.254788104.1820378905.1461896451 Download thư viện copy vào đường dẫn: C:\Program Files\SmartBear\SoapUI-5.2.1\lib thư viện ojdbc14 Cấu hình JDBC: Tạo step JDBC bằng cách chuột phải vào Test Steps -> Add Step-> JDBC Request

Tạo được JDBC Request, điền các thông tin Driver oracle: oracle.jdbc.driver.OracleDriver Connection String: cú pháp [jdbc:oracle:thin:/@::]

Tạo Script Assertion so sánh kết quả truy vấn trả ra ở trên với kết quả API response

Code Script thực hiện action đó:

Kết quả trùng cho ra True, ngược lại là False

7. Tạo Property Transfer

Chuyển giao value properties giữa các Step và Testcase chứa chúng, Test Suite, Project. Sử dụng trong các trường hợp như:

Lấy ra một giá trị từ một message XML, ví dụ như một session ID từ response SOAP trả về
Viết một giá trị vào một message XML, ví dụ như một sessionID hoặc authentication data.
Chuyển nội dung XML/Json phức tạp giữa các thuộc tính. Vào Test Steps -> Add Step -> Add Property Transfer Tạo Transfer bằng cách click

Tranfers b chuyển nội dung Response của test step GetList sang data của Request GetList

8. Tạo Assertions Contain

Dùng để so sánh giá trị API trả ra và giá trị khai báo trong Contain Kết quả trùng khớp thì cho ra result= True, ngược lại result= False Trong ConversionRate Request, bạn có thể nhìn khu vực Assertion ở phía dưới. Để thêm assertion mới, click Add một assertion.

Chọn chuyên mục Assertion, loại Assertion, rồi click Add.

Nhập giá trị '1.5' tồn tại trong response trả về.

Assertion thực hiện và show ra kết quả VALID or INVALID.

Hoặc bạn có thể sử dụng biểu thức:

Khi thay đổi nội dung của 'Contains Assertion' là '1.6' và nhìn kết quả.

Assertion được thực hiện và kết quả được đưa ra cho người sử dụng. Assertion trả ra kết quả là fail.

Not Contains assertions: Tìm kiếm cho sự không tồn tại của chuỗi quy định. Cách add giống như add ‘Contains’ assertion. Nhập chuỗi 'FromCurrency' không tồn tại trong response. Click 'OK'

Cũng như việc add assertion, nó thực hiện và hiển thị kết quả. Có thể đồng thời bổ sung 2 assertion.

9. Tạo properties

Properties là một khía cạnh chính trong việc thử nghiệm nâng cao với SOAUI. • Properties có thể được sử dụng để lưu giữ kết quả đầu cuối của dịch vụ của bạn, làm cho nó dễ dàng để thay đổi các lưu giữ đó thực tế sử dụng trong quá trình thực thi • Properties có thể được sử dụng để lưu giữ thông tin xác thực, làm cho dễ dàng để quản lý chúng trong vị trí trung tâm hoặc tập tin bên ngoài. • Properties có thể được sử dụng để chuyển giao và chia sẻ session id trong quá trình thực thi, vì vậy nhiều teststep hoặc testcases có thể chia sẻ các session tương tự. Để tạo properties bạn có thể sử dụng Properties Teststep. Cho ví dụ, với project chúng ta vừa tạo ở trên:

Điền tên của Properties step, ví như Properties – Currencies, click OK

Cửa sổ Properties mở ra. Click nút Add để thêm một property mới:

Properties Teststep is added. Kéo và thả để di chuyển step này để đầu test case (hoặc sử dụng click chuột phải) Properties Teststep đã được thêm.

Bây giờ bạn cần gọi giá trị của những properties này trong step ConversionRate Request

Click nút Run để gửi Request và get Response

Từ đó chúng ta đã kết thúc việc tạo Properties TestStep và gọi một SOAP Request sử dụng step Properties này. SOAPUI cung cấp properties ở 3 mức độ : Project, TestSuite, TestCase. Bạn có thể thêm mới properties trong cửa sổ này. Cho ví dụ,tương ứng với testcase trên:

Cú pháp định dạng đọc giá trị properties: ${[scope]propertyName} scope có thể là 1 trong các giá trị phía dưới sau: • #Project# - tham chiếu tới Project property • #TestSuite# - tham chiếu tới TestSuite property trong TestSuite chứa nó. • #TestCase# - tham chiếu tới TestCase property trong TestCase chứa nó. • [TestStep name]# - tham chiếu tới TestStep property Ví dụ 1, edit SOAP request để tham chiếu TestCase property vừa tạo.

Cho ví dụ 2, tạo properties ở project

Sửa request REST data đầu vào ở value của parameter band_id sử dụng properties vừa tạo

Lấy được value vừa tạo và response ra kết quả tương ứng

10. Set character encoding in SOAPUI Preferences

Để setup encoding cho request/response bạn đánh dấu request đó trong Navigator. Rồi sau đó hiển thị đến "Request/Response properties" chọn encoding set tới UTF-8 or iso-8859-1.

III. MockService

1. Tổng quan về MockService:

1.1. Mocking là gì

Mocking là việc thực hành tạo ra một môi trường giả lập để làm việc, tạo các đối tượng giả lập các hành vi của những đối tượng thực tế.

1.2. Khi nào sử dụng Mocking

Bạn nên sử dụng mock khi bạn không thể sử dụng trên thực tế. Cần xem xét cẩn thận khi sử dụng mock.

1.3. Ưu điểm của sử dụng Mocking

(You can create tests in advance)Có thể tạo dữ liệu test cơ bản. Bạn có thể viết Services test trước khi Service được tạo. Bạn có thể tạo các dữ liệu test trong môi trường kiểm thử tự động trong suốt quá trình phát triển. (Teams can work in parallel)Các đội có thể làm việc song song: Việc thực hiện dữ liệu test và việc tạo Service của đội phát triển là độc lập. Mock giúp giả lập các bộ dữ liệu test trước khi Service được tạo. (You can create proof of concepts or demos)Là thí nghiệm cho một khái niệm hoặc demo. Là nền tảng để quyết định cho việc triển khai một dự án, quyết định cho việc thực hiện theo hướng thực tế. (You can write test for resource not accessible) Có thể viết test cho nguồn tài nguyên không thể truy cập. Mock cho phép xây dựng dữ liệu test trên môi trường giả lập, cụ thể như máy tính local, không giới hạn mức truy cập. (Mock can be delivered to the customer) Mock có thể chuyển giao hoàn toàn cho khách hàng sử dụng 24/7 mà không hạn chế về độ bảo mật về dữ liệu như trong môi trường thực tế. (Save yourself from the money pit)Tiết kiệm chi phí: Một số hệ thống sử dụng trong môi trường thực tế có thể liên kết với giao dịch phí khác. Điều này có thể nảy sinh nhiều sai sót trong quá trình thử nghiệm. Để hạn chế rủi ro về khía cạnh chi phí, giao dịch phí, Mock giả lập dữ liệu test khắc phục được vấn đề đó. ( You can isolate systems)Bạn có thể phân lập các hệ thống: Đôi khi bạn muốn thử nghiệm một phần hệ thống của bạn mà không muốn có sự ảnh hưởng đến các phần còn lại của hệ thống. Hạn chế việc nhiễu dữ liệu, có kết luận tốt từ các dữ liệu thu thập được. Điều này mang đến cho bạn một môi trường thử nghiệm mà bạn đã gỡ bỏ tất cả các hành vi ngẫu nhiên, có mô hình lặp lại và có thể giám sát các hệ thống cụ thể tốt. (You can test the Live Environments before you have the service in it)Bạn có thể test trên môi trường Live trước khi có service. Đôi khi nó có lợi để làm một số thực nghiệm của môi trường vật lý trước khi bạn thực sự có một dịch vụ để đặt vào nó. Đặt Mock trong môi trường Live có thể phát hiện các vấn đề với các tài nguyên mạng, sai sót trong các thiết lập máy chủ hoặc lỗi trong cấu hình của hệ thống bên ngoài.

1.4. Hạn chế của sử dụng Mocking

Chỉ sử dụng ở một thời điểm nhất định: Mock có thể được loại bỏ nếu có sự update từ phía yêu cầu thay đổi.
Có nhiều hạn chế trong việc triển khai: Cần được tạo điều kiện môi trường phù hợp cho việc triển khai Mock.
Mock có thể tồn tại nhiều lỗi.
Mock chỉ là sự thể hiện của những gì nó muốn giả lập, là ý tưởng của dịch vụ muốn giả lập.
Giữa Mock và live: Mock có sự giảm thiểu khá nhiều về sự phức tạp so với môi trường live. Nên yêu cầu người dung (khách hàng) hiểu được điều đó, trước khi có sự phê phán cho những lỗi xảy ra ở độ phức tạp hơn khi sử dụng Mock.
Mock chỉ là giả lập, nên không thể nào là sử dụng là hoàn hảo như là real.

1.5. Phương pháp tốt nhất của Mocking (Best Practices)

Bắt đầu từ phạm vi nhỏ và mở rộng: Bắt đầu từ Mock cơ bản trong vài giờ, sau đó phát triển các chức năng quanh nó, nhận định chức năng nào phù hợp và sử dụng mở rộng Mock đó.
Chỉ đi sâu Mock nếu như nó thật sự cần thiết: Một số giao diện có thể là ít phức tạp hoặc có giá trị kinh doanh ít hơn, làm cho nó ít quan trọng để Mock trong chiều sâu, trong khi khác có thể là ngược lại. Ngoài ra còn phụ thuộc vào nguồn lực thực hiện cho Mock đó.
Xem xét các yếu tố như tần số sử dụng, độ phức tạp, tiếp cận và giá trị kinh doanh để xây dựng Mock có phạm vi phù hợp.
Có thể tái sử dụng các Mock hữu ích giúp tiết kiệm chi phí, thời gian.
Tổng hợp những gì về quy trình mà Mock mô phỏng được, giúp cho sự hài hòa trong quá trình làm việc giữa các bên về sau này. Có sự clear ngay từ đầu.
Có thể xem xét sử dụng tiện ích đám mây.

2. Tạo Mockservice từ Service đã tồn tại:

2.1. Mock Service

Tạo new Project. Bắt đầu với một SOAP project sử dụng WSDL: http://www.webservicex.net/CurrencyConvertor.asmx?WSDL

We're now ready to Create the MockService Tạo một Mock Service B1: Click chuột phải trên SOAP interfaces và chọn Generate MockService

 B2: Trong cửa sổ Generate Mock Service bạn có thể ghi rõ local port/pathcho Service bạn tạo rồi Click OK.

 B3: Nhập tên Mockservice và click OK. Ta có MockService sau:

2.2. Edit MockService

Sửa value của ConversionRateResult thay thế vào giá trị mặc định

2.3. Invoking a MockService

Sau khi có MockService, trên cửa sổ MockResponse editor, Click Create Request.

Khi đó sẽ mở ra cửa sổ Request cho hoạt động [ConversionRate]

Khi bạn mở Request, SOAPUI sẽ tự động thay đổi Request-Response theo định nghĩa Response trong MockService

Nếu bạn quay trở lại MockResponse editor và chọn Response trong MockService. Sẽ thấy hiển thị Request và Response tương ứng khi Edit.

2.4. Customizing a MockResponse

Trước tiên, sẽ tạo MockResponse thứ 2.

Nhập tên MockResponse

Viết script cho Response. Click Script tab trên Response và viết trong Groovy Script context.setProperty ( "rate", Math.random() )

Scipt này gán 1 property rate gọi tới 1 số random. Trong ConversionRateResult element nhập: ${rate}

Kết quả này đã được insert vào Response. Sau khi có MockService, trên cửa sổ MockResponse editor, Click Create Request. Khi đó sẽ mở ra cửa sổ Request cho hoạt động [ConversionRate] Khi bạn mở Request, SOAPUI sẽ tự động thay đổi Request-Response theo định nghĩa Response trong MockService

Nếu bạn quay trở lại MockResponse editor và chọn Response trong MockService. Sẽ thấy hiển thị Request và Response tương ứng khi Edit.

3. Tạo Mockservice mới giả lập.

3.1. MockService

Thêm [Project]: Vào project click chuột phải Add project

Tạo được project, thay tên project

Thêm [Rest MockService]: Click chuột phải vào Project vừa tạo -> New REST MockService

Thêm [Mock action]: Click chuột phải vào REST Mockservice -> Add new mock action

Mock action hỗ trợ các dạng Method là Get và Post,Put, Delete…

Thêm [MockResponse]: Click chuột phải vào Mock action -> New MockResponse

Ta có Mockservice sau:

3.2. Edit Mockservice

Trong cửa sổ Editor của MockResponse nhập chuỗi ở định dạng Json thể hiện đầu ra cho Request gọi MockService:

{
"students": {
 "student":    [
            {
         "bank_id": 1113,
         "id": 101,
         "bank_full_name": "Ngân hàng TMCP Việt Nam Thịnh Vượng",
         "time_updated": "",
         "card_type": "VISA",
         "status": 1,
         "time_begin": 1466669330,
         "bin_code": "86",
         "time_created": 1466669330,
         "trade_name": "VPBank",
         "time_end": 0,
         "time_approve": "",
         "installment_bank_id": 140
      },
            {
         "bank_id": 1113,
         "id": 83,
         "bank_full_name": "Ngân hàng TMCP Việt Nam Thịnh Vượng",
         "time_updated": "",
         "card_type": "VISA",
         "status": 3,
         "time_begin": 1466215891,
         "bin_code": "86",
         "time_created": 1466215891,
         "trade_name": "VPBank",
         "time_end": 0,
         "time_approve": 1466216354,
         "installment_bank_id": 140
      }
}
}

Theo trên, ta có một Mock action ở phương thức GET Tạo Mock action sử dụng phương thức POST:

Truyền value trực tiếp cho tham số:

Mock action sử dụng gọi property vào truyền value cho tham số:

3.3. Invoking a Mockservice

Quan sát Mocservice đã tạo: Click double chuột vào Mockservice -> View Custom Properties, nhìn vào 2 thông số: [Path]: / [Port]: 8080

Ta lấy được URI của mockservice: http://localhost:8080

B1: Tạo project gọi Mockservice:
B2: Tạo REST Service. Click chuột phải vào project -> New REST Service from URI

Với cùng thao tác này, lần lượt tạo 2 REST service tương ứng 2 mock action với 2 phương thức là GET và POST:

Chạy lần lượt từng Rest service: Mock action Method=GET

Mock action Method=POST

4. Tạo Mockservice động (truy vấn đến DB)

4.1. Tổng quan Mockservice Scripting

Đối với Mockservice hỗ trợ viết script: Cho phép viết và có phản hồi các kịch bản MockResponse. Đây là nơi tập trung để tạo ra các nội dung response động. Đối với MockOperations; chọn option "Script" trong MockOperation Dispatch cho phép bạn sử dụng script để quyết định Mockresponse return tới khách hàng.

4.2. Các Object trong Mock

Một số đối tượng thường có sẵn trong hầu hết các kịch bản:  Context: sử dụng để lưu trữ các đối tượng MockService-wide, như các kết nối cơ sở dữ liệu , token bảo mật  RequestContext: sử dụng để lưu trữ các đối tượng MockService-wide, như các nội dung động để chèn vào thông điệp Response.  MockRequest: một đối tượng tương ứng với yêu cầu thực tế thực hiện cho các MockService. Thông qua đối tượng này, bạn có thể có giữ được các tin nhắn gửi đến, tiêu đề của nó, vv Cũng như các đối tượng HttpRequest và HttpResponse có sẵn để xử lý " low-level".  MockResult: một đối tượng đóng gói các kết quả của các yêu cầu gửi đi (dispatched request).  MockResponse/mockOperation: đối tượng có sẵn ở các mức phù hợp để truy cập vào cấu hình và chức năng cơ bản.  MockRuner: các đối tượng tương ứng để thực hiện các Mock service; điều này cho phép bạn truy cập vào các kết quả Mock trước đó.

4.3. Chuyển giá trị từ request tới response

Trong màn hình Script, các script sử dụng các thuộc tính của đối tượng mockRequest để lấy được request gửi đến, chiết xuất các giá trị mong muốn thông qua XPath và sau đó viết các kết quả được tạo ra tới requestContext property. Trong ví dụ sau:

Nhập nội dung Script như sau và Response Mock:

def groovyUtils=new com.eviware.soapui.support.GroovyUtils(context)
def temp="";
def xml=new XmlSlurper().parseText(mockRequest.requestContent)
xml.breadthFirst().each{
        def v=it.toString()
        if(it.name()=="FromCurrency" || it.name()=="ToCurrency" )
{
                temp +=it.text()+" ";
                log.info("============================================="+it.text());
        }
}

context.data= temp

Mở Request tương ứng:

Sau khi chạy, ta được kết quả:

IV. Load/ Performance Test API SOAPUI

1. Tổng quan Load testing

1.1. Performance Testing là gì?

Performance testing là việc thực hiện test để xác định một hệ thống có thể đáp ứng và ổn định với yêu cầu độ tải cao. Nó có thể phục vụ để điều tra, đo đạc, xác nhận hoặc xác minh chất lượng các thuộc tính của hệ thống như: khả năng thay đổi, tính tin cậy, và tài nguyên sử dụng.

1.2. Các loại kiểm thử hiệu năng

Baseline Testing: Tìm số liệu cho hiệu năng hệ thống theo mức tải trọng mức bình thường/ chấp nhận được.
Load Testing là khái niệm chủ yếu của việc kiểm thử mà có thể tiếp tục hoạt động ở một mức tải cụ thể, cho dù đó là một lượng lớn dữ liệu hoặc lượng lớn người sử dụng. Mục tiêu: Tìm số liệu cho hiệu năng hệ thống theo mức tải trọng cao hơn.
Stress Testing: là một cách để kiểm tra (độ) tính tin cậy. Để tìm số lượng tải mà hệ thống thực sự bị phá vỡ hoặc gần để phá vỡ. Mục tiêu: Tìm điểm phá hệ thống.
Soak Testing: Đảm bảo không có hành vi không mong muốn xuất hiện theo thời gian. Tiến hành ngầm thử nghiệm trong thời gian dài.
Scalability Testing: Test khả năng mở rộng, gần như là Load test, nhưng thay vì tăng số lượng yêu cầu,thì tăng kích thước hay độ phức tạp của yêu cầu gửi. Ví dụ như gửi yêu cầu lớn, file đính kèm lớn, hoặc yêu cầu sâu xa. Mục tiêu: Tìm chỉ số cho hiệu suất hệ thống theo khối lượng lớn dữ liệu.

1.3. Cách kiểm thử tải:

Kiểm thử tải:

Kiểm thử khả năng chịu tải của một ứng dụng web sử dụng loadUI. Sau khi thực hiện kiểm tra tải, LoadUI sẽ tạo ra một bản báo cáo, giúp xác định liệu các ứng dụng có thể chịu tải nặng hay không.
Kiểm thử khả năng chịu tải của một ứng dụng web sử dụng loadUI
Mô phỏng mức độ cao và kiểm thử tải thực tế một cách dễ dàng.
Cho phép tùy chỉnh báo cáo chi tiết để nắm bắt các thông số hiệu suất.

2. Tạo và thực hiện Load test:

2.1. Tạo một Load test:

Sau khi Generate TestSuite, ta được Testcase được tạo gồm Test steps, Load tests và Security tests được hiển thị trên thanh navigator

Tạo new Load test: Click chuột phải vào Load test -> New Load test (Cltl + N) Ta được một step Load test như sau:

2.2. Chạy load test:

Click button chạy Load test và theo dõi kết quả ở Statistics table như trên. Kết quả cũng được thể hiện Statistics Graphs: Cho phép bạn xem các giá trị thay đổi ví dụ như khi bạn tăng số lượng các thread. Statistics History Graph: Cho thấy một lựa chọn giá trị thống kê cho tất cả các bước cho phép bạn so sánh chúng và xem nếu phân phối của bất kỳ giá trị giữa teststeps thay đổi theo thời gian. Từ đó, đối với cùng một thử nghiệm, ta có thể so sánh mức trung bình thời gian.

2.3. Thêm assertion tới Loadtest

Trên LoadTest editor, chọn tab LoadTest Assertion

Click button Add Assertion trong menu LoadTest Assertion để add một assertion.

Cửa sổ Add Assertion được mở, chọn Step Maximum. Chọn Maximum cho thời gian tối đa milliseconds mà response được phép lấy, nếu thời gian vượt quá những gì đã thiết lập, thử nghiệm sẽ thất bại. Nhấn OK.

Cửa sổ TestStep Max Assertion sẽ mở ra. Click Ok

Step Maximum assertion được add thành công.

Bây giờ chạy thử nghiệm một lần nữa. Nếu response kéo dài quá lâu, bạn sẽ thấy các con số trong cột err tăng lên nhanh chóng.

3. Các loại Strategy:

Các Load Strategy khác nhau có sẵn trong soapUI và soapUI Pro cho phép bạn mô phỏng nhiều loại tải theo thời gian, cho phép bạn dễ dàng kiểm tra việc thực hiện các dịch vụ mục tiêu của bạn dưới một số điều kiện. Chọn chiến lược mong muốn cho LoadTest từ Thanh công cụ Strategy trong cửa sổ LoadTest.

3.1. Simple Strategy:

Khi tạo một LoadTest mới này là strategy mặc định và đặt ở một tải trọng tương đối thấp (5 thread với sự chậm trễ 1000ms).

Simple Strategy là hoàn hảo cho Baseline test. Sử dụng nó để khẳng định hiệu năng ở mức cơ bản của service. Một thiết lập như thế này có thể được sử dụng để liên tục kiểm tra tải để đảm bảo rằng dịch vụ của bạn thực hiện như mong đợi mức tải trung bình. Test Delay định nghĩa sự trì hoãn giữa mỗi lần test. Random được sử dụng để thiết lập số lượng ngẫu nhiên tương đối cho test delay.

3.2. Variable Load Strategies

Có một số chiến lược có thể được sử dụng để thay đổi tải (số thread) theo thời gian, mỗi loại mô phỏng một loại hành vi khác nhau. Chúng có thể hữu ích cho việc test phục hồi và test stress. Có thể setup khoảng thời gian Strategy đến 5000 số lượng các thread thay đổi trong 5 giây (5 seconds). (Variance strategy) : Strategy chênh lệch-phương sai - điều này thay đổi số lượng các thread theo thời gian trong một cấu hình "răng cưa"; thiết lập các Interval là việc tăng giảm thread và Variance. Ví dụ, nếu chúng ta bắt đầu với 20 thread, thiết lập interval tới 60 and Variance tới 0.8, số lượng các thread sẽ tăng 20-36 trong vòng 15 giây đầu tiên, sau đó giảm trở lại 20 và tiếp tục xuống đến 4 thread sau 45 giây, và cuối cùng đã quay trở lại với giá trị ban đầu sau 60 giây. Trong Statistics Diagrams chúng ta có thể theo dõi sự chênh lệch này một cách dễ dàng.

(Burst Strategy) Strategy bùng nổ: strategy này được thiết kế đặc biệt để kiểm tra phục hồi và lấy phương sai để cùng cực của nó. Ở đây bạn có thể (và nên!) Thiết lập số lượng các chủ đề cho một giá trị cao (20 +) để mô phỏng một sự tấn công trong một khoảng thời gian ngắn, sau đó đo sự phục hồi của hệ thống của bạn với một LoadTest cơ sở trực chuẩn có chứa cơ bản performance- khẳng định có liên quan. Hãy thử điều này với burst delay and duration từ 10 giây cho 60 giây; Biểu đồ hiển thị các bùng nổ của hoạt động. Cũng lưu ý rằng độ phân giải đã được thay đổi để 250ms (từ mặc định "dữ liệu" giá trị), nếu không chúng ta sẽ không có bất kỳ bản cập nhật sơ đồ trong quá trình "ngủ" giai đoạn thực hiện (vì không có dữ liệu để thu thập)

Thread Strategy: cho phép bạn thay đổi tuyến tính số lượng các thread từ một cấp độ khác qua các lần chạy của LoadTest. Đó là mục đích chính là như là một phương tiện để xác định mà tại đó thống kê một số mức độ thay đổi hoặc các sự kiện xảy ra, ví dụ để tìm thấy ở đó THREADCOUNT tối đa TPS hoặc BPS có thể đạt được hoặc tìm thấy ở đó THREADCOUNT lỗi thử nghiệm chức năng bắt đầu xảy ra. Thiết lập giá trị start và end thread (ví dụ 5-50) và thiết lập duration để một thời gian tương đối dài (tôi sử dụng ít nhất là 30 giây cho mỗi thread, trong ví dụ này sẽ là 1.350 giây) để có được số đo chính xác.

4. Export Data

Chạy LoadTest và cần tạo một vài các báo cáo khác nhau và export chúng ra các file chi tiết. Có nhiều lựa chọn phù hợp như sau: • Export Statistic (Export dữ liệu của bảng thống kê). • Export Statistic Diagrams (Export dữ liệu của biểu đồ thống kê. • Export Data Continuously (Xuất dữ liệu liên tiếp trong khi thử nghiệm chạy).

4.1. Export Statistic

Mở button [Export Statistics] trên thanh công cụ

Dẫn ra một file get nội dung của bảng thống kê dữ liệu có định dạng là dữ liệu trong các dòng chia bởi dấu phẩy (,)

4.2. Export Statistic Diagrams

Biểu đồ statistic có button export tương tự. Các tần số dữ liệu phân giải được thiết lập trong biểu đồ, trong trường hợp 250ms mặc định “Sample Interval” trong LoadTest Options dialog. Biểu đồ thể hiện:

Biểu đồ Statistics History cho ta thấy tất cả các số liệu thống kê cơ bản cho các TestStep lựa chọn (hoặc Total như trong ảnh chụp màn hình) được export, cho phép bạn import file này vào các ứng dụng khác để vẽ biểu đồ và phân tích.

4.3. Export Data Continuously

Xuất báo cáo sau mỗi lần chạy testcase, sẽ ghi lại báo cáo của mỗi Step cũng như chung của cả testcase. Sau khi chạy Loadtest được kết quả thống kê sau:

Thực hiện export report data, như hình minh họa:

Ta được report:

Mở file report ta thấy được sự thay đổi của các thông số [date,threads,elapsed,min,max,avg,last,cnt,tps,bytes,bps,err,reason] sau mỗi sự thay đổi (+1) của ThreadCount

5. Kết luận:

Trong bảng thống kê kết quả sau mỗi lần thực hiện Loadtest: Dựa vào 2 thông số avg và err: Average time và Error % theo chuẩn thì Avg time <= 3s là passed Error % <=0.08

Trung bình 3 lần chạy với cùng thông số, sẽ lấy kết quả cuối cùng, do có sự chênh lệch tùy thuộc vào tốc độ mạng.

6. Reference:

Tính TPS / BPS Calculation of the different values in the Statistics table is straight-forward for all columns except TPS (transactions per second) and BPS (bytes per second) which can be calculated in two different ways (controlled by the "Calculate TPS/BPS" setting in the LoadTest Options dialog); Tính toán các giá trị khác nhau trong bảng kê là minh bạch cho tất cả các cột trừ TPS (transactions per second) và BPS (bytes per second) mà có thể được tính theo hai cách khác nhau (điều khiển bởi các "Calculate TPS/ BPS " thiết lập trong hộp thoại LoadTest Option);

Căn cứ vào thời gian thực tế được thông qua (mặc định):

TPS: CNT / giây trôi qua, tức là một TestCase đã kéo dài trong 10 giây và xử lý 100 yêu cầu => sẽ nhận được một TPS = 10
BPS: Bytes / Thời gian trôi qua, tức là một TestCase đã kéo dài trong 10 giây và xử lý 100.000 byte sẽ có được một BPS của 10000.

Căn cứ vào thời gian thực hiện trung bình:

TPS: (1000 / avg) * THREADCOUNT, ví dụ trung bình = 100 ms với 10 chủ đề sẽ cung cấp cho một TPS 100
BPS: (byte / CNT) * TPS, tức là số lượng trung bình các byte theo yêu cầu * TPS.

6.1. LoadTest Window

Tổng quan - LoadTest Window ** Component Description**

LoadTest Toolbar: Overall control of the LoadTest Project (kiểm soát tổng thể của dự án thử tải)
Strategy Bar: Control the LoadTest strategy
Statistics Table: Display the statistic data in table form (Hiển thị các số liệu thống kê trong bảng)
LoadTest Log: Examine the current LoadTest execution log (Kiem tra log LoadTest thuc tai)
LoadTest Assertion: Examine the assertions of current LoadTest
Setup Script: Setup a script before the TestCase begins
TearDown Script: Setup a script after the TestCase ends
Report Script: Setup a script when generating TestCase Report
Report Parameters: Examine the Report properties