开发文档遗漏了某些重要内容或某些设计，不能全部满足既定的技术指标; 或存在逻辑错误、引用错误; 再或者引入了不必要的风险。这些问题在软件开发文档中屡见不鲜，而软件验证技术就是着力于解决这些问题，力争使开发文档臻于完善。

通过图1可以发现，软件缺陷错误绝大多数是在需求和设计阶段引入的，不清晰的需求分析、不合理的系统设计常常导致后续的开发活动困难重重。因此，需求验证和设计验证是软件验证的重点，对于排除软件缺陷而言是非常关键的。

软件需求验证

一份未经验证的《软件需求规格说明》（以下简称《需求说明》），极可能是包含着种种隐藏的软件缺陷，这些缺陷如果被带入到后续的开发阶段或当系统投入使用时才被发现，将会导致较高代价的返工，因为需求的变化常会导致系统设计和实现的相应变化，从而使系统重新经历编码、集成、系统测试、交付等阶段。需求的验证过程主要是检查需求规格说明，对该文档中定义的各需求项执行多种类型的验证。一般来说，需求验证主要包括以下内容：

1．有效性验证

有效性验证是指开发人员和用户应该对需求规格说明中各用户需求项进行认真地审核，以确保用户的需求被充分、正确地表达了出来，并且对于规格说明中提出的各项软件需求，必须保证它确实能够满足用户的相关需要、解决用户的问题。

2．一致性验证

一致性是指各需求项之间以及需求项和相应的规范或标准之间没有冲突，对同一个系统功能不应出现不同的描述或矛盾的约束。一致性验证主要包括四方面内容：一是验证各个需求项之间是否一致; 二是验证《需求说明》中规定的模型、算法和数值方法相互是否兼容; 三是验证《需求说明》中所采用的技术和方法是否与用户要求的技术及方法保持一致; 四是验证各需求项中涉及到的软硬件接口是否具有兼容性。

3．完备性验证

完备性验证是指检查需求文档是否包括用户需要的所有的功能、性能和约束，是否满足用户的所有要求。一个完备的需求文档应该对所有可能的状态、状态变化、转入条件、相关约束等都进行了完整、准确的描述。

完备性验证主要包括对《需求说明》六个方面的验证：是否包括了所有有意义的需求，并按优先级排序; 是否明确规定了哪些是绝对不能发生的故障或设计缺陷; 所有的需求项是否都被列入需求描述表，并被编号，能支持索引或回溯; 各图表、表格是否都有标号，各类专业术语及测量单位是否都给出相应的定义或引用的标准化文件; 时间关键性功能是否都被清晰地标识出来，对时间的具体要求是否作了规定; 是否包括了对所有异常的响应，尤其是对各种有效的、无效的输入值的响应规定，对各种操作模式下的环境条件、系统响应时间等是否都作了相应的规定。

4．可行性验证

可行性验证是指根据现有的软硬件技术水平和系统的开发预算、进度安排，对需求的可行性进行验证，以保证所有的需求都能实现。包括验证《需求说明》中定义的需求对软件的设计、实现、运行和维护而言是否是可行的，验证其规定的模型、算法和数值方法对于要解决的问题而言是否合适，验证约束性需求中所规定的质量属性是个别地还是成组地可以达到。

5．可验证性验证

可验证性是指为了减少客户和开发商之间可能产生的争议，系统需求应该能够通过一系列检查方法来进行验证，以确定交付的系统是否满足需要。它包括验证各个需求项是否能够通过测试软件产品和软件开发文档来证明这些需求项已经被实现; 各个需求项描述是否清楚、最好能量化; 每一个需求是否都对应于一个验证方法。

6．可跟踪性验证

可跟踪性是指需求的出处应该被清晰地记录，如每一项功能都能够追溯到要求它的用户需求或相关文件。主要验证每个需求项是否都具有惟一性并且被惟一标识，需求项定义描述中是否都明确地注明了该项需求源于上一阶段中哪个文档，以及是否可以从上一阶段的文档中找到需求定义中的相应内容。

7．可调节性验证

可调节性是指需求的变更不会对其他系统带来大规模的影响，主要验证需求项是否被组织成可以允许修改的结构，例如采用列表形式; 验证每个特定的需求的具体规定是否多于一次，有没有出现冗余的说明; 以及是否有一套规则用来在后续的软件生命周期里对《需求说明》进行维护。

8．其他方面的验证

另外，对《需求说明》的验证还包括编写格式是否符合相应的规范或标准（如GB 8567-88、或GJB1091-91），需求中提出的算法和方法方面的需求项是否有科技文献或其他文献作为基础，以及是否出现“待定”之类的不确定性词汇，如果出现，是否注明是何种原因导致的不确定性。

对于一个中型软件项目而言，以上验证项绝大多数是必须的，各测试团队可以根据项目的实际工程环境对此做裁减和细化。需求验证的执行应该遵循“策划→执行→检查→评估”的顺序完成。验证采取的形式可以是走查、审查、会议评审以及用户正式、非正式会议。不管采用哪种形式，上述验证的内容应该尽量覆盖到。

概要设计验证

图2 某桌面程序的开发流程

从图2可以看出，概要设计是软件开发过程中决定软件产品质量的关键阶段。这个阶段设计人员需要站在全局的高度，在比较抽象的层次上分析、对比多种可能的系统实现方案和多种可能的软件体系结构，从中选出最佳的方案和最合理的软件结构。概要设计验证可以确保《概要设计说明书》（以下简称《设计说明》）中所描述的软件概要设计在总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性、完整性，从而以保证用较低的成本开发出较高质量的软件系统。

1．验证设计系统在项目软件中所处的层次结构描述是否准确以及在后续设计阶段中的指导性作用

这里主要是验证《设计说明》中对所要设计的系统在整个项目软件中所处的地位、作用，及其与同级、上级系统之间的关系描述是否准确; 以及是否可以作为《详细设计规格说明》撰写的基础性文档。

2．验证系统描述是否具有可追溯性

重点对《设计说明》做以下验证：每一部分的设计是否都可以追溯到《需求说明》、《接口设计说明书》或其他开发文档; 非功能需求项（如接口需求等）是否已经分配到《概要设计规格说明》中; 不完整、易变动或潜在的需求项是否都进行了相应的设计分析，对各种设计限制是否做了全面的考虑; 模块的规格及大小划分是否和《需求说明》中的功能需求项以及约束性需求项之间保持一致。

3．验证总体设计是否合理

重点对《设计说明》进行以下验证: 设计目标描述是否明确清晰; 是否阐述了设计所依赖的运行环境，核对是否和《需求说明》中规定的运行环境一致; 业务逻辑是否准确、完备; 是否对不同的设计方案作了介绍并比较，是否有选择方案的结论，是否清楚阐述了方案选择的理由; 是否合理地划分了模块并对各模块之间的关系作了清晰的阐述; 系统设计结构和数据处理流程是否能满足软件需求规格说明中所要求的全部功能性需求。

4．接口设计是否合理

这方面主要是验证《设计说明》中用户接口设计是否正确全面，是否有单独的用户界面设计文档，是否包括硬件接口、软件接口、通信接口等的设计，以及是否描述了各类接口的功能、各接口与其他接口或模块之间的关系以及接口的设计是否具有可测试性。

5．验证模块及模块内部的设计是否合理

主要验证模块的划分是合适、模块与模块之间是否具有一定的独立性; 每个模块的功能和接口定义是否正确; 数据结构的定义是否正确，比如面向对象编程中的数据封装是否适当等; 模块内的数据流和控制流的定义是否正确。

6．验证概要设计是否包含相关属性设计

验证《设计说明》中是否有可靠性、安全性、可维护性、可移植性、可测试性等方面的设计，并且是否合理、有效。

7．验证计算机资源的利用和余量设计是否合理

这里考察《设计说明》是否对余量设计做了相应考虑。包括CPU的处理能力要求、内存的容量要求、外存储设备的容量要求等是否留有余量; 外存储设备的容量要求是否留有余量; 算法的效率是否可接受; 关键软件部件发生故障时是否有快速恢复能力等等。

各测试团队可以根据待测项目的规模进行裁减和细化。对于没有概要设计阶段的软件开发项目，此阶段的验证活动可以相应地略去。概要设计在执行中采取的形式以评审会为多，也可以采用非正式内部审查或专题会议的形式进行。由于概要设计的验证在很大程度上与软件需求规格说明的内容有关，建议聘请软件需求规格说明的起草人员和验证人员参与到概要设计的验证活动中来。(作者戴金龙E-mail:popodai@163.com)

下期话题预报：Junit和nunit分别是Java和.Net环境下的著名单元测试工具，下期测试专家戴金龙将就这两个工具在具体项目中的应用方法进行介绍。