Bug 6-"evidence of spot"

Original article published on 13:02:16

An example of a bug is provided in the previous article, which briefly introduces some common attributes of the Bug, such as the Bug ID, status, cause, and assignment. As agreed, this article will introduce the bug reproduction problem, that is, the "Description" section in the bug example.

 

Careful readers will find that several additional tags marked with square brackets are added in the "Description" column of the above bug. This is the tags added to the management process by the author. A complete bug is described as follows:

 

Description

[Test Cases] <The bugTestUse Case ID> [Precondition] <Enter the Preset conditions here> [Descr resume ption] <Enter the detailed description here> [Expected] <Enter the expected result here> [Actual] <Enter the actual result here> [Found in build] <Source code build number of the Bug found> [Reason] <BugFor the cause, enter it as the developer> [Solution] <Solution to the bug> [Resolved in build] <Build code of the source code to solve the bug. Fill in the code by the developer> [Reopen reason] <Optional. Cause of bug reactivate>

 

The description information has been listed in the above table, so it is not necessary to detail it in detail. In practice, the author manages bugs according to this mode. As long as the descriptions are correct, we can reproduce the bugs only according to this part of content. Of course, it is necessary to explain some points:

1 [test cases] [precondition] [descr into ption] [expected] [actual] [found in build] These labels are tested by testers (strictly speaking, they are bug reporters, if possible, it is required that all bug reporters follow this mode for management.) added and filled in, [reason] [solution] [resolved in build] These labels are filled by developers (bug fixes.

2. The content of the test environment is not included in the report of a single bug.OthersThe environment used only in a few cases is described in the preset condition [precondition.

3 [reopen reason] refers to a bug or closed bug discovered by the tester but not modified but marked as modified by the developer, in this case, the tester needs to reactivate the bug. In addition to the reason for re-opening, the tester also needs to add content such as build version information.

4. When a bug is re-activated, a bug enters a new cycle of illness, this is reflected in the bug description as the [reopen reason] label, which will be followed by the [reason] [solution] [resolved in build] and other labels filled by developers to describe the bug correction. status.

5 The content in [resolved in build] is generally written as a version number plus a "+", indicating that the bug will not be reproduced in this version and later versions. For example, systema1.0.1320 +

 

The above for personal opinions, if you have suggestions or exchange needs, please contact unique.wuchaodong@hotmail.com