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

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

2) 产品质量风险驱动測试。

3) 模型驱动測试；

4) （系统）功能驱动測试。

5) 设计驱动測试。

6) （程序/代码）结构驱动測试。

7) 统计/经验驱动測试

1. 业务/需求驱动測试：比較easy理解，一个软件总是要解决用户的某类业务问题。业务驱动測试就是从用户的实际业务需求出发，分析业务目标、业务流程、用户角色、业务规则、业务数据、业务发展等測试对象。针对这些对象确定測试范围、測试方法和策略。

測试是否充分，也是从业务流程和数据来衡量。软件系统是否能充分满足业务需求，是业务/需求驱动測试最关切的问题，基于需求的验证方法、基于用户场景的測试方法，能够归为这类測试。

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

3. 模型驱动測试针对现实问题进行抽象构建验证模型，如UML建模、有限状态机、Petri网、Kripke结构等。系统属性可用时序逻辑公式（如CTL。LTL）来描写叙述。更广泛的理解。决策表、因果图、Pair-wise等也属于測试建模。

大规模的复杂应用系统的測试建模会受到非常大挑战，随着软件技术和建模技术的发展和融合，这些问题会逐步得到解决。但基于模型能自己主动生成測试用例和自己主动化脚本，可以更彻底地完毕測试的自己主动化过程，而之前人们多数自己主动化測试局限于測试的运行，须要开发和维护大量的測试脚本。手工比重不小。最多算半自己主动化。

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

5.设计驱动測试（DDT）：DDT受TDD启示，为測试事先进行分析与设计。測试是被设计驱动的。

DDT具有下列这些特性：測试更灵活、更简单，消除反复工作。測试用例指导測试计划（和传统測试相反）。測试用例可转换成測试代码，包括业务需求測试和场景測试、控制器測试，測试对开发和測试团队都非常实用。关于设计驱动測试，已有专题论述的著作：设计驱动測试——让程序猿更轻松地进行測试http://product.dangdang.com/23407007.html

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

7.统计/经验驱动測试能够看作“经验软件project”的组成部分，认可实际度量数据和经验比各种理论模型更有价值。

通过软件測试过程中数据和经验的收集，进行统计分析、归纳整理。生成经验模型来开展測试。上下文驱动測试、探索式測试、缺陷预防、错误推測法等可归为这类。尽管不是非常严谨，但都基本是从统计/经验来驱动測试。