测试开发手册

自动化理解及应用场景

# 自动化理解及应用场景

# 什么是自动化测试

意义：

自动化测试是把人对软件的测试行为转化为由机器执行测试行为的一种实践

本质：

先写一段代码，然后去测试另一段代码，所以实现自动化测试用例本身属于开发工作，需要投入大量的时间和精力，并且已经开发完成的用例还必须随着被测对象的改变而不断更新，需要为此付出维护测试用例的成本

# 为什么需要自动化测试

优势：

  • 自动化测试可以替代大量的手工机械重复性操作，测试工程师可以把更多的时间花在更全面的用例设计和新功能的测试上
  • 自动化测试可以大幅提升回归测试的效率，非常适合敏捷开发过程
  • 自动化测试可以更好地利用无人值守时间，去更频繁地执行测试，特别适合现在非工作时间执行测试，工作时间分析失败用例的工作模式
  • 自动化测试可以高效实现某些手工测试无法完成或者代价巨大的测试类型，比如关键业务 7×24 小时持续运行的系统稳定性测试和高并发场景的压力测试等
  • 自动化测试还可以保证每次测试执行的操作以及验证的一致性和可重复性，避免人为的遗漏或疏忽

劣势：

  • 自动化测试并不能取代手工测试，它只能替代手工测试中执行频率高、机械化的重复步骤
  • 自动测试远比手动测试脆弱，无法应对被测系统的变化
  • 自动化测试用例的开发工作量远大于单次的手工测试，所以只有当开发完成的测试用例的有效执行次数大于等于 5 次时，才能收回自动化测试的成本
  • 手工测试发现的缺陷数量通常比自动化测试要更多，并且自动化测试仅仅能发现回归测试范围的缺陷
  • 测试的效率很大程度上依赖自动化测试用例的设计以及实现质量，不稳定的自动化测试用例实现比没有自动化更糟糕
  • 实行自动化测试的初期，用例开发效率通常都很低，大量初期开发的用例通常会在整个自动化测试体系成熟，和测试工程师全面掌握测试工具后，需要重构
  • 业务测试专家和自动化测试专家通常是两批人，前者懂业务不懂自动化技术，后者懂自动化技术但不懂业务，只有二者紧密合作，才能高效开展自动化测试
  • 自动化测试开发人员必须具备一定的编程能力

# 自动化测试应用场景

# 需求稳定，不会频繁变更

需求不稳定，过高的需求变更频率会导致自动化测试用例的维护成本直线上升

# 研发和维护周期长，需要频繁执行回归测试

  • 软件产品比软件项目更适合自动化

    • 软件产品的生命周期一般都比较长，通常会有多个版本陆续发布，每次版本发布都会有大量的回归测试需求
    • 软件产品预留给自动化测试开发的时间也比较充裕，可以和产品一起迭代
    • 自动化测试用例的执行比高于 1:5，即开发完成的用例至少可以被有效执行 5 次以上时，自动化测试的优势才可以被更好地体现

  • 软件项目的自动化，需要根据项目具体情况而定

短期项目：以手工测试为主

中长期项目：对比较稳定的软件功能进行自动化测试，对变动较大或者需求暂时不明确的功能进行手工测试，最终目标是用 20% 的精力去覆盖 80% 的回归测试

# 需要在多平台上重复运行相同的测试场景

  • 对于 GUI 测试，同样的测试用例需要在多种不同的浏览器上执行
  • 对于移动端应用测试，同样的测试用例需要在多个不同的 Android 或者 iOS 版本上执行，或者是同样的测试需要在大量不同的移动终端上执行
  • 对于一些企业级软件，如果对于不同的客户有不同的定制版本，各个定制版本的主体功能绝大多数是一致的，可能只有个别功能有轻微差别，测试也是需要覆盖每个定制版本的所有测试

# 某些测试项目通过手工测试无法实现，或者手工成本太高

  • 性能测试
  • 压力测试

# 被测软件的开发较为规范，能够保证系统的可测试性

注意：某些用例的自动化必须要求开发人员在产品中预留可测试性接口

如：有些用户登录操作，需要图片验证码，开发人员需要提供绕开图片验证码的路径

# 测试人员已经具备一定的编程能力

存在的阻力：

  • 前期的学习成本，很难在短期内对实际项目产生实质性的帮助
  • 热衷于学习使用自动化测试技术，以至于他们的工作重点会发生错误的偏移，把大量的精力放在自动化测试技术的学习与实践上，而忽略了测试用例的设计，这将直接降低软件整体的质量

# 不同阶段的自动化技术

在软件研发生命周期的各个阶段都有自动化测试技术的存在，并且对提升测试效率有着至关重要的作用

# 单元测试阶段

观点：

单元测试本身就是自动化的，它根据软件详细设计采用等价类划分和边界值分析方法设计测试用例，在测试代码实现后再以自动化的方式统一执行

广义理解：

单元测试阶段的「自动化」内涵不仅仅指测试用例执行的自动化，还应该包含以下五个方面：

  • 用例框架代码生成的自动化
    有些框架代码应该由自动化工具生成，单元测试开发者可以把更多的精力放在测试逻辑的覆盖和测试数据的选择上，从而大幅提高单元测试用例的质量和开发效率

  • 部分测试输入数据的自动化生成
    能够根据不同变量类型自动生成测试输入数据

例子说明：

函数原型：void fun（int* p, short b）

入参 int* p：生成 “空”和“非空”的两个指针 p

函数执行：观察执行情况

  • 自动桩代码的生成

桩代码（stub code）：是用来代替真实代码的临时代码

如：某个函数 A 的内部实现中调用了一个尚未实现的函数 B，为了对函数A的逻辑进行测试，那么就需要模拟一个函数 B，这个模拟的函数B实现就是所谓的桩代码

自动桩代码 ：自动化工具可以对被测试代码进行扫描分析，自动为被测函数内部调用的其他函数生成可编程的桩代码，并提供基于测试用例的桩代码管理机制，单元测试开发者只需重点关注桩代码内的具体逻辑实现，以及桩代码的返回值

抽桩：用真实函数代替原本桩代码函数的操作，就称为“抽桩”

  • 被测代码的自动化静态分析

目的：对代码进行静态扫描，识别出违反编码规则或编码风格的代码行

  • 测试覆盖率的自动统计与分析

单元测试用例执行结束后，自动化工具可以自动统计各种测试覆盖率，如代码行覆盖率、分支覆盖率、MC/DC 覆盖率等。这些自动统计的指标，可以衡量单元测试用例集合的充分性和完备性，提供适当增补测试用例以提高测试覆盖率的依据

# 代码级集成测试

代码级集成测试是指将已经开发完成的软件模块放在一起测试

关注点：软件模块之间的接口调用和数据传递

与单元测试异同点：

相似：

从测试用例设计和测试代码结构来看，代码级集成测试和单元测试非常相似，它们都是对被测试函数以不同的输入参数组合进行调用并验证结果

区别：

代码级集成测试中被测函数内部调用的其他函数必须是真实的，不允许使用桩代码代替，而单元测试中允许使用桩代码来模拟内部调用的其他函数

缺点：

代码级集成测试对测试框架的要求非常高，这个框架除了可以顺利装载自己的软件模块外，还必须能装载其他相互依赖的模块，做到被测软件模块可运行

应用场景：

主要应用在早期非互联网的传统软件企业，软件以“单体”应用居多，一个软件内部包含大量的功能，每一个软件功能都是通过不同的内部模块来实现的，那么这些内部模块在做集成的时候，就需要做代码级集成测试

现在的软件企业，尤其是互联网企业，追求的是系统复杂性的解耦，会去尽量避免“大单体”应用，采用 Web Service 或者 RPC 调用的方式来协作完成各个软件功能，基本不会去做代码级集成测试

# Web Service 测试

类型：

  • SOAP API

  • REST API

典型工具：

  • SoapUI

  • Postman

代码的 API 测试用例，通常包含三大步骤 ：

  • 准备 API 调用时需要的测试数据；

  • 准备 API 的调用参数并发起 API 的调用；

  • 验证 API 调用的返回结果

除了以上的用例执行外，还包括以下 4 个方面：

  • 测试脚手架代码的自动化生成

核心：如何设计测试用例的输入参数以及组合，以及在不同参数组合情况下 Response 的验证

  • 部分测试输入数据的自动生成

API 测试对应的是 API 的参数以及 API 调用的 Payload，数据生成的原则同样遵循边界值原则

  • Response 验证的自动化

关注点：返回状态码 、 Scheme 结构以及具体的字段值

核心思想：自动比较两次相同 API 调用的返回结果，并自动识别出有差异的字段值，比较过程可以通过规则配置去掉诸如时间戳、会话 ID（Session ID）等动态值

  • 基于 SoapUI 或者 Postman 的自动化脚本生成

# GUI 测试阶段

两大方向：

  • 传统 Web 浏览器：业内主流的开源方案采用 Selenium，商业方案采用 Micro Focus 的 UFT

  • 移动端原生应用：通常采用主流的 Appium，它对 iOS 环境集成了 XCUITest，对 Android 环境集成了 UIAutomator 和 Espresso

（完）