《软件测试技术》PPT课件

软件测试技术,课程特点,用真实应用的案例和技术来讲解如何解决测试中的实际难题 课程的中心思想是如何建立质量保证体系，做到缺陷的预防 用一个大型的真实产品作为案例，讲解从立项计划到发布的每一步是如何实施的 对于同一个测试环节，开发人员、测试人员、测试管理者应该分别关注什么、做哪些工作来最终保证测试质量 不仅讲解要做好测试都需要做什么，更注重讲解怎么做、为什么这样做、如果不这样做会出现什么情况,课程安排,与实践相关的软件测试理论 这一部分只会用很少的一点时间，基础知识略过，仅对实践中最重要的、最容易混淆或最容易出问题的地方强调一下 测试计划 这部分内容将分别从测试执行者和测试管理者的角度出发，讲解如何制定能覆盖到细节的测试计划，以及准备资源的依据，并最终评定每一个测试人员的测试执行情况,课程安排,测试用例设计方法 这部分内容会着重讲解如何进行深度验证和解决白盒测试的难点，以及各种用例设计方法的综合使用,课程安排,测试方法及技巧 这部分内容将对每一种测试方法的重点、难点和实施技巧进行讲解，用一个真实的企业级软件项目作为案例，讲解如何在一个真实项目中逐一实施这些测试方法，其中绝大部分的测试方法都以自动化测试的技术和实现方法来讲解。当所有的测试方法都部署完成，讲解何如把这些独立的测试方法和测试活动整合成自动化测试体系。从而实现缺陷预防的持续改进。,课程安排,测试度量体系的建立这部分内容会在课程中分两个层面讲解。第一个层面是技术方面的，包括与缺陷相关的各种度量数据，软件可靠性分析 、缺陷分析等；第二个层面是管理方面的，包括如何应用数据进行辅助决策、需要积累和建立哪些数据内容、以及根据缺陷状态预估项目进度和质量等级等。,课程安排,自动化测试技术 这部分内容先从自动化测试技术的初级部分入手，介绍最新的自动化测试技术和挑选工具的方法，然后分析自动化测试技术的核心价值,课程安排,缺陷预防的持续改进 这部分内容是核心中的核心，它是建立在前面用例设计、测试计划和各种测试方法的基础上的，可以说前面的内容都是在为这一块打基础,课程安排,测试管理 没有科学的测试管理就不可能建立完备的质量保证体系，这部分内容讲解在实践中如何进行缺陷的度量。软件质量的度量以及测试质量的度量,在课程中要逐一解决的问题,测试人员不足，尤其是有经验的测试工程师不足 团队对Bug的理解不一致，有时测试团队开的Bug开发团队不认可 没有有效的技术手段保证测试速度，甚至测试被认为额外增加了项目进度时间 测试量很大，测试报告不能及时反映最新版本中存在的问题 测试中重复劳动太多，长期下来，测试工程师缺乏成就感和创造力 软件发布前是否经历了足够的测试？能否发布到底谁说了算？ 缺陷预防的持续改进 建立质量保证体系,第一章 软件测试基础理论,什么是软件测试,软件测试的引出 软件测试的定义 软件测试的存在阶段,软件测试的引出,什么是有效代码？怎么知道写出的代码是不是有效的？ 测试仅仅是一种技术吗？ 测试仅仅是一种活动吗？ 测试是在开发进度的基础上额外投入一块时间吗？ 测试是要建立起一套质量保证体系，使得项目按照既定的方向和标准前进,软件测试的定义,为了保证软件的质量和可靠性，应力求在分析，设计等各个阶段结束前，对软件进行严格的评审。也就是说软件测试是在软件投入运行前，对软件需求分析，设计规格说明和编码的最终审查，它是软件质量保证的关键步骤。,软件测试的存在阶段,需求阶段的Spec Review 编码阶段的单元测试 编码完成后的各种综合测试 测试可以加速软件开发进度，在实践上必须让测试渗透到每一个阶段、每一个细节,什么是软件缺陷,缺陷的定义：软件缺陷这一概念用来描述各种软件错误，是所有软件错误的统称。 把符合下列5种特征之一的软件错误认为是软件缺陷： （1）软件未达到软件产品需求说明书中指明的要求； （2）软件出现了软件产品需求说明书中指明不会出现的错误； （3）软件功能超出了软件产品需求说明书中指明的范围； （4）软件未达到软件产品需求说明书中虽未指明但应达到的要求； （5）难以理解、不易使用、运行速度缓慢或者最终用户认为不好的问题。,缺陷的分类,缺陷和BUG，它的分类要根据不同的公司不同的产品来确定，但是基本的分类思想是一致的。 Code bug Spec bug Performance Security UI Bug Accessibility,可能发生的风险,以下方面是很容易引入风险的： 软件在发布或交付使用之前没有经历足够的测试 采用产量很少的硬件、芯片，及即将停产的型号 购买刚被兼并的软件公司的产品 不明确的需求 未经充分论证的架构,Myers软件测试目的,1979年，Glenford Myers在The Art of Software Testing一书中提出“测试的目的是证伪”这一概念，推翻了过去“为表明软件正确而进行测试”的错误认识，为软件测试的发展指出了方向，软件测试的理论、方法在之后得到了长足的发展。,软件测试的原则,1. 应当把“尽早地和不间断地进行软件测试”作为测试团队的座右铭。 2. 如何做到尽早测试和不间断测试？ 3. 程序员应避免检查自己的程序。 4. 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。,5. Bug的标准：测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。 6. 严格执行测试计划，排除测试的随意性。 7. 应当对每一个测试结果做全面检查。 8. 让数据说话：通过对测试用例和Bug的追踪统计，看出项目组发生了什么、正在发生什么、甚至将会发生什么。测试团队需要建立Case管理平台和缺陷追踪体系,详细设计规格说明,概要设计规格说明,需求规格说明,怎样理解经典模型,Review,缺陷和Bug的区别 软件测试的意义,第二章 测试计划,如何在需求和设计阶段有效的介入 对需求和设计的频繁变更如何应对 测试文档的核心价值是什么？为什么要写测试计划？,测试文档,Test Spec,INTRODUCTION Objective Statement Related Documents and Links Glossary,Test Spec,SCOPE Goals Non-Goals Dependencies and Partners Risks Assumptions and Limitations Assumptions Limitations,Test Spec,FEATURE OVERVIEW Feature Description Release Criteria Functional Area Breakdown Feature Data Flow Diagram (DFD),Release Creteria,CC：Code Complete Pass Rate：这是RC的核心衡量指标之一，我们的要求是必须保证95的case通过率 Case和Bug的级别：允许存在5不通过的case，但这些case决不能是重要case ZBB：这是Zero Bug Bounce的缩写，意为“零Bug边界” Code Coverage：代码覆盖率,Test Spec,FEATURE VALIDATION For all features Overview Valid Scenario Invalid Scenarios,Test Spec,GENERAL APPROACHES Security Permission Help and documentation International Sufficiency (Globalization/localization) Accessibility Scalability/ Performance Stress Geo/Political/Legal Logging/ Message format Tracing/Counters( Diagnos ability) Testability Test Hooks,Test Spec,SCENARIO BASED TESTS Reliability/LongHaul Memory Usage CPU Usage Time Consumption Integration Interoperability Compatibility,Test Spec,TEST COMPONENT CHECKLIST tool/lib name Feature list,Test Spec,Topology requirements,Test Spec,OPEN ISSUES,Test Spec,SIGN-OFF CHANGE 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 0 1 0 1 0 1 1 1 1 0,1 2 3,1 2 3 4,循环结构分析,循环分为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 Test Black box and White box Security Help and documentation International Sufficiency (Globalization/localization) Accessibility Scalability/ Performance Stress,软件测试的种类,Geo/Political/Legal Logging/ Message format Tracing/Counters( Diagnos ability) Testability Test Hooks SCENARIO BASED TESTS Reliability/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 Test Black box and White box Security Help and documentation International Sufficiency (Globalization/localization) Accessibility Scalability/ Performance Stress,Review,Geo/Political/Legal Logging/ Message format Tracing/Counters( Diagnos ability) Testability Test Hooks SCENARIO BASED TESTS Reliability/LongHaul Integration Interoperability Compatibility UE测试,程序的静态测试,代码会审（Code Review） 代码会审是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。 Code Review的条件是清晰的Guildeline,人工测试 经验表明，使用人工测试能够有效地发现30到70的逻辑设计和编码错误。 桌前检查（Desk Checking） 由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试之前，对源代码进行分析，检验，并补充相关文档，目的是发现程序的错误。,调试（Debug）,软件调试是在进行了成功的测试之后才开始的工作。它与软件测试不同，调试的任务是进一步诊断和改正程序中潜在的错误。 调试活动由两部分组成： 确定程序中可疑错误的确切性质和位置。 对程序(设计,编码)进行修改，排除这个错误。,调试工作是一个具有很强技巧性的工作。 软件运行失效或出现问题，往往只是潜在错误的外部表现，而外部表现与内在原因之间常常没有明显的联系。如果要找出真正的原因，排除潜在的错误，不是一件易事。 可以说，调试是通过现象，找出原因的一个思维分析的过程。,调试的步骤,(1) 从错误的外部表现形式入手，确定程序中出错位置； (2) 研究有关部分的程序，找出错误的内在原因； (3) 修改设计和代码，以排除这个错误； (4) 重复进行暴露了这个错误的原始测试或某些有关测试。,从技术角度来看，查找错误的难度在于： 现象与原因所处的位置可能相距甚远。 当其他错误得到纠正时, 这一错误所表现出的现象可能会暂时消失，但并未实际排除。 现象实际上是由一些非错误原因 (例如，舍入不精确) 引起的。,现象可能是由于一些不容易发现的人为错误引起的。 错误是由于时序问题引起的，与处理过程无关。 现象是由于难于精确再现的输入状态（例如，实时应用中输入顺序不确定）引起。 现象可能是周期出现的。在软、硬件结合的嵌入式系统中常常遇到。,几种主要的调试方法,调试的关键在于推断程序内部的错误位置及原因。可以采用以下方法： 强行排错 这种调试方法目前使用较多，效率较低。它不需要过多的思考，比较省脑筋。例如： 通过内存全部打印来调试，在这大量的数据中寻找出错的位置。,在程序特定部位设置打印语句，把打印语句插在出错的源程序的各个关键变量改变部位、重要分支部位、子程序调用部位，跟踪程序的执行，监视重要变量的变化。 自动调试工具。利用某些程序语言的调试功能或专门的交互式调试工具，分析程序的动态过程，而不必修改程序。,应用以上任一种方法之前，都应当对错误的征兆进行全面彻底的分析，得出对出错位置及错误性质的推测，再使用一种适当的调试方法来检验推测的正确性。 回溯法调试这是在小程序中常用的一种有效的调试方法。一旦发现了错误，人们先分析错误征兆，确定最先发现“症状”的位置。,然后，人工沿程序的控制流程，向回追踪源程序代码，直到找到错误根源或确定错误产生的范围。 例如，程序中发现错误处是某个打印语句。通过输出值可推断程序在这一点上变量的值。再从这一点出发，回溯程序的执行过程，反复考虑：“如果程序在这一点上的状态（变量的值）是这样，那么程序在上一点的状态一定是这样.”， 直到找到错误的位置。,归纳法调试 归纳法是一种从特殊推断一般的系统化思考方法。归纳法调试的基本思想是：从一些线索(错误征兆)着手，通过分析它们之间的关系来找出错误。 收集有关的数据 列出所有已知的测试用例和程序执行结果。看哪些输入数据的运行结果是正确的，哪些输入数据的运行结果有错误。,组织数据 由于归纳法是从特殊到一般的推断过程，所以需要组织整理数据，以发现规律。 常以3W1H形式组织可用的数据： “what” 列出一般现象； “where”说明发现现象的地点； “when” 列出现象发生时所有已知情况； “how” 说明现象的范围和量级； “Yes”描述出现错误的3W1H；,归纳法中组织数据的3W1H表,“No”作为比较，描述了没有错误的3W1H。通过分析找出矛盾来。 提出假设 分析线索之间的关系，利用在线索结构中观察到的矛盾现象，设计一个或多个关于出错原因的假设。如果一个假设也提不出来，归纳过程就需要收集更多的数据。此时，应当再设计与执行一些测试用例，以获得更多的数据。,证明假设 把假设与原始线索或数据进行比较，若它能完全解释一切现象，则假设得到证明；否则，就认为假设不合理，或不完全，或是存在多个错误，以致只能消除部分错误。,演绎法调试 演绎法是一种从一般原理或前提出发，经过排除和精化的过程来推导出结论的思考方法。 演绎法排错是测试人员首先根据已有的测试用例，设想及枚举出所有可能出错的原因做为假设；然后再用原始测试数据或新的测试，从中逐个排除不可能正确的假设；最后，再用测试数据验证余下的假设确是出错的原因。,列举所有可能出错原因的假设把所有可能的错误原因列成表。通过它们，可以组织、分析现有数据。 利用已有的测试数据，排除不正确的假设仔细分析已有的数据，寻找矛盾，力求排除前一步列出所有原因。如果所有原因都被排除了，则需要补充一些数据(测试用例)，以建立新的假设。,改进余下的假设利用已知的线索，进一步改进余下的假设，使之更具体化，以便可以精确地确定出错位置。 证明余下的假设,调试原则,在调试方面，许多原则本质上是心理学方面的问题。调试由两部分组成，调试原则也分成两组。 确定错误的性质和位置的原则 用头脑去分析思考与错误征兆有关的信息。 避开死胡同。,只把调试工具当做辅助手段来使用。利用调试工具，可以帮助思考，但不能代替思考。 避免用试探法，最多只能把它当做最后手段。 修改错误的原则 在出现错误的地方，很可能还有别的错误。,修改错误的一个常见失误是只修改了这个错误的征兆或这个错误的表现，而没有修改错误的本身。 当心修正一个错误的同时有可能会引入新的错误。 修改错误的过程将迫使人们暂时回到程序设计阶段。 修改源代码程序，不要改变目标代码。,Review,Code Review Debug,第六章自动化测试,自动化测试,什么是自动化测试 自动化测试是用来找Bug的吗？ 自动化测试工具 Automation Code 自动化测试用例的编码原则 自动化测试的运行,测试度量体系自动化测试,测试体系的核心是由自动化测试构成的 从找Bug到让Bug自己跳出来 修改一个Bug可能会引入更多的Bug，怎样杜绝这种情况的发生 计算进行缺陷预防的投资回报率 缺陷分析工具,测量缺陷预防活动的有效性,自动化测试,数据驱动的测试 BVT（DOA）和NonBVT Pass Rate Code Coverage Failure Track GUI测试自动化,缺陷预防,效率: 有多少人被卷入一个Bug的处理? 避免 break和DOA break,Pre-Check in 代码,在测试文档里就应该定义哪些用例属于Pre-Check In case 和产品代码同时check in，保证每一块产品代码从Check In的第一天就处于被测状态，这是质量保证体系的关键 保证至少 85% 代码覆盖率,代码覆盖率,DOA/Basic Feature,Code Review流程,No Bug VS. Finding Bugs,自动化测试最大的价值是什么？ Silver Bullet？,第七章 测试管理,测试管理,Bug数是否意味着开发人员的水平？ Bug的分类和优先级 产品Bug和测试Bug 解决Bug的时间要求,测试管理,测试部门的组建 硬件环境准备 测试团队的人数和构成 测试人员的要求 按功能块分工 按测试类型分工,测试度量体系测试管理,测试团队和其他团队的配合，尤其是开发团队 日常测试活动安排 周期性测试活动安排 突发性测试活动安排 测试人员的考评标准 测试纪律,测试管理,统一测试团队和开发团队对Bug的理解和认识 Triage团队的权威性和严肃性 质量文化 目标工作制 限时完成 数据统计和数据挖掘 根据数据预估和控制进度,Bug Trend,测试管理,Bug Bash 不同阶段的奖励与惩罚 目标负责制 不断探索新方法、内部立项开发新工具 筹备内部通用Frame Work 设备是可以买的，但时间是买不来的,测试管理,合理的项目计划，包括开发计划和测试计划 合理的里程碑及里程碑之间的工作计划 长期计划、中期计划、短期计划 对不可预见因素的预判能力 Guideline和CheckList 工作成效的延续和发扬,Review,质量和进度哪个更重要 测试团队最核心的任务是什么？,与其他软件工程方法的结合,测试活动在软件生命周期中不是孤立存在的 与配置管理尤其是版本管理的结合 Daily Build和分支管理 与变更管理的结合 与需求管理的结合,回顾,测试度量体系建立：缺陷度量体系的建立、缺陷度量库的建立 缺陷度量： 理解与缺陷相关的各种度量数据 、使用缺陷度量数据做决策 、软件可靠性分析、缺陷分析工具测试管理 缺陷预防的持续改进： 缺陷数据库 、缺陷估算模型 、制订缺陷目标、应用缺陷预防实践、测量缺陷预防活动的有效性 、 计算进行缺陷预防的投资回报率,Q&A,Thank You!,