软件测试从零开始(三)

5、缺陷报告

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

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

5.1 报告缺陷之描述

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

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

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

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

有的测试员对严重等级和优先级之间的区别不太清楚,这里我解释一下:

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

5.2 bug尽可能纯粹

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

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

5.3 不要夸大程序错误

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

5.2 报告设计错误

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4 关于小缺陷

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

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

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

6 测试结果分析

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

总结:

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

原文发布于微信公众号 - 软件测试经验与教训(udatest)

原文发表时间:2017-04-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java架构沉思录

Redis 深度历险:核心原理与应用实践

Redis 是互联网技术架构在存储系统中使用最为广泛的中间件,它也是中高级后端工程师技术面试中面试官最喜欢问的工程技能之一,特别是那些优秀的、竞争激烈的大型互联...

2742
来自专栏微信公众号:Java团长

总结下我在架构师升级过程中的那些坑以及各种体会

先说明,本文说的是技术架构,而不是业务架构,另外,这个架构是指目前比较热门的高并发大数据的架构。论能力,我还达不到架构师的水平,所以我目前还在不断努力。

1091
来自专栏PPV课数据科学社区

5种最流行的AI编程语言

导读:有没有兴趣来了解更多与AI开发有关的内容? 本文将介绍创建AI程序时可以使用的5种最佳语言。 Python ? Python语法简单,功能多样,是开发人...

5198
来自专栏小怪聊职场

管理|从0开始组建一支研发团队(一)

2957
来自专栏达摩兵的技术空间

前端大牛or架构师应该具备这些

相信很多招聘要求上都会写明需要3-5年经验才可以达到架构师要求,并且针对其中一些必要的技术储备大家已经能够耳熟能详,那究竟为什么需要这么久时间,以及具体每项技能...

1006
来自专栏ytkah

app开发学习需要经历哪些流程

  app开发学习需要经历哪些流程?如何零基础入门app开发?以下是知乎热心开发者的经验总结,对学习app开发有很好的参考意义 1.如果没有编程基础的,学习基础...

3113
来自专栏BestSDK

4种主流评论功能设计:虎扑最悬疑,豆瓣最人性

不管是在qq空间,微信朋友圈,在好友的状态下抖一波机灵,还是在新闻下面吐槽最近雾霾又严重了;不管是在纠结吃什么的时候,打开团购app看下大家的评分和点评,还是在...

6826
来自专栏Django中文社区

django开发时遇到问题的正确求助姿势

自 django博客教程发布以来,已有超过上万名读者学习了该教程。一些学习者跟随教程顺利地完成了个人博客的搭建,但一直以来也不断地收到读者的评论留言、QQ 留言...

3478
来自专栏成猿之路

编程,听歌,找图片,看电影,找资源,一个网站可以让你减少10个软件的安装

1052
来自专栏云计算D1net

私有云计算的发展与应用

似乎业界所有人都在谈论云计算。但是,虚拟化是对发展私有云战略的重要一步。如果你已经虚拟化了部分的基础设施,那么你可能比想象的更接近私有云计算。 采用云计算的好处...

3635

扫码关注云+社区

领取腾讯云代金券