软件测试很简单么？

| 2022-04-14

有个不是很好笑的笑话，说的是某某公司扫地的大妈都可以做软件测试，某某公司看门的大爷都可以做软件测试。导致现在还有很多人对测试的认知都停留在这个层面上。想当初，个人也靠着惠普的三大件（估计很多人都不知道，LR、QTP、QC），混了份不错的工作。伴随着对测试工作的不断深入（在这个行业混迹了 10 多年），越发感觉自己不懂的越来越多，测试，真的不简单。

1 外人眼中的测试

主要有两类观点，1 种是测试不就是点点么，没什么技术含量。还有 1 种是测试为什么要懂代码？如果代码能力很好，为什么不去做开发，还“赖”在测试圈？

先说说第一种：测试初期，确实大部分的工作都是在测试执行中度过的，这个时候点点点是我们工作的大部分内容。但是再往后呢，为什么要这么点，哪些可以点，哪些可以不点？有些人思考了，有些人没有，于是就产生了分层，测试思维的差距就出来了。然后有人会去想，为什么要手动点？多累啊，能不能自动点？能不能快速点？自动化就自然而然的出现了，然后带来更多地思考，带来更多的专项，也给测试带来了更多的可能。所以，作为测试人，不要看轻自己，外行人的评价并不能说明什么。很多人还觉得造车简单呢，不就一个发动机+4 个轮子的事么。

再说说第二点：测试人员的代码能力强了，就一定要转开发么？本人菜炒得还不错，那我就要放弃测试去做厨师么？测试多个能力伴身不香么？开发也不见得比测试好混啊。从薪资上来说，同等能力的测试不会比开发差太多。如果你用中等开发能力的人，来和基础测试的人做对比，那你不是在比较，是在耍流氓。

2 入门级的小陈

小陈作为刚入行的测试新人，每天除了执行老员工给的测试用例外，还会主动地去以下几件事，来帮助自己成长：

写测试用例：先看别人写的用例，然后通过自己的思考，也尝试去写测试用例，从用户的角度，从可用性的角度，从体验的角度去补充和完善更多的用例，同时培养独立思考的能力，慢慢培养自己测试思维。

记录 BUG：认真记录自己发现的 BUG，尽可能地去还原步骤，探查原因，多问问开发为什么会这样，是什么原因引起的。同时多看看同事记录的 BUG，想想他们是通过什么路径发现的这些 BUG。

做测试总结：定期做测试总结，看看自己学到了些什么新技能，还是对业务有了更深的了解，画画业务流程图、数据流向图、系统架构图等等。

学习测试技术：多混论坛，看看别人在玩什么，看看又出了哪些工具。哪些能帮助到自己。反正还年轻，最不缺的就是时间，折腾呗。得益于国内的各种破解氛围，基本上都主流的软件都能下，一步步跟着别人学习，并在自己测试的系统上去尝试，去验证，公司的项目就是好就地试验对象。

看看代码：有机会，就去看看开发写的代码，看不懂也没什么关系，多看，多问。现在系统性地学习某种开发语言的视频和博客不要太多。

就这样，小陈慢慢地变成了陈工。

3 不断升级的陈工

经过几年的磨练，小陈逐渐变成别人眼中的陈工，有自己的测试思维，能够更准确的定位 BUG 根因，和开发逐步变成了朋友。于是，小陈，哦，是陈工，又开始思考了。

测试充分性：测试的时间总是被压缩，延期是不可能延期的，怎么办呢？有没有什么更好的测试策略，可以用更少的用例，覆盖更多的场景？能不能在测试前期做更多的准备，以便在测试执行的过程中能够更顺利些。

测试有效性：当下团队写的测试用例是否全是有效的呢？如何给臃肿的回归测试用例瘦身呢？没有发现 BUG 的用例，是无效用例？那些需要很复杂的步骤才能复现 BUG 是否是优质 BUG？测试是否覆盖全了呢？哪些没有测试到，依据是什么？

关于 BUG：都到测试阶段了，BUG 的修复成本太高，能不能早点发现 BUG 呢？经过这么长时间的测试积累了，BUG 一般会聚集在哪些功能点上？能不能提供一些典型的 BUG 给到开发，让他们多注意下，提升一下提测质量？BUG 的根因是什么，如何更好的避免这些 BUG 的出现？

关于自动化：测试金字塔提到的测试分层，应该如何落地到团队中去呢？每一层应该关注什么？重点测试什么？哪些可以让开发去执行验证。在什么场景下开展对应的自动化测试才是合理有效的？如何自动化产生真实的效益，而不是沦为 PPT 工程？

关于测试改进：当下团队的测试瓶颈点在哪里？如何去改善？业内有什么更流行的测试方法论或者测试技能，能够解决当下团队的问题？

（陈工想的这些问题，你都有答案么？）

4 眼界更高的老陈

人类一思考，上帝就会发笑。个人不思考，就无法进步，别用行动上的勤奋，来掩盖思维上的懒惰。“Hello word”你用不同的语言写了多少遍了？陈工通过自己的思考加上不断行动，逐步变成了对业务有一定认知的小高手。他的能力也不仅仅停留在测试的范围，他已经可以拉通好几个部门一起做事了，这叫“整合有限的资源，投入到无限的可能中去”。

质量内建：如果仅靠测试人员来保证产品质量，那一定会疲于奔命，发现 BUG 速度远跟不上写 BUG 的速度，有必要通过一定的手段来培养全员质量意识，让大家感知到质量不单单是测试人员的事，还是整个团队的事。质量需要端到端的去管理。

改进研发过程：有思想了，还要有工具，否则就是空想了。于是整个 DevOps 的研发过程就逐步去推进，需求实例化，代码分支管理、代码扫描、CICD、质量门禁、制品管理、生产监控等等一系列的内容，都需要老陈参与进去。

不断尝试新的技术：老陈穿梭于各种行业大会，观察更新更前沿的技术，看看哪些可以被团队吸收和落地，代码染色不错，可以帮助测试人员更好的确认被测试对象，测试覆盖率也可以，精准测试？混沌工程？契约测试？研发效能？。。。。。。

5 小结

老陈还在测试的道路上不断前进，各位看官，还觉得测试简单么，你们觉得老陈薪资几何？干一行爱一行。许多行业的入门要求都不高，但是要做得好，都不是简单的事。测试人员也不应当把自己局限在测试的职责范围内，不断扩充自己的边界，不好么？测试难不难，取决于你的自我要求，市场会给你真实的答案，没事多看看相关的招聘信息。

原文链接：https://mp.weixin.qq.com/s/SmApqbriZBsmo8HqXMvSDQ

本文文字及图片出自 InfoQ