从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可操作性相对较强。但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。软件的生命周期可用图1的流程表示。

　　为了确保软件的质量，对图1的过程应进行严格的管理。虽然测试是在实现且经验证后进行的，实际上，测试的准备工作在分析和设计阶段就开始了。

1．测试的过程及组织

　　当设计工作完成以后，就应该着手测试的准备工作了，一般来讲，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。

　　在实现组将所开发的程序经验证后，提交测试组，由测试负责人组织测试，测试一般可按下列方式组织：

　　(1)首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。

　　(2)为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、集成测试和验收测试。

　　(3)代码会审：
　　代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组由组长，2～3名程序设计和测试人员及程序员组成。会审小组在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示错误的关键所在。实践表明，程序员在讲解过程中能发现许多自己原来没有发现的错误，而讨论和争议则进一步促使了问题的暴露。例如，对某个局部性小问题修改方法的讨论，可能发现与之有牵连的甚至能涉及到模块的功说明、模块间接口和系统总结构的大问题，导致对需求定义的重定义、重设计验证，大大改善了软件的质量。

　　(4)单元测试：
　　单元测试集中在检查软件设计的最小单位—模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。由于模块规模小、功能单一、逻辑简单，测试人员有可能通过模块说明书和源程序，清楚地了解该模块的I/O条件和模块的逻辑结构，采用结构测试（白盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使之对任何合理和不合理的输入都能鉴别和响应。高可靠性的模块是组成可靠系统的坚实基础。

　　(5)集成测试：
　　集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。

　　(6)验收测试：
　　验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

　　经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经验收后，将软件提交用户。

2．测试方法的应用

　　集成测试及其后的测试阶段，一般采用黑盒方法。其策略包括?/p>

　　(1)用边值分析法和（或）等价分类法提出基本的测试用例；
　　(2)用猜测法补充新的测试用例；
　　(3)如果在程序的功能说明中含有输入条件的组合，宜在一开始就用因果图法，然后再按以上（1）、（2）两步进行。

　　单元测试的设计策略稍有不同。因为在为模块设计程序用例时，可以直接参考模块的源程序。所以单元测试的策略，总是把白盒法和黑盒法结合运用。具体做法有两种：

　　a、先仿照上述步骤用黑盒法提出一组基本的测试用例，然后用白盒法作验证。如果发现用黑盒法产生的测试用例未能满足所需的覆盖标准，就用白盒法增补新的测试用例来满足它们。覆盖的标准应该根据模块的具体情况确定。对可靠性要求较高的模块，通常要满足条件组合覆盖或路径覆盖标准。

　　b、先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒法进行补充。

3．测试的人员组织

　　为了保证软件的开发质量，软件测试应贯穿于软件定义与开发的整个过程。因此，对分析、设计和实现等各阶段所得到的结果，包括需求规格说明、设计规格说明及源程序都应进行软件测试。基于此，测试人员的组织也应是分阶段的。

(1)软件的设计和实现都是基于需求分析规格说明进行的。

　　需求分析规格说明是否完整、正确、清晰是软件开发成败的关键。为了保证需求定义的质量，应对其进行严格的审查。审查小组由下列人员组成：
　　组长：1人
　　成员：包括系统分析员，软件开发管理者，软件设计、开发和测试人员和用户

(2)设计评审：

　　软件设计是将软件需求转换成软件表示的过程。主要描绘出系统结构、详细的处理过程和数据库模式。按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价，同时利用关系数据库的规范化理论对数据库模式进行审查。评审小组由下列人员组成：
　　组长：1人
　　成员：包括系统分析员、软件设计人员、测试负责人员各一人。

(3)程序的测试：

　　软件测试。是整个软件开发过程中交付用户使用前的最后阶段，是软件质量保证的关键。软件测试在软件生存周期中横跨两个阶段：通常在编写出每一个模块之后，就对它进行必要的测试（称为单元测试）。编码与单元测试属于软件生存周期中的同一阶段。该阶段的测试工作，由编程组内部人员进行交叉测试（避免编程人员测试自己的程序）。这一阶段结束后，进入软件生存周期的测试阶段，对软件系统进行各种综合测试。测试工作由专门的测试组完成，测试组设组长一名，负责整个测试的计划、组织工作。测试组的其他成员由具有一定的分析、设计和编程经验的专业人员组成，人数根据具体情况可多可少，一般3～5人为宜。

4．软件测试文件

　　软件测试文件描述要执行的软件测试及测试的结果。由于软件测试是一个很复杂的过程，同时也是设计软件开发其它一些阶段的工作，对于保证软件的质量和它的运行有着重要意义，必须把对它们的要求、过程及测试结果以正式的文件形式写出。测试文件的编写是测试工作规范化的一个组成部分。

　　测试文件不只在测试阶段才考虑，它在软件开发的需求分析阶段就开始着手，因为测试文件与用户有着密切的关系。在设计阶段的一些设计方案也应在测试文件中得到反映，以利于设计的检验。测试文件对于测试阶段工作的指导与评价作用更是非常明显的。需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时仍须用到测试文件。

(1)测试文件的类型

　　根据测试文件所起的作用不同，通常把测试文件分成两类，即测试计划和测试分析报告。测试计划详细规定测试的要求，包括测试的目的和内容、方法和步骤，以及测试的准则等。由于要测试的内容可能涉及到软件的需求和软件的设计，因此必须及早开始测试计划的编写工作。不应在着手测试时，才开始考虑测试计划。通常，测试计划的编写从需求分析阶段开始，到软件设计阶段结束时完成。测试报告用来对测试结果的分析说明，经过测试后，证实了软件具有的能力，以及它的缺陷和限制，并给出评价的结论性意见，这些意见即是对软件质量的评价，又是决定该软件能否交付用户使用的依据。由于要反映测试工作的情况，自然要在测试阶段内编写。

(2)测试文件的使用

　　测试文件的重要性表现在以下几个方面：

　　a、验证需求的正确性：测试文件中规定了用以验证软件需求的测试条件，研究这些测试条件对弄清用户需求的意图是十分有益的，

　　b、检验测试资源：测试计划不仅要用文件的形式把测试过程规定下来，还应说明测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。如果某个测试计划已经编写出来，但所需资源仍未落实，那就必须及早解决。

　　c、明确任务的风险：有了测试计划，就可以弄清楚测试可以做什么，不能做什么。了解测试任务的风险有助于对潜伏的可能出现的问题事先作好思想上和物质上的准备。

　　d、生成测试用例：测试用例的好坏决定着测试工作的效率，选择合适的测试用例是作好测试工作的关键。在测试文件编制过程中，按规定的要求精心设计测试用例有重要的意义。

　　e、评价测试结果：测试文件包括测试用例，即若干测试数据及对应的预期测试结果。完成测试后，将测试结果与预期的结果进行比较，便可对已进行的测试提出评价意见。

　　f、再测试：测试文件规定的和说明的内容对维护阶段由于各种原因的需求进行再测试时，是非常有用的。
　　g、决定测试的有效性：完成测试后，把测试结果写入文件，这对分析测试的有效性，甚至整个软件的可用性提供了依据。同时还可以证实有关方面的结论。

(3)测试文件的编制

　　在软件的需求分析阶段，就开始测试文件的编制工作，各种测试文件的编写应按一定的格式进行。