浅谈-自动化测试

一、自动化测试的好处

1.回归测试，降低测试成本

对于产品型的软件或生命周期长的项目，经常会有新功能的开发或需求的变动，对于新发布的软件功能，大部分都和上一个版本相近或相同，这些功能如果在上一个版本之前已经实现了自动化测试，那么新发布的版本中，这部分功能就可以自动化测试实现，避免了重复测试的成本，也确保了软件的质量。

2.提高测试效率

一些测试用例手工测试是比较繁琐的，比如话单或协议字段的检查，如果是人工检查将是一件既繁琐又耗时还容易出错的工作，如果是自动化测试，测试就会变得轻松和容易很多。

对于检查点很多的测试用例，如果手工执行一步都需要停下来检查好几个复杂的检查点，测试的效率自然是非常低，使用自动化测试，设置好了输入条件和预期结果，只要点击按钮运行一下脚本就知道了复杂的测试结果。

3．易于发现软件的改动

自动化测试脚本可以重复执行，容易发现软件的任何变动。比如修复了一个TR后，引起原功能的改动，执行相同的脚本，可以通过测试轻易发现问题。

4.充分利用资源

自动化测试可以不需要人在现场的情况下自动执行，发布了一个新版本的软件后，可以在白天的上班时间进行新功能的手工测试，原有功能的自动化测试可以在晚上或周末执行，第二天上班就可以看到执行的结果。这样充分利用时间资源，提高测试的效率，也避免了开发和测试之间的等待。

5．性能测试

在一些压力大的性能测试中，人工是很难模拟的。在没有引入自动化测试工具之前，为了测试并发，研发中心再加上公司的其它部门上千号人在研发经理的口令“1－、2－、3！”的号召下，大家同时按下同一个按钮。这样的测试，虽然是模拟了并发，但需要消耗相当大的成本，想要测试一次也不容易。

在性能测试中使用自动化测试，可以轻易模拟并发，为性能压力测试提供了更好的方法。

6．将精力投入更有意义的测试

自动化测试减轻了很多重复的工作，我们有更多的时间去思考如何提高软件的质量，制定详细的测试计划，精心设计测试用例，构建更复杂的测试。对于我来说，这是自动化测试给我带来的最大的好处。

二、自动化测试的基本原则

2.1 判断是否适合做自动化

1、不适合做自动化测试的系统

1）系统业务逻辑和交互过于复杂

如果系统业务逻辑和交互过于复杂，要实现自动化测试的成本非常高，工具开发和脚本编写的时间可能远远大于手工测试，这个系统就没有自动化测试的必要。

2）项目周期过短

如果系统的生命周期很短（半年内），即使很容易实现自动化测试，但自动化测试的使用率只有很短的时间或很有限的次数，这样的自动化测试也没有必要。因为前期脚本的编写和后期的维护都需要很多的时间，虽然自动化测试在功能测试的过程或回归测试的过程会节省一些时间，但如果自动化测试的脚本只是很短的生命周期，自动化测试的成本就非常的高了。

3）系统需求频繁变动

对于功能不稳定的系统，会由于这些不稳定因素导致自动化测试失败，自动化的测试结果也就变得不可信，这类型的系统也不适合使用自动化测试。

2、适合做测试化测试的系统

适合做自动化测试的系统，通常是一些生命周期比较长的项目或产品，且系统功能实现自动化测试也较为容易，这样的项目使用自动化测试必然可以节省很多的资源和成本。特别是一些在今后的几年间需要不断开发和维护的项目，需要重复的进行大量的回归测试，如果有完善的自动化测试脚本，回归测试就可以节省大量的时间和精力了。对于一些增量式的产品，白天手工测试新功能，晚上或周末利用自动化测试脚本回归测试，可以达到资源使用的最优化，用很少的时间和很少的资源做很多的事情。

简而言之，是否值得使用自动化测试，就要看它是否具有自动化测试的特点和高的投资回报率。

2.2  开始自动化测试的时机

如果是新的自动化测试工具的开发或研究，最好预留一个比较充裕的时间，时间太赶很难设计出精品。如果想在功能测试阶段使用自动化测试，那么自动化测试架构的设计最好能够与代码实现同步，否则如果等代码实现提交测试之后再做自动化测试工具的开发或研究，在功能测试或回归测试的过程中就被动了很多。

关于在项目的什么阶段开始自动化测试，由项目决定，对于需求相对稳定并且是基于成熟的架构上开发的系统，自动化测试脚本最好在功能测试开始之前编写，在功能测试阶段就可以使用已经编写好的脚本做功能测试了。

但我们平时遇到的项目，有很多是需求变化比较大的，或者是一些不够成熟的系统，这样的系统如果在功能测试之前编写好的脚本，很有可能不能在系统上正确运行，大多还是需要手工执行才可以测试，甚至会在功能测试完后系统跟功能测试之前的系统会有非常大的区别。对于这样的项目，自动化测试开始得越早项目的成本就越大，最好在系统的架构或需求相对稳定后再做自动化测试。

对于一些需要录制GUI界面的功能的自动化测试，在页面的功能相对稳定之后再做自动化测试性价比会比较高，因为页面是最容易变动的部分，而且任何一个控件的修改都会导致自动化工具不能识别控件，导致很多自动化测试脚本会跟着做大量的修改，增加了维护的成本。当然，因为页面变化而引起的脚本的改动的大小，也跟自动化测试的架构和写脚本的功力有密切的关系。

对于一些协议或接口相关的功能测试（比如：XML或socket接口等），是较为容易实现自动化测试的，封装好底层的协议提供给自动化测试脚本调用，即使是协议会有变化，改动起来还是很简单的，维护的成本相对较低。

总的来说，在软件功能达到相对的稳定，没有严重错误和逻辑错误后开始自动化测试，性价比是比较高的。

2.3  自动化测试的覆盖率

自动化测试的覆盖率是很多管理层所关心的，很多项目或产品的自动化测试目标之一就是自动化测试的覆盖率。从管理的角度来说，100%的自动化目标只是一个从理论上可能达到的，但是实际上达到 100% 的自动化的代价是十分昂贵的。自动化测试覆盖率越高，测试脚本的维护成本也就越大。由于对每一个构建版本的需求变化的复杂度，你将花费更多的时间在变更测试用例上以使他们能够正确的运行。

自动化测试的覆盖率的大小与自动化测试的成本有着很大的联系。自动化测试的覆盖率为多少比较恰当，也要看被测试系统的性质和测试的阶段。

在自动化测试设计的阶段，可以考虑先实现冒烟测试的测试用例自动化，冒烟测试的功能一般是系统的主要功能，是自动化测试设计必须首先实现的，而且通过实现这些功能，也可以检验自动化测试的架构是否合理。

在功能测试的前期，自动化测试脚本的覆盖率最好只是一些关键的并且是相对稳定的功能的测试自动化，用于冒烟测试或关键功能测试。

系统稳定后，如果系统是一个生命周期很长的系统，且测试的功能很容易实现自动化测试，这样的系统的自动化测试覆盖率可以考虑在80％以上。

但如果是一些时间很赶的项目，或者是一些比较难实现自动化测试的功能，也就没有追求高的自动化测试的覆盖率的必要。随着测试案例的增加，维护的成本也会相应增加，特别是一些GUI的测试，自动化比率越高，维护脚本的成本也就越高。

不要追求在很短的时间实现自动化测试，也不要追求100％的自动化测试覆盖率，积累经验循序渐进的自动化测试，效果会更好。

三、自动化测试实现基本策略

自动化测试与软件开发本质上是一样的，利用自动化测试工具，经过测试需求分析，设计出自动化测试用例，从而搭建自动化测试的框架，设计与编写自动化脚本，验证测试脚本的正确性，最终完成自动化测试测试脚本（即主要功能为测试的应用软件）。

3.1 测试系统需求分析

任何测试的基础都是被测系统的功能，不管是手工的功能测试还是自动化测试或者是性能测试，都是基于系统的功能展开的。当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。

很多公司都是将自动化测试和功能测试划分成两个不同的team，自动化测试team的同事实现自动化测试工具的开发，功能测试team的同事向自动化测试team的同事提需求，自动化测试team的同事编写代码实现自动化测试工具的功能后提交给功能测试team的同事使用，这是当前非常常见的自动化测试的模式，毕竟每个人都有自己擅长的技能，某个人也不可能面面俱到，通过这样的一种方式可能使自动化测试的门槛变得更低一些。自动化测试工具的开发和自动化测试的使用的确是可以由不同的角色去承担，不过作为自动化架构设计的人员，应该是对系统的功能或需求非常熟悉，同时具有良好的设计和开发能力，才可以设计出适合测试系统的自动化测试架构，否则开发出来的自动化测试工具就只是简单的一个工具，某种程度上会增加维护的成本。

漂亮的自动化测试架构的设计是一个渐进的过程，但这个渐进是基于对功能熟悉的基础上，全盘考虑之后一点一点的搭建起来的。

3.2 自动化测试工具的选择

很多测试的同行或以前的老同事都会问，你们用什么自动化测试工具？几年前入门测试时跟着老前辈写自动化测试工具，后来因为兴趣偶尔玩一下当时流行的自动化测试工具，再到现在毫无选择工具的余地设计自动化测试架构，越来越发觉自动化测试工具真的没有那么的重要。工具始终是工具，思想和架构才是自动化测试的核心，同样的工具不同的人使用会出现完全不一样的结果，而且，不管是什么样的自动化测试工具，原理都有异曲同工之处。所以，不需要把工具看得那么重要，而是把怎样使用工具，怎样利用工具为你服务放在首位。也就是你的思想位于工具之上。

但是，是不是这就意味着测试工具一点也不重要呢？当然不是，遇上不稳定或不友好的测试工具，可能会浪费大量的时间在调试工具上，也可能会出现因为工具不稳定导致测试结果的不可信任，那么自动化测试不是提高测试效率反而是阻碍了测试的进度了。

关于工具的选择或开发，基本的原则为：1)首先，能够满足项目的需求，容易扩展，可以满足系统任何重要功能的自动化测试；2)其次，友好易用，容易上手，为测试人员提供较为低的门槛；3)当然最重要的是它的稳定性，是否不需要人工干预就能稳定地批量运行所有的自动化测试脚本，并且能够产出准确的测试报告；4)最后，还有一点就是它的性价比是否值得，免费的软件对公司来说当然是最好：）

市场上有很多测试工具，在这些测试工具中，puretest是一个性价比很高的自动化测试工具。它容易入门，易于扩展，使用简单，运行稳定，基本上可以满足任何包括GUI、协议和业务逻辑的测试。

3.3 自动化测试架构设计

自动化测试架构的设计是整个自动化测试的灵魂核心，它的好坏关系到自动化测试的成败。从系统的基本功能入手，设计自动测试架构，这是软件测试的关键一步。架构的好与坏很重要，它影响到系统的扩展、维护和使用，如果想要系统容易扩展和维护，一定要多花心思在设计上。很多同行问我使用什么测试工具，我会告诉他们，用什么测试工具其实并不那么重要，不同的人使用同样的测试工具，会做出效果完全不一样的自动化测试，那是因为他们的架构不同，设计比工具重要得多。

怎样的自动化测试架构才算是一个好的架构？首先是容易扩展，能够满足现在的功能需求，也能满足以后需要测试的功能的需求。第二，容易维护，当业务流程、接口或页面变动的时候，只需要做一些简单的修改就可以实现。第三，可读性强，别人能够容易读懂和接手维护。第四，容易使用，项目组的其他人想要使用的时候能够简单地搭建和运行。第五，有统一的编码规范、存储规范和编写风格。第六，方便调试，当脚本运行出现问题的时候，可以方便跟踪问题产生的根源。第七，结构清晰，测试用例与测试工具和代码分离。最后，是最重要的一点，是脚本具有很高的可信性以及自动运行的稳定性。

在设计架构之前，首先要熟悉测试系统以及这个测试系统需要测试的功能有哪些类型，每种测试类型在测试架构中是否都可以满足。在设计架构时，可以选择覆盖系统基本功能的smoke test测试用例来做基本的测试用例，在实现这些基本的测试用例的自动化测试过程中，对架构进行完善。基本的自动化测试框架实现之后，再回顾一下是否测试系统中需要实现自动化的测试用例，测试架构都可以满足需求，如果不可以满足则需要继续做进一步的开发，如果测试架构可以满足需求，接下来可以让其他的同事使用，收集改进的建议对测试架构进行完善和改进。好的测试架构，是要使用的人觉得舒服。

自动化测试架构设计的时候的一些基本的策略：

1、 自动化测试脚本与自动化测试架构的代码分离，自动化测试架构的代码实现自动化测试的基本功能，自动化测试脚本包含业务逻辑。

2、设计清晰的脚本和配置文件的存放目录。

3、 数据驱动

1）测试系统相关的配置、模拟器的配置等系统级的配置用系统级配置文件存放，不要把这些值写死在脚本或代码中，否则当测试系统的环境变化的时候相应的维护成本也会很高。

2）测试系统所使用到的一些规范定义取值，定义在配置文件中，在脚本中需要使用的时候引用变量定义，这样即使规范定义改变了也不需要修改脚本，只要简单的修改配置文件即可；如果外部规范定义和内部的定义取值不一样，最好有对应的mapping定义表。

3）测试数据的数据模型如果比较复杂，最好也在配置文件中对数据模型以及字段的取值进行定义，方便在脚本中创建数据时使用。

4） 协议或Schema或话单的格式，在配置文件中定义，当协议的格式改动的时候，只需要修改配置文件即可。

5）脚本中尽量少用常量，输入参数、脚本运行时提取的值、测试结果的对比等，都可以使用变量，避免脚本的常量写死后引起的维护工作。

4、测试数据准备

1） 测试数据准备，有两种类型，一类是脚本运行前事先可以准备好的数据，这种类型的数据，可以在自动化测试前自动创建好并保存到文件中提供给测试脚本使用；另一类是脚本运行时要创建的特殊数据，这些数据可以在脚本运行的过程中调用基础脚本进行创建。

2） 公用的数据，如果在脚本运行的过程中被修改，在该脚本运行结束后需要恢复到原样，避免因为公用数据的修改引起其它脚本运行失败。

5、模块化：对基础脚本进行封装，一些可以公用的脚本单独封装给其余的测试脚本调用，当公用的业务逻辑改变的时候，只需要修改基础脚本，而不需要对所有的测试脚本进行改动。

6、 提供自动化脚本编写模版，新写的脚本只需要在模版的基础上做很小的改动就可以实现功能，可以节省脚本编写的时间和降低脚本编写的门槛。

3.4 自动化测试脚本编写

自动化测试脚本的编写功力很重要，写得好的脚本，可以减少维护的工作量。自动化测试脚本一般由测试的输入、业务逻辑、测试输出和测试结果验证几部分组成。自动化脚本的编写，要注意全局的把握和review，不同的人会有不同的风格，稍不注意就会问题多多。在自动化脚本编写前，给相关同事提供技术和架构的培训，培训的内容包括被测试系统的基本功能介绍、自动化测试工具的架构、自动化测试的配置说明、自动化测试的编写原则、自动化脚本编写示例等。自动化测试脚本的例子也很重要，建议在脚本编写前对系统准备实现自动化测试的功能进行分类，由资深的自动化测试工程师根据每个分类都先写一个例子并且review通过后作为这些功能的自动化测试脚本的编写模板，其余的同事可以参照例子按照自动测试架构编写规范写脚本。

编写脚本时应该注意脚本的可重用性和可维护性，如果脚本中充满了硬编码的值，这些值应该被参数化，否则脚本仅仅适用于一个测试情况，脚本还应该加入条件判断、循环等结构，以便增强测试脚本的灵活性。

在编写脚本的时候必然会遇到技术问题或业务问题，需要有资深的工程师或TL协助解决，并且在整体的架构上全局把握。脚本编写完成后，需要有一个抽查Review的过程，挑几个典型的脚本review一下，看看是否存在不足的地方，然后改进。

3.5 自动化测试脚本测试

当每一个测试用例所形成的脚本通过测试后，并不意味着执行多个甚至所有的测试用例就不会出错。输入数据以及测试环境的改变，都会导致测试结果受到影响甚至失败。而如果只是一个个执行测试用例，也仅能被称作是半自动化测试，这会极大的影响自动化测试的效率，甚至不能满足夜间自动执行的特殊要求。

自动化测试脚本最基本的原则是测试结果可信，也就是在批处理运行这些脚本的时候，该测试通过的就测试通过，该测试失败的就测试失败，如果出现本应该失败的脚本在运行的时候通过了或本应该通过的脚本在运行时失败了，测试结果就变得不可信了，自动化测试也就失去它本应该有的意义。

因此，脚本的测试与试运行极为重要，它需要检查多个脚本不能依计划执行的原因，并保证其得到修复。同时他也需要经过多轮的脚本试运行，以保证测试结果得一致性与精确性。

3.6 自动化测试脚本执行

 

自动化脚本主要有三个用途：功能测试、为手工测试做数据准备和回归测试。在功能测试的阶段，可以利用自动化测试脚本进行数据的准备，也可以利用自动化脚本进行功能测试。在项目稳定之后自动化测试的最大价值就是回归测试。

 

脚本可以分为三个级别：基本流程测试脚本，用于每次出新build安装后做smoke test；关键功能测试脚本，每次出新build后对所有重要功能进行回归测试，确保改动不会对原有功能的造成影响；全面回归测试脚本，系统经过比较大的修改或系统上线前作回归测试。自动测试脚本在回归测试中发挥了出色的作用，特别是系统在上线前夕，为了适应客户的需求，功能不断修改，对于原有的功能，自然不可能都手工测试，脚本在这个时候的意义特别大。

3.7 自动化测试持续集成

自动化测试可以做到持续集成，从编译到测试，任何一步都可以自动化：

1、将所有的源代码存放在服务器，持续集成任务起来后到源代码管理服务器上进行自动编译，对编译的结果进行分析，并将编译成功的软件版本放到发布服务器；

2、将新版本的软件下载到测试环境，并且自动安装；

3、自动安装成功后进行冒烟测试，如果冒烟测试成功则证明软件的版本是可用的；

4、自动执行自动化测试脚本进行功能测试或回归测试；

5、自动化测试结束后生成测试报告，将测试结果发送邮件给相关的人员。

在持续集成中任何一步失败都会导致整个测试失败，自动化测试生成失败的测试报告，并将测试结果发送给相关的人员。