• 我在百度5年的QA生涯
  • 发布于 2个月前
  • 212 热度
    0 评论
  • 怅忘归
  • 0 粉丝 26 篇博客
  •   
最近各种原因换了个工作,回想起来校招(实习)就进百度了,一晃5年多了。最近又宣传“十四五”,也想着自己确实得好好总结下这五年,而且市面上做 QA 的比较少,希望能对新同学有些帮助。

重新review下工作
做程序员这一块,可能都会遇到第一个瓶颈,工作前2两年成长很快(特别是 QA,都是现学),但后面就慢了,感觉重复着之前的工作。这里以“捕鼠器案例”为引子(杨震原字节内部分享,来源王梦秋百度的内部分享),重新捋一下 QA 的工作:

工作第1年
刚工作接到的任务一般比较简单、直接,比如导师可能叫你去放一下捕鼠器。这个时候你一般看看文档,多观察下,就知道捕鼠器是用来捕老鼠的,你只要不给它挂在墙上就行。甚至前人已经放过捕鼠器了,你只要依样画葫芦隔一段距离放一下就行了。

这个时候你就要稍微总结下了,放捕鼠器为什么有时没捕到老鼠,你可以会观察录像,看别人的捕鼠器怎么做的,这个时候稍作改进就会效果明显。具体的到QA的工作,你现在已经非常熟悉这块的业务,每次小功能的测试都游刃有余,而且通过学习你还会了 API/UI 自动化测试,效率也变高了。

工作第2年
由于表现还不错,你已经晋升为 T4 了。这个时候你会发现只放好老鼠夹子效果还是不好,具体到工作可能会发现线上还是有很多问题。你一想,捕鼠器是干啥,消灭老鼠,但消灭老鼠,不仅仅只有捕鼠器一种方法,或者说一种方法不够。当一个人从完成任务到解决问题,能够再问一步,这个问题关联的问题是什么,进而去提出新的问题,这就是关键的突破点。

你可能会发现老鼠药更管用。类比测试工作上来说,你引入了更多的测试方法:diff 测试、性能测试、稳定性测试、兼容性测试、安全测试、ET测试等,工作开始变的顺风顺水。

工作第3-5年
这个时候你测试环节已经做的很不错了,能负责一个系统或者业务方向的测试了,一般的话也晋升为 T5(高级测试工程师)之列了。但这个时候就开始重复之前的工作了,项目不停迭代、新功能测也测不完。而且随着需求积累,回归测试也很多了,因此对于 QA 来说这种重复的感觉比 RD、FE 更强烈。

这个时候还得回到原点来,捕老鼠是为了什么?为了保护粮食。那 QA 找 Bug 是为了什么?是为了“质量”。

这个时候介绍一个在百度内部非常重要的概念:全流程质量保障。作为 QA(Quality Assurance,质量保障),自己把自己定位成测试是不行的。

全流程质量保障
可能每个公司的项目流程都不一样,但都会包含以下几部分,当你跳出“测试”来看,就会发现能做的事情还有很多:

需求阶段
有些同学觉得需求不都是 PM、RD 的事情嘛,QA 能干啥。往小了说,参与需求评审能了解需求的来龙去脉,方便我们设计测试case。往大了说,有时候 Bug 多、上线 delay,是需求不靠谱,PM 可能只考虑自己这块的功能,实现起来需要复杂的周边改造配合,不必要的提高了整体复杂度,这时可以建议 PM,换个思路来满足用户的需求。

开发阶段
大量工程经验告诉我们,Bug 发现的越早,修复成本越低。我们不光要督促 RD 做好单测,还得深入参与方案设计评审、code review,提供完善的自测 case 帮助 RD 自测,总的来说就是尽早的发现问题。

测试阶段
此时才到具体的测试,除了做好测试本身外。我们更多的可以关注到 CI(持续集成)来,比如我们的自动化 case,可以在 RD change 代码阶段就运行一些核心 case,拦截低级问题,合入后运行完整的测试 case。并不断的提高测试覆盖率(case 运行完后覆盖了 RD 代码多少分支)。还可以性能测试例行化,发现版本间性能变化。最终能做到只要流水线通过,就能有底气让 RD 直接上线。

发布阶段
发布肯定也不只是 RD、OP 的事情,别的不说,上线后的验证 case,就需要 QA 提供完善。发布流程上也有很多提升质量的方式,比如灰度、A/B测试、众测、单节点/单机房小流量等,还有完善的回滚机制。这样问题即使出现也能控制影响范围。

线上稳定性
前面都做的很好,但线上问题(可能不是直接的 Bug)多,这更直接影响用户体验,更体现质量差,所以线上稳定性 QA 也需要重点关注。

发现问题要快,相关业务拨测、日志监控是否完善?一般公司都有相关平台,没有的话需要推进建设。
定位问题要快,比如相关日志 logid 是否能够串接起来,日志信息打印是否规范?不求找出确切问题,但需要知道大体原因,方便执行下一步策略。

兜底策略时候完善,线上问题往往来势汹涌,还来不及查问题就已经挂了。这个时候如果近期有代码变更,回滚策略是否完善(线上问题止损第一位)。上下游重试/熔断机制是否合理?机房切流是否有预案?


数据说话
研发质量、效率,产品效果有时候比较主观,虽然不支持唯分数(KPI)论,但基本的数据分析和度量还是要有的。比如功能埋点数据如何上报,如何保障用户隐私,如何测试埋点数据能满足 PM 的需求。研发质量如何度量?比如可以分析发现 Bug 的类型,是否可以针对性改进,发现 Bug 的阶段是否靠后导致 RD 修复风险大,提测打回率,漏测率等等。线上运行情况如何,比如可以建立 SLA 体系,及时或者定时报告质量情况。还可以结合日志平台,收集各个模块调用数据,能全盘看见整个微服务的情况。方方面面还有很多,更广的就涉及到了BI(Business Intelligence)、EE(Efficiency Engineering)的范畴了。

测试技术
本文没有详细阐述某个技术具体怎么做的,比如百度 QA 自动化测试怎么做的,因为 QA 发展了那么多年,特别是在 BAT 这种大厂,自动化测试各类的技术已不是高阶 QA 主要能力瓶颈和测试技术短板。更看重产品的全生命周期的质量保障,从尽早发现问题,到缺陷预防,到减少发布后遗漏问题的影响都是 QA 投入的重点,也是在百度(任何公司)不可或缺的核心价值。

整个流程粗略一看能提升质量的地方就很多,干好其中几项自然就升到 T6 了。这里一定要注意不要为了晋升而做事情,晋升应该是水到渠成的。

小结
可以看出,不管是风险左移,还是保障右移,都需要 QA 自生有不弱于 RD 的能力,不是做不了开发才来做测试,仅仅是社会主义分工不同。还有就是经济基础决定上层建筑,就像一个国家搞原子弹、搞航母一样,并不是一朝一夕能行的,也不是每个国家都需要航空母舰(外蒙古就不需要)。所以还需要因地制宜,适合自己项目组的才是最好的。但你有想造航母的目标,那么可能还是得去大公司,才能实现 QA 的价值。

到了这时,其实我们可以再想想一开始的问题,保障质量最终又是为了什么呢?所以说再往上,你可以跟更高的目标去对齐,你的能力,你发挥的作用也会更大。首先需要了解目标是什么,评估方法是什么,怎样去改进,走成一个正循环。


机遇和努力
当前互联网环境还是偏浮躁,很多新同学会问,机遇和努力哪个更重要呢?答案肯定是机遇更重要,但机遇是可遇而不可求的,因此我们只能更加努力。保持一颗平常心,吃饭时好好吃饭,睡觉时好好睡觉(毕竟现在想着年前为什么不把基金卖了也没啥用),先把当前的事情做好,仰望星空,脚踏实地,有助于我们克服“内卷”的焦虑。
用户评论