关于提BUG的一些疑惑

做为测试执行人员，最经常不过的事情就是提BUG。找到BUG，提上去，这种看似简单的事情，我还是存在一些疑惑。不同的人， 有不同的方式和风格，比如有的人提的BUG比较粗、有的人提的比较细德行。之前，我坚持自己的方式不错，但是看到别人不同的方式所带来的效果，自己也开始反思和比较起来。

1 BUG的粗与细

记得看过一些测试书籍中提到，BUG最好是反映出一个问题。我的原则是在一个界面上类似的问题提一个BUG。比如一个表单的提交界面，检查各输入框的校验功能，存在几个输入框的校验有问题，在一个BUG中列出来。再细一点的做法可以分开提数字校验、字符校验、金额校验等多个BUG，甚至可以一个输入框提一个BUG（我想开发不乐意了）。一般来说，你提的细也没有什么错，只是在一般的项目中，BUG的多少关系着一些相关人员和项目的考核（利益问题就不说了），还有开发人员修改起来比较麻烦（一个BUG走的流程也很多，同一个界面修改了这个又要改那个）。我最近遇到一个这种问题，金额校验的BUG，在系统多个页面都有。当时没想太多，遇到一个页面的提一个BUG，结果提了几个BUG上去，被审核人指为‘重复’。仔细一想，这些页面可能都是调用一个校验程序，不需要一个页面一个页面的提BUG，但是验证时还是要一个页面一个页面的验证。这种情况可以提一个总的BUG，再把不同的页面说明清楚。但是这样还是存在问题，比如如何定位BUG的位置，对各模块的BUG统计有影响，如何指派人去修改（不同的人负责不同的模块功能）等等。粗与细还是要根据当前的实际情况进行拿捏。

2 对于在需求中没有明确的BUG提或不提？要先与BA或开发人员确认吗？

在我们公司，软件需求写得不详细已经是司空见惯了。边测试边修改软件需求也是经常发生的事情（可能是测试时发现一些问题或者开发时功能无法实现等等）。如果测试中发现一些比较严重的问题在需求中没有涉及到，我认为要与需求人员、设计人员先进行确认，看问题需要怎么解决。讨论的结果可能是立即补充需求进行修改，也可能是认为这不是问题不做修改，还可能是认为这是问题但在这个版本不做修改。以前，我遇到这种情况时，往往在讨论结果为立即修改时才录入BUG，似乎这样顾及了大家的意见。但是，我现在要更加明确自己做为测试人员的立场，如果经过讨论还是认定这是问题，立即录入BUG。这样，对应上面的三种情况，结果为立即修改，BUG审核通过指派下去开发人员修改；结果为不做修改，BUG被拒绝，但是测试人员可以在自己的评估报告中说明被拒绝的原因，是否合理，以及拒绝后的风险；结果为本版本不修改的，BUG可以延期到下个版本，评估报告中也可以说明这点。

以上谈到的是处理比较严重的问题，还有一些细微的问题，需求中也没有提及。这时，可以先找人确认或者自己比较确定是BUG的就直接提交了。这有时关系到测试人员的工作态度问题。说实话，我以前经常放走这类的BUG，认为这种问题太小开发不愿改的或者站在开发角度找借口（比如实现起来麻烦等等），还有就是怕这种BUG会被驳回或拒绝之类的。最近遇到的一个问题让我意识到自己的做法不对。是一个导出为CVS文件的功能，CVS文件导出后用EXCEL打开，部分格式上有点问题，比如时间本来显示到秒的，显示出来截去了最后两位，但是实际的数值是正确的。我想这是显示格式上的问题，反正数值是正确的就没有管了。但是，我的同事提了出来，而且是提了多个（有多个导出功能）。刚开始开发解释是因为用EXCEL打开造成的，但是随着提的BUG增多，大家开始商量解决方法，最后BA决定即然CVS文件用EXCEL打开会造成这些问题，以后导出文件就改为XLS格式。经过这件事情，让我意识到自己是测试人员，发现问题，提交BUG，这是我们的工作和职责，无论大小都应该提交给项目组，让大家解决。