I want to emphasize the nature of the following phrase: bug of the underlying causes? bug does not produce the root causes of this bug where the source code, even though the information and analysis may be close. But the bug was found means to find the root cause for these errors. Through some examples to illustrate the problem may be more clearly.
Let us look at a common thread synchronization problems on. Suppose a multi-threaded applications need to synchronize access to a data structure. Assigned to test the product's QC engineers found that in some scenarios, the application while not Crash, but it will stop responding. QC process is normal, this bug has been recorded in the bug tracking system, and describes the test scenarios and stop responding to actual results. However, if the QA engineers familiar with the source code, you can bug the cause of the preliminary analysis. For example, the QC engineer may determine the cause of this bug is not freed before the thread mutex, thus creating the conflict. The analysis can be recorded in a detailed description of the bug, bug analysis as a basis.
(2) Bug revised and further analysis
As always, found a bug, the developer should be responsible for it. However, if the bug bug discovery process includes a preliminary analysis of root causes, then on how to solve this bug, the developer may have more information. Although this is not a preliminary analysis of QC engineers purpose of bug, but it may provide developers with more ideas.
In addition to fixing bugs, and records the specific steps to achieve the developer should also conduct further analysis of the bug. The analysis should focus on leading the development of scenarios generated bug.
In the case of thread synchronization, developers should not only record the addition of a call to release the mutex (Note: Mutal Exclusion = mutex lock to ensure data is not shared by multiple threads simultaneously access granted only to share a thread exclusive access to resources). Instead, developers should find out the reasons does not release the mutex. Assumption of the reason is: because the need to synchronize more than one way to return point, so developers forget to clean up some control path code.
Simple analysis of this kind brings great practical value. Different from the records of specific solutions to specific problems, we now have the experience to solve many cases, in some cases not even related to thread synchronization and release mutex. However, the analysis does not end the process, we need further analysis to collect all the data will be converted to practice, to help in the future to avoid the occurrence of a similar bug.
(3) bug prevention of
Analysis of the final step is to find a way to prevent similar mistakes. This approach not only to the development, QC engineers, but also to write the code is not directly responsible for a senior developer.
The results of this phase is some useful practical experience, developers can prevent these practices and not bug correction bug. These practices should not be a specific solution to the problem. Thread synchronization in our case, such a practice might be: Is there scope of the audit mechanism to obtain and release resources? This practice (not necessarily suitable for all programming languages) can guide the developer to use a class (class) package of resources, such structures (constructor) function with easy distribution and destructor (destructor) function releases resources. If compliance with this agreement, when the program ends this way, no matter how the control path, and resources (the above example obtained mutex) total can be released.
Bug bug prevention analysis of the entire core of the process. The practice of this phase can be summed up in the broader context of prevention of potential defects. As the results of extensive application, analysis into a specific problem will be easily recovered.
Is very important that the example before us is a random bug. Developers to inadvertently forget to release resources. Realized in the code, this bug is randomly generated, but generated a similar bug has a very high probability. So, although this type of bug is random, but still can be foreseen and prevent.
(4) Release experience
Analysis of the practical experience obtained should be recorded and published, so other developers can learn from these experiences by avoiding similar mistakes. The best way to experience a release is the knowledge base. This will make the new knowledge flows within the organization was related to the development of staff learning.
If the results of the analysis is not communicated to others within the organization related, then the aim of the analysis will not be met. To avoid the next bug appears the only way is to let developers know how to avoid it, and encourage them to do so.
Bug analysis example
Let us examine another example, in order to better understand the benefits of bug analysis. In this case the, QC engineers in the following operation: When entering a long string to the application causing the crash (crash). This conclusion is in itself requires a certain level of analysis, but the QC engineers are not satisfied with this analysis, further study of the relevant code, found that crash because the input string processing problems. One step is to enter the character buffer size in a fixed array, and this array is sometimes too small.
And as examples of thread synchronization, QC engineers preliminary analysis led to great value, development can more easily find and fix this bug. In addition, the real cause of defects in the recording but not on the surface, will help others avoid a similar bug.
Then, developers began to fix the bug. When the amendment, she not only records the solutions, and explains the causes of lead defects. In this case, because the bug caused by the operation of untreated C / C + + buffer, there is no regular testing for the size of the buffer is not enough. However, this conclusion can even be further summed up the experience for wider application to help developers in the future to avoid similar defects. Therefore, the analysis of the final stage of development of a more senior officer in the group of developers with the help of practical experience are the following: Avoid the use of untreated C / C + + buffer as far as possible the safe use of collections and strings, 濡俿tandard template provided the database of available collections and strings. This completely avoids the previous discovery of this bug.
Benefit
Bug analysis brings a lot of benefits. The first benefit is to help developers create the wrong lessons learned, and make him in the future to avoid similar mistakes. Sometimes, only a specific bug correction rather than to analyze it will not help the cause and improve in the future. In this case, only the in-depth analysis and guidance of senior developers to enable developers to grow and improve their ability.
Wider benefits that allow other developers to learn from the mistakes of colleagues. Analyze and summarize the practical experience can prevent the production bug, this knowledge sharing among members within the organization. Developers created a bug to help others within the organization to avoid a similar bug there.
From a more general point of view, publish best practice (such as bug analyze and summarize the practice of) the members of the organization to promote the learning and self-improvement. It would appear, Bug analysis of the value of prevention is also not only flaws.
Another advantage is that by recording from a broader perspective on the bug, other QC engineers within the organization will know how to find a similar error. In addition to testing within the organization to share knowledge and experience, bug analysis process can promote the development of better testing techniques and tools to help find a similar bug. Therefore, even if defect is not completely prevent, but also make it easier to find.
As a result of all of the above benefits, QC in a test will have more time to test more complex scenarios and found more "cunning" bug. If you have a similar bug was not susceptible to prevention, and QC have better technology to find a similar bug, there is a more time to carry out more advanced tests. Of course, the organization's quality products will be enhanced.
Finally, I would like to emphasize that the bug of not only the collection of implementation problems, and summarizes these issues from the experience. For example, lead to a bug causes the demand may not be sufficiently clear. In this way, the experience gained through the bug analysis provides a way to prevent the demand is not clear. This experience may not be on the organization's developers have an effect. So, although QC engineers began the realization of the results verify the developers, but also need to improve the development process, such as requirements gathering, design process and so on.
4. Summary
The quality is not really bug the production of products. Any other goals are to make within the organization to accept members from thinking it is normal for software defects as part of the workflow. Therefore, the first step is to prevent the recurrence of the same bug. We could easily implement this goal. We can produce a developer of a bug to improve practices throughout the organization.
Products through in-depth analysis of a bug, we can understand the mechanism of this bug: Why would? How to prevent it? How do the next time we find it more easily? Just a little time to understanding our bug, rather than just fix it as soon as possible, we can gain experience. In this way, because a defect wasted time can be turned into investment: to ensure that similar mistakes will never happen again.
相关链接:
Adobe Is Very Fragile, Then Photoshop It?
God used to measure BI
Poisoning Emergency Treatment Measures
Source Editors Comments
VOB to Flash
Do not let your single into a Disturbance with
Kaspersky KIS7.0 Stand-alone Public Celebration Was Held In Beijing
Picked XML Or CSS Tools
Frontpage2000 Jianzhan contrast detail - Relative 98
MPG to Flash
AVI to MPEG4
Export and the introduction of THE registry
revolution in software testing
No comments:
Post a Comment