大家都发资料，我也发一个自己写的缺陷模板

linlin212

呵呵，公司要求写一个提交bug的模板，顺手写了个，贴上来跟大家一起研究下，欢迎鲜花和板砖

[ 本帖最后由 linlin212 于 2010-8-6 12:05 编辑 ]

linlin212

::aida::: ::aida::: 没人顶

linlin212

谢谢了 呵呵

[ 本帖最后由 linlin212 于 2010-8-6 12:02 编辑 ]

zhangting85

1，严重级别以外，还需要有优先级别。
因为有的很严重比如会导致系统崩溃，但缺陷出现的步骤烦琐，客户使用时出现的可能性低，就可以设一个低优先级以后改，有的问题虽然不严重，但是用户友好性非常差，必须优先改，比如拼错公司名称。

2，复杂的bug会很难写进你的模板里去。
有的bug可能有特殊的前提条件，可能需要10个以上的操作步骤，可能在某一个操作步骤之后要等系统给出某个正确反应才能继续下一步操作，这样的就很难写进你的模板里去。

另外对缺陷模板的作用表示不解，一般上使用缺陷管理系统记录bug会更好。word文档记录bug会导致文档版本过多，难以统计，难以更新等等缺点。

linlin212

第一：我们这里bug的优先级别是PM来定，所以测试只是来报告严重级别
第二：不管这个bug怎么特殊怎么有前提条件，那也会有开始有结束，那么都可以写进这个步骤里边，也就是说任何人按照你的步骤操作都可以将bug复现
第三：这个模板就是给大家一个写缺陷的思路，具体的也是会写到缺陷管理工具里边

zhangting85

首先如果你想听纯赞美的就不用往下看了。

你没明白我的意思。

我非常相信你的模板在你们那里完全可以使用。但是我也非常怀疑其易用性和通用性。可以使用和很好用是两个概念

假设一个有很多步骤的bug，以及有XX条件的bug，分步骤写会很长，也就很难阅读，特别是有中间结果的时候，举个例子：

有这样一个bug
先在A功能里设置一个参数，在B功能里确认A的参数并使其有效，在C功能里看到结果。

那你的中间步骤的结果（比如B里面点了确认按钮之后出现一段提示已确认的文字），你是写在步骤里，还是写在预期结果里。如果你写在预期结果里，怎么和上面的步骤对应，特别是当这个工作流较长时，你怎么标明步骤和结果的对应关系。如果你写在步骤里，你的步骤就变成了步骤+中间结果，结果你的bug报告里预期结果和实际结果部分根本没有体现完整的结果，而只体现最终步骤的结果。

再补充一个问题，假如你提出一个bug，但是这个bug在开发看来不重要，你有义务在bug报告里附加上一些具有说服力的内容让开发知道这个bug为什么具有这样的重要性。这个内容你写在哪里？

我知道你的模板这样写是可以写的，但是缺点就是，太不灵活。就像是IEEE里死板的软件测试标准，没人用的来。

linlin212

“这个模板就是给大家一个写缺陷的思路”不知道你看到我说的这句话了没，我写这个东西也不是说要赞美什么的，只是现在大家提bug没什么格式，基本都是按照自己的想法乱写，所以我才写一个这样的东西，帮助大家整理一下思路，就是这个目的，我觉得要bug模板可能误导了你，大概叫范例差不多的样子吧

linlin212

原帖由 zhangting85 于 2010-8-6 11:17 发表
首先如果你想听纯赞美的就不用往下看了。

你没明白我的意思。

我非常相信你的模板在你们那里完全可以使用。但是我也非常怀疑其易用性和通用性。可以使用和很好用是两个概念

假设一个有很多步骤的bug，以及有 ...

我觉得你的举例，如果我是测试B那我会把B的结果，例如你说的（比如B里面点了确认按钮之后出现一段提示已确认的文字），写到B的期望结果里，但是如果我测试的是C，或者说是因为有B才有C，也或者说B的结果影响到C，那么B的结果我会写到步骤里，因为那里的期望结果和实际结果是要写C的

sakuna

还行

[ 本帖最后由 sakuna 于 2010-8-6 13:25 编辑 ]

linlin212

::yiwen::: ::yiwen:::