常见的测试风险
D级：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题
23. 测试用例的要素
- 测试用例编号
字符和数字组合成的字符串，用例编号应具有唯一性、易识别
系统测试：产品编号-ST-系统测试项名-系统测试子项名-XXX
集成测试：产品编号-IT-集成测试项名-集成测试子项名-XXX
单元测试：产品编号-UT-单元测试项名-单元测试子项名-XXX - 测试项目
当前测试用例所在测试大类、被测试需求、被测模块、被测单元等
系统测试用例测试项目
软件需求项
集成测试用例测试项目
集成后的模块名或接口名
单元测试用例测试项目
被测函数名 - 测试标题
简单描述，需要用概括的语言描述用例的出发点和关注点，原则上每个用例的标题不能重复 - 重要级别
对基本和普通测试项的区分
高级别
保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例
中级别
重要程度介于高和低之间的测试用例
低级别
实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例 - 预置条件
执行当前测试用例需要的前提条件，如果这些前提条件不满足，则后面测试步骤无法进行或无法得到 预期结果 - 输入
用例执行过程中需要加工的外部信息。根据软件测试用例的具体情况，有手工输入、文件、数据库记录等
- 1
7.操作步骤
执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行
8.预期输出
当前测试用例的预期输出结果，包括返回值内容，界面的响应结果，输出结果的规则符合度等
测试用例额外的要素
1.用例设计者
能准确的找到测试用例设计人员，对用例修改时能方便找准人员
2.用例设计日期
方便检查用例设计的进度
3.用例版本号
方便用例设计人员对用例的跟踪
4. 对应的开发人员
出现BUG后能及时找到相应的人员进行修复
- 1
- 2
24. 测试用例级别的划分
优先级一般都是和缺陷的严重程度对应的。
一般可以把优先级分为三种：
高：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。
中：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI展示、用户体验等方面的测试用例设计
低：不常被执行的测试用例。比如压力和性能测试用例设计，接口测试用例设计随着时间的推移已经从低级别变化到了中级别
25. 怎样保证覆盖用户需求？
覆盖用户的需求；
从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
用例各个要素要齐全，步骤应该足够详细，操作应该明确，容易被其它测试工程师读懂，并能顺利执行；
做好用例评审，及时更新测试用例。
测试完成应找业务人员进行验收，便于发现非测试角度的问题
26. 写好测试用例的关键 /写好用例要关注的维度
测试用例：测试用例为验证某一特定软件产品准备的一组有编号，输入，预期输出的描述 //记得《软件测试过程与管理》上是这样写的,而我个人觉得应该是有编号，输入，预期输出，测试步骤，测试描述等等一些信息的描述
以下Shared by Mikhail Rakhunov
好的测试用例：一个发现Bug概率很大的用例就是一个好的测试用例
测试用例设计应该具备的以下的特点
Test Case ID:
用来标记测试用例的编号，这个编号必须是唯一的
测试描述:
用来描述你将要进行的测试是怎样实施的
修订历史:
为了明确测试用例由谁创建或者修改，所以每个测试用例都应该有其修订历史
功能模块:
测试功能模块的名字
测试环境:
用来描述你的测试环境，当然包括硬件环境和软件环境
测试准备:
测试之前除了你所测试的程序之外还应该准备的东西，如打印机，网络等等
测试执行:
用来详细描述你的测试步骤.
期望结果:
The deion of what you expect the to do.
描述该功能所要实现怎样的结果
实际结果:
通过/失败
如果成功——纪录实际运行的过程
如果失败——描述你观察到的现象，这将有利于发现Bug的起源
----------
一个很好的测试所应具有的特征:
发现Bug的几率很大
没有多余
不是太简单也不会太复杂
----------
ps.当你的期望结果有很多的时候，测试用例就会变得很复杂
27. 测试用例的状态
排队（In Queue）：
测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。
进行中（IP）：
该测试正在进行，并且会持续一段时间。（如果一个测试所需要的时间少于一天，我就不会讲一个测试标为进行中，因为我每天会跟踪测试用例的状态）
阻塞（Block）：
一些因素会导致测试不能进行到底，例如某个功能欠缺或者测试环境的某个部分欠缺。我通常会在测试用例总结工作表的意见栏记录下阻塞的状态。你可以把阻塞理解为：我希望运行测试，但是目前还不能运行测试。
跳过（Skip）：
你决定在当前测试阶段跳过某个测试，可能是因为它的优先权相对较低。（同样地，我会在测试用例总结工作表的意见栏记录下我跳过这个测试的原因。）你可以把跳过理解为：我现在可以运行这个测试，但是我不想运行它。
通过（Pass）：
测试运行结束，测试人得到了预料中的测试结果状态和测试行为。
失败（Fail）：
在很多情况下，测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远。这就引发了关于系统质量的疑问。一个或多个测试错误需要记录下来。
警告（Warn）：
在很多情况下，测试人得到预料之外的测试结果，状态或行为，但是这些结果与测试目标差别不是很大（我通常会在测试包总结工作表的通过一栏记为警告，而不是另加一栏）。另一种想法是，警告意味着当前的错误是无关紧要的，或者对正在测试的特征是没有意义的。系统报出了更多的错。我处理这个问题的一个标准是只和延期的或不是一定要改的错误相关的测试可以标记为警告，而不是失败。
关闭（Close）：
一个测试在第一个循环中被标为失败或警告，第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后，没有错误出现。将这类测试标记为关闭而不是通过，使得你可以跟踪测试在某一个测试发布中失败的实事（同标记为警告的测试一样，我在测试包总结工作表中将标记为关闭的测试也纳入成功的范畴）。
28. 常见的测试用例设计方法
用例编写步骤：
拿到测试需求 -> 分析需求（画思维导图） -> 编写用例 -> 划分用例优先级
用例编写特性：
· 一致性：主要包括用例模板一致；各同事的编写手法一致；以及用例的细粒度一致。
· 覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对那些功能会产生影响的覆盖；对各种场景的覆盖等 。
·可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。
·执行准确性：是指用例执行的准确度，本身没什么技术含量。但这里需要注意的是执行人对待执行用例的态度。不要因为用例简单或者一些外界的因素，导致部分用例未实际执行标为通过的情况。
·持续更新：要及时不断的更新，要尽量减少用例库中失效的用例 。
·复用性：主要用例可以被不断的复用，从而减少维护成本
用例设计方法：
1. 等价类与边界值**（重点方法）**
等价类：等价类划分法是把所有可能输入的数据，有无效等价类和有效等价类（即正确输入和非法输入），即程序的输入域划分策划国内若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。方法是一种重要的、常用的黑盒测试用例设计方法。
边界值：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
与等价类区别：
· 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
· 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
等价类与边界值的结合使用：
例：一个文本框的输入长度为 6-10 个字符
分析：有效等价类： >=6个字符，<=10个字符
无效等价类：<6个字符，>10个字符
边界值：5,6,7,9,10,11个字符
2. 场景法**（重点方法）**
定义：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。
基本流：是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）
备选流：一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）
场景法的运用：
例：有一个在线购物的实例，用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用帐号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。
· 基本流
· 备选流： 1) 进入购物网站，选择物品，登录账号，付费，生成订单
2）账号不存在
3) 账户余额不足
更多的备选流。。。。。。
3. 正交排列驱动法
定义：在界面中有多个控件，控件之间有多种组合关系，如果组合的数量巨大（一般超过20种），没有必要将所有组合都测试，可以通过正交排列法将组合中最优，最少的组合进行测试。
正交表公式：
Ln（m^k）
· L（line）行
n:表示正交表的行数
提示：正交表确定后，n值是固定的，不需要测试人员计算
m：表示正交表中数据的最大值
测试时：m表示每个控件的取值个数
K:表示正交表的列数
测试时：k表示参与组合的控件的个数
与判定表驱动法的区别：正交表一般用于组合较多的场合（一般>20种），判定表一般用于组合较少的情况
4. 因果图
1.定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
2.因果图法产生的背景：
等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。
3.因果图介绍
-
4种符号分别表示了规格说明中向4种因果关系。
-
因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。
-
Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。Ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。
4. 因果图概念
- 关系
①恒等：若ci是1，则ei也是1；否则ei为0。
②非：若ci是1，则ei是0；否则ei是1。
③或：若c1或c2或c3是1，则ei是1；否则ei为0。“或”可有任意个输入。
④与：若c1和c2都是1，则ei为1；否则ei为0。“与”也可有任意个输入。
- 约束
输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。
A.输入条件的约束有以下4类：
① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。
② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。
③ O约束（唯一）；a和b必须有一个，且仅有1个为1。
④R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。
B.输出条件约束类型
输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。
5. 采用因果图法设计测试用例的步骤：
1)分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。
2)分析软件规格说明描述中的语义，找出原因与结果之间, 原因与原因之间对应的关系，根据这些关系,画出因果图。
3)由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。
4)把因果图转换为判定表。
5)把判定表的每一列拿出来作为依据,设计测试用例。
5. 判定表
定义：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
判定表的优点
· 能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。
·在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
判定表通常由四个部分组成如下图所示：
1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
6. 错误推测法
定义：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法
错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例
29. 判定表用在哪些时候/哪些功能
判定表比较多用在多层条件判断组合的场景，比如嵌套的if语句这种
使用场景：
1：等价类和边界值无法覆盖到控件与控件之间的联系，此时我们需要判定表来覆盖控件与控件之间的影响
什么是判定表：
判定表是分析若干输入条件下，被测试对象根据不同的条件作出不同的响应的工具，适用于业务逻辑关系和多种条件组合情况
判定表的结构：
名词解释：
- 条件桩：被测对象所有的输入
- 动作桩：针对条件桩所有的动作
- 条件项：被测对象可能输入的真假值 T F
- 动作项：针对条件项的动作T F
使用判定表的步骤
1.列出所有的条件和动作
2.根据提取出来的条件桩和动作桩，设计判定表确定规则的个数（假如有n个条件，每个条件有2个取值 （0、1），就可以产生2的n次方种规则）
3.填写判定表
4.简化判定表【合并判定表会减小测试的充分性，8条以内的规则不建议合并】
5.一个规则就可以转成一个测试用例
12345
- 1
- 2
- 3
- 4
- 5
- 6
以登录模块为例
正确的账号密码登录成功
用户名和密码为空：提示用户名或密码不能为空
用户名输入错误：提示用户名或密码错误，用户名和密码清空
用户名正确，密码错误，提示：密码错误，用户名保留，密码清空
生成判定表如下图
判定表优点
判定表法主要针对功能需求中的处理过程，处理过程越是复杂，就越有必要使用判定表法。判定表法充分考虑了输入条件间的组合，对组合情况覆盖充分，且可得出每个组合的预期输出。其实，做测试需求分析的目的也就是得出完整的测试用例。重测试需求分析，轻测试执行过程。
判定表缺点
当被测试特性输入较多时，会造成判定表的规模很庞大。当输入条件间的约束条件不能有效区分输入是否需要进行组合测试时，有可能产生冗余。需手工剔除冗余用例。