第2章软件测试的策略与过程课件.ppt
126页
第二章 软件测试策略与过程 第2章 软件测试策略与过程2.1 软件测试的复杂性分析2.2 排除软件缺陷的手段2.3 软件测试方法与策略2.4 单元测试2.5 集成测试2.6 确认测试2.7 系统测试2.8 验收测试2.9 测试后的调试2.10 面向对象的软件测试2 本章教学目标•理解软件测试的复杂性•理解软件测试的方法与策略•明确单元测试的主要任务和过程•明确集成测试的方法和确认测试的准则•明确系统测试的八个领域测试要点•明确验收测试的主要内容和相关配置3 2.1 软件测试的复杂性分析1、无法对程序进行完全测试 （1）测试所需要的输入量太大 （2）测试的输出结果太多 （3）软件实现的途径太多 （4）软件规格说明没有一个客观标准2、测试无法显示潜在的软件缺陷和故障 ——通过软件测试只能报告软件已被发现的缺陷和故障，无法报告隐藏的软件故障3、存在的故障现象与发现的故障数量成正比 ——结论：应当对故障集中的程序段进行重点测试4 M1D1D2D3D4M2M3M4M5M6M7D5<=20次循环次数012……20独立路径数51+52+53+……+521≈1014(1百万亿)每个测试用例（考虑、执行、验证结果）5分钟共需测试时间10亿年无法进行完全测试的例子-15 无法进行完全测试的例子-2程序PXYZ若X、Y为所有可能的整数 在字长32位机上测试X1、Y1 Z1．．． Xn、Yn Znn = 232232 = 264 1.84 10196 软件测试的复杂性分析（续） 4、不能修复所有的软件故障 ——原因：没有足够的进行修复；修复的风险较大；不值得修复;可不算做故障的一些缺陷；“杀虫剂现象”。
——结论：关键是要进行正确的判断、合理的取舍，根据风险分析决定哪些故障必须修复，哪些故障可以不修复 5、软件测试的代价 ——工作原则：就是如何将无边无际的可能性减小到一个可以控制的范围，以及如何针对软件风险做出恰当选择，去粗存精，找到最佳的测试量，使得测试工作量不多也不少，既能达到测试的目的，又能较为经济 7 软件测试的复杂性分析（续）软软件件缺缺陷陷故故障障数数量量测试工作量测试工作量测试中测试中测试后测试后测试费用测试费用遗漏缺陷数目遗漏缺陷数目优化测试量优化测试量图图2-1 测试工作量和软件缺陷数量之间的关系测试工作量和软件缺陷数量之间的关系8 2.2 排除软件缺陷的手段•软件测试•软件项目评审9 软件测试•软件测试 ● 测试在软件开发中占有重要地位● 测试成本占总开发成本的近一半10 软件开发成本分布软件类型开发成本按阶段分布%需求与设计实现测试控制软件462034航空航天软件342046操作系统331750科技计算软件442630商业应用软件44282811 测试人员所占比例12 实际产品中的情况TeamExchange 2000Windows 2000Program Manager25About 250Developer140About 1700Tester350About 3200Tester / Dev2.5About 1.913 需求分析设计走查概要设计设计评审详细设计编码代码走查单元测试集成测试确认测试测试评审需求评审单元测试计划软件项目评审回归测试系统测试14 T：测试 R：评审UT：单元测试 IT：集成测试ST：系统测试AT：验收测试引入消除传递RRRR需求设计编程测 试UT ITATSTR运行/维护T软件生存期中缺陷的引入、传递与消除15 缺陷跟踪16 缺陷的状态•Microsoft–Fixed–Duplicated–Postponed–By design–Not repro–Won't fix•Athens Olympic Games System–Open–In Analysis–Accepted–Rejected–Fixed–Delivered–Pending–Closed–Reopened–Unresolved17 根根据据微微软软的的经经验验，，每每修修复复三三到到四四个个Bug一一般般就就会产生一个新的会产生一个新的Bug。
18 测试对象•程序测试：发现程序中的缺陷测试数据程序P比较结果数据预期数据相符不符追查缺陷19 测试对象•文档测试：发现文档中存在的各种错误，以及各种文档之间的逻辑不一致性等–需求规格说明–设计说明（概要与详细）–程序（代码走查，编写的代码是否符合既定的规范和标准等，不是指可执行的二进制代码）–测试用例、测试计划、测试结果报告–用户手册、安装/配置手册、帮助文档等•其他–样本/范例，错误提示信息和产品支持信息等所有与软件产品有关联的部分都可成为被测试的对象！20 测试计划测试用例测试程序测试建立可靠性模型排错评估测试结果预期结果修正的软件可靠性模型软件配置测试配置测试工具测试结果错误出错率回归测试｝软件测试信息流21 为什么要实施测试评审P—Plan 计划 D—Do 实施C—Check 检验、审查A—Action 措施、行动 软件开件开发中中：： P—SDP 软件开发计划 SRS 软件需求规格说明 D—软件设计、实现、编程 C—软件测试、软件评审 A—解决测试和评审中发现的问题—回答：测试是否按计划实施 测试是否充分而有效地检验了功能、性能和使用要求—体现PDCA循环APCD22 APCDAPCDTestingP：制定测试计划D：执行测试C：测试评审A：解决测试评审发现的问题软件开发软件测试测试计划与测试评审的关系23 需求分析概要设计详细设计编码单元测试集成测试确认测试系统测试决定软件与系统的配合关系测试与开发前期工作的关系24 发现的错误数周周总缺陷数目不同阶段的缺陷数目测试查错曲线25 生存期各阶段V、V&T活动系统测试分析设计编码维护安装测试单元测试验证确认系统测试 质量控制集成测试回归测试验收测试Do the thing rightDo the right thing26 1.需求分析阶段–制定本项目的VV&T计划–设置基于需求的测试用例–对需求进行评审与分析–对用户手册初稿进行评审与分析2.概要设计阶段–修订VV&T计划–制定基于设计的测试步骤–对概要设计进行评审与分析3.详细设计阶段–设置基于设计的功能测试数据–对详细设计进行评审与分析软件生存期各阶段的VV&T活动27 4.程序编写和单元测试–完成测试用例说明书–进行单元测试–进行集成测试5.安装–进行系统测试–进行验收测试6.运行和维护阶段–软件评价–软件修改评价–回归测试（引自美国国家标准局信息处理标准FIPS PUB101）软件生存期各阶段的VV&T活动(续)28 如何正确对待测试工作１．明确测试工作意义２．加强责任心，疏忽可能造成恶果３．学习——实践——钻研，积累经验， 努力提高业务水平４．处理好与编程人员关系29 测试工作评估问题1.你单位是否有专人负责测试工作？2.你们是否有、是否用测试计划规范？3.你们是否有、是否用单元测试规程？4.你们是否有、是否用测试报告规范？5.测试过程（包括计划和实施）与整个开发过程是否并行开展？（测试在开发初期着手，在开发结束完成）6.测试能够确认规格说明得到正确的实现吗？7.除规格说明以外，你能否确认用户的期望也能满足吗？8.测试人员能验证开发的阶段（如需求和设计）的精确性和完全性吗？9.测试人员向开发人员报告缺陷以期进一步采取措施吗？10.在制定计划之前测试人员能估计业务风险吗？30 测试工作评估问题(续)11.针对被测软件是否提出了可度量的测试目标？12.如已提出，它与商业风险有关吗？13.测试中发现的缺陷是否做了纪录和总结，使其用于改进开发过程和测试过程？14.测试人员是否根据以前的工作经验判断可能的缺陷？15.是否有改进测试过程的办法？16.你为缺陷命名吗？17.是否利用缺陷记录、总结和事故数据来评价测试过程的有效性？18.是否采用度量（如千行代码缺陷数）来计划和评价测试过程？19.是否已建立了测试人员的培训制度？20.采用测试工具来支持测试过程吗？31 不同等级的测试机构等级否个数状 态特 点117-20把测试工作当作艺术(art)u测试依赖于测试人员个人的技巧和创造性u对测试人员无指导，无要求u测试工作效果不稳定，有时好，有时糟u顾客和用户不能靠测试的有效性判断质量213-16把测试工作当作技艺(craft)u有测试过程、规范、标准和测试计划u测试计划得不到实施u测试人员只热衷于找缺陷，报告开发人员u用户不信任测试过程，只好做验收测试39-12执行已确切定义的测试过程u测试过程已被定义，单位但未得到有效执行u测试工作针对规格说明，重视问题的需求u测试结束时没有提供表明被测软件能否投入使用的正式报告32 不同等级的测试机构45-8先进的测试机构u有明确的测试目标，可优化利用测u试资源实现目标u重视测试过程薄弱环节的改进50-4最先进的测试机构u测试工作基于降低风险，测试人员u工作有效u测试得到度量，过程得到很好定义u缺陷得到记录、分析和总结，且用u其改进过程u测试成本显著下降u顾客和用户相信测试过程，不依靠u验收测试取得满意产品33 2.3 软件测试方法与策略2.3.1 静态测试与动态测试2.3.2 黑盒测试与白盒测试2.3.3 软件测试过程2.3.4 软件测试原则Return34 软件测试策略•什么是软件测试策略？ ——是为软件工程过程定义的一个软件测试的模板，也就是把特定的测试用例方法放置进去的一系列步骤。
•软件测试策略包含的特征：（1）测试从模块层开始，然后扩大延伸到整个基于计算机的系统集合中2）不同的测试技术适用于不同的时间点3）测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的4）测试和调试是不同的活动，但是调试必须能够适应任何的测试策略35 软件测试充分性准则•对任何软件都存在有限的充分测试集合•如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的这一特性称为单调性•即使对软件所有成分都进行了充分的测试，也并不表明整个软件的测试已经充分了这一特性称为非复合性•即使对软件系统整体的测试是充分的，也并不意味软件系统中各个成分都已经充分地得到了测试这个特性称为非分解性•软件测试的充分性应该与软件的需求和软件的实现都相关•软件越复杂，需要的测试数据就越多这一特性称为复杂性•测试得越多，进一步测试所能得到的充分性增长就越少这一特性称为回报递减率36 2.3.1 静态测试与动态测试1、静态测试•静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估•静态测试包括代码检查、静态结构分析、代码质量度量等它可以由人工进行，也可以借助软件工具自动进行。
•静态测试方法也可利用计算机作为对被测程序进行特性分析的工具，但与人工测试方式有着根本区别另一方面，因它并不真正运行被测程序，只进行特性分析，这又与动态方法不同所以，静态方法常常称为“分析”，静态测试是对被测程序进行特性分析方法的总称37 静态测试与动态测试（续）静态测试阶段的任务：（1）检查算法的逻辑正确性2）检查模块接口的正确性3）检查输入参数是否有合法性检查4）检查调用其他模块的接口是否正确5）检查是否设置了适当的出错处理6）检查表达式、语句是否正确，是否含有二义性7）检查常量或全局变量使用是否正确8）检查标识符的使用是否规范、一致9）检查程序风格的一致性、规范性10）检查代码是否可以优化，算法效率是否最高11）检查代码注释是否完整，是否正确反映了代码的功能41 静态测试与动态测试（续）•静态测试可以完成以下工作：（1）发现下列程序的错误：错用局部变量和全局变量；未定义的变量、不匹配的参数；不适当的循环嵌套或分支嵌套、死循环、不允许的递归；调用不存在的子程序，遗漏标号或代码2）找出以下问题的根源：从未使用过的变量；不会执行到的代码、从未使用过的标号；潜在的死循环3）提供程序缺陷的间接信息：所用变量和常量的交叉应用表；是否违背编码规则；标识符的使用方法和过程的调用层次。
4）为进一步查找做好准备5）选择测试用例6）进行符号测试42 静态测试与动态测试（续）2、动态测试动态方法的主要特征是： ——计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况即输入与输出的对应关系进行分析，以达到检测的目的动态测试包括： （1）功能确认与接口测试 （2）覆盖率分析 （3）性能分析 （4）内存分析43 2.3.2 黑盒测试和白盒测试•若测试规划是基于产品的功能，目的是检查程序各个功能是否能够实现，并检查其中的功能错误，则这种测试方法称为黑盒测试(Black-box Testing)方法 ——黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试它是一种从用户观点出发的测试，一般被用来确认软件功能的正确性和可操作性•若测试规划基于产品的内部结构进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分使用，则这种测试方法称为白盒测试(White-box Testing)方法 ——白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试，一般用来分析程序的内部结构 44 黑盒测试和白盒测试（续）白盒测试白盒测试黑盒测试黑盒测试两种测试方法从完全不同的角度出发，两种测试方法从完全不同的角度出发，反映了测试思路的两方面情况，适用于反映了测试思路的两方面情况，适用于不同的测试阶段。
不同的测试阶段45 黑盒测试和白盒测试（续）1、黑盒测试•黑盒测试的基本观点是：任何程序都可以看作是从输入定义域映射到输出值域的函数过程，被测程序被认为是一个打不开的黑盒子，黑盒中的内容（实现过程）完全不知道，只明确要做到什么•黑盒测试主要根据规格说明书设计测试用例，并不涉及程序内部构造和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例•黑盒测试的特点：（1）黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以使用2）黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间46 黑盒测试和白盒测试（续）输入输入输入输入输出输出输出输出黑盒测试是在程序接口进行测试，它只是检查黑盒测试是在程序接口进行测试，它只是检查黑盒测试是在程序接口进行测试，它只是检查黑盒测试是在程序接口进行测试，它只是检查程序功能是否按照规格说明书的规定正常使用程序功能是否按照规格说明书的规定正常使用程序功能是否按照规格说明书的规定正常使用程序功能是否按照规格说明书的规定正常使用也被称为用户测试或功能测试也被称为用户测试或功能测试也被称为用户测试或功能测试也被称为用户测试或功能测试。
47 黑盒测试和白盒测试（续）•黑盒测试主要是为了发现以下几类错误：v是否有不正确或遗漏了的功能？是否有不正确或遗漏了的功能？v在接口上，输入能否正确地接受？能否输出正确的结果？在接口上，输入能否正确地接受？能否输出正确的结果？v是否有数据结构错误或外部信息访问错误？是否有数据结构错误或外部信息访问错误？v性能上是否能够满足要求？性能上是否能够满足要求？v是否有初始化或终止性错误？是否有初始化或终止性错误？•黑盒测试的难点：在哪个层次上进行测试？•黑盒测试的具体技术方法 ： 边界值分析法 等价类划分法 因果图法 决策表法48 黑盒测试和白盒测试（续）2、白盒测试•白盒测试将被测程序看作一个打开的盒子，测试者能够看到被测源程序，可以分析被测程序的内部结构，此时测试的焦点集中在根据其内部结构设计测试用例•白盒测试要求是对某些程序的结构特性做到一定程度的覆盖，或者说这种测试是“基于覆盖率的测试”•通常的程序结构覆盖有： 语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 路径覆盖49 黑盒测试和白盒测试（续）白盒测试需要白盒测试需要白盒测试需要白盒测试需要完全了解程序结构和处理过程，完全了解程序结构和处理过程，完全了解程序结构和处理过程，完全了解程序结构和处理过程，它按照程序内部逻辑测试程序，检验程序中它按照程序内部逻辑测试程序，检验程序中它按照程序内部逻辑测试程序，检验程序中它按照程序内部逻辑测试程序，检验程序中每条通路是否按预定要求正确工作。
每条通路是否按预定要求正确工作每条通路是否按预定要求正确工作每条通路是否按预定要求正确工作也被称也被称也被称也被称为程序员测试为程序员测试为程序员测试为程序员测试应用程应用程序序50 黑盒测试和白盒测试（续） ？？ X = 2 y=2x Y=4 X = 2Y=4未知等式与已知等式黑盒黑盒白盒白盒3、黑盒测试法和白盒测试法的比较、黑盒测试法和白盒测试法的比较51 黑盒测试和白盒测试（续）•黑盒测试： ——以用户的观点，从输入数据与输出数据的对应关系，即根据程序外部特性进行测试，而不考虑内部结构及工作情况 ——黑盒测试技术注重于软件的信息域（范围），通过划分程序的输入和输出域来确定测试用例 ——若外部特性本身存在问题或规格说明的规定有误，则应用黑盒测试方法是不能发现问题的 •白盒测试： ——只根据程序的内部结构进行测试 ——测试用例的设计要保证测试时程序的所有语句至少执行一次，而且要检查所有的逻辑条件 ——如果程序的结构本身有问题，比如说程序逻辑有错误或者有遗漏，那也是无法发现的52 黑盒测试和白盒测试（续）项目项目黑盒测试法黑盒测试法白盒测试法白盒测试法规划规划方面方面功能的测试功能的测试结构的测试结构的测试优点优点方面方面 能确保从用户的角度能确保从用户的角度出发进行测试出发进行测试 能对程序内部的特定部位进能对程序内部的特定部位进行覆盖测试行覆盖测试缺点缺点方面方面无法测试程序内部特无法测试程序内部特定部位；当规格说明有定部位；当规格说明有误，则不能发现问题误，则不能发现问题无法检查程序的外部特性；无法检查程序的外部特性； 无法对未实现规格说明的程无法对未实现规格说明的程序内部欠缺部分进行测试序内部欠缺部分进行测试测试测试方法方法 边界分析法边界分析法 等价类划分法等价类划分法 决策表测试决策表测试 语句覆盖，判定覆盖，语句覆盖，判定覆盖， 条件覆盖，判定条件覆盖，判定/ /条件覆盖，条件覆盖， 路径覆盖，循环覆盖，路径覆盖，循环覆盖， 模块接口测试模块接口测试53 黑盒测试和白盒测试（续）A A只能用黑盒测试发现的错误只能用黑盒测试发现的错误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黑盒测试与白盒测试能够发现的错误54 2.3.3 软件测试过程单元单元测试测试单元单元测试测试单元单元测试测试集成集成测试测试集成集成测试测试确认确认测试测试系统系统测试测试* * 这三个测试可能交叉与前后互换这三个测试可能交叉与前后互换被测模块被测模块被测模块被测模块被测模块被测模块设计信息设计信息单元单元 软件需求软件需求其它元素其它元素用户信息用户信息其它元素其它元素* * ……* * 验收验收测试测试* * 交付用户交付用户……图2-2 软件测试的过程流程55 软件测试过程（续）•单元测试：针对每个单元的测试,以确保每个模块能正常工作为目标。
•集成测试：对已测试过的模块进行组装,进行集成测试目的在于检验与软件设计相关的程序结构问题•确认（有效性）测试：是检验所开发的软件能否满足所有功能和性能需求的最后手段•系统测试：检验软件产品能否与系统的其他部分（比如，硬件、数据库及操作人员）协调工作•验收（用户）测试：检验软件产品质量的最后一道工序主要突出用户的作用，同时软件开发人员也应有一定程度的参与56 一个实用软件测试过程•一种简单实用的软件测试过程模型 POCERM•测试过程中必需的基本测试活动及其产生的结果•拟定软件测试计划 (Plans)•编制软件测试大纲 (Outlines)•设计和生成测试用例 (test Case generation)•实施测试 (Execution)•生成软件测试报告 (software testing Reports)v软件问题报告软件问题报告SPR (Software Problem Report)SPR (Software Problem Report)v测试结果报告测试结果报告 ( (test result Reports)test result Reports)57 一个实用软件测试过程（续）•基本特性：（1）计划性: 任务 人员 设备 时间 相关...（2）平行性: 开发 编码 || 测试 再测试（3）完整性: 计划+大纲+用例+SPRs+...（4）重用性: 测试 再测试 回归测试 升级 多平台…（5）可重复性: SPRs 用例 大纲 再现Bugs（6）周期性: test cycles, regression, update（7）可管理性: well structured and organized QE group + well planned and prepared task58 软件测试计划•一个大中型软件系统的测试必须经历一个相当复杂的测试过程，并且常常需要经历数月乃至史长时间，需要投入相当可观的人力和物力资源，所以针对整个项目的预定目标和可能的实际条件，对系统的测试过程事先进行认真的计划，软件测试计划可分为3个层次。
1)概要测试计划:是软件项目实施计划中的一项重要内容，应当在软件开发初期，即需求分析阶段制定这项计划应当定义被测试对象和测试目标;确定测试阶段和测试周期的划分;制定测试人员、软硬件资源和测试进度等方而的计划;规定软件测试方法、测试标准以及支持环境和测试工具，比如：语句覆盖率需达到95％ , 3级以上的错误改正率需95％ ,所有决定不改正的“轻微”错误都必须经过专门的质量评审委员会同意等59 软件测试计划（续）2)详细测试计划:是针对子系统在特定的测试阶段所要进行的测试工作制定详细计划它详细规定了测试小组的各项测试任务、测试策略、任务分配和进度安排等3)测试人员的测试实施计划:是根据详细测试计划制定的测试者的测试具体实施计划它规定了测试者在每一轮测试中负贡测试的内容、测试强度和工作进度等测试实施计划是整个软件测试计划的组成部分，是检查测试实际执行情况的重要依据60 软件测试大纲•软件测试大纲是软件测试的依据它明确详细地规定了在一次测试中针对系统的每一项功能或特性所必须完成的基木测试项目和测试完成的标准无论是自动测试还是手动测试，都必须满足测试大纲的要求•实际上，测试大纲是从测试的角度对被测对象的功能和各种特性的细化和展开。
比如，针对系统功能的测试大纲是基于软件质量保证人员对系统需求规格说明书中有关系统功能定义的理解，将其逐一细化展开后编制而成的因此，测试大纲不仅是软件开发后期测试的依据，而且在系统的需求分析阶段也是质量保证的重要文档和依据61 两者的区别•计划是组织管理文档，考虑的是组织架构、工作任务分配、工作量估计、人力物力资源的分配、进度的安排、风险的估计和规避、各任务通过准则等，并不涉及到技术层面的东西；•测试大纲是技术文档，考虑的是测试需求的细化、自动化测试框架的设计、测试数据和测试脚本的设计、测试用例设计的原则等，不需考虑组织管理方面的因素 62 1)在测试工作开始以前，不应设想程序中没有缺陷或找不出缺陷测试心理学）2)测试以前应预知测试的结果数据3)尽可能避免测试自己写的程序坚持独立测试原则，必要的情况下建立独立测试机构4)测试用例应兼顾有效输入和无效输入5)不仅要检验程序是否做了该做的事，还应检验是否做了不该做的事6)测试的充分性7)测试的有效性8)限于人力、物力，测试工作适可而止测试经济学）2.3.4 软件测试的原则63 软件测试的原则(续)9)保留一切测试用例10)任何已测程序的变更都应重新进行测试。
回归测试）11)测试是不完全的测试不完全）12)测试具有免疫性软件缺陷免疫性）13)测试是“泛型概念” 全程测试） 14)80-20原则15)缺陷的必然性 16)软件测试的意义-事后分析64 2.4 单元测试2.4.1 单元测试的主要任务2.4.2 单元测试的执行过程Return65 软件测试的过程流程单元单元测试测试单元单元测试测试单元单元测试测试集成集成测试测试集成集成测试测试确认确认测试测试系统系统测试测试* * 这三个测试可能交叉与前后互换这三个测试可能交叉与前后互换被测模块被测模块被测模块被测模块被测模块被测模块设计信息设计信息单元单元 软件需求软件需求其它元素其它元素用户信息用户信息其它元素其它元素* * ……* * 验收验收测试测试* * 交付用户交付用户……66 单元测试的基本概念•单元测试是对程序模块进行正确性检验的测试工作•单元测试的目标：验证开发人员所书写的编码是否可以按照其所设想的方式执行而产出符合预期值的结果，确保产生符合其需求的可靠的程序单元符合需求的代码通常应该具备以下性质： 正确性、清晰性、规范性、一致性、高效性67 单元测试的误区•单元测试是一种浪费时间的工作。
•单元测试只能证明代码做了什么•我是一个很棒的程序员，是不是可以不进行单元测试？•集成测试可以捕捉所有的BUG•单元测试的成本效率不高68 单元测试的主要任务•单元测试针对每个程序的模块，主要测试5个方面的问题： ——模块接口、局部数据结构、边界条件、独立的路径和错误处理69 2.4.2 单元测试的执行过程•何时进行单元测试？单元测试常常是和代码编写工作同时进行的，在完成了程序编写、复查和语法正确性验证后，就应进行单元测试用例设计•在单元测试时，如果模块不是独立的程序，需要设置一些辅助测试模块辅助测试模块有两种： （1）驱动模块(Drive) 用来模拟被测试模块的上一级模块，相当于被测模块的主程序它接收数据，将相关数据传送给被测模块，启动被测模块，并打印出相应的结果 （2）桩模块(Stub) 用来模拟被测模块工作过程中所调用的模块它们一般只进行很少的数据处理 •驱动模块和桩模块都是额外的开销，虽然在单元测试中必须编写，但并不需要作为最终的产品提供给用户 75 单元测试的执行过程（续）•被测模块、驱动模块和桩模块共同构成了一个如下图所示的单元测试的测试环境：测试用例测试用例被测模块被测模块驱动模块驱动模块测试结果测试结果桩模块桩模块1桩模块桩模块2桩模块桩模块3桩模块桩模块n桩模块桩模块…76 单元测试和集成测试的关系•对象不同：单元测试是程序模块（详细设计），集成测试是模块（概要设计）以及模块组合；•测试方法不同：单元测试主要使用基于代码的白盒，集成测试主要使用基于功能的黑盒测试；•测试时间不同：集成测试在单元测试之后；•测试内容不同：单元测试主要测试模块内部；集成测试主要测试模块之间接口；•二者的界限趋向模糊。
77 单元测试和系统测试的关系•对象不同：单元测试是证明程序模块的正确，系统测试是证明系统是否满足用户的需求；•出发点不同：单元测试主要从程序员的角度测试，系统测试主要从用户的角度测试；•测试时间不同：系统测试在单元测试之后；•测试内容不同：单元测试主要测试模块内部，系统测试主要根据需求规格说明书进行；•测试错误定位：单元测试定位容易可以并行，系统测试发现错误比较难定位；78 单元测试经验总结 测试人员在进行测试的工作过程中，应该注意积累测试工作经验，这样可以缩短单元测试的时间，提高测试效果和效率如： 1、在做单元测试的过程中，要灵活选用测试用例设计技术，首先使用黑盒测试用例设计技术，然后根据相应的覆盖率统计再补充白盒测试用例既减少了测试工作的重复，又保证了单元测试的完整性 2、应该尽量开发简单测试驱动代码，增强其可读性最重要的是，单元测试代码中不能包含分支和逻辑语句，因为这意味着有多个测试在同时进行这样将会使测试代码变得难以理解和维护79 单元测试小结 通过单元测试，我们验证开发人员所书写的编码是可以按照其所设想的方式执行的，产出了符合预期值的结果这就实现了单元测试的目的。
相比后面阶段的测试，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复 从全程的费用来考虑， 相比起那些复杂且旷日持久的集成测试，或是不稳定的软件系统来说，单元测试所需的费用是很低的 模块单元设计完毕之后的开发阶段就是单元测试80 2.5 集成测试2.5.1 非增量式测试2.5.2 增量式测试2.5.3 不同集成测试方法的比较2.5.4 回归测试Return81 集成测试应该考虑的问题1.在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；2.各个子功能组合起来，能否达到预期要求的父功能；3.一个模块的功能是否会对另一个模块的功能产生不利的影响；4.全局的数据结构是否有问题；5.单个模块的误差积累起来，是否会有放大，从而达到不可接受的程度82 2.5.1 非增量式测试•非增量式测试是采用一步到位的方法来构造测试： ——对所有模块进行个别的单元测试后，按照程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试•非增量式测试的缺点： ——当一次集成的模块较多时，非增量式测试容易出现混乱，因为测试时可能发现了许多故障，为每一个故障定位和纠正非常困难，并且在修正一个故障的同时，可能又引入了新的故障，新旧故障混杂，很难判定出错的具体原因和位置。
83 非增量式测试 As3s4s5d2 Cd4 Ed5 Fd1 B s1d3 s2 DABCDEFABCDEF（1）程序结构图（3）集成测试示意图（2）单元测试示意图84 2.5.2 增量式测试增量式测试的集成是逐步实现的： ——逐次将未曾集成测试的模块和已经集成测试的模块（或子系统）结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题 按照不同的实施次序，增量式集成测试又可以分为三种不同的方法： （1）自顶向下增量式测试 （2）自底向上增量式测试 （3）混合增量式测试85 自顶向下增量式测试•自顶向下增量式测试表示逐步集成和逐步测试是按照结构图自上而下进行的，即模块集成的顺序是首先集成主控模块（主程序），然后依照控制层次结构向下进行集成从属于主控模块的按深度优先方式（纵向）或者广度优先方式（横向）集成到结构中去•深度优先方式的集成： ——首先集成在结构中的一个主控路径下的所有模块，主控路径的选择是任意的 •广度优先方式的集成： ——首先沿着水平方向，把每一层中所有直接隶属于上一层的模块集成起来，直到底层。
86 自顶向下增量式测试（续）•集成测试的整个过程由3个步骤完成： （1）主控模块作为测试驱动器 （2）根据集成的方式（深度或广度），下层的桩模块一次一次地被替换为真正的模块 （3）在每个模块被集成时，都必须进行单元测试 重复第2步，直到整个系统被测试完成 实例 按照广度优先方式进行集成测试 实例 按照深度优先方式进行集成测试87 自顶向下增量式测试（续） 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））广度优先方式广度优先方式88 自顶向下增量式测试（续） A B C D E F A S1 S2 S3 A B S2 S3 E A B C S3 E（（1））（（2））（（3））深度优先方式深度优先方式（（4））89 自底向上增量式测试•自底向上增量式测试表示逐步集成和逐步测试的工作是按结构图自下而上进行的，即从程序模块结构的最底层模块开始集成和测试•由于是从最底层开始集成，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经集成并测试完成，所以不再需要使用桩模块进行辅助测试。
在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到 实例 采用自底向上增量式测试方法进行集成测试90 自底向上增量式测试 A B C D E F d2 Cd1 Ed3 Fd4 B Ed5 F D A B C D E F91 混合增量式测试•混合增量式测试是把自顶向下测试和自底向上测试这两种方式结合起来进行集成和测试这样可以兼具两者的优点，而摒弃其缺点•常见的两种混合增量式测试方式：•（1）衍变的自顶向下的增量式测试：基本思想是强化对输入/输出模块和引入新算法模块的测试，并自底向上集成为功能相对完整且相对独立的子系统，然后由主模块开始自顶向下进行增量式测试•（2）自底向上-自顶向下的增量式测试：首先对含读操作的子系统自底向上直至根节点模块进行集成和测试，然后对含写操作的子系统做自顶向下的集成与测试92 集成测试方法•非增量测试•增量测试 自顶向下测试 广度优先 深度优先 自底向上测试 混合测试93 2.5.3 不同集成测试方法的比较•1、非增量式测试与增量式测试的比较•非增量式测试的方法是先分散测试，然后集中起来再一次完成集成测试。
假如在模块的接口处存在错误，只会在最后的集成测试时一下子暴露出来•增量式测试是逐步集成和逐步测试的方法，把可能出现的差错分散暴露出来，便于找出问题和修改而且一些模块在逐步集成的测试中，得到了较多次的考验，因此，可能会取得较好的测试效果•结论：增量式测试要比非增量式测试具有一定的优越性94 不同集成测试方法的比较（续）2、自顶向下与自底向上增量式测试的比较•自顶向下增量式测试： ——优点在于它可以自然的做到逐步求精，一开始就能让测试者看到系统的框架 ——缺点是需要提供桩模块，并且在输入/输出模块接入系统以前，在桩模块中表示测试数据有一定困难•自底向上增量式测试： ——优点在于，由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，生成测试数据也无困难 ——缺点在于，直到最后一个模块被加进去之后才能看到整个程序（系统）的框架95 集成测试与系统测试的区别1、测试对象 集成测试的测试对象是由通过了单元测试的各个模块所集成起来的组件而系统测试的测试对象，除了软件之外，还有计算机硬件及相关的外围设备、数据采集和传输机构、计算机系统操作人员等的整个系统。
2、测试时间 集成测试是介于单元测试和系统测试之间的测试 在测试时间上，先于系统测试96 集成测试与系统测试的区别 3、测试方法 集成测试通常会采用灰盒测试而系统测试通常使用黑盒测试 4、测试内容 集成测试的主要内容就是各个单元模块之间的接口，以及各个模块集成后所实现的功能而系统测试的主要内容就是整个系统的功能和性能97 集成测试与系统测试的区别 5、测试目的 集成测试的主要目的就是发现单元之间接口的错误，以及发现集成后的软件同软件概要设计说明不一致的地方而系统测试的主要目的就是，通过与系统需求定义相比较之后发现软件与系统定义不符合或矛盾的地方 6、测试角度 集成测试工作的开展更多的是站在测试工作人员的角度上系统测试工作的开展更多的是站在用户的角度来进行98 2.5.4 回归测试•什么是回归测试？ ——在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用或引发新的问题 ——在更广的环境里，回归测试就是用来保证（由于测试或其他原因的）改动不会带来不可预料的行为或另外的错误。
•回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行•回归测试集包括三种不同类型的测试用例： （1）能够测试软件的所有功能的代表性测试用例 （2）专门针对可能会被修改而影响软件功能的附加测试 （3）针对修改过的软件成分的测试99 2.6 确认测试1、确认测试的准则 确认测试也称为合格性测试，是检验所开发的软件是否能按用户提出的要求进行软件确认要通过一系列证明软件功能和要求一致的黑盒测试来完成 经过确认测试，应该为已开发的软件给出结论性评价：（1）经过检验的软件的功能、性能及其他要求均已满足需求规格说明书的规定，则可被认为是合格的软件2）经过检验发现与需求说明书有相当的偏离，得到一个各项缺陷清单100 确认测试（续）2、配置审查的内容 确认测试过程的重要环节就是配置审查工作其目的在于确保已开发软件的所有文件资料均已编写齐全，并得到分类编目，足以支持运行以后的软件维护工作 配置审查的文件资料包括用户所需的以下资料： （1）用户手册 （2）操作手册 （3）设计资料 ——如：设计说明书、源程序以及测试资料（测试说明书、测试报告）等101 2.7 系统测试•为什么要进行系统测试？ ——由于软件只是计算机系统中的一个组成部分，软件开发完成之后，最终还要和系统中的硬件系统、某些支持软件、数据信息等其他部分配套运行。
因此，在投入运行前要完成系统测试，以保证各组成部分不仅能单独的得到检验，而且在系统各部分协调工作的环境下也能正常工作•尽管每一个检验有特定的目标，然而所有的检测工作都要验证系统中每个部分均已得到正确的集成，并能完成指定的功能•严格的说，系统测试超出了软件工程范围通常这项工作并不由系统开发人员或系统开发组织来承担，而是由软件用户或软件开发机构委托独立测试机构来完成 102 恢复测试•恢复测试是通过各种手段，强制性地使软件出错，使其不能正常工作，进而检验系统的恢复能力•恢复测试包含的内容： ——如果系统恢复是自动的（由系统自身完成），则应该检验：重新初始化、检验点设置机构、数据恢复以及重新启动是否正确 ——如果这一恢复需要人为干预，则应考虑平均修复时间是否在限定的、可以接受的范围之内103 安全测试•安全测试的目的在于验证安装在系统内的保护机制能否在实际中保护系统且不受非法入侵，不受各种非法干扰•在安全测试中，测试者扮演着试图攻击系统的个人角色： — 尝试去通过外部的手段来获取系统的密码 — 使用可以瓦解任何防守的客户软件来攻击系统 — 把系统“瘫痪”，使得其他用户无法访问 — 有目的地引发系统错误，期望在恢复过程中侵入系统 — 通过浏览非保密的数据，从中找到进入系统的钥匙•系统的安全测试要设置一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。
104 强度测试•从本质上来说，强度测试（也称压力测试-Stress Testing）的目的是要检测非正常的情形，测试是想要破坏程序 强度测试需要在反常规数据量、频率或资源的方式下运行系统，以检验系统能力的最高实际限度 •举例： — 如果正常的中断频率为每秒5次，强度测试设计为每秒50次中断 — 把输入数据的量提高一个数量级来测试输入功能会如何响应 — 若某系统正常运行可支持200个终端并行工作，强度测试则检验1000个终端并行工作的情况 — 运行大量的消耗内存或其他系统资源的测试实例105 性能测试•性能测试用来测试软件在系统集成中的运行性能，特别是针对实时系统和嵌入式系统，仅提供符合功能需求但不符合性能需求的软件是不能被接受的•性能测试可以在测试过程的任意阶段进行，但只有当整个系统的所有成分都集成在一起后，才能检查一个系统的真正性能•性能测试常常和强度（压力）测试结合起来进行，而且常常需要硬件和软件测试设备，这就是说，常常有必要在一种苛刻的环境中衡量资源的使用（比如，处理器周期）106 正确性测试•正确性测试检查软件的功能是否符合规格说明•正确性测试的方法： ——枚举法，即构造一些合理输入，检查是否得到期望的输出。
测试时应尽量设法减少枚举的次数，关键在于寻找等价区间，因为在等价区间中，只需用任意值测试一次即可 ——边界值测试，即采用定义域或者等价区间的边界值进行测试因为程序设计容易疏忽边界情况，程序也容易在边界值处出错 107 可靠性测试•可靠性测试是从验证的角度出发，检验系统的可靠性是否达到预期的目标，同时给出当前系统可能的可靠性增长情况•对可靠性性测试来说，最关键的测试数据包括失效间隔时间，失效修复时间，失效数量，失效级别等根据获得的测试数据，应用可靠性模型，可以得到系统的失效率及可靠性增长趋势•可靠性指标有时很难测试，通常采用平均无故障时间或系统投入运行后出现的故障不能大于多少数量这些指标来对可靠性进行评估108 兼容性测试•软件兼容性测试是检测各软件之间能否正确地交互和共享信息，其目标是保证软件按照用户期望的方式进行交互，使用其它软件检查软件操作的过程•兼容性的测试通常需要解决以下问题： （1）新开发的软件需要与哪种操作系统、Web浏览器和应用软件保持兼容，如果要测试的软件是一个平台，那么要求应用程序能在其上运行 （2）应该遵守哪种定义软件之间交互的标准或者规范 （3）软件使用何种数据与其它平台、与新的软件进行交互和共享信息。
109 兼容性测试（续）软件兼容的实例：•从Web页面剪切文字，然后在文字处理程序中打开的文档中粘贴•从电子表格程序保存账目数据，然后在另一个完全不同的电子表格程序中读入这些数据•使图形处理软件在同一操作系统下的不同版本正常工作•使文字处理程序从联系人管理程序中读取姓名和地址，打印个性化的邀请函和信封•升级到新的数据库程序，读入现存所有数据库，并能够像老版本一样对其中的数据进行处理110 兼容性测试（续）•兼容性通常有4种——向前兼容与向后兼容、不同版本间的兼容、标准和规范、数据共享兼容 （1）向前兼容和向后兼容 向前兼容是指可以使用软件的未来版本，向后兼容是指可以使用软件的以前版本并非所有的软件都要求向前兼容和向后兼容，这是软件设计者需要决定的产品特性 使用文本文件可以对向前兼容和向后兼容作一个简单的演示：在Windows 98上用Notepad创建的文本文件，它可以向后兼容MS-DOS 1.0后的所有版本，它还可以向前兼容Windows 2000甚至以后的版本111 兼容性测试（续） （2）不同版本间的兼容 不同版本间的兼容是指要实现测试平台和应用软件多个版本之间能够正常工作。
•举例： 现在要测试一个流行的操作系统的新版本，当前操作系统上可能有数几十上百万现有程序，则新操作系统的目标是与它们百分之百兼容因为不可能在一个操作系统上测试所有的软件程序，因此需要决定哪些是最重要的、必须进行的对于测试新应用软件也一样，需要决定在哪个平台版本上测试，以及和什么应用程序一起测试 113 兼容性测试（续） （3）标准和规范 适用于软件平台的标准和规范有两个级别——高级标准和低级标准 高级标准是产品应当普遍遵守的，例如软件能在何种操作系统上运行？是互联网上的程序吗？它运行于何种浏览器？每一项问题都关系到平台，假若应用程序声明与某个平台兼容，就必须最受关于该平台的标准和规范 低级标准是对产品开发细节的描述，从某种意义上说，低级标准比高级标准更加重要114 兼容性测试（续） （4）数据共享兼容 数据共享兼容是指要在应用程序之间共享数据，它要求支持并遵守公开的标准，允许用户与其他软件无障碍的传输数据•实例： — 在Windows环境下，程序间通过剪切、复制和粘贴实现数据共享在此状况下，传输通过剪贴板的程序来实现若对某个程序进行兼容性测试就要确认其数据能够利用剪切板与其他程序进行相互复制。
— 通过读写移动外存实现数据共享，如软磁盘、U盘、移动硬盘等，但文件的数据格式必须符合标准，才能在多台计算机上保持兼容115 Web网站测试 Web网站的网页是由文字、图形、音频、视频和超级链接组成的文档 对网站的测试包含许多方面，如配置测试、兼容测试、可用性测试、文档测试等；黑盒测试、白盒测试、静态测试和动态测试都有可能采用 通常Web网站测试包含以下内容： （1）文字测试 （2）链接测试 （3）图像、图像测试 （4）表单测试 （5）动态内容测试 （6）数据库测试 （7）服务器性能及负载测试（8）安全性测试116 2.8 验收测试2.8.1 验收测试的内容2.8.2 软件配置和文档资料测试Return117 2.8.1 验收测试的内容•软件验收测试应完成的工作内容包括：（1）明确验收项目，规定验收测试通过的标准2）确定测试方法3）决定验收测试的组织机构和可利用的资源4）选定测试结果分析方法5）指定验收测试计划并进行评审6）设计验收测试所用的测试用例7）审查验收测试准备工作8）执行验收测试。
9）分析测试结果10）做出验收结论，明确通过验收或不通过验收118 验收测试的内容（续）在验收测试计划当中，可能包括的检验方面有以下几种：•功能测试如完整的工资计算过程•逆向测试如检验不符合要求数据而引起出错的恢复能力•特殊情况如极限测试、不存在的路径测试•文档检查•强度检查如大批量的数据或者最大用户并发使用•恢复测试如硬件故障或用户不良数据引起的一些情况•可维护性的评价•用户操作测试如启动、退出系统等•用户友好性检验•安全测试119 2.8.2 软件配置和文档资料测试•对文档的测试包括以下内容： （1）检查产品说明书属性 （2）检查是否完整 （3）检查是否准确 （4）检查是否精确 （5）检查是否一致 （6）检查是否贴切 （7）检查是否合理 （8）检查代码无关 （9）检查可测试性120 2.9 测试后的调试•软件调试和软件测试有完全不同的含义： ——测试的目的是显示存在错误 ——调试的目的是发现错误或导致程序失效的错误原因，并修改程序以修正错误•通常情况是在测试以后紧接着要进行调试，调试是在测试发现错误后消除错误的过程实际上这两项工作是交叉进行的。
Return121 2.10 面向对象的软件测试Return1、面向对象的软件测试•面向对象软件测试的目标与传统测试一样，即用尽可能低的测试成本和尽可能少的测试用例，发现尽可能多的软件缺陷面向对象的测试策略也遵循从“小型测试”到“大型测试”，即从单元测试到最终的功能性测试和系统性测试 •但面向对象技术所独有的封装、继承、多态等新特点给测试带来一系列新的问题，增加了测试的难度与传统的面向过程程序设计相比，面向对象程序设计产生错误的可能性增大，或者使得传统软件测试中的重点不再那么突出，或者使得原来测试经验和实践证明的次要方面成为了主要问题122 面向对象的软件测试（续）2、面向对象的单元测试•与传统的单元不同，面向对象软件测试中的单元是封装的类和对象每个类和类的实例（对象）包含了属性和操作这些属性的方法•类包含一组不同的操作，并且某个或某些特殊操作可能作为一组不同的类的一部分而存在，测试时不再测试单个孤立的操作，而是测试操作类及类的一部分，单元测试的意义发生了较大的变化•对面向对象软件的类测试等价于对面向过程软件的单元测试传统的单元测试主要关注模块的算法和模块接口间数据的流动，即输入和输出；而面向对象软件的类测试主要是测试封装在类中的操作以及类的状态行为。
123 面向对象的软件测试（续）3、面向对象的集成测试•面向对象的集成测试通常需要进行两级集成： （1）将成员函数集成到完整类中； （2）将类与其它类集成•对面向对象的集成测试有两种不同的策略： （1）基于线程的测试集成针对回应系统的一个输入或事件所需的一组类，每个线程被集成并分别进行测试 （2）基于使用的测试首先测试独立的类，并开始构造系统，然后测试下一层的依赖类（使用独立类的类），通过依赖类层次的测试序列逐步构造完整的系统124 面向对象的软件测试（续）4、面向对象的确认测试•与传统的确认测试一样，面向对象软件的有效性集中在用户可见的动作（事件驱动与过程）和用户可识别的系统输出（结果），通过测试检验软件是否满足用户的需求•在面向对象的确认测试中，通常采用传统的黑盒测试方法，以证明软件功能和需求的一致性125 本章小结•软件测试的复杂性分析•排除软件缺陷的手段•软件测试方法与策略•单元测试•集成测试•确认测试•系统测试•验收测试•测试后的调试•面向对象的软件测试126 。
