4. Client Compatibility Test
1. Platform testing
There are many different operating system types in the market, the most common ones are Windows, Unix, Macintosh, Linux, etc. Which operating system the end user of the Web application system uses depends on the configuration of the user system. In this way, compatibility problems may occur, and the same application may run normally under some operating systems, but may fail to run under another operating system.
Therefore, before the release of the Web system, it is necessary to test the compatibility of the Web system under various operating systems.
2. Browser testing
The browser is the core component of the Web client, and browsers from different manufacturers have different supports for Java, JavaScript, ActiveX, plug-ins or different HTML specifications. For example, ActiveX is a product of Microsoft and is designed for Internet Explorer, JavaScript is a product of Netscape, Java is a product of Sun, and so on. Also, frame and hierarchy styles are displayed differently in different browsers, or not displayed at all. Different browsers have different settings for security and Java.
One way to test browser compatibility is to create a compatibility matrix. In this matrix, the adaptability of certain components and settings to different vendors and different versions of browsers is tested.
5. Safety test
The security testing areas of the web application system mainly include:
(1) The current web application system basically adopts the method of first registering and then logging in. Therefore, you must test valid and invalid usernames and passwords, pay attention to whether they are case-sensitive, limit how many times you can try, whether you can directly browse a certain page without logging in, etc.
(2) Whether the web application system has a timeout limit, that is, if the user does not click on any page within a certain period of time (for example, 15 minutes) after logging in, whether it needs to log in again to use it normally.
(3) In order to ensure the security of the Web application system, log files are crucial. It is necessary to test whether the relevant information is written into the log file and whether it can be traced.
(4) When a secure socket is used, it is also necessary to test whether the encryption is correct and check the integrity of the information.
(5) Server-side scripts often constitute security holes, and these holes are often exploited by hackers. Therefore, it is also necessary to test the problem that scripts cannot be placed and edited on the server side without authorization.
6. Summary
The web-based system testing methods have been discussed above from the aspects of function, performance, usability, client compatibility, security and so on.
Web-based system testing has similarities and differences with traditional software testing, which brings new challenges to software testing. Web-based system testing not only needs to check and verify whether it runs according to the design requirements, but also evaluates whether the system is displayed properly on different users' browsers. It is important to also conduct security and usability testing from an end-user perspective.
Notes on web page testing:
Web testing is often not valued by testers, and it is considered to be physical work without technical content. I will talk about some precautions in Web testing based on my work experience, which may be helpful to everyone. The testing process mainly considers HTML pages, TCP/IP communication, Internet links, firewalls, and some programs running on web pages (for example, applets, javascript, application plug-ins), as well as applications running on the server side (for example, CGI scripts) , database interface, logger, dynamic page generator). In addition, because there are many types of servers and browsers, the differences between different versions are small, but the performance results are different, such as connection speed, increasingly rapid technology and multiple standards and protocols. Of course, it can also be automated with the help of Web testing tools. Other things to consider are:
1. What is the expected load on the server (for example, the number of hits per unit time), and what kind of performance should it have under these loads (for example, server response time, database query time). What kind of testing tools are needed for performance testing (eg, web load testing tools, other testing tools that have been adopted, web automatic download tools, etc.)?
2. Who is the system user? What browser are they using? What type of connection speed to use? Are they internal or external to the company?
3. What kind of performance do you want on the client side (for example, page display speed? Animation, applets speed, etc.? How to boot and run)?
4. Is website maintenance or upgrade allowed?
5. Need to consider security aspects (firewall, encryption, password, etc.) and how to do it? How can it be tested? How reliable are the Internet sites that require a connection? How are backup system or redundant link requests handled and tested? What steps need to be considered when managing and upgrading web sites? What is the need for requirements, tracking, control of page content, graphics, links, etc.?
6. Which HTML specification needs to be considered? How strict? What changes are allowed to end-user browsers?
7. Are there any standards or requirements for page display and/or pictures occupying the entire page or part of the page?
8. Can internal and external links be verified and updated? How often?
9. Can it be tested on the product system? Or need a separate test system? Were browser caches, changes in browser operating settings, dial-up connections, and Internet "traffic jams" resolved during the test, and were these considered?
10. Can server log and report content be customized? Are they considered an integral part of system testing and need to be tested?
11. Can CGI programs, applets, javascripts, ActiveX components, etc. be maintained, tracked, controlled and tested?
18. What should be paid attention to in the evaluation of the test? Who is it mainly aimed at?
Expert analysis: The concept of review is very weak in China, but it is ubiquitous. For example, frequent code walk-throughs, project approval meetings, requirements discussions, etc. are actually a simplified review. Some companies call this "brainstorming" (it is often to gather everyone's wisdom to break through when encountering difficulties)
1. There are many things that can be reviewed, such as requirements, strategies, plans, use cases, codes... basically anything you can think of in the project can be reviewed.
2. The organizational review needs to have a clear purpose (this is an important part of the whole process), it is very simple, you first need to know, what do you need to get from this review? Maybe it is to hope that the reviewed stuff will be more perfect, maybe it is to increase the opportunities for everyone to communicate, or it may even be to cope with the inspections above and so on.
3. For different purposes of review, the participants will naturally change accordingly: For example, if you want to have a more complete review, theoretically all personnel related to the product, ranging from project managers to front-line sales personnel, need to participate. However, the more reviewers there are, the more difficult it is to arrange the time, so it needs to be cut according to the actual situation. Of course, it does not mean that a review must be attended by XX people. For example, a private communication between a BA and a customer or developer can also be counted as a review as long as detailed records are made.
Therefore, content-based review is actually informal. If an internal or external review is necessary to regulate, I can only say that it is just a formality.
4. Regarding the details of the organization review, one point is very important: do not "act as the book" during the review process.
Many companies do not make preparations before the review. During the review, they pull a moderator up and read the documents and PPT for a while. After half a day, they ask everyone if they have any questions, but the result can only be a few words.
Therefore, it is best to do a pre-review before the review, that is, before the review, give the reviewers a certain amount of time, maybe three or two days, maybe a week, so that the reviewers are familiar with the review objectives and put forward their own opinions. A unified procedure is collected and addressed one by one in the review. This effect will be much better.
5. Finally, talk about the more standardized review process
Determining review objectives——determining participants (including moderators, recorders, reviewers, etc.)—arranging review time—pre-review—organizing pre-review reports—reviewing—organizing review reports—authors revise review objectives—review (The review can follow a simple process, and the reviewers who make suggestions check whether their suggestions have been reasonably modified) —— archive
19. How to define the granularity of test cases? When encountering a test with complex functions, how should I write test cases?
Expert analysis: according to demand. For more complicated ones, you can draw the flow chart first, and then write the test cases.
Article source: The network copyright belongs to the original author
The above content is not for commercial purposes, if it involves intellectual property issues, please contact the editor, we will deal with it immediately