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?
How does web testing compare to desktop application testing?
Cross-browser compatibility testing
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.
Web application testing: terms to know
|HTML||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.|
|CSS||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.|
|DOM||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
|HTTP||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.|
|XML||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.|
|Cookie||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
- 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”
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?
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
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
Performance testing workflow
- 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.