Web Services Automated Testing via SoapUI Tool
11 likes32,254 views
soapUI is a tool for testing APIs, including SOAP and REST web services. It allows testing functionality, security, performance, and documentation. Key features include testing API functions with parameters, negative testing, security testing like SQL injection and XSS, load and performance testing, and documentation logging. The tool supports SOAP, REST, and HTTP services. Projects contain elements like WSDL/WADL files, services, test cases, test steps, and property transfers between steps. Test cases validate requests with parameters and assertions. Security tests simulate attacks. Performance tests assess response times and throughput under varying loads. Mock services emulate real services for testing without dependencies.
![Security tests
SQL Injection : tries to exploit bad database integration coding.
statement = "SELECT * FROM `users` WHERE `name` = '" + userName + "';“
userName = ' or '1'='1
XPath Injection : tries to exploit bad XML processing inside your target service
String xpathQuery = "//user[name/text()='" + request.get("username") + "' And
password/text()='" + request.get("password") + "']";
userName = lol' or 1=1 or 'a'='a
Boundary Scan/Ivalid types : tries to exploit bad handling of values that are outside of
defined ranges or of different type, e.g.:
xsd:min, xsd:max, xsd:length, xsd:minInclusive, xsd:maxInclusive, xsd:minExclusive,
xsd:maxExclusive, xsd:totalDigits, xsd:fractionDigits
Continuation on the next page…
What attacks are you able to simulate?](https://image.slidesharecdn.com/webservicesautomatedtestingviasoapuit-130926101118-phpapp02/85/Web-Services-Automated-Testing-via-SoapUI-Tool-11-320.jpg)
Web Services Automated Testing via SoapUI Tool
- 2. Introduction SOAP and REST services: main QA aspects Compliance to protocols’ standards Functional testing • API functions tests with supported parameters range • Negative tests Security testing Load and Performance testing Usability testing Documentation and Logging Most of these types can be tested with soapUI. • It supports SOAP, REST and regular Web services via HTTP protocol • It has a multi-OS test-runner that can be integrated into a build server
- 3. Main elements Available elements of a soapUI project Web Service Description Language (.wsdl) file • A default config element for Simple Object Access Protocol (SOAP) services Web Application Description Language (.wadl) file • A default config element for REpresentation State Transfer (REST) services REST Service • A config element of a REST service, created manually Mock Service • A config element of a Stub Service that can emulate several operations (see below) Test Suite • An element containing Test Cases and Web Test Cases (see below) • Can contain Setup and TearDown scripts
- 4. Test Cases What types of Test Cases does soapUI support? Test Case • A set of requests to any service/server • Includes test steps, load tests and security tests • Can contain Setup and TearDown scripts Web Test Case • A set of requests to a web server with support of HTTP recording • Includes test steps, load tests and security tests • Can contain Setup and TearDown scripts
- 5. Test Steps What types of Test Steps does soapUI support? Test Request – a request to a SOAP service REST Test Request – a request to a REST service HTTP Test Request – a request to a HTTP server JDBC Request – a query to a Database Property Transfer – a special step allowing to transfer parameters between other Test Steps Groovy Script – a script that can do any action Delay – a pause Conditional Goto – goes to a given step if an XPath expression applied to the previous step returns true; otherwise goes to the next step Security Test – a test request with specific parameters and assertions Load Test – a set of test requests with specific statistics Etc…
- 6. Main testing cycle How are most of test cases written? Parameters Test Request Assertions Property Transfer Parameters • Three-level hierarchy: Project level, Test Suite level, Test Case level • Accessible from Property Transfer elements, from Groovy Scripts and from any place as expressions ${#Level#Name}
- 7. Main testing cycle What elements are in Test Requests? Resource/Method (for SOAP/REST requests) or EndPoint (for Web request) A list of pre-defined parameters with values: • Template parameters – <endpoint>/<path>/val1/val2 • Query parameters – <endpoint>/<path>?par1=val1&par2=val2 • Matrix parameters – <endpoint>/<path>;par1=val1,val2 • Header parameters – par1: val1 Accept Header Content-Type Header (for requests with content) Additional Headers and Assertions (see below) Etc… Response – a result of a request, which can be presented in XML, JSON, HTML or Raw format
- 8. Main testing cycle What are main types of assertions? Assertions • Contains / Not Contains – checks if a response contains / does not contain a given fragment. Allows regular expressions • XPath Match – checks if a part of a response, obtained using XPath query, equals to a given fragment. Allows wildcards • XQuery Match – checks if a part of a response, obtained using XQuery expression, equals to a given fragment. Allows wildcards • Valid HTTP Status Codes / Invalid HTTP Status Codes – allows to specify a list of valid / invalid response codes • Script Assertion – allows to check any response element using a groovy script • Etc…
- 9. Main testing cycle XQuery assertion? Supports XPath and XML insertions Can convert nodes to attributes and vice versa Can return a part of xml tree Allows sorting Has a recurrent structure
- 10. Main testing cycle How to transfer properties? Property Transfer • Can transfer fragments of a test request object to pre-created parameters (in its hierarchy) or directly to another request • Can use XPath or XQuery when transferring, or transfer the whole response • Can transfer text content of a node or an XML tree • Supports JSON responses as well as XML ones Using Groovy Scripts for transferring properties • Can transfer wider set of values • Can transfer to any pre-created parameter
- 11. Security tests SQL Injection : tries to exploit bad database integration coding. statement = "SELECT * FROM `users` WHERE `name` = '" + userName + "';“ userName = ' or '1'='1 XPath Injection : tries to exploit bad XML processing inside your target service String xpathQuery = "//user[name/text()='" + request.get("username") + "' And password/text()='" + request.get("password") + "']"; userName = lol' or 1=1 or 'a'='a Boundary Scan/Ivalid types : tries to exploit bad handling of values that are outside of defined ranges or of different type, e.g.: xsd:min, xsd:max, xsd:length, xsd:minInclusive, xsd:maxInclusive, xsd:minExclusive, xsd:maxExclusive, xsd:totalDigits, xsd:fractionDigits Continuation on the next page… What attacks are you able to simulate?
- 12. Security tests Malformed XML : tries to exploit bad handling of invalid XML on your server or in your service XML Bomb : tries to exploit bad handling of malicious XML request (be careful) Malicious Attachment : tries to exploit bad handling of attached files • Corrupted or very large files intended to make the server to crash. • Files containing code that is harmful for the server or server to execute/parse, i.e. a virus targeted at the server. The Malicious Attachment Security Scan allows generation of corrupt files as well as attachment of user-selected files. Continuation on the next page… What attacks are you able to simulate?
- 13. Security tests Cross Site Scripting (XSS): tries to find cross-site scripting vulnerabilities Custom Script : allows you to use a script for generating custom parameter fuzzing values • The Custom Scan follows the basic model of the other parameter-based Security Scans but requires you to specify a script (Groovy, Javascript or Java) that will provide the values to send for each permutation, giving you maximum flexibility with how you can provoke your target services. e.g.: fuzzling test What attacks are you able to simulate?
- 14. Performance tests Validation of: • speed • scalability • stability characteristics Key types of performance tests It’s all about the load model that you choose… What are performance tests aiming at? By means of assessing: • response times • throughput • resource-utilization levels Term Purpose Performance test To determine or validate speed, scalability, and/or stability. Load test To verify application behavior under normal and peak load conditions. Stress test To determine or validate an application’s behavior when it is pushed beyond normal or peak load conditions. Capacity test To determine how many users and/or transactions a given system will support and still meet performance goals.
- 15. Performance tests Simple performance test in soapUI 1 2 Profit!
- 16. Performance tests And so what? Assertions! We allowed a max response of one second, 1000 milliseconds. And we see that number of errors is growing since responses take much more time. Create more complicated strategies and models, take reports, it’s all in soapUI…
- 17. Performance tests Load Strategies Choose load strategy corresponding your load model. More info on strategies: http://www.soapui.org/Load-Testing/strategies.html
- 18. API Mocking According to the Cambridge Dictionary something that is “mocked” is: “Not real but appearing or pretending to be exactly like something” So we are essentially talking about something that will not behave as a real service, but will only mimic the behavior of the service. A mock service is not the same as a full service simulation. A mock will only simulate a part, perhaps one specific interaction, of a system. While a service simulator will simulate the entire system and behave in an expected way for all calls. What is a Mock Service?
- 19. API Mocking The real service is not implemented • While serial development usually sux (slow) Services out of your control: • Test data • Life cycle • Availability & Access • Negative scenarios Charged services Prototyping 3rd-party Consumers Why should you mock a service?
- 20. API Mocking What do you need to run a mocked service? • A service contract (WSDL) to mock • Specify port to run the mock on from soapUI • Generate responses you need (positive or negative, static or dynamic) • Launch your mock What is your mock good for? • A MockService can simulate any number of WSDL contracts • Built in scripting functionality (Groovy) helps simulate almost any desired behavior • Fixed responses, random errors, dynamic results, etc. How is your mock managed and hosted? • You may run it from soapUI tool GUI • You may run it from command-line (Java-based multi-OS runner) • You may deploy it to a standard servlet container as a WAR How does soapUI help?
- 21. Slideshare - https://www.slideshare.net/Sperasoft/ SpeakerDeck - https://speakerdeck.com/sperasoft GitHub - http://github.com/sperasoft Check out more knowledge sharing here: Company site - http://www.sperasoft.com/ On Facebook - https://facebook.com/sperasoft On Twitter - http://twitter.com/sperasoft Learn more about Sperasoft: