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 on the client side, and low maintenance costs, but low personalization ability and slow response speed. C/S has fast response speed and strong security, which is suitable for general
applications In the local area network, because it needs to be developed 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.
The response mainly includes the status code of the response, such as 200, 304, 307, 404, 500,
and various response header information, such as setting the cached response header, Content-Type content type, and setting cookie header information.
200: (Success) The server has successfully processed the request
304: (Unmodified) The client issued a conditional request, but the resource on the server has not changed, then respond to this response status
307: (Redirect) The browser internally restarts Directed
404: (not found) the server cannot find the resource requested by the client; Not Found
500: (server internal error) cannot complete the request;
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, it must be requested by post)
The amount of data transmitted by Get is small, mainly due to the limitation of the length of the url; the amount of data transmitted by Post is relatively large, and it is generally defaulted to be unlimited.
Get requests can be cached, Post requests will not be cached
At the same time, I have also prepared a video tutorial on software testing. If you need it, you can watch it directly below, or click the small card at the end of the article to get the information document for free
Where to watch the video tutorial:
https://www.bilibili.com/video/BV1SY4y1p7k6/?spm_id_from=333.999.0.0&vd_source=74d0257ec7066cc4f9013524f0bb70134. 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. The 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
Regression Testing
When testing a new version of the software, all test cases of a previous important version are repeated. Purpose:
1. Verify that all defects generated by the previous version have been fixed;
2. Confirm that the repair of these defects does not cause new defects
smoke test
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
аTesting is a test conducted by a user in a development environment, and it can also be a test conducted by a user within the company in a simulated actual operating environment.
ß testing is a type of acceptance testing. 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 piece of 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 within 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 test strategy formulation stage, formulate a regression test strategy
2. Determine the version that requires regression testing
3. Release the regression test version, perform regression testing according to the regression testing 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. The 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: The summary describes the software to be tested, the explanation of terms, and the 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 each other 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 resolved.
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
As an administrator, one person must have been trained in a certain factory or region.
3. The import of basic data is completed.
The import of basic necessary data such as users, organizations, and business data is completed.
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 must be 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
before testing:
1. Have a clear understanding of the purpose of the test
2. Familiar with the functional test points of the product
3. Familiar with the principle of modules to avoid the problem of "mutual influence"
4. Focus on user scenario issues and Internet access issues
5. Key test case design that cannot be sloppy
When writing test cases:
1. Build a test case framework
2. The design of the 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.)
Test case design method and thinking
1. Keep in mind the main goal of product testing
2. Pay attention to the precise wording
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 falling into the wrong tendency of ignoring the main 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
Be sure to file a bug
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.
Try to reproduce the bug
26. When we think a certain place is a bug, but the development thinks it is not a bug, what should we do?
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 influence when the problem is fixed, and which functions need to be tested for regression testing;
3. After the problem is fixed, first in the test environment Regression, patch the production environment after passing, and then perform regression testing;
4. Summarize 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;
3. To be fixed: the defect is waiting for the developer to correct;
4. To be verified: the developer has completed the correction and is waiting for the tester to verify;
5. Pending review: The developer refuses to modify the defect and needs to be reviewed by the review committee;
6. Closed: The defect has been processed.
31. Defect level
Minor defects, general defects, serious defects, fatal defects
32. The defect list should contain these elements
Defect Title, Defect Type, Steps to Reproduce, Expected Result, Actual Result, Defect Priority, Attachment Remarks
33. The 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 To sum up)
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, how many low-level bugs How many bugs and suggestions are there, listed until the end of the project
Project summary, report the general results of the test.
Remains and risks, what are the remaining problems of the software, and what are the risks, all must be explained one by one, and
finally judge whether the software meets the online standards, date, signature, stamping, 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 caused by the misoperation of the tester Abnormality
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 tester can basically confirm After the cause of the bug, you can directly find the developer to raise the bug (pay attention to communication skills)
6. If you can’t confirm the cause of the bug after analyzing all aspects, you can find the cause of the bug together with the developer (note that the bug site can be 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 question sheet:
specific test time, test environment, test scenario, specific business and function of the test, test code and test data used, test execution steps, test results, bug symptoms (preferably screenshots), Log records, expected results, 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 severity of the problem from the user's point of view, analyze the probability of the user encountering this problem, and guide the developer to think from the user's point of view, so that the developer is aware of the seriousness of the problem b) You can list a previous problem with the
developer For similar issues, provide references 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 handed over 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 Testing
Can it be written normally? Is there any leakage of pen oil? Can the pen cap be pressed 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?
Coding 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 json The format 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 documents are 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 whether 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 here can only be done after the function is completed, and the test is performed. Only then do we know what the function looks like, so it’s too late to write test cases at this time, so we adopt this idea to operate, record the test points while testing, 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, there is no external service that consumes CPU resources, such as: virtual machine running
4. If it is a C/S or B/S structure software, you need to check whether it is due to the connection with the server There is a problem, or there is 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
functional testing
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 100 characters, 101 characters, and whether the display of the maximum length is normal;
which are the supported character types: Numbers, letters, Chinese characters, characters! @! #, special characters; (depending on requirements)
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 requirements)
performance testing
After clicking the search button, how long does it take for the search results to appear?
How long does it take to enter 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, whether
the size of the input box, the length of the button, and the height are reasonable
Shortcut keys: whether all selection, partial selection, copy, cut and paste are available, and 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
functional testing
Enter the correct user name and password, click the submit button, the login is successful, and jump to the correct page
Enter the correct user name, wrong password, login fails, and prompt the corresponding error message
Input the wrong user name, correct password, Login fails, and prompts the corresponding error message
User name is empty, verification login fails, and the corresponding error message is prompted
Password is empty, verification login fails, and the corresponding error message is prompted
User name and password are both empty, click login
username and password There are spaces before and after, whether to process the spaces in the middle (depending on requirements)
performance testing
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?
security testing
Whether the password is encrypted at the front end and whether it is encrypted during network transmission Whether the input
box of user name and password can prevent SQL injection attack Whether the input
box of user name and password can prevent XSS attack Whether the number of wrong logins is limited
(to prevent brute force cracking)
Support multiple users to log in on the same machine,
one user logs in on different terminals, and
users log in from different places
User Experience Testing
Whether the page layout is reasonable, whether the input box and the button are aligned Whether
the size of the input box, the length of the button, and the height are reasonable
Whether it can be operated with the keyboard, whether there is a shortcut key
Enter the user name and password and press Enter, whether it can log in
involves verification For coding, it is also necessary to consider whether the text is too distorted to make it difficult to recognize, consider the color (for color-blind users), whether it is easy to use the refresh or change button
compatibility test
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, whether the layout of the page is complete
2. Whether the function buttons of the page can be displayed normally
3. Whether it will display Add to Cart on the product page
4. Whether the selected product can be added to the shopping cart
5. Add to the shopping cart Whether it can display all the information of the product
6. Whether the product added to the shopping cart can be deleted
7. If the network is not good or there is no network, whether it can be successfully added to the shopping cart
8. After adding the shopping cart, click the plus sign Will the quantity increase?
9. After adding to the shopping cart, will the quantity decrease when you click the minus sign?
10. If you click the minus sign to reduce to a certain extent, will you be prompted that it can no longer be reduced?
11. If the Taobao user is not logged in, if you add Will it be prompted to log in first when entering the shopping cart
? 12. If no product is selected, click checkout, will the user be prompted "Please add the product to be checked out"?
13. After checking the product, will the total price of the selected product be displayed?
14. After checking the total price of the product, is the calculation of the total price correct?
15. After selecting the product and clicking the settlement button, whether the page for confirming the order information will be entered. 16. Is
the total price of the page for confirming the order information correct ? The accuracy
is inaccurate, for example: the correct total price is 18.99, and 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 ? .Can you select all products ? 23. Can you cancel the selection of all products ? 24. Can you modify the specifications of the products in the shopping cart?
25. Whether the number of added shopping exceeds the inventory quantity is limited.
26. Whether it is possible to empty the shopping cart.
27. Whether the settlement amount will change with the increase or decrease of the quantity of goods
. 28. If there are too many refreshes, will there be a flashback? Phenomenon
29. When the mobile phone calls, the Taobao page will still run.
30. When the mobile phone memory is not enough, will Taobao freeze when running?
Organized a wave of previously released software testing resources [click the small card at the end of the article to get it for free] , no routines to get it!
Basically covers all the core technical points of software testing: testing theory, Linux foundation, MySQL foundation, Web testing, interface testing, App testing, management tools, Selenium related, performance testing, computer network, composition principle, data structure and algorithm, logic Questions, human resources, technical brain maps, etc... the quality is very high! ! ! More than enough for technical interviews!
The entire document has more than 200 pages in total, and it is definitely unrealistic to show you all. In order not to affect your reading experience, only part of the content is shown. I hope you will bear with me. I hope it can help you review before the interview and Find a good job, and save everyone's time searching for information on the Internet to learn! I hope everyone can gain something!
