自动化功能测试实施流程

版本：V1.0

目 录

1  简介.... 3

1.1       目的... 3

2  自动化实施流程.... 3

2.1       测试项目评估... 3

2.1.1       不适合项目... 3

2.1.2       适合项目... 3

2.2       测试计划制定... 4

2.3       测试用例筛选... 4

2.3.1       自动化测试用例的原则... 4

2.4       测试工具选择... 4

2.4.1       测试工具的优点... 5

2.4.2       测试工具的不正确期望... 5

2.4.3       主流的测试工具... 5

2.4.4       测试工具的选择... 7

2.5         测试框架构建... 7

2.5.1       自动化框架设计原则... 7

2.6       测试脚本开发... 8

2.6.1       测试脚本的目标... 8

2.6.2       自动化脚本编写的规范... 8

2.7       测试数据准备... 9

2.8       测试脚本调试... 9

2.9       测试脚本执行... 9

2.10     测试结果分析... 10

2.11     测试报告编写... 10

2.12     测试脚本维护更新... 10

1   简介

1.1  目的

       该文档主要描述了实施自动化功能测试的主要流程，为实施自动化测试提供指导和参考;自动化测试实施的主要流程如下：测试项目评估--测试计划的制定--测试用例的筛选--测试工具的选择—测试框架的构建--测试脚本的开发--测试数据的准备--测试脚本的调试--测试脚本的执行--测试结果的分析—测试报告的编写--测试脚本的维护和更新。

2   自动化实施流程

2.1  测试项目评估

  对于即将开展自动化测试的项目，首要的工作就是评估该项目是否适合做自动化测试，其依据主要从下面两个方面权衡，确定该项目是否进行自动化测试。

2.1.1  不适合项目

　　自动化测试不是适合所有的公司、所有的项目。

　　1、定制型项目(一次性的)

　　为客户定制的项目，维护期由客户方承担的，甚至采用的开发语言、运行环境也是客户特别要求的，即公司在这方面的测试积累就少，这样的项目不适合作自动化化测试。

　　2、项目周期很短的项目

　　项目周期很短，测试周期很短，就不值得花精力去投资自动化测试，好不容易建立起的测试脚本，不能得到重复的利用是不现实的。

　　3、业务规则复杂的对象

　　业务规则复杂的对象，有很多的逻辑关系、运算关系，工具就很难测试。

　　4、美观、声音、易用性测试

　　人的感观方面的：界面的美观、声音的体验、易用性的测试，也只有人来测试

　5、测试很少运行：一个月只运行一次

　　测试很少运行，对自动化测试就是一种浪费。自动化测试就是让它不厌其烦的、反反复复的运行才有效率。

　　6、软件不稳定

　　软件不稳定，则会由于这些不稳定因素导致自动化测试失败。只有当软件达到相对的稳定，没有界面性严重错误和中断错误才能开始自动化测试。

　　7、涉及物理交互

　　工具很难完成与物理设备的交互，比如刷卡的测试等。

2.1.2  适合项目

自动化测试之所以能在很多大公司实施起来，就是有它适合自动化测试的特点和高的投资回报率。

　　1、产品型项目

　　产品型的项目，每个项目只改进少量的功能，但每个项目必须反反复复的测试那些没有改动过的功能。这部分测试完全可以让自动化测试来承担，同时可以把新加入的功能的测试也慢慢地加入到自动化测试当中。

　　2、增量式开发、持续集成项目

　　由于这种开发模式是频繁的发布新版本进行测试，也就需要自动化测试来频繁的测试，以便把人从中解脱出来测试新的功能。

　　3、能够自动编译、自动发布的系统

　　要能够完全实现自动化测试，必须能够具有自动化编译，自动化发布系统进行测试的功能。当然，不能达到这个要求也可以在手工干预下进行自动化测试。

　　4、回归测试

　　回归测试试自动化测试的强项，它能够很好的确保你是否引入了新的缺陷，老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。

　　5、多次重复、机械性动作

　　自动化测试最喜欢测试：多次重复、机械性动作，这样的测试对它来说从不会失败。比如要向系统输入大量的相似数据来测试压力和报表。

　　6、需要频繁运行测试

　　在一个项目中需要频繁的运行测试，测试周期按天算，就能最大限度的利用测试脚本，提高工作效率。

　　7、将烦琐的任务转化为自动化测试

2.2  测试计划制定

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试工具、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

针对自动化测试的测试计划主要偏重于测试策略、测试方法、测试工具、测试周期，测试资源；是进行自动化测试的参考和依据。

2.3  测试用例筛选

测试项目是否需要进行自动化需要评估，同时，对于适用自动化测试的项目并不是所有的测试案例都适用于自动化，所谓“选择测试用例进行自动化”，就是根据每个用例“实现自动化的难易程度”和“重要性”两方面进行优先级的排序。

2.3.1  自动化测试用例的原则

自动化测试是用来验证曾经正确工作的部分仍然在正确工作。选择测试用例进行自动化的原则是：

l  如果测试用例未通过手工测试，不要自动化

l  如果不能通过自动化对这个用例进行100%准确测试，不要自动化

l  结合项目情况，分析用例“实现自动化的难易程度”和“重要性”，按优先级进行自动化

2.4  测试工具选择

选择测试工具首先要对测试工具有个清晰的认识，认识到工具的优点和不足，做到发挥其长处优势，使其对测试项目发挥最大的效益。

2.4.1  测试工具的优点

测试工具具有以下优点：

l  提高测试质量，避免人为因素。

l  提高测试效率，减轻重复的人力。

l  提高测试覆盖率，通过录制回放和数据驱动来测试功能，可以分析测试深度。

l  更好地重现软件缺陷，同一个自动化测试脚本执行的测试结果具有一致性。

l  更好地利用资源，可以在周末或晚上时间自动执行测试。

2.4.2  测试工具的不正确期望

对测试工具不应抱有不正确的期望，例如：

l  “自动化测试可以完成一切测试工作”。

这是绝对不可能的。目前没有任何一种测试工具（在可以预见的将来也不会有）能够完全替代手工测试。自动化测试仅仅是对手工测试的补充。

l  “测试工具能使工作量大幅度降低”。

事实正好相反，首次将测试工具引入团队的时候，测试工作将变得更为艰巨，团队也将增加更多的工作量。只有合理地使用测试工具，且有一定的技术积累后，测试工作量才会逐步下降。

l  “测试工具能够实现百分之百的测试覆盖率”。

在有限的资源下，即使使用测试工具也无法达到100%的测试覆盖率。

l  “自动化测试工具容易使用”。

由于捕获操作是否正确以及测试脚本的编辑是否合理都会影响测试结果，因此，掌握自动化测试技能需要更多的培训和实践。

l  “自动化测试能发现大量的新缺陷”。

事实上，发现新缺陷的任务通常是由手工测试来完成的。自动化测试主要用于发现已有的老缺陷。

2.4.3  主流的测试工具

2.4.4  测试工具的选择

    对测试工具有了清晰的认识后，就要根据公司的预算，测试计划，以及项目的开发语言和运行环境统筹考虑，选择一款或一组自动化工具进行自动化测试的开发。选用工具时需要考虑以下问题：

l  开发平台和开发语言的支持：确保工具支持项目的开发平台和开发语言。

l  功能：事实上目前市场上同类测试软件的基本功能大致相同，只是侧重点有所不同。因此，除了基本功能外，我们还可以通过以下几方面来进行考量（报表功能：能否提供清晰的测试结果报表；集成功能：能否和开发工具进行良好的集成；兼容性：与团队目前采用的开发平台是否兼容）。

l  价格：从价格昂贵的商用测试软件，到完全免费的开源测试软件，有很大的选择余地。当然商用软件的品质通常更有保证。

l  长期考虑：应保证今后测试工具与团队开发工作能够具备连续性和一致性。例如应考虑软件升级带来的影响。

2.5   测试框架构建

自动化框架可以大规模的驱动自动化测试脚本的并行执行，并能够在短时间之内获取到测试结果。并根据测试结果生成完整的测试报告。而这个测试报告时一个软件版本能否发布的重要的质量依据。越早拿到整个测试报告，产品的发布周期就会缩短。 Time to Market的时间就会缩短，企业就会早一点占领市场。

2.5.1  自动化框架设计原则

一个好的自动化测试项目必须有一个好的框架，由于提高效率，降低成本，好的测试框架设计时主要考虑如下原则：

l  测试脚本和测试框架脱离

即是将“一个测试脚本负责整个测试执行过程”的设计思路变为“测试脚本只负责业务逻辑，一个测试框架驱动多个测试脚本完成测试”。当业务逻辑变化时，我们可以只修改测试脚本和数据而无须修改测试框架。

l  测试数据和测试脚本脱离

当测试数据需要增加和修改时，我们可以只修改测试数据而无须修改测试脚本。

l  强力的执行引擎：真正做到无人值守

所谓强力的执行引擎，是指一个自动化测试框架在批量执行脚本的情况下，不论遇到什么情况，如脚本运行错误，脚本质量错误，测试环境异常，被测设备死机或者挂起等，都要有能力重新清理测试环境，使测试环境恢复到最初始的状态，并执行接下来需要执行的脚本。 也就是说，一个好的测试引擎，能够做到24小时7天的无人值守的运行，而不会中途因为任何的非物理异常而退出。

l  良好的报表生成和管理功能

良好的报表生成功能是指一个测试框架要有分布式的对脚本的结果的收获和呈现的能力。很多情况下，脚本是并发执行的，就像一下子种了一大块田，而当脚本执行完毕，也就是庄稼成熟的时候，如何对脚本执行的结果进行快速收割，并捆绑好，整齐划一，让人对结果一目了然。更重要的是，要需要能够提供针对不同版本的相同自动化脚本执行日志的比较。并能够对这些报表进行搜索和排序， 这些都需要一个很好的报表生成和管理功能。

2.6  测试脚本开发

   测试脚本不仅仅是简单的录制回放，为了满足测试脚本的目标，使测试脚本更稳定，重用性更强需要对测试脚本进一步的开发。

2.6.1  测试脚本的目标

l  可维护性

易于更新；易于理解脚本的行为；简单。

l  可靠性

精确性；可重复性；弹性。

l  可重用性

在未来；在其他项目中；被其他测试人员使用。

2.6.2  自动化脚本编写的规范

　　1）基本信息

　　在每个脚本模块的最上面，必须写上脚本运行的软件和硬件环境（如IE版本、QTP版本、数据库版本等）、外包项目名称、脚本编写人（使用英文名或中文拼音缩写）、脚本创建时间、脚本修改时间、修改说明、输入参数、输出参数、脚本描述等。

　　2）常量命名规范

　　常量的命名应该全部用大写，使用"_"作为单词间的分隔符，单词尽量使用全名称，如，Public Const MSG_EMPTY_ROW As String = "有空行存在"。

　　使用Public而不是早期版本的global来声明变量。

　　另外，对常量的声明必须带上类型，如前面的As String。

　　3）变量命名规范

　　变量命名应该简单，应尽量使用缩写。如果是一般的值类型（如integer string），则直接使用变量用途命名。尽量使用全名，例如，Dim name As String；如果是一般的临时性变量定义，应该尽可能地简单，例如，Dim i As Integer；如果名称由多个单词组成，则取每个单词的首字母，如EntityManager缩写为em，ProcedureManager缩写为pm；如果名称由一个单词组成，则对单词进行分段取首字母，如Entity缩写为et。缩写应该控制在3个字母以内，且尽量清晰。

　　4）参数命名规范

　　参数命名的原则是全部用小写，如果参数包括两个或两个以上的单词时，首单词字母小写，其他单词首字母大写，如stepName、stepDescription。

　　5）函数命名规范

　　此处函数包括sub和function，函数表示的是一个动作，所以它的结构应该是动词+名词，动词必须小写，后面的名称首字母大写，如getMaterialCode。函数命名尽量不要使用缩写，而且它的名称应该使人一目了然，能够从名称就知道这个函数的功能，不要使用无意义的函数名称。当函数名称不足以表达其功能时，应使用在函数头部加上让调用者足够明白的注释。

　　6）代码注释规范

　　注释务必做到准确简洁，能够充分表达代码实现的功能。

　　7）空行

　　空行是区分代码块与块的间隔，在函数之间必须加上空行；而在函数内部，变量声明块和实现块（实现块指除变量声明外的其他代码）要使用空行来间隔，实现块的内部，通过空行来标识一个功能段。

　　8）缩进

　　必须严格执行缩进，变量声明块不缩进，实现块必须保证全部缩进（不可能有实现块是行首对齐的）；对于基本的控制结构来说，必须要有缩进，如IF、DO、WITH、FOR、WHILE块。

　　9）续行

　　对于过长的语句来说，必须使用续行，续行位置要有明显意义，例如，sql ="SELECT [code]，[name] FROM [Person]"_&"WHERE [code] LIKE'001%'"。

　　另外，还要通过管理对象库来提高代码的可读性，通过修改命名来达到更加易读的效果。对于使用比较频繁的代码块来说，最好将其写成函数，并尽量将功能复杂的大函数拆分成小函数。

注意：在任何地方，不要写ElseIf语句，最好转换成If…Else…Endif结构。

　　10）检查点检查

　　每个测试脚本都应该有相应的检查点及对应的检查结果输出。

2.7  测试数据准备

信息化的时代信息的重要性被越来越多的人重视，同理，测试数据的重要性对于整个自动化测试而言的重要性是不言而喻的。数据是整个测试过程的灵魂，测试数据的准备不仅仅包括测试初始数据的准备，测试数据的存储方式，还包含测试过程中不重复输入数据的生产规则以及输出数据的保存和利用。

用来存贮数据的文件多为以下几种：格式化的文本文件；Excel文件；xml文件以及各种数据库文件。

2.8  测试脚本调试

    测试脚本并不是一蹴而就，好的测试脚本稳定性和重用性都比较高，脚本完成基本的流程后还需要针对不同的初始条件，不同的异常，不同的情况进行调试，保证脚本的健壮性。

2.9  测试脚本执行

测试脚本开发完成后就要对测试脚本进行管理，执行；测试脚本的执行主要包含如下内容：

测试环境的管理配置；

测试脚本配置；

测试脚本的执行；

测试异常中断处理和恢复。

2.10 测试结果分析

    测试结果出来后要对测试结果进行检查分析，确保相应检查点都成功执行，未通过的脚本是真实缺陷还是工具环境造成以决定是否提交相应的缺陷，为接下来的测试报告的编写提供准确的测试数据。

2.11 测试报告编写

针对分析后的测试结果形成相应的测试报告，主要包括发现的缺陷数，缺陷的等级等，做为评判此次软件版本质量的依据。

2.12 测试脚本维护更新

随着软件新需求的增加，需求变更，以及软件开发技术的升级更新，也要对测试脚本进行相应的维护和更新使其满足项目的测试需求，测试脚本的维护和更新是一个持续的过程将伴随项目的一生。