软件质量保证与测试工程硕士

软件测试1内容前言第一章软件质量保证第二章软件测试概述第三章测试人员的数学知识第四章软件测试技术第五章软件测试过程第六章软件测试管理体系前言--内容课程的由来软件危机软件工程软件质量保证软件测试课程的介绍目标内容形式和要求参考书目前言--课程由来软件危机(1960s)表现：软件质量不高、超出预算、项目延迟根源：软件系统复杂性提高、多人合作解决：软件工程与软件相关的人员项目组用户和股东计算机系统设计技术控制复杂：人的思维极限抽象/建模分解重用：质量和效率语言与开发包OO前言--课程由来软件工程目标：解决沟通和集成问题策略：控制错误错误缺陷/Bug/Defect/Error狭义：软件定义、设计、实现、打包/部署、使用过程中出现的与明确的需求不一致：不能正确完成任务、完成多余的任务广义：还包括：改善产品的建议；与用户隐含的需求不一致前言--课程由来软件工程方法：预防错误：规范化流程、职责、角色、模式：RUP(RationalUnifiedProcess)、CMM/CMMI、Pattern表达方式：UML、Pattern文档化迭代与体系结构纠正错误：测试调试减少错误损失培训前言--课程由来SQA涉及的工作岗位过程改进工程师过程改进测试工程师软件测试开发工程师软件测试软件调试测试经理测试流程管理测试度量前言--内容课程的由来软件危机软件工程软件质量保证软件测试课程的介绍目标内容形式和要求参考书目前言--课程介绍目标学习质量保证的基本概念和理论学习软件测试的基本概念和理论掌握白盒测试/黑盒测试技术掌握单元测试/集成测试/系统测试技术掌握测试流程管理和测试度量技术掌握测试工具和测试流程管理工具了解测试相关工作的岗位要求和职业素质要求了解测试行业的现状和技术发展趋势前言--课程介绍内容测试工程师需要掌握的黑盒测试技术、集成测试/系统测试要求攻击式软件测试测试度量方法测试工具职业素质要求测试经理需要掌握的测试流程管理测试团队组织和测试度量测试流程管理工具和缺陷跟踪工具职业素质要求前言--课程介绍形式和要求学习前的要求：掌握软件工程基本概念掌握软件开发方法、高级程序设计语言和数据库相关知识了解Windows平台开发学习方式：课堂讲解上机实践（浪潮通软ERP或者自己开发计算器程序）课堂讨论或者课堂练习

成绩评定方法：期末笔试占总成绩的60%实践和课堂讨论（课堂练习）占总成绩的40%前言--课程介绍参考书目《软件测试基础》PaulAmmann,JeffOffutt，2010,机械工业出版社《软件测试案例教程》吕云翔，王洋等，2011，机械工业出版社《实用软件测试指南》马良荔，2003，电子工业出版社第一章软件质量保证17第一章内容

1.1软件质量

1.2软件质量保证：SQA1.2.1SQA目标1.2.2SQA模型1.2.2.1ISO90011.2.2.2CMMI1.3SQA支持工具1.1软件质量

什么是软件质量ANSI/IEEEStd729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。M.J.Fisher定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。1.1软件质量为什么提出软件质量软件质量不高是导致软件危机的根本原因进度延误、预算超支项目失败、项目终止软件质量高可以降低总成本软件维护成本高质量的软件可以降低维护成本，并延长软件的生命期，从而降低总成本软件失效成本高质量的软件可以降低软件失效导致的成本损失，从而降低总成本怎样提高软件质量目标优化软件开发过程减少软件中的bug方法防止在软件中引入错误

通过检测找出软件中的错误，并解决这种错误

1.1软件质量1.2软件质量保证：SQA什么是SQASoftwareQualityAssurance是软件工程领域中的一部分为了确保软件开发过程和结果符合预期的要求，而建立的一系列规程和计划，以及依照规程和计划采取的一系列活动及其结果评价软件开发过程是按照计划和规范实施的软件开发结果包括完整的软件和文档，并且符合可预期的目标和检验标准1.2.1SQA目标软件开发不同阶段：需求分析：RequirementsAnalysis规格定义：SoftwareSpecifications设计：Design编码：Coding测试：Testing维护：Maintenance1.2.1SQA目标需求分析：RequirementsAnalysis确保客户提出的要求是可行的确保客户了解自己提出的需求的含义，并且这个需求能够真正达到他们的目标确保开发人员和客户对于需求没有误解或者误会确保按照需求实现的软件系统能够满足客户提出的要求1.2.1SQA目标编码：Coding:确保建立了编码规范、文档格式标准，并且按照该标准进行编码确保代码被正确地测试和集成，代码的修改符合变更控制和版本控制流程确保按照计划的进度编写代码确保按照进化的进度进行代码评审1.2.1SQA目标测试：Testing:确保建立了测试计划，并按照测试计划进行测试确保测试计划覆盖了所有的系统规格定义和系统需求确保经过测试和调试，软件仍旧符合系统规格和需求定义1.2.1SQA目标维护：Maintenance:确保代码和文档同步更新，保持一致确保建立了变更控制流程和版本控制流程，并按照这些流程管理维护过程中的产品变化确保代码的更改仍旧符合编码规范、通过代码评审，并且不会造成垃圾代码或冗余代码1.2.2SQA模型质量管理历史质量就是产品、过程、系统符合标准要求的能力质量是生产出来的，不是检测出来的质量存在于全部直接/间接相关的环节中Deming(美国质量管理专家戴明博士

)，日本的全面质量管理TQM预防为主第一次就把事情做好是最经济的质量管理的灵魂在于持续改进PDCA1.2.2SQA模型软件质量管理相关标准和技术标准ISO9000族标准国际标准，ISO/TC176制订，适用于所有行业，其中9000-3针对软件开发行业SW-CMM/CMMI标准CMM:行业标准，CMU-SEI制订和管理，针对软件开发行业CMMI:集成的CMMISO15504标准国际标准，试图结合ISO9000、CMM与软件工程概念项目管理技术项目：目标、起止时间、相关活动定义、计划、实施1.2.2.1ISO9001ISO9000族标准一系列关于质量管理/质量保证/质量审核方面的国际标准，1983/1994/20009001/9002/9003/9004/9000-3是管理思想的精华，管理工作的指导原则，也是做事方式文档管理：写你要做的，做你所写的，记你所做的过程控制：PDCA---计划性及持续改进相关标准：QS9000等1.2.2.1ISO9001原则原则1：以顾客为中心组织依存于顾客。因此，组织应理解顾客当前和未来的需求，满足顾客要求并争取超越顾客期望原则2：领导作用领导将本组织的宗旨、方向和内部环境统一起来，并创造使员工能够充分参与实现组织目标的环境1.2.2.1ISO9001原则原则3：全员参与各级人员是组织之本。只有他们的充分参与，才能使他们的才干为组织带来最大的收益原则4：过程方法将相关的资源和活动作为过程进行管理，重视输入和输出，可以更高效地得到期望的结果1.2.2.1ISO9001原则原则5：管理的系统方法针对设定的目标，识别、理解并管理一个由相互关联的过程所组成的系统，有助于提高组织的有效性和效率原则6：持续改进持续改进是组织的一个永恒目标1.2.2.1ISO9001原则原则7：基于事实的决策方法对数据和信息的逻辑分析或直觉判断是有效决策的基础原则8：互利的供方关系通过互利的关系，增强组织及其供方创造价值的能力1.2.2.1ISO9001在软件企业的实施案例原则：运用项目管理技术重视质量策划重视培训和工具支持框架：质量手册、规程文件、作业指导书开发管理、体系支持1.2.2.1ISO9001在软件企业的实施案例角色分工1.2.2.1ISO9001在软件企业的实施案例产品开发规程1.2.2.1ISO9001在软件企业的实施案例定制项目开发规程1.2.2.1ISO9001在软件企业的实施案例体系支持规程管理评审规程

质量体系文件控制规程内部质量体系审核规程

纠正措施规程预防措施规程配置管理规程

质量记录控制规程产品度量规程过程度量规程采购规程配套软件产品控制规程

培训规程档案管理规定合同评审规程软件质量保证规程产品开发规程1.2.2.1ISO9001在软件企业的实施案例ISO9001是品质保证标准，对过程管理提出最低要求质量保证体系根据软件工程原理自行设计和维持，满足ISO9001要求质量策划根据项目自身特点，对质量体系进行剪裁和补充1.2.2.2CMMICMMI：CapabilityMaturityModelIntegration，即能力成熟度模型集成来源于：美国卡内基梅隆大学的软件工程研究所(SEI)创立的CMM(CapabilityMaturityModel软件能力成熟度模型)1.2.2.2CMMI目标为提高组织过程和管理产品开发、发布和维护能力提供保障。帮助组织客观评价自身能力成熟度和过程域能力，为过程改进建立优先级以及执行过程改进。1.3SQA支持工具SQA实施要素规范规程、模板、指南文档、记录人员分工、接口、培训、检查技术知识管理、工具1.3SQA支持工具支持工具自行开发厂商提供IBMRational第二章软件测试概述49内容2.1软件测试定义及术语2.2错误与缺陷的分类2.3软件测试的目标2.4软件测试的特征2.5测试用例及管理工具2.1什么是软件测试软件测试是为了发现错误而执行一个程序或系统的过程2.1软件测试的发展历史20世纪50年代之前，没有系统的软件测试20世纪50年代-60年代，测试的重点是高级语言编写的系统，软件测试发展缓慢20世纪70年代以后，软件测试发展迅速，同时面临着危机现在，软件测试是一个基于软件开发整个生命周期的质量控制活动2.1国内软件行业的现状处于起步阶段软件评测中心的出现2.1软件的生命周期阶段基本任务工作结果占工作量参加者开发期需求分析理解表达用户需求需求规格说明书SRS20％用户、系统分析员设计建立系统结构模块说明书数据说明15％高级程序员程序编写编程程序20％高级和初级程序员测试发现错误与排除错误可运行的系统45％模块测试25％其它20％测试部门运行期维护改进系统2.1相关术语软件故障：软件中的静态缺陷软件错误：不正确的内部状态，该状态是某个故障的表现软件失败：与需求或者其他期望行为的描述有关的、外部的、不正确的行为2.1相关术语以看病为例解释上述术语：病人带着一些失败（症状）进入医生办公室，医生必须发现故障（症状的根源）。为了帮助诊断，医生制定一些测试来寻找异常的内部条件，比如高血压、心律不齐等，这些异常的内部条件相当于错误。2.1相关术语软件测试与医生诊疗有质的不同：软件中的故障是设计错误医疗问题与计算机硬件故障一样，经常是物理退化的结果2.1相关术语PublicstaticintnumZero(int[]x){//效果：统计x中0出现的次数

intcount=0；

for(inti=1;i<x.length;i++){if(x[i]=0){count++;}}returncount;}

考虑输入为[2.7.0]和[0.7.2]时，上述程序的表现虽然有软件故障，但是第一个输入，软件并没有失败2.1相关术语上一页的例子说明，对于一个给定的故障，不是所有的输入都会“触发”故障来创建不正确的输出（失败）。要发现一个失败需要考虑下面3个条件：程序中包含故障的位置必须找到执行该位置后，程序的状态必须是不正确的受到影响的状态必须传播出来，引起改程序的某个输出是不正确的2.1软件故障产生的原因2.2软件测试的目的2.2软件测试的目的软件测试是一个为了寻找缺陷而运行程序的过程一个好的测试用例是很可能找到至今为止尚未发现的缺陷的测试用例一个成功的测试是揭示了至今为止尚未发现缺陷的测试软件测试的目标是设计这样的测试：既能系统的揭示不同类型的缺陷而且耗费最少的时间和最少的工作量2.2软件测试的原则测试能提高软件的质量，但是提高质量不能依赖测试确定预定的输出避免测试自己的程序彻底检查每一个测试结果对非法、非预期性输入的测试检查程序是否做了它不该做的事程序中存在错误的概率与已发现的错误数成正比保留测试用例

2.2软件测试中的误区调试和测试是一样的测试组应该为保证质量负责过分依赖Beta测试把测试作为新员工的一个过渡工作把不合格的开发人员安排作测试关注测试的执行，忽略测试的设计2.2软件测试中的误区（续）测试自动化是万能的测试时可以穷尽的测试是为了证明软件的正确性测试是枯燥乏味，缺乏创造力的工作2.2软件测试人员应具备的素质探索精神故障排除能力不懈努力创造性追求完美判断准确老练稳重说服力2.3软件缺陷软件未达到产品描述标明的功能/非功能要求软件出现了产品描述指明不会出现的错误软件功能超出了产品描述指明的功能 软件未达到产品描述虽未指明但应达到的目标测试人员或者最终用户认为软件难以理解、不易使用、运行速度缓慢2.3缺陷分类轻微词语拼写错误中等误导或重复信息使人不悦被截断的名称影响使用有些交易没有处理严重丢失交易2.3缺陷分类（续）非常严重不正确的交易处理极为严重经常出现“非常严重”错误无法忍受数据库破坏灾难性系统停机容易传染扩展到其他系统停机2.4软件测试的特征软件测试具有一定的风险软件缺陷的寄生虫性软件测试的杀虫剂现象软件测试的不修复原则Pareto原则2.4完全测试程序是不可能的输入量太大输出结果太多软件实现途径太多软件说明书没有客观标准2.4软件测试是有风险的行为2.4软件缺陷的寄生虫性找到的缺陷越多，说明软件存在的缺陷越多原因：程序员的疲倦程序员往往犯同样的错误某些软件缺陷可能是大灾难的征兆2.4软件测试的杀虫剂现象软件测试越多，其免疫力越强方案：编写新的测试用例对程序的不同部分进行测试2.4软件测试的不修复原则并非所有的软件缺陷都需要修复原因：没有足够的时间，项目进度决定不算真正的缺陷，是一项功能修复风险太大，可能导致其它bug不值得修复，不常用的功能，不常出现的bug，可以躲过的2.4Pareto原则2.5什么是测试用例？测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。2.5系统测试用例的好处（一）要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。2.5系统测试用例的好处（二）对测试过程可以进行进行有效的监督，可以准确、有效的评估测试的工作量2.5系统测试用例的好处（三）可以对测试结果进行评估，并且对测试是否完成产生一个量化的结果2.5系统测试用例的好处（四）可以在回归测试的过程中准确、快速的进行正确的回归2.5系统测试用例的好处（五）测试用例的使用令软件测试的实施重点突出、目的明确2.5系统测试用例的好处（六）在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。2.5系统测试用例的好处（七）在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期2.5系统测试用例的范围用户的需求，包括用户提出的功能性需求、非功能性需求等系统测试用例需要考虑的问题：功能、易用性、性能、安全等2.5测试用例的局限性我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。2.5测试用例设计人员测试用例应由测试设计员或专职测试工程师来制定，而不是普通的测试执行人员；应该让最有能力的人员来完成用例的设计2.5测试用例要素编号：唯一编号前置条件：说明测试路径重要级别：对后期的测试用例执行的考核提供一个标准输入：输入的条件期望输出：期望输出的结果实际输出：实际输出的结果是否正确：是/否执行人：测试用例执行人标志执行时间：测试用例执行的时间备注：其他说明文字2.5练习一有两个有故障的程序，每个包含了一个以失败为结果的测试用例，确定程序中的故障。练习一2.5测试用例编写1、Word2、Excel3、系统管理（TestDirector、Bugzilla）2.5TestDirectorMercuryInteractive公司（2006年被HP以45亿美元收购）的测试管理工具2.5TestDirector-测试管理过程需求定义（SpecifyRequirements）：分析应用程序并确定测试需求。测试计划（PlanTests）：基于测试需求，建立测试计划。测试执行（ExecuteTests）：创建测试集（TestSet）并执行测试。缺陷跟踪（TrackDefects）：报告程序中产生的缺陷并跟踪缺陷修复的全过程。贯穿测试的每一个阶段，你能够通过产生详细的报告和图标对数据进行分析。2.5TestDirector-需求定义定义测试范围（DefineTestingScope）：检查应用程序文档，并确定测试范围——测试目的、目标和策略。创建需求（CreateRequirements）：创建需求树（RequirementsTree），并确定它涵盖所有的测试需求。描述需求（DetailRequirements）：为“需求树”中的每一个需求主题建立了一个详细的目录，并描述每一个需求，给它分配一个优先级，如有必要的话还可以加上附件。分析需求（AnalyzeRequirements）：产生报告和图表来帮助你分析测试需求，并检查需求以确保它们在你的测试范围内。TestDirector-需求定义2.5TestDirector-需求描述优先级：Low,Medium,High,VeryHigh,Urgent覆盖状态：nocovered,passed,nocompleted,norun,failedTestDirector-需求描述2.5TestDirector-测试计划定义测试策略（DefineTestingStrategy）：检查应用程序、系统环境和测试资源，并确认测试目标。定义测试主题（DefineTestSubject）：将应用程序基于模块和功能进行划分，并对应到各个测试单元或主题，构建测试计划树（TestPlanTree）。定义测试（DefineTests）：定义每个模块的测试类型，并为每一个测试添加基本的说明。创建需求覆盖（CreateRequirementsCoverage）：将每一个测试与测试需求进行连接。2.5TestDirector-测试计划设计测试步骤（DesignTestSteps）：对于每一个测试，先决定其要进行的测试类型（手动测试和自动测试），若准备进行手动测试，需要为其在测试计划树上添加相应的测试步骤（TestSteps）。测试步骤描述测试的详细操作、检查点和每个测试的预期结果。自动测试（AutomateTests）：对于要进行自动测试的部分，应该利用MercuryInteractive、自己或第三方的测试工具来创建测试脚本。分析测试计划（AnalyzeTestPlan）：产生报告和图表来帮助你分析测试计划数据，并检查所有测试以确保它们满足你的测试目标。TestDirector-测试计划TestDirector-建立测试覆盖TestDirector-测试步骤2.5TestDirector-测试执行创建测试集（CreateTestSets）：在你的工程中定义不同的测试组来达到各种不同的测试目标，他们可能包括，举个例子，在一个应用程序中测试一个新的应用版本或是一个特殊的功能。并确定每个测试集都包括了哪些测试。确定进度表（ScheduleRuns）：为测试执行制定时间表，并为测试员分配任务。运行测试（RunTests）：自动或手动执行每一个测试集。分析测试结果（AnalyzeTestResults）：查看测试结果并确保应用程序缺陷已经被发现。生成的报告和图表可以帮助你分析这些结果。TestDirector-建立测试集TestDirector-加入测试集2.5TestDirector-缺陷跟踪添加缺陷（AddDefects）：报告程序测试中发现的新的缺陷。在测试过程中的任何阶段，质量保证人员、开发者、项目经理和最终用户都能添加缺陷。检查新缺陷（ReviewNewDefects）：检查新的缺陷，并确定哪些缺陷应该被修复。修复打开的缺陷（RepairOpenDefects）：修复那些你决定要修复的缺陷。测试新构建（TestNewBuild）：测试应用程序的新构建，重复上面的过程，直到缺陷被修复。分析缺陷数据（AnalyzeDefectData）：产生报告和图表来帮助你分析缺陷修复过程，并帮助你决定什么时候发布该产品。TestDirector-缺陷跟踪TestDirector-添加缺陷2.5TestDirector-缺陷状态New：测试人员新发现的缺陷open：经开发负责人检查后，确认是缺陷，将其状态设置为openFixed：开发人员对于缺陷修复完毕后，将其状态置为fixedRejected：如果发现不是缺陷或者是重复缺陷，开发负责人将缺陷的状态置为rejectedClosed：对于状态是fixed或者是rejected的缺陷，可以关闭，closed是缺陷的最终状态Reopen：对于状态是fixed的缺陷，如果测试人员经过验证后，发现没有完全修复，将其状态置为reopenTestDirector—主页面TestDirector—创建项目TestDirector-创建用户TestDirector-登陆2.5编写测试用例需要考虑的问题1、测试用例的执行结果可以作为测试报告的一个附件提交，从而提高测试报告的能够更准确的反映测试的进展2、通过对测试用例的执行情况的汇总、统计，可以得出系统目前所进行的测试工作是否充分、必要，是否已经达到了预期的效果，测试是否已经按计划完成等第三章测试人员的数学知识1153.1集合论集合定义：一组明确的、互不相同的事物组成的整体，称为一个集合。集合与成员：组成集合的各个事物称为该集合的元素。3.1集合定义方式全部列举：写出集合的所有元素部分列举：列举部分元素，其它元素用省略号代替规定集合的元素所满足的条件：A={x|x具有的性质P}3.1空集空集是不包含任何元素的集合空集表示：ΦΦ和{Φ}是不同的Φ＝{年|2012≤年≤1812}3.1维恩图维恩图是由两个或者两个以上重叠的圆组成的，用于表示集合之间的相互关系。集合的关系

A是B的子集AÍBA是B的真子集AÌB A和B是相等集合A=B3.1集合划分集合的划分

A1,A2,…,An是集合A的子集

A1,A2,…,An是集合A的一个划分

A1∪A2∪…∪An=A且

Ai∩Aj…=Φ(i!=j)3.1集合划分在测试中的应用测试（1）完备性（2）无冗余性比如：三角形和非三角形

等边、等腰、不等边和非三角形

等边、等腰、不等边、直角和非三角形3.2函数任何程序都可以看成将其输出与输入关联起来的函数，因此函数是开发测试的核心概念。1对1函数/多对1函数程序实现的功能大多数是多对一的函数，这对测试很重要（多对一测试可选代表等价类1对1功能相似也可分等价类）3.3概率论测试中研究语句执行特定路径的概率事件的概率P(E)=│E│/│S│ s是有限样本空间，E是事件3.4图论有向图无向图定义：图G=(V,E)由结点的有限非空集V和结点无序对偶集E组成图通过关联矩阵表示图G=(V,E)的关联矩阵是m×n矩阵3.4图论相邻矩阵

n1n2n3n4n5n6n7N10101000N21000100N30001000N41010010N50100000N60001000N700000003.4图论路径结构化测试中用例路径是一系列的边或一系列的节点3.4图论有向图（框图）D=(V,E)一个节点有限集合V一个边的集合E有向图即可表示程序框图有向图相邻矩阵：有m个节点的有向图D=(V,E)的相邻矩阵是一个m×m矩阵有向图的路径：有向图的路径是一系列的边，使得该序列中所有相邻对偶ei，ej第一条边的终止节点是第二条边的起始节点第四章测试技术128内容4.1功能测试技术4.1.1白盒静态测试4.1.2白盒动态测试4.1.3基于场景测试4.1.4黑盒测试4.1.5因果图测试4.1.6侵入测试4.1.7错误猜测法4.2功能测试总结4.3自动化功能测试4.4非功能测试技术4.5自动化非功能测试4.6非功能测试案例4.7GUI测试4.1静态与动态测试4.1功能测试功能测试的基本方法是构造一些合理或者不合理的输入，检查输出是否与期望的相同。如果两者不一致，即表明功能有误。也有例外的情况，如《需求规格说明书》中的某个功能写错了，而实际上软件的功能却是正确的，这时要更改的是《需求规格说明书》。功能测试看起来比较简单，只要看得懂《需求规格说明书》，谁都会做。难点在于如何构造有效的输入。由于输入空间通常是无限的，穷举测试显然行不通。随便输入一些东西，碰运气也是行不通的4.1功能测试肯定测试：验证系统和它陈述的需求一致否定测试：证明一个系统不会作不需要它做的事情4.1录音机需求状态：备用、打开、播放、停止在备用模式时，按打开按钮打开录音机当录音机打开时，按备用按钮回到备用模式当录音机打开时，按播放按钮开始播放当前磁带，按停止按钮停止播放4.1肯定测试的用例在备用模式时，按打开按钮打开录音机当录音机打开时，按备用按钮回到备用模式当录音机打开时，按播放按钮开始播放当前磁带，按停止按钮停止播放4.1否定测试的用例当录音机正在播放磁带时，按下备用按钮会怎样？按下打开按钮会怎样？当录音机打开并且没有磁带时，按下播放按钮会怎样？按下停止按钮会怎样？当录音机正在播放磁带时，断电。4.1功能测试技术白盒测试黑盒测试4.1白盒测试和黑盒测试白盒测试：对于测试对象的内部内容是透明的、可见的，可以设计数据覆盖测试对象的每一条路经。黑盒测试：黑盒法不关心程序内部的逻辑，而只是根据程序的功能说明来设计测试用例4.1.1白盒测试4.1.1白盒测试代码检查静态结构分析代码质量度量功能确认与接口分析逻辑覆盖率分析性能与效率分析内存分析4.1.1白盒法--静态测试代码检查静态结构分析4.1.1白盒法—代码检查目的确保代码编程规范被有效执行检查代码是否存在逻辑上的错误4.1.1白盒法—代码检查变量命名和类型检查变量初始值检查变量作用范围检查程序逻辑审查程序语法检查程序结构检查4.1.1白盒法—代码检查排除违背程序编写标准的问题排除违背程序编程风格的问题确保代码和设计的一致性确保代码的逻辑表达的正确性确保代码结构的合理性找出程序中不可移植的部分发现程序中不安全、不明确、模糊的部分实践表明，程序走查平均能查出被测程序的30%--70%的逻辑设计和代码缺陷，IBM代码走查能够检查出80%的错误4.1.1白盒法—代码检查需求描述文档程序设计文档程序的源代码清单代码编码标准代码缺陷检查表4.1.1C/C++代码检查表文件结构程序的版式命名规则表达式与基本语句常量函数设计内存管理C++函数的高级特性类的构造函数、析构函数类的高级特性其他特性4.1.1文件结构头文件和定义文件的名称是否合理头文件和定义文件的目录结构是否合理版权和版本声明是否完整4.1.1程序的版式空行是否得体?代码行内的空格是否得体?长行拆分是否得体?“{”和“}”是否是否各占一行并且对齐于同一列一行代码是否只做一件事情?如只写一条语句If,for,while,do等语句各占一行，不论执行多少语句都写{}4.1.1命名规则命名规则是否与采用的操作系统或者开发工具的风格保持一致标示符是否直观并且可以拼读4.1.1程序的版式If(year>=2000)//良好的版式If(year>=2000)//不良的版式If(a>=b)&&(c<=d)//良好的版式If(a>=b&&c<=d)//不良的版式4.1.1表达式与基本语句如果代码行中的运算符比较多,是否已用括号清楚地确定表达式的运算顺序是否编写太复杂或者多用途的复合表达式4.1.2白盒法动态测试voidDoWork(intx,inty,intz){intk=0,j=0;if((x>3)&&(z<10)){k=x*y-1;//语句块1

j=sqrt(k);}if((x==4)||(y>5)){j=x*y+10;//语句块2}

j=j%3;//语句块3}4.1.2流程图4.1.2白盒法语句覆盖判定覆盖条件覆盖判定/条件覆盖

条件组合覆盖路径测试4.1.2白盒法－语句覆盖

语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次；4.1.2白盒法－语句覆盖为了说明简略，分别对各个判断的取真、取假分支编号为a、b、c、d、e。

为了测试语句覆盖率只要设计一个测试用例就可以把三个执行语句块中的语句覆盖了。 测试用例输入为：{x=4、y=5、z=5}

程序执行的路径是：abd

该测试用例虽然覆盖了可执行语句，但并不能检查判断逻辑是否有问题，例如在第一个判断中把&&错误的写成了||，则上面的测试用例仍可以覆盖所有的执行语句。可以说语句覆盖率是最弱的逻辑覆盖准则。4.1.2白盒法－判定覆盖

执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值，或者说使得程序中的每一个分支至少都通过一次。4.1.2白盒法－判定覆盖对于上面的程序，如果设计两个测试用例则可以满足条件覆盖的要求。测试用例的输入为： {x=4、y=5、z=5} {x=2、y=5、z=5}

上面的两个测试用例虽然能够满足条件覆盖的要求，但是也不能对判断条件进行检查，例如把第二个条件y>5错误的写成y<5,、上面的测试用例同样满足了分支覆盖。4.1.2白盒法－条件覆盖执行足够的测试用例，使得判定中的每个条件获得各种可能的结果。

4.1.2白盒法－条件覆盖对例子中的所有条件取值加以标记。例如： 对于第一个判断： 条件x>3取真值为T1，取假值为-T1

条件z<10取真值为T2，取假值为-T2

对于第二个判断： 条件x=4取真值为T3，取假值为-T3

条件y>5取真值为T4，取假值为-T44.1.2白盒法－条件覆盖测试用例通过路径条件取值覆盖分支x=4、y=6、z=5abdT1、T2、T3、T4bdx=2、y=5、z=5ace-T1、T2、-T3、-T4cex=4、y=5、z=15acdT1、-T2、T3、-T4cd上面的测试用例不但覆盖了所有分支的真假两个分支，而且覆盖了判断中的所有条件的可能值。4.1.2白盒法－条件覆盖但是如果设计了下面的测试用例，则虽然满足了条件覆盖，但只覆盖了第一个条件的取假分支和第二个条件的取真分支，不满足分支覆盖的要求。测试用例通过路径条件取值覆盖分支x=2、y=6、z=5acd-T1、T2、-T3、T4cdx=4、y=5、z=15acdT1、-T2、T3、-T4cd4.1.2白盒法－条件判定覆盖执行足够的测试用例，使得判定中每个条件取到各种可能的值，并使每个判定得到各种可能的结果。

4.1.2白盒法－条件判定覆盖根据定义只需设计以下两个测试用例便可以覆盖8个条件值以及4个判断分支。测试用例通过路径条件取值覆盖分支x=4、y=6、z=5abdT1、T2、T3、T4bdx=2、y=5、z=11ace-T1、-T2、-T3、-T4ce4.1.2白盒法－条件判定覆盖 分支条件覆盖从表面来看，它测试了所有条件的取值，但是实际上某些条件掩盖了另一些条件。例如对于条件表达式(x>3)&&(z<10)来说，必须两个条件都满足才能确定表达式为真。如果（x>3）为假则一般的编译器不在判断是否z<10了。对于第二个表达式（x==4）||（y>5）来说，若x==4测试结果为真，就认为表达式的结果为真，这时不再检查（y>5）条件了。因此，采用分支条件覆盖，逻辑表达式中的错误不一定能够查出来了。4.1.2白盒法－条件组合覆盖执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次

4.1.2白盒法－条件组合覆盖x>3,z<10记做T1T2，第一个判断的取真分支x>3,z>=10记做T1-T2，第一个判断的取假分支x<=3,z<0记做-T1T2，第一个判断的取假分支x<=3,z>=10记做-T1-T2，第一个判断的取假分支x=4,y>5记做T3T4，第二个判断的取真分支x=4,y<=5记做T3-T4，第二个判断的取真分支x!=4,y>5记做-T3T4，第二个判断的取真分支x!=4,y<=5记做-T3-T4，第二个判断的取假分支4.1.2白盒法－条件组合覆盖根据定义取4个测试用例，就可以覆盖上面8种条件取值的组合。测试用例如下表：测试用例通过路径条件取值覆盖组合号x=4、y=6、z=5abdT1、T2、T3、T41和5x=4、y=5、z=15acdT1、-T2、T3、-T42和6x=2、y=6、z=5acd-T1、T2、-T3、T43和7x=2、y=5、z=15ace-T1、-T2、-T3、-T44和84.1.2白盒法－条件组合覆盖上面的测试用例覆盖了所有条件的可能取值的组合，覆盖了所有判断的可取分支，但是却丢失了一条路径abe。4.1.2白盒法－路径测试路径测试就是设计足够多的测试用例，覆盖被测试对象中的所有可能路径。4.1.2白盒法－路径测试上面的例子是一个很简单的程序函数，只有四条路径。但在实践中，一个不太复杂的程序，其路径都是一个庞大的数字，要在测试中覆盖所有的路径是不现实的。为了解决这一难题，只得把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行一次。下面介绍的基本路径测试就是这样一种测试方法，它在程序控制图的基础上，通过分析控制构造的环行复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。4.1.2白盒法路径测试在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。包括以下4个步骤4.1.2白盒法路径测试程序的控制流图：描述程序控制流的一种图示方法。程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。准备测试用例：确保基本路径集中的每一条路径的执行。

4.1.2白盒法-控制流图的符号在介绍基本路径方法之前，必须先介绍一种简单的控制流表示方法，即流图。流图使用下面的符号描述逻辑控制流，每一种结构化构成元素有一个相应的流图符号。4.1.2白盒法voidSort(intiRecordNum,intiType)1{2intx=0;3inty=0;4while(iRecordNum-->0)5{6 if(0==iType)7 x=y+2;8else9 if(1==iType)10x=y+10;11else12x=y+20;13}14}4.1.2第一步：画出控制流图

c/c++语句中的控制语句表示含义如下： 图中的每一个圆称为流图的结点，代表一条或多条语句。流图中的箭头称为边或连接，代表控制流。

4.1.2白盒法4679101113144671491011144.1.2白盒法

程序设计中遇到复合条件时，生成的流图变得更为复杂。当条件语句中用到一个或多个布尔运算符(逻辑OR，AND，NAND，NOR)时，就出现了复合条件。下图为语句IFaORb中的每一个a和b创建了一个独立的结点，包含条件的结点被称为判定结点，从每一个判定结点发出两条或多条边。例如：1ifaorb2x3else4y

对应的逻辑为：4.1.2第二步：计算圈复杂度圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。

4.1.2第二步：计算圈复杂度有以下两种方法计算圈复杂度：给定流图G的圈复杂度：V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量；给定流图G的圈复杂度：V(G)，定义为V(G)=P+1，P是流图G中判定结点的数量。4.1.2第二步：计算圈复杂度对应上面图中的圈复杂度，计算如下：V(G)=10条边-8结点+2=4;V(G)=3个判定结点+1=4。4671491011144.1.2第三步：导出测试用例 根据上面的计算方法，可得出四个独立的路径：路径1：4-14路径2：4-6-7-14路径3：4-6-8-10-13-4-14路径4：4-6-8-11-13-4-14 根据上面的独立路径，去设计输入数据，使程序分别执行到上面四条路径。4.1.2第四步：准备测试用例 为了确保基本路径集中的每一条路径的执行，根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到，满足上面例子基本路径集的测试用例是：路径1：4-14输入数据：iRecordNum＝0，或者取iRecordNum<0的某一个值预期结果：x＝0路径2：4-6-7-14输入数据：iRecordNum＝1,iType＝0预期结果：x＝24.1.2第四步：准备测试用例路径3：4-6-8-10-13-4-14输入数据：iRecordNum＝1,iType＝1预期结果：x＝10路径4：4-6-8-11-13-4-14输入数据：iRecordNum＝1,iType＝2预期结果：x＝204.1.2白盒法－循环测试

循环测试是一种白盒测试技术，注重于循环构造的有效性。有四种循环：简单循环,串接循环，嵌套循环和不规则循环。简单循环嵌套循环串接循环不规则循环4.1.2白盒法－循环测试简单循环：下列测试集用于简单循环，其中n是允许通过循环的最大次数。整个跳过循环；只有一次通过循环；两次通过循环；m次通过循环，其中m<n；n-1，n,n+1次通过循环。4.1.2白盒法－循环测试嵌套循环： 如果将简单循环的测试方法用于嵌套循环，可能的测试数就会随嵌套层数成几何级增加，这会导致不实际的测试数目，下面是一种减少测试数的方法：从最内层循环开始，将其它循环设置为最小值；对最内层循环使用简单循环，而使外层循环的迭代参数（即循环计数）最小，并为范围外或排除的值增加其它测试；由内向外构造下以个循环的测试，但其它的外层循环为最小值，并使其它的嵌套循环为“典型”值；继续直到测试所有的循环。4.1.2白盒法－循环测试串接循环： 如果串接循环的循环都彼此独立，可是使用嵌套的策略测试。但是如果两个循环串接起来，而第一个循环是第二个循环的初始值，则这两个循环并不是独立的。如果循环不独立，则推荐使用的嵌套循环的方法进行测试。不规则循环：不能测试，尽量重新设计给结构化的程序结构后再进行测试。4.1.3使用用例场景设计测试用例用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有的基本流和备选流。4.1.3使用用例场景设计测试用例现在的软件都是由事件触发来控制流程的，事件触发时的情景便形成了场景。将软件设计中的思想引入到软件测试中最早由Rational公司提出4.1.3使用用例场景设计测试用例黑线：基本流彩色线：备选流4.1.3可能的场景场景一：基本流场景二：基本流备选流1场景三：基本流备选流1备选流2场景四：基本流备选流3场景五：基本流备选流3备选流1场景六：基本流备选流3备选流1备选流2场景七：基本流备选流4场景八：基本流备选流3备选流44.1.3ATM取款场景－基本流ATM处于就绪状态1准备提款：客户将银行卡插入ATM2验证卡：ATM读取卡信息3输入PIN：ATM要求的PIN4验证帐户和PIN：帐户和密码是否正确5ATM选项：ATM显示本机上所有的选项4.1.3ATM取款场景－基本流6输入金额：要从ATM中提取的金额7授权：ATM将帐户、密码和金额提交银行系统进行验证8出钞：提供现金9返回银行卡：银行卡被返回10收据：打印凭单ATM就绪状态4.1.3ATM取款场景－备选流备选流1：银行卡无效备选流2：ATM内没有现金备选流3：ATM内现金不足备选流4：PIN有误备选流5：帐户不存在4.1.3ATM取款场景－备选流备选流6：帐面金额不足备选流7：达到每日最大提款额备选流8：记录错误备选流9：退出备选流10：暂停4.1.3ATM取款场景场景1：成功提款基本流场景2：没有现金基本流备选流2场景3：现金不足基本流备选流3场景4：密码有误基本流备选流4场景5：密码有误基本流备选流4场景6：帐户不存在基本流备选流5场景7：余额不足基本流备选流6场景8：达到每日最大题款数基本流备选流74.1.3测试用例V:valid有效;I:invalid无效;n/a:不适用4.1.3测试用例4.1.4黑盒测试等价分类法边缘值分析法因果图法错误推测法4.1.4黑盒测试4.1.4等价类划分被测试系统的输入和输出可以被分组或划分为相关的组或类步骤：1.划分等价类

2.选择测试用例

4.1.4等价类划分实例a<=X1<=de<=x2<=g4.1.4等价类划分-弱一般等价类弱一般等价类测试通过使用一个测试用例中的每个等价类的一个变量实现基于单缺陷假设单缺陷假设：失效极少有两个（或多个）缺陷的同时发生引起的。4.1.4等价类划分-弱一般等价类4.1.4等价类划分-强一般等价类强一般等价类测试基于多缺陷假设，因此需要等价笛卡儿积的每个元素对应的测试用例笛卡儿积可以保证两种意义上的完备性：1、覆盖所有的等价类2、可能的输入组合4.1.4等价类划分-强一般等价类4.1.4等价类划分-弱健壮等价类健壮：考虑了无效值弱：基于单缺陷假设4.1.4等价类划分-弱健壮等价类4.1.4等价类划分-强健壮等价类健壮：考虑了无效值强：基于多缺陷假设4.1.4等价类划分-强健壮等价类4.1.4测试用例实例程序TRANLE输入三个整数，它们表示一个三角形的三条边长，该程序产生一个结果指出三角形是等腰三角形、等边三角形还是不等边三角形

请利用15分钟进行测试用例设计4.1.4测试用例实例（续）合理的不等边三角形（输入数据为1、2、3或2、5、10等不能算这一类）

合理的等边三角形（输入数据为0、0、0不算）

合理的等腰三角形（输入数据为2、2、4等不能算这一类）等腰三角形的三种排列次序(3，3，4;3，4，3;4，3，3)4.1.4测试用例实例（续）三个正数，其中两个之和等于第三个

上一种情况的三种排列次序

三个正数，其中两个之和小于第三个

上一种情况的三种排列次序

输入数据含有零值

输入数据含有负数4.1.4测试用例实例（续）输入数据含有非整数值三个数均为零

输入数据不是三个数

输入数据中有字符

4.1.4功能测试－等价类划分划分等价类在很大程度上是试探性的，下面几点可供参考:1）如果某个输入条件说明了输入值的范围，如“数据值”是从1到999，则可划分一个合理等价类：大于等于1而小于等于999的数和两个不合理等价类：小于1的数，以及大于999的数。4.1.4功能测试－等价类划分2)如果某个输入条件说明了输入数据的个数,如每个学生可以选修1至3门课程，则可划分一个合理等价类：选修1~3门课程〉和两个不合理等价类：没选修课程，以及超过3门课程。4.1.4功能测试－等价类划分3）如果一个输入条件说明了一个“必须成立”的情况，如标识符的第一个字符必须是字母，则可划分一个合理等价类：第一字符是字母和一个不合理等价类第一字符不是字母。4.1.4功能测试－等价类划分4）如果某个输入条件说明了输入数据的一组可能的值，而且认为程序是用不同的方式处理每一种值的，如职称的输入值可以是助教、讲师、副教授和教授4种，则可为每一种值划分一个合理等价类：助教、讲师、副教授和教授，并划分一个不合理等价类：上述4种职称之外的任意值。4.1.4功能测试－等价类划分5）如果认为程序将按不同的方式来处理某个等价类中的各种测试用例，则应将这个等价类再分成几个更小的等价类。如上面第4）就是将一个合理等价类又分成助教、讲师等4个等价类。4.1.4等价类实例－三角形问题R1={<a,b,c>:等边三角形}R2={<a,b,c>:等腰三角形}R3={<a,b,c>:不等边三角形}R4={<a,b,c>:不构成三角形}4.1.4等价类划分实例测试用例号旅馆收费被测分区预期输出1500<旅馆收费<=70正确2-25旅馆收费<=0错误信息389旅馆收费>70错误信息4.1.4功能测试－等价类划分1）为每个等价类编号。2）设计一个新的测试用例，使它能包括尽可能多的尚未被包括的合理等价类;重复做这一步，直至这些测试用例已包含所有的合理等价类。3）设计一个新的测试用例，使它包括一个(而且仅仅一个)尚未被包括的不合理等价类，重复做这一步，直至测试用例己包括所有的不合理等价类。

4.1.4功能测试－等价类划分考察一个把数字串转变成整数的函数。用二进制补码表示整数，机器字长16位，即整数范围最小为-32768，最大为32767。函数及参数的说明如下：

functionStrToInt(dstr:shortstr):integer;typeshortstr=array[1..6]ofchar;要求被处理的数字串是右对齐的，即在少于6个字符的串左补空格。负号在最高位数字左边一位。试用等价划分法设计测试方案。4.1.4功能测试－等价类划分首先根据规格说明划分等价类。考虑到PASCAL编译器的固有检错功能，测试时不需要使用长度不等于6的数组，也不需要用非字符数组类型的参数。有效输入类：①1~6个数字字符组成的数字串（最高位非0）；②最高位为0的数字串；③最高位左邻负号的数字串；无效输入类：④空字符串（6位空格）；⑤左边补位的既非0亦非空格；⑥最高位右边含有空格；⑦最高位右边含有其它非数字字符；⑧负号与最高位间有空格；4.1.4功能测试－等价类划分有效输出类：⑨在合法范围内的负整数；10110；在合法范围内的正整数；无效输出类：小于-32768的负整数；大于32767正整数。12134.1.4功能测试－等价类划分下面根据等价划分，设计出一套测试方案：①1~6个数字字符组成的数字串，最高位非0；输出为合法正整数。输入：‘1’预期输出：1②最高位为0的数字串，输出为合法正整数。输入：’01’预期输出：14.1.4功能测试－等价类划分③负号与最高位数字相临；输出合法负整数。输入：’-1’预期输出：-1④最高位为0；输出0。输入：’0’预期输出：0⑤太小的负整数。输入：’-123456789’预期输出：“错误，无效输入”⑥太大的正整数。输入：’123456789’预期输出：“错误，无效输入”4.1.4功能测试－等价类划分⑦空字符串。输入：’’预期输出：“错误：没有数字”⑧左边补位的非0也非空格。输入：‘q1478’预期输出：“错误：非法填充”⑨最高位右边也含空格。输入：’0123’预期输出：“错误：无效输入”⑩最高位右边含其它非数字字符。输入：’1a123’预期输出：“错误：无效输入”负号与最高位间有空格。输入：’-125’预期输出：“错误：负号位置非法”114.1.4边界值分析错误更可能出现在输入变量的极值附近MinMin+NomMax-Max考虑输出值1.划分等价类

2.选择测试用例4.1.4边界值分析4.1.4边界值分析－健壮性测试4.1.4边界值测试一、如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据；

4.1.4边界值测试二、如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1个、比最小个数少1个的数做为测试数据；三、根据规格说明的每一个输出条件，使用规则一；

4.1.4边界值测试四、根据规格说明的每一个输出条件，使用规则二；五、如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试用例；

4.1.4边界值测试六、如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例；

七、分析规格说明，找出其他可能的边界条件。4.1.4边界值分析－实例1测试用例号旅馆收费被测边界预期输出123-101

0错误信息错误信息正确456697071

70正确正确错误信息4.1.4边界值分析－实例2假

设

商

店

货

品

价

格(R)皆

不

大

於100元

（

且

为

整

数

）

，

若

顾

客

付

款

在100元

内(P)，

求

找

给

顾

客

之

最

少

货币

个（张）

数

？

（

货

币

面

值50元(N50)，10元(N10)，5元(N5)，1元(N1)四

种

）

4.1.4边界值分析－实例2分

析

输

入

的

情

形

R>1000<R<=100

R<=0

P>100

R<=P<=100

P<R4.1.4边界值分析－实例2分

析

输

出

情

形

N50=1N50=0

4>N10>=1

N10=0

N5=1

N5=0

4>N1>=1

N1=04.1.4边界值分析－实例2RR1,RR2,RR3表示应找的钱数R>100R<=0

P>100

P<R

RR1>=50

RR2>=10

RR3>=54.1.4边界值分析－实例2输入／输出条件组合出可能的情形:

R>100R<=0

0<R<=100,P>100

0<R<=100,P<R

0<R<=100,R<=P<=100,RR=50

0<R<=100,R<=P<=100,RR=49

0<R<=100,R<=P<=100,RR=10

4.1.4边界值分析－实例20<R<=100,R<=P<=100,RR=9

0<R<=100,R<=P<=100,RR=5

0<R<=100,R<=P<=100,RR=4

0<R<=100,R<=P<=100,RR=1

0<R<=100,R<=P<=100,RR=04.1.4边界值分析－实例21.货品价格=1012.货品价格=03.货品价格=-14.货品价格=100,付款金额=1015.货品价格=100,付款金额=996.货品价格=50,付款金额=1007.货品价格=51,付款金额=1004.1.4边界值分析－实例28.货品价格=90,付款金额=1009.货品价格=91,付款金额=10010.货品价格=95,付款金额=10011.货品价格=96,付款金额=10012.货品价格=99,付款金额=10013.货品价格=100,付款金额=1004.1.4边界值分析－实例2见附件4.1.4黑盒测试NextDate函数是一个有三个变量的（年、月、日）的函数，函数返回输入日期后面的那个日期。Y:1812<=年份<=2012M：1<=M<=12D：1<=D<=31请用黑盒测试设计其测试用例4.1.5因果图法等价分类法和边界值分析法都没有考虑输入情况的各种组合，也没有考虑各个输入情况之间的相互制约关系因果图方法的思路：从用自然语言书写的需求规格说明书中找出因（输入条件）和果（输出或者程序状态的改变），通过因果图转换为判定表4.1.5因果图法的几个步骤分析需求规格说明书，找出原因和结果分析需求规格说明书中的语义内容，并将其表示成连接各个原因与各个结果的“因果图”对原因和结果的组合情况不可能出现的，在因果图上使用若干特殊符号表明约束条件4.1.5因果图法的几个步骤（续）把因果图转换成判定表把判定规则(每一列)转换成测试用例4.1.5因果图的基本图形符号在因果图中用Ci表示原因，Ei表示结果，各节点表示状态。4.1.5因果图的基本图形符号说明恒等：若原因出现，则结果出现；若原因不出现，则结果也不出现。非：若原因出现，则结果不出现；若原因不出现，则结果出现。或：若几个原因中有1个出现，则结果出现；若几个原因都不出现，则结果不出现。与：若几个原因都出现，结果才出现；若其中有1个原因不出现，则结果不出现。4.1.5因果图的约束符号4.1.5因果图的约束符号说明异：表示几个原因不会同时成立，最多有一个成立或：多个原因中至少有一个必须成立唯一：表示各种原因中必须有一个，且仅有一个成立要求：表示当原因a出现时，b也必须出现。a出现时，不可能b不出现。强制：当a是1时，b必须是0；当a是0时，b必须是14.1.5因果图实例讲解某软件规格说明中包含这样的要求：

第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L;如果第二列字符不是数字，则给出信息M。

分开原因和结果

原因：1----第一列字符是A;

2----第一列字符是B;

3----第二列字符是一数字。

结果：21----修改文件;

22----给出信息L;

23----给出信息M。4.1.5因果图实例讲解4.1.5因果图实例讲解有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下： 若投入5角钱或1元钱的硬币，按下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来.若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并按下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。

4.1.5因果图实例讲解(1)分析这一段说明，列出原因和结果

原因:1.售货机有零钱找2.投入1元硬币 3.投入5角硬币 4.按下橙汁按钮 5.按下啤酒按钮 建立中间结点，表示处理中间状态

11.投入1元硬币且按下饮料按钮

12.按下〖橙汁〗或〖啤酒〗的按钮

13.应当找5角零钱并且售货机有零钱找

14.钱已付清

4.1.5因果图实例讲解结果：21.售货机〖零钱找完〗灯亮22.退还1元硬币23.退还5角硬币24.送出橙汁饮料25.送出啤酒饮料

(2)画出因果图。所有原因结点列在左 边，所有结果结点列在右边。(3)由于2与3，4与5不能同时发生， 分别加上约束条件E。

(4)因果图因果图因果图4.1.6侵入测试出于测试的目的，侵入测试需要修改被测试系统及其行为这种修改均不能提交给最终用户谨慎使用4.1.7错误猜测有关被测试系统的知识，如设计方法和实现技术有关的早期测试阶段的结果的知识测试类似或相关系统的经验典型的实现错误的知识（被零除）通用的测试经验规则4.2白盒测试的优缺点优点：迫使测试人员考虑软件的实现可以检测代码中的每条分支和路径解释隐藏在代码中的错误对代码的测试比较彻底最优化4.2白盒测试的优缺点缺点：昂贵有遗漏的路径4.2黑盒测试的优缺点优点：效率高测试人员不需要了解细节测试人员和编程人员