背景

传统测试

一个标准的软件研发流程:

  1. 需求清晰
  2. 流程固化
  3. 开发有序
  4. 系统可测
  5. 测试时间充足

在标准的软件研发流程中,为了保证系统不出问题,我们往往做了大量的回归测试。

在最早的测试理论中,对回归测试的定义是这样的:“回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试作为软件生命周期的一个组成部分,在整个测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。内容通常是重复以前的全部或部分的相同测试”。

但在敏捷开发快速迭代的时代里,是没有足够的时间给测试去做一轮又一轮的回归测试的。那敏捷模式下的测试工作,要如何做到保证质量的同时并提升效率。书里初步给出了以下两个方案:

  1. 缩减回归测试的范围
  2. 依靠自动化测试

首先,我们看方案2:自动化测试。

自动化测试

在传统的瀑布式开发里,自动化测试的推行,是一种进步;而在敏捷研发模式里,自动化是必不可少的基础。

传统的自动化测试,通常指的是测试过程被自动化。即把手工测试的用例交给机器去做。

自动化的类型,可以分为以下几种:

  • 单元测试
  • 代码静态检查
  • 接口自动化测试
  • UI自动化测试
  • 性能测试

在项目实战过程中,这些测试类型都可能被用到。如UI自动化帮助回归,静态检查、接口测试等做到了人工测试无法测试到的场景。而这些自动化测试可以提前介入测试工作中,提交发现问题。

总结自动化测试的价值如下:

  1. 帮助回归,节省人力
  2. 构建人工测试无法构建的场景等,提高测试覆盖率
  3. 前置测试,让测试和开发并行,降低测试周期

但自动化测试从本质上来说,不过是按照人工设置的场景按部就班的去执行,即它本质上是一个测试工具。所以,我们要考虑的不是自动化测试,而是如何缩减回归测试的范围,让自动化测试发挥最大的价值。

探索 & 测试分析

在不懂代码的情况下,测试时范围的选择往往依赖于开发告诉你要测什么。如果开发只是加了个判断语句,出于安全考虑却让你把所有的功能回归了一遍。这些工作真的有必要吗?

如果这时我们懂得代码,自己去分析开发修改的点,发现真的只是加了个判断语句,再针对判断的 true or false 条件测试了对应的用例,测试工作就大大减少,同时也保证了项目的稳定。

测试分析:建立在对需求本身及对应的系统架构和实现细节的充分了解的基础上,通过对数据流、状态变化、逻辑时序、功能/性能/兼容性等方面进行分析,得出详细的测试关注点的过程。

基于需求的测试分析

分析对象:需求规格说明书

对需求进行分解,考虑需求本身,以及需求所影响的功能模块,从而得到测试范围。

分析基础

  • 对业务熟悉
  • 对用户使用场景了解

分析方法

  • 业务流程分析:描述业务的正向流程
  • 业务状态分析:描述业务对象的状态转换
  • 测试范围分析:需求本身模块/受影响的模块

对于这个方法,有经验的人可以对需求本身的功能模块做到很准确的分析,但对于受影响的功能模块,如果不了解开发的实现,则很难界定准确。

基于开发实现的测试分析

需要厘清两个问题:

  1. 用户/需求价值方向:测试是无穷尽的,想要在有限时间内做最优的测试,就要充分把握需求需求的价值方向,在测试策略和测试关注点方面做出正确的判断。如,支付类应用安全是第一位的,而通信类的应用性能才是第一位的。
  2. 架构/实现细节:代码的实现架构,实现细节其实就是产品的体现。当我们理解具体执行的逻辑,进行的操作,测试路径可以采用穷举路径来规避风险,提高质量和效率。

分析测试关注点:

功能测试

  • 涉及模块
  • 模块交互时序
  • 接口/类/函数设计
  • 实现细节

性能测试

  • 基于系统资源的性能测试分析
  • 基于响应时间的性能测试分析

接口测试

  • 是否具备可测接口,为什么要测及要测哪些
  • 是否有接口变更,变更影响范围和测试内容

稳定性、兼容性测试