怎么会允许你投入这么多测试人员(研发测试接近3:1)

 

这是一个经典的问题,我大约答复,业务较多,包含许多其他内容,单元测试,部署等等各种事情,没有过分纠结。现在回想,当时聊昏了头脑,应当简洁回复一句:测试人数根据测试任务多少、时间多少实际情况而定 

 

过分的追究研发测试几比几、KPI、人力成本控制等等,已让大家已经丧失最基本的判断,其实道理与依据很简单:

 

测试任务=测试人数*时间

 

a.测试任务 恒定,时间 短,人数 多

 

b.测试任务 恒定,时间 长,人数 少

 

c.测试任务 多,时间 短,人数 更多

 

补充:人员能力参差不齐,也是影响人数增加的因素

 


  X:快速迭代如何提高测试覆盖率

 

我大约建议,看工作量与实际情况,研发测试1:1或者N:1结对投入,同步编写代码与测试用例(自动化测试用例),采用代码覆盖率工具统计覆盖率。

 

答复其实不全面,测试覆盖率(Test Coverage)应该包含两个部分:需求覆盖率、代码覆盖率

 

需求覆盖率:一般会作为测试准出标准的一个指标,但是在快速迭代,需求不一定是确定的,所以很难界定需求的覆盖率,快速迭代提高需求覆盖率是一个难点, 但可以退求其次,需求变更前时间段内的需求覆盖率,短时间内的需求覆盖还是可以统计。

 

代码覆盖率:其实这应该算白盒测试的内容,各类语言都有相关统计工具,比如JAVA的EMMA

 


  Z:我认为产品质量提升主要在性能测试

 

我直接忽略了这个话题,第一关他的注点不一样,第二今天扯淡时间太长了,该结束话题了。

 

一直在思考的俩个问题是:a 如何跟测试小白介绍测试; b 如何跟专业的同行探讨测试。其实这两种还好说,一个用大白话聊,一个用专业术语聊。但最要命的是,懂一点点的还装X小白...

 

咳咳咳..扯远了,回到这个话题,最开始第一反应是想反驳,真的,测试职业病,质疑导致习惯性反驳(现在方式比较柔和),这个见解本身不存在什么问题,给个前提就行了:

 

a.需求一定时间稳定

 

b.需求均已实现

 

c.业务功能不存在BUG

 

鉴于以上几点确实只有从性能、安全、代码等其他测试维度去发现问题提高质量

 


  思考:业务测试与通用技能学习的重要性

 

测试主要依赖于公司相关业务开展测试,因此本职工作就是做好业务相关联的测试工作,也许通常一般大约,加薪、考核70%是业务相关(业务熟悉度、有效缺陷、漏测等),还剩30%是技能提升之类的(开发语言、性能、安全、分享)。

 

然后30%决定你以后能走多远、多高。所以这里一直存在的一个矛盾点就是: 如何平衡业务测试时间与学习通用技能?

 

先别急着回答,比如业务测试过程中也可以学习通用技能?同学好天真哦...听我扯淡:

 

拼命型公司:如创业型公司,变幻莫测的需求,无比繁重的测试工作量,加上"牛逼的"快速迭代(or敏捷开发),ALL time全部耗在业务相关工作,比如:

 

理需求-->写计划-->写用例-->评用例(沟通)-->部环境-->提BUG-->修用例-->验BUG-->验BUG...-->新需求(再来一遍)

理需求—>写计划-->写用例-->需求变更(再来一遍)...-->评用例(沟通)-->部环境-->提BUG-->修用例-->验BUG...-->新需求(再来一遍)

 

... 

 

养老型公司:朝九晚五的,时间充足。一天开3、5个会,duang一天过了;写几个会议纪要,duang,1、2个小时过去了;搞几个业务分享,duang时间又没了。

 

所以时间不在开会,就在开会的路上。当然这类公司一般会组织有一些技能分享应付KPI,但比较浅,重复度很高且以介绍工具使用为主(不信数一数,80%)。

 

鉴于以上不靠谱的总结,咱在回想一个问题:责任心很强的你,是不是总是很迷茫,天天忙、但面试时感觉什么也不会?

 

对的,面试面的是通用技能,项目熟悉程度,不是你提交的BUG数与编写的用例数。

 


因此:如果你想有所成长,那么你一定要“不务正业”,抽时间学习、实践。