缺陷,测试人的命根 - 软件测试从美好开始之三

发布于 2021-05-11 20:04 ，所属分类：软件测试工程师学习资料

我们，一起学习+涨薪不掉队！

转｜Mack gongzhong号 软件测试经验与教训

分享你的测试成长经历，吴老师免费送书！

5、缺陷报告

当找开发而对方不愿意理你的时候，当感觉绩效考核对你不公的时候，当看到是别人晋升加工资而非你的时候，当提了问题而开发不改的时候，也许一种可能是你在测试报告上存在问题。

顺便说一句，个人看法：测试人员的责任不是保证所有错误都能得到改正，而是准确报告问题，使项目干系人能够理解问题的影响，不过具体如何，还需看测试员在自己公司的使命，可以看一下我的另一篇文章《测试员职责浅谈》。

5.1 报告缺陷之描述

缺陷报告需要尽可能提高可读性：

一次只走查该程序错误一步
为每一步编号
不要跳过重现问题所需的任何步骤
列出能使开发重现bug的最少步骤
使用简短句子
说明实际结果和预期结果
如果认为严重，解释为什么严重。
注意语气

另外对于老手我觉得仍需要提醒以下几点：

解释缺陷会怎样影响产品的正常使用？
会破坏什么数据？
用户如何经常遇到这个问题？
利用客户的态度/网上对于类似软件的评论
问题可能给用户带来的麻烦
引用运维/技术支持的数据
以前的版本这个模块没有问题

有的测试员对严重等级和优先级之间的区别不太清楚，这里我解释一下：
严重等级表示程序错误的影响，优先级表示什么时候公司要求修改错误。一般严重等级是固定不变的，优先级随项目的进展而发生变化。例如，程序启动界面或其他页面有公司标志，但公司名称写错了，这纯粹是装饰性问题，但是大多数公司都会把它当做高优先级的缺陷。

5.2 bug尽可能纯粹

有时候开发会抱怨：能不能把类似的缺陷提到一个bug报告中，否则改起来太麻烦了。确实，有的bug可以也应该提到一个报告中，比如多个页面的“翻页”都存在问题，因为可以一次性解决；但有时候不应该提到同一个报告中，比如多个页面的提示信息存在相同问题，否则有的错误就会得不到解决。

在不清楚是否应该分开的时候，可以先提到一个报告中，开发修改后打上修改标记，并将未修改的重新开一个缺陷。

5.3 不要夸大程序错误

有人觉得严重程度低了，开发就不重视，所以会采用提高严重性来“促使”开发重视和修改bug。不建议采取这种措施，因为这会影响到我们测试部的可信性，而可信性是我们影响力的基础。如果我们所报告的程序错误看起来比实际情况严重，就会失去影响力！

5.4 报告设计错误

有的测试员有这样的想法，开发竟然不如自己懂业务丢不丢脸？

有这样的想法，说明测试对开发的工作方式不了解。测试员可能是项目团队中看到或者评估设计错误及其对现有系统影响的唯一成员，错误测试员不报告设计错误，谁还会报告呢？

有人（包括一些测试）认为我们测试员不需要报告设计错误，因为程序的设计在项目初期就应该已经定下来，而且我们测试员也没有专门的知识来评估设计。我觉得这两种观点都是错误的。

关于设计的后期评判。即使产品已经事前完全设计好（不太可能），多数人也要到系统架构完成时才能充分理解系统的含义。很多时候我们直到系统几乎完成，甚至直到真正使用系统，才会发现系统设计错误。所以当发现设计问题时必须报告，不用觉得发现太晚怕批评而不报告。

关于专门知识的问题。如果确信是问题，直接提就是了。如果不确定，先沟通。

5.5 报告小问题和不可重现的问题

报告之前努力重现，并找程序员帮助。即使不能复现仍然建议记录，并标记为不可重现。
定期浏览bug库，总结不可重现缺陷的模式，同样的问题可能出现多次。
当要报告一个不可重现错误，特别是在项目后期时，需要格外注意努力重现该bug。如果做了大量尝试仍然不能复现，则明确说明这缺陷是不可复现的。并描述所做的工作（重要）。

5.6 不要坚持要求修改所有程序错误，要量力而行

有时项目经理出于风险，或者客户不会为修改付费等原因不修改程序错误。因为每个程序错误修改都可能会引入新的错误（甚至修改一个bug，却引入了一个严重bug ），特别是临近交付的时候，即使开发改了，测试人员也没有时间进行深入测试（这意味着风险），项目经理出于这样的考虑，有时候会拒绝一些bug的修改。

遇到这种情况，需要根据实际情况进行处理。比如召开评审会，比如意见不一致时向上级领导反馈，或让项目经理进行上线功能的裁剪，或者跟客户申请延期。

-----对测试经理的建议------

5.7 关于利用缺陷数评价测试员

曾经有段时间我把提交的缺陷数作为评价一个测试员好坏的重要指标，后来发现了很多这种做法带来的弊端，例如为了提高错误数，更多的容易发现、肤浅的缺陷被报告了出来，有时候同一个bug分成多个实例报告，bug描述也越来越不规范（这些现象慢慢影响到了测试部的威信），甚至老员工也开始不那么乐意花时间指导新人，开发也抱怨我们测试的浅、提的bug看不懂、应该提一个的bug非要弄成多个......这不是我希望看到的，如果必须把缺陷数作为KPI，需要好好引导。

5.8 关于小缺陷

开发人员经常会抱怨我们提交了一些“小问题”，对此我们需要坚定立场。

任何产品都会存在一些小缺陷，但我们得明白，随着小缺陷数量的增加，客户信心会下降。而且更糟糕的是容忍这些缺陷的腐蚀作用。当停止报告小缺陷后（有些公司要求员工只报告“值得报告”的错误），测试员和公司就会容忍越来越多的严重缺陷。长此以往很容易失去客户。

顺便说一句，不断容忍更大的错误是造成挑战者号航天飞机空难的一个重要因素。Richard Reynman在他的《你在什么方面在乎别人想什么》（《What Do You Care What Other People Think》）一书中，对这个问题做过说明

6 测试结果分析

软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。

总结：

限于文章的篇幅，本文不可能给出一个类似于 checklist 的指导性的软件测试新手入门。无论从事软件测试还是从事其它的工作，技术上的和技巧上的问题都可以通过查询相关的软件测试技术书籍获取，掌握一套基本的方法论是最重要的。以上文字，都是作者从事软件测试工作积累的经验之谈，如发现谬误之处请不吝指出。