软件测试Day4|软件测试理论02

6. 测试用例基础

6.1 测试用例的定义

• 设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果；
• 如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内；
• 软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题己修改完成。

6.2 测试用例要素

测试用例编号	测试项	依赖用例	测试步骤	测试数据	预期结果	测试结果	测试人	优先级	备注
TestCase_项目名称_模块名称_功能名称_0001	简短的话描述测试模块、对象、方式、事件	前置用例步骤	测用最朴实的语言写步骤	测试数据	预期结果	Pass/Failed	测试人	优先级	特殊步骤

6.3 测试用例设计和编写的作用

• 有效性：测试用例是测试人员测试过程中的重要参考依据。
• 可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率。
• 易组织性：即使是小的项目，也可能会有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用。
• 可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。
• 可管理性：测试用例也可以作为检验测试人员进度、工作量以及跟踪/管理测试人员的工作效率的标准。
  1）测试用例越详细，覆盖的越多，时间耗费越多。时间不够用的情况下，还要进行详细测试吗？（在时间范围内，测试更多的内容，覆盖面越广越好，可能不深入）
  2）测试用例需要经常更新吗？（必须更新，特别是发现过缺陷的测试用例–杀虫剂【杀虫剂效应，虫子变异】）

7. 黑盒测试用例设计方法

7.1 用例设计方法分类

• 测试数据选择：等价类划分、边界值分析
• 测试步骤设计：因果图法、判定表法、正交实验法、功能图法、场景法

7.2 测试数据选择

7.2.1 等价类划分

（1）等价类划分原理

• 把程序的输入域划分成若干部分然后从每个部分中选取少数代表性数据作为测试用例；
• 每一类的代表性数据在测试中的作用等价于这一类中的其他值，如果某一类中的一个例子发现了错误， 这一等价类中的其他例子也能发现同样的错误；反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。

（2）确定等价类的原则

• 在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类；
• 在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下，可以确立个一个有效等价类和一个无效等价类；
• 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类；
• 在规定了输入数据的一组值(假定n个)，并且程序要对每一 个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类；
• 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(以不同角度违反规则)；【用户名规则】
• 在确知己划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该价类进一步地划分为更小的等价类

（3）划分有效等价类和无效等价类

补充

• 用例编号可按照测试分类写上：功能（Function）、界面（UI）、性能（Performance)、安全（Security）、接口（Interface）；
• 测试项：必须是肯定句，可以不写目的产生的结果，写了不算错；
• 测试项：一般只写一个测试目的（只违反一个规则）；
• 依赖用例：下游用例依赖上游用例（已经存在的用例）；
• 测试数据：没有数据，空着不写（需在测试项中标注某个内容为空）；对空格进行测试（数 据）（建议一般不要将空格放在数据前和后，看不出来空格）；
• 用例中不需要显示是否是正向还是反向；

7.2.2 边界值分析

常在河边走，哪有不湿鞋。

• 边界值本身是一个数值；次边届：按照系统规定的单位或计算方式，一个单位数据的差异。
  1）6≤x≤12：测试用例：5，6，7，11，12，13
  1）6＜x＜12：测试用例：6，7，8，10，11，12
• 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚超越这个范围边界的值作为测试输入数据；
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据；
• 分析规格说明，找出其他可能的边界条件
• 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例
• 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。
  分析规格说明，找出其他可能的边界条件

7.3 测试步骤设计

7.3.1 因果图法

• 适合于描述对于多种输入条件组合的测试方法（少量条件和结果组合）
• 适合于检查程序输入条件涉及的各种组合情况
• 根据输入条件的组合，约束关系和输出条件的因果关系，分析输入条件的各组情况组合，从而设计测试用例

（1）根据条件写出关系

• 恒等，条件A成立-结果D成立
• 非，条件A成立-结果D一定不成立
• 与，条件A，B，C同时成立-结果D成立
• 非，条件A，B，C部分成立-结果D成立
  

（2）根据功能说明在因果图中加上约束条件

互斥、包含、唯一、要求是对原因的约束，屏蔽是对结果的约束

• 互斥（E）：eg：不同时为1：条件a，b，c至多一个为1；
• 包含（I）：eg：至少有一个1：条件a，b，c不同时为0；
• 唯一（O）：eg：只有一个1，条件a，b，c有且仅有一个1；
• 要求（R）：eg：条件a=1则条件b必须为1，即不可能a=1，b=0；
• 屏蔽（M）：eg：若结果d出现，则结果e必须不出现。
  

（3）列出所有的原因和结果的列表，设计初步的测试用例步骤

		Case1	Case2	Case3	Case4
投币	投5角	1	1
	投1元			1	1
选饮料	橙汁	1		1
	啤酒		1		1
结果	出橙汁	1		1
	出啤酒		1		1
	找零5角			1	1

• 因果图中不能把没有结果（不投币选饮料没有结果，因为该结果没有在之前的需求内）和缺陷写到测试用例

（4）优点和局限性

• 优点：能够发现设计中的不足（如果出现有结果没有在之前的需求内，则出现不足）
• 局限性：当原因和结果很多的时候，他们之间的关系连线就很多，导致因果图的可读性变差；因此用作局部的小功能分析（原因和结果不是很多的时候）

7.3.2 判定表法

• 主要适用于多条件的内容组合与结果分析；是分析和表达多逻辑条件下执行不同操作的情况的工具。它由条件桩、动作桩、条件项、动作项组成；
• 使用条件：条件桩在表中的位置和顺序互不影响；所有的动作桩的栓徐不会因为条件顺序的变化而产生不同。

---

• 条件桩（ConditionStub) ：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
• 动作桩（ActionStub) ：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
• 条件项（Condition Entry) ：列出针对它左列条件的取值。在所有可能情况下的真假值。
• 动作项（Action Entry) ：列出在条件项的各种取值情况下应该采取的动作。

（1）实现步骤

• 识别出操作条件（原因）和对应的动作（结果）；
• 分析出条件的组合数量；
• 简化和优化结果，排除一些不可能出现的情况。

（2）实例

• 需求：1）大于500+没过期，发批准单和提货单
  2）大于500+过期了，不发批准单
  3）低于500+无论是否过期，发批准单和提货单，过期发通知单

金额>500	1	0	1	0
时效（过期）	1	0	0	1
批准单	0	1	1	1
提货单	1	1	1	1
通知单	0	0	0	1

• 优化：不论金额与否，只要没过期，就是发批准单和提货单（在测试时间有限时，可以只测一个），减少测试用例

7.3.3 场景法

• 流程图法；现在的软件几乎都是用事件触发来控制流程的。测试时，可以生动地描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。
• 基本流：软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流， 且基本流仅有一个起点和一个终点。
• 备选流：除了基本流之外的各支流，包含多种不同的情况。
• 场景列表
  1） 场景1 基本流
  2） 场景2 基本流 备选流1
  3） 场景3 基本流 备选流1 备选流2
  4） 场景4 基本流 备选流3
  

7.3.4 正交实验法

概念

• 使用正交表；本质是统计和分析实验数据，从大量实验中找到合适的实验数据组合
• ”大量实验中，挑选出一部分具有代表性的点，进行实验分析数据“
• 数学原理：线性代数，概率论、数理统计等

n阶拉丁方-正交运算

左边两个 每行每列元素出现一次，右边正交后 每个数对只能出现一次

• 核心概念
  1）影响实验结果的实验因素（因子）–因素。
  2）每一个因素的不同取值（状况）–水平
  例如，字的显示效果–字体，自豪，颜色称为因素；字体可以选择宋体，楷体等称为水平；
  字体（100个水平）字号（20个水平）颜色（256个水平）
  3）每一列数字出现相同（水平），数对（水平对）出现相同，比如白色和黑色都出现3次，白楷5号、黑楷4号都出现1次
• 实施步骤
  1） 分析所有对结果有影响的因素
  2）选择水平（充分利用等价类和边界值）
  3）选择正交表。只有特定的因素数和水平数的组合才有对应的正交表。所以在现实中用到的时候，找最贴近的正交表（正交表的因素数和水平数一般要大于实际的因素数和水平数）

L9_3_3 三水平三因素 9次实验正交表

7.3.5 功能图法

• 状态迁徙图法：在遇到有事务流或由于某种条件成立导致状态改变的软件时。
• 目标：设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖。
• 如进程调度算法
  

7.3.6 测试大纲法

• 着眼于需求的方法；为列出各种测试条件，将需求转换为大纲的形式，转化为思维导图，树形结构
• 无需用例设计，一般从根节点开始分析，到叶节点为止，这样的一条路径就是一条测试用例；
• 一般用于快速的测试和过程记录。用例一般后补

7.3.7 探索性测试法

• 基于测试人员的经验和直觉
• 是计划内测试用例设计的补充
• 也需要设计测试用例

7.3.8 猴子/随意测试法

• 没有书面测试用例（无意识的行为）
• 测试往往不太真实，不能达到指定的覆盖率
• 想要重复操作，极其困难

7.4 测试用例设计方法综合选择

• 没有哪一方法是单独使用的；
  1）首先进行等价类划分，任何情况下都必须使用边界值分析法；
  2）所有的软件都有文本框–考虑必须一定使用等价类、边界值；
  3）如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图和判定表驱动法；
  4）对于参数类配置的软件，要用正交实验法选择较小的组合方式达到最佳效果;
  5）状态迁徙图法也是很好的测试用例设计方法，可通过不同时期条件的有效性设计不同的测试数据；
  6）对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程；
  7）可以用错误推测法追加一些测试用例；
  8）对于程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

8. 小结

• 测试需求、测试用例和报告缺陷的关系
  1）软件测试基本流程：获取测试需求-编写测试计划-指定测试方案-设计测试用例-执行测试用例-提交缺陷-测试分析和评审-测试总结-准备下一版本测试
  2）获取测试需求是测试工作的重点，也是第一步，通过需求的分析，了解和掌握测试的方向和内容；例如①分析出系统的模块和组织结构；②分析出软件的基本功能和运行流程；③识别出软件的重要和次要功能；获取测试需求中，测试人员要有相应的分析成果，一般用xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试对需求的获取和分析（正反向、覆盖程度等）。
  3）测试中最能体现测试人员工作量的指标就是缺陷的数量和用例的数量。①设计的测试用例总量；②执行的测试用例总量；③执行通过的测试用例总量；④执行失败的测试用例总量；⑤提交的缺陷的总量；【一般④≤⑤：一条用例的预期结果是固定的，bug一部分来自于测试用例，一部分来自于测试人员的经验和直觉在测试过程中发现的】。