Classification by test type
1. Test execution process
Main tasks in the test execution phase
1. Determine the priority of test cases
2. Develop test procedures and determine priorities, create test data, and also prepare test equipment and design automated test scripts
3. Create test suites based on test procedures to improve the efficiency of test execution
(according to Test plan to design and create test scenarios, and put the corresponding test cases into my test suite)
4. Confirm that the test environment has been properly established
5. According to the execution order of the plan, execute the test procedures manually or using test tools (all It is based on the execution order in the plan)
6. Record the results of the test execution, as well as the identification and version of the tested software, test tools and test pieces.
(Extract some bugs and record the version number of the current tested software)
7. The actual results and the expected results were compared, the differences between actual results and expected results, as event reporting, and the intake line analysis to determine the cause of the difference of
8. after the bug fixing and re-testing activities
2. Test entry and exit – must know standards
Test access criteria (when can testing be started)
◆ Development coding is completed, and unit testing has been completed in the development environment . (I have developed a preliminary test code)
◆ functional requirements have been specified on real now; if not fully realized, please provide the test range
◆ integration testing has been completed, the basic flow of the system under test can go through, the interface All functions are implemented, after code review and compliance with software coding specifications (equivalent to joint debugging between development)
◆ Development submits the latest version of the code, based on this, submit and notify the test team for testing
◆ Compatibility testing requirements are clear
◆ Security testing And performance test scope and requirements
(Development self-test, basic process runs through, the test scope is relatively clear)
Test pause, stop
1. The tester conducts a smoke test first . If there are too many major defects or bugs, or the process is blocked, the basic process cannot be passed, and the test cannot be carried out normally. The test can be suspended and returned to development
. 2. The test item needs to be adjusted and suspended . , The test is also suspended accordingly
3. When there are other tasks with higher priority, you can apply to the leader to suspend the test
4. The system under test has passed the system test and reached the system approval standard , you can stop the test
Test access criteria (when the test ends)
3. Software defects
Defects are a generic term. They can refer to functional errors, poor performance, poor usability, etc. (such as long response time).
Not all testers can submit defects that are approved by development, nor are testers at any Can submit defects recognized by development
What is a software defect
1. Software does not meet product specifications indicated function (demand omission)
2. Software error has occurred will not be specified in the product manual of
3. software features super a product specification as indicating the scope
4. Software does not meet product specifications but has not yet pointed out that should reach Goal (probably the customer may be the product manager ’s requirement)
5. The software tester thinks the software is difficult to understand, difficult to use, slow to run, or the end user thinks it is bad
(what does this software love about what a button means , Or the entire software is not easy to use, the slower it becomes)
Causes of defects
So testers should join the discussion group as soon as possible.
Due to changes in hotspots, the project requirements will continue to change, or the requirements are not analyzed at first.
Due to the complexity of the software, any small changes may affect the
lack of perfect requirements documents in the entire process, and design documents may cause defects. produce.
Good tests can think about the causes of defects
How to find defects
1. The user experience is not good enough
2. There is an obvious error message on the interface
3. The function is not complete, and the code is not written according to the instructions, resulting in the lack of certain functions
4. ** Incomplete functions, ** Cannot operate normally or the process of operation The program crashes and stops running in
5. The logic is incorrect, which is inconsistent with the requirements specification and test cases
6. The interaction between the modules is not good , and problems are encountered when doing integration tests with other modules (the system is not developed by one person)
Yes, when multiple people work together and interact with each other, there may be problems due to less communication) 7. The performance of the program is not good enough to bear the pressure test
Defect Report-Notes
An important point for defect reports is that the reported defects must be reproducible defects
BUG reproduction
1. Do n’t think I think I need to make a bug record and record the process
2. Find out the problem with the competitive conditions since time (such as the balance of Yu'ebao ’s fund is related to time), and find out what the conditions are for this problem
3. White-box problems such as boundary condition software defects, memory leaks, and data overflows may slowly reveal themselves (such as a project? When you start testing, there is no problem, but after a month, the test suddenly becomes very slow, you can consider memory Issues such as leaks)
4. State defects are only revealed in specific software states
5. Consider the interaction of resource dependencies and memory, network, and hardware sharing
Unreproducible bugs
(Suddenly appears, suddenly disappears, cannot catch the law and cannot be reproduced)
1. First of all, such defects should be recorded in detail and submitted to the developer as soon as possible
2. Secondly, reasonable time should be arranged for finding defects that are difficult to reproduce To take into account the overall progress of the test project, defects that are difficult to reproduce at one time can be temporarily shelved to ensure the normal progress of the project.
3. Finally, pay attention to the unappeared bugs during the test process, and then study and study by yourself
Defect report
1. The defect report is the defect recording, classification and tracking of documents
one of the tasks 2. Software testers are books to write good software defect reports
3. Provide accurate, complete, concise , consistent defect report is a manifestation of software testing Professional, high-quality main evaluation indicators
4. Generally, the direct readers of the defect report are software developers and quality management personnel. In addition, people from the market and technical support departments may also need to check the defect situation.
Defect report contains information
◆ Easy to search for defects in software test reports. (Software defects must have their own keywords)
◆ The reported software defects have been isolated as necessary, and the reported defect information is specific and accurate. ( Find the point where the error actually occurred, do not generalize that the entire process is wrong)
◆ Software developers want to obtain the essential characteristics of the defect and the steps to reproduce it. (From the point of view of the developer, give where the essence of the defect comes from)
◆ Market and technical support departments] hope to obtain the distribution of defect types and the degree of impact on the market and users. (Such as application type or flow-type, so judge you for how this defect for users to influence the market large)
Guidelines for writing defect reports (5C)
◆ Correct (accurate): the description of each component is accurate without causing misunderstanding
◆ Clear (clear): the description of each component is clear and easy to understand
◆ Concise (concise): contains only the essential information, not including Any redundant content (not only the steps, but also the data used to color this defect)
◆ Complete (complete): contains the complete steps to reproduce the defect and other essential information
◆ Consistent (consistent): written in a consistent format All defect reports
Defect report organization
1. The title of the defect (e.g. easy to find)
2. The basic information of the defect (environmental information version information, in which project)
3. Software and hardware environment
tested 4. Software version tested
5. Types of defects
6 . defect severity
7. the process defects priority (priority requires the developer immediately for technical support)
8. Procedure recurring defects
9. defective actual results are described
correctly describes the desired results 10.
11. the comment text And intercepted defective images
Defect title
1. Try to write according to the cause and result of the defect ("After A is executed, B occurs," or "B, when A is executed")
2. Avoid using ambiguous words, such as "function interruption" "" Incorrect function "
behavior does not work", etc. You should use specific text to explain how the function is interrupted, how
incorrect, or how it does not work
3. Use keywords to make it easy to search
4. Avoid using terms, slang or overly specific Test details, etc.
Steps to reproduce the defect.
** The steps to reproduce include the complete steps to make it easy for others to reproduce the defect. ** In order to meet this requirement, the information of the reproduction steps must be complete, accurate, concise, and reproducible.
However, in the actual software testing process, there are always some bad defect reports. The main problem is the extra steps, Poor readability, difficult to understand, missing steps, etc.
Requirements for recurring steps
◆ Provide preliminary steps and information for testing
◆ Simply guide step by step to reproduce the defect
◆ Try to record only one operation for
each step
◆ Number the steps before each step ◆ Try to use phrases and short sentences to avoid complex sentence patterns和 句式
◆ The steps of reproduction should be complete, accurate, and short.
◆ There are no missing steps.
◆ Each step is accurate.
◆ There are no redundant steps.
◆ Common steps are combined into fewer steps.
◆ Only record individual actions What are the steps and do not need to include the results of each step
Note on defect report
◆ Has the defect report included complete, accurate, and necessary information for the reader?
◆ Is only one defect reported in a defect report? (Do n’t pile too many defects in a defect report, developers have to do more in-depth Analysis)
◆ Can the reader easily search for the defect?
◆ Can the steps be fully reproduced and clearly expressed?
◆ Is the environment variable or data file used for testing required to reproduce the defect included? Written in the manner of fruit)
◆ Is the title of the defect written in terms of causes and results?
◆ Is the actual and expected results described not clear enough to cause ambiguity?
Principles of defect reporting
1. Organization Structure:
Testers should use deliberate and cautious methods to perform the test and make detailed records. This can encourage them to have a good understanding of the measurement system. When an error occurs, an organized tester can know where the problem first occurred.
2. Reproduce Reproduce: The
tester must check whether the problem is reproducible before writing a defect report. If the error is no longer reproducible, it should still be written down, but the accident must be explained. A good handling principle is to try again and again 3 times before writing the defect.
3. Isolate:
Before attempting to write a defect report, you must try to isolate the error. You can change some variables (to see if the defect is due to data, program, or configuration), such as the configuration of the system, it may change the symptoms of the error. This information can provide ideas for developers to start debugging.
4. Generalize: After
discovering an isolated, reproducible problem, the problem should be summarized. Does the same problem appear in other modules or other places? Does the same fault have more serious problems?
5. Compare Compare:
If the tester has previously verified the test case that is wrong now, then he should check the previous test The result is to check whether the previous test passes under the same condition. If yes, then the problem is like a regression error. Note that because the same test condition may appear in multiple test cases, this step is not just to check multiple previous results of a test case.
6. Summarize: It
is critical to write the wrong summary on the first line of the defect report. The tester needs to spend some time thinking about how the discovered errors affect the customer. This not only requires that the report written by the tester be able to attract readers, make the communication with the management clear, but also be able to help set the priority of bug fixes.
7. Streamline Condense:
After the first draft of the defect report is completed, the tester should read it over and over again, focusing on those steps or words that are not relevant. Implied or vague descriptions and those endless nagging that consume the report due to unrelated details or steps that are not needed in the process of reproducing the error are not the goals of the defect report. (Don't write too detailed, some very simple operations do not need to be too detailed)
8. Disambiguation: Disambiguate:
Testers should carefully check the report at the same time or immediately afterwards to check whether there is any misunderstanding in the report. Testers
should try to avoid using vague, ambiguous and subjective words. The goal is to use words that are capable of expressing facts, clearly and without disputes.
9. Neutralize:
As a messenger of bad news, it is a challenge to submit messages kindly. As with all error summaries, independent defect reports should be fair in terms of wording. Attacking developers, blaming potential mistakes, attempting to use humor or use sarcasm to bow | developers' hatred, and divert attention from the big goal of "improving product quality"
10. Check Review:
Once the tester feels that the defect report is the best version he can write, he should review the report with one or more peers. In the time allowed, the test team should submit the best defect report as possible.
About bug
bug's life cycle:
from the moment bug bug was discovered to have been developed to solve the (development and testing process of communication)
The following can be well represented bug's life
The division of labor in the bug life cycle
Defect tracking management system
Most of the early defect tracking was completed in the form of defect records . There are still many projects that still use this method. However, with the increasing demand for software functions by users, many changes have occurred in software algorithms and complexity. What came was the growth of software defects, and later Excel was not enough, so a defect tracking management system appeared.
In the development of the software industry, once or defect management system is being heavily used include JIRA, BUGZILLA, QC, Zen and so on .
At present, in addition to some large IT companies have self-developed defect tracking management system, many companies use Zen Tao for defect tracking and even project management.
These platforms are mainly different pages, almost all of them are bug management
