《软件测试技术》PPT课件.ppt

软件测试技术,课程特点,用真实应用的案例和技术来讲解如何解决测试中的实际难题课程的中心思想是如何建立质量保证体系，做到缺陷的预防用一个大型的真实产品作为案例，讲解从立项计划到发布的每一步是如何实施的对于同一个测试环节，开发人员、测试人员、测试管理者应该分别关注什么、做哪些工作来最终保证测试质量不仅讲解要做好测试都需要做什么，更注重讲解怎么做、为什么这样做、如果不这样做会出现什么情况,课程安排,与实践相关的软件测试理论这一部分只会用很少的一点时间，基础知识略过，仅对实践中最重要的、最容易混淆或最容易出问题的地方强调一下测试计划这部分内容将分别从测试执行者和测试管理者的角度出发，讲解如何制定能覆盖到细节的测试计划，以及准备资源的依据，并最终评定每一个测试人员的测试执行情况,课程安排,测试用例设计方法这部分内容会着重讲解如何进行深度验证和解决白盒测试的难点，以及各种用例设计方法的综合使用,课程安排,测试方法及技巧这部分内容将对每一种测试方法的重点、难点和实施技巧进行讲解，用一个真实的企业级软件项目作为案例，讲解如何在一个真实项目中逐一实施这些测试方法，其中绝大部分的测试方法都以自动化测试的技术和实现方法来讲解。当所有的测试方法都部署完成，讲解何如把这些独立的测试方法和测试活动整合成自动化测试体系。从而实现缺陷预防的持续改进。,课程安排,测试度量体系的建立这部分内容会在课程中分两个层面讲解。第一个层面是技术方面的，包括与缺陷相关的各种度量数据，软件可靠性分析、缺陷分析等；第二个层面是管理方面的，包括如何应用数据进行辅助决策、需要积累和建立哪些数据内容、以及根据缺陷状态预估项目进度和质量等级等。,课程安排,自动化测试技术 这部分内容先从自动化测试技术的初级部分入手，介绍最新的自动化测试技术和挑选工具的方法，然后分析自动化测试技术的核心价值,课程安排,缺陷预防的持续改进这部分内容是核心中的核心，它是建立在前面用例设计、测试计划和各种测试方法的基础上的，可以说前面的内容都是在为这一块打基础,课程安排,测试管理没有科学的测试管理就不可能建立完备的质量保证体系，这部分内容讲解在实践中如何进行缺陷的度量。软件质量的度量以及测试质量的度量,在课程中要逐一解决的问题,测试人员不足，尤其是有经验的测试工程师不足团队对Bug的理解不一致，有时测试团队开的Bug开发团队不认可没有有效的技术手段保证测试速度，甚至测试被认为额外增加了项目进度时间测试量很大，测试报告不能及时反映最新版本中存在的问题测试中重复劳动太多，长期下来，测试工程师缺乏成就感和创造力软件发布前是否经历了足够的测试？能否发布到底谁说了算？缺陷预防的持续改进建立质量保证体系,第一章 软件测试基础理论,什么是软件测试,软件测试的引出软件测试的定义软件测试的存在阶段,软件测试的引出,什么是有效代码？怎么知道写出的代码是不是有效的？测试仅仅是一种技术吗？测试仅仅是一种活动吗？测试是在开发进度的基础上额外投入一块时间吗？测试是要建立起一套质量保证体系，使得项目按照既定的方向和标准前进,软件测试的定义,为了保证软件的质量和可靠性，应力求在分析，设计等各个阶段结束前，对软件进行严格的评审。也就是说软件测试是在软件投入运行前，对软件需求分析，设计规格说明和编码的最终审查，它是软件质量保证的关键步骤。,软件测试的存在阶段,需求阶段的Spec Review编码阶段的单元测试编码完成后的各种综合测试测试可以加速软件开发进度，在实践上必须让测试渗透到每一个阶段、每一个细节,什么是软件缺陷,缺陷的定义：软件缺陷这一概念用来描述各种软件错误，是所有软件错误的统称。把符合下列5种特征之一的软件错误认为是软件缺陷：（1）软件未达到软件产品需求说明书中指明的要求；（2）软件出现了软件产品需求说明书中指明不会出现的错误；（3）软件功能超出了软件产品需求说明书中指明的范围；（4）软件未达到软件产品需求说明书中虽未指明但应达到的要求；（5）难以理解、不易使用、运行速度缓慢或者最终用户认为不好的问题。,缺陷的分类,缺陷和BUG，它的分类要根据不同的公司不同的产品来确定，但是基本的分类思想是一致的。Code bugSpec bugPerformanceSecurityUI BugAccessibility,可能发生的风险,以下方面是很容易引入风险的：软件在发布或交付使用之前没有经历足够的测试采用产量很少的硬件、芯片，及即将停产的型号购买刚被兼并的软件公司的产品不明确的需求未经充分论证的架构,Myers软件测试目的,1979年，Glenford Myers在The Art of Software Testing一书中提出“测试的目的是证伪”这一概念，推翻了过去“为表明软件正确而进行测试”的错误认识，为软件测试的发展指出了方向，软件测试的理论、方法在之后得到了长足的发展。,软件测试的原则,1.应当把“尽早地和不间断地进行软件测试”作为测试团队的座右铭。2.如何做到尽早测试和不间断测试？3.程序员应避免检查自己的程序。4.在设计测试用例时，应包括合理的输入条件和不合理的输入条件。,5.Bug的标准：测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。6.严格执行测试计划，排除测试的随意性。7.应当对每一个测试结果做全面检查。8.让数据说话：通过对测试用例和Bug的追踪统计，看出项目组发生了什么、正在发生什么、甚至将会发生什么。测试团队需要建立Case管理平台和缺陷追踪体系,详细设计规格说明,概要设计规格说明,需求规格说明,怎样理解经典模型,Review,缺陷和Bug的区别软件测试的意义,第二章 测试计划,如何在需求和设计阶段有效的介入对需求和设计的频繁变更如何应对测试文档的核心价值是什么？为什么要写测试计划？,测试文档,Test Spec,INTRODUCTIONObjective StatementRelated Documents and LinksGlossary,Test Spec,SCOPEGoalsNon-GoalsDependencies and PartnersRisksAssumptions and LimitationsAssumptionsLimitations,Test Spec,FEATURE OVERVIEWFeature DescriptionRelease CriteriaFunctional Area BreakdownFeature Data Flow Diagram(DFD),Release Creteria,CC：Code CompletePass Rate：这是RC的核心衡量指标之一，我们的要求是必须保证95的case通过率Case和Bug的级别：允许存在5不通过的case，但这些case决不能是重要caseZBB：这是Zero Bug Bounce的缩写，意为“零Bug边界”Code Coverage：代码覆盖率,Test Spec,FEATURE VALIDATIONFor all featuresOverviewValid ScenarioInvalid Scenarios,Test Spec,GENERAL APPROACHESSecurityPermissionHelp and documentationInternational Sufficiency(Globalization/localization)AccessibilityScalability/PerformanceStressGeo/Political/LegalLogging/Message format Tracing/Counters(Diagnos ability)TestabilityTest Hooks,Test Spec,SCENARIO BASED TESTSReliability/LongHaulMemory UsageCPU UsageTime ConsumptionIntegrationInteroperabilityCompatibility,Test Spec,TEST COMPONENT CHECKLISTtool/lib nameFeature list,Test Spec,Topology requirements,Test Spec,OPEN ISSUES,Test Spec,SIGN-OFFCHANGE HISTORY,Review,一篇好的测试文档应当包含哪些内容、注意哪些方面,第三章 测试用例设计,测试用例设计,黑盒测试等价类划分边界值分析错误推测法因果图,白盒测试逻辑覆盖判定结构分析循环结构分析基本路径覆盖,黑盒测试,这种方法是把测试对象看做一个黑盒，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求和功能规格说明，检查程序的功能是否符合它的功能说明。黑盒测试叫做功能测试或数据驱动测试。一种特殊的黑盒测试叫做接口测试，它不管程序的需求和实现细节，仅依据程序与其外部环境的接口来选择测试数据。,黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误:是否有不正确或遗漏了的功能？在接口上，输入能否正确地接受？能否输出正确的结果？是否有数据结构错误或外部信息(例如数据文件)访问错误？性能上是否能够满足要求？是否有初始化或终止性错误？,用黑盒测试发现程序错误，必须在所有可能的输入条件和输出条件中确定测试数据，检查程序能否产生正确的输出。但这是不可能的。例如，设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：可能采用的测试数据组个数：232232264 如果测试一组数据需要1毫秒,一年工作36524小时，完成所有测试需5亿年。,白盒测试,此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。,软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：对程序模块的所有独立的执行路径至少测试一次 路径覆盖测试；对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次 逻辑覆盖测试；在循环的边界和运行界限内执行循环体 控制流测试；测试内部数据结构的有效性 数据流测试、领域测试等。,对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字。给出一个小程序的流程图，它包括了一个执行20次的循环。包含的不同执行路径数达 520 条，对每一条路径进行测试需要1毫秒，假定一年工作36524小时，要想把所有路径测试完，需3170年。,灰盒测试,灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。,灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。,逻辑覆盖,语句覆盖 判定覆盖 条件覆盖 判定条件覆盖 条件组合覆盖 路径覆盖,逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。,(A1)and(B=0),(A=2)or(X1),X=X/A,X=X+1,T,T,F,F,a,b,d,c,e,L1(a c e)=(A 1)and(B=0)and(A=2)or(X/A 1)=(A 1)and(B=0)and(A=2)or(A 1)and(B=0)and(X/A 1)=(A=2)and(B=0)or(A 1)and(B=0)and(X/A 1),L2(a b d)=not(A 1)and(B=0)and not(A=2)or(X 1)=not(A 1)or not(B=0)and not(A=2)and not(X1)=not(A 1)and not(A=2)and not(X 1)or not(B=0)and not(A=2)and not(X 1),L3(a b e)=not(A 1)and(B=0)and(A=2)or(X 1)=not(A 1)or not(B=0)and(A=2)or(X 1)=not(A 1)and(A=2)or not(A 1)and(X 1)or not(B=0)and(A=2)or not(B=0)and(X 1),L4(a c d)=(A 1)and(B=0)and not(A=2)or(X/A 1)=(A 1)and(B=0)and not(A=2)and not(X/A 1),语句覆盖,语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。在图例中，正好所有的可执行语句都在路径L1上，所以选择路径 L1设计测试用例，就可以覆盖所有的可执行语句。,测试用例的设计格式如下【输入的(A,B,X)，输出的(A,B,X)】为图例设计满足语句覆盖的测试用例是:【(2,0,4)，(2,0,3)】覆盖 ace【L1】,(A=2)and(B=0)or(A1)and(B=0)and(X/A1),判定覆盖,判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖。对于图例，如果选择路径L1和L2，就可得满足要求的测试用例:,【(2,0,4)，(2,0,3)】覆盖 ace【L1】【(1,1,1)，(1,1,1)】覆盖 abd【L2】,(A=2)and(B=0)or(A 1)and(B=0)and(X/A 1),not(A 1)and not(A=2)and not(X 1)or not(B=0)and not(A=2)and not(X 1),如果选择路径L3和L4，还可得另一组可用的测试用例:【(2,1,1)，(2,1,2)】覆盖 abe【L3】【(3,0,3)，(3,0,1)】覆盖 acd【L4】,not(A 1)and(X 1)or not(B=0)and(A=2)or not(B=0)and(X 1),(A 1)and(B=0)and not(A=2)and not(X/A 1),条件覆盖,条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。在图例中，我们事先可对所有条件的取值加以标记。例如，对于第一个判断：条件 A1 取真为，取假为 条件 B0 取真为，取假为,对于第二个判断：条件A2 取真为，取假为 条件X1 取真为，取假为 测试用例 覆盖分支 条件取值【(2,0,4)，(2,0,3)】L1(c,e)【(1,0,1)，(1,0,1)】L2(b,d)【(2,1,1)，(2,1,2)】L3(b,e)或,测 试 用 例覆盖分支 条件取值【(1,0,3)，(1,0,4)】L3(b,e)【(2,1,1)，(2,1,2)】L3(b,e)判定条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，每个判断中的每个分支至少执行一次。,判定条件覆盖,测 试 用 例覆盖分支 条件取值【(2,0,4)，(2,0,3)】L1(c,e)【(1,1,1)，(1,1,1)】L2(b,d),(A=2)and(B=0)or(A 1)and(B=0)and(X/A 1),not(A 1)and not(A=2)and not(X 1)or not(B=0)and not(A=2)and not(X 1),and,or,A1,T,B=0,T,X=X/A,T,F,F,A=2,T,F,X1,F,X=X+1,条件组合覆盖,条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。记 A1,B0 作 A1,B0 作 A1,B0 作 A1,B0 作,A2,X1 作 A2,X1 作 A2,X1 作 A2,X1 作 测 试 用 例 覆盖条件 覆盖组合【(2,0,4),(2,0,3)】(L1),【(2,1,1),(2,1,2)】(L3),【(1,0,3),(1,0,4)】(L3),【(1,1,1),(1,1,1)】(L2),路径测试,路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径。测 试 用 例 通过路径 覆盖条件【(2,0,4),(2,0,3)】ace(L1)【(1,1,1),(1,1,1)】abd(L2)【(1,1,2),(1,1,3)】abe(L3)【(3,0,3),(3,0,1)】acd(L4),判定结构分析,当程序中判定多于一个时，形成的分支结构可以分为两类：嵌套型分支结构和连锁型分支结构。对于嵌套型分支结构，若有n个判定语句，需要n+1个测试用例；对于连锁型分支结构，若有n个判定语句，需要有2n个测试用例，覆盖它的2n条路径。,嵌套型分支结构,连锁型分支结构,对于连锁型分支结构，当 n 较大时将无法测试。为减少测试用例的数目，可采用试验设计法，抽取部分路径进行测试。,这样，测试路径数目从238条减少到314条。,L4,0 0 01 0 10 1 11 1 0,1 2 3,1234,循环结构分析,循环分为4种不同类型：简单循环、连锁循环、嵌套循环和非结构循环。(1)简单循环 零次循环：从循环入口到出口 一次循环：检查循环初始值 二次循环：检查多次循环 m次循环：检查在多次循环 最大次数循环、比最大次数多一次、少一次的循环。,基本路径测试,基本路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，设计测试用例的方法。设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。,程序的控制流图,符号为控制流图的一个结点，表示一个或多个无分支的PDL语句或源程序语句。箭头为边，表示控制流的方向。,在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。如果判断中的条件表达式是由一个或多个逻辑运算符(OR,AND,.)连接的复合条件表达式，则需改为 一系列只有单个条件的嵌套的判断。,等价类划分,等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。,使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。(1)划分等价类等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其他值的测试。,等价类的划分有两种不同的情况：有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。,划分等价类等价类的原则。1)如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。例如，在程序的规格说明中，对输入条件有一句话：“项数可以从1到999”则有效等价类是“1项数999”两个无效等价类是“项数1”或“项数999”。,在数轴上表示成:,2)如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。例如，在Pascal语言中对变量标识符规定为“以字母打头的串”。那么所有以字母打头的构成有效等价类，而不在此集合内（不以字母打头）的归于无效等价类。,3)如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。4)如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。这时可为 每一个输入值确立一个有效等价类，此外针对这组值确立一个无效等价类，它是所有不允许的输入值的集合。,例如，在教师上岗方案中规定对教授、副教授、讲师和助教分别计算分数，做相应的处理。因此可以确定4个有效等价类为教授、副教授、讲师和助教，一个无效等价类，它是所有不符合以上身分的人员的输入值的集合。5)如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。,例如，Pascal语言规定“一个语句必须以分号;结束”。这时可以确定一个有效等价类“以;结束”，若干个无效等价类“以:结束”、“以,结束”、“以 结束”、“以LF结束”等。(2)确立测试用例在确立了等价类之后，建立等价类表，列出所有划分出的等价类。,再从划分出的等价类中按以下原则选择测试用例：1)为每一个等价类规定一个唯一编号；2)设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；3)设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。,用等价类划分法设计测试用例的实例 在某一PASCAL语言版本中规定：“标识符是由字母开头，后跟字母或数字的任意组合构成。有效字符数为8个，最大字符数为80个。”并且规定：“标识符必须先说明，再使用。”“在同一说明语句中，标识符至少必须有一个。”,用等价类划分方法，建立输入等价类表:,下面选取了 9 个测试用例，它们覆盖了所有的等价类。VAR x，T1234567：REAL；BEGIN x:=3.414；T1234567:=2.732；.(1),(2),(4),(8),(9),(12),(14)VAR：REAL；(3)VAR x，：REAL;(5),VAR T12345678：REAL；(6)VAR T12345.：REAL；(7)多于80个字符 VAR T$：CHAR；(10)VAR GOTO：INTEGER；(11)VAR 2T：REAL；(13)VAR PAR：REAL；(15)BEGIN.PAP:=SIN(3.14*0.8)/6；,边界值分析,边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。,比如，在做三角形计算时，要输入三角形的三个边长：A、B和C。我们应注意到这三个数值应当满足 A0、B0、C0、ABC、ACB、BCA，才能构成三角形。但如果把六个不等式中的任何一个大于号“”错写成大于等于号“”，那就不能构成三角形。问题恰出现在容易被疏忽的边界附近。,这里所说的边界是指，相当于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。使用边界值分析方法设计测试用例，首先应确定边界情况。应当选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。,错误推测法,人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。,因果图,因果图的适用范围 如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。用因果图生成测试用例的基本步骤,1)分析软件规格说明描述中，哪些是原因(即输入条件或输入条件的等价类)，哪些是结果(即输出条件)，并给每个原因和结果赋予一个标识符。2)分析软件规格说明描述的语义，找出原因与结果之间，原因与原因之间对应的关系?根据这些关系，画出因果图。3)由于语法或环境限制,有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。,4)把因果图转换成判定表。5)把判定表的每一列拿出来作为依据，设计测试用例。在因果图中出现的基本符号 通常在因果图中用Ci表示原因，用Ei表示结果，各结点表示状态，可取值“0”或“1”。“0”表示某状态不出现，“1”表示某状态出现。,主要的原因和结果之间的关系有:,表示约束条件的符号为了表示原因与原因之间，结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束条件的符号。,例如，有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，押下橙汁或啤酒的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示零钱找完的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示零钱找完的红灯灭，在送出饮料的同时退还5角硬币。”,1)分析这一段说明，列出原因和结果原因:1.售货机有零钱找 2.投入1元硬币 3.投入5角硬币 4.押下橙汁按钮 5.押下啤酒按钮建立中间结点，表示处理中间状态11.投入1元硬币且押下饮料按钮12.押下橙汁或啤酒的按钮13.应当找5角零钱并且售货机有零钱找14.钱已付清,结果：21.售货机零钱找完灯亮 22.退还1元硬币 23.退还5角硬币 24.送出橙汁饮料 25.送出啤酒饮料 2)画出因果图。所有原因结点列在左边，所有结果结点列在右边。3)由于 2 与 3，4 与 5 不能同时发生，分别加上约束条件E。4)因果图 5)转换成判定表,使用各种设计方法的综合策略,测试素材的复用在任何情况下都必须使用边界值分析法。用这种方法设计出测试用例发现程序错误的能力最强。必要时用等价类划分法补充一些测试用例。用错误推测法再追加一些测试用例。不要因为实现的困难程度而影响设计用例Generic Test自动生成测试用例,Review,编写测试Property Page的Test Case,第四章 测试度量体系的建立,一个完备的测试度量体系的构成要素：缺陷库的建立用例库的建立测试结果库的建立自动化测试体系高效的工作流程数据统计和数据挖掘缺陷追踪体系科学的测试管理,测试度量体系构成,用例库的建立不能把用例库只建成一个详细的记录平台，它是自动化测试体系的支撑平台用例库的具体实现缺陷库的建立同样地，缺陷库也不只是记录Bug的数据库，建设时要考虑缺陷追踪和为管理提供支撑缺陷库的具体实现测试结果库的建立用例库、缺陷库和结果库是数据辅助决策的支撑平台,测试度量体系平台建设,测试度量体系（一）,Bug和Case的关联Known Failure与New Failure,缺陷的生命期,（1）Open态-pending态-resolve态/open态（2）Open态-Close态（3）Open态-delay态,测试度量体系流程,Review,从开一个Bug到关闭一个Bug经历的阶段、处理的方法、判断的依据,第五章 测试方法及技巧,从两个小故事想到的,香皂盒测试太空用笔Work Around和彻底解决问题,软件测试的种类,Functionality TestBlack box and White boxSecurityHelp and documentationInternational Sufficiency(Globalization/localization)AccessibilityScalability/PerformanceStress,软件测试的种类,Geo/Political/LegalLogging/Message format Tracing/Counters(Diagnos ability)TestabilityTest HooksSCENARIO BASED TESTSReliability/LongHaul Integration Interoperability Compatibility UE测试,功能测试功能测试是在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严重错误。,可靠性测试,也叫稳定性测试在正常负载下的测试，记录资源占用曲线 结合负载测试进行,可靠性测试如果系统需求说明书中有对可靠性的要求，则需进行可靠性测试。平均失效间隔时间 MTBF(Mean Time Between Failures)是否超过规定时限?因故障而停机的时间 MTTR(Mean Time To Repairs)在一年中应不超过多少时间。,强度测试强度测试也叫压力测试，是要检查在系统运行环境不正常乃至发生故障的情况下，系统可以运行到何种程度的测试。例如：把输入数据速率提高一个数量级，确定输入功能将如何响应。设计需要占用最大存储量或其他资源的测试用例进行测试。设计出在虚拟存储管理机制中引起“颠簸”的测试用例进行测试。,压力测试和性能测试的区别压力测试的难点一般情况下需要借助工具进行（Load Runner，UI Spider）,设计出会对磁盘常驻内存的数据过度访问的测试用例进行测试。强度测试的一个变种就是敏感性测试。在程序有效数据界限内一个小范围内的一组数据可能引起极端的或不平稳的错误处理出现，或者导致极度的性能下降的情况发生。此测试用以发现可能引起这种不稳定性或不正常处理的某些数据组合。,性能测试性能测试是要检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统。性能测试常需要与强度测试结合起来进行，并常要求同时进行硬件和软件检测。通常，对软件性能的检测表现在以下几个方面：响应时间、吞吐量、辅助存储区，例如缓冲区，工作区的大小等、处理精度，等等。,检验系统的能力最高能达到什么程度。例如，对于编译程序，让它处理特别长的源程序；对于操作系统，让其作业队列“满员”；对于信息检索系统，让它使用频率达到最大。在使系统的全部资源达到“满负荷”的情形下，测试系统的承受能力。,需要定义详尽的界定值（Benchmark）一般情况下需要借助工具进行性能测试性能测试的原则和难点,安全性测试安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。力图破坏系统的保护机构以进入系统的主要方法有以下几种：正面攻击或从侧面、背面攻击系统中易受损坏的那些部分；以系统输入为突破口，利用输入的容错性进行正面攻击；,申请和占用过多的资源压垮系统，以破坏安全措施，从而进入系统；故意使系统出错，利用系统恢复的过程，窃取用户口令及其他有用的信息；通过浏览残留在计算机各种资源中的垃圾（无用信息），以获取如口令，安全码，译码关键字等信息；浏览全局数据，期望从中找到进入系统的关键字；浏览那些逻辑上不存在，但物理上还存在的各种记录和资料等。,安全性测试,安全测测试本质上也是功能测试的一种对于非桌面型应用、CS/BS应用、电信/金融/企业级的应用尤为重要安全性测试的前提条件是清晰详尽的权限定义,可使用性测试可使用性测试主要从使用的合理性和方便性等角度对软件系统进行检查，发现人为因素或使用上的问题。要保证在足够详细的程度下，用户界面便于使用；对输入量可容错、响应时间和响应方式合理可行、输出信息有意义、正确并前后一致；出错信息能够引导用户去解决问题；软件文档全面、正规、确切。,这个测试更多的是针对设计，发bug时design change类型多于code bug无效页、步骤等UI界面不能完成，需要用命令行或脚本用户干预困难,安装测试安装测试的目的不是找软件错误，而是找安装错误。在安装软件系统时，会有多种选择。要分配和装入文件与程序库 布置适用的硬件配置 进行程序的联结。而安装测试就是要找出在这些安装过程中出现的错误。,安装测试是在系统安装之时进行测试。它要检验：用户选择的一套任选方案是否相容；安装失败的测试 系统的每一部分是否都齐全；所有文件是否都已产生并确有所需要的内容；硬件的配置是否合理，等等。,文档测试这种测试是检查用户文档(如用户手册)的清晰性和精确性。用户文档中所使用的例子必须在测试中一一试过，确保叙述正确无误。随产品发布Help文档随机手册内部文档,Globalization/localization,语言的兼容性文化考虑，如日期格式等不推荐使用硬编码（Hard Code）这个测试方法对定制开发同样有效,灵活性/可扩展性测试,可扩展性是衡量软件品质的重要指标之一，扩展性好的软件不仅有助于保护客户投资，同时可以提高用户对产品的忠诚度容量扩展功能扩展,Geo/Political/Legal,非技术性测试专业顾问、专家支持用户图标官司,可诊断性测试,Logging/Message format Tracing/Counters(Diagnos ability),可测性测试,Testability这是对软件设计的一项要求，继承层次、接口行为、函数调用等,测试探针,Test Hooks代码注射，事件捕捉等，对测试人员要求较高,场景测试,是集成测试的浓缩版，覆盖产品最关键的用况自动化测试小组协同测试,集成测试,大规模集成测试涉及到软件、硬件、拓扑、复杂场景等测试成本较高需要良好的协调组织模拟真网，尽可能模拟真实用户环境,兼容性测试,经验表明，越符合计算机界通用标准的产品，生命周期越长与标准的兼容性与其他产品的兼容性兼容性指标直接影响市场效益,交互性测试,与兼容性测试的区别，现代软件测试将交互性测试从兼容性测试中分离出来Word,测试和测试,在软件交付使用后，用户将如何实际使用程序，对于开发者来说是无法预测的。测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。测试的目的是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持）。尤其注重产品的界面和特色。,UE测试,Error Message界面风格描述性语言的表达风格一致性,Review,Functionality TestBlack box and White boxSecurityHelp and documentationInternational Sufficiency(Globalization/localization)AccessibilityScalability/PerformanceStress,Review,Geo/Political/LegalLogging/Message format Tracing/Counters(Diagnos ability)TestabilityTest HooksSCENARIO BASED TESTSReliability/LongHaul Integration Interoperability Compatibility UE测试,程序的静态测试,代码会审（Code Review）代码会审是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。Code Review的条件是清晰的Guildeline,人工测试 经验表明，使用人工测试能够有效地发现30到70的逻辑设计和编码错误。桌前检查（Desk Checking）由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试之前，对源代码进行分析，检验，并补充相关文档，目的是发现程序的错误。,调试（Debug）,软件调试是在进行了成功的测试之后才开始的工作。它与软件测试不同，调试的任务是进一步诊断和改正程序中潜在的错误。调试活动由两部分组成：确定程序中可疑错误的确切性质和位置。对程序(设计,编码)进行修改，排除这个错误。,调试工作是一个具有很强技巧性的工作。软件运行失效或出现问题，往往只是潜在错误的外部表现，而外部表现与内在原因