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

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

  1. 业务/需求驱动测试;
  2. 产品质量风险驱动测试;
  3. 模型驱动测试;
  4. (系统)功能驱动测试;
  5. 设计驱动测试;
  6. (程序/代码)结构驱动测试;
  7. 统计/经验驱动测试

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

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

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

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

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

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

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

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

联系我
  • 上海市嘉定区曹安公路4800号同济大学软件学院
  • kerryzhu@vip.163.com