第2章软件测试的策略与过程-课件.ppt

1、第二章 软件测试策略与过程2第2章 软件测试策略与过程2.1 软件测试的复杂性分析2.2 排除软件缺陷的手段2.3 软件测试方法与策略2.4 单元测试2.5 集成测试2.6 确认测试2.7 系统测试2.8 验收测试2.9 测试后的调试2.10 面向对象的软件测试3本章教学目标 理解软件测试的复杂性 理解软件测试的方法与策略 明确单元测试的主要任务和过程 明确集成测试的方法和确认测试的准则 明确系统测试的八个领域测试要点 明确验收测试的主要内容和相关配置42.1 软件测试的复杂性分析1、无法对程序进行完全测试 （1）测试所需要的输入量太大 （2）测试的输出结果太多 （3）软件实现的途径太多 （4

2、）软件规格说明没有一个客观标准2、测试无法显示潜在的软件缺陷和故障 通过软件测试只能报告软件已被发现的缺陷和故障，无法报告隐藏的软件故障。3、存在的故障现象与发现的故障数量成正比 结论：应当对故障集中的程序段进行重点测试5M1D1D2D3D4M2M3M4M5M6M7D5=20次循环次数01220独立路径数51+52+53+5211014(1百万亿)每个测试用例（考虑、执行、验证结果）5分钟共需测试时间10亿年无法进行完全测试的例子-16无法进行完全测试的例子-2程序PXYZ若X、Y为所有可能的整数 在字长32位机上测试X1、Y1 Z1 Xn、Yn Znn=232232=264 1.84 101

3、97软件测试的复杂性分析（续）4、不能修复所有的软件故障 原因：没有足够的进行修复；修复的风险较大；不值得修复;可不算做故障的一些缺陷；“杀虫剂现象”。结论：关键是要进行正确的判断、合理的取舍，根据风险分析决定哪些故障必须修复，哪些故障可以不修复。5、软件测试的代价 工作原则：就是如何将无边无际的可能性减小到一个可以控制的范围，以及如何针对软件风险做出恰当选择，去粗存精，找到最佳的测试量，使得测试工作量不多也不少，既能达到测试的目的，又能较为经济。8软件测试的复杂性分析（续）软软件件缺缺陷陷故故障障数数量量测试工作量测试工作量测试中测试中测试后测试后测试费用测试费用遗漏缺陷数目遗漏缺陷数目优化

4、测试量优化测试量图图2-1 测试工作量和软件缺陷数量之间的关系测试工作量和软件缺陷数量之间的关系92.2 排除软件缺陷的手段 软件测试 软件项目评审10软件测试 软件测试 测试在软件开发中占有重要地位 测试成本占总开发成本的近一半11软件开发成本分布软件类型开发成本按阶段分布%需求与设计实现测试控制软件462034航空航天软件342046操作系统331750科技计算软件442630商业应用软件44282812测试人员所占比例13实际产品中的情况TeamExchange 2000Windows 2000Program Manager25About 250Developer140About 170

5、0Tester350About 3200Tester/Dev2.5About 1.914需求分析设计走查概要设计设计评审详细设计编码代码走查单元测试集成测试确认测试测试评审需求评审单元测试计划软件项目评审回归测试系统测试15 T：测试 R：评审UT：单元测试 IT：集成测试ST：系统测试AT：验收测试引入消除传递RRRR需求设计编程测 试UT ITATSTR运行/维护T软件生存期中缺陷的引入、传递与消除16缺陷跟踪17缺陷的状态 Microsoft Fixed Duplicated Postponed By design Not repro Wont fix Athens Olympic Ga

6、mes System Open In Analysis Accepted Rejected Fixed Delivered Pending Closed Reopened Unresolved18根据微软的经验，每修复三到四个根据微软的经验，每修复三到四个Bug一般就一般就会产生一个新的会产生一个新的Bug。19测试对象 程序测试：发现程序中的缺陷测试数据程序P比较结果数据预期数据相符不符追查缺陷20测试对象 文档测试：发现文档中存在的各种错误，以及各种文档之间的逻辑不一致性等需求规格说明设计说明（概要与详细）程序（代码走查，编写的代码是否符合既定的规范和标准等，不是指可执行的二进制代码）测试

7、用例、测试计划、测试结果报告用户手册、安装/配置手册、帮助文档等 其他样本/范例，错误提示信息和产品支持信息等所有与软件产品有关联的部分都可成为被测试的对象！21测试计划测试用例测试程序测试建立可靠性模型排错评估测试结果预期结果修正的软件可靠性模型软件配置测试配置测试工具测试结果错误出错率回归测试软件测试信息流22为什么要实施测试评审PPlan 计划 DDo 实施CCheck 检验、审查AAction 措施、行动 软件开发中软件开发中：PSDP 软件开发计划 SRS 软件需求规格说明 D软件设计、实现、编程 C软件测试、软件评审 A解决测试和评审中发现的问题回答：测试是否按计划实施 测试是否充

8、分而有效地检验了功能、性能和使用要求体现PDCA循环APCD23APCDAPCDTestingP：制定测试计划D：执行测试C：测试评审A：解决测试评审发现的问题软件开发软件测试测试计划与测试评审的关系24需求分析概要设计详细设计编码单元测试集成测试确认测试系统测试决定软件与系统的配合关系测试与开发前期工作的关系25发现的错误数周周总缺陷数目不同阶段的缺陷数目测试查错曲线26生存期各阶段V、V&T活动系统测试分析设计编码维护安装测试单元测试验证确认系统测试 质量控制集成测试回归测试验收测试Do the thing rightDo the right thing271.需求分析阶段 制定本项目的V

9、V&T计划 设置基于需求的测试用例 对需求进行评审与分析 对用户手册初稿进行评审与分析2.概要设计阶段 修订VV&T计划 制定基于设计的测试步骤 对概要设计进行评审与分析3.详细设计阶段 设置基于设计的功能测试数据 对详细设计进行评审与分析软件生存期各阶段的VV&T活动284.程序编写和单元测试完成测试用例说明书进行单元测试进行集成测试5.安装进行系统测试进行验收测试6.运行和维护阶段软件评价软件修改评价回归测试（引自美国国家标准局信息处理标准FIPS PUB101）软件生存期各阶段的VV&T活动(续)29如何正确对待测试工作明确测试工作意义加强责任心，疏忽可能造成恶果学习实践钻研，积累经验，

10、努力提高业务水平处理好与编程人员关系30测试工作评估问题1.你单位是否有专人负责测试工作？2.你们是否有、是否用测试计划规范？3.你们是否有、是否用单元测试规程？4.你们是否有、是否用测试报告规范？5.测试过程（包括计划和实施）与整个开发过程是否并行开展？（测试在开发初期着手，在开发结束完成）6.测试能够确认规格说明得到正确的实现吗？7.除规格说明以外，你能否确认用户的期望也能满足吗？8.测试人员能验证开发的阶段（如需求和设计）的精确性和完全性吗？9.测试人员向开发人员报告缺陷以期进一步采取措施吗？10.在制定计划之前测试人员能估计业务风险吗？31测试工作评估问题(续)11.针对被测软件是否提

11、出了可度量的测试目标？12.如已提出，它与商业风险有关吗？13.测试中发现的缺陷是否做了纪录和总结，使其用于改进开发过程和测试过程？14.测试人员是否根据以前的工作经验判断可能的缺陷？15.是否有改进测试过程的办法？16.你为缺陷命名吗？17.是否利用缺陷记录、总结和事故数据来评价测试过程的有效性？18.是否采用度量（如千行代码缺陷数）来计划和评价测试过程？19.是否已建立了测试人员的培训制度？20.采用测试工具来支持测试过程吗？32不同等级的测试机构等级否个数状 态特 点117-20把测试工作当作艺术(art)u测试依赖于测试人员个人的技巧和创造性u对测试人员无指导，无要求u测试工作效果不稳

12、定，有时好，有时糟u顾客和用户不能靠测试的有效性判断质量213-16把测试工作当作技艺(craft)u有测试过程、规范、标准和测试计划u测试计划得不到实施u测试人员只热衷于找缺陷，报告开发人员u用户不信任测试过程，只好做验收测试39-12执行已确切定义的测试过程u测试过程已被定义，单位但未得到有效执行u测试工作针对规格说明，重视问题的需求u测试结束时没有提供表明被测软件能否投入使用的正式报告33不同等级的测试机构45-8先进的测试机构u有明确的测试目标，可优化利用测u试资源实现目标u重视测试过程薄弱环节的改进50-4最先进的测试机构u测试工作基于降低风险，测试人员u工作有效u测试得到度量，过程

13、得到很好定义u缺陷得到记录、分析和总结，且用u其改进过程u测试成本显著下降u顾客和用户相信测试过程，不依靠u验收测试取得满意产品342.3 软件测试方法与策略2.3.1 静态测试与动态测试2.3.2 黑盒测试与白盒测试2.3.3 软件测试过程2.3.4 软件测试原则35软件测试策略 什么是软件测试策略？是为软件工程过程定义的一个软件测试的模板，也就是把特定的测试用例方法放置进去的一系列步骤。软件测试策略包含的特征：（1）测试从模块层开始，然后扩大延伸到整个基于计算机的系统集合中。（2）不同的测试技术适用于不同的时间点。（3）测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。（4

14、）测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。36软件测试充分性准则 对任何软件都存在有限的充分测试集合。如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的。这一特性称为单调性。即使对软件所有成分都进行了充分的测试，也并不表明整个软件的测试已经充分了。这一特性称为非复合性。即使对软件系统整体的测试是充分的，也并不意味软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。软件测试的充分性应该与软件的需求和软件的实现都相关。软件越复杂，需要的测试数据就越多。这一特性称为复杂性。测试得越多，进一步测试所能得到的充分性增长就越少。这一特性称

15、为回报递减率。372.3.1 静态测试与动态测试1、静态测试 静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估。静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，也可以借助软件工具自动进行。静态测试方法也可利用计算机作为对被测程序进行特性分析的工具，但与人工测试方式有着根本区别。另一方面，因它并不真正运行被测程序，只进行特性分析，这又与动态方法不同。所以，静态方法常常称为“分析”，静态测试是对被测程序进行特性分析方法的总称。38静态测试与动态测试（续）代码检查代码检查 代码检查包括代码走查、桌面检查、代码审查等，主要检查代码和设计的一致性，代码对标准的遵循

16、、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面。代码检查的具体内容：变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等。代码检查的优点：在实际使用中，代码检查比动态测试更有效率，能快速找到缺陷，发现30%70%的逻辑设计和编码缺陷；代码检查看到的是问题本身而非征兆。代码检查的缺点：非常耗费时间，而且代码检查需要知识和经验的积累。39静态测试与动态测试（续）静态结构分析静态结构分析 静态结构分析主要是以图形的方式表现程序的内部结构。例如函数调用关系图、函数内部控制流图。其中：函数调用关系图以直观的图形方式描述一个应用程序中各个函数的调用和被调用关系；控制流图显示一个函

17、数的逻辑结构，由许多节点组成，一个节点代表一条语句或数条语句，连接结点的叫边，边表示节点间的控制流向。40静态测试与动态测试（续）代码质量度量代码质量度量 软件质量包括六个方面：功能性、可靠性、易用性、效率、可维护性和可移植性。软件的质量是软件属性的各种标准度量的组合。针对软件的可维护性，目前业界主要存在三种度量参数：Line复杂度、Halstead复杂度和McCabe复杂度。其中Line复杂度以代码的行数作为计算的基准。Halstead以程序中使用到的运算符与运算元数量作为计数目标（直接测量指标），然后可以据以计算出程序容量、工作量等。McCabe复杂度 一般称为圈复杂度，它将软件的流程图转

18、化为有向图，然后以图论来衡量软件的质量。41静态测试与动态测试（续）静态测试阶段的任务：（1）检查算法的逻辑正确性。（2）检查模块接口的正确性。（3）检查输入参数是否有合法性检查。（4）检查调用其他模块的接口是否正确。（5）检查是否设置了适当的出错处理。（6）检查表达式、语句是否正确，是否含有二义性。（7）检查常量或全局变量使用是否正确。（8）检查标识符的使用是否规范、一致。（9）检查程序风格的一致性、规范性。（10）检查代码是否可以优化，算法效率是否最高。（11）检查代码注释是否完整，是否正确反映了代码的功能。42静态测试与动态测试（续）静态测试可以完成以下工作：（1）发现下列程序的错误：错

19、用局部变量和全局变量；未定义的变量、不匹配的参数；不适当的循环嵌套或分支嵌套、死循环、不允许的递归；调用不存在的子程序，遗漏标号或代码。（2）找出以下问题的根源：从未使用过的变量；不会执行到的代码、从未使用过的标号；潜在的死循环。（3）提供程序缺陷的间接信息：所用变量和常量的交叉应用表；是否违背编码规则；标识符的使用方法和过程的调用层次。（4）为进一步查找做好准备。（5）选择测试用例。（6）进行符号测试。43静态测试与动态测试（续）2、动态测试动态方法的主要特征是：计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况即输入与输出的对应关系进行分析，以达到检测的目的。动态测试包括：（1

20、）功能确认与接口测试 （2）覆盖率分析 （3）性能分析 （4）内存分析442.3.2 黑盒测试和白盒测试 若测试规划是基于产品的功能，目的是检查程序各个功能是否能够实现，并检查其中的功能错误，则这种测试方法称为黑盒测试(Black-box Testing)方法。黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。它是一种从用户观点出发的测试，一般被用来确认软件功能的正确性和可操作性。若测试规划基于产品的内部结构进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分使用，则这种测试方法称为白盒测试(White-box Testing)方法。白盒测试又称为结构测试、逻辑驱动测试或

21、基于程序的测试，一般用来分析程序的内部结构。45黑盒测试和白盒测试（续）46黑盒测试和白盒测试（续）1、黑盒测试 黑盒测试的基本观点是：任何程序都可以看作是从输入定义域映射到输出值域的函数过程，被测程序被认为是一个打不开的黑盒子，黑盒中的内容（实现过程）完全不知道，只明确要做到什么。黑盒测试主要根据规格说明书设计测试用例，并不涉及程序内部构造和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。黑盒测试的特点：（1）黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以使用。（2）黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。47

22、黑盒测试和白盒测试（续）48黑盒测试和白盒测试（续）黑盒测试主要是为了发现以下几类错误：v是否有不正确或遗漏了的功能？是否有不正确或遗漏了的功能？v在接口上，输入能否正确地接受？能否输出正确的结果？在接口上，输入能否正确地接受？能否输出正确的结果？v是否有数据结构错误或外部信息访问错误？是否有数据结构错误或外部信息访问错误？v性能上是否能够满足要求？性能上是否能够满足要求？v是否有初始化或终止性错误？是否有初始化或终止性错误？黑盒测试的难点：在哪个层次上进行测试？黑盒测试的具体技术方法：边界值分析法 等价类划分法 因果图法 决策表法49黑盒测试和白盒测试（续）2、白盒测试 白盒测试将被测程序看

23、作一个打开的盒子，测试者能够看到被测源程序，可以分析被测程序的内部结构，此时测试的焦点集中在根据其内部结构设计测试用例。白盒测试要求是对某些程序的结构特性做到一定程度的覆盖，或者说这种测试是“基于覆盖率的测试”通常的程序结构覆盖有：语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 路径覆盖50黑盒测试和白盒测试（续）51黑盒测试和白盒测试（续）？X=2 y=2x Y=4 X=2Y=4未知等式与已知等式黑盒黑盒白盒白盒3、黑盒测试法和白盒测试法的比较、黑盒测试法和白盒测试法的比较52黑盒测试和白盒测试（续）黑盒测试：以用户的观点，从输入数据与输出数据的对应关系，即根据程序外部特性进行测试，而不考虑内

24、部结构及工作情况。黑盒测试技术注重于软件的信息域（范围），通过划分程序的输入和输出域来确定测试用例。若外部特性本身存在问题或规格说明的规定有误，则应用黑盒测试方法是不能发现问题的。白盒测试：只根据程序的内部结构进行测试。测试用例的设计要保证测试时程序的所有语句至少执行一次，而且要检查所有的逻辑条件。如果程序的结构本身有问题，比如说程序逻辑有错误或者有遗漏，那也是无法发现的。53黑盒测试和白盒测试（续）项目项目黑盒测试法黑盒测试法白盒测试法白盒测试法规划规划方面方面功能的测试功能的测试结构的测试结构的测试优点优点方面方面 能确保从用户的角度能确保从用户的角度出发进行测试出发进行测试 能对程序内部

25、的特定部位进能对程序内部的特定部位进行覆盖测试行覆盖测试缺点缺点方面方面无法测试程序内部特无法测试程序内部特定部位；当规格说明有定部位；当规格说明有误，则不能发现问题误，则不能发现问题无法检查程序的外部特性；无法检查程序的外部特性；无法对未实现规格说明的程无法对未实现规格说明的程序内部欠缺部分进行测试序内部欠缺部分进行测试测试测试方法方法 边界分析法边界分析法 等价类划分法等价类划分法 决策表测试决策表测试 语句覆盖，判定覆盖，语句覆盖，判定覆盖，条件覆盖，判定条件覆盖，判定/条件覆盖，条件覆盖，路径覆盖，循环覆盖，路径覆盖，循环覆盖，模块接口测试模块接口测试54黑盒测试和白盒测试（续）A A

26、只能用黑盒测试发现的错误只能用黑盒测试发现的错误C C只能用白盒测试发现的错误只能用白盒测试发现的错误B B用黑盒测试或白盒测试都能发现的错误用黑盒测试或白盒测试都能发现的错误D D用黑盒测试或白盒测试均无法发现的错误用黑盒测试或白盒测试均无法发现的错误A+BA+B能用黑盒测试发现的错误能用黑盒测试发现的错误B+CB+C能用白盒测试发现的错误能用白盒测试发现的错误A+B+C A+B+C 用两种测试能发现的错误用两种测试能发现的错误A+B+C+DA+B+C+D软件中的全部错误软件中的全部错误ABCD黑盒测试与白盒测试能够发现的错误552.3.3 软件测试过程单元单元测试测试单元单元测试测试单元单

27、元测试测试集成集成测试测试集成集成测试测试确认确认测试测试系统系统测试测试*这三个测试可能交叉与前后互换这三个测试可能交叉与前后互换被测模块被测模块被测模块被测模块被测模块被测模块设计信息设计信息单元单元 软件需求软件需求其它元素其它元素用户信息用户信息其它元素其它元素*验收验收测试测试*交付用户交付用户图2-2 软件测试的过程流程56软件测试过程（续）单元测试：针对每个单元的测试,以确保每个模块能正常工作为目标。集成测试：对已测试过的模块进行组装,进行集成测试。目的在于检验与软件设计相关的程序结构问题。确认（有效性）测试：是检验所开发的软件能否满足所有功能和性能需求的最后手段。系统测试：检验

28、软件产品能否与系统的其他部分（比如，硬件、数据库及操作人员）协调工作。验收（用户）测试：检验软件产品质量的最后一道工序。主要突出用户的作用，同时软件开发人员也应有一定程度的参与。57一个实用软件测试过程 一种简单实用的软件测试过程模型 POCERM 测试过程中必需的基本测试活动及其产生的结果 拟定软件测试计划(Plans)编制软件测试大纲(Outlines)设计和生成测试用例(test Case generation)实施测试(Execution)生成软件测试报告(software testing Reports)v软件问题报告软件问题报告SPR(Software Problem Report

29、)SPR(Software Problem Report)v测试结果报告测试结果报告(test result Reports)test result Reports)58一个实用软件测试过程（续）基本特性：（1）计划性:任务 人员 设备 时间 相关.（2）平行性:开发 编码|测试 再测试（3）完整性:计划+大纲+用例+SPRs+.（4）重用性:测试 再测试 回归测试 升级 多平台（5）可重复性:SPRs 用例 大纲 再现Bugs（6）周期性:test cycles,regression,update（7）可管理性:well structured and organized QE group+w

30、ell planned and prepared task59软件测试计划 一个大中型软件系统的测试必须经历一个相当复杂的测试过程，并且常常需要经历数月乃至史长时间，需要投入相当可观的人力和物力资源，所以针对整个项目的预定目标和可能的实际条件，对系统的测试过程事先进行认真的计划，软件测试计划可分为3个层次。1)概要测试计划:是软件项目实施计划中的一项重要内容，应当在软件开发初期，即需求分析阶段制定。这项计划应当定义被测试对象和测试目标;确定测试阶段和测试周期的划分;制定测试人员、软硬件资源和测试进度等方而的计划;规定软件测试方法、测试标准以及支持环境和测试工具，比如：语句覆盖率需达到95,3级

31、以上的错误改正率需95,所有决定不改正的“轻微”错误都必须经过专门的质量评审委员会同意等。60软件测试计划（续）2)详细测试计划:是针对子系统在特定的测试阶段所要进行的测试工作制定详细计划。它详细规定了测试小组的各项测试任务、测试策略、任务分配和进度安排等。3)测试人员的测试实施计划:是根据详细测试计划制定的测试者的测试具体实施计划。它规定了测试者在每一轮测试中负贡测试的内容、测试强度和工作进度等。测试实施计划是整个软件测试计划的组成部分，是检查测试实际执行情况的重要依据。61软件测试大纲 软件测试大纲是软件测试的依据。它明确详细地规定了在一次测试中针对系统的每一项功能或特性所必须完成的基木测

32、试项目和测试完成的标准。无论是自动测试还是手动测试，都必须满足测试大纲的要求。实际上，测试大纲是从测试的角度对被测对象的功能和各种特性的细化和展开。比如，针对系统功能的测试大纲是基于软件质量保证人员对系统需求规格说明书中有关系统功能定义的理解，将其逐一细化展开后编制而成的。因此，测试大纲不仅是软件开发后期测试的依据，而且在系统的需求分析阶段也是质量保证的重要文档和依据。62两者的区别 计划是组织管理文档，考虑的是组织架构、工作任务分配、工作量估计、人力物力资源的分配、进度的安排、风险的估计和规避、各任务通过准则等，并不涉及到技术层面的东西；测试大纲是技术文档，考虑的是测试需求的细化、自动化测试

33、框架的设计、测试数据和测试脚本的设计、测试用例设计的原则等，不需考虑组织管理方面的因素。631)在测试工作开始以前，不应设想程序中没有缺陷或找不出缺陷。（测试心理学）2)测试以前应预知测试的结果数据。3)尽可能避免测试自己写的程序。坚持独立测试原则，必要的情况下建立独立测试机构。4)测试用例应兼顾有效输入和无效输入。5)不仅要检验程序是否做了该做的事，还应检验是否做了不该做的事。6)测试的充分性。7)测试的有效性。8)限于人力、物力，测试工作适可而止。（测试经济学）2.3.4 软件测试的原则64软件测试的原则(续)9)保留一切测试用例。10)任何已测程序的变更都应重新进行测试。（回归测试）11

34、)测试是不完全的。（测试不完全）12)测试具有免疫性。（软件缺陷免疫性）13)测试是“泛型概念”。（全程测试）14)80-20原则。15)缺陷的必然性。16)软件测试的意义-事后分析。652.4 单元测试2.4.1 单元测试的主要任务2.4.2 单元测试的执行过程66软件测试的过程流程单元单元测试测试单元单元测试测试单元单元测试测试集成集成测试测试集成集成测试测试确认确认测试测试系统系统测试测试*这三个测试可能交叉与前后互换这三个测试可能交叉与前后互换被测模块被测模块被测模块被测模块被测模块被测模块设计信息设计信息单元单元 软件需求软件需求其它元素其它元素用户信息用户信息其它元素其它元素*验收

35、验收测试测试*交付用户交付用户67单元测试的基本概念 单元测试是对程序模块进行正确性检验的测试工作。单元测试的目标：验证开发人员所书写的编码是否可以按照其所设想的方式执行而产出符合预期值的结果，确保产生符合其需求的可靠的程序单元。符合需求的代码通常应该具备以下性质：正确性、清晰性、规范性、一致性、高效性68单元测试的误区 单元测试是一种浪费时间的工作。单元测试只能证明代码做了什么。我是一个很棒的程序员，是不是可以不进行单元测试？集成测试可以捕捉所有的BUG。单元测试的成本效率不高。69单元测试的主要任务 单元测试针对每个程序的模块，主要测试5个方面的问题：模块接口、局部数据结构、边界条件、独立

36、的路径和错误处理。70单元测试的主要任务（续）模块接口模块接口 这是对模块接口进行的测试，检查进出程序单元的数据流是否正确。模块接口测试必须在任何其它测试之前进行。模块接口测试至少需要如下的测试项目：（1）调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；（2）所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配；（3）是否修改了只做输入用的形式参数；（4）调用标准函数的参数在个数、属性、顺序上是否正确；（5）全局变量的定义在各模块中是否一致。71单元测试的主要任务（续）局部数据结构局部数据结构 在模块工作过程中，必须测试模块内部的数据

37、能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。对于局部数据结构，应该在单元测试中注意发现以下几类错误：（1）不正确的或不一致的类型说明。（2）错误的初始化或默认值。（3）错误的变量名，如拼写错误或书写错误。（4）下溢、上溢或者地址错误。72单元测试的主要任务（续）路径测试路径测试 在单元测试中，最主要的测试是针对路径的测试。测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。常见的错误有：误解的或不正确的算术优先级；混合模式的运算；错误的初始化；精确度不够精确；表达式的不正确符号表示。针对判定和条件覆盖，测试用例还要能够发现如下错误：不同数据类型的比较；

38、不正确的逻辑操作或优先级；应当相等的地方由于精确度的错误而不能相等；不正确的判定或不正确的变量；不正确的或不存在的循环终止；当遇到分支循环时不能退出；不适当地修改循环变量。73单元测试的主要任务（续）边界条件边界条件 边界测试是单元测试的最后一步，必须采用边界值分析方法来设计测试用例，认真仔细地测试为限制数据处理而设置的边界处，看模块是否能够正常工作。一些可能与边界有关的数据类型如数值、字符、位置、数量、尺寸等，还要注意这些边界的首个、最后一个、最大值、最小值、最长、最短、最高、最低等特征。在边界条件测试中，应设计测试用例检查以下情况：（1）在n次循环的第0次、1次、n次是否有错误。（2）运算

39、或判断中取最大值、最小值时是否有错误。（3）数据流、控制流中刚好等于、大于、小于确定的比较值是否出现错误。74单元测试的主要任务（续）出错处理出错处理 测试出错处理的重点是模块在工作中发生了错误，其中的出错处理设施是否有效。检验程序中的出错处理可能面对的情况有：（1）对运行发生的错误描述难以理解。（2）所报告的错误与实际遇到的错误不一致。（3）出错后，在错误处理之前就引起系统的干预。（4）例外条件的处理不正确。（5）提供的错误信息不足，以至于无法找到错误的原因。752.4.2 单元测试的执行过程 何时进行单元测试？单元测试常常是和代码编写工作同时进行的，在完成了程序编写、复查和语法正确性验证后

40、，就应进行单元测试用例设计。在单元测试时，如果模块不是独立的程序，需要设置一些辅助测试模块。辅助测试模块有两种：（1）驱动模块(Drive)用来模拟被测试模块的上一级模块，相当于被测模块的主程序。它接收数据，将相关数据传送给被测模块，启动被测模块，并打印出相应的结果。（2）桩模块(Stub)用来模拟被测模块工作过程中所调用的模块。它们一般只进行很少的数据处理。驱动模块和桩模块都是额外的开销，虽然在单元测试中必须编写，但并不需要作为最终的产品提供给用户。76单元测试的执行过程（续）被测模块、驱动模块和桩模块共同构成了一个如下图所示的单元测试的测试环境：测试用例测试用例被测模块被测模块驱动模块驱动

41、模块测试结果测试结果桩模块桩模块1桩模块桩模块2桩模块桩模块3桩模块桩模块n桩模块桩模块77单元测试和集成测试的关系 对象不同：单元测试是程序模块（详细设计），集成测试是模块（概要设计）以及模块组合；测试方法不同：单元测试主要使用基于代码的白盒，集成测试主要使用基于功能的黑盒测试；测试时间不同：集成测试在单元测试之后；测试内容不同：单元测试主要测试模块内部；集成测试主要测试模块之间接口；二者的界限趋向模糊。78单元测试和系统测试的关系 对象不同：单元测试是证明程序模块的正确，系统测试是证明系统是否满足用户的需求；出发点不同：单元测试主要从程序员的角度测试，系统测试主要从用户的角度测试；测试时间

42、不同：系统测试在单元测试之后；测试内容不同：单元测试主要测试模块内部，系统测试主要根据需求规格说明书进行；测试错误定位：单元测试定位容易可以并行，系统测试发现错误比较难定位；79单元测试经验总结 测试人员在进行测试的工作过程中，应该注意积累测试工作经验，这样可以缩短单元测试的时间，提高测试效果和效率。如：1、在做单元测试的过程中，要灵活选用测试用例设计技术，首先使用黑盒测试用例设计技术，然后根据相应的覆盖率统计再补充白盒测试用例。既减少了测试工作的重复，又保证了单元测试的完整性。2、应该尽量开发简单测试驱动代码，增强其可读性。最重要的是，单元测试代码中不能包含分支和逻辑语句，因为这意味着有多个

43、测试在同时进行。这样将会使测试代码变得难以理解和维护。80单元测试小结 通过单元测试，我们验证开发人员所书写的编码是可以按照其所设想的方式执行的，产出了符合预期值的结果。这就实现了单元测试的目的。相比后面阶段的测试，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复。从全程的费用来考虑，相比起那些复杂且旷日持久的集成测试，或是不稳定的软件系统来说，单元测试所需的费用是很低的。模块单元设计完毕之后的开发阶段就是单元测试。812.5 集成测试2.5.1 非增量式测试2.5.2 增量式测试2.5.3 不同集成测试方法的比较2.5.4 回归测试82集成测试应该考虑的问题1.在把各个模块连接起来

44、的时候，穿越模块接口的数据是否会丢失；2.各个子功能组合起来，能否达到预期要求的父功能；3.一个模块的功能是否会对另一个模块的功能产生不利的影响；4.全局的数据结构是否有问题；5.单个模块的误差积累起来，是否会有放大，从而达到不可接受的程度。832.5.1 非增量式测试 非增量式测试是采用一步到位的方法来构造测试：对所有模块进行个别的单元测试后，按照程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试。非增量式测试的缺点：当一次集成的模块较多时，非增量式测试容易出现混乱，因为测试时可能发现了许多故障，为每一个故障定位和纠正非常困难，并且在修正一个故障的同时，可能又引入了新的故障，新旧

45、故障混杂，很难判定出错的具体原因和位置。84非增量式测试 As3s4s5d2 Cd4 Ed5 Fd1 B s1d3 s2 DABCDEFABCDEF（1）程序结构图（3）集成测试示意图（2）单元测试示意图852.5.2 增量式测试增量式测试的集成是逐步实现的：逐次将未曾集成测试的模块和已经集成测试的模块（或子系统）结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。按照不同的实施次序，增量式集成测试又可以分为三种不同的方法：（1）自顶向下增量式测试 （2）自底向上增量式测试 （3）混合增量式测试86自顶向下增量式测试 自顶向下增量式测试表示逐步集成

46、和逐步测试是按照结构图自上而下进行的，即模块集成的顺序是首先集成主控模块（主程序），然后依照控制层次结构向下进行集成。从属于主控模块的按深度优先方式（纵向）或者广度优先方式（横向）集成到结构中去。深度优先方式的集成：首先集成在结构中的一个主控路径下的所有模块，主控路径的选择是任意的。广度优先方式的集成：首先沿着水平方向，把每一层中所有直接隶属于上一层的模块集成起来，直到底层。87自顶向下增量式测试（续）集成测试的整个过程由3个步骤完成：（1）主控模块作为测试驱动器。（2）根据集成的方式（深度或广度），下层的桩模块一次一次地被替换为真正的模块。（3）在每个模块被集成时，都必须进行单元测试。重复第

47、2步，直到整个系统被测试完成。实例 按照广度优先方式进行集成测试 实例 按照深度优先方式进行集成测试88自顶向下增量式测试（续）A B C D E F A S1 S2 S3 A B C D S4 S5 A B C D E F（1）（2）（3）广度优先方式广度优先方式89自顶向下增量式测试（续）A B C D E F A S1 S2 S3 A B S2 S3 E A B C S3 E（1）（2）（3）深度优先方式深度优先方式（4）90自底向上增量式测试 自底向上增量式测试表示逐步集成和逐步测试的工作是按结构图自下而上进行的，即从程序模块结构的最底层模块开始集成和测试。由于是从最底层开始集成，对于

48、一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经集成并测试完成，所以不再需要使用桩模块进行辅助测试。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。实例 采用自底向上增量式测试方法进行集成测试91自底向上增量式测试 A B C D E F d2 Cd1 Ed3 Fd4 B Ed5 F D A B C D E F92混合增量式测试 混合增量式测试是把自顶向下测试和自底向上测试这两种方式结合起来进行集成和测试。这样可以兼具两者的优点，而摒弃其缺点。常见的两种混合增量式测试方式：（1）衍变的自顶向下的增量式测试：基本思想是强化对输入/输出模块和引入新算法模块的测试，并自

49、底向上集成为功能相对完整且相对独立的子系统，然后由主模块开始自顶向下进行增量式测试。（2）自底向上-自顶向下的增量式测试：首先对含读操作的子系统自底向上直至根节点模块进行集成和测试，然后对含写操作的子系统做自顶向下的集成与测试。93集成测试方法 非增量测试 增量测试 自顶向下测试 广度优先 深度优先 自底向上测试 混合测试942.5.3 不同集成测试方法的比较 1、非增量式测试与增量式测试的比较 非增量式测试的方法是先分散测试，然后集中起来再一次完成集成测试。假如在模块的接口处存在错误，只会在最后的集成测试时一下子暴露出来。增量式测试是逐步集成和逐步测试的方法，把可能出现的差错分散暴露出来，便

50、于找出问题和修改。而且一些模块在逐步集成的测试中，得到了较多次的考验，因此，可能会取得较好的测试效果。结论：增量式测试要比非增量式测试具有一定的优越性。95不同集成测试方法的比较（续）2、自顶向下与自底向上增量式测试的比较 自顶向下增量式测试：优点在于它可以自然的做到逐步求精，一开始就能让测试者看到系统的框架。缺点是需要提供桩模块，并且在输入/输出模块接入系统以前，在桩模块中表示测试数据有一定困难。自底向上增量式测试：优点在于，由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，生成测试数据也无困难。缺点在于，直到最后一个模块被加进去之后才能看到整个程序（系统）的框架。96集成测