软件测试的起点和源泉——七种测试驱动模式（方法论）

海鸥一飞

在进行软件测试时，总要有一个出发点吧？从哪里开始分析？测试设计是基于什么？简单地说，什么驱
动测试工作？这是一个基本问题，基于自己多年对软件工程、产品质量和测试等的理解，总结出七类测
试驱动模式（按推荐程度高低来排序）：

1)      业务/需求驱动测试；

2)      产品质量风险驱动测试；

3)      模型驱动测试；

4)      （系统）功能驱动测试；

5)      设计驱动测试；

6)      （程序/代码）结构驱动测试；

7)      统计/经验驱动测试

1. 业务/需求驱动测试：比较容易理解，一个软件总是要解决用户的某类业务问题。业务驱动测试就是从
用户的实际业务需求出发，分析业务目标、业务流程、用户角色、业务规则、业务数据、业务发展等测
试对象，针对这些对象确定测试范围、测试方法和策略。测试是否充分，也是从业务流程和数据来衡量。
软件系统能否充分满足业务需求，是业务/需求驱动测试最关切的问题，基于需求的验证方法、基于用户
场景的测试方法，可以归为这类测试。

2. 产品质量风险驱动测试：根据产品质量模型：内部质量-->外部质量 --> 使用质量来进行测试，强调
全生命周期消除产品质量风险，从代码评审、代码复杂度度量等工作开始，对内部质量进行评估以暴露
质量风险，然后逐步扩展到系统外部质量、用户使用质量的评估，持续揭示、反馈产品质量主要风险。
在这类测试中，对产品质量的属性分析会比较透彻，也强调静态测试，包括人工代码评审和设计评审、
使用代码静态分析或检查工具。

3. 模型驱动测试针对现实问题进行抽象构建验证模型，如UML建模、有限状态机、Petri网、Kripke结构等，
系统属性可用时序逻辑公式（如CTL，LTL）来描述。更广泛的理解，决策表、因果图、Pair-wise等也属于
测试建模。大规模的复杂应用系统的测试建模会受到很大挑战，随着软件技术和建模技术的发展和融合，
这些问题会逐步得到解决。但基于模型能自动生成测试用例和自动化脚本，能够更彻底地完成测试的自动
化过程，而之前人们多数自动化测试局限于测试的执行，需要开发和维护大量的测试脚本，手工比重不小，
最多算半自动化。

4.（系统）功能驱动测试：许多人一谈到软件测试，就是功能测试、性能测试，这或多或少体现了“功能
测试驱动”思想。功能驱动测试，就是从系统功能特性出发，根据软件功能规格设计说明书（可能没有）
，针对每个功能进行验证，确定功能运行是否正常，是否和设计保持一致。一般会将功能进行分解，分
为子功能、子功能的子功能，形成功能点列表，针对功能点进行测试用例设计和执行。

5.设计驱动测试（DDT）：DDT受TDD启发，为测试事先进行分析与设计，测试是被设计驱动的。DDT
具有下列这些特性：测试更灵活、更简单，消除重复工作，测试用例指导测试计划（和传统测试相反），
测试用例可转换成测试代码，包含业务需求测试和场景测试、控制器测试，测试对开发和测试团队都很
有用。

6.（程序/代码）结构驱动测试：基本类似于：结构化测试、白盒测试。从程序结构来驱动测试，进行程
序结构分析，逐步覆盖程序的各个部分及其关联关系，如基于组件测试、基于接口测试或基于API进行测
试；从代码结构进行测试，包括代码行覆盖、分支覆盖、基本路径覆盖等。结构驱动测试的充分性度量
会更客观性，特别是基于代码覆盖率分析，目前有大量工具支持。

7.统计/经验驱动测试可以看作“经验软件工程”的组成部分，认可实际度量数据和经验比各种理论模型更
有价值。通过软件测试过程中数据和经验的收集，进行统计分析、归纳整理，生成经验模型来开展测试。
上下文驱动测试、探索式测试、缺陷预防、错误猜测法等可归为这类，虽然不是很严谨，但都基本是从
统计/经验来驱动测试。