By Bob Boydston and Tom Bindewald – UCI OIT Central Services

Over the last few years OIT Software QA has been involved in quality assurance testing and conducting performance measurements for various applications. In that period of time we have noticed that the results for these applications vary greatly especially in terms of how the QA testing and performance results can help a development team in identifying issues with an application’s overall quality and performance. What we have noticed is that those that employ Webservices have the easiest time in getting the application tested and once tested dealing with application performance issues.

Why? From a quality perspective, Webservices allow for each “method” to be tested individually. Through its interface each field in the method constrains the type of data that can be entered. This allows a test team to virtually specify the total number of test cases that are necessary. This includes both positive and negative types of testing.

From a performance perspective, each of the methods can be tested separately as well. Because the testing can be conducted from the level of a “method” then the results of a “method” allow for the development team to hone in on underlying issues. In other words, once the results come in the development team can quickly determine where there may be issues and focus on those methods that look problematic.

Webservices have two opposing types of application programming interfaces (aka API). One is called SOAP (Simple Object Access Protocol) and the other REST (Representational State Transfer). We don’t want to get into the battles between those who prefer one over the other but want to explain how they are used in terms of testing. As explained before you can test them at the method level (one operation) or from a scenario level. In fact, from a QA perspective you would want to test them at both levels; first at the method level and then from the creation of scenarios. The scenarios many times will emulate how the application will be developed, so it is important to know which methods will be used in the application and in what sequence. Ultimately, this is how the entire application gets tested. One example here at UCI is the UCPath project that utilizes ESBAT webservices both QA and Performance testing.

The most popular API is Rest. One of the main reasons is because REST allows for many types of data types and data formats like plain text, HTML, XML and JSON. While SOAP only uses XML. However, SOAP is excellent from the security level via the WS-Security extension.

Webservices from the Quality Perspective

So what is the process that makes the use of webservices an approach for better quality and better performance? Maybe the best way to explain is to show this by creating a sample application that is very simple for demonstration purposes.

Let’s say you have a web application that has the following features: User, User Role or User Profile, an Organization and the capability to Login and Logout. For each of these features we would want to utilize the four basic functions for handling data such as create, read, update and delete (also known as “CRUD” for those familiar with databases). For “Users” we’d want to perform functions like create a user, read a user’s information, update a user (or change information on a user) and delete a user.

So from a Webservice perspective we could create four methods (as explained above) or functions in the following manner: createUser, readUser, updateUser and deleteUser. Each of these methods would contain fields where data can be entered or modified.

Let’s look at createUser. One could imagine the following fields would be available: First Name, Last Name, Street Address, City, State, ZipCode and US Citizen. The first five fields would be alphanumeric fields. The ZipCode would be a numeric field. And the US_Citizen field would be a Boolean field.

To test this one would create positive tests for each of the fields, in other words, enter data that is constrained but appropriate for the fields. For the negative tests we would enter data that is not appropriate for that each field type. For the alphanumeric fields we could enter a Boolean values. For the (Zipcode) field we would enter a letter and Boolean value. Lastly, for the Boolean field I would enter both numbers and letters. We would, then, do the same type of testing for all other methods. How is this testing different than for other types of applications? It’s different because we’re testing to the constraints governed by the method. This means that the methods contain a limited range of functionality. Therefore, from a positive and negative perspective, you have tested every possible combination.

There other benefits to Webservice testing in that a tester can create scenarios by combining methods into suites. In this case, you could login, create a user, give the user a role, assign a user to an organization and then log out.

One other advantage of this scenario is that you can create a matrix of dependent methods. For instance, you cannot create a user role until you have created a user.

Webservice Tools

Two tools come to mind in the testing of webservices; SoapUi and Postman. While SoapUi can accommodate both SOAP and REST, Postman is essentially a REST client. Both tools allow for testing to occur at the method level and the scenario level. Also, both allow for validations to occur (pass or fail). Both have a free (open source) products but also applications with more convenient interfaces but at a price.

Webservices from the Performance Perspective

Many of the advantages of Webservices for QA are the same when measuring an application’s performance. The main advantage of using Webservices when testing for its performance is that the testing can take place at the level of a single method. Some methods are based at the business logic layer while others directly hit the database. Over the years of performance testing we have discovered, by and large, that database activity dominates application performance.

For database performance one can test using the CRUD methodology as it’s basis but especially in terms of retrieving data (get function) and updating or adding data (post or put function). Think of it this way, if you knew that hundreds or even thousands of users were attempting to retrieve data, you would want to know where potential bottlenecks may be hiding. Through Webservices you have the opportunity to discover this because you are able to isolate your search to a single method.

There are two popular applications that take advantage of webservices performance testing; mainly jMeter and LoadUi. jMeter is the most inclusive of the performance tools. The features are truly extensive. It is compatible with the following features: HTTP, HTTPS, SOAP, REST, FTP, JDBC (database connectivity), LDAP, mail, SMTP, POP3, IMAP, shell scripts, TCP, Java, multithreading and BeanShell.

LoadUi is a companion of SoapUi. Because it’s based on SOAPUI’s Webservice capabilities it allows for testing at the method level and at the scenario level.

Conclusion

Webservices have proven to be a boon not only in terms of an application’s quality but also in terms of its performance. In fact, it has become a standard within the IP industry. If you are building your application on webservices it allows you to build quality into your product as you create it. In the end, it is a great foundation for both quality and performance and OIT QA can be your partner in the process.