Ch14-测试用例设计-STMT.ppt

软件测试方法和技术 - ch.14 测试用例的设计,zhu.kerry,kerry zhu,第14章 软件测试用例的设计,zhu.kerry,14.1 测试用例概述 14.2 白盒测试用例设计方法 14.3 黑盒测试用例设计方法 14.4 测试用例的组织和跟踪,测试用例概述,如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。 测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。,zhu.kerry,什么是测试用例,测试用例可以独立进行测试执行的最小单元 测试内容的一系列情景和每个情景中必须依靠输入和输出，而对软件的正确性进行判断的测试文档，称为测试用例。 测试用例就是将软件测试的行为活动，做一个科学化的组织归纳。 软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例,zhu.kerry,为什么需要测试用例,在开始实施测试之前设计好测试用例，避免盲目测试并提高测试效率，减少测试的不完全性； 测试用例的使用令软件测试的实施重点突出、目的明确； 根据测试用例的多少和执行难度，估算测试工作量，便于测试项目的时间和资源管理与跟踪； 减少回归测试的复杂程度，在软件版本更新后只需修正少量的测试用例便可展开测试工作，降低工作强度、缩短项目周期；,zhu.kerry,为什么需要测试用例（2）,功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断细化其效率也不断攀升； 根据测试用例的操作步骤和执行结果，为分析软件缺陷和程序模块质量提供依据；可以方便地书写软件测试缺陷报告； 可以根据测试用例的执行等级，实施不同级别的测试； 便于大型软件测试项目外包测试指导基础；,zhu.kerry,良好测试用例的特征,可以最大程度地找出软件隐藏的缺陷 可以最高效率的找出软件缺陷 可以最大程度地满足测试覆盖要求 既不过分复杂、也不能过分简单 使软件缺陷的表现可以清楚的判定 测试用例包含期望的正确的结果 待查的输出结果或文件必须尽量简单明了 不包含重复的测试用例 测试用例内容清晰、格式一致、分类组织,zhu.kerry,测试用例的组成元素与范例,测试用例编号id 测试用例标题 测试的模块,测试输入条件 期望的输出结果 其它说明,zhu.kerry,白盒测试用例设计方法,白盒测试用例的设计方法 逻辑覆盖：以程序的内部逻辑结构为基础，分为语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖等 基本路径测试：在程序控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。,zhu.kerry,白盒测试用例注意事项 由于测试路径可能非常多，由于时间和资源问题，选出足够多的路径测试 由于深入到程序编码，通常开发人员协助测试人员书写白盒测试用例,基本路径测试,goal: exercise each independent path at least once.,using the code, draw a corresponding flow graph (first drawing the activity diagram for the code may help, but is not required) determine the cyclomatic complexity of the flow graph. determine a basis set of linearly independent paths. prepare test cases that force the execution of each path in the basis set.,zhu.kerry,example,procedure: process records 1. do while records remain 2. read record; 3. if record field 1 = 0 then 4. store in buffer; 5. increment counter; 6. else if record field 2 = 0 then 7. reset counter; 8. else store in file; 9. end if 10. end if 11. end do end,example (continued),1,9,10,11,2,4,5,7,8,3,6,v(g) = 4,基本路径测试:流程图,1,2,3,4,5,10,11,zhu.kerry,流程图复杂度确定,v(g) =number of regions (areas bounded by nodes and edgesarea outside the graph is also a region) v(g) = number of edges - the number of nodes + 2 v(g) = number of (simple) predicate nodes + 1,cyclomatic complexity: a quantitative measure of the logical complexity of code, provides an upper bound on the number of paths that need to be tested in the code,zhu.kerry,流程图复杂度例子,v(g)=4,region 4,zhu.kerry,确定线性独立的路径集合,independent path any path that introduces at least one new set of processing statements or a new condition basis set set of independent paths through the code test cases derived from a basis set are guaranteed to execute every statement at least one time during testing basis set is not unique,zhu.kerry,path1: 1-2-3-6-7-9-10-1-11,basis path test example,path2: 1-2-3-6-8-9-10-1-11,path3: 1-2-3-4-5-10-1-11,path4: 1-11,zhu.kerry,测试用例覆盖集合中每条路径,basis path testing does not test all possible combinations of all paths through the code; it just tests every path at least once.,you do not need an activity diagram, but the picture will help when you trace component paths count each logical testcompound tests count as the number of boolean operators + 1 (i.e., count each simple predicate) basis path testing should be applied to all components, if possible, and to critical components always,zhu.kerry,条件测试,goal: further exercises the true and false value of each simple logical condition in a component.,logical conditions simple condition: (a rel-op b) where rel-op= (may be negated with not), e.g., ab; not(ab) compound condition: two or more simple conditions connected with and, or, e.g., (ab) and (c(a+b+c) errors to test for include (incorrect/missing/extra): boolean operator relational operator boolean variable arithmetic expression boolean parenthesis,zhu.kerry,条件测试 (2),domain testing for an expression e1 rel-op e2, test for e1 = e2 guarantees detection of rel-op error if e1 and e2 are correct to detect errors in e1 / e2, the difference between e1 and e2 for the tests e1 than e2 should be as small as possible for an expression with n variables, 2n tests are required,branch testing for a compound condition c, test true and false branches of c and every simple condition of c e.g., for c = (ab) and (cd) test:,zhu.kerry,条件测试 - example,but ( i = result = 0 ) : maxint n in result=maxint -1 1 true false 1 0 false true gives condition coverage for all conditions,but it does not preserve decision coverage always take care that condition coverage preserves decision coverage : decision / condition coverage,zhu.kerry,分支测试,branch coverage execute the enough test cases，attempting to cover all the paths in the software: - get both “true” and “false” - go through each branch。 for example if b then s1 else s2 case x of 1 : . 2 : . 3 : .,zhu.kerry,分支测试 - example,1 program som ( maxint, n : int ) 2 int result := 0 ; i := 0 ; 3 if n 0 4 then n := - n ; 5 while ( i n ) and ( result = maxint ) 6 do i := i + 1 ; 7 result := result + i ; 8 od; 9 if result = maxint 10 then output ( result ) 11 else output ( “too large” ) 12 end.,zhu.kerry,分支测试 - continued,tests for complete statement coverage: maxint n 10 -1 0 -1 is not sufficient for branch coverage;,take: maxint n 10 3 0 -1 for complete branch coverage,zhu.kerry,(n=0),result=0 i=0,goal: execute loops at their boundaries and within their bounds.,循环测试 1,1.simple loops (n iterations) skip the loop entirely only one pass through the loop two passes through the loop m passes through the loop where m n n-1, n, n+1 passes through the loop,zhu.kerry,循环测试 2,2. nested loops beizerbei90 conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration work outward, conducting tests for the next innermost loop continue until all the loops have been tested,tests grow geometrically as the level of nesting increases,zhu.kerry,循环测试 3,unstructured loops redesign!,3. concatenated loops independent loops simple loop testing dependent loops nested loop testing,zhu.kerry,等价类测试用例设计方法,黑盒测试用例的设计方法之一 等价类划分： 在分析需求规格说明的基础上划分等价类，列出等价类表。 将程序可能的输入数据分成若干个子集，从每个子集选取一个代表性的数据作为测试用例，等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的。 等价类的分类：有效等价类和无效等价类。有效等价类是有意义的、合理的输入数据，可以检查程序是否实现了规格说明中所规定的功能和性能。无效等价类与有效等价类的意义相反。,zhu.kerry,设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。经过正反的测试才能确保软件具有更高的可靠性。,确定等价类的方法,在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。,zhu.kerry,value,在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类,确定等价类的方法（2）,zhu.kerry,not member of set,member of set,boolean,non-boolean,确定等价类的方式 (3),在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。,zhu.kerry,个人月收入- x 税率 x 101600 45%,等价类测试用例-example,等价类1: integer 等价类2: decimal fraction 等价类3: negative 等价类4: invalid input,zhu.kerry,根据等价类创建测试用例的步骤,建立等价类表，列出所有划分出的等价类：,为每个等价类规定一个唯一的编号； 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖； 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。,zhu.kerry,边界值测试用例设计方法,程序的很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以发现不少程序缺陷。 设计方法： 确定边界情况（输入或输出等价类的边界） 选取正好等于、刚刚大于或刚刚小于边界值作为测试数据,zhu.kerry,确定边界值的方法,如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。,zhu.kerry,确定边界值的方法（2）,如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。,zhu.kerry,test cases for abs(x) : class x = 0, arbitrary value x = 100 classes x = 0, on boundary : x = 0 classes x = 0, below and above: x = -1, x = 1,test cases : class arbitrary value: x1 = 123123 class boundary value: x2 = 12345 class boundary value: x3 = 1234567 class boundary value: x4 = 1 class boundary value: x5 = 0 class invalid value: x6 = -123123 class invalid value: x7 = asdasd others?,bva example 2,test a function which limit user input to 6-digit positive integer,class invalid value: x8 = 000123,x9 = asd123 x10 = empty,zhu.kerry,bva example 3,test cases : class arbitrary value: random select some options class boundary value: select all options class boundary value: select none option class boundary value: select 1 option,zhu.kerry,二进制,binary: 0 and 1, byte is made up of 8 bits, word is made up of 4 bytes, ,zhu.kerry,ascii table,zhu.kerry,字符编辑域,default empty blank null zero none,zhu.kerry,一些特殊的边界值,numeric character position quantity speed location size,first/last， first-1/last+1 min/max，min-1/max+1 star/finish， start-1/finish+1 empty/full less than empty/ more than full slower/faster largest/smallest over/under， just over/just under shortest/longest ,zhu.kerry,错误推测法测试用例设计,基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例。 发现程序经常出现的错误的方法： 单元测试中发现的模块错误； 产品的以前版本曾经发现的错误； 输入数据为0或字符为空； 当软件要求输入时(比如在文本框中),不是没有输入正确的信息，而是根本没有输入任何内容，单单按了enter键； 这种情况在产品说明书中常常忽视，程序员也可能经常遗忘，但是在实际使用中却时有发生。程序员总会习惯性的认为用户要么输入信息，不管是看起来合法的或非法的信息，要不就会选择cancel键放弃输入，,zhu.kerry,测试场景法设计测试用例,现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。,zhu.kerry,因果图法测试用例设计,多种输入条件的组合，产生多种结果设计测试用例。 设计方法： 分析软件规格说明文档描述的哪些是原因（输入条件），哪些是结果（输出条件），给每个原因和结果赋予一个标示符。 找出原因与结果，原因与原因之间的对应关系，划出因果图 在因果图上标上哪些不可能发生的因果关系，表明约束或限制条件 根据因果图，创建判定表，将复杂的逻辑关系和多种条件组合很具体明确的表示出来 把判定表的每一行作为依据设计测试用例。,zhu.kerry,因果图法sample 1,valid equivalence classes : condition valid eq. classes . abs(n) n 0, n 0 maxint k maxint, k maxint test cases : maxint n result maxint n result 55 10 55 100 0 0 54 10 error 100 -1 1 56 10 55 100 1 1 0 0 0 ,given inputs maxint and n compute result :,result = if this = maxint, error otherwise,zhu.kerry,因果图法sample 2,causes k maxint 1 1 0 0 inputs k maxint 0 0 1 1 n 0 1 0 1 0 n 0 0 1 0 1 effects k 1 1 0 0 outputs error 0 0 1 1,zhu.kerry,因果图法sample 3,case matrix:,zhu.kerry,测试类型与测试用例设计,根据测试类型设计,根据程序功能模块设计,功能测试,易用性测试,配置测试,压力测试,回归测试,界面测试,文档测试,国际化测试,测试用例1 测试用例2 测试用例3,测试用例1 测试用例2 测试用例3,安装/卸载测试,联机帮助测试,软件更新测试,联机注册测试,文件操作测试,测试用例1 测试用例2 测试用例3,测试用例1 测试用例2 测试用例3,数据备份测试,zhu.kerry,设计测试用例的策略选择,测试用例的设计方法不是单独存在的，具体到每个测试项目里都会综合运用多种方法 首先进行等价类划分，包括输入条件和输出条件，将无限测试变成有限测试 在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。 对照程序逻辑，检查、补充测试用例，以达到逻辑覆盖程度的要求。 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程。,zhu.kerry,测试用例设计工具,设计依据： 软件需求文档 软件设计文档,通用设计工具： microsoft word microsoft excel microsoft access,设计工具专用： ibm rational testmanager mercury interactive testdirector,常见问题： 软件文档不全或没有文档 没有完成编码就开始设计测试用例,zhu.kerry,案例研究1：根据输入判断三角形的形状,测试场景： 一个程序读入3个整数，把这三个数值看作一个三角形的3条边的长度值。这个程序要打印出信息，说明这个三角形是不等边的、是等腰的、还是等边的。,确定输入数据与三角形形状的关系： 设三角形的3条边分别为a，b，c。如果它们能够构成三角形的3条边，必须满足： a0，b0，c0，且a+bc，b+ca，a+cb； 如果是等腰的，还要判断a=b，或b=c，或a=c； 如果是等边的，则需判断是否a=b，且b=c，且a=c。,zhu.kerry,案例研究1：判断三角形的形状（续1）,创建等价类表：,zhu.kerry,案例研究1：判断三角形的形状（续2）,确定等价类输入数据：,zhu.kerry,案例研究2：测试用户登录对话框的功能,测试场景： 在各种输入条件下，测试程序的登录对话框功能。 用户名和密码的规则如下： 用户名长度为6至10位（含6位和10位） 用户名由字符（a-z、a-z）和数字（0-9）组成 不能为空、空格和特殊字符 密码规则同用户名规则,zhu.kerry,案例研究2：登录对话框的功能（续1）,确定输入数据的情形：,zhu.kerry,案例研究2：登录对话框的功能（续2）,确定具体的输入数据：,zhu.kerry,案例研究3：压力/负载测试用例设计,设计目的： 验证程序在承受某种负载或压力下是否能够正常运行 找出程序安全运行的临界值 适用情形： 服务器/客户机局域网 服务器/浏览器互联网 设计方法： 设计出不同等级的压力条件,压力/负载分类与代号： cpu速度cs cpu使用量cu 磁盘空间ds 物理内存pm 虚拟内存使用量vm 登录用户的数量un 传输带宽bw 传输数据的大小dn,zhu.kerry,案例研究3：压力/负载测试用例设计（续1）,zhu.kerry,案例研究4：测试软件对话框的界面设计,deployment testcase test case id：62 title： userexitform path： deploymentgeneral author： xxxxx purpose : make sure the dialog to test is properly designed, look for truncations, wrong tab orders, duplicated hotkeys, overlappings and any other posible issues steps： pre-steps: 1. launch app. 2. go to “tools” / “import/export settings” 3. select “general development settings” 4. click reset settings 5. if you are prompted to save your settings, click “dont save” 6. a dialog appears telling you that the operation had been successful,zhu.kerry,案例研究5：测试中断安装软件的功能,purpose: verify the app can be canceled during installation test steps: 1. launch app name 2. from the drop down menu select “file“, “new“ and “project“ 3. the new project dialog box should appear 4. in “project types”, select “other project types” and under this, “setup and deployment”. from the “templates” select a setup project, give the project a name for example “deploy1“ and press “ok” 5. from the “build” menu c