一次面评引发的思考

记得之前我参加团队模拟面评的时候，面试官问我：你认为测试开发工程师（业务保障方向）最核心的能力是什么？由于我一直都没有思考过这个问题，卡了10秒钟没有回答，结果面试官说，既然没思考过，就不用回答了。尴尬。。。

其实当时脑海里出现了很多关键词，比如：发现bug的能力、风险把控能力、快速理解业务的能力，开发测试工具的能力等等，很多的关键字,但是我不知道说哪一个，确实是临时思考的。后来我才知道这其实是一个开放性的题目，无论我回答什么，面试官都会一直追问下去。我下来思考了很久，如果说一定要说出一个核心能力，我认为这个核心能力应该是： 度量质量的能力

什么是质量度量

我认为度量质量是一种能力，对不同的产品，产品的不同时期，度量的标准都有可能不一样，但是可以确定的是，度量的标准肯定是一个具体的值，是以数据为驱动的，不是主观的看法，比如说：我觉得这个版本质量不错，我觉得上线风险不大。度量的标准可以是代码覆盖率、版本bug率、接口覆盖率等等。

互联网软件，无论是浏览器/服务器(B/S)架构，还是客户端app/服务端(C/S)架构，都离不开软件测试过程，至少在短时间内，测试工程师的职位还是有存在的必然性。对于测试工程师，保障业务的质量是最基本的要求，也是从业的根基。主动去识别业务当前的质量风险，善于利用当前的技术栈打造符合当前需求的解决方案。

既然要保障业务的质量，那么如果都无法得知业务当前的质量情况，谈何保障呢？因此，测试同学需要对业务的质量保持高度的敏感性，重点关注以下几个方面：

1、版本bug情况

如果我问你最近这个版本有多少个bug，也许你会很快回答出来，但是，如果我问你这些bug中有多少是严重的bug，多少只是UI显示的bug，你可能一分钟后可以回答我。那如果我问你最近这个月研发产生的bug都集中在什么地方，是逻辑上的bug较多，还是只是UI显示的bug比较多呢？最近半年呢？你能评判最近半年研发的代码质量是变好了还是变差了吗？

我们为什么需要知道这些数据呢？因为我们测试不仅仅只是给研发兜底呢，我们应该去发现存在的问题，思考应该从哪些方向去改善整个研测流程，比如说我们发现研发出现比较多的逻辑性bug，那么我们需要狠抓一下单元测试，无论是研发自己写单测还是QA来写，覆盖尽量多的核心逻辑，那么逻辑性的bug在提测后就会相应减少。如果我们发现UI类型的bug比较多，那么可以让产品同学多介入，研发多自测。

2、最近线上问题情况

这里的线上问题包括需要紧急修复的hotfix和不需要紧急修复的问题，我们需要记录这些问题并归类。既然已经将问题漏到线上去了，那么可以肯定的是我们的研测流程存在问题，在后面的工作中尽量避免再次犯错，可以指定相应的措施或规范。

3、最近线上故障数量

任何系统都可能发生故障，比如出现：

• 严重的慢查询，系统响应时间飙升，无法响应用户
• 第三方接口挂了，直接影响我们的正常接口
• 缓存命中率骤降，数据库压力增加，系统响应变慢
• 推流失败率突然升高，观众侧播放成功率骤降
• 出现full gc，访问业务主页转圈圈

每一次故障我们都要去复盘，目前的系统究竟还存在哪些短板，还有哪些有风险的地方。

4、单元、接口、UI自动化用例覆盖情况

自动化测试，是我们测试开发必须要掌握的技能。做互联网测试，在我看来，都离不开单元-接口-UI的这个测试金字塔。提高回归效率，减少bug出现是测试金字塔的目标，对不同的技术栈、不同的业务特点和阶段偏重不同的测试才能发挥测试的最大作用。

另外需要特别强调的是，自动化测试并不是做得越多越好，要考虑合理的投入产出。

5、当前线上覆盖了多少核心指标监控

一个故障，你能在多长时间发现它，用多长时间可以让业务恢复正常？除了一套很好的故障响应机制或值班制度，更重要的是我们做了多少监控，覆盖到了多少关键指标。从基础设施层、组件层、应用层、业务层、到用户层，层层的监控才能让我们在出现问题时较快得定位到问题的原因，从而恢复故障。

以上便是我对测试开发（业务保障方向）工程师核心能力的思考——质量度量，其实这里不仅包含了专业能力，还包含了流程管理、制度管理等相关的内容，这是一个综合能力，这也是与传统的业务测试工程师和纯研发测试开发工程师有所区别的地方吧。