软件测试必备知识【从B站而来】

2.0案例：QQ账 6-10位自然数

2.边界值分析法

1边界范围

确定边界情况（输入输出等价类的边界）

选取正好等于、刚好大于、刚好小于边界的值，作为测试数据

2上点：

边界上的点（正好处于边界上的点）

3离点：

距离上点最近的点

如果是开区间，那么离点就是域范围内离上点最近的点

如果是闭区间，那么离点就是域范围外离上点最近的点

4内点：

范围内的点

5开区间

（20,30）大于20，小于30，开区间。20、30是上点，21、 29是离点，23是内点

6闭区间

[20,30]大于等于20，小于等于30，闭区间。20、30是上点，19、 31是离点，23是内点

• 对于闭区间，上点是有效数据，离点是无效数据

• 对于开区间，上点是无效数据，离点是有效数据

• 不管开和闭区间，内点都是有效数据

7步骤

1. 明确需求
2. 划分有效和无效等价类
3. 确定边界值
4. 编写测试用例

8案例

• 要求：标题长度>0 标题长度

等价类划分法和边界值分析法都是着重考虑单个输入的输入条件，没有考虑输入条件的各种组合、输入条件与输出条件之间的相互制约关系。

判定表法才能解决上述案例编写测试用例的过程

3.判定表法

1定义

有多个输入、有多个输出，输入输出之间有相互制约关系

2组成

1. 条件桩：列出所有的输入，顺序无关
2. 动作桩：列出所有的输出，顺序无关
3. 条件项：把条件桩中所有能出现的组合都罗列出来
4. 动作项：根据不同条件项组合产生的结果。动作结果

1.0允许呼叫——判定表编写

3步骤

1. 明确需求
2. 画出判定表：先画条件桩、动作桩，再罗列条件项的不同组合；根据条件项完成动作项
3. 编写测试用例：判定表中一条规则对应一个测试用例

判定表贯穿条件项和动作项的一行就是一条规则，每条规则对应一个测试用例

4案例

2.0订购单的检查，如果金额大于500元，又未过期，则发出批准单和提货单；

如果金额大于500元，但过期，则不发批准单与提货单；

如果金额小于等于500元，则不论是否过期，都发出批准单和提货单。

在过期的情况下不论金额大小还需要发出通知单。

不能直接用判定表去执行测试

通过判定表编写测试用例，用测试用例去执行测试

测试用例的两个重要原则：能看懂、能执行

工作中软件测试千万不能直接修改代码中的BUG，问有关人员能不能改，应该是不能改的，有公司内部的版本

4.因果图法

1因果图的核心

因果图的“因”——输入条件

因果图的“果”——输出结果

2因果图中的基本关系和符

通常在因果图中C表示原因，E表示结果

在测试时，要考虑这些控件的组合情况，组合量非常大（eg：3^4=81种组合情况）

那么用以上的测试方法均不合适，如何采用最少测试用例集合获得最大的测试结果——应使用正交排列法

5.正交排列法

1适用范围

当输入数据或输入数据的组合量很大，这时我们不可能为每一种输入组合都创建测试用例

2正交表

一种特制的表，一般的正交表标记为$L_n(m^k)$，

n表示行数，k是表的列数，m是列的取值个数

eg：$L_9(3^4)$：9行4列，4因素3水平，4个列，一个列有三种取值个数

列数就是因素，水平就是取值

$$正交表公式：L_n(m^k)，n表示行数，k表示列数，m是列的取值个数$$

3步骤

1）明确需求

2）绘制正交表

• 先确定列数
• 再确定正交表每列的取值
• 根据因素和水平可以确定行数

3）根据正交表写出测试用例

• 正交表的一行代表一个测试用例

4案例

窗体中有多个控件（字体、字符样式、颜色、字 ），每个控件有多个取值

字体：仿宋、楷体、华文彩云

字符样式：粗体、斜体、下划线

颜色：红色，绿色，蓝色

字 ：20 、30 、40

绘制正交表

6.判定表和正交表案例

1.0题目：

2.0题目：

7.场景法——流程图法

1定义

场景法使用流程图描述用户的使用场景

然后通过覆盖流程路径来设计测试用例

• 从流程开始到结束，有几条路径就有几个路径
• 一条路径对应一个用例

2意义

场景法测的是各个功能组合起来——从用户角度

从测试人员角度：平时测的是单个的功能点，场景法多用的是单个功能点的组合

3步骤

1. 确定需求
2. 画出流程图
3. 根据流程图写出测试用例

• 有多少条路径就有多少个测试用例

4案例

ATM机取钱

流程图：

8.错误推测法

了解即可。凭的是直觉和经验，对于测试经验丰富的测试人员喜欢使用 的一种测试用例方法

1使用场景

项目紧，任务急，时间不够的时候使用

二、软件缺陷

缺陷管理

项目管理工具——禅道

测试管理工具——JIRA

1.软件缺陷定义

软件或者程序中存在的各种问题

2.软件缺陷的判定标准

软件未达到需求规格说明的功能；

软件功能超出需求规格说明的范围；

软件出现需求规格说明书指明不会出现错误的地方；

软件出现需求规格说明书虽未指明，而应该达到的目标；

测试人员难以使用，效率低，或者最终用户体验不好；

3.缺陷产生的原因

软件缺陷产生不可避免，产生原因如下：

• 需求解释、记录、定义错误
• 设计文档存在错误
• 编码、程序代码有误
• 硬件或软件系统产生错误

4.缺陷产生的根源：

• 需求的变更
• 交流不充分
• 软件的复杂性
• 进度压力

5.软件缺陷信息

1缺陷的状态：

• fixed：修复状态。研发人员修复
• closed：修改完，关闭状态。测试人员关闭
• rejected：拒绝状态
• postpone：拖延状态
• new：新建状态
• open：打开状态
• renew/reopen：重建状态

2缺陷的严重情况：

• 5—Critical 致命：系统瘫痪、异常退出、死循环、严重的计算错误
• 4—VeryHigh 较严重：频繁死机、系统大部分功能不可用
• 3—Hgih 严重：功能点没有实现，不符合用户需求、数据丢失
• 2—Medium 一般：仅在特定条件上发生
• 1—Low 低：错别字

3缺陷的优先级：

• 5—Urgent：
• 4—VeryHigh：
• 3—High：
• 2—Medium：
• 1—Low：

4简单示范

测试用例：

6.缺陷跟踪流程

缺陷统计分析注意点：

• 看软件模块的问题多

• 看哪个测试人员谁 告的软件缺陷多

• 缺陷数量所占百分比

• 修复缺陷的百分比、及时性

• 一次修复缺陷的百分比

• 能否在计划时间内正常发布

8.测试 告演示

9.项目管理工具——禅道

受众主要在IT行业

10.测试管理工具——JIRA

受众更广，全行业

企业管理人员、项目管理者、开发人员、测试人员、其他人员