作为一名多年的测试人员，对测试这个岗位的存在，也有自己的一点拙见。纵观现在的互联网公司，不管是国际巨头，行业巨头，或初创型公司，测试的岗位都必不可少。但不同的公司之间，却又有很多的差异性，拿测试开发比来说：在 Google 公司，测试开发比为 1:10；但微软则能达到 1:1 甚至更高；笔者现在所在的公司，大概是到 1:3 左右。
其实每个公司的配比，都是视本公司的业务形态/协作方式决定的，单纯靠配比来决定什么，也是不科学的。微软的一些测试人员需要写单元测试，相当于测试开发的角色，写出来的东西去测试开发写出来的代码，加之微软产品性质比如复杂操作系统，服务器产品之类的，需要的测试人员自然多；而 Google 的开发人员的习惯是，开发自己承担自己的单元测试和功能测试，众所周知谷歌的工程师开发水平又很高，所以公司专职测试人员就很少。
不同的公司之间配比差异这么大，那大家是怎么保证测试结果的呢。如果只有一个测试人员的公司，应该怎么做到最大价值呢？测试人员承担的是什么角色，如果只是“保姆”的角色，那测试行业会不会消失？
这就引申出一个话题：测试效率，今天我们谈谈。
在我看来，测试效率大概分成四个部分：
1.测试执行的速度；
2.测试验证的准确性；
3.测试覆盖场景的比例；
4.转换成工程价值的比例。
前三条从字面意思都很好理解，第四项怎么理解呢？我认为这是个综合的考量，也就是测试价值的衡量：减少迭代的bug数目，减少线上事故数，质量保障过程可控，就是在转换成工程价值。
现在很多公司的测试部门都不称为「测试部」了，而是称之为「效率部」，这也是有原因的。「测试」听起来是一个阶段性的工作，就像流水线的某个车间；而「效率」听起来更像是一个全流程的把控。笔者觉得这也算是为测试争取“地位”的一个很显著的表现。
试想，如果整个公司只有你一位测试，你会怎么做？最大提升效率？我想首先你应该熟知业务形态，清楚产品的风险点所在，对可能发生事故和问题的模块足够清晰。一个完整的产品，一定有最基本的底层/前端/后端，我们说“从根源上把控质量”，这话一点不假。我刚开始做质量工作的时候，都是浮于一些功能模块，或者一些端的功能，或者交互的功能；现在再拿到手一个产品，我基本不会这样了，而是看它的服务都有哪些，接口有哪些，调用关系如何，日志怎么看，前后端怎么对接。你要清楚，产品之所以能 run，都是底层服务/接口互相调用的结果。所以，我们应该把测试工作“下沉”，下沉到我们可以管控的地方，优先在这里做测试工作包括自动化的东西。这也是在自动化领域，我一直主张优先做底层接口测试的原因。当然，前端的一些控件/界面测试除外，其它的，能下沉就下沉，你会比你想象的学习到更多。
方向对了，测试效率也已经领先了一大步，自己也会省事很多。那接下来就是怎么优化这个测试工作。拿 API 测试来说，写一个 API case 并不难，比如常见的 Python 的 requests 库，花两分钟你就能知道如何写请求，如何 assert response 了。但如何系统组织这些用例，比如对于复杂请求，怎么写成请求链路，怎么解析多层次的 json；对于一些变量，需要跟数据库交互的时候，应该怎么存；如何做成自动化测试的 CICD，却是需要一定功底的。复杂的 API 请求，一般涉及到复杂的 case 编写，比如之前笔者做人工智能的相关接口返回值的提取时，用的都是 mongoDB，因为那里面很多非结构化的数据，我需要先存，然后在下一个 API 的时候，再用这些数据。
还有一个直观提升测试效率的方法，就是最大化增加测试覆盖。说白了就是最大化你的用例“波及”范围。这也是作为一名测试工程师的基本素养和技能。我们所熟知的边界值法/等价类划分/分支覆盖法/条件覆盖法等用例编写方法，是最基本也是用的最多的，一定要掌握好，对自己的测试工作负责。“漏测”我以前是一直不认同的，因为我认为 bug 都是开发写出来的，而不是测出来的。但现在，我们团队中的一些新手，很多时候考虑并不全面，导致“漏测”，引发了一些线上事故。测试工程师，首先就应该有扎实的基本功，别人才能信任你去把控质量。这点也是笔者对一些测试新手想说的吧。
测试工作千千万万，其实真正的效率问题才是部门内部最应该思考的。不止测试，开发/运维都有效率可言，这也催生了我们的各种自动化，自动化测试，自动化运维，自动化部署，以及像 DevOps 这样的岗位的产生。测试这个工作永远都不会消失，但在互联网更发达的将来，测试这个岗位却有可能被合并。所以，作为测试人员，掌握良好的技术能力也是必须的，包括编码能力以及必要的测试大局观。最后，也祝愿大家都能一步步提升！
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
