什么是好用的缺陷报告记录

TD是开发，测试人员协同工作的工具。缺陷报告本身应该具有清晰的指引性。
当信息不明确时，意味着信息传导出现问题，失真或者通道断裂。

TD的最根本的用户是开发人员，他们据此处理程序中发现的问题。
开发人员处理问题时需要关心的信息应该在缺陷报告记录中体现：
。让开发人员快速理解问题的信息：众多功能和用例中的哪一个
---什么功能出的错
。让开发人员能了解或想象到捕获此问题时的场景：开发人员能够在调试环境下还原或者能够进行代码逻辑分析
---具体的操作步骤，甚至驱动数据，系统环境(这个不常需要)
。谁报告的：
知道具体的报告者，在上述信息不明确的情况下，开发人员可以知道找谁询问。

谁能决定Assigned To?
。测试人员并不一定知道（甚至通常不知道）该分配给谁
分配给谁需要一定的项目开发信息，功能的开发者，如果涉及多个模块和多个开发者，则不容易分辨出来。那相当于测试人员在诊断问题了。
专业的测试人员相对可能比较容易决定，与开发更接近，但参与测试的客服人员则无法决定。
在不清楚分配给谁的情况下，分配给项目经理（具体的人或者建立一个抽象帐户）


最近发现TD报告经常不符合上面基本的预期。
---Detected By：很多是admin. (是测试人员没有自己的帐户吗？)
---描述过于简单：开发人员需要凭借联想才能估计到问题所指

原因可能有：
。没有要求
。没有培训
。个人工作习惯：报告可能来自个人工作的记录，直接粘贴到TD的
。规格化操作可能更费时：嫌慢


以下是2个示例：

1.bug1280
Summary:基本属性
Details:
1：显示信息不完整调度参数下面的解释说明没有完全显示


。基本属性？是哪个模块的功能，操作导航呢？
。配上截图更一目了然

2.bug1279
Summary:数据字典→修改属性
Detials:
1、修改属性后数据库中属性无法更改、例如：在界面中修改tb_10028_1117表中的dest_mis_id字段的长度及字段名称，在TB_1031中的长度发生变化，对应TB_10028_1117中的字段长度未发生变化，修改dest_mis_id为dest_mis_id_1在表TB_0044中的名字仍为dest_mis_id，更改属性后需重新打开后，在其他规则中才能看到有更改


。如果能把Details的内容精简到Summary，并且提供更多的信息，似乎考验我们的归纳能力了
Summary该是什么样子的？
---接口配置工具数据字典维护,修改属性不起作用
（没有绝对的指标，参考指标是：更多的重要信息，准确）
。我猜测这是客服人员报告的：内容非常淳朴，以一个纯粹的使用者的角度：他能简单地告诉你做的根本不对。如果以这种目标审视我们的程序，并最终符合，则程序会比较完美。

----------------------------------------------------------
这是我的回复：（我的习惯是直接在Description中回复处理描述）

字典信息维护的基本逻辑应该是：从现有对象获取，而非孤立指定。

说明这种编辑式的操作是错误的。（缺少先期定义）

在已打开规则配置的情况下，使数据字典的变化即时生效，需要不那么容易的程序实现（事件响应，规则的编辑状态控制）。
----从软件完美的角度，确实应该这样。
（退而其次，提示一下用户，数据字典更新只有在重新启动程序后才生效）
理论上，除非不得已，你才需要重新启动程序，有时重新启动是简化实现的手段。---但可能惹用户抱怨。