2.4.1静态黑盒测试
白盒测试有静态和动态。黑盒测试一般是动态测试，事实上，目前基本不讲静态测试，讲的更多是评审，如代码评审、设计评审等等，运用的都是静态测试的方法
静态测试的对象：静态黑盒测试、开发文档、用户文档、管理文档：项目开发计划
需求测试进行的原因：用户的需求描述在不同人员的理解是不同的
需求文档的测试必要性：需求分析不够详细或偏离用户的需求，会对项目造成灭绝性的灾难。同时，用户的表达和需求工程师的理解有时并不会一致，用户所需和需求说明书上所描述的有偏差，50%以上的缺陷都是需求阶段被引入的
测试项目的周期：需求测试阶段、测试计划阶段、测试设计阶段、测试执行阶段以及总结评估阶段，共5个阶段。
需求评审的目的：让需求明确。让测试、开发、需求方对需求的理解一致
测试人员参与需求的评审的原因：
- 软件生命周期中，越晚发现的错误越难修改，修改成本越高
- 软件不同阶段有不同的专业人士配合完成，会有不同的理解，导致不同阶段的产物之间存在不一致的现象
- 使测试人员对需求的理解与需求分析人员一致
- 从可测试的角度努力发现用户需求说明书中不接测试的需求，从而提醒需求分析人员尽早修改
- 从测试人员的角度努力发现用户需求说明书中的不完整性，从而及时补充遗漏的用户需求
需求规格说明书的检查步骤：
- 获取最新版本、用户原始需求的文档
- 理解说明书所有需求项
- 对照说明书检查列表进行检查和记录
- 针对检查结果进行讨论，修订说明书
需求文档规范：正确性、必要性、优先级、明确性、可测性、一致性、可修改性
静态黑盒测试——用户文档测试
- 帮助用户正确地安装、使用和维护软件
- 改善可用性
- 提高可靠性
- 降低售后支持成本
- 用户文档测试现状
- 写帮助文档的人对产品整体不熟悉
- 缺少统一流程化管理
- 不予重视，时间紧张
区分产品需求说明书和需求规格说明书
产品说明书：是根据与现场时间客户进行沟通，吧系统要解决的业务逻辑、要实现的功能描述清楚，更宏观，重点是站在客户的角度讲产品的功能
产品规格说明书：是从业务规则讲起的，细一点偏向于人间的概要设计。把系统的约束、输入、输出和处理过程定义清楚，更具体，包含原型界面、业务接口、活动图等。