● 从执行过程而言

　　首先从测试目前我们执行的测试是三轮测试。相对而言，在P1，P2，P3阶段会有针对性的对某个功能点进行重复测试。假设我们在项目中期开展自动化测试的话，尽早产出脚本，就可以在P2,P3阶段利用脚本，甚至是P1阶段就利用脚本去执行，这样就可以为功能测试人员节省更多的时间去做别的功能点的测试。其次，这部分的脚本在以后的回归测试中仍然可以代替功能测试的手工操作，并且随着执行测试的不断增多，所节约的跟手工测试时间会不断增加，这是自动化测试的根本优势。

　　● 从质量保证而言

　　我们知道自动化测试的高效性能保证用例，能够保证一个自动化用例在各个测试阶段执行的测试密度之外，也能确保非自动化执行用例的执行密度。因为在有限的时间里面，当功能测试的部分用例被自动化测试代替之后，功能测试人员有相对多的时间去执行那些没有被自动化测试所覆盖的用例上来，从而从整体上确保了整个项目用例的执行密度，近一步确保了项目的质量。

　　最后在项目中期实施自动化还可以用于进行测试环境的验证。作为测试人员比较头痛的的一个问题就是测试环境不稳定的，这意味着我们什么都做不了。同时一遍遍的验证环境，又浪费了我们本来就紧张的测试时间。但是如果在每次测试之前，能用一些主流程性的脚本跑一下，就可以知道当前的测试环境是否好的。尤其是进行部署之后的环境验证，能够节省功能测试人员的测试时间。

　　因此，有上面几点看，挑选合适的项目也能在项目中期开展自动化测试，并让自动化测试与手工测试结合确保项目的质量。

　　5、需要解决的问题

　　我们说在项目中期开展自动化测试是可行的，这个可行的是建立在如何降低脚本的编写和维护成本的基础上的。那应该从哪几个方面去解决这个问题？

　　● 首先是对业务需求的理解

　　对业务的理解和熟悉是自动化测试的前提，只有对业务知识足够的了解，才能划定出自动化测试的范围，自动化测试的计划，以及自动化测试的数据准备方法，和脚本设计的方法，从而保证脚本的质量。

　　● 其次是脚本编写框架的健全

　　对业务熟悉之后，下面就是编写脚本的具体技术问题了。

　　我们知道自动化测试尤其是页面自动话测试对页面的依赖是比较大的。降低脚本的维护成本除了挑选好的也就是适合自动化的项目之外，更应该从脚本的编写技术上降低脚本对页面的依赖。利用目前的简单的通过页面元素的属性进行控件定位或者控件的dom结构进行操作显然是不行的，因为正是由于测试阶段某些需求的变化使得开发更改页面导致这些东西的变化从而影响了脚本，导致了脚本的维护成本高。因此，在编写脚本时，需要有一种灵活的方式，尽量降低简单的直接依赖页面控件的属性进行控件定位。例如可以将现在method的page思想和loutus的编写脚本方式进行结合。一方面通过loutus的方式利用页面控件的前导显示名称进行控件的定位，使得控件只要前导显示名称不变哪怕，属性变化了照样能找到对象，同时也通过page进行页面对象配置（通过：前导显示名称与控件属性值互补方式），一旦页面中的控件发生变化（前导显示名称和控件属性值发生变化），只需要修改page文件即可，而不需要对脚本中涉及到得控件一一做修改，从而确保了脚本维护成本的降低。

　　● 测试平台的建立

　　测试过程的自动化和测试结果分析的自动化，将手工测试人员从中解脱出来。那这样一个目标的实现，除了有对业务的熟悉和脚本编写的健壮之外，还应该有一个完整的平台来支撑整个自动化测试，例如建立测试计划，驱动不同的机器在指定时间里面执行脚本；进行测试结果分析，给出测试结果统计；允许建立测试集合，进行批量的脚本执行等等。tWork平台就是扮演了这样一个角色。

　　6、在项目中实施自动化的效果

　　上文说了在项目中期开展自动化测试是可行的，那我们究竟客户以通过哪些方面对项目中期自动化效果进行衡量？

　　自动化测试永远不可能完全替代手工测试这是毫无疑问的，项目中我们发现当产品存在的问题越多，脚本跑起来越困难，也就是说要想跑脚本必须有个相对稳定的测试环境，那这个前期就需要通过手工测试人员进行测试，在前期手工测试人人员发现bug的概率就远远大于了自动化测试发现的bug，测试专家James Bach总结得85%的缺陷靠手工发现，而自动化测试只能发现15％的缺陷。换言之，新缺陷的发现应该是手工测试的主要目的。自动化测试的效果应该体现在它的高效性及准确性上。

　　举个例子，假设我们的脚本编写比较顺利，通过冒烟时，开发提供的测试页面，在冒烟阶段就能产出部份脚本的话（设编写脚本时间为Ta），就直接能在p1,p2,p3轮测试的时候用上，假设单词手功测试的时间为t，原计划每轮测试执行次数n1,n2,n3次，即原计划手工测试时间为：Tm=(n1+n2+n3)*t：

　　当Tm>=Ta的时候，我们可以认为项目中自动化测试效果良好，脚本编写的时间比值性时间短，同时在后续回归中的话这部分时间差距会更多。（条件1）

　　只有当Tm<Ta的时候，可以认为项目中不大适合自动化，但是这部分时间差会在后续的回归测试阶段被缩小，直到Tm>Ta。

　　另一方面，我们知道一个项目质量的好坏和测试阶段每个用例的执行密度有关，因此也可以通过计算项目中的每个用例的执行密度来衡量自动化效果的好坏。

　　举个例子：假设项目中一共有M个用例，每个用例的平均执行时间为t,总执行时间为T。

　　因此每个用例的执行测试为：T/Mt.

　　现在假设项目中加入自动化（满足条件1的情况：Tm>=Ta），自动化用例占N%，脚本编写时间为Ta，则计算手工测试部分的用例地测试密度：A= [(MN%)* (T/Mt)-Ta+ T/MtM(1-N%)]/ M(1-N%).由此可见A> (T/Mt.)

　　所以在项目中介入自动化测试能从用例的执行密度上保证项目质量。