摘要：测试活动不是软件开发后的一个阶段，测试的对象也不仅是程序本身。测试活动应贯穿于软件开发的整个过程，只有这样，才能更有效率地的开发出有质量保障的优质软件系统。

随着软件开发技术的发展，软件测试技术也开始得到人们越来越多的重视，但人们普遍的观念认为测试活动是在软件开发的中后期才需要介入的研发步骤，有的开发人员甚至认为测试活动不属于研发过程，而仅仅是软件开发完成后依赖黑盒测试…来保证软件产品质量的一个过程。事实证明，软件测试是软件开发过程中的重要阶段，是确保软件质量的关键，尤其越是早期的测试活动，对软件产品质量的影响越是事半功倍。因此，软件开发阶段的测试活动是软件开发中不容忽视的一个重要环节。

一、软件测试的概念

软件测试是发现错误的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例j，利用这些测试用例去运行程序，以发现程序错误的过程。

从实际测试过程来看，软件测试过程是由一系列不同的测试阶段所组成。软件开发阶段的测试可分为：需求分析审查、设计审查、代码审查、单元测试、集成测试和系统测试等。需求分析审查、设计审查、单元测试中的代码评审及各阶段测试用例的评审都是通过对相关文档或代码的走读活动来实现的，这种评审活动称之为静态测试。静态测试能发现文档中存在的问题（也只能通过静态测试实现），通过对文档存在问题的分析或其他软件评审方法来发现需求分析、软件设计等中的问题。它能有效地检查代码是否具有可读性和可维护性，是否遵守编程规范，包括代码风格、变量／对类的命名、注释行等。静态测试已被当做一种自动化的、主要的代码校验方法，它的查错和分析功能是其他方法所不能替代的。

单元测试、集成测试及系统测试等是通过运行软件来检验软件的动态行为和运行结果正确性的测试方法，它们称之为动态测试。

二、测试活动在软件开发各个阶段的应用与目标

1．需求分析审查

需求分析是对用户需求进行确认和整理后对用户的需求进行性能、安全性、可维护性等项的划分，并将其细化为多个实现点，将用户的需求与软件的设计目标进行关联，生成需求规格说明书。它不仅是系统测试和用户文档的基础，也是所有子系统项目规划、设计和编码的基础。因此，它描述的准确性至关重要，对其评审即静态测试活动是不可掉以轻心的。软件需求规格说明书的评审是由评审专家组在对其仔细研读的基础上，站在各自的角度全方位地查找缺陷的过程。主要看其是否尽可能完整地描述系统预期的外部行为和用户的可视化行为；在功能点的描述上是否具有二义性；在实现上是否具有可行性；通过会议方式将缺陷确认、整理、修改到评审专家组认可。

2．设计审查

软件设计分为概要设计和详细设计，它依据需求规格说明书对系统的具体实现进行描述。概要设计是站在较高的层面上将整个系统进行模块划分，并将各功能项尽可能合理地安排在各个模块中来实现；根据系统的复杂度，可在每个模块中再进行下一级子模块的划分。详细设计则深入到每一级子模块当中，涉及到每个功能的具体实现流程、使用的数据结构乃至函数级的具体实现流程。它不但要考虑是否能更好地完成需求规格中向用户承诺的性能，还要兼顾其可靠性等质量保障。对软件设计的审查是通过评审专家对设计文档进行预审后，在评审会议上与设计人员将问题一一确认来实现。

评审专家依据需求规格说明书审查设计是否覆盖到用户提出的每个功能点，对每个函数流程或伪代码进行逻辑与语句的审查，更重要的、也是最容易忽视的是要求评审专家要以自己的经验，重点对设计中使用的数据结构、函数执行效率、资源访问冲突风险等进行合理评估，以便尽早地把这些对系统开发有着颠覆性影响的问题在编码及单元测试之前排除。

3．代码审查

代码审查是通过代码走读的方式来实现的。代码走读是开发人员在对某个模块的代码（必须编译通过）依据设计说明书完成编码后，进行的代码评审活动。代码走读前要在内部统一标准，明确质量目标。评审中，除了看编码是否紧扣设计外，走读还应兼顾三个层面：第一个层可称之为单元走读，关注的是“单元”，一般是一个方法或一个类，需要查找代码层面的错误，比如数据库网络资源的回收、一些异常的捕捉、空指针的检查及关键字的使用是否正确等；第二个层面可称之为集成走读，关注的是接口和流程，包括传人的参数检查、返回值检查及流程能否顺利地进行和正确串联等；第三个层面可称之为系统走读，关注的是功能层面和业务逻辑，这时发现更多的应该是逻辑错误和功能缺陷。

当然，在走读过程中这三个层面不是截然分开的，很多时候是并行的、互相交织和渗透的。代码走读的另一个重要内容是看代码是否遵守编程规范引，是否具有可读性和可维护性，注释是否充足等。按编程规范编码对提高代码的可读性以及降低编码的出错率至关重要，在大型项目中，具备可读性、规范性的代码更是日后进行有效维护的保障。因此，代码走读不仅可以保证代码的质量，更能有效地促进整个项目的编码水平。

4．单元测试

单元测试是对软件中的基本组成单位进行测试，检验其函数的正确性（包括功能正常，输出正确）。

一般来说，单元测试用例的编写最早可以在设计评审完成后就启动，和编码可以同时进行。但如果在时间允许的情况下，单元测试用仞』的编写最好放在编码后进行，这样能更好地覆盖代码的各个分支。若是以设计文档为唯一的编写依据，那么对于代码走读时发现的缺陷将在用例评审中被再次发现，造成重复劳动，用例的维护期也将提前开始。

单元测试用例编写的目的是函数覆盖，覆盖的方法有：语句覆盖、分支覆盖、条件覆盖、条件组合覆盖和路径覆盖等。为了以最少的资源做最多的测试检查，首选路径覆盖的方法。路径覆盖是设计足够的测试用例，运行所测程序并覆盖程序中所有可能的路径。

5．集成测试

集成测试是软件系统在集成过程中所进行的测试。其主要目的是检查软件单位之间的接口是否正确。其接口主要包括通信协议、调用关系、与文件或数据库等第三方中间件的交互。

集成测试用例的编写要紧扣与程序相关的各个接口，使每类接口的数据流或控制流均通过接口，从而实现接口测试的完全性。注意：对同一数据流要分别进行正确数据流与错误数据流的用例设计，对边界值的输入最好有单独的用例。集成测试还应关注接口的性能问题，根据系统的性能需求还要设计相关的接口性能测试用例。集成测试的执行主要是借助测试工具——桩程序来实现。桩程序的编写最好由他人来完成，以防止一个人对接口定义理解有偏差而使意外发生。

6．系统测试

系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性以及性能等是否满足各系统的需要。换言之，系统测试就是对系统所提供的业务流程进行测试，同时关注软件的强壮性和易用性等。系统测试应该由若干个不同的测试组成，其目的是充分地运行系统，验证系统各部件是否都能正常工作，并完成所赋予的任务。除业务测试外，还包括：

（1）恢复测试主要检查系统的容错能力。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。如拔掉与系统外界通信的网线再插上时，系统各功能能否自动恢复。

（2）安全测试检查系统对非法侵入的防范能力。如测试人员用非法通信程序与系统通信，验证是否能被系统发现并制止。

（3）强度测试检查系统对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。如在CPU或内存使用率过高或硬盘空间过低时，系统能否有良好的自我保护能力。

（4）性能测试虽然集成测试包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地进行系统性能测试。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。

三、结束语

测试活动不是软件开发后的一个阶段，测试的对象也不仅是程序本身。测试活动应贯穿于软件开发的整个过程，只有这样，才能更有效率地的开发出有质量保障的优质软件系统。