灌水 又要写年终总结了,大家对测试团队的漏测率怎么看

jacksonchina · December 26, 2017 · Last by lwtazt-github replied at April 29, 2019 · 3570 hits

大家团队里边,漏测率是怎么统计的呢?

我所带的团队是个2c的产品,前端依赖十分重,公司上一层的领导认为,目前的漏测率很高,不可接受。大概是3%吧。一周一个版本,
平均一个版本发现200个缺陷,漏5-6个这样。

说实话,从我的角度,我觉得每周发布的节奏下,我们已经尽力了。

不知道大家平时的工作中是怎么看待这些的。如果你们的漏测率很低,请分享下你们是如何做到的

共收到 20 条回复 时间 点赞

一周一个版本200个缺陷,你们的缺陷好多呀。。

200个也太多了吧。。。

最主要的还是看bug的严重程度和触发条件。 如果容易触发,严重程度也很高。 这样的bug漏测一个都是不行的。 相反的如果bug的严重程度很低,例如就是个简单样式问题,而且触发条件极其苛刻。这样的bug来10几个20个都可以忍受

孙高飞 回复

十分赞同。再多提一句,简单的UI样式问题,大部分都应该在提测前避免的,不应该在测试阶段出现。

kilalonger 回复

我就是举个例子

每周发布,200个不是很正常么。。。
尽力就好,没主流程异常就OK了。
监测异常,第一时间反馈就好。

Author only
ice 回复

是的。一周,半天讨论需求,3天开发,1天半功能测试+回归测试。这种前端做的很重的项目,就是很多bug。。开发试过一天修复了100个bug

magicyang 回复

看来大家都差不多啊。

一个版本200个bug,这是开发自测试不充分呀。感觉你们测试是开发的保姆了。

Droid roll 回复

哎,这你就不懂了吧,开发都996甚至更夸张开发了,哪来的自测时间。。。

也可以从流程上优化,开发自测+测试验证+产品UAT+生产验证,大家一起参与,一起把好质量关。对于线上出现的漏侧场景,及时反思总结,看是没有分析到位还是执行层面没有把控好,如果是没分析到位,那就追加到测试用例,几个版本积累下来,肯定会越做越完善。然后将全量的测试用例抽取主流程,整理出发版验证checklist,每次发版前按照checklist一条一条执行,坚持下去,相信质量会越来越好

容忍错误 毕竟工作中不断有坑要踩 但是低级错误扣分、重复错误再犯扣分、事故级别的错误扣分、严重投诉扣分。。。

我们公司专门分QA和QC,QA就是搞这个事情的,出了线上bug,评估影响,定级……年底算账😝 一般都是开发和测试55开背锅,有时候还得搭上运维,产品

纯稀饭 回复

合理的惩罚制度当然很好。就怕严格这么执行之后,每个版本都有处罚,结果只会是士气越来越低。目前的改进措施,都是着重从总结,复盘,然后改进工作效率的为主。

jacksonchina 回复

如果每个版本都有我说的那些个问题,是不是该反思测试人员对工作没有用心或者自身水平有限呢。
我们刚开始推的前几个月确实有一些处罚,但随着时间推移,低级错误和重复错误的的确确是减少了
当然这种规则这也和结果导向的公司文化分不开。

纯稀饭 回复

有理。可以尝试

先看复现难度分析线上出现的概率,进而去分析影响范围、产生的经济和体验上的损失,然后析影响了多少日活等其他数据,然后来对这个漏测定性。
不太注重漏测了多少。

我们之前发布一个版本,出现38个产品崩溃问题,有一半都是偶现崩溃。你说这开发水平有多差,公司为了节省成本,找来的大部分开发都是培训机构出来的,简直了。我作为测试领头人,干完那个版本直接走人了。

jacksonchina 回复

我只想问你们几个前端

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up