【软件测试技术】ISO标准流程与黑盒实战，提升缺陷发现率

前言

本文旨在为你构建一套完整的设计体系。我们将深入探讨：如何基于ISO/CMMI质量框架，让测试贯穿项目全生命周期；如何科学规划测试用例的粒度与数量；如何通过严谨的需求分析、输入输出定义及评审流程，打造无懈可击的用例文档。同时，我们将深度剖析黑盒测试的双刃剑——如何利用静态与动态技术最大化其价值，并清醒认识其数据穷尽的局限性。

1. 测试点的确认

• ISO质量体系
  • 在概要设计或详细设计中应该明确指出每个单元模块的测试要点、指标和方法
• CMMM质量体系
  • 在系统的用例模型描述中应明确指出每个用例
    模型的优先级及用例工作流程，每一个用例模
    型为一个测试点，用例模型中每一个测试需求
    至少应有两个测试用例
• 测试用例应该由测试设计员或分析设计员来制定，而不是普通测试员
• 测试点应由分析设计员确立，与测试人员
  无关
• 测试工作应该是项目立项之后，而不是代码开发完成之后
• 测试对象不仅仅是源代码，还包括需求分析、需求规格说明书、概要设计、概要设计说明书、详细设计、详细设计说明书、使用手册等各阶段的文档

2. 测试用例设计概述

2.1. 基本概念

• 测试用例是为了特定目的而设计的测试数据及与之相关的测试规程的一个特定集合，或称之为发现软件缺陷的最小测试执行单元
• 软件质量的好坏很大程度上取决于测试用
  例的数量和质量

2.2. 测试用例

• 测试用例的重要性：

  • 测试用例是测试人员执行测试的重要参考依据
  • 良好的测试用例具有很好的复用功能
  • 测试用例是在长期的测试实践中积累起来的
  • 测试用例的通过率是检验代码质量的例证（衡量代码质量的量化标准：测试用例的通过率、软件缺陷的数目）
  • 测试用例也是检验测试人员进度、工作量
    以及跟踪/管理测试人员的工作效率的因素
  • 测试用例不是任何人都能编写的（需要撰写者对于用户场景、功能规格说明、产品的设计以及程序/模块的结构都有比较透彻的了解）

• 测试用例数与软件规模的关系

  • 对软件质量的要求不同，则测试用例数与程序源代码规模比例不同
  • 软件规模不同，想要达到相同的软件质量，测试用例数与程序源代码规模比例也不同，大规模软件应该比小规模软件更高
    
    这里需要注意的是：

1. 对于单元测试来说，软件规模与测试用例数基本是成比例的
2. 对于集成测试和系统测试，测试用例数与软件规模并不是简单的正比关系（软件规模越大，模块间的关系越复杂，组合情况越多，测试用例数越大）

• 测试用例的设计难度也与软件规模有关系
  • 软件规模越大，测试用例的设计难度越大

2.3. 测试用例设计步骤

• 为测试需求确定测试用例

  • 测试需求：来源与规格说明文档，设计规格。测试计划中应该明确！
  • 测试需求编号
  • 每一个测试需求至少确定两个测试用例

• 为测试用例确定输入和输出

  • 输入是指用户在执行该测试用例时，由用户输入的与之交互的对象、字段和特定的数据值
  • 输出即预期结果，是指执行完该测试用例后得到的状态或数据
  • 在确定输入和输出参数时，采用以下原则：
    • 任何情况都要使用便边界析法
    • 必要时使用等价类划分，补充测试用例
    • 对照程序逻辑，检查测试用例的逻辑覆盖度
    • 如果程序的功能说明中含有输入条件的组合情
      况，则一开始就可以选择因果图法

• 编写测试用例

  • 测试用例编号为：TC_测试用例需求标识
  • 测试目标状态和测试数据状态：执行此测试用例前系统应具备的状态
  • 输入
  • 输出

• 测试用例的书写规范

  • 主要元素如下：
    • 标识符：每个测试用例应有一个唯一的标识，作为引用的基本元素
    • 测试项：测试用例应该精准地描述出被测试项及其主要特征
    • 测试环境要求：表面该测试用例执行所需要的测试环境
    • 输入数据
    • 输出数据
    • 测试用例之间的关联

• 评审测试用例

  • 测试用例检查表
    • 是否每一个需求都有一个测试用例来验证
    • 是否每一个设计元素都有其对应的测试用例来验证
    • 或事件顺序，它能够产生唯一的测试目标行为？
    • 是否每一个测试用例都阐述了预期结果
    • 是否每一个测试用例都明确了初始测试目标状态和测试数据状态
    • 测试用例是否包含了所有单一边界
    • 测试用例是否包含了所有的业务数据流
    • 是否所有的测试用例名称、ID名称都与测试工程文件命名规约一致

• 跟踪测试用例

  • 参加人员：项目经理、系统分析员、测试设计员、测试员
  • 需求管理：需求→测试用例
  • 测试用例是否覆盖了需求：需求→测试需求→测试用例
  • 测试用例执行率、通过率：测试用例→测试用例执行结果

3. 测试用例设计技术

3.1. 黑盒测试用例设计技术

3.1.1. 黑盒测试的概念

• 黑盒测试是在程序接口进行的测试，检查程序功能是否符合规格说明书
• 能够接受适当的输入，输出正确信息
• 并且保证外部信息的完整性

黑盒测试依赖于测试环境下，应用的规格说明或者功能描述：

黑盒测试将程序看做一个黑盒子，完全不知道程序的内部结构和处理过程（测试员只需要知道软件能做什么即可）：

3.1.2. 黑盒测试的作用

• 黑盒测试技术主要是为了发现一下几类错误
  • 是否有不正确或者遗漏的功能
  • 在接口生，是否能正确接收输入，并输出正确的结果
  • 是否有数据结构信息或者外部信息访问错误
  • 性能上是否满足需求
  • 是否有初始化或终止性错误

3.1.3. 黑盒测试的局限

• 使用黑盒测试发现程序中的错误，需要在有可能的输入和输出中确定测试数据，来检查是否都能产生正确的输出，但这是不可能的：
  
• 一些外购的软件没有办法得到源程序，所以只能采用黑盒测试
• 黑盒测试依赖于需求规格说明，但是一些情况下，需求规格说明本身并非完全正确
• 第三方测试大多数采用黑盒测试

3.1.4. 静态黑盒测试

• 测试产品说明书属于静态黑盒测试（产品说明书是静态文档，而不是可执行程序，因此是静态的）
• 无论对于何种的产品说明书，都可以使用静态黑盒测试技术进行测试
• 通过询问软件的设计者和编制者，甚至可以测试没有写出来的产品说明书

1. 对产品说明书进行高级审查
   审查产品说明书的第一步不是要去找代码缺陷，而是在一个高度上审视，为了找出根本性的问题、遗漏之处。

2. 设身处地为用户着想
   第一次接触到需要审查的产品说明书时，就应该站在用户的角度，了解软件是否满足客户的需求。

3. 研究现有的标准和规范
   软件测试员需要检验的是软件产品中是否采用了正确的标准个规范。

4. 审查和测试同类软件
   了解软件最终结果的最佳方案是去研究同类软件。
   在审查中应该注意的问题：规模、复杂性、测试性、质量/可靠性。

5. 产品说明书的低级测试技术

• 产品说明书的属性检查清单：
  • 优秀的产品说明书应该具有八个属性：
    完整、准确、精确、一致、贴切、合理、代码无关、可测试
• 产品说明书用语检查清单
  • 在审查产品说明书时应该注意对于问题的描述：
    

3.1.5. 动态黑盒测试

不深入代码细节的测试，叫做动态测试（又称为行为测试）。它是动态的，因为程序在执行，但是为黑盒子，并不知道具体细节。

3.1.6. 黑盒测试用例设计技术

后面的内容我们我们用一片文章单独讲解。