软件测试的七类驱动测试模式

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

　　·业务/需求驱动测试

　　·产品质量风险驱动测试

　　·模型驱动测试

　　·功能驱动测试(系统)

　　·设计驱动测试

　　·结构驱动测试(程序/代码)

　　·统计/经验驱动测试

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

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

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

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

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

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

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

　　以上内容为大家介绍了软件测试的七类驱动测试模式，本文由多测师亲自撰写，希望对大家有所帮助。