软件测试过程及方法指南
最近总有人询问测试计划的编写方法和步骤，如何合理的设计测试计划是每个测试经理 的责任，测试中需要关注的要素太多了，既有技术方面的考虑，也有管理方面的考虑，如何 才能设计出实用的测试计划呢？我根据自己的经验，理出一份软件测试计划编写指南，希望对大家有所启示，并同大家交流测试中的心得和方法。
1 前言
1.1 软件测试的目的
软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出错误， 那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测试目的是 为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。
不同的软件项目会有不同的测试目的；相同的软件项目，不同的时期也可能有不同测试 目的，可能是测试不同区域或是对同一区域的不同层次的测试。
软件测试：
①、软件测试是为了发现错误而执行程序的过程；
②、测试是为了证明程序有错，而不是证明程序无错误。
③、一个好的测试用例是在于它能发现至今未发现的错误；
④、一个成功的测试是发现了至今未发现的错误的测试。
这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目，查找不出错误的测试就是没有价值的，事实并非如此。
首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。
其次，没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
对于测试数据的动态积累可以给项目管理者展示出当前项目的实时状态，为科学的决策提供有力的保障，并且为今后的培训，考评，工作的检查等提供强有力的数据基础。
1.2 软件测试的复杂性和经济性
人们常常以为，开发一个程序是困难的，测试一个程序则比较容易。这其实是误解。设计测试用例是一项细致并需要高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。不论是黑盒测试方法还是白盒测试方法，由于测试情况数量巨大，都不可能进行彻底的测试。所谓彻底测试，就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。 “黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用， 才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。 “白盒”法是穷举路径测试，贯穿程序的独立路径数是天文数字，但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。所以说：“程序测试只能证明错误的存在，但不能证明错误不存在”。
在实际测试中，穷举测试工作量太大，实践上行不通，这就注定了一切实际测试都是不彻底的。当然就不能够保证被测试程序中不存在遗留的错误。软件工程的总目标是充分利用有限的人力和物力资源，高效率、高质量地完成测试。为了降低测试成本，选择测试用例应注意遵守“经济性”的原则。第一，要根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级；第二，要认真研究测试策略，以便能使用尽可能少的测试用例，发现尽可能多的程序错误。掌握好测试量是至关重要的，一位有经验的软件开发管理人员在谈到软件测试时曾这样说过：“不充分的测试是愚蠢的，而过度的测试是一种罪孽”。测试不足意味着让用户承担隐藏错误带来的危险，过度测试则会浪费许多宝贵的资源。
测试是软件生存期中费用消耗最大的环节。测试费用除了测试的直接消耗外，还包括其它的相关费用。能够决定需要做多少次测试的主要影响因素如下：
①、系统的目的
系统目的的差别在很大程度上影响所需要进行的测试的数量。那些可能产生严重后果的系统必须要进行更多的测试。
②、潜在的用户数量
一个系统的潜在用户数量也在很大程度上影响了测试必要性的程度。这主要是由于用户团体在经济方面的影响。
③、信息的价值
在考虑测试的必要性时，还需要将系统中所包含的信息的价值考虑在内，一个支持许多家大银行或众多证券交易所的客户机/服务器系统中含有经济价值非常高的内容。很显然这一系统需要比一个支持鞋店的系统要进行更多的测试。这两个系统的用户都希望得到高质量、无错误的系统，但是前一种系统的影响比后一种要大得多。因此我们应该从经济方面考虑，投入与经济价值相对应的时间和金钱去进行测试。
④、开发机构
一个没有标准和缺少经验的开发机构很可能开发出充满错误的系统。在一个建立了标准和有很多经验的开发机构中开发出来的系统中的错误不会很多，因此，对于不同的开发机构来说，所需要的测试的必要性也就截然的不同。 然而，那些需要进行大幅度改善的机构反而不大可能认识到自身的弱点。那些需要更加严格的测试过程的机构往往是最不可能进行这一活动的，在许多情况下，机构的管理部门并不能真正地理解开发一个高质量的系统的好处。
⑤、测试的时机
测试量会随时间的推移发生改变。在一个竞争很激烈的市场里，争取时间可能是制胜的关键，开始可能不会在测试上花多少时间，但几年后如果市场分配格局已经建立起来了，那么产品的质量就变得更重要了，测试量就要加大。测试量应该针对合适的目标进行调整。
1.3 文档介绍
1.3.1 本文档的受众
测试计划编写指南有两类潜在的受众。首先，测试经理使用它作为指导方针编写测试计划。测试计划编写完成后，将作为整个团队（包括开发人员和测试人员）沟通的基础。
1.3.2 文档更新
测试项目开始时，应该完成测试计划的大部分内容。项目开始后，由于测试情况有变化，可能导致测试计划文档变化。如果文档有明显的变化，必须在文档中添加变更历史来记载这些变化。
1.3.3 文档目的
测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。
本文档描述出了整个开发过程中测试工作的流程，不同的测试时期可以根据需要对本文档的一部分进行充实（如：单元测试阶段等），但是在结项后，本文档规定的各个时期的测试计划均需完整，以备检查。对于项目类产品，可根据实际情况参照执行。
1.4 测试工作流程
测试工作从产品立项后开始介入，贯穿于软件产品的整个生命周期。初期测试经理参与项目的需求评审，并以需求设计为标准设计系统测试的测试用例。当开发进入详细设计阶段时，测试经理根据测试的需要同开发经理讨论技术的实现方式，在允许的范围内，尽量使用方便今后测试工作开展的实现方式。同时此阶段测试经理开始设计集成测试的测试用例。详细设计评审通过后，开发人员开始进入编码阶段，同时，测试经理应同开发经理协调好进度，按照模块开发的时间规划，测试经理开始根据模块的接口规范设计灰盒测试用例，尽量保证模块级的测试可以同开发进度协调进行。编码完成后，测试人员协助开发人员进行集成测试，测试经理使用前期已经完成的集成测试方案对产品进行测试。集成测试完成后，由测试经理对集成测试的效果进行评估，对于合格的产品填写系统测试申请报告，向测试部正式申请进入系统测试阶段。系统测试完成后，由测试经理向测试部申请软件发行。当相关的产品化工作正式完成后，由测试部开据质量合格证书，产品正式发行。
以上概要的介绍了测试方法和测试原则，以及公司对于产品类项目的测试流程，以下将具体的给出各个测试阶段，相关测试计划的文档要求，文档中将给出关键的考察点，计划编制的技巧与说明，以便在书写测试计划的时候有章可循。
2 引言
2.1 编写目的
阐明编写测试计划的目的并指明读者对象。
2.2 项目背景
说明项目的来源、委托单位及主管部门。
2.3 定义
列出测试 计划中所用到的专门术语的定义和缩写词的原意。
2.4 参考资料
列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：项目的计划任务书、合同或批文；项目开发计划；需求规格说明书；概要设计说明书；详细设计说明书；用户操作手册；本测试计划中引用的其他资料、采用的软件开发标准或规范。
2.5 文档摘要
主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员（比如经理或开发项目的负责人）。
提示和技巧：
在写这一节时，考虑一下你的计划在那些地方可能会引起反对。这个计划跟以前的计划相比，有什么不同的地方。测试项目与系统开发计划的关系等。
使用列表的格式，可以将问题按重要程度罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在。
2.6 文档历史和变更
[作者] – [日期] – [文档的当前状态，上版本以来所作的主要变化]
3 管理
3.1 系统视图和目标
系统视图对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。系统目标是帮助实现系统视图的重要指标。系统视图和目标对实现整个项目计划来说是至关重要的。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。
通常情况下视图和项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。
提示和技巧：
为什么视图对客户是重要的？
你如何向客户表达这种视图？
你将做什么来保证你是在向实现视图的方向前进?
在你回答这些问题之后，你就可以将视图转换成测试导向的目标？
整个系统的总体运行框架什么？各个部分的运行目标是什么？
3.2 运行环境
需测试的软，硬件环境，有无特殊的要求。如有些设备是有使用时限的需注明，如果测试环境不能满足测试要求，如何解决等？
3.3 资源需求
3.3.1 培训需求
本节说明项目测试人员需要哪些培训。
提示和技巧：
对于新手需要先介绍测试系统，如果测试人员比较熟悉该系统，则需要说明新系统的功能。
是否进行自动测试。
测试人员要不要培训以编写自动化脚本。
3.3.2 硬件需求
本节说明测试人员需要的各种类型的硬件以及这个测试团队需要的硬件。
3.3.3 软件需求
本节说明测试人员需要使用的软件。
3.3.4 办公空间需求
本节说明需要多少办公空间。
3.4 风险分析
目前存在那些不确定因素，包括可预计的和不可预计的。系统开发和测试过程中，会有各种可能导致系统发布延迟，在计划中需要预先估计这些风险，并且提出相应的对付办法。
3.5 测试团队结构
这一节说明测试团队的结构和项目测试人员的数量。
提示和技巧：
查看开发计划确定那些功能需要最多资源。
在各个测试阶段确定需要多少测试人员，各需掌握那些技巧。
多少人做自动测试，是哪些人。
列出项目参与人员的联系方式包括 E-mail 和电话。
3.6 相关信息保存的位置
测试服务器的相关信息；
测试文档保存的位置；
测试工具保存的位置；
测试中需要使用的软硬件的存放地点；
Bug如何记录，存放的位置。
3.7 测试时间安排
包括主要时间点的安排，如各个测试阶段的开始，截至日期，产品预计发布日期等。
3.8 缺陷处理
测试过程中可衡量的是发现的缺陷的状况。因此缺陷的报告和管理必须写成书面文档。
3.8.1 Bug 数据库管理
提示和技巧：
谁负责创建数据库？
谁有权限增加数据库的帐号？
谁有权使用哪类帐号？
数据库使用过程中出了问题和谁联系？
谁负责数据库备份？
多长时间备份一次？
由谁使用数据库？
缺陷管理应该与开发部门的负责人一起讨论。
3.8.2 缺陷处理过程
提示和技巧：
解释缺陷报告和分配过程。
缺陷标题、测试环境应如何填写。
解释如何输入，解决，重新打开，关闭和重新即或一个缺陷。
让测试人员清楚一个缺陷从击活到解决的全过程。
缺陷必须指定由谁负责解决。
定义优先级、严重级别等。
在项目结束时，如何解决这些缺陷。
如果有Bug管理工具，只需遵照工具的流程执行。
3.9.测试过程控制
在测试过程中，通过对缺陷数据库进行分析可以确定测试的状态。另外，通过让测试人员填写测试工作周报，可以对项目进展状况进行反馈。
3.9.1 缺陷数据分析
提示和技巧：
在开发过程和稳定阶段是否有过多的未处理缺陷，这可能说明开发的资源不够，或者有其它问题。
如何确定项目中是否有过多的缺陷。
测试人员是否积极发现缺陷，或者过分积极。
在每个时间点上，系统是否稳定。
系统哪些部分的缺陷最集中。
在系统发行时修复了多少缺陷。
哪些类型的缺陷最普遍。
3.9.2 测试工作周报
提示和技巧：
周报中应包括哪些信息。
如何填写工作周报。
谁负责查看工作周报。
以上详细的描述了，测试过程中可能遇到的或者必须提前安排的工作内容，有一些项是要在工作过程中陆续充实的，有一些是需要提前给出解决办法的，在制定计划过程中，请依据实际情况进行书写。
4 测试计划
4.1 整体测试策略
本节的目的是说明计划中使用的基本的测试过程。
提示和技巧：
是否使用里程碑技术和在测试过程中验证每个模块？或者是什么都不做，只是普通的测试而已。
测试人员是否在项目开发初期就开始工作？或者测试人员只在系统开发完后，才开始测试。
是否明显的界定出单元，集成，系统，验收测试阶段？
自动测试工作是否进行？
对于像压力，性能，兼容性等的测试项目，放到那一个测试区间内，有什么质量要求？
4.2 测试范围
通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。
提示和技巧：
需要特别测试那些部分？
那些部分不需要测试，为什么？
测试人员是否需要测试内容以及相关部分？
是否要验证每个模块的稳定性？
是否有理论上应该测试的，但是测试环境无法进行测试的内容？
对于产品附带的文档，测试人员是否需要检查？
4.3 质量目标
围绕软件质量，有几种不同的说法。第一个是质量是一种绝对的标准，对所有的系统必须等同处理。事实上，质量是相对的而且是和产品相关的概念。例如，多媒体产品的质量目标倾向于精美的表示和适当的内容，而应用系统可能倾向于易用性、健壮性和适用于不同的任务。质量目标可能是动态的。在项目进行过程中，会由于市场压力、新的机会和功能改变而重新设定质量目标。
另一种有关软件质量的说法是，定义和衡量系统质量是测试部门一个部门的事。实际上，建立质量标准是所有职能部门共同努力的结果。测试、开发、系统使用部门、用户教育、系统支撑必须为建立和维护系统的质量标准做出自己的贡献。每个部门必须对自己最了解的部分做出相应的质量定义。例如，测试和开发部门对系统质量的衡量标准主要是健壮性和正确性。用户部门可能对易用性方面比较熟悉。
最后，质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具，应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如，系统是否能够正式发行？在代码完成后，应该修复那些缺陷？在系统完成后那种类型的测试是最合适的。
提示：
质量目标应该是一个确实可行的软件质量描述，在确定之前应该同相关人员达成一致的意见，不要等到发货的时候才发现大家对其的理解有分歧，这时测试人员会非常被动，在达成一致意见后，当开发人员和测试人员有分歧时，可以使用质量目标作为衡量的标准。
4.4 测试计划
一般情况下测试活动大致分成四个部分：单元测试，集成测试，系统测试，验收测试。下面具体介绍一下测试计划的书写方法，工作过程中可以依据实际情况进行删减和补充。
4.4.1 单元测试
单元测试是代码一级的测试，主要依赖于开发人员进行。
单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设计描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。
一、单元测试任务
单元测试任务包括：
（1）模块接口测试；
（2）模块局部数据结构测试；
（3）模块边界条件测试；
（4）模块中所有独立执行通路测试；
（5）模块的各条错误处理通路测试。
模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素：
（1）输入的实际参数与形式参数的个数是否相同；
（2）输入的实际参数与形式参数的属性是否匹配；
（3）输入的实际参数与形式参数的量纲是否一致；
（4）调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
（5）调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
（6）调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
（7）调用预定义函数时所用参数的个数、属性和次序是否正确；
（8）是否存在与当前入口点无关的参数引用；
（9）是否修改了只读型参数；
（10）对全程变量的定义各模块是否一致；
（11）是否把某些约束作为参数传递。
如果模块内包括外部输入输出，还应该考虑下列因素：
（1）文件属性是否正确；
（2）OPEN/CLOSE语句是否正确；
（3）格式说明与输入输出语句是否匹配；
（4）缓冲区大小与记录长度是否匹配；
（5）文件使用前是否已经打开；
（6）是否处理了文件尾；
（7）是否处理了输入/输出错误；
（8）输出信息中是否有文字性错误；
检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
（1）不合适或不相容的类型说明；
（2）变量无初值；
（3）变量初始化或省缺值有错；
（4）不正确的变量名（拼错或不正确地截断）；
（5）出现上溢、下溢和地址异常。
在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括：
（1）误解或用错了算符优先级；
（2）混合类型运算；
（3）变量初值错；
（4）精度不够；
（5）表达式符号错。
比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：
（1）不同数据类型的对象之间进行比较；
（2）错误地使用逻辑运算符或优先级；
（3）因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；
（4）比较运算或变量出错；
（5）循环终止条件或不可能出现；
（6）迭代发散时不能退出；
（7）错误地修改了循环变量。
一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：
（1）输出的出错信息难以理解；
（2）记录的错误与实际遇到的错误不相符；
（3）在程序自定义的出错处理段运行之前，系统已介入；
（4）异常处理不当；
（5）错误陈述中未能提供足够的定位出错信息。
边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。
二、单元测试过程
一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。
应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。
驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的集成测试方法。
提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。单元测试计划的编写应该含盖上述的内容，单形式不限，对于测试的数据应该有效的予以保留，为今后进行数据分析作准备。
4.4.2 集成测试
集成测试针对的是各个相关模块的组合测试，最终的目标是将整个系统正确的组合成功，没有明显的模块之间的匹配问题。
时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。集成测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行集成测试以便发现与接口有关的各种错误。
某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。下面讨论两种增量式集成方法。
一、自顶向下集成
自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。以下图为例，若选择了最左一条路径，首先将模块 M1，M2，M5 和 M8 集成在一起，再将 M6 集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。仍以下图为例，它首先把M2、M3 和M4 与主控模块集成在一起，再将M5和M6 和其他模块集资集成起来。
自顶向下集成测试的具体步骤为：
（1） 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；
（2）依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；
（3）每集成一个模块立即测试一遍；
（4）只有每组测试完成后，才着手替换下一个桩模块；
（5）为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。
从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。
自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行，下面专门讨论。
二、自底向上集成
自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。
自底向上集成测试的步骤分为：
（1）把低层模块组织成实现某个子功能的模块群（cluster）;
（2）开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；
（3）对每个模块群进行测试；
（4）删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。
从第一步开始循环执行上述各步骤，直至整个程序构造完毕。
自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向集成测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。
此外，在集成测试中尤其要注意关键模块，所谓关键模块一般都具有下述一或多个特征： ①对应几条需求；②具有高层控制功能；③复杂、易出错；④有特殊的性能要求。关键模块应尽早测试，并反复进行回归测试。
以上介绍了一些进行集成测试的具体方案，不同的项目，测试经理可以根据实际情况选择。但是在实施之前，必须给出实施的步骤和时间规划。
4.4.3 系统测试
系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能正常工作并完成所赋予的任务。下面简单介绍几类系统测试。
（1）验证测试
以前期的用户需求规格说明书的内容为依据，验证系统是否正确无误的实现了需求中的全部内容。
（2）强度测试
强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行，验证系统的健壮性是否可靠。
（3）性能测试
对于那些实时系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。
编辑评论意见 （田俊国）
测试和过程控制是构筑软件质量的两个重要环节，也是软件工程化的重要标志。然而，我国大多数中小型软件企业，对软件测试的重视还很不够, 媒体上介绍软件测试的文章也很少。因此，很多软件工程师对测试知之甚少，甚至对测试心存偏见，不少人认为测试工程师比开发工程师低一个档次。而这一点在国外正好相反，在美国，没有三年以上软件开发经验的人是不能做测试工程师的。
本文比较系统地介绍了软件测试的方方面面，有技术也有方法；有理论也有作者的实战体会；更可贵的是专业的测试理念贯穿全文，比如： 测试的目的是找错误，但不仅仅局限于找错误；测试是在软件开发过程的末尾进行的，但测试人员却要从需求分析阶段就介入项目组… …
文章深入浅出，通俗易懂， 的确是一篇不可多得的软件测试知识普及性文章。相信软件开发同行们会从中大受裨益，参加软件专业资格水平考试的朋友们更是不可不读。
编辑评论意见 （胡志华）
当我还是一名程序员的时候，我也曾为测试而焦头烂额，我也曾对测试员***难和不顾；当我作为测试员的角色时，也因无从下手而懊恼，面对测试计划也表示怀疑和不解；我也曾制定测试计划、编写测试用例，主持或参与对软件或网站的验收。相信我所遭遇的艰难，您也曾遭遇或者您也许会遭遇，在这个时候，我们都需要交流和学习，也许阅读这篇文章就是一个选择啊。
本文虽然旨在论述测试计划的编写，但是对于测试的其他方面也做了详细的介绍，例如测试的一些基本概念，测试的几种类型，测试过程的控制等。
