发布时间 : 星期三 文章自动化测试基础更新完毕开始阅读
但是，是不是这就意味着测试工具一点也不重要呢？当然不是，遇上不稳定或不友好的测试工具，可能会浪费大量的时间在调试工具上，也可能会出现因为工具不稳定导致测试结果的不可信任，那么自动化测试不是提高测试效率反而是阻碍了测试的进度了。
关于工具的选择或开发，基本的原则为：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、自动化测试结束后生成测试报告，将测试结果发送邮件给相关的人员。
在持续集成中任何一步失败都会导致整个测试失败，自动化测试生成失败的测试报告，并将测试结果发送给相关的人员。
1.5 自动化测试过程
制定测试方案 准备测试数据 编写集成测试用例表
编写、修改、维护测试脚本
测试实施
test runner 脚本通常与所测试的应用程序（AUT）部署在同一个服务器上。 test runner 脚本
清单 1. Selenium 测试用例的结构
| First command | Target | Value |
| Second command | Target | Value |