Web Application Testing Guide
This web testing guide explains the key differences between desktop and web testing, introduces key concepts in web application development, explores web application testing techniques, and provides links to additional resources. When reading this guide, it is helpful to be familiar with the general application testing concepts introduced in the Ranorex Beginner’s Guide for User Interface Testing.
What is web testing?
Web testing verifies that a web application has the right functionality and design to deliver a great user experience, with the performance and security that users expect. As the name implies, a web application runs in a web browser, rather than being installed on a user’s device. This approach has several advantages for developers. Web applications run any device that can access the Internet, including desktop computers, tablets, and mobile phones. When the application is updated, new features or other changes are immediately available to users: it is not necessary to download or install an update. The table below shows how a typical web application compares with other types of applications.
How does web testing compare to desktop application testing?
Functional testing ensures that the application does what it is supposed to do, as defined by user requirements and/or acceptance criteria. For example, functional testing of a banking application would include tests for the most common use cases, such as the ability of a user to log on, view their account balance and recent transactions, pay a bill online, and print their statement. When it comes to verifying the functionality of a user interface, there is little difference between testing a web-based application and a desktop application.
Cross-browser compatibility testing
Web applications must be compatible with all popular browsers. In cross-browser testing, a tester runs the same set of functional tests for each popular browser to ensure that the application behaves consistently. Since cross-browser testing involves repeating the same test cases, automating these tests can save valuable testing time and provide a good return on investment.
Responsive design testing
A web application must be responsive to the varying screen sizes and orientations of desktop computers, tablets, and mobile phones. Refer to the Ranorex Beginner’s Guide for Mobile Application Testing for more information about testing web applications on mobile devices.
Desktop applications have a “state,” meaning that they have access to previous user actions such as button clicks or form entries. However, HTML pages in a web application are stateless, and instead, use small data files called “cookies” to maintain the session state. Therefore, an important part of web application testing is verifying the security and proper functioning of cookies.
While a desktop application generally has a single user, a web application may have hundreds or thousands of users. Major e-retailers have millions of users. In addition, web applications may experience extreme spikes in usage due to events such as new product releases, special discounts, and holiday shopping. Load testing ensures that the web application can handle normal volumes, while stress testing verifies the ability of the application to respond to extreme cases.
Web applications are vulnerable to an array of attacks, making security testing essential.
More information on each of these types of testing is provided in the sections below.
Web application testing: terms to know
Understanding the following terms will be useful as you get started with web application testing.
|Hypertext Markup Language. Along with CSS, HTML is the building block of a web page. HTML tags format the text on a page with headings, bullets, italics and bolding, active hyperlinks, and so forth. For example, the h1 tag marks the top-level heading on a web page.|
|Cascading Style Sheet. CSS describes the colors, fonts, page margins and other layout elements on a web page. For example, the CSS may format the h1 tag with a color, font-size, font-weight, and border.|
|Document Object Model. When a browser loads a web page, it combines the HTML page content with the CSS style definitions to create the DOM and display it to a user. The DOM has a tree-like structure. Each element of the web page is a node in the tree structure. DOM nodes are defined by their relationship to other nodes, such as
|Hypertext Transfer Protocol. A communication protocol used to exchange information between browser, client application, and server. HTTPS is a secured version of HTTP. HTTP consists of methods, such as GET to retrieve data, and POST to submit data for processing. HTTP is stateless, meaning that any given request has no access to previous requests. Therefore, web developers have to use methods such as cookies to “remember” the state of a session, such as whether or not a user is logged in to the application.|
|eXtensible Markup Language. A browser and a server can exchange only text information. XML is used to represent data as text and exchange it between browser and server.|
|A cookie is a small data file that stores information. There are several different types of cookies. For example, a session cookie lasts only as long as a user keeps a browser open and is deleted when the browser closes. By comparison, a persistent cookie lasts beyond a single browser session. A persistent cookie for a shopping site could keep track of items a user has placed in a shopping cart so that the user does not have to re-add them if the browser is closed before checking out.|
Looking deeper: understanding web technologies
It is possible to test the UI of a web application without knowing the underlying architecture – this approach is called “black box” testing and is the focus of most of this article. However, understanding the web technologies that comprise your particular application will help you move beyond testing the UI to testing other aspects of the application as well, using “white box” testing techniques.
One of the most common and well-established web stacks is known by the acronym LAMP: a stack that includes the Linux operating system, Apache web server, MySQL database and a client-facing application written in PHP (or Python or Perl).
Web application testing techniques
Below are the common web application testing techniques. As discussed in the Ranorex Beginner’s Guide for User Interface Testing, a testing technique describes “how” a test is performed.
Scripted and exploratory testing verifies the web application’s functionality. See below for a functional testing checklist.
Usability and user experience (UX) testing validate ease of use as well as the quality and consistency of design and content. This type of testing is often performed by customer or end-users.
Accessibility testing for persons with disabilities ensures that the web application is compliant with relevant regulations.
Cross-browser compatibility testing executes the same set of test cases against a range of browsers to ensure that the application works consistently in each browser.
Web application functional testing checklist
Functional testing addresses the following aspects of a web application. Elements to check on each page of the application include the following:
- Visual elements such as text, images, fonts, and colors
- Form field validation, such as ensuring that date fields only accept valid dates, numeric fields only accept correctly-formatted numbers in a valid range, and that mandatory fields cannot be left blank.
- Controls including buttons, drop-down menus, and navigation
- Links, including internal links, external links, and email links to ensure proper functioning and that there are no dead links.
- Data processing, to ensure that data is retrieved, updated, and saved or deleted properly.
- Session state handling, including the use of persistent and non-persistent cookies. More information on cookie testing is below.
- Search engine optimization, including the following:
- Headings are correct and use optimized H1 and H2 tags
- The TITLE tag contains a meaningful title
- The application pages are “crawlable”
In addition to checking individual elements, be sure to validate a typical user’s path through the system, called the “happy path.” For instance, a hotel booking website “happy path” would include searching for hotel room availability, selecting a room, entering reservation and payment details, and completing the reservation. It is important to also test the “sad path” negative test cases, such as no availability on a given date, and “bad path” error conditions such as a request for a reservation for a date in the past.
What is cross-browser compatibility testing?
Cross-browser compatibility testing verifies that an application provides a consistent user experience in all popular web browsers, including Google Chrome, Apple Safari, Mozilla Firefox, and Microsoft Edge/Internet Explorer. Because users may not always have the most recent version of a browser, it is important to test versions that may still be in wide use. The W3 website maintains monthly global statistics on market share for leading web browser versions.
Automating tests with Ranorex Studio greatly reduces the effort required for cross-browser testing. Once a test has been automated in one browser, it can be run for any other browser simply by changing a single parameter. See the Ranorex blog entry “Cross Browser Test Automation” for an example of automating a test for execution against multiple browsers.
What is web cookie testing?
Web applications have two common types of cookies: persistent cookies and session cookies.
Persistent cookies have an expiration date, after which the browser automatically deletes them. Test persistent cookies to ensure that the application is setting a proper expiration date. To see the expiration date for cookies in Google Chrome, click the Customize icon (three dots) in the Chrome toolbar, then click Settings > Advanced > Content Settings > Cookies. Scroll down to see the list of cookies, and expand each cookie to review detailed information including its creation date and expiration date.
Session cookies do not have a “valid until” date, and may be automatically deleted by the browser when it closes, depending on user settings such as “restore tabs on startup.” Given that it is not certain that session cookies will be deleted when a browser closes, it is important to understand how the AUT should respond to session cookies and test for this behavior. For instance, should a user stay logged in after closing the browser, or should the user be required to log in again?
Third-party cookies, also called tracking cookies, are a special type of persistent cookie that can be shared between websites, typically for the purpose of advertising. For example, if a user views an item for sale at an online shopping site, he or she may see an advertisement for that same item appear when visiting a photo-sharing or social media site. Ensure that your website provides a proper cookie consent form for users is required by local law. In particular, EU
Each browser has a slightly different process to manage cookies. For example, to delete all cookies in Google Chrome, click the “Customize” icon in the Chrome toolbar, then click Settings > Advanced > Clear Browsing Data. The screen shown below appears. Notice that one of the options available is to delete “cookies and other site data”.
Verify that a cookie either does not store sensitive data, such as usernames, passwords, or other personal data or that such data is properly encrypted. Also, check that the web application performs as expected when a user disables browser cookies or clears the cookie cache. This may include presenting the user with a prompt to re-enable cookies if required by the application. Finally, try editing the stored cookie to see if corrupted data cases the web application to crash, or if it is possible to circumvent the application’s security by changing data values in the cookie.
How to do performance testing for web applications
The goal of performance testing is to ensure that a web application can respond to user requests in an acceptable timeframe, even under a heavy load. The responsiveness of an application includes the time required for page reload and refresh, file upload/download, caching, and website navigation.
If a website is unable to handle the volume of traffic, response times can soar or the website itself may even crash. Performance testing looks for bottlenecks such as misconfigured servers or database row locking that cause unacceptable delays in response.
To conduct performance testing, begin by identifying the typical load expected for the website, as well as the maximum load. For example, an online game site may have a normal daily load of 5 million players, but the load may double or even triple when a new game is launched. Load testing verifies the ability of the AUT to perform well under the normal volume, while stress testing verifies its performance under the maximum expected load.
Performance test environment setup
For performance testing to provide valid results, it is important to set up the test environment to be as realistic a representation of the planned production environment as possible. This includes the number and type of servers, network bandwidth, interfaces, database configuration, and realistic test data. It is also important to isolate the test environment from other applications so that results are not skewed. While it is possible to use cloud infrastructure to mimic the production environment, the results of such testing may not be an adequate reflection of the actual production environment.
Once the test environment is set up, the next step is to create the proper load – a process called load injection. Performance testing tools that can assist in creating the simulated load include NeoLoad, Apache JMeter, HPE Load Runner, Borland Silk Performer, and Rational Performance Tester, among others
Performance testing workflow
The following list describes the common workflow for performance testing.
- Create entry/exit criteria for the performance test. Entry criteria might include that the application has passed all functional and regression tests and that a valid performance test environment is available.
- Set goals for performance such as expected response times, timeout handling, number of dropped connections.
- Run a baseline test, such as a single user scenario.
- Run one or more performance tests to analyze the response to typical use scenarios, beginning with a light load and then gradually ramping up to the desired test load.
- Run one or more stress tests to analyze the response to maximum use scenarios.
- Finally, it is a best practice to load test the application once it is in production, to ensure that changes such as network or server configuration settings have not introduced new performance bottlenecks.
How to do web security testing
One of the most important aspects of web application testing is ensuring that the application responds appropriately to security threats. Client-side security testing checks whether sensitive data is properly encrypted and not stored in temporary internet files. It also verifies SSL and session management – such as ensuring that user sessions are stopped after prolonged inactivity and that non-persistent cookies are deleted.
On the server side, security testing can include database and network configuration testing, checking that users have the minimum authorization needed to access data, and ensuring that protection is in place against Distributed Denial of Service (DDoS) and other types of attacks.
Penetration testing is a black-box approach which requires no knowledge of the AUT and includes techniques that hackers might use to compromise a web application. Security testing also incorporates white-box techniques such as static code reviews as well as automatic HTML and CSS analyzers.
The table below describes some of the most common client-side security threats and how to test for them. For a detailed exploration of web security testing, an excellent, free resource is the Open Web Application Security Project (OWASP)
|Type of Threat||Description||What to test|
|Password cracking||Attempts to gain access to a website by obtaining a user’s password. These can be done through brute-force attack routines that try every possible combination of characters, “dictionary” based attacks that test various combinations of words, starting with popular passwords, or “rainbow tables” that contain lists of encrypted (hashed) passwords matched to their plain text equivalents.||Ensure that the application has an appropriate response to multiple failed logins, such as adding a delay prior to the next login attempt, presenting a CAPTCHA test, or asking the user to answer a security question. Locking out a user after a certain number of login attempts is also an alternative, but the approach has a significant number of drawbacks (see OWASP for more information).|
|SSL/TSL attacks||Transport Layer Security (TLS) and the Secure Sockets Layer (SSL) are secure protocols for exchanging data between a browser application and the server. Attacks against these secure protocols take advantage of misconfigured servers or defects in the SSL/TLS encryption to intercept secure communications and steal data.||Use a tool such as Qualys SSL Labs Server Test or the DigiCert SSL Diagnostics Tool to validate properly configured secure protocols|
|URL manipulation||Modifying the URL of an HTTP GET request with malicious input parameters, such as user ID information.||Test that GET requests do not permit changes to stored data – only HTTP PUT requests should make changes to data, or that other protective measures have been taken by developers, such as encrypting the URL.|
|SQL injection||Malicious SQL statements entered into places like search boxes, login forms and even into a URL in order to access the database server. These statements can retrieve data such as usernames and passwords, insert data to create backdoors, and even execute commands on the server.||Ensure that developers use best practices for constructing SQL statements, such as using parameter values for user input. There are SQL injector vulnerability testers such as SQLMap – but these should be used with caution, as doing so can cause database corruption.|
|Cross-site scripting (XSS)||An XSS attack works by injecting a malicious script into the normal processing of the web application. The script may steal data from the user’s browser such as login credentials.||Ensure that the application uses best practices against XSS attacks, such as checking input for proper encoding, and configuring cookies with the HttpOnly setting so that their contents are accessible only to the server.|
Web application testing is essential to ensure that users have a consistent, secure, and responsive experience. To see how Ranorex can help you automate your web application testing and efficiently complete cross-browser and cross-device testing, download the free trial or contact a member of our sales team today.