【自动化测试总结】优点、场景、流程、项目人员构成

一、自动化测试的概念

以程序测试程序，以代码代替思维，以脚本的运行代替手工测试，可以大大提高工作测试的效率。

二、自动化测试的优点

1.回归测试更为方便，可靠。自动化测试最主要的任务和特点，特别是在程序修改比较频繁的时，效果最为明显。由于回归测试的业务流程流程操作和测试用例是预先完全设计好的，预期结果也是完全在项目人员掌握之中的，将回归测试交给计算机自动运行，可以极大提高测试效率，缩短回归测试时间。但是，上述说的程序修改比较频繁指的是新功能不断加入，而老公能的逻辑是不变或者很少变化的，不是指整个程序全部或者大批量的改动。因为这样是违反自动化测试原理的。

2.可运行更多，更为繁琐的测试，且快速高效。自动化测试可以实现在短暂的时间运行更多的test case。我们知道，有很大一部分业务功能由于业务逻辑极其繁琐，使用手工测试往往耗费大量的时间，测试1次，2次，3次还可以，但是如果测试10次以上或者更多，耐心会达到极致。

3.可以执行对于手工测试来说相当困难或者根本做不到的测试。比如，对于大量用户的测试并发，不可能同时让足够多的测试人员同时进行测试，但是却可以通过对自动化测试模拟同时有许多用户并发点击某一功能，从而达到测试的目的。再比如，人工不可能24小时不眠不休进行测试，但是计算机则不同休息。当然，类似的例子还有很多，无法全部列举出来。

4.更好地利用资源，使资源的使用更有价值。将方所的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来，投入更多精力设计更好的测试用例。有些测试不适合于自动化测试，仅适合手工测试，将可自动化测试的测试自动化后，可以让测试人员在专注于手工测试部分，提高手工测试的效率。

5.自动化测试脚本完全更有信任度。

6.自动化测试脚本完全具有复用性。

7.多个环境下进行测试。我们知道，一个系统，往往会被要求能够支持各种不同的环境并稳定运行，但是这么多不同的环境，比如常用浏览器有IE6,IE7,IE8,FireFox等，系统有Windows 2003，Windows XP，Windows Vista，Windows 7等，甚至还有杀毒软件，如卡巴斯基，360，诺顿等，这么多环境的组合，如果每一种环境组合我们都需要花人力，物力去把功能测试一遍，会无形加重负担。

三、适合引入自动化测试的条件

1.项目周期长，系统版本不断。如果你目前躲在测试的项目或者系统是属于一个周期比较长的项目的时候，可以说，的确非常适合引入自动化测试，把大量的回归测试托付给测试自动化是一个比较明智的选择。还有一种根据是从系统的版本数得来的，曾经测试领域专家有过相关的研讨并最后得出结论，一般自动化测试耗费的时间是手工测试的6-10倍，所以，如果你所在的项目版本数在10个以上，纳闷，引入测试自动化也同样非常的睿智。

2.需求变更不频繁，当项目的需求非常稳定，不会进场出现变更的时候，此时也很适合引入测试自动化。

3.系统中的测试对象基本可以正常识别。

4.系统中不存在大批量第三方控件。有实际项目经验的人一定会发现，无论什么系统，B/S架构也好，C/S架构也好，多少存在一些第三方控件，但是如果这些第三方的控件数量不多的话，经过详细的计划与评估后，完全可以引入测试自动化，当然，如果第三方控件数量庞大或者刑事种类庞大的话，就会带来很多麻烦。

5.需要反复测试。

PS：多数对象无法识别以及脚本维护频繁与艰难，二者有其一，自动化测试注定失败。如果项目中存在大量无法识别的空间（这种情况基本是发生在系统中存在大量的第三方控件）或者项目中没有获得相应的对象识别插件，是没有办法写出自动化测试脚本的。当然，对象的识别不一定要靠插件，还有其他解决方法，比如SDK插件扩展，或者让开发人员提供相应的DDL来识别等。

自动化测试工具对系统具有有效性。如果项目时间并不紧迫，项目需求也较为稳定，项目周期也较长，那么可想尝试开发自动化测试脚本，必须具备一款匹配的自动化测试工具，那么可以是开源的也可以是商业化的，甚至是自主研发一款。此时，就需要确切的了解这款测试工具是否真的能够应付项目需求，假设你所在的公司购买了一款商业化的自动化测试工具，项目系统中全部是一些java控件，但是测试工具自带的插件中又不包含java控件的识别插件，那么此时就算拥有这款自动化测试工具，但是由于无法有效的识别到项目中的控件，所以，对于项目来说是毫无作用的。

四、自动化测试的一个流程

1.合理的自动化测试切入点。通常，项目只有在经历了完整的系统测试后才算具备了基本的引入测试自动化的条件。一般也就在这个时间段，项目经理与测试经理才会以此定位自动化测试开始筹划与准备的时间点。到目前为止，绝大部分的公司都以系统测试完成为标准来作为自动哈UC屙屎的切入点，因为在这之前的任何阶段中都不是非常适合做自动化测试。

2.测试自动化分析

（1）可行性分析

（2）抽样demo分析 demo已经是一个实体案例，所以完全可以通过透析demo来发现是否存在技术上的致命问题通常在demo完成之后，有经验的自动化测试工程师或者组长就能对这个项目的自动化测试工作有一个答题的把握了，关于demo的选取，一般直接选择猫眼测试用例写成测试脚本，检查脚本是否能够成功运行通过，已设计的测试点是否全部执行到即可。

（3）测试需求分析我们需要分析项目中具体哪些测试需求（功能点）准备进行自动化测试，一条测试需要可以包含多条自动化测试用例，通过测试需求分析来判定项目中此时自动化要做到什么程度。举个例子，在自动化测试用例的设计上，大体是一正向，反向划分，我们知道自动化测试是不需要也没有必要做到100%覆盖率，所以在测试需求分析这个阶段，确定测试覆盖率以及自动化测试粒度，测试用例上筛选等都是重点工作。

PS:正向测试用例就是正常的业务操作流，几乎没有什么非正常的情况，反向及时一场的业务操作流。

3.测试计划的定制

4.自动化测试设计阶段

（1）自动化测试框架设计，开发与搭建自动化测试框架对于整个自动化测试项目来说就相当于一个架构，这个架构越好，功能越强大和使用，呢就可以给今后整个自动化测试项目的工作过程带来更多的好处，自动化测试框架是能保证测试的分布执行，脚本模块化，数据驱动，日志分析，错误截图，报表回收，共享对象库，公共函数库，环境配置，同一设计模式，异常处理，场景回复等一个无人值守，针对每个肚里项目的测试框架。

（2）自动化测试用例设计三部曲

.筛选手工测试用例的过程首先要根据测试需求分析阶段得出的分析结果筛选出所有要被测试自动化的手工测试用例，在全部筛选完毕后，再分成两部分，一部分是可以直接二次复用的手工测试用例，不要客气，直接拿来即可，另外一部分则要经理下一个过程，实际上，大多数还是需要经历改造的，毕竟自动化测试用例的设计方法和手工测试用例的设计方法有点出入，哪怕是冒烟测试用例多少也要修改。

.转换手工测试用例的过程

.新增和补充自动化测试用例的过程

5.测试脚本设计与开发

在自动化测试中，测试脚本大致可以划分为5种

（1）线性脚本：通过录制直接产生的线性执行的脚本

（2）结构化脚本，具有顺序，循环，分支等结构的脚本

（3）可共享脚本：可以被多个测试用例使用，被其他脚本调用的脚本

（4）数据驱动脚本：测试数据和业务流程控制分离的脚本，通过读入数据文件来驱动流程进行的脚本

（5）关键词驱动脚本：脚本，数据，业务分离，数据和关键字在不同的数据表中，通过关键字来驱动测试业务逻辑，关键字驱动脚本的特点是，她看起来更像描述一个测试用例在做什么，而不是如何做

6.自动化测试执行

所有的自动化测试脚本全部开发完毕后会进入合并联调阶段，脚本联调成功后方能进入这一阶段。

脚本联调是一个关键的时期，联调如果不通过是无法进行下一个环节的，毕竟都到了这个阶段了，已经花了很多工时了

（1）无人值守的测试

.环境搭建，部署与配置

.自动化测试用例和测试脚本互相绑定

.自动化测试用例执行顺序排列与组合

（2）异常处理和场景恢复

（3）一个自动化测试执行实例，举一个QC自动化测试框架（Quality Center 一款集测试解决方案，测试流程管理，缺陷管理的工具，其本身也是一个自动化测试框架的例子）我们将测试脚本上传到QC服务器与相应测试用例绑定，最后，可以生成一个测试集，测试集里可以导入之前设计的测试用例，如果导入的用例和脚本有过绑定，则脚本也随之自动加载到测试集中，只需要点击执行按钮即可如果在执行过程中发生意外秦光，只要预先设置了各种异常情况及处理应对方式，QC就会自动进行处理，并把测试场景恢复到预置的状态重新自动执行测试。等测试集中的测试用例全部运行完毕后，QC就会显示这些测试用例的运行结果并生成图标，然后自动将缺陷提交到服务器中，方便测试工程师了解自动化测试运行以及完成的情况乃至发现的缺陷情况。

7.提交自动化测试产物

8.测试脚本维护