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.
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.
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.
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.
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.
Understanding the following terms will be useful as you get started with web application testing.
|
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. |
|
JavaScript
|
An HTML page is static – meaning that it doesn’t change in response to user input. To make static web pages work more like desktop applications, programmers use JavaScript or a similar programming language to add responsive functionality such as clickable buttons. jQuery is a free, open-source library of JavaScript functions that speed up the process of web page development. |
|
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. |
|
JSON
|
JavaScript Object Notation. JSON is similar to XML in that it is a way of exchanging data as text between a browser and a server. Where JSON differs from XML is that JSON objects are ready-to-use by JavaScript functions, where XML objects require an XML parser. |
|
AJAX
|
Asynchronous JavaScript and XML. AJAX combines JavaScript (or a jQuery function) with either JSON or XML to exchange data with a server and update web page elements in the background, without needing to reload the entire page. |
|
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. |
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.
The diagram below shows a web application divided into a “client side” and a “server side.” On the client side, HTML, CSS and JavaScript code make up the part of the application that presents the UI to the user. The client side uses HTTP requests to exchange information with the web server. Front-end unit testing validates the HTML, CSS and JavaScript code that makes up the part of the application that is visible to the user. There are several popular JavaScript frameworks available to web developers for front-end testing, including Mocha, Jasmine, and Karma.
The back-end application is usually written in languages such as JavaScript, Ruby, Python or PHP and is hosted on a web server such as the Apache HTTP web server. Data that the application needs is maintained in a back-end database – either a SQL database such as MySQL, Oracle or Microsoft SQL server, or a non-SQL database such as MongoDB. The final layer of the web application is the operating system that hosts the web server, such as Linux or Microsoft Windows Server. Together, these technologies are called the “web stack.”
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).
Another common web stack and competitor to the LAMP stack is known by the acronym MEAN: which includes the no-SQL MongoDB database, Express.js for data flow, AngularJS for data presentation, and Node.js as the web server. JSON is used to format data throughout the stack. Because the MEAN stack uses JavaScript and JSON on both the front-end and back-end, the complexity of the stack is reduced. In addition, the MEAN stack is not tied to one operating system, as is the LAMP stack.
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.
Functional testing addresses the following aspects of a web application. Elements to check on each page of the application include the following:
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.
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.
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.
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.
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
The following list describes the common workflow for performance 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.
There are more and more Android testing tools available for mobile app developers. These are our favorites for performance, accessibility, and security.
Regression testing and retesting are essential methodologies testers employ to ensure software quality. If you’re new to both or aren’t sure when to use which technique, this article should help. We’ll discuss the importance of regression testing in software testing. ...
DevOps test automation enables teams to work faster and create better products. These best practices and tools make it easier to implement test automation.
