企业对接口测试的需求

最近几年我们可以从招聘的角度看到企业对测试人员要求越来也将接口同功能测试一样作为一项最基本的招聘要求了。以下是摘录一些网站的招聘要求：

基本每个企业在测试人员招聘上，接口测试已经成为继功能测试的第二个必须具备的能力。其实从软件技术的发展也很容易看出这点。现有国内的软件技术架构变化相对几年前发生了较大的变化，比如微服务、分布式、小程序、APP 等发展企业开展测试发现导致以下几个问题：

1. 接口量越来越大，业务逻辑接口越来越多，单接口越来越少,导致基于业务场景的接口测试迫切
2. 前端框架越来约丰富，UI 元素越来越多，导致 UI 开展和维护相对接口要难的多
3. 微服务等框架开发，很多开发逐渐已经抛弃单元测试，而接口是最为接近后端服务的测试类型之一。 基于上述，综合测试人员投入成本和测试收益，接口测试逐步相对其他测试项最具性价比。这也最终导致了测试金字塔逐步向测试菱形模式进行变化。

企业在接口测试方面的选择

很多企业其实开始了接口测试的实践和落地，在这一过程中采用的方式也不太一样：
第一种：测试人员较少或者以独立项目维度的测试，很多的时候采用工具进行，比如 JMeter 或者 PostMan 等；
第二种：基于 Pytest 框架进行，这类往往效率更快，但是在对人员上有着一定的要求后期的用例维护也相对较为麻烦；
第三种：采用开源的接口测试平台进行，比如 MeterSphere，此类需要有带头的人进行推广，毕竟开源平台的落地需要一个培育期（“时间成本”）；
第四种：直接外采接口测试商业平台（MeterSphere 也有商业版本），此类相对效果较好，能够提供培训和最佳实践指导等，但是需要付出相应的 “金钱成本”，这个需要看企业是否有这方面的预算。
第五种：企业投入人力自研，自研平台在使用习惯或者需求上更能和企业贴合，但是需要投入相应开发人员的大量的时间和精力，并且自研后推广和使用、改进也是一个难点。当然自研接口测试平台是能够产生较大的收益，但是如果只是为了 “KPI” 或者 “个人炫技” 类，这个效果就不太好下结论了。

测试人员应如何应对

作为测试人员，我们应该思考我们应该具备什么样的能力而能在现在的这种大环境下而不被 “边缘化”。无论企业现在处于哪一种的落地阶段，我们也能够很好的满足和应对。简单的来说，作为测试人员我们应该注重那些方面能力才能更好的得到企业的关注。
先举一个简单的例子，如果你作为一个测试管理者，现有两名测试人员进行面试，一名测试人员精通 PostMan 的使用，一名精通某一接口测试平台的使用，并在上家企业进行了推广和落地。你会如何选择？其实答案显而易见，都会选择第二个，因为平台给企业带来的是独立于人员的可持续性。这个就是工具和平台的区别，尤其在管理运营方式上，工具和平台有着本质的区别，工具遵从功能实现的角度出发，不太注重企业管理上的能力，工具的使用规范、标准等依赖个人用户和企业明文的一些规章制度进行约束。而平台型，除了功能的实现同时，也注重人员权限的管理、流程的规范上的考虑。比如大部分的平台型产品都会包含的 “基于角色的访问控制” 管理模型（RBAC）。
所以作为一名测试人员，我们应该具备测试架构师的思维模式，不能永远局限某一单一测试熟练，而是能够在长远的角度进行规划和考量。个人建议从以下方面考虑接口测试方面的事情：

功能方面：需要思考现有的工具、框架或者平台是否能够满足我司现有的接口测试功能需求？
管理方面：如果采用了现有的方式进行接口测试，那么其他测试人员或者是否能够快速进行培训和使用，还有在接口量大下的管理问题？
发展方面：也就是可持续问题，当测试人员离职后，他创建的接口用例是否方便后续人员进行维护、升级、优化，以前的测试是否可以 “传承”？

最后

文章感想来源于笔者今年在上海疫情后的招聘测试讲解方案架构师面试了近 100 名测试人员只发现一个人满足我们的招聘要求（100 名测试人员中大概有 80% 的人员 “被离职”，可见大环境的恶劣），最后总结发现很多测试人员不具备测试架构思维导致，很多测试人员只关注了自己的本职工作，没有考虑被测试的业务系统架构、什么样的业务系统应该采用何种测试方式等等。

本文参与了「TesterHome 技术征文」，欢迎正在阅读的你也加入