Testing - 软件测试知识梳理 - 自动化测试

软件开发的过程是一个持续集成和改进的过程，而每一次的改进均可能引进新bug,所以当软件的一部，或者所有修改时，都须要对软件产品从新进行测试。
其目的是要验证修改后的产品是符合需求的，而当没有自动化测试代码时，每每会因为各类各样的缘由，回归不充分，致使bug遗漏。

自动化测试模型

一个自动化测试框架就是一个集成体系，在这一体系中包含测试功能的函数库、测试数据源、测试对象识别标准，以及种可重用的模块。
自动化测试框架在发展的过程当中，不断有新的模型（概念）被提出，目前经历了几个阶段:模块驱动测试、数据驱动测试、对象驱动测试。
自动化测试模型是自动化测试架构的基础。

线性测试

经过录制或编写脚本，一个脚本完成一个场景（一组完整功能操做） ，经过对脚本的回放来进行自动化测试；
优点就是每个脚本都是独立的，任何一个脚本文件拿出来就能单独运行；
缺点也很明显，用例的开发与维护成本很高；
这种模式下数据和脚本是混在一块儿的，若是数据发生变也须要对脚本进行修改。这种模式下的脚本没有可重复使用的概念；

模块化与类库

把脚本中重复使用的部分代码独立出来，造成公共的模块或库，须要的时候进行调用；
优势：提升了开发效率，不用重复的编写相同的脚本；方便了代码的维护，代码的更改限制在模块以内；

数据驱动

数据的改变（更新）驱动测试自动化的执行，从而引发测试结果的改变；
能够直白地理解成“输入数据的不一样从而引发输出结果的变化”；
优势是实现了数据与脚本的分离（参数化），加强的脚本的复用性；
在开发层面，易于实现；

关键字驱动

理解了数据驱动，无非是把“数据”换成“关键字”，经过关键字的改变引发测试结果的改变；
独立以编程方式实现关键字驱动彷佛不太容易，通常是利用现有工具和框架；
在QTP、robot framework 等此类型的测试工具中， “填表格”式的关键字驱动封装了不少底层的东西，易用性强；
测试人员只要考虑三个问题：要作什么？ 对谁作？怎么作？

自动化测试用例

自动化测试用例	手工测试用例
执行对象是脚本，任何一个判断都须要编码定义。	较好的异常处理能力，能经过人为的逻辑判断校验当前步骤的功能实现正确与否
用例步骤之间关联性强。	人工执行用例具备必定的步骤跳跃性。
主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工做中解脱出来。	人工测试步步跟踪，可以细致的定位问题。
主要定位在冒烟测试和回归测试	主要用来发现功能缺陷

自动化测试替代不了手工测试，目的仅仅在于让测试人员从繁琐重复的机械式测试过程解脱出来，把时间和精力突入到更有价值的地方，从而挖掘更多的产品缺陷。

• 冒烟测试执行的是主体功能点的用例。
• 回归测试执行所有或部分的测试用例。

自动化测试用例设计

一些注意事项：

1. 不是全部的手工用例都要转为自动化测试用例。
2. 考虑到脚本开发的成本，不要选择流程太复杂的用例。若是有必要，能够考虑把流程拆分多个用例来实现脚本。
3. 选择的用例最好能够构建成场景。例如一个功能模块，分 n 个用例，这 n 个用例使用同一个场景。这样的好处在于方便构建关键字测试模型。
4. 选择的用例能够带有目的性，例如这部分用例是用例作冒烟测试，那部分是回归测试等，固然会存在重叠的关系。若是当前用例不能知足需求，那么惟有修改用例来适应脚本和需求。
5. 选取的用例能够是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。
6. 选取的用例能够是主体流程，这部分适用冒烟测试。
7. 自动化测试也能够用来作配置检查，数据库检查。这些可能超越了手工用例，可是也算用例拓展的一部分。项目负责人能够有选择地增长。
8. 若是平时在手工测试时，须要构造一些复杂数据，或重复一些简单机械式动做，告诉自动化脚本，让他来帮你。或许你的效率所以又提升了

一些原则：

• 一个脚本是一个完整的场景
• 一个脚本只验证一个功能点
• 遵循用户正常使用原则编写脚本，尽可能只作功能中正向逻辑的验证。不要考虑太多逆向逻辑的验证（逆向逻辑的状况会不少，须要编写大量的脚本，并且非正常的逻辑难以被自动化脚本所验证）
• 在整个脚本中只对验证点进行验证，不要对整个脚本每一步都作验证。
• 若是对数据进行了修改，须要对数据进行还原。
• 脚本之间不产生关联性，也就是说编写的每个脚本都是独立的，不能依赖或影响其余脚本。

软件过程自动化

• 构建自动化：自动化从各个模块的源码构建组装成一个完整的产品
• 测试自动化：构建前自动完成相应的测试工做
• 部署自动化：对于经过测试的构建好的产品，作好成品测试后，自动化部署到生产服务器
• 自动化场合选取：尽可能对稳定的对象作自动化，如API接口；GUI不建议使用自动化，投资回报比过低，变动大
• 自动化比例：基于稳定的测试环境和测试计划；在效率和质量上寻求平衡点

自动化测试的实施

适合作自动化测试的项目

• 软件需求变更不频繁
  测试脚本的稳定性决定了自动化测试的维护成本。
  若是软件需求变更过于频繁，测试人员须要根据变更的需求来更新测试用例以及相关的测试脚本。
  而脚本的维护自己就是一个代码开发的过程，须要修改、调试，必要的时候还要修改自动化测试的框架，若是所花费的成本不低于利用其节省的测试成本，那么自动化测试即是失败的。
  项目中的某些模块相对稳定，而某些模块需求变更性很大。咱们即可对相对稳定的模块进行自动化测试，而变更较大的还是用手工测试。

• 项目周期较长
  自动化测试需求的肯定、框架的设计、脚本的编写与调试，这样的过程自己就是一个测试软件的开发过程，须要较长的时间来完成。
  若是项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。

• 自动化测试脚本可重复使用
  所测试的项目之间是否很大的差别性（如C/S系统和B/S系统的差别）；
  所选择的测试工具是否适应这种差别；
  测试人员是否有能力开发出适应这种差别的自动化测试框架。

不一样阶段对应的自动化测试

• 单元测试
  关注代码的实现逻辑，例如一个if 分支或一个for循环的实现；
  利用相应的单元测试框架，几乎全部的主流语言，都会有其对应的单元测试框架。

• 集成、接口测试
  关注函数、类（方法）所提供的接口是否可靠。

• UI层的功能测试
  经过相应的自动化测试工具来模拟UI层的功能测试，从而解放重复的劳动。

自动化测试应该侧重于单元测试与接口测试。而后有选择有必要地经过自动化方式“部分解放”UI层的重复劳动。
三种测试的比例要根据实际的项目需求来划分。
以google为例，70%的投入为单元测试，20%为集成、接口测试，10% 为UI层的自动化测试（《google 测试之道》）。

参考信息

• 聊聊自动化测试框架