1. What is software testing first? The purpose and principle of software testing is the process of operating the program under specified conditions to find program errors, measure the quality of the software, and evaluate whether it can meet the design requirements.
The purpose of software testing:
Testing is the execution process of the program, the purpose is to find errors
A successful test case is to find errors that have not been discovered so far
A successful test is a test that finds errors that have not been found so far
Ensure that the product has fulfilled its promised or announced functions, and that the functions that users can access have clear written instructions.
Ensure products meet performance and efficiency requirements
Ensure that the product is robust and adaptable to the user's environment
Principles of software testing:
A mandatory part of the test case is to define the expected output or takeover
Programmers should avoid testing their own programs
Organizations that write software should not test their own software
The execution results of each test should be thoroughly checked
The writing of test cases should not only be based on valid and expected input, but also should be based on invalid and unexpected input
Checking whether the program "does not do what it should do" is only half of the test, and the other half of the test is to check whether the program "does what it should not do"
Disposal of test cases should be avoided unless the software itself is a one-off software
You should not acquiesce when planning your testing
The possibility of more errors in a certain part of the program is proportional to the number of errors that have been found in that part
Software testing is a very creative and intellectually challenging work
2. What are the types of software testing you know, briefly introduce them. Classified by test strategy:
1. Static and dynamic testing
2. Black box and white box testing
3. Manual and automatic testing
4. Smoke test
5. Regression test;
Classified by test stage: unit test, integration test, system test, acceptance test;
Other common test methods: 1, functional test 2, performance test 3, stress test 4, load test 5, usability test 6, installation test 7, interface test 8, configuration test 9, document test 10, compatibility test 11, Security test 12. Recovery test
Software acceptance testing includes formal acceptance testing, alpha testing, and beta testing.
3. What is the main test case design method at present? White box testing: logical coverage, loop coverage, basic path coverage
Black box testing: boundary value analysis method, equivalence class division, wrong guessing method, causality diagram method, state diagram method, test outline method, random test, scenario method
Briefly describe what is static testing, dynamic testing, black box testing, white box testing, alpha testing, beta testing
Static testing is the process of looking for possible errors in the program code or evaluating the program code without running the program itself.
Dynamic testing is to actually run the program under test, enter the corresponding test instance, check the difference between the running result and the expected result, determine whether the execution result meets the requirements, so as to check the correctness, reliability and effectiveness of the program, and analyze the efficiency and effectiveness of the system. Robustness and other performance.
Black box testing is generally used to confirm the correctness and operability of software functions. The purpose is to detect whether the various functions of the software can be realized. The program under test is regarded as a black box, regardless of its internal structure. In the case of the relationship between the input and output or the function of the program, rely on the software specification to determine the test cases and infer the correctness of the test results.
White box testing is based on the analysis of the internal logic structure of the software. It is a code-based test. Testers judge the quality of the software by reading the program code or by using single-step debugging in the development tool. Generally, the black box testing is performed by the project manager. To be realized in the development of programmers.
Alpha testing is a test performed by a user in a development environment, or a controlled test performed by an internal user in a company that simulates the actual operating environment. Alpha testing cannot be completed by programmers or testers.
Beta testing is a test conducted by multiple users of the software in the actual use environment of one or more users. Developers are usually not on the test site, and Beta testing cannot be done by programmers or testers.
4. What is the software life cycle and its model? Software life cycle (Software life cycle) is also called software life cycle, life cycle. It refers to the entire process from the formation of the developed software concept, after the developed software is used, until it loses its use value and dies. Generally speaking, the entire life cycle includes three periods of planning (definition), development, and operation (maintenance), and each period is divided into several stages. Each stage has clear tasks.
Periodic model (typically several):
Rapid prototyping model: The rapid prototyping model allows preliminary rather than complete analysis and definition of the software requirements in the requirements analysis stage, and quickly design and develop a prototype of the software system, which shows the user all or part of the functions and performance of the software to be developed ; The user tests and evaluates the prototype, and gives specific improvement opinions to enrich and refine the software requirements; the developers modify and improve the software accordingly, until the user is satisfied and approved, complete the software implementation, testing and maintenance.
Iteration model: Iteration includes all development activities that produce a product release (stable, executable product version) and all other peripheral elements necessary to use the release. To a certain extent, development iteration is a process that goes through all the workflows at once: requirements analysis, design, implementation, and testing workflows. In essence, it is similar to a small waterfall project. RUP believes that all stages can be subdivided into iterations. Each iteration will produce a product that can be released, which is a subset of the final product.
Life cycle stage:
Software plan and feasibility analysis
Operation and maintenance
5. What is the purpose of the test planning work? What should be included in the test plan document? Which of these are the most important? The software test plan is a programmatic document that guides the testing process:
Leaders are able to carry out macro-control according to the test plan and carry out corresponding resource allocations
Testers can understand the entire project testing situation and the work to be done in different stages of project testing, etc.
It is convenient for other personnel to understand the work content of the tester and carry out related work
Contains product overview, test strategy, test method, test area, test configuration, test cycle, test resources, test communication, risk analysis, etc. With the help of the software test plan, the project members participating in the test, especially the test management personnel, can clarify the test tasks and test methods, maintain smooth communication in the test implementation process, track and control the test progress, and respond to various changes in the test process.
6 elements of test plan preparation (5W1H):
why-why do these tests need to be carried out;
what what aspects to test and the content of work at different stages;
when start and end time of different stages of testing;
where corresponding documents, storage location of defects, test environment, etc.;
who The composition of relevant personnel of the project, and which testers are arranged for testing;
how how to do it, which test tools and test methods to use for testing
There is a strategic and tactical relationship between the test plan and the detailed test specifications and test cases. The test plan mainly plans the scope, methods and resource allocation of test activities from a macro perspective, while the detailed test specifications and test cases are specific tactics for completing the test tasks. So the most important thing is to test the test strategy and test method (preferably review first).
6. What are the testing strategies and requirements for the various stages of software testing? What are the software testing strategies? Software testing strategies: under the guidance of certain software testing standards and testing specifications, based on the specific environmental constraints of the test project And the set of principles, methods, and methods for software testing.
Corresponding to the development process, the testing process will go through four main stages: unit testing, integration testing, system testing, and acceptance testing:
Unit testing: Unit testing is the smallest unit of software design-program modules and even code segments for correctness testing, usually performed by developers.
Integration test: Integration test is to assemble the modules according to the design requirements for testing, the main purpose is to find problems related to the interface. Since the product development team must conduct joint debugging before the product is submitted to the testing department, integration testing is done by developers in most enterprises.
System test: The system test is carried out after the integration test is passed, the purpose is to fully operate the system, verify whether each subsystem can work normally and complete the design requirements. It is mainly carried out by the testing department. It is the largest and most important test in the testing department and has a significant impact on the quality of the product.
Acceptance test: The acceptance test takes the "Requirement Specification" in the demand stage as the acceptance standard, and requires simulation of the actual user's operating environment during the test. For the actual project, it can be carried out together with the customer, and for the product, it is the last system test. The test content is a comprehensive test of the functional module, especially the document test.
Unit test test strategy:
Top-down unit testing strategy: much higher than the cost of isolated unit testing, not a good choice for unit testing.
Bottom-up unit testing strategy: A more reasonable unit testing strategy, but the testing cycle is longer.
Isolated unit testing strategy: the best unit testing strategy.
The test strategy of the integration test:
Big Bang integration: suitable for a maintenance project or a small system under test
Top-down integration: It is relatively clear and stable for product control structure; high-level interface changes are small; low-level interface is undefined or may be frequently modified; production control components have greater technical risks and need to be verified as soon as possible; hope as soon as possible Can see the system function behavior of the product.
Bottom-up integration: It is more stable to adapt to the bottom interface; the high-level interface changes more frequently; the bottom-level components are completed earlier.
Advantages of schedule-based integration: It has a high degree of parallelism; it can effectively shorten the development schedule of the project. Disadvantages: the pile and driver workload is large; some interface tests are not sufficient; some tests are repeated and wasteful.
Test strategy for system testing:
Data and database integrity testing; functional testing; user interface testing; performance evaluation; load testing; strength testing; capacity testing; security and access control testing; failover and recovery testing; configuration testing; installation testing; encryption testing; usability testing ; Version verification test; document test
7. What is usually done in each phase of software testing? What are the result files of each stage? What is included? Unit test stage: each independent unit module is tested in isolation from other parts of the system. The unit test checks the correctness of each program module to check whether each program module correctly implements the specified functions. Generate unit test report and submit defect report.
Integration testing stage: Integration testing is based on unit testing. It tests whether all the software units are assembled into modules, subsystems or systems in accordance with the requirements of the outline design specifications. Whether each part of the work meets or achieves the corresponding technical indicators and The requested activity. In this stage, an integration test report is generated and a defect report is submitted.
System testing stage: The software that has passed the confirmation test is used as an element of the entire computer system, combined with other system elements such as computer hardware, peripherals, some supporting software, data, and personnel. In the actual operating environment, the The computer system carries out comprehensive functional coverage. At this stage, test summary and defect reports need to be submitted.
8. What are the common design methods of test cases for black box testing? Please use specific examples to illustrate the application of these methods in the design of test cases. 1) Equivalence class division: Equivalence class refers to a sub-collection of a certain input field. In this sub-collection, each input data is equivalent for exposing errors in the program. And it is reasonable to assume: test a certain equivalence The representative value of the class is equivalent to the test of other values of this type. Therefore, all input data can be reasonably divided into several equivalence classes, and one data in each equivalence class is taken as the input condition of the test, and a small amount can be used Representative test data. Good test results are obtained. Equivalence classes can be divided into two different situations: valid equivalence classes and invalid equivalence classes.
2) Boundary value analysis method: It is a supplement to the equivalence class division method. Test work experience tells me that a large number of errors occur on the boundary of the input or output range, rather than inside the input and output range. Therefore, design test cases for various boundary conditions to detect more errors.
To use the boundary value analysis method to design test cases, first determine the boundary conditions. Usually the boundary of the input and output equivalence classes is the boundary conditions that should be tested. The value that is exactly equal to, just greater than or just less than the boundary should be selected as the test data. Instead of selecting typical values or arbitrary values in the equivalence class as test data.
3) Wrong guessing method: based on experience and intuition to speculate on all possible errors in the program, so as to design test cases in a targeted manner.
The basic idea of the error speculation method: List all possible errors in the program and special cases where errors are prone to occur, and select test cases according to them. For example, many common errors in modules listed during unit testing. Previous products Errors found in the test, these are the summary of experience. Also, the input data and output data are 0. The input form is blank or the input form has only one line. These are the situations that are prone to errors. You can choose these situations The following example is used as a test case.
4) Causality diagram method: The equivalence class division method and boundary value analysis method introduced above both focus on the input conditions, but do not consider the connection between the input conditions, mutual combination, etc. Consider the mutual combination between the input conditions, Some new situations may arise. But it is not easy to check the combination of input conditions. Even if all input conditions are divided into equivalence classes, there are quite a few combinations between them. Therefore, a suitable one must be considered To describe the combination of multiple conditions and correspondingly generate multiple actions to consider the design of test cases. This requires the use of causal diagrams (logical models). The final result of the causal diagram method is the decision table. It is suitable for checking program input conditions Various combinations.
5) Orthogonal table analysis: The number of test cases may increase sharply due to the combination of a large number of parameters. At the same time, these test cases have no obvious priority gap, and testers cannot complete so many tests. , You can use the orthogonal table to reduce some use cases, so as to achieve the possibility of covering the largest possible range with as few use cases as possible.
6) Scenario analysis method: Refers to simulating the user's operation steps according to the user scenario. This is more similar to a causal diagram, but the depth and feasibility of the possible execution are better.
7) State diagram method: Obtain all states of the system under test through the description of input conditions and system requirements, and obtain output conditions through input conditions and states; obtain test cases of the system under test through input conditions, output conditions and states.
8) Outline method: Outline method is a method that focuses on requirements. In order to list various test conditions, the requirements are converted into outline form. The outline is represented as a tree structure, and there is a unique path between the root and each leaf node. Each path in the outline defines a specific set of input conditions for defining test cases. The number of leaves in the tree or the path in the outline gives the approximate number of test cases required to test all functions.
9. Briefly describe the life cycle of the bug?
1. Effectively record bugs
- Use BUG templates
3. Evaluate the priority and severity of BUG
4. BUG's life
5. Maintain the BUG database
10. What is included in a software defect (or bug) record? How to submit high-quality software defect (Bug) records? Basically, a bug record should contain:
The severity level and priority of the bug;
The module where the bug is generated;
1. there must be a bug summary, explaining the general content of the bug;
The version corresponding to the bug;
Detailed description of the bug phenomenon, including some screenshots, videos... etc.;
The test environment when the bug appears, and the conditions generated correspond to the operation steps;
High-quality bug records:
Universal UI must be unified and accurate
The UI of the defect report should be consistent with the UI of the tested software, so that it is easy to find and locate.
Try to use the usual expression terms and expression methods in the industry
Use the usual expression terms and expression methods used in the industry to ensure accurate expression and reflect professionalism.
Each defect report includes only one defect
Each defect report only includes one defect, which enables the defect fixer to quickly locate one defect and concentrate on correcting only one defect at a time. The verifier only verifies whether one defect has been corrected correctly at a time.
Non-reproducible defects should also be reported
1. the defect report must demonstrate the ability to reproduce the defect. Defects that cannot be reproduced should be reproduced as best as possible. If the defects cannot be reproduced after doing their best, the defect must still be reported, but the frequency of the defect that cannot be reproduced and the occurrence of the defect should be indicated in the report.
Clearly indicate the type of defect
According to the phenomenon of the defect, summarize and judge the type of the defect. For example, that is, functional defects, interface defects, and data defects. Reasonable suggestions are the most common type of defects or defects. Other forms of defects or defects are also subordinate to one of them.
Clearly indicate the severity and priority of defects
Always clarify the difference between severity and priority. High-severity issues may not be worth solving, and small cosmetic issues may be treated as high-priority issues.
Description (Description), concise, accurate and complete, reveal the essence of the defect, record the defect or the location of the defect
The description should accurately reflect the essence of the defect, short and clear. In order to find the specified test defects in the software defect management database, it is a good habit to include the user interface (UI) when the defect occurs. For example, record the title of the dialog box, the name of the menu, button and other controls.
Use automatic digital serial numbers between short lines, use the same font, font size, and line spacing
Use automatic digital serial numbers between short lines, use the same font, font size, and line spacing to ensure that the format of each record is consistent, and to be standardized and professional.
Try to record only one operation at each step
Keep it concise, organized, and easy to repeat steps.
Confirmation steps are complete, accurate and short
To ensure rapid and accurate repetition of defects, "complete" means that there are no omissions, "accurate" means that the steps are correct, and "short" means that there are no redundant steps.
According to the defect, you can choose whether to capture the image
In order to visually observe the defect or defect phenomenon, it is usually necessary to attach the interface where the defect or defect appears, in the form of a picture as an attachment attached to the "attachment" part of the record. In order to save space and truly reflect the defect or the nature of the defect, the full screen, active window and partial area of the defect or defect can be captured. In order to quickly locate and correct the defect or defect location, it is usually required to attach a Chinese comparison chart.
Attach necessary special documents and personal suggestions and comments
If a defect or defect occurs when a particular document is opened, the document must be attached so that the defect or defect can be quickly reproduced. Sometimes, in order to make the defect or defect fixer further clarify the defect or the manifestation of the defect, personal suggestions or comments can be attached.
Check spelling and syntax defects
Before submitting each defect or defect, check the spelling and syntax to ensure that the content is correct and the defect is described correctly.
Try to use phrases and short sentences to avoid complex sentence patterns
The purpose of the software defect management database is to facilitate the location of defects. Therefore, it requires an objective description of the operation steps without the need for modified vocabulary and complex sentence patterns to enhance readability.
The above summarizes the specification requirements for reporting test defects. As the software testing requirements are different, testers have accumulated corresponding testing experience after long-term testing, and will gradually develop good professional habits and continue to supplement new specification writing requirements. In addition, frequently reading and studying test defect reports of other test engineers, and comparing and thinking with one's previous test defect reports, can continuously improve skills.
Defect description content
The content of the defect description can include defect operation steps, actual results and expected results. The operation steps can facilitate developers to reproduce defects and correct them. Some developers have poor ability to reproduce defects. Although he understands the defects you are referring to, they cannot reproduce, especially new developers who are not familiar with the system. The introduction steps can facilitate them Reappear. The actual result allows the developer to understand what the error is, and the expected result allows the developer to understand how the correct result should be.
11. The tracking process of the BUG management tool (using BugZilla as an example) The tester finds the BUG and submits it to Bugzilla, the status is new, and the recipient of the BUG is the developer interface personnel
The development interface assigns the BUG to the developer of the relevant module, the status is changed to Allocated, the developer and the test confirm the BUG, if it is my own BUG, it is set to receive; if it is another developer s problem, it is forwarded, It is up to the next developer to perform this behavior; if you think it is not a problem, you need to discuss and confirm the problem, then reject the bug, and then the tester closes the problem.
If the developer accepts the BUG and revises it, he will change the BUG status to repaired and tell the test in which version it can be tested.
Testers test in the new version. If the problem still exists, the verification is rejected; if it has been fixed, the BUG is closed.
12. What are the tasks of testers in the software development process? 1. Find out the bugs in the system as early as possible;
2. Avoid defects in the software development process;
3. Measure the quality of the software and ensure the quality of the system;
4. Pay attention to the needs of users and ensure that the system meets the needs of users.
The overall goal is: to ensure the quality of the software.
13. Other basic knowledge V model
The RAD (Rap Application Development, rapid application development) model is an important model in the software development process. Because its model is similar to the letter V, it is also called the V model of software testing. The V model can be roughly divided into the following different stages Steps: requirements analysis, outline design, detailed design, software coding, unit testing, integration testing, system testing, acceptance testing.
14. What are the quality characteristics of software products? Functionality: adaptability, accuracy, interoperability, compliance, and security.
Reliability: maturity, fault tolerance, and easy recovery.
Usability: easy to understand, easy to learn, easy to operate.
Efficiency: time characteristics, resource characteristics.
Maintainability: easy to analyze, easy to change, stable, easy to test.
Portability: adaptability, easy installation, compliance, easy replacement
15. How to test a paper cup? Functionality: Fill a glass with water to see if it leaks; can the water be drunk
Safety: Whether the cup is poisonous or bacteria
Reliability: the degree of damage to the cup falling 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 there are anti-slip measures, whether it is convenient to drink
User documentation: Does the user manual have a detailed description of the usage, restrictions, and conditions of use of the cup?
Fatigue test: Fill the cup with water (case 1) for 24 hours to check the time and condition of leakage; hold the cup with gasoline (case 2) for 24 hours to check the time and condition of leakage, etc.
Pressure test: use a needle and continuously add weight to the needle, see how high the pressure will penetrate
The information below should be the most comprehensive and complete preparation warehouse for friends of [software testing]. This warehouse has also accompanied me through the most difficult journey, and I hope it can also help you~
Everything must be done as early as possible, especially in the technology industry, we must improve our technical skills. At every stage of technological growth, there will be a matched, difficult-to-cross-tech bottleneck period! At this stage, there is no magic medicine that can be solved once, only one's own continuous accumulation, precipitation, breaking the game, and finally the explosion. And this knowledge may be boring at first, just like watching a big A and not a small a, watching a small a and then involving a small b, there is no way to pick up layer by layer, learn layer by layer.
Although the above is not a very valuable thing, if you can use it, you can take it away directly. You can take it away by yourself in my QQ technical exchange group (technical exchange and resource sharing), group number: 902061117.
If I can help you a little bit, your "like" is the biggest motivation for the editor's creation. See you in the next article!