Interviews for testing positions are actually very similar. Here I have collected and compiled 185 high-frequency interview questions. I hope it will be helpful to everyone who is looking for a job or preparing to change jobs!
1. Test basics
1. How to develop a test plan
Reference answer:
The test plan includes test objectives, test scope, description of the test environment, description of the test type (function, security, performance, stability), test tools, module division, test leader, time schedule of test execution rounds, and related documents Position in the document management repository, risks of testing. The division of modules needs to be allocated based on the testers' familiarity with the business and personal abilities. The estimation of workload needs to be based on previous testing experience and combined with the modification of this requirement, the test volume can be roughly estimated.
2. How to ensure software quality in projects
Reference answer:
Project quality is not only guaranteed by one person or a certain team, but the result of the entire team's joint efforts. There needs to be a standardized project process at the company level.
1. For products, ensure the product logic during the iteration process, make predictions about possible compatibility and upgrades, and provide solutions
2. Design, while satisfying product expression, ensures the continuity of design.
3. During development, product details must be ensured. The selection of technical solutions must be rigorous, considering compatibility and performance. After development is completed, full self-testing must be carried out and development specifications must be strictly followed.
4. Test and verify product logic, conduct systematic verification of interaction design from the user's perspective, and use as many technical means as possible to ensure test quality
3. What do functional test cases generally include?
Reference answer:
Elements generally include: use case number, use case priority, test purpose, module to which it belongs, prerequisites, test environment,
Input data, test steps, expected results, test scripts, etc.
Core elements: use case priority, test purpose, expected results
4. What are the black box (or functional) test case design methods?
Reference answer:
Equivalence class division method: The equivalence class division method divides all possible input data (valid and invalid) of the program into several equivalence classes.
Boundary value method: Boundary value analysis method is a black box testing method that tests the boundary value of input or output.
Error speculation method: When testing a program, people can speculate on various errors that may exist in the program based on experience or intuition, and thus write test cases to check these errors in a targeted manner.
Cause-and-effect diagram method: The cause-effect diagram method is a testing method suitable for describing combinations of multiple input conditions. Based on the combination of input conditions, constraint relationships, and the causal relationship of output conditions, various combinations of input conditions are analyzed to design tests. The use case method is suitable for checking various combinations of program input conditions.
Decision table-driven analysis method: Decision table is one of the methods of black box testing. The decision table is a table formed by listing the various combination values of all inputs as conditions and the corresponding output values.
Orthogonal decomposition method: It is a design method for studying multi-factor and multi-level. It is based on orthogonality and selects some representative points from all the level combinations of test factors for testing. By analyzing the test results of this part, Analyze and understand the overall test situation to find the optimal level combination.
Scenario analysis method: Analyze software application scenarios and design test cases from the user's perspective. It is a user-oriented test case design method. Care about what users do, not what the product does.
Global exploratory testing method: Testers can freely explore various functions of the program based on the information provided by the application without any restrictions or constraints.
5.What is the difference between APP testing and web testing?
Web-side testing and mobile-side testing are basically similar in type. Both require functional testing, performance testing, and security testing.
In the test, they mainly distinguish between the web side, which is generally b/s architecture and browser-based, and the app, which is c/s architecture and has a client.
(1) From the perspective of system architecture: as long as the server is updated in the web test, the client will be updated simultaneously; and if the server is modified under the app, it means that all core versions used by client users need to be returned. Test it again.
(2) Client performance: The Web may only focus on response time; the App may also care about traffic, power, CPU, etc.;
(3) Compatibility: The Web is based on browsers, so it prefers compatibility between browsers (IE, Chrome, Firefox) and computer hardware and computer system directions; App testing must rely on mobile phones or pads, not only the resolution Rate, channel size, and equipment system are important.
6. If a bug is found, how to determine whether it is an APP-side or server-side problem?
1. Packet capture analysis: Capture packets on the client and analyze whether the data returned by the server meets expectations, such as
If the server data is correct, then it is a client problem
2. Log analysis can be done by viewing the client/server logs and analyzing whether there are any abnormal log information.
to determine the specific reasons
7. Write test points for the installation function of the App?
1. Perform a normal installation test to check whether the installation is successful.
2. APP version coverage test. For example: first install a version 1.0 APP, and then install a higher version (version 1.1) APP to check whether it is overwritten.
3. Roll back version testing. For example: first install a version 2.0 APP, and then install a version 1.0 APP. Under normal circumstances, the version can be rolled back.
4. There is insufficient memory during installation, and a prompt pops up.
5. Follow the installation manual to make sure it is installed correctly.
6. Check what will happen if there are unexpected situations during the installation process (forced power outage, network disconnection, incoming calls, checking information), etc.
7. Through 'synchronization software', check whether some files are installed simultaneously during installation.
8. Install on mobile phones of different models, systems, screen sizes, and resolutions.
9. Whether the SD card is recognized during installation and installed to the SD card by default.
10. After the installation is completed, can the application be started normally?
11. After the installation is complete, restart the phone to see if the application can be started normally.
12. After the installation is completed, will it affect other applications?
13. After the installation is complete, can I add a shortcut?
14. After the installation is completed, will the anti-virus software treat it as a virus?
15. Install through multiple processes and check whether the installation is successful.
16. During the installation process, all prompt information must be in English or Chinese. Codes, symbols, garbled characters, etc. cannot appear in the prompt information.
17. After installation, whether to automatically start the program.
18. Whether to support third-party installation.
19. Click Cancel during installation.
8. What is the purpose of continuous integration?
Continuous integration refers to integrating code into the trunk frequently (multiple times a day).
There are two main benefits:
(1) Find errors quickly. Every time an update is completed, it is integrated into the backbone. Errors can be quickly discovered and it is easier to locate errors.
(2) Prevent branches from deviating significantly from the trunk. If integration is not frequent and the backbone is constantly being updated, it will become more difficult or even difficult to integrate in the future.
The purpose of continuous integration is to enable products to be iterated quickly while maintaining high quality. Its core measure is that before the code is integrated into the trunk, it must pass automated testing. As long as one test case fails, it cannot be integrated.
9. How to test paper cups
Functionality: paper cup capacity (empty cup, full cup liters, half cup liters); whether water can be drunk; paper cup shape (right cylinder, wide top and narrow cylinder, narrow top and wide cylinder, other shapes), paper cup Material (all paper, all plastic, half paper and half plastic), paper cup temperature resistance (cold water, hot water, cold water, ice), supported liquid names (water, coffee, milk, cola)
Safety: Does the cup contain poison or bacteria? How long does it take for the liquid to undergo chemical reactions (for example: odor)
Reliability: Damage to cups dropped from different heights
Portability: Whether the cup can be used normally in different places, temperatures and other environments
Compatibility: Whether the cup can hold juice, water, alcohol, gasoline, etc.
Ease of use: whether the cup is hot to your hands, whether it has anti-slip measures, whether it is convenient for drinking, how long it takes for the liquid to leak, and whether it contains a lot of hot water.
How long will it deform? How many degrees of hot water will it deform?
User documentation: Does the user manual provide a detailed description of the usage, restrictions, conditions of use, etc. of the cup?
Fatigue test: Fill the cup with water and leave it for 24 hours to check the leakage time and condition; fill the cup with gasoline and leave it for 24 hours to check the leakage time and condition, etc.
Pressure test: Use a needle and continuously add weight to the needle to see how much pressure it will penetrate; how long it will take to deform when squeezed by hand (single
hand, both hands)
10. How do you deal with it when the developer says it's not a BUG?
The developer said it is not a bug. There are two situations. One is that the demand has not been determined, so at this time, the product manager can be asked to investigate.
Please confirm whether any changes are needed, and then decide whether to change it after discussion. Second, this situation cannot happen, so there is no need to
If you want to modify it, you can first tell as much as possible what is the basis for the BUG? If it is discovered by the user or something goes wrong,
What adverse consequences will there be? The programmer may give you many reasons and you can refute his explanation. if still not
OK, then you can raise this issue and confirm with the development manager and test manager. If you want to modify it, change it. If you don’t want to modify it,
Don't change it if you change it. If the bug is ultimately determined not to be corrected, it should be recorded in the test report for future reference.
11. What should I do if I encounter a probabilistic bug?
Probabilistic bugs are also called ghost bugs. The first thing to make clear is that this type of bug also requires a bill of lading, which clearly describes the operating environment, operating steps, data, and provides necessary logs. You can also note the possible reasons. Then be patient, use elimination methods and wrong guesses to find patterns, and if necessary, find developers and project managers to analyze and discuss together. If it is still not solved in the end, it needs to be reflected in the test report, and the possible impact must be analyzed, and everyone can weigh it together. Whether this bug can be left behind.
12. How to design a use case for an ID number input box?
Verify the validity of ID number rules (including address code, date of birth code, sequence code and check code
Verify that both the 15-digit ID number and the 18-digit identity are available
Check the situation when the last digit is X
Check the situation of less than 15 digits, 16-17 digits and more than 18 digits
If it is a required input, will there be a correct prompt when the verification is not entered?
If it is not a required input, you need to verify whether the process can proceed normally when you do not enter it.
Verify whether there will be correct prompt information if non-digits are entered (including uppercase and lowercase letters, Chinese characters, special characters and punctuation marks)
Verify whether the system will recognize when you enter full-width numbers (this depends on your needs to determine whether full-width numbers can be used)
13.What is regression testing? How to do regression testing?
Regression testing means that during the software life cycle, as long as the software changes, it may cause problems for the software;
Therefore, whenever the software changes, we must retest the existing functions to determine whether the modifications have achieved the intended purpose and to check whether the modifications destroy the original normal functions.
Regression testing can occur at any stage, including unit testing, integration testing and system testing
So how do we do regression testing? It can be summarized in the following points
1. In the testing strategy formulation stage, formulate a regression testing strategy
2. Determine the version that requires regression testing
3. Release the regression test version and perform regression testing according to the regression testing strategy
4. The regression test is passed and the defect tracking ticket (problem ticket) is closed.
5. If the regression test fails, the defect tracking order is returned to the developer, the developer re-modifies the problem, and submits it to the tester for regression testing again.
14. How to submit a high-quality defect tracking ticket
First of all, it must be clear that the defect tracking sheet is not just for yourself, so the most important criterion for a high-quality defect sheet is
The judging criteria are that others can understand it at a glance, the title is concise and clear, and the steps are clear and organized. It is also necessary to consider the completeness of the defect, such as defect level, functional module, version, reproduction steps, expected results, actual results, causes, log screenshots, etc.
15. What are the project testing procedures?
Requirements review, test plan, technical review, use case writing, use case review, test execution, test report, online verification, project summary
16. How to classify bug priority and severity
Priority (priority) and Severity (severity) are two important attributes for submitting bugs.
Usually, when submitting a bug, testers only define the Severity of the bug, that is, the severity of the bug, and leave the Priority to the Project Leader or Team Leader to define, and they decide the priority of fixing the bug. In a sense, the definition of Priority depends on Severity. In most cases, the more severe the Severity, the higher the Priority of the bug.
Severity is as follows:
Blocker: that is, the system cannot be executed, crashes or is seriously insufficient in resources, the application module cannot be started or exits abnormally, cannot be tested, causing system instability.
Critical: It affects the function or operation of the system. There are serious flaws in the main functions, but it will not affect the stability of the system.
Major (serious): interface, performance defects, compatibility.
Minor/Trivial: Usability and advisory issues.
Priority: Immediate, Urgent, High,
Normal, Low (slightly slower)
17. What do you think is the key to good test case design?
The key point is to be familiar with the requirements, but the requirements can be divided into the following aspects
1. Familiar with the business needs
2. Be familiar with the relationship between other systems and this requirement
3. Be familiar with development design documents and understand development implementation logic
4. Familiar with database design documents and understanding of data storage
5. Familiar with the project structure and discover hidden requirements
18. Give you a website, how to conduct testing
1. Search for requirement descriptions, website design and other related documents, and analyze test requirements.
2. Develop a test plan, determine the test scope and test strategy.
3. Design test cases, including functions, compatibility, performance, security, etc.
4. Carry out test execution
5. Regression testing and test summary
