1. Self-introduction
(Self-introduction is not limited to the following template, flexible expression)
Hello interviewer, my name is xxx, I am xx years old, and my hometown is xx city, xx province. After graduating in 20xx, I have been engaged in software testing work, and it has been xx years now.
So far, I have experienced x companies. The first job was in xxx company, and I worked for about x years as a test engineer, mainly responsible for the functional testing of the company's web and APP projects; the second job was in xxx company. . .
In the past few years of work, I have accumulated rich experience in functional testing, and I can independently be responsible for the functional testing of the project. In addition, he has also been responsible for the interface testing of the server, and can use testing tools to realize basic interface automation. Others like Linux and SQL are also used a lot. In terms of code, there are some Python foundations, and I am continuing to learn now.
The above is my basic situation, thank you!
2. Test basis
1. Low - How to develop a test plan
The test plan includes:
Test objectives, test scope, description of test environment, description of test type (function, security, performance, stability), test tools, division of modules, test leader, schedule of test execution rounds, test risks, etc.
2. Medium - how to ensure software quality in the project
Project quality is not guaranteed by only one person or a certain team, but the result of the joint efforts of the entire team. Therefore, there needs to be a standardized project process at the company level
A. Products, guarantee the product logic in the iterative process, make predictions about possible compatibility and upgrades, and give solutions
B. Architectural design, while satisfying the product expression, ensures the continuity of the design
C. Development, guarantee of product details, rigorous selection of technical solutions, consideration of compatibility, performance, full self-test after development, and strict compliance with development specifications
D. Test, verify the product logic, systematically verify the interaction design from the perspective of the user, and use as many technical means as possible to ensure the quality of the test
E. Operation and maintenance, formulate rigorous online process and authority control, do a good job of monitoring and alarming the production environment, and have emergency plans after accidents
3. What are the general contents of high-functional test cases?
core content:
Use case number, title, prerequisites, test steps, expected results, use case priority, module to which it belongs, input data, etc.
4. What are the design methods of middle-black box (or functional) test cases?
There are mainly equivalence classes, boundary values, process analysis, cause and effect diagrams, decision tables, scenario analysis, error guessing, etc.
5. What is the difference between high-APP testing and web testing
(1) From the perspective of the system architecture: the web end is generally a b/s architecture, based on a browser, and the app is a c/s architecture with a client.
(2) Compatibility: Web is browser-based, so it is more inclined to be compatible with different browsers (Chrome, firefox); App testing must rely on mobile phones, and pay more attention to compatibility of system version, resolution, screen size, etc. question.
(3) In addition to the functional test, the APP side also needs to pay more attention to some special tests, such as weak network test, interruption test, installation/uninstallation test, traffic/power test, mobile terminal performance test, etc.
6. High - found a bug, how to locate the problem of APP or server
A. Packet capture analysis, packet capture analysis on the interface, if there is an error in the parameters in the request, it is generally a bug on the client side; if the request is normal but the response is wrong, it is a bug on the server side
B. Log analysis, you can also check the client/server log to analyze whether there is any abnormal log information, so as to determine the specific reason
7. High - Tell me about your testing process
1> Requirements review and analysis
2> Make a test plan
3> Write test cases according to requirements documents
4> Test case review
5> Execute the smoke test after testing
6> Execute the first round of testing to find bugs
7> Execute regression testing to verify bugs
8> Execute the second round of testing
9> Deploy the project to the pre-production environment
10> Pre-production environment testing
11> Send test report
12> Project launched
13> Online verification (main process, verification of main function points)
8. High - How do you cope when the developer says it's not a bug?
The developer said it is not a bug, there are 2 situations:
One is that the requirements have not been determined, so at this time, you can find a product manager to confirm whether it needs to be changed or not.
The second is that this kind of situation cannot happen, so there is no need to modify it. At this time, you can first say as much as possible what is the basis for the BUG? If it is discovered by users or if something goes wrong, what bad consequences will there be?
If it still doesn't work, you can ask this question and confirm it with the development manager and test manager. If the final bug is determined not to be changed, it must be recorded in the test report for future reference.
9. Medium - What should I do if I encounter a probabilistic bug?
First of all, it needs to be clear that this type of bug also needs to be reported, clearly describe the operating environment, operation steps, data, and provide necessary logs, and note the possible reasons. Then be patient, use the method of elimination and wrong guessing to find the law, and if necessary, find the developer to locate, analyze and discuss together. If it is still not resolved in the end, it needs to be reflected in the test report, and the possible impact is analyzed, and everyone weighs whether the bug can be left behind.
10. Low - How to submit a quality defect tracker
First of all, it must be clear that the defect tracking list is not just for yourself, so the most important criterion for judging a high-quality defect list is that others can understand it at a glance, the title is concise and clear, and the steps are clear. The completeness of the defect also needs to be considered, such as defect level, functional module, version, reproduction steps, expected results, actual results, causes, log screenshots, etc.
11. How to divide low-bug priority and severity
Severe: Issues that require immediate resolution, such as freezes, unresponsive processes, crashes
High: Major functional errors of the software, or defects that cause data loss
Medium: General defects affecting software functionality and performance
Low: Defects that have a very slight impact on the quality of the software, mostly suggestive or UI-level issues
12. Medium - What is the key to doing a good job in test case design
1) Familiar with business requirements and user usage scenarios
2) Understand the impact of this requirement on other systems
3) Understand development technology implementation and database design
4) Write test cases from different dimensions, such as function, performance, security, compatibility, etc.
13. Medium - give you a project, how to carry out the test
1. Find relevant documents such as requirements description and project design, and analyze requirements.
2. Make a test plan, determine the test scope and test strategy.
3. Design test cases, including functions, compatibility, performance, security, etc.
4. Conduct test execution
5. Regression testing and sending test reports
14. High-bug life cycle
New: Newly discovered bugs, assigned to corresponding developers
Open: The developer confirms the bug and thinks it needs to be modified
Fixed: After the developer makes modifications, mark it as a fixed state, waiting for the tester's regression test verification
Rejected: If the developer thinks it is not a bug, the modification is refused
Delay: If it is considered that there is no need to modify or cannot be modified temporarily, the modification is postponed and a reason needs to be given
Closed: The bug that modifies the state is verified by the regression tester of the tester, and the bug is closed
Reopen: If it is verified that the bug still exists, you need to reopen the bug and the developer will re-modify it
Later: Delayed modification (fixed in the next version)
15. Low-difference between black box testing and white box testing
Black box testing is to treat the system as a black box. It does not need to understand the internal details of the system, but only focuses on the input and output.
Input different data to verify that the output meets expectations;
White-box testing needs to understand the internal implementation details of the system, usually for testing functions, and needs to write test code to call the corresponding functions.
Test whether the return value of the function meets expectations by passing in different parameters.
16. What is included in the test report
Test scope, test time, participants, test strategy, number of bugs, online risk, remaining problems, whether the test passed
17. High - How to improve the coverage of use cases and reduce missed tests
1. Use cases should be written according to the requirements documents to ensure that each requirement is covered by the corresponding use cases
2. It is necessary to fully understand the business, discover hidden needs, and write corresponding use cases
3. In addition to normal business scenarios, consider some abnormal scenarios and data
4. It is necessary to test the software from multiple dimensions, considering functions, performance, security and other aspects
5. Think about problems from the user's point of view and simulate the user's usage scenarios
6. Organize use case review
18. High - When a bug is found, how to determine whether it is a bug
1. Look at the requirements document, whether there are clear requirements
2. Check whether this problem violates the behavior habits of normal people or the general norms of the industry
3. You can communicate with the product manager or developer to determine whether it is a bug
4. For problems that cannot be agreed, you can organize a meeting of relevant personnel to jointly decide whether it is a bug
19. High - How to carry out testing without requirements documents
The absence of a requirement document does not mean that there is no requirement.
You can find relevant personnel to communicate and obtain requirements, such as product managers and developers
You can refer to competing products in the same industry to summarize and sort out the needs
According to the user's usage habits and some industry norms, some functional requirements can be summarized
Space limit Only some interview questions and answers are shown here. The full version has been compiled into a document. You can click the card below to get it.