2.4黑盒测试和白盒测试（1）

2.4.1静态黑盒测试

白盒测试有静态和动态。黑盒测试一般是动态测试，事实上，目前基本不讲静态测试，讲的更多是评审，如代码评审、设计评审等等，运用的都是静态测试的方法

静态测试的对象：静态黑盒测试、开发文档、用户文档、管理文档：项目开发计划

需求测试进行的原因：用户的需求描述在不同人员的理解是不同的

需求文档的测试必要性：需求分析不够详细或偏离用户的需求，会对项目造成灭绝性的灾难。同时，用户的表达和需求工程师的理解有时并不会一致，用户所需和需求说明书上所描述的有偏差，50%以上的缺陷都是需求阶段被引入的

测试项目的周期：需求测试阶段、测试计划阶段、测试设计阶段、测试执行阶段以及总结评估阶段，共5个阶段。

需求评审的目的：让需求明确。让测试、开发、需求方对需求的理解一致

测试人员参与需求的评审的原因：

• 软件生命周期中，越晚发现的错误越难修改，修改成本越高
• 软件不同阶段有不同的专业人士配合完成，会有不同的理解，导致不同阶段的产物之间存在不一致的现象
• 使测试人员对需求的理解与需求分析人员一致
• 从可测试的角度努力发现用户需求说明书中不接测试的需求，从而提醒需求分析人员尽早修改
• 从测试人员的角度努力发现用户需求说明书中的不完整性，从而及时补充遗漏的用户需求

需求规格说明书的检查步骤：

• 获取最新版本、用户原始需求的文档
• 理解说明书所有需求项
• 对照说明书检查列表进行检查和记录
• 针对检查结果进行讨论，修订说明书

需求文档规范：正确性、必要性、优先级、明确性、可测性、一致性、可修改性

静态黑盒测试——用户文档测试

• 帮助用户正确地安装、使用和维护软件
• 改善可用性
• 提高可靠性
• 降低售后支持成本
• 用户文档测试现状
• 写帮助文档的人对产品整体不熟悉
• 缺少统一流程化管理
• 不予重视，时间紧张

区分产品需求说明书和需求规格说明书

产品说明书：是根据与现场时间客户进行沟通，吧系统要解决的业务逻辑、要实现的功能描述清楚，更宏观，重点是站在客户的角度讲产品的功能

产品规格说明书：是从业务规则讲起的，细一点偏向于人间的概要设计。把系统的约束、输入、输出和处理过程定义清楚，更具体，包含原型界面、业务接口、活动图等。