1、自动化测试的定义
　　我们一直在说自动化测试，也一直在做自动化测试，那到底什么是自动化测试？以自动化的方式完成测试？测试过程的自动化？通过写脚本，以机器执行代替手工校验？理解方式很多，也都可以认为正确。从我们目前的工作去理解自动化测试其实两点：测试过程的自动化和测试结果分析的自动化，换言之，是通过写脚本语言，让机器代替手工执行，实现测试过程自动化并给出终的测试结果，校验通过或校验不通过。
　　2、自动化测试的优势
　 　通过自动化测试的定义我们可以发现，利用自动化测试可以起到高效，准确，客观的测试作用。首先，测试的高效性，手动测试的速度远不及机器执行的速度，在 单位时间内通过机器执行的用例数量远远大于手工执行的量，同时，由于机器的执行时间可以控制，所以我们可以通过制定测试计划来控制执行的时间，将人工从执 行测试用例里面解脱出来。其次，测试的准确性，由于机器执行的高效性，从而可以提高测试用例的边界覆盖度，从测试的广度上保证测试质量。测试的客观性，由 于整个执行的过程是由机器执行，包括测试结果的分析都是通过机器得到，在保证了测试脚本的正确性的前提基础上，整个测试执行过程都是依靠机器判断，不需要 依赖人为判断，保证了客观性。
　　对于用户而言，一个软件产品，用什么工具开发，用了什么测试方法测试都不重要，大家关心的只是软件质量。自动化测试的这些特性都是能够提高软件的质量。因此，目前越来越多的公司开始引入自动化测试。
　　3、自动化测试的普遍介入时间
　 　自动化测试介入时间有过很多的讨论，目前普遍认为，自动化应该在回归测试或者软件基本功能或者流程已经成型的条件下而且以后变动不大的情况下,可以 开始介入自动化测试了。其实，这个介入时间是从自动化测试成本的角度去考虑的。首先，毫无疑问，在回归测试阶段由于软件的基本功能已经稳定，页面结构也已 经不大会变化，这个时候，可以写脚本，跑脚本。由于变动不大，脚本后期也不会有多大更改，所以脚本的维护成本相对较低。但是在项目开发提交测试阶段介入自 动化测试，估计并不能得到大部分人的赞同。因为，开发提交测试阶段，软件的一些模块功能并不稳定，尤其是一些页面结构上变动会比较大，例如测试认为这个界 面从设计的不漂亮，提bug，然后开发同学这对测试提交的bug重新布局页面控件。这个时候，假设前期写好的脚本用于执行了，但是随着开发页面的更改，脚 本全部报废，需要修改从而提高了脚本编写与维护的成本。所以，很多人都认为在项目中期开展自动化测试并不是佳时机。
　　4、在项目中期开展自动化测试的可行性
　　很多人在项目中期开展自动化测试存在顾虑，主要原因在于脚本的维护成本比较高，而且在项目中测试时间比较紧张，所以在这期间开展自动化测试并不是佳选择。事实上，选择合适的项目并在项目中期开展自动化测试也是完全可行的。
　　● 首先从项目选择的角度出发
　 　对于一些比较小的项目而言，功能流程比较简单，页面结构也会比较稳定，所以一旦开发提交测试了，软件基本功能或者流程已经成型，页面也不会有大改动，并 且项目中有大量重复性操作的校验，或者是分支点很多的校验，这类项目的话自动化测试人员可以在冒烟阶段开始编写脚本，在P1阶段可以跑脚本了，并且脚 本的维护成本也会比较低。这样的项目比较适合做自动化。
　　另一种情况是，一些新的项目往往是在一些原有项目的基础上的一种升级，或者说 在原有项目的基础上进行增加新的功能。所以新项目中有一部分测试是针对已有功能的校验或者是在原有主流程基础上的一些新增加功能的测试。针对这类项目中的 这部分模块也可以尝试在项目中期进行自动化测试。
　　还有一种情况是，项目中某些模块对页面依赖并不是非常大，换句话说页面操作涉及的控件比较少，但是有大量的重复性的操作或者是大量的数据库校验的一些模块也完全可以通过自动化测试来完成。
● 从执行过程而言
　　首先从测试目前我们执行的测试是三轮测试。相对而言，在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.)
　　所以在项目中介入自动化测试能从用例的执行密度上保证项目质量。