The interviews of the test posts are actually very similar. Here I have collected and sorted out 185 high-frequency interview questions. I hope it will be helpful to everyone who is looking for a job or planning to change jobs!
1. Test basis
1. How to make a test plan
Reference answer:
The test plan includes test objectives, test scope, description of test environment, description of test types (function, security, performance, stability), test tools, division of modules, test leader, time schedule for test execution rounds, and related documents Position in the document management repository, risk of testing. Among them, the module division needs to be allocated according to the testers' familiarity with the business and personal ability. The workload estimation needs to be based on the experience of previous tests, combined with the modification of this requirement, the test amount can be roughly estimated.
2. How to ensure software quality in the project
Reference answer:
Project quality is not guaranteed by only one person or a certain team, but the result of the joint efforts of the entire team. There needs to be a standardized project process at the company level
1. Products, guarantee the product logic in the iteration process, make predictions about possible compatibility and upgrades, and give solutions
2. Design, while satisfying the product expression, ensure the continuity of the design
3. Development, guarantee of product details, rigorous selection of technical solutions, consideration of compatibility, performance, full self-test after development is completed, and strictly follow the development specification operation
4. Test and 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
3. What are the general contents of functional test cases?
Reference answer:
The elements generally include: use case number, use case priority, test purpose, module, precondition, 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 partitioning method: The equivalence class partitioning method divides all possible input data (valid and invalid) of the program into several equivalence classes.
Boundary value method: Boundary value analysis is a black box testing method for testing the boundary value of input or output.
Error guessing method: When testing a program, people can speculate on various errors that may exist in the program based on experience or intuition, so as to write a method of testing test cases for these errors.
Cause-and-effect graph method: The cause-and-effect graph method is a test method suitable for describing combinations of various input conditions. According to the combination of input conditions, constraint relationships, and causality of output conditions, various combinations of input conditions are analyzed to design tests. The method of use cases is suitable for examining various combinations of input conditions involved in a program.
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 various combination values of all inputs and corresponding output values as conditions.
Orthogonal decomposition method: It is a design method for studying multi-factors and multi-levels. According to the orthogonality, some representative points are selected from the combination of all levels of the experimental factors for experimentation. Analyze and understand the situation of comprehensive experiments to find the optimal combination of levels.
Scenario analysis method: analyze software application scenarios, design test cases from the perspective of users, and design test cases from the perspective of scenarios, which is a user-oriented test case design method. Focus on what the user does, not what the product does.
Global exploratory testing method: testers are free to play according to the information provided by the application program, without restriction, and without any constraints to explore various functions of the program.
5. What is the difference between APP testing and web testing
The types of web-side testing and mobile-side testing are basically similar, and both require functional testing, performance testing, and security testing.
Try, they mainly distinguish that the web end is generally a b/s architecture, which is based on a browser, and the app is a c/s architecture, which has a client.
(1) From the perspective of system architecture: as long as the web test updates the server side, the client side will be updated synchronously; and if the server side is modified under the app side, it means that all core versions used by client users need to be regressed Test it out.
(2) In terms of client performance: the Web side may only focus on response time; the App also cares about traffic, power, cpu, etc.;
(3) Compatibility: Web is based on browsers, so it is more inclined to be compatible with browsers (IE, Chrome, firefox) and computer hardware and computer systems; App testing must rely on mobile phones or pads, not only depends on the resolution Frequency, frequency item size, mainly depends on the equipment system.
6. When a bug is found, how to locate the problem on the APP side or the server side?
1. Packet capture analysis By capturing packets on the client side, analyze whether the data returned by the server meets expectations, such as
If the server data is correct, it is the client's problem
2. Log analysis can analyze whether there is any abnormal log information by viewing the log of the client/server.
to determine the specific cause
7. Write a test point for the installation function of the App?
1. 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, and check whether it is overwritten.
3. Rollback version test. For example: first install a 2.0 version of the APP, and then install a 1.0 version of the APP, under normal circumstances, the version can be rolled back.
4. When the memory is insufficient during installation, a prompt will pop up.
5. According to the installation manual, whether it is installed correctly.
6. Unexpected situations during the installation process (forced power off, network disconnection, incoming calls, checking information), etc., check what will happen.
7. Through 'Synchronization Software', check whether some files are installed synchronously during installation.
8. Install on mobile phones with different models, systems, screen sizes, and resolutions.
9. Whether there is an SD card recognized during installation, and it is installed to the SD card by default.
10. After the installation is complete, 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 complete, whether it will affect other applications.
13. After the installation is complete, can you add a shortcut.
14. After the installation is complete, whether the anti-virus software will treat it as a virus.
15. Multi-process installation, whether the installation is successful.
16. During the installation process, all prompt information must be in English or Chinese, and no codes, symbols, garbled characters, etc. can appear in the prompt information.
17. After installation, whether to start the program automatically.
18. Whether to support third-party installation.
19. Click Cancel during the installation.
8. What is the purpose of continuous integration
Continuous integration refers to frequent (multiple times a day) integration of code into the mainline.
It has two main benefits:
(1) Quickly find errors. Every time a little update is completed, it is integrated into the backbone, which can quickly find errors and locate errors more easily.
(2) Prevent branches from greatly deviating from the trunk. If it is not integrated frequently and the backbone is constantly updated, it will make it more difficult to integrate in the future, or even difficult to integrate.
The purpose of continuous integration is to allow products to iterate quickly while maintaining high quality. Its core measure is that before the code is integrated into the backbone, it must pass automated tests. 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 the water can be drunk; paper cup shape (positive cylinder, top wide and bottom narrow cylinder, top narrow bottom wide cylinder, other shapes), paper cup Material (all paper, all plastic, half paper and half plastic), temperature resistance of paper cups (cold water, hot water, cold water, ice), supported liquid names (water, coffee, milk, cola)
Safety: Is there any poison or bacteria in the cup, how long does it take for the liquid to have a chemical reaction (for example: odor)
Reliability: the degree of damage to the cup 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, white water, alcohol, gasoline, etc.
Ease of use: whether the cup is hot, whether it has anti-skid measures, whether it is convenient to drink, how long does it take to leak water when it is filled with liquid, and how much hot water is filled
Long-term deformation, how many degrees of hot water deformation
User documentation: Does the user manual describe in detail the usage, restrictions, and conditions of use of the cup?
Fatigue test: put the cup in water for 24 hours to check the leak time and situation; fill it with gasoline for 24 hours to check the leak time and situation, etc.
Pressure test: use a needle and continuously add weight on the needle to see how much pressure it will penetrate; how long does it take to deform by hand extrusion (single
hands, both hands)
10. How do you cope when the developer says it's not a bug?
The developer said that it is not a bug. There are two situations. One is that the demand is not determined, so at this time, a product manager can be called in.
Confirm whether it needs to be changed or not. After discussing and confirming, we will see if we need to change it. Second, this situation is unlikely to happen, so there is no need to
To modify, at this time, you can first say as much as possible what is the basis for the BUG? If it is discovered by the user or something goes wrong,
What bad consequences can there be? The programmer may give you many reasons, and you can refute his explanation. if still not
OK, then you can ask this question and confirm with the development manager and test manager. If you want to modify it, you can change it. If you don’t want to modify it
If you change it, don't change it. If the final bug is determined not to be changed, it must be recorded in the test report for future reference.
11. What should I do if I encounter a probabilistic bug?
Probabilistic bugs, also called ghost bugs, first of all need to be clear that such bugs also need a bill of lading, clearly describe the operating environment, operation steps, data, and provide necessary logs, and note the possible causes. Then be patient, use the elimination method and wrong guessing to find the law, and if necessary, find the developer and project manager to locate, analyze and discuss together. If it is still not resolved in the end, then it needs to be reflected in the test report and analyze the possible impact. Everyone weighs together Whether the bug is legacy.
12. An ID number input box, how to design a use case
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 case where the last digit is X
Cases with parity less than 15 digits, 16-17 digits and greater than 18 digits
If it is a mandatory item, will there be a correct prompt when the verification is not entered?
If it is not a mandatory item, it is necessary to verify whether the process can proceed normally without input
Check whether there will be correct prompt information (including uppercase and lowercase letters, Chinese characters, special characters and punctuation marks) when non-numbers are entered
Check whether the system will recognize when entering a full-width number (this depends on the requirement to determine whether the full-width number can be used)
13. What is regression testing? How to do regression testing?
Regression testing, that is, in 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 in order to determine whether the modification achieves the expected purpose and check whether the modification destroys the original normal function.
Regression testing can occur at any stage, including unit testing, integration testing and system testing
So how do we do regression testing? Summarized in the following points
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
14. How to submit a high-quality bug tracker
First of all, it must be clear that the defect tracking sheet is not just for yourself, so the most important judgment for a high-quality defect sheet
The judgment standard is that others can understand it at a glance, the title is concise and clear, and the steps are well-organized. 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.
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 divide 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 give the Priority to the Project Leader or Team Leader to define, and they decide the priority level of the bug to be fixed. 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 (impeding): that is, the system cannot be executed, crashes or is seriously insufficient in resources, application modules cannot be started or exit abnormally, cannot be tested, and cause system instability
Critical (important): It affects the system function or operation, and there are serious defects in the main function, but it will not affect the system stability
Major (serious): that is, interface, performance defects, compatibility.
Minor/Trivial (secondary/not serious): ease of use and advisory issues.
Priority (priority): Immediate (immediately), Urgent (urgent, priority), High (highly valued),
Normal (normal), Low (slightly slow)
17. What do you think is the key to doing a good job in 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 this business requirement
2. Familiar with the relationship between other systems and this requirement
3. Familiar with the development and design documents, understand the development and implementation logic
4. Familiar with database design documents and understand data storage
5. Familiar with the project structure and discover hidden requirements
18. Give you a website, how to test it
1. Find relevant documents such as requirements description and website design, and analyze testing 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 test and test summary
Due to space limitations, only part of the interview questions are shown. If you need a full version of the document, you can click the card below to get it~