《软件测试教案》由会员分享，可在线阅读，更多相关《软件测试教案（350页珍藏版）》请在金锄头文库上搜索。
1、软件测试教案软件测试教案常见的疑问？什么时候开始测试？测试小组的具体工作包括什么？谁执行测试？开发者？专门的测试人员？两类人员共同？每个部分都要测试？还是只测试软件中高风险部分？软件测试和单纯的代码调试有什么区别？测试应进行到什么程度？测试的生存周期是什么？测试是为了验证软件有错误，还是验证软件正确？测试人员的地位如何？测试者忠于谁？所就职的公司，还是用户？软件测试初步什么是软件测试为什么要进行软件测试如何进行软件测试软件测试的定义侧重点不同的几种观点：1983年IEEE:“使用人工或自动手段运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别”（明
2、确提出了软件测试以检验是否满足需求为目标）Myers:“是为了发现错误而执行程序的过程”（明确提出了“寻找错误”是测试目的）从软件质量保证的角度看：是一种重要的软件质量保证活动，其动机是通过一些经济、高效的方法，捕捉软件中的错误，从而达到保证软件内在质量的目的。也有人认为，软件测试（software testing）就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试发展史和职业前景20世纪50-60年代，较之硬件的作用，软件仍然处于次要位置，测试理论和方法的发展比较缓慢70年代以后，软件技术的成熟和完善使得软件测试的规模和复杂度加大，软件测试
3、也逐渐形成了一套完整的体系，逐渐走向规范化与一些发达国家相比，国内测试职位的规范性尚存一定差距。测试人员普遍所占比例较小目前国内软件测试工程师存在20W以上缺口微软：Windows2000：共5000万行代码 3000多个工程师，几百个小团队Exchange2000Windows2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人Exchange 2000和和 Windows 20002000 开发人员结构对比开发人员结构对比为什么要进行软件测试软件一般都存在错误和缺陷，在一些特定的范围内不能满足客户的合理要求测试的目的：及时发现错误，避免给用户造成损失得到
4、更优质的软件产品，为公司创造效益软件业客观环境：规模增大/功能增多/复杂度提升/用户要求更多并已完成由卖方市场到买方市场的转变TO1995年一个国外的大规模研究调查了17万个软件开发项目的完成过程，结论数据：按时&按预算完成的仅占6%被中途取消的项目占31%虽然完成，但都超出了预算和进度的：63%其中一大半的项目实际花费超值达189%back常用名词I：缺陷用于形容计算机软件毛病的专用词汇故障default失败failure事件incident异常anomaly偏差variance缺陷bug问题problem例：世上第一个计算机 BUG软件缺陷的几个经典案例1990哈勃太空望远镜焦距错误199
5、1爱国者导弹防御系统失效19941995年迪斯尼狮子王案例1994intel奔腾浮点除法缺陷1999美国火星极地探路者号探测器失踪注意分析，这些缺陷的根源是什么？注意分析，这些缺陷的根源是什么？有什么补救方案？有什么补救方案？制造望远镜是一项极其艰巨的任务，对镜面的精确度和准确度要求都非常高，而制造好后又很难测试，因为在地球上无法固定它，甚至无法全面地观察它，唯一的测试手段就是精确测量它的每一项属性，并将度量的结果和理论值相比较，全部精确符合后再发射。很不幸的是，望远镜投入使用后几乎马上就出了毛病，传回来的图象聚焦存在问题，基本不能用。经过调查发现，镜子的制造虽然确实是按照产品说明书进行了表面
6、处理，但产品说明书是错的，即镜子精确度极高但准确度不够哈勃太空望远镜焦距错误确认和验证软件测试有两个基本职责：即验证和确认确认：保证做出来的软件符合产品说明书的规定即有没有准确地实现某一目标验证：保证产品说明书确实无误地满足用户的需要即这一目标是不是真正的目的测试员保证了镜子是符合产品说明的得到了确认但产品说明没有满足实际的客观需求没有得到验证此例子可以也适用于软件方面：作为测试员，永远不能假定产品说明书是对的，它也一样需要确认软件工程基本思想一个软件的开发流程需求确认概要设计详细设计编码验收测试系统测试集成测试单元测试需求分析：需求规格说明书概要设计：系统用例图，用例场景详细设计：系统设计报
7、告，数据库设计报告测试：测试用例表，测试执行结果报告开发方法学开发方法学开发方法学开发方法学配置管理配置管理配置管理配置管理验证技术验证技术验证技术验证技术评评评评 审审审审正确性验证正确性验证正确性验证正确性验证性能调试性能调试性能调试性能调试单元测试单元测试单元测试单元测试集成测试集成测试集成测试集成测试系统测试系统测试系统测试系统测试原子事务原子事务原子事务原子事务模块冗余性模块冗余性模块冗余性模块冗余性检检检检 错错错错质量控制质量控制质量控制质量控制避免错误避免错误避免错误避免错误容容容容 错错错错调调调调 试试试试测测测测 试试试试测试在质量控制体系中的作用测试在开发流程中的位置和
8、作用软件生存期各阶段软件生存期各阶段用户要求用户要求用户用户: :我想要什么我想要什么? ?运行结果运行结果计算机计算机: :程序运行得到的结果程序运行得到的结果源程序源程序程序员程序员: :我要让计算我要让计算机怎么做机怎么做? ?设计说明书设计说明书设计员设计员: :我要让软件具我要让软件具体做什么体做什么? ?需求说明书需求说明书分析员分析员: :我可以向我可以向用户提供什么用户提供什么? ?12345用户：表达正确性用户：表达正确性用户：表达正确性用户：表达正确性分析员：理解正确性分析员：理解正确性分析员：理解正确性分析员：理解正确性理解正确性理解正确性理解正确性理解正确性设计正确性设
9、计正确性设计正确性设计正确性表达正确性表达正确性表达正确性表达正确性理解正确性理解正确性理解正确性理解正确性编码正确性编码正确性编码正确性编码正确性运行正确性运行正确性运行正确性运行正确性输入正确性输入正确性输入正确性输入正确性相符吗相符吗? ?问 题？软件缺陷主要产生于哪个环节？什么时候开始测试合适？ 从一个业内经典图例中观察客客 户户 解解 释释 的的项项目目文文档档的的记记录录用用 户户 的的 花花 费费安安 装装 的的 操操 作作商商业业顾顾问问描描绘绘的的程程序序员员编编写写的的分分析析师师设设计计的的项项目目经经理理理理解解的的项项 目目 支支 持持 的的客客户户真真正正需需要要的
10、的缺陷的最大份额出现在最初的需求分析阶段缺陷的最大份额出现在最初的需求分析阶段？软件缺陷主要源于哪个环节？什么时候开始测试合适？测试应贯穿于软件定义与开发的整个期间测试应贯穿于软件定义与开发的整个期间大多数软件缺陷并非来自编程错误对众多从小到大的项目研究中发现，导致软件缺陷的最大原因是产品说明书（即需求分析），其次是来自设计（以上两项共占约64%），来自编码本身的缺陷不到20%很多情况下，产品说明书没有写，或者写了但不全面，或者经常更改，都将造成未来的缺陷编码错误则可归咎于软件的复杂性、文档不足、进度压力，或普通的低级错误backl软件开发过程是一个自顶向下，逐步细化的过程l测试则是依相反顺序
11、自底向上，逐步集成的过程规格定义规格定义规格定义规格定义设计设计设计设计编码编码编码编码系统测试系统测试集成测试集成测试单元测试单元测试用户需求用户需求用户需求用户需求验收测试验收测试回回归归测测试试配置管理配置管理配置管理配置管理缺陷跟踪缺陷跟踪 V模型模型 J.McDermidJ.McDermid 于于于于19941994年在年在年在年在“ “软件工程师参考手册软件工程师参考手册软件工程师参考手册软件工程师参考手册” ”中提出中提出中提出中提出系统需求系统需求系统需求系统需求软件需求软件需求软件需求软件需求概要设计概要设计概要设计概要设计详细设计详细设计详细设计详细设计单元测试单元测试单元
12、测试单元测试集成测试集成测试集成测试集成测试编码编码编码编码合格性测试合格性测试合格性测试合格性测试系统测试系统测试系统测试系统测试详细设计详细设计详细设计详细设计概要设计概要设计概要设计概要设计软件需求软件需求软件需求软件需求系统需求系统需求系统需求系统需求软件任务软件任务软件任务软件任务编译后的单元编译后的单元编译后的单元编译后的单元测试后的单元测试后的单元测试后的单元测试后的单元集成的软件集成的软件集成的软件集成的软件测试后的软件测试后的软件测试后的软件测试后的软件交付软件交付软件交付软件交付软件验证验证验证验证验证验证验证验证验证验证验证验证验证验证验证验证验证验证验证验证验证验证验证
13、验证验证与确认验证与确认验证与确认验证与确认验证与确认验证与确认验证与确认验证与确认W模型模型 l开发的各个环节都可能产生缺陷，如果坚持各阶段的技术评审，就能尽早发现和预防缺陷W 模型形象地说明了测试与开发的这种同步性软件测试从开发完毕后进行应尽可能早地进入，最好从需求阶段开始软件测试由程序员就可以担任程序员只负责少量测试，测试主体则由测试员完成软件测试不需要严格的依据依据必须严格而唯一，就是需求分析文档软件测试的目的是验证软件的正确性测试的唯一目的和存在价值就是验证软件有错有关软件测试的几个常见认识误区I软件测试就是测试软件代码所有“用户可能使用、查看的部分”均需测试“缺陷”的含义就是指“错
14、误”前者含义广泛得多：任何感到不适的地方都算缺陷和程序员意见发生冲突时，测试员应做出让步测试员代表的并不是公司直接利益一个现象是不是缺陷，是不言自明的很多时候各人有不同角度的理解，无法统一有关软件测试的几个常见认识误区IITO“软件产品”不仅限于代码软件产品中常见的非软件部分：安装样本和示例说明文件帮助文件标签广告和宣传资料 图标和标志用户手册错误提示信息产品支持信息最终产品软件产品中最容易被忽视的部分软件产品中最容易被忽视的部分软件产品中最容易被忽视的部分软件产品中最容易被忽视的部分back从用户的角度用户的角度出发，普遍希望通过软件测试暴暴露软件中隐藏的错误和缺陷露软件中隐藏的错误和缺陷，
15、以考虑是否可接受该产品。从软件开发者的角度软件开发者的角度出发，则希望测试成为表表明软件产品中不存在错误明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。看待测试的两种心态而测试人员是用户的代言人而测试人员是用户的代言人back软件测试所面临的现状国内IT业需求不严密，并频繁变更开发流程不规范文档匮乏，或与事实不符对测试的忽视不测试用测试验证软件正确用最弱的人去做测试。回忆我们自己的开发习惯直取目标，先做着再说，遇到问题临时想办法，没有计划，没有文档应该是什么模式？考虑到所有可能发生的意外情况，为之安排对应策略，每一个变动都有记录课后作业模式：题目明确
16、，要求单一思考编码调试需求&设计&测试几个环节被大大压缩了没有真实的需求方，因此没有需求题目的规模太小，根本谈不上有“设计”的必要不明确测试和调试的区别形成在校生所特有的惯性微观视角大环境造成的一些障碍BACK如何进行测试初学者的手法：通过使用观察发现错误使用中的“不适”感源于发现了“对常识的违背”多半是通过常识进行判断引入实例：纸杯测试给你一只普通的纸杯，你会怎么测试它？或许我们首先应该想一想：测试即发现错误，那么，什么是正确和错误的分界？首先：不能对使用者造成伤害类型：毒副作用、烫伤其次：是否称职地发挥了效能盛水/饮料；广告/公益宣传等再次：有无使用中的不便之处漏水吗？手感好吗？纸杯测试注
17、意注意 产品说明书产品说明书纸杯产生的用户需求：人际交往中的心理需要：干净、礼貌、方便从生产厂商方面来看：用廉价、以获取的原材料制作的可盛液体、固体、用于多供临时饮食用的杯状一次性使用容器作为商品的特点：批量生产、运输、零售、批发深层分析I它是一次性的商品，其设计必须考虑若干环节：成本不可太高 取材不可太难（原木浆/回收纸）应为卖家带来剩余价值：应该好卖即卖相要好：白、亮、挺括（漂白剂、荧光粉、增塑剂）从社会公德角度：其材料应该是可回收的、环保的其原材料（纸塑）使其注定具有如下危险：其形状&运输方式：纸吸水，含水后易形成霉菌纸杯套叠在一起，脏物（霉菌、油墨）易互相传染深层分析II首要原则：作为
18、日用品：不应对人身构成显性隐性的伤害作为软件：不应该让用户的数据意外丢失、损坏其次：正确、完满地发挥了其职能，无副作用注意：此处的“职能”，所指范畴广泛最后：使用方便此项要求涵盖的最广，且有较大主观性测试着手点定义缺陷的五个标准至少满足下列5个现象之一软件未实现产品说明书要求的功能软件出现了产品说明书指明不能出现的错误软件实现了产品说明书未提及的功能软件未实现产品说明书虽未明确提及但应该实现的目标软件难以理解，不易使用，运行缓慢或者（从测试员角度看）最后用户会认为不好以计算器为例产品说明书的部分内容：本计算器能够成功地进行+-*/四则运算加法不成功 “ “未实现未实现产品说明书产品说明书要求的
19、功能要求的功能” ”本计算器在未受物理损坏并电池充足时，不会出现崩溃或停止反应的现象乱敲键盘使计算器停止接受输入 “ “出现了出现了产品说明书产品说明书指明不能出现的错误指明不能出现的错误” ”以计算器为例“实现了产品说明书未提及的功能”除了+-*/外，还能做开方运算未实现产品说明书虽未明确提及但应实现的目标“3+2=”这是计算加法的一个用例之输入如果结果是5，证明用例运行成功但未提及：“ “运算过程中的中间数据是否要显示出来运算过程中的中间数据是否要显示出来” ”？Q1Q1：如果实际未显示，那么用户是否可以投诉？：如果实际未显示，那么用户是否可以投诉？Q2Q2：如果实际未显示，那么属于设计缺
20、陷还是实现缺陷？：如果实际未显示，那么属于设计缺陷还是实现缺陷？以计算器为例“难以理解，不易使用，运行缓慢或者（从测试员角度看）最后用户会认为不好”按键不易找到按键不易被按下（机械实现缺陷）显示屏反光显示屏不易看清楚附：计算机用户权利法案1.用户总是正确的。如果对于系统使用有什么问题，那么系统就存在问题，而不是用户存在问题。2.用户有权简单安装和卸载软件和硬件系统，而没有任何副作用。3.用户有权如说明书承诺的那样使用系统。4.用户有权要求系统容易使用、非常容易地实现期望的作用，并能有效地很好地从问题状态中恢复。5.用户有权控制系统并使系统响应请求。6.用户有权清楚地了解成功使用软件或硬件的所有
21、系统需求。7.用户有权知道系统能力的局限。8.用户有权和技术供应商交流，并在遇到问题时能够得到及时的帮助。我们看到了，我们只有义务，权利基本都在用户那一方我们看到了，我们只有义务，权利基本都在用户那一方辅助作业辅助作业分别以纸杯等日用品、小游戏为例进行可以测试的日用品餐具文具食物建筑物一个小软件的初级测试实例试试看这个很常见的扫雷小游戏，能发现自己的视角受到何种限制吗？常用名词II：需求需求分析文档：由客户和公司初期达成一致需求分析文档：由客户和公司初期达成一致产品完成后的变体产品说明书（随产品附送的使用指导）对于软件公司对客户和用户的承诺对于客户验收时的收货清单对于双方发生纠纷时的呈堂证供对
22、于测试人员呢？测试原则测试原则以下的描述均为公理性质可以视为测试中的首要基本常识测试新手可能认为，在拿到软件后进行完全的测试，找出所有缺陷即可确保软件完美无缺这实际上是根本不可能的，即使是面对最简单的程序也不可能。主要原因在于：输入量太大输出结果太多软件的执行路径太多不能采用逻辑来证明程序的正确性1、完全测试是不可能的即使简单如计算器程序，其实际测试用例都复杂到即使简单如计算器程序，其实际测试用例都复杂到难以难以全部采用全部采用假设我们先从加法入手开始测试：测试加法功能是否正常，并非随意寻找两个数字相加，所得结果与实际相符合就算通过，而是要把两个参与运算的数字的各种可能全部取到，一一测试成功后
23、，才算加法功能经过了完全测试具体来说，得从1+0、1+1、一直走到无限远。同时由于计算机可以处理32位的数字，所以必须测试所有的可能性，即测试过1+99（共32个9）之后，还要继续输入2+0、2+1、2+99（32个）等，直至99+99为止。这才完成了整数加中正数相整数加中正数相加的一小部分以WINDOWS自带的计算器程序为例99999999999999999999999999999999+99999999999999999999999999999999=1+0=？ 1+99999999999999999999999999999999=？2+0=？ 2+99999999999999999999
24、999999999999=？1.0+0.1=？1.0+0.2=？ 如果这样做，即使最简单的加法，也要测试数十年以上接着是测试小数部分：1.0+0.1、1.0+0.2、依次类推，这才完成了小数加中正数相加小数加中正数相加的一小部分验证完正常的数字相加均正确无误后，还要测试非法输入是非法输入是非法输入是非法输入是否能得到正确的处理否能得到正确的处理否能得到正确的处理否能得到正确的处理：不仅可以单击界面上的数字键进行运算，还可以按动键盘上的任意键来查看会引发何种反应我们发现，好的测试数据，如同好的密码一样，越是不可猜测的组合越能够保证效果。当然这些组合的可能性非常多，全都是合法而优秀的测试数据，但我
25、们不可能一一选用上述测试做完后 注意：在某种意义上，好的测试数据就意味着怪异怪异的数据 如1+a1+a、z+09z+09、1a1+21a1+2；2 2、另外，输入数据的编辑修改也必须进行测试如在计算器程序中已声明允许使用退格键和删除键去掉错误的输入，那么就需要测试退格和删除键是否能起到正常的作用，如：1退格2+2，结果是否等于4？成立以后，还需要把之前所有做过的测试再逐个引入退格键来重新测试一遍，看它们在引入退格键后是否还是正确的（尤其在多个数相加的过程中，退格键参与的用例将有更多可能的组合）非法输入的另一部分以上是两个操作数的加法还需验证三、四、五等多个数的相加，如此下去，完成加法的测试也要
26、数十年以上以上是针对加法的部分测试（还没有算上操作数含负数的情况），完成它们之后，还有-、*、/、%、开方、求倒数等的测试需要做看完以上这些，还有人坚持选择完全测试吗？计算器程序还只是一个功能极简单的小型程序，很多真正的大型软件，其中一个极微小的子功能，都要比计算器程序复杂得多可见，完全测试是不可能的。如果觉得某些测试条件是重复、无必要的，或为了节省时间、空间而将其剔除，那么采用的就只是不完全测试IBM的研究结果表明，缺陷存在放大趋势下图表示了缺陷放大模型大致状况需求阶段需求阶段缺陷缺陷详细设计详细设计阶段缺陷阶段缺陷放大放大 n1倍倍放大放大n2倍倍放大放大 n3倍倍概要设计概要设计阶段缺陷
27、阶段缺陷代码阶段代码阶段缺陷缺陷可见，问题发现越早，解决问题的代价就越小这是软件开发过程中的黄金法则2、要尽早地和不断地进行软件测试如果决定不测试全部的情况，就等于选择了冒险。在刚才的例子里，如果我们放弃了1024+1024这组用例，就存在一定风险：有可能程序员碰巧在这种情况下留下了一个软件缺陷。如果客户碰巧输入了这组数据，就会发现这个缺陷于是将发生一个修复代价很高的软件缺陷，因为它直到软件被使用时才由客户发现至此展现的因果关系有些矛盾：测试员必然不能做全部测试，而不完全测试又会漏掉缺陷。那怎么办？3、软件测试是有风险的行为虽说应尽量多测试、尽量完整地测试，但即便如此，测试员能做的也是有限的：
28、因为软件终归要发布，所以测试在某个时候不得不终止因此测试员要有一个重要的行为准则：如何把数量巨大的可能的测试减少到可以控制的范围，以及如何针对风险做出明确的抉择：哪些测试重要，哪些不重要，哪些优先必做，哪些可以在时间不够时放弃我们的目标：找到最优的测试量，使测试不多不少并不是无休止地测试效果就最好数数数数量量量量遗漏的软件遗漏的软件缺陷数目缺陷数目测试的费用测试的费用测试中测试中测试中测试中测试后测试后测试后测试后测试工作量测试工作量测试工作量测试工作量最优最优最优最优测试量测试量测试量测试量每一个软件项目都有一个最优的测试量每一个软件项目都有一个最优的测试量假如你是一个负责检查房间内是否有蚊
29、子的检疫人员，通过仔细检查，发现了有蚊子的迹象活的、死的、在窝里的。你可以放心地下结论了：房间里有蚊子房间里有蚊子到另一个房间做出同样的查找后，你没有发现任何活动的蚊子的迹象，也许发现了死蚊子、废弃的蚊子窝，但没发现活的蚊子，你能肯定地说，这间房子没有蚊子吗这间房子没有蚊子吗？你的结论最多是：在你的搜索之下，没有找到活的蚊子。软件测试员的工作与此类似：可以报告软件缺陷存在，但无权报告软件无权报告软件缺陷不存在缺陷不存在，任何情况下，都不能保证软件缺陷已经没有了，都被发现了。唯一的方法是继续测试，很可能还会找到一些4、测试无法显示潜伏的软件缺陷测试无法显示潜伏的软件缺陷缺陷和生活中的害虫一样，都
30、是成群出现的，一旦发现一个，那么就可能马上看到一群通常，测试员都会在很长时间内一无所获，接着突然发现一个，之后很快就找到更多。其原因：源于程序员失误的缺陷，假设程序员的水平足够，他仍然不时存在状态欠佳、情绪低落、工作漫不经心的时候，这种情况一般会持续一段时间，期间的产生的软件缺陷相对于别的时段便会更多、更密集另外，同一个程序员往往会反复犯同样的错误，这是人之常情，不可避免某些缺陷只是冰山一角。测试员在初期可能不觉得各个缺陷彼此之间有什么关联，但最后会发现它们来自同一个严重原因5、找到的缺陷越多，就说明未找到的缺陷更多经验表明：测试后程序中残存的错误数目与该程序中已发现的错误数目成正比 如：对话
31、框中的某个按钮不起作用，可能其它按钮也不起作用；某个文本框不能正确显示双字节字符，则其它文本框也可能不支持双字节字符；联机帮助中某段文字的翻译包含了很多错误，与其相邻的上下段的文字可能也包含很多的语言质量问题也称为软件缺陷的群集现象 但也要注意，群集现象这条原则在极少数情况下是不适用的：如果你无论如何努力也找不出某段程序代码中的哪怕一个缺陷，那么可能真的是因为这段程序编得太好了，确实无缺陷。个中分寸如何把握，全凭经验测试员找出的全部缺陷，都要经过项目小组的取舍，他们会根据风险决定哪些缺陷需要修复，哪些不必。测试员在一定程度上要服从这些决定几个不修复的原因：没有足够的时间：在任何一个项目中，通常
32、都是软件的功能太多，开发人员和测试人员太少，而进度总是太紧，交付期限又不可更改不算真正的缺陷：从过于微观的角度理解一个功能，就容易产生误解6、并非所有缺陷都需要修复其余不修复的原因修复的风险过大：这种情况非常常见，软件本身是脆弱而且复杂的，任何功能都和其它功能有着各种密切联系，修复一个缺陷，就要做出改动，这些改动经常带来连锁反应，导致了更多本来没有的软件缺陷的出现。因此，不去理睬已知的轻量级轻量级缺陷反而更符合安全之道不值得修复：不常出现的、可以躲过的、用户有办法避免的缺陷，通常不用修复。这归结于商业风险决策，属于管理层需要考虑的问题（通常决策时有测试员、项目经理、程序员参与讨论，发表来自各自
33、立场的观点） 原因如下：程序员轻易不会承认自己写的程序有错误 程序员的测试思路有局限性，在做测试时很容易受到编程思路的影响多数程序员没有严格正规的职业训练，缺乏专业测试人员的意识程序员没有养成错误跟踪和回归测试的习惯7、尽量避免测试(指黑盒测试)自己的程序有时候测试人员提交的缺陷并不是真正的缺陷。下图具体描述了无效缺陷的来源。一般由A测试人员发现的缺陷，一定要由另外一个B测试人员来进行确认，如果发现存在严重争议的缺陷，可以召开评审会进行讨论和分析26%26%其它其它12%12%13%13%人为因素人为因素9%9%11%11%对设计的歧义理解对设计的歧义理解29%29%0%5%10%15%20%
34、25%30%35%测试过程的混乱测试过程的混乱无效的运行环境无效的运行环境工具或方法使用错误工具或方法使用错误 无效缺陷来源构成图8、缺陷的有效性需要被确认整个软件开发行业变化是很快的，去年还很先进的产品，今年就过时了。软件产品变得更庞大、复杂，功能越来越多，开发周期也更长，这就形成了矛盾：换代要求很快，开发过程又必须延长，导致的结果就是说明书频繁变化，设计细节经常改动或增加。然而除了努力紧跟变化外，别无良策产品说明书变化，就意味着测试的依据变了尽管不希望如此，但测试员必须一开始就有思想准备：最初领到的产品说明书很可能改变，未曾计划测试的功能会增加，经过测试并已报告过缺陷的功能可能因发生变化不
35、得不重新测试，或者干脆被砍掉9、产品说明书没有所谓的最终版本测试员的工作是检查和批评同事的工作，挑出毛病并且公布，这种角色必然不受欢迎。何况，在目前国内的绝大多数开发团队看来，测试员属于水平比较差的一类人在这种大环境下，测试员应该怎么做呢？早点找出缺陷：这是基本的职业精神、理所应当的职责早些找出，影响小，易于被接受控制情绪：不可在找到缺陷后不加克制地表现出兴奋的情绪，同时，交流之中要注意选择没有针对性的词汇10、测试员在整个产品小组中不受欢迎目前的大环境是：软件产业整体不规范，从业人员的软件工程意识尚不成熟，软件测试又是软件工程中一个分支。更加的不规范、不被重视以前的测试都是事后才考虑的，那时
36、软件产品很小，也不复杂，无非是程序员去相互交叉调试对方的代码，其目的也不明确，只是想“试着搞乱对方的代码看看会怎样”即使出了错，修改容易，错误的破坏性也不大，如今就不行了测试时常目前是不规范、混乱、无正规培训的摸索状态测试员在将来将是整个开发小组中的核心成员11、软件测试是一项讲究条理的技术专业其它的测试原则严格执行测试计划，排除测试的随意性。即避免不可重复避免不可重复的即兴测试的即兴测试只检查程序是否做了它应该做的事，仅仅完成了测试工作的一半，另一半则是要检查程序是否做了它不该做的事妥善保存测试计划、测试用例、出错统计和最终分析报告（直至系统废弃），为后期维护提供方便其它的测试原则所有测试可
37、在任何代码被产生之前进行计划和设计经常出错的模块修改好后还会经常出错所有测试可在任何代码被产生之前进行计划和设计pareto原则：测试发现的错误中80%很可能起源于20%的模块中。应孤立这些疑点模块重点测试理解各种测试类型（纸杯测试用例续）？测试项目测试项目？需求测试需求测试？界面测试界面测试？功能度测试功能度测试？安全性测试安全性测试？可靠性测试可靠性测试？可移植性测试可移植性测试纸杯纸杯查看杯子使用说明书查看杯子使用说明书查看杯子外观查看杯子外观用水杯装水看漏不漏；水能不能被喝到用水杯装水看漏不漏；水能不能被喝到杯子有没有毒或细菌杯子有没有毒或细菌杯子从不同高度落下的损坏程度杯子从不同高度
38、落下的损坏程度杯子在不同地理位置的城市内、杯子在不同地理位置的城市内、不同温度等环境下是否都可以正常使用不同温度等环境下是否都可以正常使用？兼容性测试兼容性测试？易用性测试易用性测试？用户文档测试用户文档测试？疲劳测试疲劳测试？跌落测试跌落测试？震动测试震动测试杯子是否能够容纳果汁、白水、酒精等常见液体杯子是否能够容纳果汁、白水、酒精等常见液体承纳饮水机开水档下的饮用水后杯子是否烫手、承纳饮水机开水档下的饮用水后杯子是否烫手、是否有防滑措施、方便饮用是否有防滑措施、方便饮用使用手册是否对杯子的用法、限制、使用条件等使用手册是否对杯子的用法、限制、使用条件等有详细描述有详细描述将杯子盛上水，放将
39、杯子盛上水，放2424小时检查泄漏时间和情况小时检查泄漏时间和情况杯子加包装杯子加包装( (有填充物有填充物), ),在多高的情况摔下不破损在多高的情况摔下不破损杯子加包装杯子加包装( (有填充物有填充物), ),六面震动六面震动, ,检查产品是否检查产品是否能应对恶劣的铁路能应对恶劣的铁路 公路公路 航空运输航空运输一道测试笔试题测试notepad的“文件保存”功能，即file/save弹出对话框的功能，能从哪几个方面写测试用例？?单元测试（白盒测试）单元测试（白盒测试）代码审查流程、部分编码规范白盒测试 白盒测试也称结构测试或逻辑驱动测试。此方法把测试对象看把测试对象看做一个透明的盒子做一
40、个透明的盒子，它允许测试人员利用被测程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，力求提高测试覆盖率。 使用被测单元内部如何工作的信息，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为开盒测试开盒测试、玻璃盒测试玻璃盒测试、结构测试结构测试、逻辑驱动测试逻辑驱动测试或基于覆盖的测试基于覆盖的测试。白盒测试的局限对一个具有多重选择和循环嵌套多重选择和循环嵌套的程序，不同不同的路径数目可能是天文数字的路径数目可能是天文数字。给出一个小程序的流程图
41、，它包括了一个执行20次的循环包含的不同执行路径数达520条，对每一条路径进行测试需要1毫秒，假定一年工作365 24小时，要想把所有路径测试完，需3170年单元测试单元测试对软件单元进行测试，确实保证它作为一个单元能正常地工作单元测试的目的是验证单元满足功能、性能和接口等的要求单元测试采用的技术：静态分析、代码审查、白盒动态测试测试的充分性由各种测试覆盖率来度量单元测试的常见错误类型 l接口错误lI/O错误l数据结构错误l算法错误l比较及控制逻辑错误l错误处理错误单元动态测试的内容l主要针对模块的下列五个基本特性进行：l模块接口l局部数据结构l重要的执行路径l出错处理路径l影响以上各点的边界
42、条件单元测试用例的原则和要求l测试所有语句至少一次l测试所有可能的执行或逻辑路径的组合l测试每个模块的所有入口和出口）用指定值、异常值和极限值验证全部计算；）验证全部输入数据的各种选择；）验证全部输出数据的各种选择和格式；）每个单元的全部可执行语句至少执行一次；）在每个分支点进行选择的测试。单元测试用例的内容）指明被验证的需求或功能；）解释测试如何进行，说明验证代码与单元设计一致的准则和技术，以验证接口满足需求；）指明测试使用的支持软件，如测试工具、驱动模块、桩模块、动态路径分析工具等；）说明全部输入数据和（或）驱动程序等；）说明预期的输出，包括数据值或其它可以验证的结果；）通过准则。指的是检
43、查设计和代码“静态”：是指测试非运行部分检验和审查“白盒（或称透明盒）”：是指访问代码，能够查看和审查静态白盒测试是在不执行软件的条件下有条理的仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时称为结构化分析审查：其含义很广，从两个程序员之间的简单交谈，到软件设计和代码的明细、严格检查均属于此过程静态白盒测试静态测试静态测试：基本特征是在对软件进行分析、检查和审阅，不实际运行被测试的软件(可找出30%70%的逻辑设计错误)代码审查：小组集体阅读讨论检查代码代码走查：小组集体用“脑”执行并检查代码桌面检查：由程序员阅读自己编写的程序检查变量、标号的交叉引用检查子程序、宏、函数常量检查
44、标准、风格检查少于少于3030代码行的函数不需要做单元测试，只要代码走查即可代码行的函数不需要做单元测试，只要代码走查即可正式审查的三种类型1.同事审查：召集小组成员进行初次正式审查中最简单的方法。它类似于“各抒己见”类型的讨论。常常仅在编写代码或设计体系结构的程序员和充当审查者的其他一两个程序员和测试员之间进行，这是要求最低的正式方法，也称伙伴审查2.公开陈述：是使同事审查正规化的下一步，又叫走查（Walkthrough）。其中编写代码的程序员向3人审查小组正式表述。审查小组应该在审查之前接到软件拷贝，以便检查并编写备注和问题，并在审查过程中提问。注意：审查人员之中至少有一位资深程序员3.检
45、验：是最正式的审查类型，具有高度组织化，要求每一个参与者都接受训练。检验与同事审查不同之处在于，表述者（presenter）者或宣读者（reader）不再是原来的程序员。这就迫使表述者去学习和了解要表述的材料，以有可能在检验会议上提出不同的看法和解释。其余的参与者称为检验员，职责是从不同的角度（如用户、测试员或产品支持人员的角度）审查代码。有些检验员还同时被委任为会议协调员（moderator）和会议记录员（recorder），以保证检验过程遵守规则及审查有效进行所谓的代码检查，其实就是以小组为单位进行代码阅读，是一系列规程和错误检查技术的集合。该过程通常将注意力集中在发现错误上，而不是纠正错
46、误成员组成：一个代码检查小组最佳的组合应该是：一位协调人（往往还兼具资深程序员和秘书功能）一位其他成员（通常是程序的设计人员）一位程序设计语言专家一位程序员新手一位测试员代码检查代码检查小组各成员的作用程序设计人员：分析缺陷的根源在具体实现还是在设计层面程序设计语言专家：分析缺陷的根源在编码还是语言本身的特点资深程序员：高效地发现编码错误新手：可以给出新颖、不带偏见的观点秘书：记录会议产生的问题被指定为测试者的成员会带着一些事先备好的书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。这些书面的测试用例必须结构简单、数量较少，因为人脑执行程序的速度比计算机执行程序的速度慢上
47、若干量级。会议期间的主要活动：（1）程序员逐句讲解程序的逻辑，其他人提问，去发现是否存在错误（程序员能比其他人发现更多的错误）。（2）对照常见的编程错误清单来对程序进行分析。在会议期间，人们将在头脑中依次推演备好的测试用例，即：把测试数据沿程序的逻辑结构走一遍，并把程序的状态（如变量的值）记录在纸张或白板上以供监视。之所以提供这些测试用例，目的不是在于其本身对测试了关键的作用，而是提供启动代码走查和质疑程序员逻辑思路及其设想的手段。在多数的代码检查中，问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的测试者的作用协调者的作用该协调人在代码检查中起主导作用（有点象质量控制工程师）
48、，他应该是个资深的程序员，但不能是该程序的编码人员，也不需要对程序的细节了解得很清楚。他的职责包括：为代码检查分发材料、安排进程；记录发现的所有错误；确保所有错误随后得到改正。他应提前几天将程序清单和设计规格说明书分发给其他的参会人员，他还有责任确保参会人员将注意力集中在发现错误而不是纠正错误上（纠正错误让程序员在检查会议之后去处理）。会议结束后，各成员可能再次碰头讨论他们发现的不足之处，并共同准备一份书面报告，明确错误清单和必须重做的部分。之后程序员据此报告进行修改代码检查的具体流程(由协调者来落实)1.在代码检查的时间和地点的选择上应避免所有的外部干扰2.一次代码检查会议的理想时间应在90
49、-120分钟之内（检查是很费精力的，会议太长，效率就会低下）3.大多数的代码检查都是按每小时大约阅读150行代码的速度进行4.对大型软件的检查应安排多个代码检查会议同时进行，每个代码检查会议处理一个或几个模块或子程序注意：对代码检查的结果要保密，知情者应仅限于参与者范围内部。尤其是如果管理人员想利用代码检查的结果针对程序员，那么就与检查过程的目的背道而驰了总结方法：组成一个小组来阅读或直观检查特定的程序，并在会上最终形成统一的目标：找出错误，但不必找出改正错误的方法（是测试，而不是调试）优点：一旦发现错误，就可以在代码中对其进行精确定位，这就降低了调试的成本，通常还可以发现成批的错误，使它们一
50、同得到修正，这也优于机器测试，因为后者只能暴露出错误的某个表症。效果：通常是能够有效地查找出30%-70%的逻辑设计和编码错误，但不能有效地查找出高层次的设计错误。地位：是与计算机的测试（即调试：DEBUG）互补。应始终记住的是：程序中的错误总数始终是未知的。否则就会浪费大量的精力和人力，也会在经济效益上或多或少有一些损失不过，就经验而言，修改一个现存的程序比编写一个新程序更容易产生错误（因为错误具有连锁反应），这依据于每写一行代码产生的错误数量注意：该处的错误发现率，并不是说所有缺陷中多达70%可能会被找出来，而是指这些方法在测试过程结束时，会发现至此发现的全部缺陷中，70%都是初期代码检查
51、时发现的。一个小技巧问题 ：希望检查一个整数的值是否为 5 通常这样写代码：if ( i = 5 ) then / / do something. / 不过，如果把代码写成了下面这样会出现什么情况呢？if ( i = 5 ) then / / do something. / 这个失误是一个缺陷，但是只有在运行时才能捕获它 可能需要相当的调试努力才能找到它。编译器会轻易放过，因为不属于语法错误，代码可以编译并运行得很好：那么如何防止这种错误发生？实际上有两个答案：可以使用一种静态代码分析工具，并希望它有足够的健壮性可以捕获这种错误，也可以交换操作数以使常量位于左边： if ( 5 = i ) t
52、hen / / do something. / 因为这种方法保证可以在编译代码时立即捕捉到问题，所以它是首选的技术。它看上去有些笨，但一旦误写成：if ( 5 = i ) then / / do something. / 可是编译器不喜欢这样，因为 5 不允许被赋值为另一个值。用这个方法就会得到所谓的“编译器保护”这种风格被成为“防御性编码”通用代码审查清单它们将代码与标准或规范比较，确保代码符合设计要求。1、数据引用错误：是指未经正确声明和初始化的变量、常量、数组、字符串或记录而导致的软件缺陷。A.是否引用了未初始化的变量？B.数组和字符串的下标是整数值吗？下标总是在数组和字符串大小范围之内
53、吗？C.在检索操作或者应用数组下标时是否包含丢掉一个这样的潜在错误？D.是否在应该使用常量的地方使用了变量？E.变量是否被赋予不同类型的值？F.为引用的指针分配内存了吗？G.一个数据结构是否在多个函数或者子程序中引用？在每一个引用中明确定义结构了吗？注意：数据引用错误是缓冲区溢出的主要原因一个造成许多软件安全问题的缺陷2、数据声明错误：其产生的原因是不正确地声明或使用变量和常量。A.所有变量都赋予正确的长度、类型和存储类了吗？B.变量是否在声明的同时进行了初始化？是否正确初始化并与其类型一致？C.变量有相似的名称吗？D.存在声明过、但从未引用或者只引用过一次的变量吗？E.在特定模块中所有变量都
54、显式地声明了吗？3、计算错误：实质上是指基本的数学逻辑问题。A.计算中是否使用了不同数据类型的变量，如整数与浮点数相加？B.计算中是否使用了数据类型相同但字节长度不同的变量？C.计算时是否了解和考虑到编译器对类型或长度不一致的变量的转换规则？D.赋值的目的变量允许取得的最大值是否小于赋值表达式的值？E.在数值计算过程中是否可能出现溢出？F.除法或模运算的除数是否可能为零？G.对于整型算术运算或某些计算，特别是除法的代码处理是否会丢失精度？H.变量的值是否超过有意义的范围？I.对于包含多个操作的表达式，求值次序是否混乱？运算优先级对吗？需要加括号使其清晰吗？数学是计算机之母，没有数学的依据和基础
55、，就没有计算机的发展，在编写程序的时候，采用一些数学方法会对程序的执运行效率有着数量级的提高。方法1循环了100次才解决问题，也就是说最少用了100个赋值、100个判断、200个加法(I和j)；而方法2仅仅用了1个加法、1个乘法、1次除法公式N*(N+1)/2的效果不言而喻。足见编程时更多的应是动脑筋找规律，最大限度地发挥数学的威力来提高运行效率方法1int I,j;for (I=1; I=0) y=sqrt(x); if (x=0) y=x;else y=abs(x); if (x=0)&(z=0) y=x*z;简单的赋值语句单分支语句双分支语句判断条件较复杂的单分支语句一些更复杂的语句 i
56、f (x100) printf(ERROR!);elseif(x=60) printf(OK!);elseprintf(FAIL!); for(i=0;i=0) y=sqrt(x); if (x=0) y=x;else y=abs(x); 令x任取一值即可使本语句被执行令x任取一非负数值即可保证判断条件成立，语句被执行令x任取一值因为此二分支覆盖了全部的取值范围，x无论取什么值，都能使其中的一个分支被执行 if (x=0)|(z=0) y=x*z;不管z，令x任取一非负数值不管x，令z任取一非负数值令x、z同时任取一非负数值这三种取值均能使判断条件成立令判断条件成立，语句即被执行 if (x1
57、00) printf(ERROR!);elseif(x=60) printf(OK!);elseprintf(FAIL!);令判断条件A成立，分支之一被执行令判断条件A不成立，但B成立，那么分支之二被执行令判断条件AB均不成立，则分支之三被执行A AB B以上三种取值，均能使这个分支语句得以执行 for(i=0;i3)/语句14k=x3-1;5j=sqrt(k);/语句26printf(%d,%5.2dn,k,j);7如下的C函数：Q1：本函数中起作用的变量有哪几个？ xQ2：用最简单的输入，使函数中的每个语句每个语句都得到执行：令x为4单分支语句voidDoWork(intx,inty,in
58、tz)12intk=0,j=0;3if(x3)&(z3)/语句14k=x-1;5else6k=sqrt(x);如下的C函数：Q1：本函数中起作用的变量有哪几个？Q2：用最简单的输入，使函数中的每个语句每个语句都得到执行x为4Q3：使函数中的每个语句都得到最充分的执行用例1：x为4用例2：x为3双分支语句概 念1.1.语句覆盖：使得每一条可执行语句至少执行一次语句覆盖：使得每一条可执行语句至少执行一次2.2.判断覆盖（也称为分支覆盖）：使程序中每个判断的取真分支和判断覆盖（也称为分支覆盖）：使程序中每个判断的取真分支和取假分支至少执行一次取假分支至少执行一次3.3.条件覆盖：使程序中每个判断的每
59、个条件的每个可能取值至少执条件覆盖：使程序中每个判断的每个条件的每个可能取值至少执行一次行一次4.4.判断判断- -条件覆盖：使程序中每个判断的每个条件的所有可能取值至条件覆盖：使程序中每个判断的每个条件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次，换言之，少执行一次，并且每个可能的判断结果也至少执行一次，换言之，即是要求各个判断的所有可能的条件取值组合至少执行一次即是要求各个判断的所有可能的条件取值组合至少执行一次5.5.条件组合覆盖：使程序中每个判断的所有可能的条件取值组合至条件组合覆盖：使程序中每个判断的所有可能的条件取值组合至少执行一次少执行一次6.6.路径覆盖：要
60、覆盖程序中所有可能的路径路径覆盖：要覆盖程序中所有可能的路径 设计若干个测试用例，运行被测试程序设计若干个测试用例，运行被测试程序各种逻辑覆盖的概念介绍1.语句覆盖：设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次每一条可执行语句至少执行一次；但其覆盖标准无法发现判定中逻辑运算的错误；但其覆盖标准无法发现判定中逻辑运算的错误；此方法是把程序中的所有的语句都覆盖到；if(x=0)y=x;if(x=0)y=x;elsey=abs(x);elsey=abs(x);x=abs(x);x=abs(x);if(x=0)y=x;if(x=0)y=x;elsey=abs(x);elsey=
61、abs(x);一个用例即可：一个用例即可：x x为为0 0一个用例即可：一个用例即可：x x为为0 02.判断覆盖（也称为分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支各至少执行一次；(x3)&(z=0)y=x;if(x=0)y=x;elsey=abs(x);elsey=abs(x);if(x=0)y=x;if(x=0)y=x;elsey=abs(x);elsey=abs(x);对程序中的双分支语句，相当于覆盖了两次第第1 1个用例：个用例：x x为为0 0第第2 2个用例：个用例：x x为为-1-1这个分支语句中，判断就是条件，条件就是判断if(x3)|(
62、z3)|(z3)和(z=0)y=x;if(x=0)y=x;elsey=abs(x);elsey=abs(x);if(x3)if(x3)|(z10)(z3)为真和假各取一次；(z3)|(z3)|(z3)|(z3)和(z3)(x3)|(z10)(z3)(x3)|(z10)(z3)为真和假各取一次；(z3)|(z3)(x3)和和(z10)(z3)(x3)和和(z10)(z3)if(x3)|(z10)(z3)(x3)|(z10)(z3)和(z3)(x3)和和(z10)(z3)(x3)和和(z10)(z3)(x3)和和(z10)(z3)(x3)和和(z10)(z3)|(z3)|(z3)和(z3)(x3)
63、|(z10)(z3)&(z5)j=x*y+10;/语句块2j=j%3;/语句块3函数的流程图语句覆盖为了说明简略，分别对各个判断的取真、取假分支编号为b、c、d、e。为了测试语句覆盖率只要设计一个测试用例就可以把三个执行语句块中的语句覆盖了。测试用例输入为：x=4、y=5、z=5程序执行的路径是：abd该测试用例虽然覆盖了每条可执行语句，但并不能检查判断逻辑是否有问题，例如在第一个判断中把&错误的写成了|，则上面的测试用例仍可以覆盖所有的执行语句（即查不出写错了这个事实）可以说语句覆盖率是最弱的逻辑覆盖准则使程序中每个语句至少执行一次判断覆盖 对于上面的程序，如果设计两个测试用例则可以满足分支
64、覆盖的要求。 测试用例的输入为： x=4、y=5、z=5 abd x=2、y=5、z=5 ace 上面的两个测试用例虽然能够满足分支覆盖的要求，但是也不能实现对判断条件的检查效果，如果把第二个条件y5错误地写成y3 取真值为T1，取假值为-T1条件2：z5 取真值为T4，取假值为-T4使程序中每个判断每个条件分别取真和取假各一次可以设计测试用例如下： 测试用例 通过路径 条件取值覆盖分支x=4、y=6、z=5 abdT1、T2、T3、T4 bdx=2、y=5、z=5 ace-T1、T2、-T3、-T4 cex=4、y=5、z=15 acdT1、-T2、T3、-T4 cd上面的测试用例不但覆盖了
65、所有分支的真假两个分上面的测试用例不但覆盖了所有分支的真假两个分支，而且覆盖了判断中的所有条件的可能值支，而且覆盖了判断中的所有条件的可能值 如果设计了下面的测试用例，则虽然满足了条件覆盖，但只覆盖了第一个条件的取假分支和第二个条件的取真分支，又不满足分支覆盖的要求（be线路未执行）测试用例 通过路径 条件取值覆盖分支x=2、y=6、z=5 acd-T1、T2、-T3、T4 cdx=4、y=5、z=5 acdT1、-T2、T3、-T4 cd使程序中每个判断的取真分支和取假分支至少执行一次需要改进：即需要改进：即判断判断- -条件覆盖条件覆盖判断-条件覆盖 条件-分支覆盖就是设计足够的测试用例，
66、使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行。 根据定义只需设计以下两个测试用例便可以覆盖8个条件值以及4个判断分支。 测试用例 通过路径 条件取值覆盖分支x=4、y=6、z=5 abdT1、T2、T3、T4 bdx=2、y=5、z=11ace-T1、-T2、-T3、-T4 ce条件-分支覆盖从表面来看，测试了所有条件的取值，但实际上，某些条件掩盖了另一些条件，即仍然有遗漏。例如：对于条件表达式(x3)&(z3）为假，则一般的编译器将不再判断是否（z5）来说，若x=4测试结果为真，就认为表达式的结果为真，这时不再检查（y5）是否为真。可见，采用分支条件覆
67、盖，逻辑表达式中的错误不一定都能查出来。条件组合覆盖：条件组合覆盖就是设计足够的测试用例，运行被测试对象，使得每一个判断的所有可能的条件取值组合组合至少执行一次。 现在对例子中的各个判断的条件取值组合加以标记如下：1.x3,z3,z=10 记做T1 -T2， 第一个判断的取假分支3.x=3,z0 记做-T1 T2， 第一个判断的取假分支4.x=10 记做-T1 -T2，第一个判断的取假分支5.x=4,y5 记做T3 T4， 第二个判断的取真分支6.x=4,y5 记做-T3 T4， 第二个判断的取真分支8.x!=4,y3)&(z5)根据定义取根据定义取4 4个测试用例，就可以覆盖上面个测试用例，
68、就可以覆盖上面8 8种种条件取值的组合测试用例。如下表：条件取值的组合测试用例。如下表：测试用例 通过路径 条件取值覆盖组合号x=4、y=6、z=5abdT1、T2、T3、T4 1和5 x=4、y=5、z=15 acdT1、-T2、T3、-T4 2和6 x=2、y=6、z=5 acd-T1、T2、-T3、T4 3和7 x=2、y=5、z=15ace-T1、-T2、-T3、-T4 4和8上面的测试用例覆盖了所有条件的可能取值的组合，上面的测试用例覆盖了所有条件的可能取值的组合，覆盖了所有判断的可取分支，但却丢失了路径覆盖了所有判断的可取分支，但却丢失了路径abeabe路径覆盖路径覆盖就是设计足够
69、多的测试用例，覆盖被测试对象中的所有可能路径在上面的测试用例中再添加一个测试用例，则可对程序进行全部的路径覆盖 测试用例 通过路径 覆盖条件 x=4、y=6、z=5 abdT1、T2、T3、T4x=4、y=5、z=15 acdT1、-T2、T3、-T4 x=2、y=6、z=15 ace-T1、-T2、-T3、-T4 x=5、y=6、z=5 abe-T1、-T2、-T3、-T4 voidSort(intiRecordNum,intiType)12intx=0;3inty=0;4while(iRecordNum-0)56if(0=iType)7x=y+2;8else9if(1=iType)10x=
70、y+10;11else12x=y+20;1314对这个C函数分别作六种覆盖1.1.语句覆盖：语句覆盖：2.2.判断覆盖判断覆盖第第1 1个用例：个用例：iTypeiType为为0 0第第2 2个用例：个用例：iTypeiType为为1 1while (iRecordNumwhile (iRecordNum - 0)- 0) if(0= =iType)if(0= =iType) x=y+2;x=y+2; elseelse if(1= =iType) if(1= =iType) x=y+10;x=y+10; elseelse x=y+20;x=y+20; 4.4.判断判断- -条件覆盖条件覆盖与判
71、断覆盖相同与判断覆盖相同iTypeiType为为0 03.3.条件覆盖条件覆盖与判断覆盖相同与判断覆盖相同5.5.条件组合覆盖条件组合覆盖与判断覆盖相同与判断覆盖相同第第3 3个用例：个用例：iTypeiType为为2 2基本路径测试voidDoWork(intx,inty,intz)voidDoWork(intx,inty,intz) intk=0,j=0;intk=0,j=0;ifif( (x3)&(z3)&(z5)(x=4)|(y5) )j=x*y+10;/j=x*y+10;/语句块语句块2 2 j=j%3;/j=j%3;/语句块语句块3 3 函数的流程图基本路径测试 这个例子是一个很简
72、单的程序函数，只有四条路径。但在实践中，一个不太复杂的程序，其路径都是一个庞大的数字，要在测试中覆盖所有的路径是不现实的。为了解决这一难题，只得把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行一次。下面介绍的基本路径测试就是这样一种测试方法，它在程序控制图的基础上，通过分析控制构造的环行复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。 在程序控制流图的基础上，通过分析控制构造的环形复杂度，导出基本可执行路径集合，从而设计测试用例。包括以下4个步骤和一个工具方法：1.程序的控制流图：描述程序控制流的一种图示方法2
73、.程序的环形复杂度：从程序的环形复杂度可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界3.导出测试用例：根据环形复杂度和程序结构设计用例和预期结果4.准备测试用例：确保基本路径集中的每一条路径的执行工具方法：图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。控制流图的符号在介绍基本路径方法之前，必须先介绍一种简单的控制流表示方法，即流图。每个构成元素都有一种相应的流图符号第一步：画出控制流图c/c+语句中的控制语句表示含义如下：图中的每一个圆称为流图的结点，代表一条或多条语句。流图中的箭头称为边或
74、连接，代表控制流。为了说明流图的用法，我们采用过程设计表示法，此处，流程图用来描述程序控制结构。可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。在流图中，每一个圆，称为流图的结点，代表一个或多个语句。一个处理方框序列和一个菱形决测框可被映射为一个结点，流图中的箭头，称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个结点，即使该结点并不代表任何语句(例如：参见if-else-then结构的符号)。由边和结点限定的范围称为区域。计算区域时应包括图外部的范围。任何过程设计都要被翻译成控制流图。voidSort(intiRecordNum,intiType)
75、12intx=0;3inty=0;4while(iRecordNum-0)56if(0=iType)7x=y+2;8else9if(1=iType)10x=y+10;11else12x=y+20;1314如下面的C函数：在将程序流程图简化成控制流图时，应注意： 在选择或多分支结构中，分支的汇聚处应有一个汇聚结点汇聚结点。 边和结点圈定的区域叫做区域。区域。当对区域计数时，图形外的区域也应记为一个区域。如何根据程序流程图画出控制流程图 ?voidSort(intiRecordNum,intiType)12intx=0;3inty=0;4while(iRecordNum-0)56if(0=iTyp
76、e)7x=y+2;8else9if(1=iType)10x=y+10;11else12x=y+20;1314画出其程序流程图如下：voidSort(intiRecordNum,intiType)12intx=0;3inty=0;4while(iRecordNum-0)56if(0=iType)7x=y+2;8else9if(1=iType)10x=y+10;11else12x=y+20;1314第二步：计算环形复杂度 环形复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用
77、到的边。有以下三种方法计算环形复杂度：1.流图中区域的数量对应于环型的复杂性；2.给定流图G的环形复杂度：V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量；3.给定流图G的环形复杂度：V(G)，定义为V(G)=P+1，P是流图G中判定结点的数量。 程序流程图和对应的控制流图如下：对应上面图中的环形复杂度，计算如下：流图中有四个区域；V(G)=10条边-8结点+2=4;V(G)=3个判定结点+1=4。第三步：导出测试用例 根据上面的计算方法，可得出四个独立的路径：路径1：4-14路径2：4-6-7-13-4-14路径3：4-6-8-10-13-4-14路径4：4-6
78、-8-11-13-4-14根据上面的独立路径，去设计输入数据，使程序分别执行到上面四条路径，即完成了测试用例的设计第四步：准备测试用例为确保基本路径集中的每一条路径的执行，根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到，满足上面例子基本路径集的测试用例是：路径1：4-14输入数据：iRecordNum0，或者取iRecordNum0的某一个值预期结果：x0路径2：4-6-7-13-4-14输入数据：iRecordNum1,iType0预期结果：x2路径3：4-6-8-10-13-4-14输入数据：iRecordNum1,iType1预期结果：x10路径4：4-6-8-11-
79、13-4-14输入数据：iRecordNum1,iType2预期结果：x20集成测试单元测试的测试环境B BA AC CD DE E待测试模块单元测试环境配置 许多模块不能用简单地进行充分的单元测试这种情况下完全的测试可放到集成测试阶段再进行单元测试的方法单元测试一般为编码步骤的附属部分模块不是独立的程序，自己不能运行，要靠其它部分来调用和驱动，在考虑测试模块时，同时要考虑它和外界的联系，即要为每个被测单元模块开发一些辅助软件去模拟与之相联系的其它模块。这些辅助软件一般包括：驱动模块驱动模块( (驱动程序驱动程序driverdriver):):相当于主模块相当于主模块桩模块桩模块( (测试存根
80、、连接程序测试存根、连接程序subsub):): 用以代替所测模块调用的子模块用以代替所测模块调用的子模块驱动模块和桩模块桩模块是为被测模块编制的、模拟其下级模块功能的“替身”模块，以代替被测模块的接口，接受或传递被测模块的数据，是专供测试用的“假”模块（集成之后就将被遗弃）例如模块A和模块B、C、D，集成测试时模块A要调用模块B、C、D，但此时模块B、C、D还没有被集成进来，就要用几个桩模块来暂时代替它们，如下图：CBDEAFA测试测试 AS2S2S1S1S3S3驱动模块和桩模块驱动模块作为测试驱动器开始进行集成测试，根据集成的实现方法(深度或广度优先)，下层的桩模块一次一个地被替换为真正的
81、模块。驱动模块主要完成以下任务： 接受测试输入； 对输入进行判断； 将输入传给被测单元，驱动被测单元执行； 接受被测单元执行结果，并对结果进行判断； 将判断结果作为用例执行结果输出测试报告。驱动模块、桩模块和被测单元都用同一种语言编写驱动模块、桩模块和被测单元都用同一种语言编写集成测试(组装测试)依据软件设计确定的软件结构，按照软件集成“工序”，把各个软件单元逐步集成为完整的软件系统，并不断发现和排除错误，以保证联接、集成的正确性主要目的：保证各个子功能模块之间的接口接口能正常工作通常采用黑盒测试技术+少量白盒测试技术（灰盒）由开发小组 & 测试组（部分参与完成）案例：案例：1999 1999
82、 美国火星极地探路者号探测器失踪事件美国火星极地探路者号探测器失踪事件集成测试需考虑的问题依据数据穿越接口可能丢失一模块可能破坏另一模块功能子功能组装可能未产生所要求的主功能全程数据结构可能出问题误差累积问题集成测试的要求必须对有调用关系的软件单元之间的所有调用进行测试，验证每个调用接口的完整性和一致性应对软件进行正确处理的能力和经受错误影响的能力进行测试测试在各种外部输入下，从外部接口采集和发送数据的能力，包括对正确数据及状态的处理，对接口错误、数据错误、协议错误的识别及处理集成测试的通过准则1）软件单元无错误地连接；2）满足各项功能、性能要求；3）对错误的输入有正确处理的能力；4）对测试中
83、的异常有合理解释；5）人机界面、对外接口正确无误；集成测试的内容1）软件单元的接口测试2）软件部件的功能、性能测试3）全面数据结构测试4）必要的运行时间、存贮空间、计算精度测试5）边界条件和非法输入的测试软件集成的策略1）非增量方式（Big Bang）先独立地测试好每一个软件单元，然后一次性全部组装在一起，再将整个软件作为一个整体进行测试2）增量方式 从一个模块开始测试,逐步把下一个已测好的软件单元或部件，同已测好的软件部件结合起来，再测试。每测完一个就添加一个，边组装边继续测试，直到整个系统组装完毕增量方式主要包括自顶向下（又包括深度优先和广度优先）、自底向上、自顶向下与自底向上相结合（“三
84、明治”）等方法增量和非增量方式的优缺点非增量方式的优点： a.非增量方式占用机器时间较少 b.非增量方式有利于并行开发增量方式的优点：a.增量方式占用人工较少b.增量方式可以较早地发现模块接口错误c.增量方式测试效果比较彻底非增量（Big Bang）方式是一种很直接、原始的组装方式，由于它一次性地把所有已通过单元测试的子模块一古脑儿地全部集成在一起，直接组装成最终的软件系统，再对之进行总体测试这种一起进行全程序的测试被贬义地称作大爆炸（Big Bang）。该方式目前仍在许多场合使用，人们期望它可以带来方便、快捷的组装效果但这种方法遭到广大测试专家的批评，普遍认为它会引起混乱，因为它在发现错误后
85、难以诊断和定位错误源的位置，又称“莽撞测试”Big Bang示意先独立地测试好每一个软件单元(b)，然后一次性全部组装在一起，再将整个软件作为一个整体进行测试增量方式又称渐增式组装渐增式组装首先对一个个模块分别进行模块测试，然后将这些模块逐步组装成较大的系统在组装的过程中，边连接边测试，以发现连接过程中产生的问题（如接口处）通过增量逐步组装成为最终符合预期要求的软件系统自顶向下方法一个模块一个模块地组装软件的方法，每组装一个都要测试一次按照控制的结构，从主控模块（主程序）开始，向下地逐个把模块连接起来集成的方式有两种：深度优先法及广度优先法深度优先法是先把结构中的一条主要的控制路经上的全部模块
86、逐步组装起来。然后再连接其它的控制路径广度优先法是从结构的顶层开始逐层往下组装自顶向下集成的过程步骤1）主控模块用作为测试驱动器。直接附属于主控模块的各模块全都用桩模块代替2）按照所选的组装法（即深度优先或广度优先）每次用一个真模块取代一个附属的桩模块3）当装入每个真模块时都要进行测试4）作完每一组测试后又再用一个真模块代替另一个桩模块5）可以进行回归测试（即重新再做一遍过去做过的全部或部分测试），以便肯定没有新的错误发生自顶向下结合方式示意图ADBECF模块测试结合顺序深度优先:A、B、E、C、D、F广度优先:A、B、C、D、E、FA测试测试 AS2S2S1S1S3S3A加入加入B并测试并测
87、试ABS2S2BS3S3S4S4A加入加入E并测试并测试ABES2S2BS3S3EA加入加入C并测试并测试ABECCBS3S3E加入加入D并测试并测试ABECDCBDE加入加入F并测试整体并测试整体CBDEAAFS5S5深度优先的自顶向下集成示意Q Q：ABCDEFABCDEF这这6 6个子模块中，哪一个得到的测试最充分？个子模块中，哪一个得到的测试最充分？自底向上方法自底向上集成测试方法是从软件结构中最底层的、最基本的软件单元开始进行集成和测试由于在逐步向上组装过程中下层模块总是存在的，也就是说不再需要桩模块了，但却需要用于调用这些模块开展工作的驱动模块驱动模块自底向上集成的过程步骤1）低层
88、的模块组成簇以执行某个特定的软件子功能2）编写一个驱动模块作为测试的控制程序，和被测试的簇连在一起，负责安排测试用例的输入及输出3）对簇进行测试4）拆去各个小簇的驱动模块,把几个小簇合并成大簇，再重复做2、3、4步 就这样在软件结构上逐步向上组装McD1MaMbD2D3簇簇1 1簇簇2 2簇簇3 3自底向上集成示意自底向上集成示意A AC CB BD DF FE EE Ed d1 1C Cd d3 3F Fd d4 4B Bd d2 2E ED Dd d5 5F F自底向上集成示意二者的比较自顶向下自底向上 优点可在测试早期实现并验证系统主要功能设计上的缺陷会尽早体现设计测试用例比较容易底层模
89、块能够得到更为充分的测试 缺点底层模块不能充分测试只有到最后程序才能作为一个整体呈现，设计缺陷难以及时被发现 一般对软件结构的上层使用自顶向下结合的方法；一般对软件结构的上层使用自顶向下结合的方法； 对下层则使用自底向上结合的方法对下层则使用自底向上结合的方法(“(“三明治三明治”方法方法) )“三明治”方法自顶向下测试的主要优点是能较早显示出整个程序的轮廓。主要缺点是当测试上层模块时使用桩模块较多，很难模拟出真实模块的全部功能，使部分测试内容被迫推迟，直至换上真实模块后才能补充测试自底向上测试则从下层模块开始，设计测试用例比较容易，但是在测试的早期无法显示出程序的轮廓针对自顶向下、自底向上方
90、法各自的优点和不足，人们提出了自顶向下和自底向上相结合，从两头向中间逼近的混合式组装方法，并形象地称之为“三明治”方法“三明治”方法的步骤步骤： 对上层模块采取自顶向下测试 对关键模块或子系统采取自底向上测试如对关关键键模模块块采取自自底底向向上上测试，就可能把输入输出模块提前组装进程序，使设计测试用例变得较为容易；或者使具有重要功能的模块早点与有关的模块相连，以便较早暴露可能存在的问题。除关键模块及少数与之相关的模块外，对其其余余模模块块尤尤其其是是上上层层模模块块仍采取自自顶顶向向下下的测试方法，以便较早显示程序总体轮廓系统测试（黑盒测试）系统测试占全部测试工作的70%以上由专门的测试人员
91、完成外包的测试公司专门的测试部采用黑盒测试等价类、边界值、因果图等具体方法此阶段不可避免地是发现缺陷的集中阶段此阶段发现的缺陷，要修改就得伤筋动骨如博彦科技惠普、微软、NEC信必优、华为、亿阳等文思创新 微软、IBM黑盒测试方法目前阶段最常用的两个（动态）黑盒测试方法：等价类划分法经典例子：判断三角形形状边界值法经典例子：软件的登陆界面创建测试用例是测试员的基本工作测试用例的存在意义，是揭示软件缺陷但测试用例往往数量巨大（因而不能做到彻底执行测试）“能否揭示软件缺陷”，是测试用例的质量高低的评价准则测试员的思考方式，就是在多个合理用例之间进行权衡，决定放弃哪一部分，采用哪一部分换言之，就是将海
92、量的测试用例集缩减到可操作的数目，同时也不造成缺陷的遗漏划分等价类后等价类法的引入可以用可以用一个一个有代表性的用例，代替一组有代表性的用例，代替一组等效等效的的多个多个用例用例以“计算器”中的加法运算的测试过程为例：我们已经知道，两个加数的可能值非常多，都能够作为测试用例，因此不可能做到完全彻底地测试。那么如何选取有代表性的、数目有限的测试用例？Q1：加数可以是什么？整数、小数、负数Q2：加数不应该是但可以是什么？不应该是，就是非法的数据；可以是，就是用户有能力输入的数据Q3：对于这类数据（注意：这个词的含义是广泛的，也包括汉字等非数字数据），我们应该关注吗？现实之中的等价类如：测（汉字）a
93、（字母）#（特殊符号）等这就是三个划分得较粗略的等价类不但应该关注，还应该重点关注注 意具体如何划分等价类，有较强的主观性针对同一个测试对象如何划分等价类，并无标准答案具体做法：先凭规则，再凭经验但所有的划分方式，都遵循以下原则：尽量避免选择了完全等效的测试用例具体划分等价类们组成了全部可能的输入数据，没有遗漏等价类之间没有交集同一个等价类内部不存在异类等价类中的所有数据，在揭示程序中缺陷方面的价值和能力是相等的换言之：如果从某个等价类中任意一个测试用例未能发现程序缺陷，该类中其它测试用例也不会发现程序的缺陷定 义等价类是指某个输入域的子集，在把全部输入数据的可能值合理地划分为若干等价类后，在
94、每一个等价类中取一个数据作为测试用例，代表这个类中的全部其它测试数据，以较少的时间来取得较好的测试结果有效等价类和无效等价类有效等价类和无效等价类 有效等价类：有效等价类：是指对于程序的规格是指对于程序的规格说明来说，是合理的，说明来说，是合理的，有意义的输入数据构有意义的输入数据构成的集合成的集合。 无效等价类：无效等价类：是指对于程序的规格说是指对于程序的规格说明来说，是不合理的，明来说，是不合理的，无意义的输入数据构成无意义的输入数据构成的集合。的集合。n n在设计测试用例时，要同时考虑有效等价类和无效在设计测试用例时，要同时考虑有效等价类和无效等价类的设计等价类的设计n n事实上，后者
95、正是揭示缺陷的有力工具事实上，后者正是揭示缺陷的有力工具“计算器”中的加法运算测试（等价类法） 有效等价类：整数小数负数以上各种合法数据的组合 无效等价类：汉字特殊符号字母以上是一些较容易想到的输入数据以上是一些较容易想到的输入数据一些特殊的无效等价类：含有多个负号的合法数据含有多个小数点的合法数据一个合法，多个非法在特定位置上合法换个角度划分等价类 In输入数据时途径的不同：用键盘用软键盘从剪贴板中复制过来用小键盘区的数字和符号n输入的过程存在删除字符的情况：用光标定位后正常删除选中部分后输入一些新数据选中部分后剪切选中部分后从剪贴板中粘贴过来一些新内容覆盖n合法运算数中的特殊数据：运算数中
96、含有0的两数互为相反数的负数是第一个操作数的n输入数据所占字节的不同：全角数字/符号半角数字/符号换个角度划分等价类 IIn应该等效的操作：键盘输入/界面上的数字、操作按钮Ctrl+c与菜单功能项“复制”Ctrl+v与菜单功能项“粘贴”n在计算机文本框中可以使用的功能键：Home、End方向键F1删除键划分等价类的原则：1如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类例如对输入 “ 项数可以从1到999 ” 有效等价类是“1项数999”两个无效等价类是“ “项数项数1 1” ” 或或 “ “项数项数999999” ”划分等价类的原则：2如果输入条件规定了输入值
97、的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类例如在Pascal语言中对变量标识符规定为“以字母打头的串”所有以字母打头的构成有效等价类不在此集合内（不以字母打头）的归于无效等价类划分等价类的原则：3如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类 “真”和“假”各一划分等价类的原则：4如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。这时可为每一个输入值确立一个有效等价类，此外针对这组值确立一个无效等价类，它是所有不允许的输入值的集合例如：在教师上岗方案中规定对教授、副教授、讲师和助教分别计算分数，做相应的处理因此可以确定4个
98、有效等价类为教授、副教授、讲师和助教一个无效等价类，它是所有不符合以上身分的人员的输入值的集合同类例子：判断输入的是哪一种字符划分等价类的原则：5如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）例如：Pascal语言规定 “一个语句必须以分号;结束”可以确定一个有效等价类 “以;结束”若干个无效等价类 “以:结束”、“以,结束”、“以 结束”等划分等价类的原则：6如已划分的等价类各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类n输入的过程存在删除字符的情况：正常删除用delete删除用backspace删除选中部
99、分后输入一些新数据按下空格按下任意键选中部分后从剪贴板中粘贴来一些内容覆盖n应该等效的操作：键盘输入/界面上的数字、操作按钮Q：是否所有计算器界面上的功能键，在都键盘上有对应等效的键位？本例仍可继续细分n输入的过程存在删除字符的情况：正常删除选中部分后输入一些新数据按下空格按下任意键数字字符键合法的数字字符非法的数字字符功能控制键和本计算器软件有关的功能控制键和本计算器软件无关的功能控制键预期结果该数字出现在原来所选中的位置，覆盖选中的内容仅有提示音，并不接收任何输入，文本框内容不变产生反应，如按F1会弹出帮助同注：每一个细化到极点的等价类，都是个需要关注的测试点情况越特殊，就越有可能发现新的
100、缺陷选取测试用例在确立了等价类之后，建立等价类表，列出所有划分出的等价类，形成等价类表，每一等价类规定一个唯一的编号 从划分出的等价类中按以下原则选择测试用例：(1) 为每一个等价类规定一个唯一编号；(2) 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；(3) 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止注 意划分等价类不仅要考虑代表“有效”输入值的有效等价类，还需重点考虑代表“无效”输入值的无效等价类每一个无效等价类至少要用一个测试用例，不然就可能漏掉某一类错误，但允许
101、若干有效等价类合用同一个测试用例，以便进一步减少测试的次数某报表处理系统要求用户输入处理报表的日期，日期限制在2003年1月至2008年12月，即系统只能对该段期间内的报表进行处理，如日期不在此范围内，则显示输入错误信息 系统日期规定由年、月的6位数字字符组成； 前四位代表年，后两位代表月；等价类法设计测试用例实例 1如何用等价类划分法来设计测试用例，以测试该程序的日期检查功能？第一步：形成等价类表“报表日期”输入条件的等价类表输入条件 有效等价类 无效等价类 报表日期的类型及长度6位数字字符(1)有非数字字符 (4)少于6个数字字符 (5)多于6个数字字符 (6)年份范围在20032008之
102、间 (2)小于2003 (7)大于2008 (8)月份范围在112之间(3)小于1 (9)大于12 (10)第二步：为有效等价类设计测试用例 对表中编号为1,2,3的三个有效等价类用一个测试用例覆盖： 测试数据 期望结果 覆盖范围200306等价类(1)(2)(3)输入有效(1)6位数字字符(2)年在20032008之间 (3)月在112之间第三步：为每一个无效等价类设至少设计一个测试用例 测试数据 期望结果 覆盖范围003MAYMAY等价类(4)输入无效20035等价类(5)输入无效2003005等价类(6)输入无效2001200105等价类(7)输入无效2009200905等价类(8)输入
103、无效20030000等价类(9)输入无效20031313等价类(10)输入无效不能出现相同的测试数据本例的本例的1010个等价类个等价类至少需要至少需要8 8个测试用例个测试用例有非数字字符 (4)少于6个数字字符 (5)多于6个数字字符 (6)小于2003 (7)大于2008 (8)小于1 (9)大于12 (10)等价类划分设计测试用例实例2对某考试系统“输入学生成绩”子模块设计测试录入准考证号的测试用例准考证号数据格式定义：共6为数字组成，其中第一位为专业代号:1 1-行政专业，2 2-法律专业，3 3-财经专业；后5位为考生顺序号，编码范围为： 行政专业准考证号码为：1 1100011
104、111215 法律专业准考证号码为：2 2100012 212006 财经专业准考证号码为：3 3100013 314015有效等价类有效等价类: : (1) 110001 (1) 110001 111215 111215(2) 210001 (2) 210001 212006 212006(3) 310001 (3) 310001 314015 314015无效等价类无效等价类: : (4) - (4) - 110000110000(5) 111216 (5) 111216 210000 210000(6) 212007 (6) 212007 31000 31000(7) 314016 (7
105、) 314016 + + 准考证号码的等价类划分等价类划分设计测试用例实例 3某一PASCAL语言版本中规定：“标识符是由字母开头，后跟字母或数字的任意组合构成。有效字符数为8个，最大字符数为80个。”“标识符必须先说明，再使用。” “在同一说明语句中，标识符至少必须有一个。”建立输入等价类表字母开头后跟字母或数字的任意组合有效字符数为8最大字符数为80标识符必须先说明，再使用同一说明语句中，标识符至少必须有一个“标识符是由字母开头，后跟字母或数字的任意组合构成。有效字符数为8个，最大字符数为80个。” “标识符必须先说明，再使用。” “在同一说明语句中，标识符至少必须有一个。”为输入等价类加
106、上标号覆盖所有等价类的测试用例 VAR VAR x x，T1234567T1234567：REALREAL；BEGIN BEGIN x x := 3.414 := 3.414；T1234567 := 2.732T1234567 := 2.732；. . (1), (2), (4), (8), (9), (12), (14)(1), (2), (4), (8), (9), (12), (14) VAR VAR ：REALREAL； (3)(3)标识符个数为零标识符个数为零VAR VAR x x，：，：REAL; REAL; (5) (5)标识符中字符数目（长度）为标识符中字符数目（长度）为0 0
107、、1 1VAR VAR T12345678T12345678：REALREAL； (6)(6)标识符中字符数目（长度）大于标识符中字符数目（长度）大于8 8 VAR VAR T12345.T12345.：REALREAL； (7) (7) 省略号表示标识符中字符长度多于省略号表示标识符中字符长度多于8080 VAR VAR T$T$：CHARCHAR； (10)(10)标识符中有非字母数字字符标识符中有非字母数字字符 VAR VAR GOTOGOTO：INTEGERINTEGER； (11)(11)标识符中有系统保留字标识符中有系统保留字 VAR VAR 2T2T：REALREAL； (13)
108、(13)标识符的首字符不是字母标识符的首字符不是字母 VAR VAR PARPAR：REAL REAL ； BEGIN . BEGIN . PAPPAP := SIN (3.14 * 0.8) / 6 := SIN (3.14 * 0.8) / 6； (15)(15)标识符未经说明就使用了标识符未经说明就使用了一个语句中标识符为多个；标识符中字符数目（长度）为一个语句中标识符为多个；标识符中字符数目（长度）为1 1个、多个；个、多个；标识符由字母、数字构成；标识符的首字符是字母；标识符先说明后使用标识符由字母、数字构成；标识符的首字符是字母；标识符先说明后使用2009.10.30杭州市文晖路实
109、景杭州新修路面沉降水管破裂 全城大堵车软件往往是极端的：要么对；要么不对如果程序代码是针对一定范围内的数据进行操作，往往对此范围内的绝大多数数据都是正确的，但在这个范围的边界处就不一定了在做三角形计算时，要输入三角形的三个边长A、B 和 C这三个数值应当满足：A0、B0、C0、ABC、ACB、BCA如果把六个不等式中的任何一个大于号“”错写成大于等于号“”就不能构成三角形软件边界与悬崖很类似如果在悬崖峭壁边可以自信地安全行走，平地就不在话下如果软件在环境压力达到极限时仍然能够正常运行，那么在普通情况下就不会出什么问题等价类中的边界数据回顾我们之前提过的WINDOWS计算器程序，你觉得哪些用例可
110、以放心地舍弃呢？从测试数据的外表上看，哪些用例可能导致危险的结果，哪些基本不会得到错误的结果呢？我们可以认为：1+5、1+6、1+7大致等效本能和编程经验会提醒我们：1+99就不一样了，这里属于计算器软件中“正整数加法”数据等价类中，文本框能容纳的数据位数之最大值，比它再大，就超过了系统能够显示的数据的极限，在此处理不当也许会出现溢出现象 正常的加法、边界点上和边界点附近的加法，分别属于两个独立的划分，在两者中各取一个测试用例，就将近乎无限次测试缩减为两次加数99是录入文本框中允许的长度最大值，也是一个位于加数边界的值。等价类中有普通的值，也有位于边界上的值，后者更容易揭示出软件缺陷。边界问题
111、是怎么产生的DIM DATA（10） AS INTEGERDIM i AS INTEGERFOR i=1 TO 10DATA（i）=-1NEXT i 这个程序段里，定义了一个长度为10的整型数组，并利用循环为数组的每一个元素赋了初值-1。看起来编程者的动机是这样的FOR i=1 TO 10但根据语法，该程序实际创建的是从DATA（0）到DATA（10）共11个元素，上述程序段实际完成的是后10个元素的初始化，而第一个元素data（0）还保持着创建时系统自动赋的初值0不变。但在实际使用时，会以为第一个元素也已被赋为-1了又是边界问题对于语法不熟练、未完全掌握业务逻辑的开发者，非常容易忽略边界上需
112、要特殊处理的特殊情况，于是形成软件缺陷所谓边界值分析，就是选择这样的测试用例：它能使被测试程序在每个等价类的边界值及其附近运行，从而更有效地暴露程序中隐藏的错误可见，问题恰出现在容易被疏忽的边界附近在划分好等价类后，我们应着重分析每个等价类的边界值选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据边界值法长期经验表明，大量的错误是发生在输入或输出范围的 边界上，而不是在输入范围的内部边界是指相当于输入、输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况边界上更容易出错，因而在等价类的边界上选择测试值，有更好的效果边界值法建立在等价类划分成功的前提上：我们要选取的是：每个等价类的边界
113、处的数据测试边界线测试临近边界的合法数据，以及刚超过边界的非法数据越界测试通常是简单地加1或很小的数 (对于最大值) 和减1或很小的数 (对于最小值)被测试被测试子子 域域测试内点测试内点测试外点测试外点围绕围绕边界条件边界条件进行等价划分，是减少无谓工作量的关键进行等价划分，是减少无谓工作量的关键边界条件类型新手往往意识不到在一组给定的数据包含多少边界。以下是一些规律： 如果软件测试问题包含确定的边界,那么数据类型可能是:数值字符位置数量速度地址尺寸针对它们要考虑的特征:第一个/最后一个最小值/最大值开始/完成空/满最慢/最快相邻/最远超过/在内一些常见的边界值例子一些常见的边界值例子1.如
114、果一个文本区允许输入最长255个字符2.用刻录软件向光盘中刻录信息3.在使用打印机打印PPT演示文稿的讲义时5.5.例如一个情报检索系统根据某一输入请求，显示有关文例如一个情报检索系统根据某一输入请求，显示有关文献的摘要，但不能多于献的摘要，但不能多于 4 4 条摘要条摘要4.在一个购物网站中的送货地址部分输入邮政编码项具体策略具体策略1.如果一个文本区允许输入最长255个字符，就尝试先分别输入1个字符和255个字符（这两种情况代表合法输入），再输入0个字符和256个字符（代表非法的输入）2.用刻录软件向光盘中刻录信息，先尝试保存一个极小的文件；之后再保存一个极大的文件（选择添加该文件后，总容
115、量刚好在光盘限定的最大容量之内）；之后再尝试保存一个空文件；或一个刚好超过光盘容量的文件（4种情况）3.在使用打印机打印PPT演示文稿的讲义时，如果允许在一页纸上打印多个页面，那么先尝试只打印一页，再尝试打印允许的最多页面，如果允许自己手动填写打印页数，再尝试输入打印0页和打印允许最多的页数+1页的情况5.5.例如一个情报检索系统根据某一输入请求，显示有关文献的摘要，例如一个情报检索系统根据某一输入请求，显示有关文献的摘要，但不能多于但不能多于 4 4 条摘要，那么就可以设计一些测试用例，使得程序条摘要，那么就可以设计一些测试用例，使得程序分别显示分别显示 1 1 篇、篇、 4 4 篇或篇或
116、0 0 篇摘要，并设计一个有可能使程序错篇摘要，并设计一个有可能使程序错误地显示误地显示 5 5 篇摘要的测试用例篇摘要的测试用例6.如果程序的输入域或输出域是个有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例4.在一个购物网站中的送货地址部分输入邮政编码项： 输入位如果为000000，那么可以尝试999999，再尝试负数9.9.如果程序中定义了一个数组，其元素下标的下界是 0 ，上界是 100 ，那么应选择达到这个下标边界的值如 0 和 100 作为用例8.有个程序计算每月的保险金额，若最小额是 0 元，最大额是 1000 元，那么就应设计导致扣除 0 元和 1000 元的测试数
117、据。另外还应考虑是否可设计使程序扣除负额或大于 1000 元的测试数据7.如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例 有一定编程经验和理工背景的人，会有看出边界点的本能倾向即找“特殊值”：使分母为零；使根号下的表达式值为零；使正切函数自变量为零；定长数组最后一个元素的引用是否不当等情况 边界条件处的软件缺陷最常见的问题是导致缓冲区溢出这是造成软件安全问题的主要原因次边界条件边界条件相对容易找到，其中多数可以从产品说明书中推断，或试用软件时明显地发现，但有些边界位于软件内部，不那么直观。而它们也一样是容易出错的地方我们称它们为次边界。要找到它们，不需要测
118、试员彻底了解代码，但是要大体了解软件的工作方式一个常见的次边界条件数字范围、大写字母、小写字母范围两侧的字符，都属于内部边界，即次边界假设我们在测试一个文本输入或文本转换的软件，如果测试其中“文本框应该只接受字母或数字输入”功能，那么在非法的测试数据中就应该包含A、Z、a、z四个字符前后的字符（见框内的/、 、 、 、 ） / /，0 0， 9 9， ， A A， Z Z， ， ， a a， z z， ，484757656490919697122 123我们所熟悉的ASCII码表：边界值分析法与等价类划分法的区别 边界值分析法不仅要考虑程序的输入空间，而且要根据输出空间设计测试用例 使用边界值
119、分析方法设计测试用例，应对确定的边界，选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。即使这个等价类的每个边界值都要作为测试数据特殊情况下的测试数据默认值、空白、空值、零值一种看起来很明显的软件缺陷是：当软件要求用户提供输入时（在文本框中），用户不是“没有输入正确的数据”，而是“根本没有输入任何内容”，却按了ENTER或“确定”键，按照正常的顺序这些键是应该在给出输入后才按下的l 这种情况在开发时经常被程序员遗忘，在产品说明书中也不提及，可是其发生频率是相当高的l好的软件，会针对这类情况给予专门的处理：例如在WINDOWS自带画图工具中，
120、某菜单项提供了调整图片尺寸的功能，需要用户输入要调整到的宽度和高度，如果用户不慎将此二文本框内容清零，并单击确定，结果如何？WINDOWSWINDOWS自带画图工具是这样处理的自带画图工具是这样处理的此类情况下，理想的处理方式是：不理会用户提交的无意义数据（不论是否有意），而是自动取某个合法的宽度和高度作为默认值自动输入，使操作流程能继续下去刚才的处理方式是次一等的：只是单纯地提示用户，这样做不符合系统规定，并拒绝接受用户提交的无意义数据后一种处理方式比前一种，差在哪里？假设用户不能理解系统所给出提示的意思，也无法按照提示重新提交一组正确的数据，那么如果本操作恰好是某一个复杂功能的中间步骤，那
121、么用户将卡在这一操作步骤上无法前进。第一种方式就不会产生这样的局面 对于程序中容易出错的情况，以下是一些经验：例如：输入数据为零或输出数据为零往往容易发生错误；如果输入或输出的数目允许变化（例如，被检索的或生成的表的项数），则输入或输出的数目为 0 和 1 的情况（例如，表为空或只有一项）是容易出错的情况还应该仔细分析程序规格说明书，注意找出其中遗漏或省略的部分，以便设计相应的测试方案，检测程序员对这些部分的处理是否正确 选择输入组合的一个有效途径是把计算机测试和人工检查代码结合起来。例如，通过代码检查发现程序中两个模块使用并修改某些共享的变量，如果一个模块对这些变量的修改不正确，则会引起另一
122、个模块出错，因此这是程序发生错误的一个可能的原因。应该设计测试方案，在程序的一次运行中同时检测这两个模块，特别要着重检测一个模块修改了共享变量后，另一个模块能否像预期的那样正常使用这些变量反之，如果两个模块相互独立，则没有必要测试它们的输入组合情况 数据测试的最后一种，是垃圾数据数据测试的最后一种，是垃圾数据在已经利用边界测试、次边界测试、默认值测试等方法验证在已经利用边界测试、次边界测试、默认值测试等方法验证“软件能够工作软件能够工作”了之后，就应该进行垃圾数据测试了了之后，就应该进行垃圾数据测试了垃圾数据测试，属于失效性测试，对应于现实使用中外行用户的失误操作如果一个用户自身的错误操作导致
123、数据丢失或系统崩溃，那么他要指责的肯定不是自己，而是开发方用户的要求永远是正确的，用户的操作永远是合理的作为测试员，就要化身为用户抢先给出种种或离奇或弱智的操作和数据，考验系统。此时思维习惯就显得很重要常见的垃圾数据常见的垃圾数据软件要求输入数字，我们就输入字母；软件要求输入数字，我们就输入字母；软件只接受正数，我们就输入负数；软件只接受正数，我们就输入负数；如果软件对日期敏感，我们就考察它能否在公元如果软件对日期敏感，我们就考察它能否在公元30003000年时还年时还能工作；能工作；或者有意不看准键盘就按下（模拟某些天生手指粗大的用户）或者有意不看准键盘就按下（模拟某些天生手指粗大的用户）有
124、意同时按下多个键；有意同时按下多个键；这类测试是没有规则可言的，唯一的目的就是破坏软件，这类测试是没有规则可言的，唯一的目的就是破坏软件，要发挥创造力，乐在其中要发挥创造力，乐在其中猜错法又叫错误推测法(errorguessing)使用边界值分析和等价划分技术，可以设计出具有代表性的、容易暴露程序错误的测试方案。但是，不同类型不同特点的程序通常又有一些特殊的容易出错的情况。一般说来，即使是一个比较小的程序，可能的输入组合数也往往十分巨大，因此必须依靠测试人员的经验和直觉，从各种可能的测试方案中选出一些最可能引起程序出错的方案。对于程序中可能存在哪类错误的推测，是挑选测试方案时的一个重要因素 n
125、错误推测法的基本想法是推测出程序中可能有的错误和容易发生错误的特殊情况，并且根据它们有针对性地编写检查这些错误的例子。本方法在很大程度上依赖于测试人员的直觉、经验和预感进行错误推测法是：n有力的补充n充分发挥敏锐、经验等能力n直接切入可能的错误，直接定位n需要丰富的经验和领域知识性能测试性能测试 当做性能测试时，需要注意观察什么？时间性能：反应速度空间性能：对系统资源的占用 “环境”都包括什么？开发环境（单一）测试环境（最多样）用户环境（微观单一，宏观多样）三者的关系应该是：开发环境和用户环境差别最大，且也不必一致但是测试环境，必须最大程度地贴近用户环境 “环境”应该：真实、干净、无毒、独立（
126、相对于开发环境） 性能依赖于环境性能测试相关理论性能测试的概念及其主要指标主要的性能测试工具性能测试的主要类别性能测试的概念及其主要指标性能测试 主要通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试 。多线程或多进程的方式模拟多个虚拟用户性能测试的概念及其主要指标概念 性能的覆盖面非常广泛，对一个软件系统而言包括：执行效率、资源占用、系统稳定性、安全性、兼容性、可靠性、可扩展性等负载测试 通过逐步增加系统负载测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量压力测试 通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么
127、负载条件下系统性能处于失效状态，以获得系统能提供的最大服务级别几个性能测试的实际应用场景某个产品要发布了，需要对全市的用户做集中培训（此种情况需模拟真实用户数，如果一台机器性能不够可以考虑部署几套系统，平时不会如此多用户并发）开发完成，总觉得某部分存在性能问题，但是又说不清楚到底是什么地方存在性能瓶颈同一系统现可以采用两种构架Java、.Net，决定用哪一个一门户网站能够支持多少用户并发操作（注册、写博客、看照片)主要指标响应时间吞吐量（单位时间从服务器获得的数据量）并发用户资源利用率（内存、CPU等的利用率等）主要指标用户角度响应时间（用户最重视的性能体验）2/5/10原则(很好/还不错/忍
128、受极限）过长时间的等待会让客户烦躁不安稳定性（系统的崩溃带来的直接是用户的崩溃）HTTP 500 数据库崩溃应用服务器崩溃主要指标系统角度网络运行情况硬件配备情况软件的配置情况（应用服务器/数据库/系统）影响性能的因素先后顺序网络状况硬件设备系统/应用服务器/数据库配置数据库设计和数据库访问实现业务的程序实现主要指标开发角度系统的框架设计不合理对应用的技术不熟悉数据库模型设计不合理SQL语句实现性能低下开发人员经验不足（算法、代码烦琐，浪费时间）主要的性能测试工具商业Mercury Loadrunner （集成到ide的插件）Rational Performance Tester（集成到ide
129、的插件）WebLoad免费Web Application Stress ToolApplication Center Test 开源OpenSTAJmeter（两个文档）Grinder自行开发（针对某一个具体的软件的一部分进行测试）性能测试的实施过程实施过程了解被测试项目的性能测试需求分析被测试项目的性能测试需求编写性能测试计划/测试用例相关资源准备l脚本维护（编写程序）l执行脚本（执行程序）l分析结果l性能调优实施过程性能测试需求性能测试需求（测试的目标）响应时间复杂查询反应时间小于15秒简单查询反应时间小于5秒持续运行时间并发用户量资源计数器CPU平均时间不得超过85%可以使用内存不得低于
130、100M实施过程分析性能测试需求分析性能测试需求响应时间的确定（依据具体的业务）哪些是系统经常用到的业务并发用户量的确定（可以估计或者通过日志得到）增加、删除、查询、修改至少都要做一个脚本可扩展的空间（1年后，用户量增加。）实施过程性能测试计划/用例性能测试计划/用例覆盖测试的需求测试的周期和风险的评估人力资源、硬件资源、软件资源的配备测试的手段和工具应在测试计划中有所体现增加、删除、查询、修改至少都要做一个脚本可扩展的空间（应依据具体的需求决定取舍测试）举例如：一个进销存系统，包括登录、货物入库、订单处理、货物出库、查询五个模块用例设计：针对模块设计用例场景设计：场景1: 10登录，10入库
131、，30订单，20出库， 30查询 （1000 用户）日常场景2: 10登录，90查询（400 用户）周末盘点性能测试技术概述序号序号类型类型详细描述详细描述1用户行为模拟低成本且具有可行性，模拟大量用户操作的一种技术，借助这种技术将被测试系统在测试阶段运行起来，以检测系统工作是否正常不同用户使用不同的数据多用户并发操作用户请求间的依赖关系及请求间的延时时间2性能指标监控通过上面技术模拟用户的行为，在系统运行中需要监控各项性能指标，并分析指标的正确性请求响应时间监控服务器处理能力监控服务器资源利用率监控3性能调优通过指标的监控发现系统存在的性能缺陷，利用分析工具，定位修正性能问题测试技术总览测试
132、技术总览不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。也称为静态分析技术。实际运行程序，并通过观察程序运行的实际结果来发现错误的软件测试技术。在不知道程序内部结构，只知道程序规格的情况下采用的测试技术或策略。在知道程序内部结构的情况下采用的测试技术或策略。开发组内部进行的，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。开发组内部进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。开发组、测试组和相关人员(QA、产品经理等)联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般
133、有正式的计划、流程和结果报告。针对要求的程序功能，按照规范的流程进行的测试。针对要求的程序功能以外的其他要求，包括性能、安全、配置、负载等指标，按照规范的流程进行的测试。针对要求的程序功能、性能、安全、配置、负载等指标，基于破坏目的、按照经验进行的随机测试。程序修改或者版本更新以后，为了确保以前正确的功能和其他指标仍旧正确，而重新进行的测试。在测试过程中，选择足够的测试用例，使得每一个可执行语句至少被执行一次。在测试过程中选择足够的测试用例，使程序中的每一个分支判断的每一种可能结果都至少被执行一次。在测试过程中，选择足够的测试用例，使得程序中的每一条可能执行的路径都至少执行一次。手工测试：黑盒
134、、白盒、灰盒手工测试：黑盒、白盒、灰盒自动化测试自动化测试( (机器测试机器测试) )：通过编制脚本控制机器自动执行测试用例通过编制脚本控制机器自动执行测试用例按测试方法分类按测试方法分类黑盒测试与白盒测试能发现的错误黑盒测试与白盒测试能发现的错误C CB BA AD D- -只能用黑盒测试发现的错误只能用黑盒测试发现的错误A- -只能用白盒测试发现的错误只能用白盒测试发现的错误- -用两种方法都能发现的错误用两种方法都能发现的错误- -用两种方法都不能发现的错误用两种方法都不能发现的错误BCD测试阶段测试阶段 主要依据主要依据 测试人员、测试方式测试人员、测试方式 主要测试内容主要测试内容
135、单元测试单元测试系统详细系统详细设计文档设计文档由开发小组执行白盒测由开发小组执行白盒测试试 路径测试（主要）路径测试（主要）接口测试（次要）接口测试（次要）集成测试集成测试系统概要系统概要设计文档、设计文档、需求文档需求文档由开发小组执行白盒测由开发小组执行白盒测试和黑盒测试试和黑盒测试 接接口口测测试试、路路径径测测试试（主要）（主要）功能测试、性能测试功能测试、性能测试 （次要）（次要）系统测试系统测试需求文档需求文档由独立测试小组执行黑由独立测试小组执行黑盒测试盒测试 功能测试、健壮性测试、功能测试、健壮性测试、性能测试、用户界面测性能测试、用户界面测试、安全性测试、压力试、安全性测试
136、、压力测试、可靠性测试、安测试、可靠性测试、安装装/反安装测试反安装测试 等等验收测试验收测试需求文档需求文档 由用户执行黑盒测试由用户执行黑盒测试 状态场景测试状态场景测试拿到一个软件后，可将其分为拿到一个软件后，可将其分为数据部分数据部分和和程序部分程序部分。要针对它们分别进行测试。要针对它们分别进行测试。对数据进行测试，就是检查对数据进行测试，就是检查用户输入、中间结果、最终返回值用户输入、中间结果、最终返回值是否都是否都正确无误（我们之前做的都是）。正确无误（我们之前做的都是）。对程序进行测试，就是对程序进行测试，就是状态测试状态测试：通过检查程序在各个时间点的状态：通过检查程序在各个
137、时间点的状态来验证软件的逻辑流程是否正确。这种测试，不那么直观。来验证软件的逻辑流程是否正确。这种测试，不那么直观。我们要仔细观察软件提供的全部选项我们要仔细观察软件提供的全部选项所有的工具、菜单、颜色等，所有的工具、菜单、颜色等，一旦选中了某个功能，使软件改变了外观、菜单样貌，就是改变一旦选中了某个功能，使软件改变了外观、菜单样貌，就是改变了该软件的状态。软件从一种状态转换到另一种状态，是内部代了该软件的状态。软件从一种状态转换到另一种状态，是内部代码层面上执行顺序带来的后果。（代码执行进入某个特定分支，码层面上执行顺序带来的后果。（代码执行进入某个特定分支，触发某些数据位，设置了某些变量，
138、读取某些数据）触发某些数据位，设置了某些变量，读取某些数据）状态测试状态测试测试员必须测试程序的状态及其转换，即软件的逻辑流程。测试员必须测试程序的状态及其转换，即软件的逻辑流程。我们的目的是访问所有功能、走遍所有分支，达到所有状态。我们的目的是访问所有功能、走遍所有分支，达到所有状态。这类似于著名的这类似于著名的“流动推销员流动推销员”问题：给定城市数目，以及任问题：给定城市数目，以及任何两个城市之间的距离，设法找出访问每一个城市一次，何两个城市之间的距离，设法找出访问每一个城市一次，并返回起点的最短路线。如果只有并返回起点的最短路线。如果只有5 5个城市，那么可以快个城市，那么可以快速计算
139、出共有速计算出共有120120条路线，从中找出最短的路线是可操作条路线，从中找出最短的路线是可操作的，但如果城市的数目增加到上百个，就基本不可能了。的，但如果城市的数目增加到上百个，就基本不可能了。状态测试中的每一个状态点相当于一个城市，遍历全部状状态测试中的每一个状态点相当于一个城市，遍历全部状态一样是不现实的。态一样是不现实的。首先建立状态转换图，绘图的技术并不重要，只要项目小组内部首先建立状态转换图，绘图的技术并不重要，只要项目小组内部可以看懂就可以了，但状态转换图至少应该包含以下内容：可以看懂就可以了，但状态转换图至少应该包含以下内容：1.1.软件可能进入的每一个独立状态软件可能进入的
140、每一个独立状态2.2.从一种状态进入另一种状态需要的输入和条件。从一种状态进入另一种状态需要的输入和条件。3.3.进入或退出某种状态时的设置条件和输出结果。进入或退出某种状态时的设置条件和输出结果。状态测试的具体做法：状态测试的具体做法：空闲空闲等待用户等待用户输入命令输入命令按下按下EscEsc键键显示口令框显示口令框口令错误口令错误 消除消除口令正确口令正确初始状态消失初始状态消失空闲空闲等待用户等待用户输入命令输入命令按下按下EscEsc键键口令正确口令正确口令错误口令错误不同形式的状态转换图用例场景用例场景用例场景是通过描述流经用例的路径来确定的过用例场景是通过描述流经用例的路径来确定
141、的过程，这个流经过程要从用例开始到结束遍历其中程，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流所有基本流和备选流ATM业务模型业务模型ATM（基本流）（基本流）l 步骤步骤1：准备提款：准备提款-客户将银行卡插入客户将银行卡插入ATM机机 的读卡机。的读卡机。l 步骤步骤2：验证银行卡：验证银行卡-ATM机从银行卡的磁条机从银行卡的磁条 中读取账户代码，并检查它是否属于可以接中读取账户代码，并检查它是否属于可以接 收的银行卡。收的银行卡。l 步骤步骤3：输入密码：输入密码-ATM要求客户输入密码要求客户输入密码（46位）位）ATM(基本流）基本流）l 步骤步骤4：验证账户和密码该账
142、户是否有效，以及所：验证账户和密码该账户是否有效，以及所输入的密码对该账户来说是否正确。输入的密码对该账户来说是否正确。l 步骤步骤5：ATM选项选项-ATM显示在本机上可用的各种显示在本机上可用的各种选项。在此事件流中，银行客户通常选择选项。在此事件流中，银行客户通常选择“提款提款”。l 步骤步骤6：输入金额：输入金额-要从要从ATM中提取的金额。对于中提取的金额。对于此事件流，客户需要选择预设的金额（此事件流，客户需要选择预设的金额（10美元、美元、20美元、美元、50美元或美元或100美元）。美元）。ATM（基本流（基本流)l步骤步骤7：授权：授权-ATM通过将卡通过将卡ID、金额以及账
143、户信息作、金额以及账户信息作为一笔交易发送给银行系统来启动验证过程。对于此事为一笔交易发送给银行系统来启动验证过程。对于此事件流，银行系统处于联机状态，而且对授权请求给予答件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新账户余额。复，批准完成提款过程，并且据此更新账户余额。l步骤步骤8：出钞：出钞-提供现金。提供现金。l步骤步骤9：返回银行卡：返回银行卡-银行卡被返还。银行卡被返还。l步骤步骤10：收据：收据-打印收据并提供给客户。打印收据并提供给客户。ATM还相还相 应地更新内部纪录。应地更新内部纪录。ATM（说明）（说明）l我们需要核实提款用例已经正确地实
144、施。此时尚未我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流：实施整个用例，只实施了下面的事件流：l 基本流基本流-提取预设金额（提取预设金额（10美元、美元、20美元、美元、50美元、美元、100美元）美元）l备选流备选流2-AMT内没有现金内没有现金l备选流备选流3-ATM内现金不足内现金不足l备选流备选流4-PIN有误有误l备选流备选流5-账户不存在账户不存在/账户类型有误账户类型有误l备选流备选流6-账面金额不足账面金额不足ATM(其他测试用例）其他测试用例）l无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、
145、磁条损坏等）磁条损坏等）l 无法读卡（读卡机堵塞、脱机或出现故障）无法读卡（读卡机堵塞、脱机或出现故障）l 账户已销户、冻结或由于其他方面原因而无法使用账户已销户、冻结或由于其他方面原因而无法使用ATM内的现金不足或不能提供所请求的金额内的现金不足或不能提供所请求的金额l 无法联系银行系统以获得认可无法联系银行系统以获得认可l 银行网络离线或交易过程中断电银行网络离线或交易过程中断电状态测试的原则：状态测试的原则：减少要测试的状态及转换的数量减少要测试的状态及转换的数量每种状态每种状态至少访问一次至少访问一次测试测试最常见最普遍最常见最普遍的状态转换的状态转换测试状态之间测试状态之间最不常用最
146、不常用的分支的分支测试测试所有错误状态所有错误状态及其返回值及其返回值测试测试随机状态转换随机状态转换确定了测试的状态及其转换之后，就可以定义测试用例了：确定了测试的状态及其转换之后，就可以定义测试用例了：测试的状态及其转换包括：检查所有的测试的状态及其转换包括：检查所有的状态变量状态变量。即与进入和退出相关的静态条件、信息、值、功能等。即与进入和退出相关的静态条件、信息、值、功能等。状态测试的具体做法：状态测试的具体做法：以以WINDOWS自带画图工具处于启动状态时的自带画图工具处于启动状态时的部分状态变量部分状态变量：v窗口外观窗口外观v窗口的尺寸被自动设置为上一次使用时的窗口的尺寸被自动
147、设置为上一次使用时的尺寸尺寸v中间的绘图区域为空白中间的绘图区域为空白v显示有工具栏、颜色栏和状态条显示有工具栏、颜色栏和状态条v铅笔工具被默认选中，其余工具均未被选铅笔工具被默认选中，其余工具均未被选中中v默认的颜色是背景白，前景黑默认的颜色是背景白，前景黑v当前文档名称是当前文档名称是“未命名未命名” 一个常见的状态变量例子一个常见的状态变量例子之前列举了某些状态变量，另外一些状态变量也许是看不之前列举了某些状态变量，另外一些状态变量也许是看不见的，但作用仍很重要。一个常见的例子是见的，但作用仍很重要。一个常见的例子是“文档涂改标志文档涂改标志”。在使用文字处理软件（在使用文字处理软件（W
148、ORD或记事本）或画图程序时，一个称为或记事本）或画图程序时，一个称为文档涂改标志文档涂改标志的的状态状态变量变量就在后台启动了（洁净状态），如果用户打开了一个文档后只是查看而未做任何就在后台启动了（洁净状态），如果用户打开了一个文档后只是查看而未做任何更改就关闭了软件，那么这个更改就关闭了软件，那么这个状态变量状态变量也保持洁净状态不变，系统也不会有任何提示。也保持洁净状态不变，系统也不会有任何提示。一旦用户做出任何改动，如删除了一个标点（这时一旦用户做出任何改动，如删除了一个标点（这时文档涂改标志文档涂改标志将变成将变成“涂改涂改”状态），如状态），如果想保留这个改动，在关闭文件或退出系统
149、之前，应保存文件，如果一个不熟练的用果想保留这个改动，在关闭文件或退出系统之前，应保存文件，如果一个不熟练的用户没有做这个操作，系统会自动弹出提示：退出前是否要保存？户没有做这个操作，系统会自动弹出提示：退出前是否要保存？系统之所以会如系统之所以会如此提示，就是因为此提示，就是因为“文档涂改标志文档涂改标志”这个这个状态变量状态变量处于处于“涂改涂改”状态，保存会使它恢复到状态，保存会使它恢复到“洁净洁净”状态。有些能实现状态。有些能实现UNDO和和REDO操作的软件，就伴随着操作的软件，就伴随着文档涂改标志文档涂改标志这个这个状态状态变量变量在在“洁净洁净”和和“涂改涂改”状态之间切换。状态
150、之间切换。失败状态测试失败状态测试此时我们的目的是找到测试此时我们的目的是找到测试软件失败软件失败的案例的案例现在的操作系统早已发展为多任务执行。宏观并行，微观串行。现在的操作系统早已发展为多任务执行。宏观并行，微观串行。操作系统被设计为同时执行多个独立的进程，每个进程可以是电子邮件、处理电子表操作系统被设计为同时执行多个独立的进程，每个进程可以是电子邮件、处理电子表格文档、打印某个图片文件。格文档、打印某个图片文件。操作系统是最重要、使用最频繁的系统软件，在漫长的充满意外操作的被使用过程中，操作系统是最重要、使用最频繁的系统软件，在漫长的充满意外操作的被使用过程中，它将会被充分考验。它将会被
151、充分考验。在真正意义上的多任务环境中，必须随时响应来自各个任务的中断要求，并与其它任在真正意义上的多任务环境中，必须随时响应来自各个任务的中断要求，并与其它任何软件共同运行，共享内存、磁盘等系统资源。何软件共同运行，共享内存、磁盘等系统资源。这就将导致竞争（请回忆这就将导致竞争（请回忆“死锁死锁”现象）。同时如果几个事件恰好挤在同一时刻出现，现象）。同时如果几个事件恰好挤在同一时刻出现，同时申请资源，软件可能未预料到运行过程会中断，将造成时序混乱。同时申请资源，软件可能未预料到运行过程会中断，将造成时序混乱。我们的测试可以模拟实现现实环境中的我们的测试可以模拟实现现实环境中的竞争条件和时序错乱
152、。竞争条件和时序错乱。当然竞争条件难以实际设计，我们应仔细考察状态转换图，当然竞争条件难以实际设计，我们应仔细考察状态转换图，观察其中的每一个状态：当需要的外部条件没有准备好，观察其中的每一个状态：当需要的外部条件没有准备好，或在用到时发生了变化，会怎样？当其中一个必要条件突或在用到时发生了变化，会怎样？当其中一个必要条件突然由满足变成不满足，会对运行状态造成什么影响？然由满足变成不满足，会对运行状态造成什么影响？常见的面临竞争条件的例子：常见的面临竞争条件的例子：v两个不同的程序同时打开或保存同一个文件。两个不同的程序同时打开或保存同一个文件。v共享同一台打印机或其它外设。共享同一台打印机或
153、其它外设。v当软件处于打读取或改变状态时按下某键或单击鼠标。当软件处于打读取或改变状态时按下某键或单击鼠标。v同时使用不同的程序访问同一个数据库。同时使用不同的程序访问同一个数据库。用户经常意外地引起这些操作，软件必须足够强壮以应付此类情况。用户经常意外地引起这些操作，软件必须足够强壮以应付此类情况。三个失效性状态测试三个失效性状态测试 重复、压迫、重负重复、压迫、重负重复测试：不断执行同样的操作。重复测试：不断执行同样的操作。最简单的是不停地启动、关闭程序；最简单的是不停地启动、关闭程序；还有反复读写数据或反复选择同一个操作。还有反复读写数据或反复选择同一个操作。这样做的最主要的目的是检查是
154、否有内存泄露。这样做的最主要的目的是检查是否有内存泄露。内存泄露：如果计算机内存被分配进行某个操作，但操作完成时，却没有释放或没内存泄露：如果计算机内存被分配进行某个操作，但操作完成时，却没有释放或没有完全释放所申请的内存空间，这样的操作反复数次，就会造成软件工作所需的有完全释放所申请的内存空间，这样的操作反复数次，就会造成软件工作所需的系统空间被耗尽。系统空间被耗尽。具体现象是：一个以前使用过的某个程序刚启动时工作状态良好，但随后变得越来具体现象是：一个以前使用过的某个程序刚启动时工作状态良好，但随后变得越来越慢，或者表现得不稳定，其原因多半就是内存泄露。重复测试就能暴露这些越慢，或者表现得
155、不稳定，其原因多半就是内存泄露。重复测试就能暴露这些问题。问题。压迫测试：使仍旧在不够理想的条件下运行，如内压迫测试：使仍旧在不够理想的条件下运行，如内存小、磁盘空间不足，存小、磁盘空间不足，CPU速度慢，速度慢，MODEM速率速率低等。观察软件对外部资源的要求和环境的依赖的低等。观察软件对外部资源的要求和环境的依赖的程度。程度。换言之，就是将外界的支持度降到最低，尽可能地换言之，就是将外界的支持度降到最低，尽可能地限制软件运行的各种必要条件，观察软件的反应。限制软件运行的各种必要条件，观察软件的反应。重负测试：与压迫测试相反，压迫测试是尽量限制软件，而重重负测试：与压迫测试相反，压迫测试是尽
156、量限制软件，而重负测试的作用是尽量提供条件任其发挥，让软件处理尽可能负测试的作用是尽量提供条件任其发挥，让软件处理尽可能大的数据文件。最大限度地发掘软件的能力，让它不堪重负。大的数据文件。最大限度地发掘软件的能力，让它不堪重负。重复测试重复测试压迫测试压迫测试重负测试重负测试应联合使用，同时进行时间也是一种重负时间也是一种重负对于大多数软件，都需要它们长期稳定地工作，有些软件人对于大多数软件，都需要它们长期稳定地工作，有些软件人们甚至期望它们能永远运行下去，而不用重新启动。们甚至期望它们能永远运行下去，而不用重新启动。虽然，项目经理们经常不同意测试员虽然，项目经理们经常不同意测试员如此破坏软件
157、如此破坏软件测试设计中需要考虑的测试设计中需要考虑的22种测试类型种测试类型黑盒测试黑盒测试白盒测试白盒测试单元测试单元测试集成测试集成测试系统测试系统测试端到端测试端到端测试健全测试健全测试衰竭测试衰竭测试接受测试接受测试状态场景测试状态场景测试负载测试负载测试强迫测试强迫测试性能测试性能测试可用性测试可用性测试安装安装/卸载测试卸载测试恢复测试恢复测试兼容测试兼容测试安全测试安全测试比较测试比较测试Alpha测试测试Beta测试测试n功能测试功能测试n性能测试性能测试n资源和余量测试资源和余量测试n外部接口测试外部接口测试n强度测试强度测试n可靠性测试可靠性测试n安全性测试安全性测试n恢复
158、性测试恢复性测试n安装性测试安装性测试n移植性测试移植性测试n保密性测试保密性测试n回归测试回归测试n根据软件需求规格说明中定义的全部功能、性能、可根据软件需求规格说明中定义的全部功能、性能、可靠性等需求，测试整个软件是否达到要求。靠性等需求，测试整个软件是否达到要求。系统合格性测试内容系统合格性测试内容功能测试功能测试n功功能能测测试试是是在在规规定定的的一一段段时时间间内内运运行行软软件件系系统统的的所所有有功功能能，以验证这个软件系统有无严重错误以验证这个软件系统有无严重错误n根根据据功功能能需需求求进进行行测测试试，以以确确认认软软件件与与软软件件功功能能需需求求的的一一致致n功能测试
159、应达到以下要求：功能测试应达到以下要求：a.每每一一个个软软件件功功能能都都必必须须被被测测试试用用例例或或被被认认可可的的异异常常所所覆覆盖盖（或或由由于于异异常常情情况况的的出出现现而而未未达达到到期期望望的的覆覆盖盖，但但该该异常已被测试者认识到，并进行了处理）；异常已被测试者认识到，并进行了处理）；b.用用一一系系列列合合理理的的数数据据类类型型和和数数据据值值运运行行，测测试试软软件件在在正正常、超负荷、饱和和其它常、超负荷、饱和和其它“最坏最坏”情况下的结果；情况下的结果；c.用用假假想想的的数数据据类类型型和和数数据据值值运运行行，以以测测试试软软件件排排斥斥不不规规则（非法）输
160、入的能力。则（非法）输入的能力。n按按规规程程进进行行安安装装正正确确性性测测试试，包包括括参参数数装订、程序加载等。装订、程序加载等。安装卸载测试安装卸载测试(1)(1)恢复测试恢复测试n恢复测试是要证实在恢复测试是要证实在克服硬件故障克服硬件故障(包括包括掉电、硬件或网络出错等掉电、硬件或网络出错等)后后，系统能否系统能否正常地继续进行工作正常地继续进行工作，并不对系统造成，并不对系统造成任何损害。任何损害。n对对有有恢恢复复或或重重置置（RESET）功功能能的的软软件件，应应专专门门对对每每一一类类导导致致恢恢复复或或重重置置的的情情况况进行测试，以确认恢复或重置功能。进行测试，以确认恢
161、复或重置功能。 自动恢复自动恢复: :检测重新初始化、检测重新初始化、 检测点设置、检测点设置、 数据恢复、数据恢复、 重新启动等是否正确重新启动等是否正确. . 人工干预恢复人工干预恢复: :检测平均恢复时间是否在检测平均恢复时间是否在允许范围内允许范围内. .恢复性测试内容恢复性测试内容n可采用各种人工干预的手段，模拟硬件故障，故意造成软件出可采用各种人工干预的手段，模拟硬件故障，故意造成软件出错。检测软件能否恰当地完成恢复错。检测软件能否恰当地完成恢复.并由此检查：并由此检查：n错误探测功能错误探测功能错误探测功能错误探测功能系统能否发现硬件失效与故障；系统能否发现硬件失效与故障；n能否
162、能否切换或启动备用的硬件切换或启动备用的硬件切换或启动备用的硬件切换或启动备用的硬件；n在故障发生时能否在故障发生时能否保护正在运行的作业和系统状态保护正在运行的作业和系统状态保护正在运行的作业和系统状态保护正在运行的作业和系统状态；n在系统恢复后能否在系统恢复后能否从最后记录下来的无错误状态开始继续从最后记录下来的无错误状态开始继续从最后记录下来的无错误状态开始继续从最后记录下来的无错误状态开始继续执行作业执行作业执行作业执行作业，等等。，等等。n掉电测试掉电测试掉电测试掉电测试：其目的是测试软件系统在发生电源中断时能否：其目的是测试软件系统在发生电源中断时能否保护当时的状态且不毁坏数据保护
163、当时的状态且不毁坏数据保护当时的状态且不毁坏数据保护当时的状态且不毁坏数据，然后在，然后在电源恢复时从保留的电源恢复时从保留的电源恢复时从保留的电源恢复时从保留的断点处重新进行操作断点处重新进行操作断点处重新进行操作断点处重新进行操作。(2)(2)安全性测试安全性测试针对程序中危险防止和危险处理设施进行针对程序中危险防止和危险处理设施进行的测试，以验证其是否有效。的测试，以验证其是否有效。设计测试用例设计测试用例, ,突破软件安全保护机构的突破软件安全保护机构的安全保密措施安全保密措施, ,检验系统预防机制的漏洞检验系统预防机制的漏洞. .安全性测试应包括下面的工作安全性测试应包括下面的工作
164、a.全全面面检检验验软软件件在在软软件件需需求求规规格格说说明明中中规规定定的的防防止止危危险险状状态态措措施的有效性和在每一个危险状态下的反应；施的有效性和在每一个危险状态下的反应；b.对对软软件件设设计计中中用用于于提提高高安安全全性性的的结结构构、算算法法、容容错错、冗冗余余、中断处理等方案，进行针对性测试；中断处理等方案，进行针对性测试；c.在在异异常常条条件件下下测测试试软软件件，以以表表明明不不会会因因可可能能的的单单个个或或多多个个输输入错误而导致不安全状态。入错误而导致不安全状态。d.用用错错误误的的安安全全性性关关键键操操作作进进行行测测试试，以以验验证证系系统统对对这这些些
165、操操作作错误的反应；错误的反应；e.对对安安全全性性关关键键的的软软件件单单元元和和软软件件部部件件，要要单单独独进进行行加加强强的的测测试，以确认其满足安全性需求。试，以确认其满足安全性需求。(3)(3)强度测试强度测试n强强度度测测试试是是要要检检查查在在在在系系系系统统统统运运运运行行行行环环环环境境境境不不不不正正正正常常常常乃乃乃乃至至至至发发发发生生生生故故故故障障障障的的的的情情情情况况况况下下下下，系系系系统统统统可可可可以以以以运运运运行行行行到到到到何何何何种种种种程程程程度度度度的的的的测测测测试试试试n强强度度测测试试是是在在预预先先规规定定的的一一段段时时间间内内，在
166、在软软件件设设计计的的极极限限状状态态下下，进进而而在在超超设设计计能能力力的的状状态态下下，运行软件以测试软件的所有功能。运行软件以测试软件的所有功能。n可可以以允允许许在在饱饱和和点点上上性性能能降降级级，但但必必须须保保证证仍仍能能顺利运行。顺利运行。强度测试中我们要做的事强度测试中我们要做的事检验系统能力最高能达到的实际限度检验系统能力最高能达到的实际限度, , 让系统处让系统处于资源的异常数量、异常频率、异常批量的条于资源的异常数量、异常频率、异常批量的条件下测试系统的承受能力件下测试系统的承受能力. .一般以比平常限度高一般以比平常限度高5-105-10倍的限度做测试用例倍的限度做
167、测试用例. .强度测试内容示例强度测试内容示例n把把输输入入数数据据速速率率提提高高一一个个数数量量级级，确确定定输输入入功功能能将将如如何何响响应。应。n设计需要占用最大存储量或其它资源的测试用例进行测试。设计需要占用最大存储量或其它资源的测试用例进行测试。n设设计计出出在在虚虚拟拟存存储储管管理理机机制制中中引引起起“颠颠簸簸”的的测测试试用用例例进进行行测试。测试。n设设计计出出会会对对磁磁盘盘常常驻驻内内存存的的数数据据过过度度访访问问的的测测试试用用例例进进行行测试。测试。n强度测试的一个变种就是强度测试的一个变种就是敏感性测试敏感性测试敏感性测试敏感性测试。在程序有效数据界。在程序
168、有效数据界限内一个小范围内的一组数据可能引起极端的或不平稳的限内一个小范围内的一组数据可能引起极端的或不平稳的错误处理出现，或者导致极度的性能下降的情况发生。此错误处理出现，或者导致极度的性能下降的情况发生。此测试用以发现可能引起这种不稳定性或不正常处理的某些测试用以发现可能引起这种不稳定性或不正常处理的某些数据组合。数据组合。(4)(4)性能测试性能测试n性能测试是要检查系统是否满足在需求说明书中性能测试是要检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统。规定的性能。特别是对于实时系统或嵌入式系统。n对软件是否与所需定量的性能需求一致进行确认。对软件是否与所需定量的
169、性能需求一致进行确认。n性能测试常常性能测试常常需要与强度测试结合起来需要与强度测试结合起来需要与强度测试结合起来需要与强度测试结合起来进行，并进行，并常常要求常常要求同时进行硬件和软件检测同时进行硬件和软件检测同时进行硬件和软件检测同时进行硬件和软件检测。性能测试内容性能测试内容n通常，对软件性能的检测表现在以下几个方面：通常，对软件性能的检测表现在以下几个方面：响应时间响应时间响应时间响应时间、吞吐量吞吐量吞吐量吞吐量、辅助存储区辅助存储区辅助存储区辅助存储区，例如缓冲区，例如缓冲区，工作区的大小等、工作区的大小等、处理精度处理精度处理精度处理精度，等等。，等等。n包括：包括：a.软件在获
170、得定量结果时计算的精确性；软件在获得定量结果时计算的精确性；b.有时间要求的软件，其实际的运行时间；有时间要求的软件，其实际的运行时间；c.软件完成功能所能处理的数据量；软件完成功能所能处理的数据量；d.软件各部分的协调性；软件各部分的协调性；e.其它性能指标。其它性能指标。 我们要做的事就是设计恰当的测试用例，并记录软件运行性能，与性能要求比我们要做的事就是设计恰当的测试用例，并记录软件运行性能，与性能要求比较，检验是否达到要求规格。较，检验是否达到要求规格。资源和余量测试资源和余量测试n测测试试是是否否符符合合软软件件需需求求规规格格说说明明中中提提出出的的处处理理时时间间、储储存存空空间
171、间和和内内存存、输输入入输输出出通通道道等等资资源源使使用的要求，并在设计中为这些资源留出了余量。用的要求，并在设计中为这些资源留出了余量。n通通常常情情况况下下，应应保保证证在在储储存存空空间间和和内内存存，输输入入输输出出通通道道，以以及及处处理理时时间间的的占占用用上上至至少少有有的余量。的余量。操作测试操作测试n操操作作测测试试包包括括对对用用户户接接口口、人人机机接接口口和和人人机机交互要求的所有测试。交互要求的所有测试。n应应以以常常规规操操作作、非非常常规规操操作作、误误操操作作、快快速速操作等情况来检验界面的可靠性。操作等情况来检验界面的可靠性。n操操作作测测试试工工作作还还包
172、包括括对对照照软软件件使使用用说说明明，逐逐条条进进行行相相应应的的操操作作，以以检检测测软软件件使使用用说说明明的的完整性、正确性、与软件程序的一致性。完整性、正确性、与软件程序的一致性。外部接口测试外部接口测试n确认软件与其外部接口要求的一致性。确认软件与其外部接口要求的一致性。n测试内容：测试内容：a.测试所有外部接口，检测接口信息的格式和内容。测试所有外部接口，检测接口信息的格式和内容。b.对对每每一一个个外外部部输输入入输输出出接接口口应应进进行行正正常常和和异异常常情情况况测试。测试。n如如果果软软件件不不能能在在运运行行环环境境中中测测试试，则则有有必必要要使使用用模拟程序或其它
173、测试工具。模拟程序或其它测试工具。可靠性测试可靠性测试n软软件件可可靠靠性性测测试试是是以以能能获获得得可可用用来来评评估估软软件件可可靠靠性性的的数数据据为为目目的的的一种软件测试。的一种软件测试。n例例如如，基基于于软软件件运运行行剖剖面面设设计计软软件件测测试试用用例例，并并用用这这些些测测试试用用例例按按出出现现概概率率进进行行随随机机输输入入以以模模拟拟软软件件真真实实运运行行状状态态，运运行行软软件件以以获获得得失失效效数数据据，进进而而给给出出软软件件的的可可靠靠性性度度量量，这这就就是是一一种种软软件件可可靠性测试。靠性测试。n软件运行剖面是指：软件运行剖面是指：1)软件运行期
174、间执行各个任务的事件和各事件相应概率的集合。软件运行期间执行各个任务的事件和各事件相应概率的集合。2)系系统统使使用用条条件件的的一一种种定定义义，系系统统输输入入值值用用其其按按时时间间或或在在可可能能输入范围中以概率分布来定义。输入范围中以概率分布来定义。可靠性指标示例可靠性指标示例平均失效间隔时间平均失效间隔时间MTBF(MeanTimeBetweenFailures)是否超过是否超过规定时限规定时限?因故障而停机的时间因故障而停机的时间MTTR(MeanTimeToRepairs)在一年中应不在一年中应不超过多少时间。超过多少时间。移植性测试移植性测试n在在所所有有要要求求的的移移植植
175、环环境境中中运运行行软软件件以以验验证软件的移植性。证软件的移植性。保密性测试保密性测试n验验证证软软件件是是否否提提供供了了软软件件需需求求规规格格说说明明中中规规定定的的保保密密机机制制，使使软软件件的的机机密密性性、完整性和有效性不被破坏。完整性和有效性不被破坏。启动停止测试启动停止测试n这这类测试的目的是验证类测试的目的是验证在机器启动及关在机器启动及关机阶段机阶段，软件，软件系统正确处理的能力系统正确处理的能力。这类测试包括这类测试包括n反复启动软件系统反复启动软件系统(例如，操作系统例如，操作系统自举、网络的启动、应用程序的调用自举、网络的启动、应用程序的调用等等)n在尽可能多的情
176、况下关机在尽可能多的情况下关机。回归测试回归测试n回回归归测测试试是是一一种种选选择择性性重重新新测测试试，目目的的是是检检测测系系统统或或系系统统组组成成部部分分在在修修改改期期间间产产生生的的缺缺陷陷，用用于于验验证证已已进进行行的的修修改改并并未未引引起起不不希希望望的的有有害害效效果果，或或确确认认修修改改后后的的系系统统或系统组成部分仍满足规定的要求。或系统组成部分仍满足规定的要求。验收测试验收测试测试：由用户在开发者的场所、在开发者关注和控制的环境下在开发者指导下进行测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试它可以从软件产品编码结束之时开始，或在模块（子系统）测试完
177、成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始测试测试 测试测试是由软件的多个用户在实际使用环境下进行的测试多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，测试测试是在开发者无法控制的环境下进行的软件现场应用。在测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。 测试测试主要着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当测试测试达到一定的可靠程度时，才能开始测试测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。软件测试自动化几种常见的
178、测试工具软件缺陷管理工具 BUGZILLA软件功能测试工具 QTP软件负载测试工具LOADRUNNER软件测试管理工具TESTDIRECTOR免费的、买来的、订做的（公司内部人员开发&专业公司开发）测试工具的来源测试工具的编制难度，低于较高端的软件开发MIMI公司：公司：Mercury InteractiveMercury Interactive为什么使用自动测试工具测试工具提高测试效率，节省测试成本有些测试单靠手工很难完成压力测试，模拟并发测试等多数的单元测试有些测试使用测试工具更合适回归测试大量测试数据的生成、部分测试结果的比较缺陷管理和测试用例管理质量度量考虑自动化工具时应该注意并不是所
179、有的测试工作都可以由测试工具来完成。并不是一个自动化工具就可以完成所有测试使用自动化工具本身也需要时间，这个时间有可能超过手工测试的时间。如果测试人员并不熟悉测试工具的使用，必然不能更多发现软件错误，从而影响测试工作质量。自动化测试工具并不能对一个软件进行完全的测试。购买自动化测试工具有可能使本项目的测试费用超出预算。何时采用手工测试/自动化测试手工很容易测试的程序只需要测试一次的程序要马上进行测试的程序要使用直觉和经验才能测试的程序不可预知结果的程序要经常执行测试的程序压力测试（如多用户执行、一个程序反复执行一万遍）手工测试自动化测试测试工具的选择功能是否适用（并非功能越多越好）功能其实大同
180、小异，只是侧重点不同测试工具可否跨平台价格（是较为重要的因素）同时也必须考虑测试工具引入的连续性即对测试工具的选择必须有一个整体的考虑，要分阶段、逐步地引入测试工具。必须考虑被测项目的特性黑盒测试工具包括功能测试工具和性能测试工具一般原理是利用脚本的录制（RECORD）和回放（PLAYBACK），模拟用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。在迭代开发过程中能够很好地进行回归测试。白盒测试工具可以很快检查代码的规范性（因为其内部集成有编码规范库）有的还能自动生成一些测试用例便于代码的单元回归测试测试管理工具一般分为缺陷管理和测试过程管理两种使用测试管理工具的好处，和使用
181、测试用例的好处一样：1.方便于集中管理各种测试资源2.方便于团队成员的交流合作（可以在不同的地点办公）3.使测试流程规范、清晰，远离了随意性和意外总结 1由于进行自动化测试，我们要放弃一些手工测试，所以在衡量自动化测试的成本时要考虑到我们因此放弃多少手工测试，少捕获了多少缺陷。 2应该针对特殊的目的来设计测试，然后针对一个或多个功能的重要方面进行测试。 3要正确估量自动化测试脚本开发和维护工作量，将关键而有许多次执行的测试用例自动化。 4一般来说，手工测试可以取代任何类型、功能的自动测试，但在多用户并发等情况下，手工测试是很难实现的，这时自动测试就发挥作用了。另外，使用自动测试工具可以减少很多
182、重复的手工劳动，精确复制缺陷，提高测试覆盖率，从而提高产品质量。 5应该根据企业的特点来选择测试工具。首先，对商业化的测试工具进行评估；然后，在公司的实际项目中试用，通过这种方法来检验工具在特定的环境下是否具有供应商所宣传的特性，同时考察代理商的技术支持水准，这对将来工具的大规模应用非常重要。 6虽然测试工具的应用可以提高测试的质量、测试的效率，但要成功实施自动化测试，测试工作就必须遵从系统的、结构化的和循序渐进的观念来进行。思考：思考： 1、自动化软件测试应该考虑哪些因素？ 2、简述自动化测试和手工测试的优缺点。 3、自动化测试工具大致可以分为几类，并举例说明几种与之相应的测试工具？ 4、简
183、述应用自动化测试工具的目的？ 5、选择测试工具时主要应从哪几个方面进行考虑？测试流程管理计划测试工作测试是系统的行为，严禁胡乱、随意的测试，必须先做计划。测试计划由测试负责人或经理来完成（测试新手一般不会被安排为项目建立全面的测试计划）测试部必须和以下公司部门打交道开发部、客服部、市场部测试工作的顺利进行，必须依赖他们的配合而配合并非理所当然，或迫于领导压力，或自身确有需要计划测试工作一、测试计划的目标如果程序员编写代码而不说明它是干什么的、如何工作，如何完成，执行测试任务就会变得很困难，同样，如果测试员之间不交流、计划测试的对象需要什么资源，进度如何安排，进度就无法进行。软件测试计划是测试员
184、和产品开发小组交流意图的主要方式，为书面文档的形式。它包括：规定测试活动的范围、策略、方法、资源和进度。要明确的是：正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人以及和计划相关的风险。需要注意的是，“计划”是一个动作，而不只是一个结果，我们侧重的是如何设计一套操作流程并把它记录下来人人遵守，而不是以撰写一系列文档为目的。写文档的目的是为实际服务，不要写出很多格式精美，但与事实不符、写好后就束之高阁，在项目开发过程中毫不起作用的文档。测试计划必须明确测试人员的职责范围测试计划必须明确测试人员的职责范围做测试计划的一个原则测试的计划过程，最终目标是交流，而不是产生文档。常见的不当
185、行为：测试组长或某位临时的测试组成员关起门来按照给定的模板逐项填入了他所知道的本组的测试意图和期望，然后上交。之后他认为这一环节的任务完成了，到了实际进行测试时，他则完全按照具体实际情况来随意操作，把文档表格上填过的文字全部忘掉了。注意：错误的计划，不如没有。 做测试计划之前，通常需要掌握以下信息： 1要测试哪些模块2需要哪些资源3必须满足哪些时间进度4. 存在哪些风险人力、设备、钱。如：培训费用、测试所需要的软硬件环境、自动化测试工具等1.先测试优先级最高的2.优先测试新加入的功能或改进的旧功能3.重点测试经常出问题的地方总体的测试范围如何界定？一个公司的回归测试策略 1.每两周进行一次完整
186、的回归测试2.当修复的缺陷数量累积到50个的时候，进行完整的回归测试3.在产品递交用户的5个工作日前，进行完整的回归测试 “修改了UI中的一些说明文字”这时就不必进行性能回归测试因为界面中文字修改影响到软件性能的可能性微乎其微 完整的回归测试：所有的测试用例都要执行一遍部分回归测试：只选取某些模块的测试用例执行一遍 注意：所有的测试文档都不能丢失，否则无法回归！测试提问单1.哪些功能模块是软件的特色？2.哪些功能是用户最常用的？3.如果系统可以分块出售，那么哪些功能将是最贵的？4.哪些功能一旦出错，将导致用户严重不满或索赔？5.哪些功能模块是最复杂、最统一出错的？6.哪些功能模块是相对独立的？
187、（可以并应该提前测试）7.哪些功能模块是全系统的性能瓶颈所在？8.哪些功能最容易扩散缺陷？9.哪些功能是开发者最没有信心的？测试策略：总体的测试范围测试活动的进入/退出标准自动化测试工具的引入、选择测试人员的工作时间、方式测试方法和测试策略的区别：测试方法：使用静态还是动态测试？使用黑盒测试技术，还是白盒？如果是白盒方法，那么采用何种覆盖标准？如果是黑盒，那么采用等价类法？边界值法？因果图法？错误推测法？单元测试的退出，是集成测试进入的标准（不绝对）集成测试的退出，是系统测试进入的标准系统测试的退出，是验收测试进入的标准测试进入和退出的标准如何界定？单元测试的退出标准之一：语句覆盖100%集成
188、测试的退出标准：测试用例通过率系统测试的退出标准：测试用例通过率 每个缺陷都要经历以下几个状态（生命阶段）：新创建由测试员提交给领导级别的审查组已决定推迟/已决定放弃/已发现重复/已发现并非缺陷，驳回由审查组决定是否推迟、放弃、驳回已通过审核（由仲裁会或评审组）发回给最初的缺陷提交人已分配由项目经理分配给程序员去改正已解决/已关闭程序员改正缺陷后需经过回归测试，看是否解决重新激活软件缺陷的集中状态（生命期）注意：关闭的缺陷，未必是已成功解决，很可能是经决策后推迟或放弃的测试用例与软件缺陷如何进行软件测试专业手法：了解被测试软件后，编写测试用例测试用例测试用例测试用例并执行，记录实际结果，并将之
189、与预期结果进行对比其优点：严密；便于跟踪和交流；不会遗漏其缺点：必须深刻了解被测试软件；耗时初学者：把握住宏观的一点：紧扣需求一个实际的测试用例back测试用例应该具有的属性所属模块、子模块，编号输入（或者预置条件、操作步骤）输出（预期结果），测试结果每个缺陷都具备以下属性，作为处理时的依据缺陷类型（即来源）需求缺陷、设计缺陷、功能和性能缺陷、界面缺陷系统结构缺陷、实现与编码缺陷等严重程度致命、严重、一般、轻微、建议处理优先级（见下页表）深入描述软件缺陷缺陷的等级划分A类：（最严重的缺陷）由于程序所引起的死机,非法退出死循环数据库发生死锁因错误操作导致的程序中断功能错误与数据库连接错误数据通讯
190、错误缺陷的等级划分B类：较严重错误，包括以下：程序错误程序接口错误数据库的表、业务规则、缺省值未加完整性等约束条件C类：一般性错误，包括以下：操作界面错误（如数据窗口内列名定义、含义不一致）打印内容、格式错误简单的输入限制未放在前台进行控制删除操作未给出提示数据库表中有过多的空字段缺陷的等级划分D类：较小错误，包括以下：界面不规范辅助说明描述不清楚输入输出不规范长操作未给用户提示提示窗口文字未采用行业术语可输入区域和只读区域没有明显的区分标志E类：测试建议处理优先级类类 别别描描 述述1立即修改完成（最高）立即修改完成（最高）影响测试进度的缺陷，重大影响测试进度的缺陷，重大的的功功能缺陷缺陷，需要及时处理的能缺陷缺陷，需要及时处理的2下一个阶段结束前必须修改完成功能没有达到需求的缺陷，设计上存在轻微缺陷的3 产品推出前必须修改完成系统上图片、文字、按钮、翻页上有的缺陷或建议4 时间允许再进行修改有缺陷，但不影响系统功能，只是系统使用起来不太方便5下个版本再修改（最低）在此版本中不做修改，进入下一版本时再做修改6 无法修改，不做处理因为所要求的内容不合理，所以不做处理
