什么是好用的缺陷报告记录
2012-12-08 14:00
302 查看
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中回复处理描述)
字典信息维护的基本逻辑应该是:从现有对象获取,而非孤立指定。
说明这种编辑式的操作是错误的。(缺少先期定义)
在已打开规则配置的情况下,使数据字典的变化即时生效,需要不那么容易的程序实现(事件响应,规则的编辑状态控制)。
----从软件完美的角度,确实应该这样。
(退而其次,提示一下用户,数据字典更新只有在重新启动程序后才生效)
理论上,除非不得已,你才需要重新启动程序,有时重新启动是简化实现的手段。---但可能惹用户抱怨。
当信息不明确时,意味着信息传导出现问题,失真或者通道断裂。
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中回复处理描述)
字典信息维护的基本逻辑应该是:从现有对象获取,而非孤立指定。
说明这种编辑式的操作是错误的。(缺少先期定义)
在已打开规则配置的情况下,使数据字典的变化即时生效,需要不那么容易的程序实现(事件响应,规则的编辑状态控制)。
----从软件完美的角度,确实应该这样。
(退而其次,提示一下用户,数据字典更新只有在重新启动程序后才生效)
理论上,除非不得已,你才需要重新启动程序,有时重新启动是简化实现的手段。---但可能惹用户抱怨。
相关文章推荐
- AIO的玻璃缺陷自动检测系统测试报告的要点记录
- 开始写博客,记录点什么
- tensorflow2caffe(1) : caffemodel解析,caffemodel里面到底记录了什么?
- 选择某个属性值最大的那条记录(不仅仅包含指定属性,而是想要什么属性都可以)
- oracle手工生成AWR报告方法记录
- 测试用例之缺陷报告的主要元素
- 【笔记】《通俗详细地讲解什么是P和NP问题》的概念记录
- [乐意黎原创]为啥人行里的个人信用报告被深圳前海微众银行查询过并留下记录
- 什么叫DNS?·什么是A记录?·什么是NS记录?·什么是别名记录(CNAME)?
- DNS A CNAME MX PTR 等记录有什么区别
- 什么是A记录?什么是别名记录(CNAME)?什么是MX记录?什么是NS记录?
- Intel 设计缺陷背后的原因是什么? | Linux 中国
- 什么是A记录、MX记录、CNAME记录
- 需求分析报告和需求规格说明书有什么区别
- Windows 10步骤记录是什么?Win10录制操作步骤的教程
- Mariadb 分布式事务两阶段提交 binlog日志 查询日志 都记录了一些什么内容 以及恢复被丢失数据方式
- 第25回 准确报告软件缺陷
- 在IIDNS上解析主机记录这一栏填什么
- 记录,很好的用例子解释了什么是mapreduce
- Linux /proc/pid记录了什么