自动化测试框架如何选型？

在技术交流群看到这样一个问题：应用开发语言是go和C++，做自动化测试用什么语言比较合适？有必要也用go来实现自动化测试吗？又是一个在技术领域被讨论了很久的话题，即框架选型和哪个语言更好。

其实无论选择哪种自动化测试框架，或者用哪门编程语言，都只是结果，在我看来并没有那么重要。重要的是想清楚为什么要做自动化测试，以及从工程实践的角度出发，考虑成本、投入产出比、上手难易程度以及扩展和兼容性。

自动化测试框架选型，首先要考虑团队当前的具体情况，即你当前所处团队是初创企业，还是小有规模或者知名大厂。团队在不同阶段的诉求和面临的痛点是不一样的，因此框架选型也要因地制宜。

初创企业的测试团队，一般具有这几个特征：技术规范和流程不完善，基础技术设施建设薄弱，团队规模较小，测试同学的技术能力相对更为薄弱。且软件产品处在一个快速迭代和扩展阶段，这个时候团队面临的最大痛点是快速迭代和质量以及效率之间的矛盾很难调和。

在这个阶段，如果要落地自动化测试，首先要解决的有无的问题，其次要考虑成本和投入产出比的问题。因此这个阶段自研测试平台或者基于开源框架二次开发，性价比就显得没那么高。更合理的做法是选择开箱即用且学习成本低的工具，能做到即插即用最好。比如jmeter/postman，能快速run起来就行，先解决有无，后续不断迭代和优化。

小有规模的测试团队，一般具备这几个特征：有一定的技术规范和流程，基础技术设施建设尚可，团队规模大约在10-30人之间，团队中部分测试同学具有一定的研发实现能力。在这个阶段，自动化测试的落地实践，除了考虑成本和投入产出比之外，还需要考虑扩展和兼容性。

当团队规模扩大且业务变得更加复杂时，随之而来的就是测试用例数量的急剧增加以及多人参与自动化测试建设的协作配合。在这个过程中较为常见的痛点有测试数据管理、测试用例集合、测试环境稳定性、测试用例执行效率、问题排查以及扩展和兼容性的问题。

在这个阶段，原有的开箱即用工具或者本地执行自动化测试的方式就显得格格不入，更为合理的做法是选择功能丰富、支持多语言、生态较好的开源工具或框架，在此基础上针对团队的具体需求进行一定的二次开发。比如metersphere，既有商业版本，也有开源免费的版本，其免费版本的功能，就足以支撑绝大多数中小型测试团队的自动化测试工作开展。

让大部分测试同学的精力集中于测试用例设计和业务功能验证方面，在保证需求吞吐量和质量的基础上，逐渐加大自动化测试的建设。

如果是知名大厂或者规模较大企业的测试团队，这个时候要面临的挑战，与其说是框架选型这种技术问题，其实更多的是考虑如何赋能和规范，降低边界摩擦和沟通成本。

大厂测试团队的优势在于，研发规范和流程很完善，基础技术设施建设比较好，技术同学整体水平较高。当团队规模大了之后，对管理者来说最大的难题就是重复建设和协作效率。重复建设需要更大的建设和维护成本，不同团队以及测试团队内部的多人协作效率，是比所谓的重复性工作更难的挑战。

因此在大厂，大家听到更多的是各种工具平台建设和所谓的最佳技术实践。所谓最佳技术实践，就是踩了很多坑走了很多技术弯路之后找到了最适合自己团队的方法，这个方法不一定是技术最新或者效率最高，但一定是平衡了成本、投入产出比、扩展兼容性以及协作效率的产物。当然，其中也包含一些OKR和KPI的非技术因素。

最后，回到文章开头提到的问题：做自动化测试用什么语言比较合适？有必要也用go来实现自动化测试吗？

如果你是自动化测试负责人，首要考虑的是自己的技术栈，即熟悉哪个用哪个，这样实现和落地技术难度较低。其次要考虑你的技术选型成本，是否有足够的时间和资源支撑你的技术方案落地，避免蒙头憋大招。再次要考虑上手难易程度，即其他测试同学的技术能力和学习能力是否可以更快上手有测试产出，否则很难落地和扩大覆盖范围。最后，则是一些非技术因素，即你的方案是否能得到领导认可，是否可以成为接下来的OKR，以及拿到更好的KPI。好的预期才能激励打工人更加努力搬砖，否则就会成为求上得中，求中的下的牺牲品。

当然，从更广范围来看，选型要考虑你当前所处团队规模和发展阶段，最好和研发的编程语言保持一致，最起码搞不定了还可以请开发帮助。

随着技术和各种工具平台越来越成熟，技术规范也越发趋于一致。如果是接口自动化测试，逻辑上来说只要研发的接口设计遵循规范，那用哪种语言其实没什么影响，毕竟大家都是CRUD和API调用工程师。