无论如何，我们得找出一个业务专家，暂且称之吧，在一起看看，哪些测试场景适应自动化，于是进行业务的抽像，封装设计提高脚本复用，从而降低维护成本。

　　1、我们的脚本开发好后，使用频率大于5-7次以上么？

　　2、基于不同的web 开发框架，对像的源头是否统一属性？

　　3、我们需要整合业务的公共用例？

　　所有的问题，引入了第三阶段。。。

　　三、认为管理很重要

　　提到技术与业务，想到自动化测试的真正目标，如果你已经上升到这个阶段，所谓思想与眼界较之前或更有开阔。与之相适应的自动化准入标准，脚本开发规范，自动化运作的工作系统流程，自动化测试的度量体系提上案头，不得不说，此时还得有个管理者坚定的支持，才是走到如何产生较好“自动化测试体系”。

　　不想再提，自动化是好还是坏，给出一个答案的人终究应噎废食，唯有积沙成塔，坚定信念给出在一定时间与背景情形下好的答案。曾经与微软自动化工程师聊过，当自动化成为习惯，大部分人会“麻木”接受。

　　因为我们可以让他看到，有多少开发check 多少行代码？ 有哪些代码经过测试？ 脚本自动化分发执行后多少用例是通过？ 以供决策，我们当前的项目计划是否合理，满足基线或里程碑的功能？终我们可以承诺给客户。。。

　　没有放之四海而皆准的，唯有合理与有效，工具又何尝不是？连到现在，也没有发现较大网站系统运行100次脚本，会有成功概率，现实与理想纵有差距。

　　庆幸自己在这不到三年内经过如此丰富的阶段！从而不在盲目，简单的东西往往决定如此深远，回头一眸，测试基础不做好，如同空中楼阁，一垮即踏。

　　写给想做自动化的人，也许给测试管理中想做好自动化管理的人也有借鉴。自动化测试，UI自动化，接口/api等等与测试相关的自动化，不能再当快餐享用。