什么样的自动化测试框架才算是好框架呢？个人根据多年的工作经验认为，一个好的自动化测试框架是和团队成员的能力相匹配，不是很难也不是太容易；是充分和开发建立协议和互信的，确保变化对测试的影响最小化；是充分融入现有工作流程，而不是独立出来自成体系；是高度封装，减少冗余无效工作，易于学习和 理解，可维护的框架体系；是能够交付使用测试体系。
1.和团队成员的能力相匹配
自动化测试能否在团队中推广使用，一个很重要的因素就是框架本身是否和团队人员能力匹配。如录制回放的自动化测试工具，在一个有一定技术能力的团队推广注定失败，因为他对大部分人员的能力提升没有帮助，团队成员在使用推广时必然会在内心对框架持反对态度。
在一个纯业务团队，推广编写难度较大的自动化测试脚本，注定也会失败，虽然技术对团队成员有一定吸引力，但如果在很短的时间不能提高，必然会使得积极性受到打击，进而认为自己不适合完成此项工作。
十多年前在某四大银行做自动化框架开发和自动化测试实施，基于QTP工具做的一套完整自动化测试解决方案，整个方案行业内都是比较领先的技术，但在实施推广时就遇到一个巨大的难题，年龄大的业务骨干，觉得录制完成，还需要学习各种脚本增强的技术，对他们来说是个挑战，不愿意学习，认为这个是年轻同志应该干的事情；但对于刚进入行方的年轻人，觉得录制回放就是给那些没有技术背景的老同志准备的，对于年轻人来说太简单了，没有“含金量”。
通过调研发现，老同志精通各种业务知识，喜欢用EXCEL做业务；新同学技术背景过硬，但业务知识欠缺。 根据特点，进一步完善测试框架，新同学通过掌握的技术知识对自动化测试中的测试对象进行封装和抽象，形成业务关键字，然后将这些业务关键字导入到EXCEL中，老同志通过熟悉业务的能力，像操作业务系统一样在EXCEL通过业务关键字组装业务场景和业务数据。这样改造后使得每个人都皆大欢喜，最终项目得以顺利实施并获得成功。
2.与开发团队形成默契，提高可测试性可维护形
在自动化测试的实施过程中，不论任何形式的自动化测试，都需要和开发团队形成默契，制定合理的合作规范协议和流程机制。提高软件的可测试性和可维护性。在软件质量属性中，软件的可测试性和可维护性是开发的内建质量范畴，所以说如果没有开发很好的配合，任何形式的自动化实施必将失败。比如在UI自动化测试中，自动化实施比较难的一个主要原因是UI界面变化频繁。界面频繁变化，给测试脚本的维护带来巨大的工作量。如果能够通过一种手段保证UI界面发生变化时，对自动化脚本的影响最小，那么自动化测试的成本会大大下降。
2013年在实施飞信的UI自动化测试之初，就和开发同学达成如下约定：
1）每个元素必须有ID和Name，ID和Name必须按照规范进行命名。
2）每一个对象和元素都必须按照约定格式编写。
3）每一个编译合格安装包，都能够自动化生成约定业务对象库，并能够自动校验对象变化对脚本的影响。
通过上面的约定，可以做到UI界面变化时，快速生成新的对象库，并且能够在第一时间确认UI的变化对测试脚本的影响范围，并快速维护。
3.融合现有工作流程
任何一个新工具或者新技术的引入都应该快速的融入到现有的工作流程中，而不是另外开辟一个新流程。因为只有这样才能够达到成本最低化，利益最大化，对原有工作的影响最小化。所以我一直非常反对为自动化测试重新制定一套新流程。这样做的结果往往是自动化测试和业务测试各自成体系，不能够实现联动，而使得重复工作巨大，效益低下；同时在测试内部也不能有效形成合力，不利于提升团队整体能力，甚至导致小团队对立。
个人比较推崇在每个测试团队都要配备一个类似于Master的角色，一个目的是指导业务测试人员学习和使用推广自动化测试技术，实现快速在团队内部推广和使用，提高整体效率；另外通过Master角色带领和引导团队成员学习新技术、新工具，进而提升整个团队的技术能力，形成良好的学习和工作氛围。
4.设计合理的自动化测试框架
好的自动化测试框架必须是高度封装和抽象，减少冗余无效工作，易于学习和 理解，可维护的框架体系。如何构建和设计一个自动化测试框架涉及信息较多，改天拟文论述，故不再赘述。
5.高质量的交付运营
在很多团队实施自动化都是按照项目的方式进行，这恰恰是大部分自动化测试项目实施失败的一个原因。作为项目来运作，就意味着有固定的开始和结束，当项目结束时，就是自动化测试项目实施失败之时。如果能按照产品运营的方式运营自动化测试，那么将会大大提升 自动化测试实施的成功率。关于如何运营自动化测试，后面专门写文论述。
啰里啰嗦说了这么多，不一定对，只是个人工作经验的总结而已，欢迎大家多多交流，多提指导，多提意见。
