The most complete network, detailed arrangement of Web test points (examples of test scenarios + analysis of common problems)

Contents: Guide

foreword

Web Testing Checklist

Functional testing, interface testing, performance testing, security testing, compatibility testing

1. Functional test
Test all links in the web page, database connections, forms used to submit or obtain information from users, cookies, etc. in the web page.

Links: external links. internal links. Links to jump on the same page. Mail orphan page;
form: each field and default value. Optional and mandatory fields for wrong input processing;
Cookie test: Before writing to the user's machine, test whether the cookie is encrypted. If you're testing session cookies (i.e. cookies that expire after the session ends), check logged-in session and user statistics after the session ends. Check the impact on application security by deleting cookies.

Validate your HTML/CSS: If optimizing your website for search engines, then HTML/CSS validation is the most important item. The main thing is to verify the HTML syntax error of the website. Check if the website can be crawled by different search engines.

Database Testing:
Check data integrity and errors when editing, deleting, modifying forms or performing any DB related functions.

Check that all database queries are executed correctly and data is retrieved and updated correctly. More database testing could be a load on the DB, we'll address that in our website load or performance testing below.

2. Interface testing
In Web testing, the interface on the server side should be tested. You can verify that the communication is working properly. Servers should be tested for compatibility with software, hardware, networks, and databases.

The main interfaces are:
Web server and application server interface;
application server and database server interface;

Check that all interactions between these servers are performed and errors are handled correctly. If any query from the database or web server to the application server returns error messages, the application server should catch these errors and display them appropriately to the user.

Check what happens if the user aborts any transaction in the middle? Check what happens if the connection to the webserver in the middle is reset?

3. Performance Test
Test the performance of the application at different network connection speeds.

You need to test whether many users visit or request the same page. Can the system handle peak load times? A website should handle simultaneous requests from many users, large input data from users, simultaneous connections to DB, reloading of specific pages, etc.

In general, stress refers to stretching a system beyond its stated limits. Web stress testing is the process of breaking a website by applying stress. It checks how the system reacts to the stress and how it recovers from a crash. Generally put pressure on input fields, login and registration areas.

In terms of website performance, test and check for errors such as memory leaks on different operating systems and different hardware platforms.

Performance testing can be applied to understand the scalability of a website, or to benchmark performance in the context of third-party products such as servers and middleware.

Test on various networks such as fiber optic, telecom, mobile, etc.

Load: How many users are there at a time; check peak load and system performance; large amounts of data accessed by users
Pressure: Continuous load; performance in terms of memory, CPU, file processing, etc. Memory, CPU, file processing and other performance.

4. Security test
If you do not log in, you should not be able to use internal URLs; overreach; responses to invalid inputs; usually you should not directly access network directories and files; whether CAPTCHA can automatically log in scripts; SSL; logs.

5. Compatibility Test
Browser Compatibility; Operating System Compatibility; Mobile Browsing; Printing Options

Websites should be compatible across browser platforms. Browser compatibility testing is more complicated if features such as AJAX calls are used, security checks or validations are performed.

Test web applications on different browsers like different versions of Chrome, Internet Explorer, Firefox, AOL, Safari, Opera browsers.

Some functions in the web application may not be compatible with all operating systems, such as graphic design and interface calling, may not be available on all operating systems. So need to test your web application on different OS like Windows, MAC, Linux etc.

There may also be compatibility issues on mobile browsers and mobile devices.

If page printing options are provided, make sure that fonts, page alignment, page graphics, etc. are printed correctly. Pages should fit on the paper size or as mentioned in the print options.

Points to consider when testing your website

HTML pages, TCP/IP communications, Internet connections, firewalls, applications running on web pages (such as applets, javascript, plug-in applications) and applications running on the server side (such as CGI scripts, database interfaces, log applications, dynamic page generators, asp, etc.).

In addition, there are various servers and browsers, each with different versions. These include small but sometimes large differences in variations in connection speeds, rapidly changing technologies, and multiple standards and protocols. The end result is that testing of a website can become a major ongoing effort.

Examples of test scenarios:
What is the expected load of the server (such as the number of clicks per unit time)?
What kind of performance (such as web server response time, database query response time) is required under each load condition?
What kind of tools are needed for performance testing (such as web load testing tools, other internal tools that can be adjusted, web robot download tools, etc.)?
Who is the target audience? What browser will they be using? What connection speed will they be using?
Are they within the organization (so potentially using high connection speeds and similar browsers) or across the Internet (so using a variety of different connection speeds and browser types)?
What are the expectations for client-side performance (e.g., how quickly do pages appear, how quickly do animations, applets, etc. load and run)?

Is downtime for server and content maintenance/upgrades allowed? If allowed, how much time?

What kind of security is required (firewall, encryption, passwords, etc.), and what is it expected to do? How to test it?
How reliable is the Internet connection required for the website? How does this affect the requirements and testing of backup systems or redundant connections?
What process is required to manage updates to website content?
What are the requirements for maintaining, tracking and controlling page content, graphics, links, etc.?
Which HTML specifications will be adhered to? How strict is it? What changes will be allowed for the target browsers?
Are there any standard requirements for page appearance and/or graphics for the entire site or parts of the site?
How to verify and update internal and external links? How often and does it happen?
Can it be tested on a production system, or do I need a separate test system?
Browser caching, changes in browser option settings, changes in dial-up connections, and the Internet in the real world – how is the "traffic jam" problem tested?

How extensive or custom are the requirements for server logs and reports; are they considered an integral part of the system and do they require testing?

How to maintain, track, control and test CGI programs, applets, javascript, ActiveX components, etc.?

Unless the content is highly focused on one topic, pages should be 3-5 screens maximum. If larger, provide an internal link within the page.
Page layout and design elements should be consistent across the site so that it is clear to users that they are still on one site.
Pages should be as browser-independent as possible, or served or generated based on browser type.
All pages should have external links and there should be no dead pages.
Every page should include the page owner, revision date, and a link to the contact or organization.

Frequently Asked Questions about Web Testing:
The following should be the various questions that testers will think of when they consider a website that has been developed and can be exposed to the public.

Is the website functioning as expected?
Will end users find the site easy to navigate?
Is the website accessible on different devices owned by end users?
Is the website secure enough?
Is the website performance up to par?
Is the data entered on the website accurately stored and persisted across the board?
Does the website integrate well with other interfaces in the workflow?
Will the website perform as expected after it goes live?

The following is the most complete software test engineer learning knowledge architecture system diagram in 2023 that I compiled