<转>七种测试驱动模式

本文转载自微信公众号：中国软件测试联盟

在进行软件测试时，我们都需要一个出发点，从哪里开始分析？测试设计是基于什么？简单说，就是什么驱动测试工作的进行？

基于对软件工程、产品质量和测试的理解，归纳出以下七类测试驱动模式。

1、业务/需求驱动测试

一个软件总是要解决用户的某类业务问题。业务驱动测试就是从用户的实际业务需求出发，分析业务目标、业务流程、用户角色、业务规则、业务发展等测试对象，

针对这些对象确定测试范围、测试方法和策略。测试是否充分，也是从业务流程和数据来衡量；软件系统能否充分满足业务需求，是业务/需求驱动测试最关切的问题，

基于需求的验证方法、基于用户场景的测试方法，可以归为这类测试。

2、产品质量风险驱动测试

根据产品质量模型：内部质量-->外部质量 --> 使用质量来进行测试，强调全生命周期消除产品质量风险，从代码评审、代码复杂度度量等工作开始，对内部质量进行评估

以暴露质量风险，然后逐步扩展到系统外部质量、用户使用质量的评估，持续揭示、反馈产品质量主要风险。在这类测试中，对产品质量的属性分析会比较透彻，

也强调静态测试，包括人工代码评审和设计评审、使用代码静态分析或检查工具。

3、模型驱动测试

针对现实问题进行抽象构建验证模型，如UML建模、有限状态机、Petri网、Kripke结构等，系统属性可用时序逻辑公式（如CTL，LTL）来描述。

更广泛的理解，决策表、因果图、Pair-wise等也属于测试建模。大规模的复杂应用系统的测试建模会受到很大挑战，随着软件技术和建模技术的发展和融合，这些问题会逐步得到解决。

但基于模型能自动生成测试用例和自动化脚本，能够更彻底地完成测试的自动化过程，而之前人们多数自动化测试局限于测试的执行，

需要开发和维护大量的测试脚本，手工比重不小，最多算半自动化。

4、（系统）功能驱动测试

许多人一谈到软件测试，就是功能测试、性能测试，这或多或少体现了“功能测试驱动”思想。

功能驱动测试，就是从系统功能特性出发，根据软件功能规格设计说明书（可能没有），针对每个功能进行验证，确定功能运行是否正常，是否和设计保持一致。

一般会将功能进行分解，分为子功能、子功能的子功能，形成功能点列表，针对功能点进行测试用例设计和执行。

5、设计驱动测试（DDT）

DDT受TDD启发，为测试事先进行分析与设计，测试是被设计驱动的。DDT具有下列这些特性：测试更灵活、更简单，消除重复工作，测试用例指导测试计划（和传统测试相反），

测试用例可转换成测试代码，包含业务需求测试和场景测试、控制器测试，测试对开发和测试团队都很有用。

关于设计驱动测试，已有专题论述的著作：设计驱动测试——让程序员更轻松地进行测试。

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

基本类似于：结构化测试、白盒测试。从程序结构来驱动测试，进行程序结构分析，逐步覆盖程序的各个部分及其关联关系，如基于组件测试、基于接口测试或基于API进行测试；

从代码结构进行测试，包括代码行覆盖、分支覆盖、基本路径覆盖等。结构驱动测试的充分性度量会更客观性，特别是基于代码覆盖率分析，目前有大量工具支持。

7、统计/经验驱动测试

可以看作“经验软件工程”的组成部分，认可实际度量数据和经验比各种理论模型更有价值。通过软件测试过程中数据和经验的收集，进行统计分析、归纳整理，生成经验模型来开展测试。

上下文驱动测试、探索式测试、缺陷预防、错误猜测法等可归为这类，虽然不是很严谨，但都基本是从统计/经验来驱动测试。