1. The difference between B/S architecture and C/S architecture
- B/S only needs to have an operating system and a browser, which can achieve cross-platform, zero-maintenance client, low maintenance cost, but low personalization ability and slow response speed
- C/S has fast response speed and strong security. It is generally used in local area networks, because it needs targeted development for different operating systems, and the maintenance cost is high.
2.HTTP protocol
The http protocol is also called the hypertext transfer protocol. When making network requests, we basically use the http protocol.
The http protocol includes requests and responses.
The request includes: request address, request method, request method includes get request and post request, the difference between get and post is that get request is followed by request parameters behind the address bar, but the size of request parameters is limited, and different browsers are different . Usually 4KB. The post request is mainly used to submit request parameters to the server. The parameters of the post request are placed in the request entity content, which is safer than the get request. In addition, there will be various request header information in the request, such as the supported data type, the source location of the request, and related header information such as Cookie header.
Response, mainly contains the status code of the response, like 200, 304, 307, 404, 500
There are also various response header information, such as setting cached response headers, Content-Type content type, and setting cookie header information.
- 200: (Success) The server has successfully processed the request
- 304: (Unmodified) The client sends a conditional request, but the resources on the server have not changed, then respond to this response status
- 307: (Redirect) Internal browser redirect
- 404: (Not Found) The server cannot find the resource requested by the client; Not Found
- 500: (Internal Server Error) The request could not be completed;
The full version of the PDF interview questions can join the following group:
3. The difference between POST and GET
- Get requests are generally to get data (in fact, it can also be submitted, but the common way is to get data); post requests are generally to submit data.
- Get is not safe, because during the transmission process, the data is placed in the URL of the request; all operations of Post are invisible to the user, and the request data is placed in the body (the most common scenario, user login password Submit, must use post request)
- The amount of data transmitted by Get is small, which is mainly due to the limitation of the length of the url; the amount of data transmitted by Post is relatively large, which is generally defaulted to be unlimited.
- Get requests can be cached, Post requests will not be cached
4. The difference and connection between Cookie and Session
- Both Cookie and Session are session technologies, Cookie runs on the client side, and Session runs on the server side.
- Cookies have a size limit and the number of cookies stored by the browser is also limited. Session has no size limit and is related to the memory size of the server.
- Cookies have potential security risks, and attacks can be carried out after finding your cookies through interception or local files.
- Session is stored on the server and will exist for a period of time before disappearing. If there are too many sessions, it will increase the pressure on the server.
5. Purpose of the test
To put it simply, it is to test for the user. The ultimate goal of the test is to ensure that the functions of the product that is finally handed over to the user meet the needs of the user, and to find and correct as many problems as possible before the product is handed over to the user.
6. What are the stages of software testing?
Unit testing , integration testing, system testing, acceptance testing.
unit test
Is the lowest level of testing activity to be performed during software development. In unit testing activities, independent units of software are tested in isolation from the rest of the program. The focus of testing is on the modules of the system, including subroutines. correctness verification, etc.
Integration Testing
Also called assembly testing or joint testing. On the basis of unit testing, all modules are assembled into subsystems or systems according to design requirements, and integration testing is carried out. Practice has shown that although some modules can work independently, it does not guarantee that they can work normally when connected. Problems that cannot be reflected locally in the program are likely to be exposed globally, affecting the realization of functions. The focus of the test is the connection between modules and the transfer of parameters.
System test
It is to assemble the tested subsystems into a complete system for testing. It is an effective method to verify whether the system can indeed provide the functions specified in the system scheme specification. The testing focuses on the operation of the entire system and compatibility with other software.
System Test Scope
Functional test, ui test, performance test, fault tolerance test, usability test, abnormal problem test, stability test, system stability test,
Compatibility test, interface test, security test, login authority test
Acceptance Test
It is the last link of software product inspection. Test and review the entire system in accordance with the project mission statement or contract, and the acceptance basis documents agreed by the supplier and the buyer, and decide whether to accept or reject the system.
Others are divided into several stages
回归测试：When testing a new version of the software, all test cases of a previous important version are repeated. Purpose:
1. Verify that all defects in previous versions have been fixed;
2. Confirm that fixing these defects does not cause new defects
冒烟测试：It refers to verifying whether the basic functions of the software are realized and whether they are testable before conducting a systematic large-scale test on a new version. Also called testability testing.
7. The difference between a test and ß test
а测试 It is a test conducted by a user in a development environment, or a test conducted by a user within the company in a simulated actual operating environment. ß测试 is an acceptance test. A beta test is a test performed at the premises of one or more users.
8. How to do the acceptance test?
1. Interface test; refers to whether the function buttons or interface can be displayed normally when browsing all the pages of the software product.
2. Functional test; whether the functions of the product can be realized normally.
3. Performance testing; the process of discovering performance bottlenecks, including multiple tests of CPU, memory, network environment, version, etc.
4. Security testing; product information confidentiality, password protection and other functional testing.
9. The difference between white box, black box and gray box testing
The difference between black box and gray box:
If a software contains multiple modules, when using black box testing, you only need to care about the boundaries of the entire software system, and you don't need to care about how the various modules in the software system cooperate. And if you use gray box testing, you need to care about the interaction between modules.
The difference between white box and gray box:
In gray box testing, you don't need to care about the internal implementation details of the module. For the internal modules of the software system, gray box testing still treats it as a black box. White-box testing also requires a deeper understanding of the implementation details and branches of internal modules.
10. Purpose of smoke test
Before formal testing, verify whether there are bugs in the main requirements or preconditions of the product or system.
11. How to do regression testing?
- 1. In the stage of test strategy formulation, formulate regression test strategy
- 2. Determine the version that needs regression testing
- 3. The regression test version is released, and the regression test is performed according to the regression test strategy
- 4. Pass the regression test and close the defect tracking list (problem list)
- 5. If the regression test fails, the defect tracking sheet is returned to the developer, the developer re-edits the problem, and submits the regression test to the tester again
12. Purpose of needs analysis
First, transform user requirements into functional requirements: 1) measure the progress of the test scope 2) measure the processing branch 3) measure the scene of the required business 4) clarify the input, processing and output corresponding to its function 5) define the hidden Formal requirements become explicit.
Second, clarify the five elements of testing activities: what is the test requirement, decide how to test, specify the test time, determine the testers, determine the test environment: the skills, tools and corresponding background knowledge required in the test, the possible encounters in the test process risk etc. Test requirements need to be as detailed and clear as possible to avoid test omissions and misunderstandings.
13. Purpose of the Test Plan
1. As early as possible, clarify the content (scope) of the test work, the method of the test work, and the various resources required for the test work.
2. All personnel involved in the testing work shall implement the issues that need to be considered and the preparation conditions for the next test work as soon as possible.
3. The focus of the test planning work is: the preparation and planning of the current work tasks and the exchange of information.
14. When to start writing the test plan
The test plan is a plan that is formulated together with the development plan after the requirements are sorted out. It belongs to one of the plans in the project plan.
15. Who will write the test plan
Project manager (considered from the perspective of the project)
test manager (considered from the perspective of the test team)
tester (written specific test plan)
16. Contents of the test plan
1. Test objective: briefly describe the test objective.
2. Test summary: a brief description of the software to be tested, terminology explanations, and relevant documents referred to.
3. Test scope: the scope and priority of the test software included in the test plan, which ones need to be tested, which ones do not need to be tested or cannot be tested or postponed.
4. Key matters: List all the main functions and test key points of the software to be tested. This part should be able to correspond to and check with the test case design.
5. Quality objectives: formulate product quality objectives and software testing objectives for testing software.
6. Resource requirements: software and hardware, testing tools, necessary technical resources, training, documents, etc. required for testing.
7. Personnel organization: How many people are required to conduct the test, their respective roles and responsibilities, whether they need relevant learning and training, when they need to start, and how long will it last.
8. Testing strategy: formulate the overall testing strategy, testing techniques and methods used.
9. Release submission: The software products, test cases, test data and related documents that need to be delivered after the test is released according to the test plan.
10. Test progress and task personnel arrangement: reasonably assign the test plan to different testers, and pay attention to the sequence. If the developed Release is uncertain, the time period of the test can be given. For long-term large-scale test plans, you can Use milestones to represent changes in progress.
11. Standards for test start/completion/delay/continuation: formulate test start and completion standards; sometimes, the test plan will be delayed for some reason (too many blocking bugs), and the test will continue after the problem is solved.
12. Risk analysis: The possible risks and solutions in the test plan need to be considered.
17. End conditions (conditions for project launch)
1. The software has been fully tested
Developer testing—>cross testing—>tester testing—>user’s business expert testing—>a certain number of user business experts concentrated testing—>trial run before going online——>going online.
2. User training
For administrators, there must be a person who has been trained in a certain factory or region.
3. The basic data import is completed
Basic data such as users, organizations, and business data must be imported.
4. Authorization must be completed
5. The switching between the old and new systems must be rehearsed in advance, and the import of various old data is completed.
6. An emergency plan must be in place.
18. Common Testing Risks
1. Requirement risk, 2. Test case risk, 3. Defect risk, 4. Code quality risk, 5. Test environment risk, 6. Test technology risk, 7. Regression test risk, 8. Communication and coordination risk, 9. R&D process Risks, 10. Other unpredictable risks
19. Elements of Test Cases
1. Use case number, 2. Test module, 3. Title of use case, 4. Test level, 5. Test purpose and conditions, 6. Test input, 7. Operation steps, 8. Expected results
20. Division of test case levels
Purpose of test case prioritization: Test case prioritization can be used to easily filter cases based on test strategy. For example, if there is a small change in a certain function, only use cases of height measurement or medium and high priority are used. For example, during smoke testing, we only need to filter the use cases with the highest priority for execution.
According to the purpose of our test case priority: the test points covered by the higher priority test case should be the most concerned by the user, such as a registration function, the priority of the use case that can be successfully registered is the highest (but not all registrations are successful) The case has the highest priority, you only need to choose one), other abnormal checks are of secondary priority, and some test points covered by the scene are difficult to appear, or even if there is a problem, the impact will not be affected. Large, can be placed in low priority
21. How to ensure that user needs are covered?
1. Confirm requirements, 2. Sort out requirements, confirm test scope, 3. Make test plan, 4. Write test cases according to test plan, 5. Execute test steps
22. The key to writing good test cases/dimensions to focus on when writing good use cases
1. Before the test:
1. Have a clear understanding of the purpose of the test, 2. Familiarize yourself with the functional test points of the product, 3. Familiarize yourself with the principle of modules to avoid "mutual influence" problems, 4. Pay attention to user scenario problems and Internet access problems ,
5. Key test case design that cannot be sloppy,
2. When writing test cases:
1. Construction of test case framework, 2. Design of test steps (one is that if the steps are too rough, it is easy to miss the test; the other is that the writing is too detailed, which may be time-consuming and labor-intensive, and will limit the thinking of the executive.)
3. Test case design method and thinking
1. Keep in mind the main goal of product testing, 2. Pay attention to the precise use of words
23. Common test case design methods
Equivalence class division, boundary value analysis, error inference method, decision table, orthogonal experiment method
24. When to use the scene method
Scenario method is suitable for solving systems or functions with clear business process and complex business. Scenario method is a testing method based on software business.
The purpose of using the scenario method is to use the business flow to string together the isolated function points to establish an overall business feeling for the testers, so as to avoid the wrong tendency of ignoring the key points of the business process in the functional details. Example: The typical business process of a voice call combines the functions of voice call, simultaneous vibration, voice message, call hold, and call transfer.
Basically every software uses the scenario method, because every software has business support behind it.
The scenario method is mainly used to test the business logic and business process of the software. When we get a test task, we don't first pay attention to the detailed test of a certain control (equivalence class + boundary value + judgment table, etc.), but first pay attention to whether the main business process and main functions are implemented correctly, which requires Use the scenario method. When there is no problem with the business process and main functions, we will test the details of the control from the aspects of equivalence classes, boundary values, and decision tables (first the whole and then the details).
Note: The key point of scenario method test case design is to test whether the business process is correct. During the test, it should be noted that the fact that there is no problem in the business process test does not mean that the functions of the system are correct. A detailed test must be carried out on a single function to ensure Adequacy of testing.
25. Handling of accidental problems
1. Be sure to submit bugs,
- 1. Remember that there is such a defect, and when you encounter it in the future, you may understand the cause of it.
- 2. Try to find the cause of the error, such as any special operation, or some operating environment.
- 3. Programmers are more familiar with the program than testers. Maybe you submit it, even if it cannot be reproduced, the programmer will understand the problem.
- 4. After the irreproducible problem reappears, you can directly call the programmer to take a look at the problem.
- 5. When recording bugs, try to describe clearly the test steps, test environment, and test data when a problem occurs.
2. Try to reproduce the bug,
26. When we think a certain place is a bug, but the development thinks it is not a bug, how to deal with it?
1. Inform the basis for judging the development bug, and at the same time clarify the reason why the development said it is not a bug.
2. Verify the reason for the development, based on 1. Refer to the requirements document, 2. Communicate and confirm with the product manager.
3. The verification result is not a bug, close the bug, if it is a bug, submit it to the development for processing to ensure product quality
27. What should testers do when users find bugs after the product is launched?
1. After the tester reproduces the problem, submit a problem ticket for tracking;
2. Assess the severity of the problem, the scope of impact when the problem is fixed, and which functions need to be tested for regression testing;
3. After the problem is fixed, first return to the test environment, and then apply a patch to the production environment after passing, and then perform regression testing;
4. Summarize the experience, analyze the cause of the problem, and avoid the same problem next time.
28. Twenty-eight theorem
Defects tend to pile up together. A module has found more defects than other modules. It usually does not mean that the module has exposed the defects, but it means that there are still as many defects in this module that have not been discovered. This is the famous 28 theorem: 80% of the defects appear in 20% of the modules.
29. How to track defects
When a defect is found, we need to submit a problem list to the development on ZenTao, and check whether the defect has been resolved at regular intervals (one hour or two hours is fine). If it is not resolved in time, we will prompt the development. Let the development fix the problem in time. After the problem is fixed, the regression test should be carried out in time.
30. Defect status
1. Initialization: the initial state of the defect;
2. To be assigned: the defect is waiting to be assigned to the relevant developer for processing;
3. To be corrected: the defect is waiting for the developer to correct it;
4. To be verified: the developer has completed the correction and is waiting for the tester to verify;
5. To be reviewed: the developer refuses to modify the defect, and needs to be reviewed by the review committee;
6. Closed: The defect has been processed.
31. Classification of Defects
Minor defects, general defects, serious defects, fatal defects
32. A defect ticket should contain these elements
Defect Title, Defect Type, Steps to Reproduce, Expected Result, Actual Result, Defect Priority, Attachment Remarks
33. Main content of the test report
What is included in the test report: Test module (each module needs to record the start time and end time of the test, how many use cases were designed, how many passed, how many failed, how many BUGs, how many BUGs were left, how many BUGs were resolved, and follow-up on this module in conclusion)
BUG statistics, according to the time axis to count the number of BUG, for example: XXXX X month X day, how many bugs were found, how many bugs were closed, how many remaining bugs, how many high-level bugs, how many mid-level bugs, low-level and recommended How many bugs are there, listed until the end of the project
Project summary, report the general results of the test.
Remains and risks, any remaining problems of the software, and any risks, must be explained one by one
Finally, judge whether the software meets the online standards, date, signature, stamp, etc.
34. How to locate bugs:
1. To find a bug, first check the detailed information of the bug, and initially analyze which module and which piece of code is the problem according to the description
2. Check the test environment, test code segment and test data that caused the bug, and eliminate the program exception caused by the misoperation of the tester
3. After confirming that the test code, test environment and data are correct, further analyze the root cause of the bug. Here we need to look at the specific test business, which can be analyzed with the help of relevant tools
4. If the product or business has relevant log records, the bug can be confirmed by analyzing the log
5. After a series of analysis, the testers can basically confirm the cause of the bug, and then they can directly ask the developer to raise the bug (pay attention to communication skills)
6. If the cause of the bug cannot be confirmed after analyzing all aspects, you can find the developer to locate it together (note that the bug scene is kept or the bug scene can be reproduced)
7. After confirming the bug, the bill of lading will be sent to the developer for bug tracking.
The following information should be clearly described on the problem sheet:
Specific test time, test environment, test scenarios, specific business and functions of the test, test code and test data used, test execution steps, test results, bug phenomena (preferably screenshots), log records, expected results, and bug confirmation related personnel etc.
8. Track bugs and perform regression testing after developers fix bugs. (Pay attention to whether the bug is completely fixed, whether it affects other functions, and whether it introduces new problems)
35. Development does not have time to fix, how to promote bug fixes:
1. For bugs with deep paths, when testing to promote development and fix bugs, you need to pay attention to the following points:
a) Analyze the seriousness of the problem from the user's point of view, analyze the probability of the user encountering this problem, and guide the development to think from the user's point of view, so that the development is aware of the seriousness of the problem
b) You can list a previous similar problem with the developer to provide a reference for development
c) The product is the person responsible for the software. When the testing and development opinions cannot reach an agreement, do not give up because you cannot promote the development and modification. You must find the product for confirmation, and the final decision is left to the product personnel.
2. The launch time is tight, and the development is too late to modify. At this time, the test should analyze the seriousness of the problem, and discuss with the product personnel whether it needs to be modified.
3. Bug modification The changes are large, the scope of influence is wide, and there is no optimal solution. It is taboo for such things to happen at the node where the project is about to go online. In the face of this situation, it is recommended that developers do research work, consult other colleagues, or organize an ad hoc meeting to gather everyone's strength to study a good modification plan
4. The third-party application problem cannot be modified by development. After confirming the reason, you need to find relevant staff, such as products, contact third-party staff, give feedback on the problem, and try to promote the application to solve the problem
summary
In short, whether the bug is repaired or not, the test should have its own principles, and at the same time weigh the pros and cons. You can't give up just because you can't push the development, let the bug go online, and you can't hold on to a small bug, which will affect the time to go online.
36. Software testing process
Understand user needs – “refer to requirements specification –” test plan (arrangement of human and material resources and time schedule) –” write test cases – “review use cases –” build environment – “test package arrangement forecast (smoke test) – formal test – bug -Report after the test – “Version Launched –” User-oriented
37. To test a ballpoint pen, what aspects should be tested? Triangular Test Case Design
Performance test
Can it be written normally? Is there any leakage of pen oil? Can the pen cap be pressed and popped up normally?
function test
How long can a pen be used and whether the written words fade
usability test
Is the length and thickness of the pen easy to use? Is it easy to replace a refill?
interface test
Whether the appearance is beautiful, fashionable and interesting
security test
Does the pen oil contain harmful substances? Is the pen tip easy to hurt people? How long is the shelf life of the pen oil or ink? Does it produce harmful substances?
compatibility test
Can it be used normally under different temperature, air pressure, and gravity? What is the result of writing under different paper quality and strength?
Triangular test case design:
1. When it is impossible for the three sides to form a triangle, an error will be displayed. When a triangle can be formed, the perimeter of the triangle will be calculated.
2. If it is an isosceles triangle, print "Isosceles triangle", if the sum of the squares of two isosceles is equal to the sum of the squares of the third side, then print "Isosceles right triangle".
3. If it is an equilateral triangle, then print: "Equilateral triangle".
4. Draw the program flow chart and design a test case.
Causality diagram, equivalence class division (recommended test method)
38. What classic bugs were found in the project? What causes it?
encoding problem
When the interface is limited to prevent brushing, the current is limited by the counter. If it exceeds a certain threshold, when a codeMsg object is returned to the front end for display, the displayed String is a problem of garbled characters. Previously, the return was always in json format. It is encapsulated in data.
This time the return is directly written to the response directly through the output stream to return the byte array directly, instead of the spring controller returning data (springboot defaults to utf-8), and there is a problem of garbled characters, which is encoded with utf-8 to solve it.
There are only two kinds of bugs that are difficult to solve. One is that there is a problem with the logic of the program, which leads to the inability to get the correct result. The second is some middleware and development environment problems.
(1) If there is a problem with the logic, if your project is relatively large, you can only use single-step debugging, or use System.out.println() to print out the desired data to see which step has the problem.
(2) If it is a problem with the development environment or middleware, the problem can only be solved by consulting the information on the Internet. If your English reading ability is OK, I recommend using Stack Overflow to check information.
39. How to carry out testing when the requirements document is not very detailed?
1. Take the initiative to understand the background and intention of this function, and what kind of problem is to be solved. This can be found in products or developers, or whoever asks for this function. After knowing these, you will have a good idea when testing. Know if the function is implemented correctly
2. Try to let people who are familiar with this business to test, so that some business problems of the function can be tested
3. Because there is no requirement specification, the test side only knows what the function looks like after the function is completed and transferred to the test. Therefore, it is too late to write the test case at this time, so we adopt this way of thinking to operate, and record the test while testing. points, and then review these test points in the group to see if there are any omissions.
40. How to find bugs in software as soon as possible?
Prioritize reproducible bugs. For some clueless bugs, you can discuss with experienced colleagues, bug amplification, binary positioning method, simulated scene, etc.
41. Is the card swallowing phenomenon of the ATM machine a BUG?
No, it is a security measure specially set up to prevent someone from being sloppy and forgetting to take out the bank card after the operation and being falsely claimed the money in the card. Therefore, a countdown timer is specially set up. If the bank card is not taken away within the time limit, the card will be swallowed
42. How to reduce the submission of non-problem sheets?
1. The summary description of the defect should be clear and accurate, so that the relevant development personnel can understand the problem at a glance.
2. A complete defect report must contain the necessary element information, such as: summary description, defect discoverer, test environment, browser, defect reproduction steps, severity level, assignee, functional module, etc., necessary Element information must be fully and clearly described.
3. Defect reproduction steps must be clearly described, so that the relevant development director can accurately reproduce the submitted defects according to the reproduction steps, so that they can locate the cause of the defect.
4. The assignment must be clear. If it is known that the defect belongs to a specific developer, it should be directly assigned to the corresponding person in charge, so as to reduce the time in the intermediate allocation process.
5. Test data, the test data is an important element information for reproducing defects, and the information used in the test must be clearly and accurately described. Let developers accurately reproduce defects based on the test data provided by the test.
6. Attachment screenshot information, attachment or screenshot information allows developers to understand the problem at a glance, so it is also very important to provide attachment or screenshot information when necessary.
7. The tone of the description of the defect content. When writing the defect list, try to use professional terms (reflecting the professionalism of the test). Secondly, pay attention not to use personal and objective tone when writing the defect report, so as not to affect the relationship between developers and testers. relationship between.
43. There is a program that runs very slowly on Windows. How to judge whether there is a problem with the program or the software and hardware system?
1. Check whether the system has moderate characteristics, such as: browser windows are opened continuously, file icons in the system are changed to uniform icons, CPU usage is kept above 90%, etc.
2. Check whether the software/hardware configuration meets the recommended standards of the software
3. Confirm whether the current system is independent, that is, it does not provide external services that consume CPU resources, such as: running a virtual machine
4. If it is software with C/S or B/S structure, it is necessary to check whether it is caused by a problem with the connection to the server or a problem with access;
5. When the system is not under any load, check the performance monitor to confirm the application's access to the CPU/memory,
44. How to test the search function
功能方面的测试：
Search for a single word, phrase, sentence, whether the retrieved content is accurate, and whether the link is accurate
Length: For example, if the input box supports 100 characters, then you need to test whether the maximum length is normal for 100 characters and 101 characters;
What are the supported character types: numbers, letters, Chinese characters, characters! @! #, special characters; (depending on demand)
There are spaces before and after the string, whether to filter the spaces before and after, and whether to keep the spaces in the middle; (depending on requirements)
Full-width and half-width letters and numbers (depending on demand)
性能方面的测试
How long does it take for search results to appear after clicking the search button
How long does it take to get to the search page
security testing
Can prevent SQL injection attacks, whether to prevent XSS attacks
User experience testing:
Whether the page layout is reasonable, whether the input box and the button are aligned
The size of the input box and the length of the button, whether the height is reasonable
Shortcut key: Can you select all, select part, whether copy, cut and paste is available, how to display the pasted string exceeding the maximum length
compatibility test
BS architecture: different browser tests, such as: IE, Firefox, Google, 360 and so on.
APP: Tested on mainstream mobile phones of different types, different resolutions, and different operating systems, such as Huawei, vivo, oppo, etc.
45. How to test the login function
功能方面的测试：
Enter the correct user name and password, click the submit button, log in successfully, and jump to the correct page
Enter the correct user name, wrong password, login fails, and prompts the corresponding error message
Enter the wrong user name, correct password, login fails, and prompts the corresponding error message
If the user name is empty, the verification login fails and a corresponding error message is prompted
If the password is empty, the verification login fails and a corresponding error message is prompted
Username and password are empty, click login
There are spaces before and after the user name and password, whether to process the spaces in between (depending on requirements)
性能方面的测试
How long does it take to open the login page
After entering the correct user name and password, how long does it take to log in successfully and jump to a new page?
安全性方面的测试
Whether the password is encrypted at the front end and whether it is encrypted during network transmission
Can the input box for user name and password prevent SQL injection attacks?
Whether the input box of user name and password can prevent XSS attack
Limit the number of wrong logins (to prevent brute force cracking)
Whether to support multiple users to log in on the same machine
A user logs in on a different terminal
User remote login
用户体验测试：
Whether the page layout is reasonable, whether the input box and the button are aligned
The size of the input box and the length of the button, whether the height is reasonable
Is it possible to use the keyboard for all operations, and is there a shortcut key?
Enter the user name, password and press Enter, whether you can log in
If the verification code is involved, it is also necessary to consider whether the text is too distorted to make it difficult to recognize, consider the color (color-blind users), whether the refresh or change button is easy to use
兼容性测试
BS architecture: different browser tests, such as: IE, Firefox, Google, 360 and so on.
APP: Tested on mainstream mobile phones with different models, different resolutions, and different operating systems, such as Huawei, vivo, oppo, Apple, etc.
46. If you are required to test Taobao's shopping cart, how would you design the test case and what aspects need to be considered.
1. After opening the Taobao page, is the layout of the page complete?
2. Whether the function buttons on the page can be displayed normally
3. Whether it will be displayed on the product page to add to the shopping cart
4. Whether the selected product can be added to the shopping cart
5. Whether all the information of the product can be displayed after adding to the shopping cart
6. Whether the products added to the shopping cart can be deleted
7. If the network is poor or no network can be successfully added to the shopping cart
8. After adding the shopping cart, will the quantity increase when the plus sign is clicked?
9. After adding the shopping cart, will the quantity be reduced when the minus sign is clicked?
10. If you click the minus sign to reduce to a certain level, will it prompt that it can no longer be reduced?
11. If the Taobao user is not logged in, will there be a prompt to log in first when adding to the shopping cart?
12. If no product is selected, click checkout, will the user be prompted "Please add items to be checked out"
13. Whether the total price of the selected product will be displayed after checking the product
14. After checking the item to display the total price, is the calculation of the total price correct?
15. After selecting the product and clicking the checkout button, will you enter the page for confirming the order information?
16. Is the total price on the confirmation order information page correct?
17. Will the total price be inaccurate, for example: the correct total price is 18.99, but the result shows that it is indeed 18.999999999999
18. Is there a back to top function?
19. Is it possible to edit product attributes
20. Can it be moved into the collection
21. Whether the store name is displayed
22. Is it possible to select all products
23. Is it possible to unselect all products
24. Is it possible to modify the specifications of the product in the shopping cart
25. Whether the quantity of added shopping exceeds the inventory quantity is limited
26. Is it possible to empty the shopping cart
27. Will the settlement amount change as the quantity of goods increases or decreases?
28. If there are too many refresh times, will there be a flashback phenomenon?
29. When the mobile phone calls, the Taobao page will still run
30. When the memory of the mobile phone is not enough, will Taobao freeze when running?
47. General rules for test cases
Finally, I would like to thank everyone who has read my article carefully. As a person who has been here, I hope that you will avoid some detours . Here I will share with you some learning resources for automated testing . If you can use it, you can take it away. I hope it can be given to you. Help along the way. ( Including Python programming, WEB automated testing, app automated testing, interface automated testing, testing framework, continuous integration, automated testing development, performance testing, security testing, big factory interview questions, resume templates, etc., and of course some testing basics, Tools, app testing, interface testing, linux, mysql database and other basic knowledge ), I believe it will make you better progress!
Information acquisition method:
