从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可操作性相对较强。但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。软件的生命周期可用图1的流程表示。
为了确保软件的质量，对图1的过程应进行严格的管理。虽然测试是在实现且经验证后进行的，实际上，测试的准备工作在分析和设计阶段就开始了。
1．测试的过程及组织
当设计工作完成以后，就应该着手测试的准备工作了，一般来讲，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。
在实现组将所开发的程序经验证后，提交测试组，由测试负责人组织测试，测试一般可按下列方式组织：
(1)首先，测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。
(2)为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、集成测试和验收测试。
(3)代码会审：代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组由组长，2～3名程序设计和测试人员及程序员组成。会审小组在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基础上，召开代码会审会，程序员逐句讲解程序的逻辑，并展开热烈的讨论甚至争议，以揭示错误的关键所在。实践表明，程序员在讲解过程中能发现许多自己原来没有发现的错误，而讨论和争议则进一步促使了问题的暴露。例如，对某个局部性小问题修改方法的讨论，可能发现与之有牵连的甚至能涉及到模块的功说明、模块间接口和系统总结构的大问题，导致对需求定义的重定义、重设计验证，大大改善了软件的质量。
(4)单元测试：单元测试集中在检查软件设计的最小单位—模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。由于模块规模小、功能单一、逻辑简单，测试人员有可能通过模块说明书和源程序，清楚地了解该模块的I/O条件和模块的逻辑结构，采用结构测试（白盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使之对任何合理和不合理的输入都能鉴别和响应。高可靠性的模块是组成可靠系统的坚实基础。
(5)集成测试：集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。
(6)验收测试：验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，测试宣告结束，经验收后，将软件提交用户。
2．测试方法的应用
集成测试及其后的测试阶段，一般采用黑盒方法。其策略包括：
(1)用边值分析法和（或）等价分类法提出基本的测试用例；
(2)用猜测法补充新的测试用例；
(3)如果在程序的功能说明中含有输入条件的组合，宜在一开始就用因果图法，然后再按以上1、2两步进行。
单元测试的设计策略稍有不同。因为在为模块设计程序用例时，可以直接参考模块的源程序。所以单元测试的策略，总是把白盒法和黑盒法结合运用。具体做法有两种：
a、先仿照上述步骤用黑盒法提出一组基本的测试用例，然后用白盒法作验证。如果发现用黑盒法产生的测试用例未能满足所需的覆盖标准，就用白盒法增补新的测试用例来满足它们。覆盖的标准应该根据模块的具体情况确定。对可靠性要求较高的模块，通常要满足条件组合覆盖或路径覆盖标准。
b、先用白盒法分析模块的逻辑结构，提出一批测试用例，然后根据模块的功能用黑盒法进行补充。
3．测试的人员组织
为了保证软件的开发质量，软件测试应贯穿于软件定义与开发的整个过程。因此，对分析、设计和实现等各阶段所得到的结果，包括需求规格说明、设计规格说明及源程序都应进行软件测试。基于此，测试人员的组织也应是分阶段的。
(1)软件的设计和实现都是基于需求分析规格说明进行的。需求分析规格说明是否完整、正确、清晰是软件开发成败的关键。为了保证需求定义的质量，应对其进行严格的审查。审查小组由下列人员组成：
组长：1人
成员：包括系统分析员，软件开发管理者，软件设计、开发和测试人员和用户
(2)设计评审：软件设计是将软件需求转换成软件表示的过程。主要描绘出系统结构、详细的处理过程和数据库模式。按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价，同时利用关系数据库的规范化理论对数据库模式进行审查。评审小组由下列人员组成：
组长：1人
成员：包括系统分析员、软件设计人员、测试负责人员各一人。
