QA的成长之路——深入测试的奇妙之旅

引言

功能测试的小伙伴，你们是否遇到过这些问题：

1、工作中重复性很高：尽管尽可能地让一个 case 覆盖更多场景，但仍有许多重复性 case，耗费大量时间，让人感到枯燥疲惫；

2、覆盖度不全：凭借需求文档写case，难以全面覆盖各种可能的情况，从而导致潜在的问题被遗漏；

3、技术提升缓慢：在技术评审时听着别人热火朝天的讨论，自己却无法发表有价值的意见，对代码也感到陌生，让人感到焦虑无助。

功能测试遇到了瓶颈，自动化测试的收益不确定，工具开发又有局限性。如何更快、更准、更稳的交付？未来的路，到底该怎么走……

来到采货侠后，我接触到了“深入测试”的概念——通过了解系统内部实现来进行测试，帮助我走出了困境。

心中疑问重重

通过大家的分享，我了解到深入测试有很多好处。

· 我们可以通过技术评审、代码走读能够提前发现问题，从而在提测前就把bug解决；

· 我们可以根据代码补充case，把需求文档上没有的异常场景都覆盖到；

· 我们更可以针对重复性场景去了解代码是如何实现的，从而精简case，提高测试效率。

但我心中仍有疑问：深入测试到底是什么？我该怎么去做呢？它真的有用吗？它的投入回报比又是如何？

此时内心：疑问重重~

深入测试前提–代码

在小师傅和团队的引导下，我开始执行深入测试，但很快遇到了难题：我的“代码能力”似乎跟不上深入测试的要求。我开始求助小师傅，首先他教会了我怎么去看代码……

1、覆盖率–定位位置：可以从覆盖率的角度去理解case，利用覆盖率工具去定位功能对应的代码位置；

2、debug–了解链路：去了解需求中一些主要的实现类，并通过debug的方式走遍代码链路；

3、diff代码–分析bug：尝试去分析bug，修复后的bug可以通过diff代码来了解问题的根源。

经过几个需求的练习，我对代码熟悉了很多，小师傅开始教我怎么去写代码……

4、数据构造–练习代码：通过几个数据构造的练习，我对代码的熟练度越来越高了。

通过不断的学习和实践，我的代码能力有了显著的提升。面对代码时也变得更加自信了。

此时内心：进步了，开心~

深入测试初体验

在经历了代码能力的提升之后，我迎来了深入测试的初次实践。

1、效率提升 - 精简case的体验：

首先，我针对重复性较高的case进行了精简。

例如：我需要根据品牌、成色等字段去和库表中字段匹配，看是否命中策略。

之前的case设计–重复性高：

查看代码，代码逻辑如下：

实现逻辑：根据不同逻辑分成三个组，每个组中的逻辑对于每个变量处理都是一样的。于是我也把case分成了三组，每组只验证一个，其他的变量只需检查一下参数是否写正确即可。十几条case变成了三条。

通过这样的精简，原本预计需要2小时验证的case，只需要30分钟就能完成了！

2、质量保证- 帮助补充case的体验：

深入测试不光可以精简case，还能帮助补充case，提高case覆盖度。

例如：我需要根据时间和价格区间取红包的值。

之前的case设计–只写了验证匹配规则是否正确：

但我在代码中发现：他对红包的值进行了正、负的判断。因为红包是一个三方提供的数据，如果红包为负数，有红包的优惠价会比没有红包时的价格更高。为了避免出现这种情况，代码中做了处理：红包值为负，就取原本的价格。

通过查看代码逻辑，我补充了关于红包值正、负判断的case：

通过这些实践，我逐渐认识到深入测试是可以帮助我们更快更稳进行测试的。

此时内心：深入测试效果初现，继续加油~

过程中的小插曲

在深入测试的实践过程中，我也走过偏路，那就是我过度重视case的覆盖度而在很多不重要的地方花费了大量精力。像抛异常后没有后续处理逻辑，仅记录error日志的代码，是不需要耗费大量精力去覆盖的。

像那些消息队列（MQ）的返回、幂等逻辑的处理，这些有逻辑处理的地方才是我们需要特别关注的。

同样，在深入测试的过程中，不能只关注代码实现而忽略业务逻辑。作为QA，业务能力是基本，深入测试是辅助，只关注代码而不关注业务逻辑，这样也会导致业务场景覆盖不全面。

此时内心：深入测试之路，任重而道远啊~

吸收、理解

每个需求都如此练习，我对深入测试有了更深的理解，并总结了自己的测试方法。

1、针对于改动小，回归范围大的需求。–可以通过diff代码来确定回归范围。例如：入参而底层逻辑没有变动，我就可以只验证入参是否获取正确即可，而无需进行全量回归测试。

2、匹配规则类、上传校验类的case。–他的特点是重复性高，可以根据代码实现看看有没有规律进行分类，每类验证一个，其余的只需验证参数是否正确。

3、异常场景想不到。–可以根据代码实现来补充场景。

慢慢地，某些功能在设计case时就会想到代码可能是怎么实现，设计case的时候，重复场景的case就可以缩减估时；哪些场景可能需要额外补充，都可以用做到心中有数。

此时内心：吸收理解，总结方法论，下次更轻松~

进阶

目前我已经掌握了深入测试入门技巧，我意识到需要给自己设立新的目标来进一步提升。

第一个目标，我希望可以像其他组员那样在提测前进行CR并发现问题。通过几个需求的积累，我现在也可以在提测前发现代码中的问题，让rd提前修复，节省了测试时间。

现在，我希望在技术评审时不再只是被动地参与其中，而是能够贡献出自己的见解。当然，业务方面的建议我是能够提出的，然而涉及到实现的合理性，就需要了解系统框架、了解代码位置才可以做到。想要达成目标，还需要更多的学习和提升。
此时内心：坚定信心，持续进步~

总结

回到最开始的疑问。

什么是深入测试？

是测试左移+灰盒测试概念的融合

测试左移，更早地发现问题和预防问题，降低问题的解决成本；

灰盒测试，基于代码实现精简和补充case， 精准定位问题，以便提升测试效率，提高覆盖度；

该怎么去做？

如何保持长期耐心呢？

首先我们要相信：深入测试一定是有帮助的。在开始的初期，要不断给自己设定目标，小进步带来成就感。如果遇到了困难要积极面对，与大家一起交流沟通，把困难当做成长的机会。

深入测试真的有用吗？

对工作：可以帮助我们更快、更准、更稳的交付。提前发现问题，精简用例，提高了测试用例覆盖度。

对个人：提升了代码能力和对系统实现的了解，突破了功能测试的瓶颈，测试更加有技巧性，更加深入。

投入回报比是怎样？

投入：学习代码的时间、看代码的时间

回报：一次投入，终身受益。对于实现方式差不多的case，可以利用之前的方式进行case精简，长期来看是节省时间的。

最后的结语

作为QA，具备扎实的业务能力是根本，但也需要了解代码和系统，结合系统实现去进行深入测试。刚开始可能会有些不适应，但慢慢地你会发现深入测试对我们有很大帮助，只是它需要长期持续的坚持。

成长是一个持续的过程，永远不要停止学习和进步的脚步。希望我的成长之路能给其他 QA 带来启发和鼓励。让我们一起努力，成为更优秀的测试工程师，为软件质量保驾护航。欢迎在评论区留言分享你的经验。

关于作者

郭荣、蔡京宁 采货侠测试工程师

> 转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。

> 关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~