杂谈客户端低级bug
上一篇 /
下一篇 2014-09-14 22:37:47
/ 个人分类：step by step android测试
Hi,all
客户端项目复盘会中提到低级bug这个字眼，且出现率约为20%+。有些开发同学就问，什么叫低级bug，
测试同学是怎么评定一个bug是不是低级bug。有些同学也提出，低级bug的比例那么高也是有原因的，随着开发任务的增加，发现到了提测的时候，满满的时间都用来做编码了，来不及做自测充分...
针对以上提到的东东，这里我来点碎碎念啦，欢迎拍砖~
主要从以下几个方面来讲吧：
- 1、什么叫低级bug？
- 2、为什么要降低低级bug？
- 3、如何来降低低级bug？
- 4、几个需要纠正的误区
-------------------------------------------------我是分割线 ------------------------------------------------
1、什么叫低级bug？
在这里我分为2个角度，一个是从黑盒测试的角度，一个是从白盒的角度。 站在黑盒测试的角度， 拿一个比较实际的例子，比如今日双列大图页面来说吧。 明显的页面显示错误，一眼就能看出来的问题（比如折扣计算错误，左右两列商品标题未对齐，商品图片被拉伸被切割）叫做低级bug；用户主流程操作无法进行（比如点击坑位后直接crash，上滑列表后第二页商品无法加载一直loading）也叫做低级bug。
站在白盒测试的角度，这个往往是开发同学编码中所特别注意的，比如我们日常中经常遇到的导致客户端crash的NullPointerException错误叫做低级bug；再比如网络异常等异常情况未做处理（无网络提示、网络延迟loading提示）也叫做低级bug；再比如，android2.3.X未做适配，导致2.3.x手机上crash掉或者异常也叫做低级bug。 虽然上面说的无法用确切的类似于1、2、3这样的数字来严格定义，但是相信你对什么叫低级bug是不是也有了一个比较大体的认识？
2、为什么要降低低级bug？
有时候开发同学会说，我希望这次的bug测试同学可以按照什么维度来分类下，但是我想告诉大家的是，我们按照什么来分类的同时，也是基于我们发现现状中可能存在某些问题，我们希望通过确切的数字来论证这一点，进而希望改进这一点。
测试同学对于bug的分类维度及统计方式有很多种。
可以按模块分类，可以按bug的严重等级来分类，可以按bug的解决时长来分类，可以按bug的指派人来分类，也可以按bug的优先级来分类。每一种分类都有我们的问题和目的包含在里面，我们希望引导的结果在里面。如果我们发现测试过程中，单独的某个模块出的问题比较多，那我们会将数据统计出来，发现这个问题确实存在的话，会深度与开发同学挖掘为什么这个模块问题多，什么原因导致的，日后如何避免它们。按bug的解决时长来分类，是因为我们发现很多bug的解决时长太久，进而阻塞了测试计划的正常进行，将数据拎出来，给大家一个直观的认识，大家面对这个现状如何去改变。诸如此类，也欢迎开发同学站在自己看到的问题的角度来给予测试同学不同的分类维度...
本次项目之所以会单独拎出来低级bug这一指标，意在于通过这个数字来告诉大家，我们的低级bug比例偏高，是到了严肃重视并且处理它的时候了。
在时间一定的前提条件下，低级bug多了，测试同学投入到页面的信息展示以及主流程的操作check上的时间也会相应的增多，从而相对的非低级bug的投入上的时间就会减少。让我们来算一算出现一个bug我们都需要额外做哪几件事情吧：1、首先测试同学在kelude上提交一个bug（有时候冒烟测试就直接被打回，最起码提测时间又要向后延迟0.5-1天,测试同学陷入等待状态）2、开发同学fix bug，投入一定的编码时间（这中间也可能会或多或少的产生开发与测试的沟通时间）。3、对应的开发同学review代码。4、测试同学重新check bug是否已经fixed。5、与此同时，还可能会增加另外一种糟糕的情形-为了修复这个bug而引入了其他的bug。这几个可能在每个人都看来都比较再正常不过的步骤，花费的时间可能是你想也想不到的。在这里，引用下官方的研究数据及观点： - 平均而言，如果在需求阶段修正一个错误的代价是1，那么，在设计阶段就是它的3～6倍，在编程阶段是它的10倍，在内部测试阶段是它的20～40倍，在外部测试阶段是它的30～70倍，而到了产品发布出去时，这个数字就是40～1000倍，修正错误的代价不是随时间线性增长，而几乎是呈指数增长的。
- 软件生命周期中各个阶段注入的软件缺陷,被发现和消除的时机包括本阶段以及此后的所有阶段,每个阶段注入的软件缺陷在本阶段被发现和消除是最佳的选择,因为前期阶段注入的软件缺陷在后面阶段被发现和消除的代价比在本阶段被发现和消除所花的代价高得多,势必造成对成本及目标实现不利的风险.
当然上面的数字对于我们来说不一定是准确的。不同的软件开发模型，不同的bug性质，在上面的数字中必然有上下波动，但是足以让我们认识到，修复一个被测试同学发现的bug的代价肯定要比开发同学在开发阶段将它消除掉要少得多。
3、如何来降低低级bug？
降低低级bug，离不开每一位同学的努力，首先要从对低级bug的认识和流程上来入手了。目前我们的提测标准是冒烟通过。但是我们会发现存在以下几个问题：
- a)虽然冒烟通过了，但是异常流却存在的问题比较多。
- b)不同模块质量参差不齐，有的模块质量很好，有的模块却比较差。
- c)自测比较随意，没有固定的标准。
针对以上几个问题，个人觉得自测需要分以下几个步骤来走。
- 1)测试同学罗列出经常出现的低级bug点给予开发同学各自做check。
- 2)测试同学单独拎出来P0级别case建立实验室给到开发同学执行完毕，做到执行后有迹可循，有结果可查。
- 3)开发同学以测试的身份做交叉测试，独立于测试case。（这一点，开发同学在复盘会上也提到了，个人觉得这一点很好，每一位同学也都在向这个目标前进。）
4、几个需要纠正的误区
误区1、明天就要提交测试了，可是我今晚刚刚编码完成，简单自测下，冒烟case都跑过了就先提交测试再说罢，后面我再慢慢修复问题。
解答：╮(╯▽╰)╭，请从上文找答案，这个时候我宁愿等待开发同学充分自测后再提交给我。
误区2：我自测是不是相当于增加了我的工作量，同时减少了测试同学的工作量？ 解答：开发自测的目的并不是这样子的，而是要弱化开发/测试的角色，通过共同努力，扬长避短，形成一套立体的质量保证体系,缩短软件开发周期，提高软件开发质量和效率。
误区3：我把这些个工作都做了，测试同学干啥子？
解答：测试同学可以做更多的事情，要做的事情有很多，如：1）提供更多bug信息，帮助开发同学快速定位bug。2）为方便开发自测做尝试，比如数据准备，代码检查工具，测试数据中心就是个很好的例子。3）将更多精力放在不易发现的问题上，比如性能等。4）更多关注用户体验与反馈解决。5）只要可以想到的，希望做的，都是可能的...
收藏
举报
TAG:
