原文发表于2009-02-02 13:02:16
在上一篇文章中给出bug的一个示例，简单介绍了bug自身的一些常用属性，如Bug ID、状态、原因、指派给等。按照约定，这篇文章将介绍bug重现的问题，亦即bug示例中的“描述”部分。
细心的读者会发现，在上面的bug“描述”一栏中又增加了几个用方括号标记起来的标记，这是笔者在管理的过程中添加进去的几个标签。一个完整的bug描述如下：
|
描述 |
[Test Cases] <出现该bug的测试用例的ID> [Precondition] <在此填写预置条件> [Descrīption] <在此填写详细描述信息> [Expected] <在此填写期望结果> [Actual] <在此填写实际结果> [Found in Build] <发现bug的源代码build号> [Reason] <bug产生的原因，开发人员填写> [Solution] <解决bug的方法> [Resolved in Build] <解决bug的源代码Build号，开发人员填写> [Reopen Reason] <可选，bug被重新激活的原因> |
关于描述的信息在上面的表格上面基本上已经列出来了，因此不必要再一一详述。笔者在实践中即是按照该模式来管理bug的，只要“描述”得当，我们完全可以仅依照这部分的内容就把bug重现出来。当然，有些地方还是有必要解释一下：
1 [Test Cases][Precondition][Descrīption][Expected][Actual][Found in Build]这些标签是由测试人员（严格意义上是bug提交人员，如果可能的话可以要求所有的bug提交者都遵循这种模式以便于管理）添加并填写的，而[Reason][Solution][Resolved in Build]这些标签是由开发人员（bug的修正人员）填写的。
2 有关测试环境的内容不列入单个bug的report中，对于其他仅在少数用例中使用的环境则在预置条件即“[Precondition]”中加以描述。
3 [Reopen Reason]是指测试人员发现不过没有被修改但是已经被开发人员标记为修改的bug或者已经被关闭的bug死灰复燃，这个时候测试人员需要重新激活该bug，因此除了需要注明重新打开的原因之外，一般还需要在其中添加如诸如Build版本信息等内容。
4 当一个bug被重新激活之后，一个bug进入一个新的生病周期，这在bug的描述中体现为[Reopen Reason]标签之后会跟着出现[Reason][Solution][Resolved in Build]等有开发人员填写的标签以描述bug的修正情况。
5 [Resolved in Build]中的内容一般形式上写为版本号加上一个“+”表示该版本及以后的版本中该bug都不会被重现了。如SystemA1.0.1320+
以上为个人意见，如有意见建议或交流需要，请联系unique.wuchaodong@hotmail.com
