工欲善其事，必先利其器。好的框架对于自动化的开发以及维护事半功倍。如何选择适合的框架，对于自动化开发工程师显得格外重要。本文将简单从测试人员构成，测试在软件开发流程所处的阶段，以及维护成本几个角度，与大家分享下自己的思路。
软件测试人员构成
从本人待过的几家公司来看，不论大小公司，对于测试这个角色整体是认可的，但是对于自动化的投入成本不一而足。所以我们看到团队内部，测试主力主要在应付功能交付。写代码，甚至开发框架不是他们擅长的领域，甚至还有一些排斥。少部分人员有一些开发经验，喜欢钻研，能写出甚至不输开发的漂亮代码。因此，从用人之长的角度出发，会安排这些有代码能力的人来完成框架的选型，对开源框架拓展实现自家个性化需求并抽象出公有方法，让没有代码能力的人来辅助增加自动化用例。选取的测试框架，基本上只需要有简单代码基础的框架就能快速完成一个用例。但是测试人员真的需要写代码么？
测试在软件开发流程所处的阶段
接着上面的问题。从对测试人员招聘的简历看，其实我们需要测试人员熟悉接口测试，会设计测试用例，高效覆盖用户使用场景，有代码经验只是加分项。他们做的工作也是在需求评审后，设计测试用例，在后端接口提测后，进行接口测试，以及在整体功能提测后，手工完成既定的测试用例。现在我们要平白无故多加一个自动化用例编写，在当下这个减员增效大环境下，无疑于雪上加霜。我们其实都了解自动化测试对于回归好处，这个是一个长远利益，但是在优先级上，永远不会是最高优先级。因此实际情况下，补充自动化用例就是牺牲品，技术债会越积越多。
此外，测试处于承接用户和开发的角色，我们要白盒了解开发是如何实现功能，以此为基础找到可能存在的缺陷。还要站在用户角度出发，从用户操作体验和场景来验证功能是否完善。因而我们的产物也应该是带有这两方面属性。如果是纯代码，不能很好的让产品了解我们测试了哪些地方，如果是纯用例也不能自动化运行。
维护成本
维护成本是一个通用问题，对于开发选型也是一样。我们在实现自己的业务需求基础上尽量选用社区活跃，用户基数大的框架。尽量不要从无到有发明一个新框架。因为可能在后面面临无人接手的问题。对于测试框架选型人员尤为重要的是，我们要时刻提醒自己，我们的使用者是业务繁重，没有多余精力来完成代码编写，再简单的代码也面临维护成本几何级别增长问题。
综上所述，一个理想的自动化框架需要结合当下测试人员的工作，在开发流程后不增加技术债并且易于维护。最后祝大家都能找到适合的理想型。
