First, what is software testing? Purpose and Principles of Software Testing The process of operating a program under specified conditions in order to detect program errors, measure software quality, and evaluate whether it meets design requirements.
The purpose of software testing:
Testing is the execution of a program to find errors
A successful test case is one that finds errors that have yet to be discovered
A successful test is one that finds errors that have yet to be discovered
Ensure that the product does what it promises or announces, and that the features that users can access are clearly documented.
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 necessary part of the test case is the definition of the expected output or output
Programmers should avoid testing their own programs
Organizations that write software should not test their own software
The results of each test execution should be thoroughly reviewed
Test cases should be written not only for valid and expected input, but also for invalid and unexpected input
Checking whether the program “doesn’t do what it should” is only half the test. The other half of the test is checking whether the program “does what it shouldn’t”
Test case throwback should be avoided unless the software is inherently disposable
Testing efforts should not be planned on the tacit assumption that errors will not be found
The likelihood of more bugs in a part of the program is proportional to the number of bugs already found in that part
Software testing is a very creative and intellectually challenging job
Two, what are the types of software testing that you know, a brief introduction. By test strategy:
1. Static and dynamic testing
2, black box and white box test
3. Manual and automatic testing
4. Smoke test
5. Regression test;
Classification by test stage: unit test, integration test, system test, acceptance test;
Other common test methods: 1, function test 2, performance test 3, stress test 4, load test 5, ease of use test 6, installation test 7, interface test 8, configuration test 9, document test 10, compatibility test 11, security test 12, recovery test
Software acceptance test includes formal acceptance test, alpha test and beta test.
Iii. What are the main test case design methods at present? White box test: logical coverage, circular coverage, basic path coverage
Black box test: boundary value analysis, equivalence class division, error guess method, causality diagram, state diagram, test outline method, random test, scene method
What are static testing, dynamic testing, black box testing, white box testing, alpha testing and beta testing
Static testing is the process of looking for possible errors or evaluating program code without running the program itself.
Dynamic test is to actually run the program under test, input 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 performance of the system, such as operation efficiency and robustness.
Black box testing are commonly used to confirm the correctness of the software function and operability, the purpose is to test whether the function of software can be realized, the tested program as a black box, regardless of its internal structure, knowing the relationship between the input and output of the program or a program function, rely on software specifications to determine the test cases and test results of right Sex.
White box testing is based on the analysis of the internal logical structure of the software. It is a test based on code. Testers judge the quality of the software by reading the program code or by using the single-step debugging in the development tools.
Alpha tests are tests performed by a user in a development environment, or controlled tests performed by an internal user in a simulated operational environment. Alpha tests cannot be performed by programmers or testers.
Beta testing is testing by multiple users of the software in the actual use environment of one or more users. Developers are usually not on site, and Beta testing cannot be done by programmers or testers.
What is the software life cycle and its model? Software life cycle is also called Software life cycle. It refers to the whole process from the formation of the concept of development software, after the use of the software, until the end of the use value. Generally speaking, the whole life cycle includes planning (definition), development, operation (maintenance) three periods, each period is divided into several phases. Each stage has a clear task.
Periodic models (typical ones) :
The waterfall model
Rapid prototyping model: Rapid prototyping model allows preliminary rather than complete analysis and definition of software requirements in the requirement analysis stage, and rapid design and development of software system prototype, which shows users all or part of the functions and performance of the software to be developed; Users test and evaluate the prototype and give specific improvement suggestions to enrich and refine the software requirements; Developers modify and improve the software accordingly, until the user is satisfied with the recognition, software complete implementation and testing, maintenance.
Iteration model: Iteration includes all development activities that produce a product release (a stable, executable version of the product) and all other peripheral elements necessary to use the release. To some extent, a development iteration is a complete process through all workflows: requirements analysis, design, implementation, and test workflows. In essence, it’s like a small waterfall project. RUP believes that all phases can be subdivided into iterations. Each iteration produces a releasable product that is a subset of the final product.
Life cycle stage:
Software planning and feasibility analysis
Demand analysis
The software design
coding
Software testing
Operation and maintenance
What is the purpose of the test plan? What should the contents of the test plan document include? Which are the most important? A software test plan is a programmatic document that guides the testing process:
The leader can carry out macro-control and corresponding resource allocation according to the test plan
Testers can understand the whole project testing situation and the work to be carried out in different phases of the project testing
It is convenient for other personnel to understand the work content of testers and cooperate with them
It includes product overview, test strategy, test method, test area, test configuration, test cycle, test resources, test communication, risk analysis and so on. With the help of the software test plan, the test project members, 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 deal with various changes in the test process.
6 elements of test plan compilation (5W1H) :
Why — why these tests are carried out;
What – what to test, what to do at different stages of work;
When – Test the start and end times of different stages;
Where – documentation, location of defects, test environment, etc.
Who — The composition of relevant personnel of the project, and which testers are arranged to carry out the tests;
How – How to do this, which testing tools and testing methods to use
The relationship between test plan, test specifications and test cases is strategic and tactical. Test plan mainly plans the scope, method and resource allocation of test activities from a macro perspective, while test specifications and test cases are specific tactics to complete test tasks. So the most important thing is to test the test strategy and test methodology (preferably reviewed first).
How many stages are software testing divided into? What are the testing strategies and requirements for each stage? What is the strategy for software testing? Software testing strategy: a collection of software testing principles, methods and methods stipulated under the guidance of certain software testing standards and testing specifications and according to the specific environmental constraints of testing projects.
Corresponding to the development process, the testing process will successively go through four main stages: unit test, integration test, system test and acceptance test:
Unit testing: Unit testing is the testing of the correctness of the smallest unit of software design — a program module or even a piece of code, usually by a developer.
Integration testing: Integration testing is the assembly of modules according to design requirements for testing, the main purpose is to find problems related to the interface. Integration testing is done by developers in most enterprises because the product development team performs joint debugging before the product is delivered to the test department.
System test: System test is carried out after the integration test is passed, the purpose is to fully run the system, verify whether each subsystem can work normally and complete the design requirements. It is mainly carried out by the test department, is the biggest and most important test of the test department, has a significant impact on the quality of the product.
Acceptance test: The acceptance test is based on the Requirement Specification in the requirement stage, and the operating environment of actual users is simulated during the test. For the actual project can be carried out with the customer, for the product is the last system test. The test content is the comprehensive test of the functional module, especially the document test.
Unit test Testing strategy:
Top-down unit testing strategy: Much more expensive than isolated unit testing and not a good choice for unit testing.
Bottom-up unit test strategy: A more reasonable unit test strategy, but the test cycle is longer.
Isolated unit testing strategy: The best unit testing strategy.
Testing strategies for integration testing:
Big bang integration: Suitable for a maintenance project or smaller system being tested
Top-down integration: suitable for clear and stable product control structure; The change of high-level interfaces is small; The underlying interface is undefined or often subject to modification; Production control components have a high technical risk and need to be verified as soon as possible; We hope to see the system functional behavior of the product as soon as possible.
Bottom-up integration: it is stable to adapt to the underlying interface; High-level interfaces change frequently. The underlying components are completed earlier.
Advantages of progress-based integration: high degree of parallelism; Can effectively shorten the project development schedule. Disadvantages: pile and drive workload is large; Some interface tests are inadequate; Some tests are repetitive and wasteful.
Test strategy for system testing:
Data and database integrity testing; Functional testing; User interface testing; Performance evaluation; Load test; Strength test; Capacity test; Security and access control testing; Failover and recovery testing; Configuration test; Installation test; Encryption test; Usability testing; Version verification test; Document the test
7. What is usually done at each stage of software testing? What are the resulting files for each phase? What does it include? Unit test stage: each independent unit module is tested in isolation from other parts of the system. Unit test verifies the correctness of each program module to check whether each program module correctly realizes the specified functions. Generate unit test reports and submit defect reports.
Integration test stage: On the basis of unit test, integration test is an activity that tests whether all parts of the work meet or achieve the corresponding technical indicators and requirements in the process of assembling all software units into modules, subsystems or systems according to the requirements of the outline design specifications. This phase generates integration test reports and submits defect reports.
System test stage: the software that passes the confirmation test, as an element of the whole given computer system, is combined with other system elements such as computer hardware, peripherals, some supporting software, data and personnel, and carries out comprehensive functional coverage of the computer system under the actual operating environment. This phase requires the submission of test summaries and defect reports.
8. What are the common design methods of black box test cases? Please give specific examples to illustrate the application of these methods in the test case design work. 1) Equivalence class division: Equivalence class refers to a subset of an input field. In this subset, each input data is equivalent to exposing errors in the program. It is reasonably assumed that testing a representative value of an equivalence class is equivalent to testing other values of that class. Therefore, all input data can be reasonably divided into several equivalence classes, and a small amount of representative test data can be used if one data from each equivalence class is taken as the input condition of the test. Get good test results. Equivalence classes can be divided into two different cases: valid equivalence classes and invalid equivalence classes.
2) Boundary value analysis method: it is a supplement to equivalence class division method. My experience in testing has taught me that a large number of errors occur at the boundary of the input or output range, not inside the input or output range. Therefore, designing test cases for various boundary cases can detect more errors.
When designing test cases using boundary value analysis, the boundary cases should be determined first. In general, the boundary of input and output equivalence classes is the boundary case that should be tested. You should select values that are exactly equal to, just above or just below the boundary as test data, rather than typical or arbitrary values in the equivalence class.
3) Error guessing method: the method of speculating all possible errors in the program based on experience and intuition, so as to design test cases in a targeted way.
The basic idea of the error prediction method is to list all possible errors in the program and special cases prone to errors, and select test cases according to them. For example, many common errors in modules were listed during unit testing. Errors found in previous product tests, etc., are the summary of experience. There are also cases where the input data and the output data are zero. Input form is blank or input form has only one line. These are all error-prone situations. You can select examples in these cases as test cases.
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 and their combination. Some new situations may arise when you consider combinations of input conditions. But it is not easy to examine the combination of input conditions, and even if all input conditions are divided into equivalence classes, there are quite a few combinations between them. Therefore, you must consider designing test cases in a form that is suitable for describing multiple actions resulting from a combination of multiple conditions. 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 various combinations of program input conditions.
5) orthogonal table analysis: probably because of the combination of a large number of parameters caused by the surge in the number of test cases, at the same time, these test cases and no obvious gap in priority, and the tester can’t do so many number of tests, you can cut through orthogonal table in some cases, so as to achieve less as far as possible use cases cover as far as possible big the scope of the possibilities.
6) Scenario analysis method: it refers to simulating the operation steps of users according to user scenarios. This is similar to the causal diagram, but the execution depth and feasibility may be better.
7) State diagram method: obtain all states of the system under test through input conditions and system requirements, and obtain output conditions through input conditions and states; The test case of the system under test is obtained by input condition, output condition and state.
8) The outline method: The outline method is a requirement-focused approach that converts requirements into an outline in order to list various test conditions. The outline is represented as a tree structure with a unique path between the root and each leaf node. Each path in the outline defines a specific set of input criteria for defining test cases. The number of leaves in the tree or paths in the outline gives an approximate number of test cases needed to test all the functionality.
Describe the lifecycle of the bug.
1. Effectively record bugs
- Using BUG Templates
3. Evaluate the priority and severity of the BUG
4. A BUG’s life
5. Maintain BUG database
What does a software defect (or Bug) record contain? How do I submit high quality software Bug records? A Bug record should basically contain:
The bug number;
Bug severity level and priority;
Bug-generated modules;
First, there should be a bug summary, describing the general content of the bug;
Version of the bug;
Bug Detailed symptom description, including some screenshots and videos… And so on;
The test environment when the bug appears, the conditions are the corresponding operation steps;
High quality Bug logging:
Common UI should be uniform and accurate
The UI of defect report should be consistent with the UI of the tested software for easy locating.
Try to use industry jargon and expressions
Use terminology and expression methods commonly used in the industry to ensure accurate and professional expression.
Each defect report contains only one defect
Each defect report contains only one defect, which enables the defect fixer to quickly locate a defect and focus on fixing only one defect at a time. The verifier verifies that only one defect at a time has been corrected correctly.
Non-reproducible defects are also reported
First, the defect report must demonstrate the ability to reproduce the defect. The defect that cannot be reproduced should be reproduced as much as possible. If the defect cannot be reproduced after all efforts are made, the defect should still be reported, but the frequency of the defect should be indicated in the report.
Clearly identify the defect type
According to the phenomenon of defects, summarize and judge the types of defects. For example, functional defects, interface defects, data defects, rationalization suggestions these are the most common types of defects or defects, and other forms of defects or defects also fall into one of these forms.
Clearly identify defect severity and priority levels
Always identify the difference between severity levels and priority levels. Serious problems may not be worth solving, and minor cosmetic problems may be treated as high priority.
Description, concise, accurate, complete, reveal the essence of the defect, record the defect or the location of the defect
The description should accurately reflect the nature of the defect and be short and concise. To facilitate the search for defined test defects in the software defect management database, it is a good practice to include the user interface (UI) at the time the defect occurred. For example, record the title of the dialog box, the name of the menu, and the name of the button.
Use automatic numeric numbering between short lines, and use the same font, size, and line spacing
The use of automatic numerical numbering between short lines, the use of the same font, size, line spacing, can ensure that each record format is consistent, to achieve standard and professional.
Try to record only one operation per step
Keep it simple, organized and easy to repeat.
Make sure steps are complete, accurate and brief
To ensure quick and accurate repetition of defects, “complete” means no missing, “accurate” means correct steps, and “brief” means no extra steps.
According to the defect, you can choose whether to capture the image
In order to intuitively observe the defect or defect phenomenon, it is usually necessary to attach the interface where the defect or defect appears, and attach the picture as an attachment to the “attachment” part of the record. In order to save space and truly reflect the nature of defects or defects, you can capture the full screen, active window and local area when defects or defects occur. In order to quickly locate and correct defects or defect locations, a Chinese reference map is usually required.
Gigs attach necessary special documentation and personal advice and annotations
If a defect or defect arises from opening a particular document, the document must be attached so that the defect or defect can be reproduced quickly. In some cases, personal modification suggestions or notes may be attached to enable the defect or defect corrector to further clarify the appearance of the defect or defect.
Check for spelling and grammar defects
Before submitting each defect or defect, check spelling and grammar to make sure the content is correct and the defect is described correctly.
Try to use phrases and short sentences instead of complex sentence patterns
The purpose of software defect management database is to facilitate defect location. Therefore, it is required to describe operation steps objectively, without modifying vocabulary and complex sentence patterns, and enhance readability.
The above summarizes the specification requirements for reporting test defects. With the different testing requirements of software, testers will gradually develop good professional habits after long-term testing and accumulate corresponding testing experience, and constantly add new specification writing requirements. In addition, you can constantly improve your skills by reading and learning test defect reports from other test engineers and comparing and thinking about your own previous test defect reports.
Defect Description content
The content of defect description can include defect operation steps, actual results, and expected results. The operation steps can be convenient for developers to reproduce defects for correction. Some developers have poor ability to reproduce defects. Although they understand the defects you refer to, they just cannot reproduce defects, especially for new developers who are not familiar with the system. The actual result lets the developer know what went wrong, and the expected result lets the developer know what the correct result should be.
11. Tracking process of BUG management tool (using BugZilla as an example) The tester finds a BUG, submits it to BugZilla, the status is new, and the recipient of the BUG is the developer interface person
The development interface assigns the BUG to the developer of the relevant module, and the status is changed to assigned. The developer and the test confirm the BUG. If the BUG is my own, it is set to receive. If the problem is caused by another developer, it is forwarded to the next developer. If it’s not a problem, it needs to be discussed and confirmed, rejected, and then the tester closes the problem.
If the developer accepts the BUG and fixes it, change the BUG status to fixed and tell the test in which version it can be tested.
The tester tests in the new version and rejects validation if the problem persists. If it has been fixed, close the BUG.
What is the tester’s role in the software development process? 1. Find out bugs in the system as early as possible;
2. Avoid defects in the process of software development;
3. Measure the quality of software and ensure the quality of the system;
4. Pay attention to the needs of users and ensure that the system meets their needs.
The overall goal is to ensure software quality.
Other basic knowledge V model
RAD (Rap Application Development) model is an important model in the process of software Development. Because its model composition resembles the letter V, it is also called V model of software testing. V model can be roughly divided into the following different stages: Requirements analysis, outline design, detailed design, software coding, unit testing, integration testing, system testing, acceptance testing.
What are the quality characteristics of software products? Functionality: adaptability, accuracy, interoperability, compliance, security.
Reliability: maturity, fault tolerance, easy recovery.
Usability: easy to understand, easy to learn, easy to operate.
Efficiency: time characteristic, resource characteristic.
Maintainability: easy analysis, easy to change, stability, easy to test.
Portability: adaptability, easy installation, compliance, easy replacement
How to test a paper cup? Function: with a cup of water to see the leakage does not leak; Can the water be drunk
Safety: There is no poison or bacteria in the cup
Reliability: Degree of damage caused by a cup falling from different heights
Portability: whether the cup can be used normally in different places, temperatures and other environments
Compatibility: Whether the glass can hold juice, water, alcohol, gasoline, etc
Ease of use: whether the cup is hot, whether there are anti-slip measures, whether it is easy to drink
User documentation: The user manual describes the usage, restrictions, and conditions of use of the cup in detail
Fatigue test: Put the cup in water (Case 1) for 24 hours to check the time and situation of leakage; Fill the gasoline (case 2) and leave it for 24 hours to check the time and situation of leakage, etc
Pressure test: use a needle and keep adding weight to the needle to see how much pressure will penetrate
The following information for [software testing] friends should be the most comprehensive and complete preparation warehouse, this warehouse also accompanied me through the most difficult journey, I hope to help you ~
Everything should be done as early as possible, especially in the technology industry, we must improve our technical skills. Each stage of technological growth will encounter a matching, difficult to cross, technical bottleneck period! At this stage, there is no magic medicine to solve, only their own continuous accumulation, precipitation, broken, to the final outbreak. And these knowledge may be boring at the beginning, just like watching A big A will not small A, watching A small A will involve small B, there is no way but to pick layer by layer, layer by layer learning.
Although the above is not what very valuable things, if you use it, you can take it directly. In my QQ technical exchange group (technical exchange and resource sharing), you can take it by yourself, group number: 902061117.
If you have a little help, everyone’s “praise” is the biggest power of small series creation, we will see you in the next article!