测试设计和测试方法 笔记

四 、测试设计和测试方法

动态测试：软件实际运行时，进行测试的过程

静态测试：看文档或者对代码进行逻辑检查

正式评审：产品的需求评审，开发的概设评审，代码评审，测试的用例评审，主要是让项目组各方面了解需求的实现目的

度量：缺陷密度（缺陷个数÷用例总数 缺陷个数÷代码行数)，测试覆盖率，性能要求，上线之前的通过率

技术评审：

（1）用例评审（测试评审）：对用例进行评审，对测试的场景达成测试

（2）代码评审：对当前迭代的功能相关的代码机型评审

（3）接口评审：前后端进行数据交互的方式

圈复杂度：代码越复杂，圈复杂度越高，代码越简单，圈复杂度越低

file:///C:/Users/Zhang/AppData/Local/Temp/msohtmlclip1/01/clip_image002.png

圈复杂度计算：

file:///C:/Users/Zhang/AppData/Local/Temp/msohtmlclip1/01/clip_image004.png

圈复杂度计算:

判定节点===》判断===》是、否判定节点:1,2,3,4

独立路径:5条独立路径===》圈复杂度为5

1-4-6

1-2-5-6

1-2-3-7-6

1-2-3-2-5-6

1-4-5-6

圈复杂度计算公式一: V=E(结构图的边数)-N(节点数)+2=10-7+2=5

圈复杂度计算公式二: V=区域数=5

卷复杂度计算公式三: V=P(判定节点)+1=4+1=5

file:///C:/Users/Zhang/AppData/Local/Temp/msohtmlclip1/01/clip_image006.png

数据流：数据从哪里来，最终到哪里去

file:///C:/Users/Zhang/AppData/Local/Temp/msohtmlclip1/01/clip_image008.png

&&与符号==》条件要同时满足

ll 或符号==》只要满足一边条件

-----------------------------------------------------

测试技术分为黑盒测试、白盒测试

黑盒测试：黑盒测试就是功能测试，主要对功能进行验证，不看代码，直接根据需求进行测试

黑盒测试就已知产品的功能需求，验证实现的功能是否符合需求的要求。测试员是不需要知道程序内部的逻辑机构和代码的特性，只要根据需求文档，验证功能是否满足预期

白盒测试：已知产品内部的一个工作过程，验证每个操作（每个路径）是否符合设计要求

把测试的对象看成一个透明的盒子，对程序内部所有的逻辑路径进行测试，也叫结构测试，代码测试

灰盒测试：介于白盒和黑盒之间，既要对功能进行测试，也要对代码进行测试，主要是对接口进行测试

file:///C:/Users/Zhang/AppData/Local/Temp/msohtmlclip1/01/clip_image010.png

测试人员都是根据需求文档进行测试==》提炼测试点（思维导图XMind）==》编写测试用例（excel，word）

----------------------------------------

等价类：

主要是划分有效等价类和无效等价类

有效等价类：主要检查正常场景，检查功能或者数据是对程序是有意义的

无效等价类：主要是检查异常场景，建议无效的输入或者异常的操作不能对程序产生有效的影响，一般返回对异常提示

需求：对某个同学的成绩进行打分（输入域：0-100分）

在0-100之间输入任何的数字都是等效（效果相同）的

结论：等价类中任意输入对象都是等效的

例如：0<a<100

有效等价类:0<a<100

无效等价类:小于等于0，大于等于100

需求:qq密码由6-10位数字字符组成有效等价类:满足6-10位的数字无效等价类:

1，从数字字符的长度去违反密码小于6位

密码大于10位

2，从字符的种类进行违反(6-10位)

出来数字以外的其他字符:中文、字母、特殊字符

工作中常见划分等价类的地方:

0<a<100

有效等价类:1个0<a<100

无效等价类:2个小于等于0，大于等于100

输入值为布尔值（真true 假false)

有效等价类:2个 真 假

无效等价：0个

规定了输入数据的一组值---枚举值：一组可以被选择的值（文化程度：初中/高中/大学）

有效等价类：3个 初中，高中，大学

无效等价类：1个 不在枚举值范围内的任意值

往往发现bug的用例都是在无效等价类中出现

需求（测试用例）：QQ密码由6-10位数字或字母、下划线组成

常见的能够划分等价类的地方:

1.数值范围(红包可以发多少)

2.重复次数(账号)(登陆失败的限制次数)

3.字符串长度(输入框的长度限制)

4.字符串组中字符的个数（['初中' , '高中' ,‘大学’]--枚举值的验证）

5.文件命名----上传头像文件只能支持.jpg .png .gif等等

6.文件大小-----支持1 - 100M

7.屏幕的颜色种类（显示屏支持的色域，跟与市场调研相关的颜色）

8.超时时间（验证码的限制时间，ATM机操作时间限制）

-----------边界值-------------

需求:对某个同学的成绩进行打分0-100分

上点:在边界上的点，能取到的点(0,100)--作为正常测试用例(有效等价类)的测试数据

离点:不在范围内但是是离上点最近的(-1,101) --作为异常测试（无效等价类）的测试数据

内点:在范围内的点--是不考虑测试，只要把上点进行测试就可以确保内点都是正常的

闭区间[0,100] 0≤x≤100上点:0,100

离点:-1,101

开区间(0,100)0<x<100上点:1,99

离点:0,100

注意:边界值要考虑最小单位

0.00<x<=200.00

上点:0.01 200.00

离点:0.00 200.01

半闭半开区间 ：以1min为粒度，查找2021年所有的xx信息

[2021-01-01 00:00,2022-01-01 00:00)

上点:2021-01-01 00:00 2021-12-3123:59

离点:2020-12-31 23:59 2022-01-01 00:00

边界值必须注意地方：必须是一个有序集合

[1-9]====>有序集合

[1,2,3,4,5,6,7,8,9]====>这是一组数据，属于枚举值

file:///C:/Users/Zhang/AppData/Local/Temp/msohtmlclip1/01/clip_image012.png

需求:发微信红包最大是200元

1，显性需求

直接在需求文档中存在的

2，隐性需求

要通过阅读需求后进行发掘最小0.01元

红包是怎样发

红包发出后，怎么收，退款不同系统终端能不能收

3，关联需求==》考虑关联系统的需求情况，我方系统功能修改后是否会影响到上下游系统，其他上下游系统修改后会不会影响到我方系统

发红包是在聊天系统做的，红包的金额关联着微信钱包，微信钱包关联着外部的银行系统

外部的银行系统限额会不会影响到发红包的功能

微信钱包修改金额的最小单位，会不会影响到发红包的功能

4，特殊需求：考虑用户的需求，用户的关注点

例如一些特殊的日子，可以发520的红包

编写测试用例的过程：根据需求分析===》提炼测试点===》编写测试用例（测试案例/test case）

提炼测试点===》思维导图xmind

写测试用例===》excel，思维导图，word（非常少）

面试题：

Xmind思维导图如何转换为测试用例？

通过使用Xmind对需求进行梳理，梳理出本次需求的业务流程，提炼测试点，之后根据梳理出来的测试点进行输出测试用例，以确保我们的测试覆盖率

我们理解的思维导图出来的测试点好比是本次测试的测试大纲，然后测试用例就是本次测试执行的细化输出

测试用例是围绕着需求文档进行编写，对需求不明确的地方是可以进行提出，但是确认后依据产品经理所说的为准

每—条测试用例就是执行测试的最小维度的文档

编写测试用例的注意要点：

1，测试用例包含着一些基础内容：

（1）用例编号：是对多条用例进行唯一的编号

（2）用例标题：简述本条测试用例的测试场景和测试目的，要求尽可能的唯一，要求是陈述句，要做到和预期结果首尾呼应，一般是以“验证”开头，“验证xxx操作，满足xxx结果”，例如：验证输入正确的账号，正确的密码，登录成功

（3）前置条件：描述测试执行之前需要准备的东西，作用是简化用例步骤，把一些重复执行的内容（不在测试范围的内容）进行简述

（4）用例步骤：对执行测试的步骤进行描述，一般不超过6步

（5）预期结果：对测试执行之后的结果进行预知，假设用例步骤执行后没有达到预期结果，可以判断这条用例测出bug

2，excel表格中换行：aLt+enter

3，用例标题的编写要与预期结果首尾呼应

4，用最少的测试用例覆盖最多的有效等价类（正常场景）

5，一个无效等价类就是一条测试用例，一条测试用例不能覆盖多条

6，对“不输入”的情况也要考虑无效等价类

7，测试用例当中的测试数据需要用 “” 括起来

8，用例步骤，前置条件，预期结果，如果使用了序号，那么每个序号后面需要标上标点符号，需要统一

9，涉及到枚举值的场景，每个枚举值就是一个有效等价类，也就是需单独的一条测试用例。枚举值都要进行单独的测试用例验证

10，每一条测试用例体现的测试数据一般一条，不会出现‘或‘

11，预期结果的编写，如果没有要求必要的返回信息，那么要简单描述对应的预期返回结果。如果需求中有明确各种返回的信息，那么就要进行逐─验证，要确保每个结果都得到了覆盖测试

12，时间类型的边界值，也是要验证上点（正常场景）和离点（异常场景)，而且也要关注最小的单位

13，编写测试用例时，最好是先写覆盖正常的场景测试用例，再对相关模块的异常测试用例进行编写

14，不要把bug编写成测试用例

进行用例评审的流程:

首先先说一下自己本次任务的需求内容，让其他同事知道我对需求内容的了解程度(自己对需求的理解)，一般是讲本次需求的业务流程，说明本次需求的改点。

接着就是讲解本次需求任务的测试场景和测试点（测试用例进行讲解)

会议结束后，会根据会议上，其他同事提出的点，对自己的测试用例进行修改或者补充

file:///C:/Users/Zhang/AppData/Local/Temp/msohtmlclip1/01/clip_image014.png

file:///C:/Users/Zhang/AppData/Local/Temp/msohtmlclip1/01/clip_image016.png

测试点的分析思路?

面试题:我讲一下xxx的测试点?

1，从页面讲起，检查页面的元素是否美观，信息的描述是否准确，页面的功能按钮是否都正常，操作是否简洁友好

2，接着从各种功能上展开描述，讲一个正常的接多个异常的（购物车加入商品功能:正常的商品有库存时是否能加入购物车，异常的商品库存为0时是否能加入购物车，选择数量大于库存量是否能加入购物车，选择数量超过购物车最大值是否能加入购物车)

3,接着从性能上思考，多人操作的情况，快速的连续提交的操作

4，从网络状态思考，弱网（网络差)，无网络

5，如果涉及安全的，也要考虑安全的问题，一般是接口信息篡改的问题（有无做加密出来）

6，考虑兼容性的问题，软件是否适配不同的系统，不同浏览器，各种网络状态的适配

判定表:分析多个条件下可以执行得到不同操作情况

需求:12306登陆，账号，密码，验证码进行登陆，登陆成功和登陆失败

步骤：

1)找出问题，作为条件桩账号，需求中可以找到的密码，验证码的输入

2）找到可能出现的结果，条件组合之后有什么结果，作为动作桩===》需求中可能出现的结果

登陆成功，登陆失败

3)把所有的条件桩可能触发的情况进行列举，只有对与错的情况，也就是列出条件项

4)通过分析条件项，把可能触发的动作进行列举，列出动作项

5）合并相似的需求

6）编写测试用例

file:///C:/Users/Zhang/AppData/Local/Temp/msohtmlclip1/01/clip_image018.png

file:///C:/Users/Zhang/AppData/Local/Temp/msohtmlclip1/01/clip_image020.png

条件桩：找出需求中的问题，条件

条件项：对各个条件桩不同的状态进行列出，只分为正确或者错误

动作桩：条件结合后会得到什么杨的结果

动作项：最终根据满足的条件获得实际结果

判定表的优缺点:

优点:可以对不同的条件组合进行覆盖，可以保证测试的覆盖率

缺点:当需求中的条件较多时，那么得到的场景就会非常复杂，假设一个需求中有n个条件，那么可以列出的场景就是2^n次方个场景，比较繁琐，例如10个条件进行组合那么就是2^10=1024个场景

----------------------------------------------

因果图:是结合着判定表去使用

面试题:你对因果图是怎么理解的?你是怎样理解因果图的?

我们公司之前对有因果关系的需求，首先会先找到里面的原因转换为判定表中的条件桩，然后把因果关系中的结果转换为判定表中的动作桩，从而得到一个判定表，以防止测试场景的漏测情况

C原因(输入条件) E结果(输出结果)

1，原因和结果的关系

恒等:==等于equal

a=1 b=1 a==b

非：不 not 否 不等于 '！=' '<>' '~'

或：or 或者 '||' '|''/' 'v' ：只要满足其中一个条件

与：且 和 and '^' '&' '&&' ：要同时满足

2,原因与原因的关系

异：非必选的选择框，可以出现一个，但是出现只能出现一个

或：多选框，可以同时都出现，但是也可以只出现一个

唯一：必选的单选框，只能出现一个，而且是必须出现一个

要求：当选择了广州，那么省份必须要求是广东

3，结果与结果的关系

强制：投保成功和投保失败只能出现一个

面试题：输入3个正整数a、b、c，分别作为三角形的三条边，通过程序判断三条边是否能构成三角形？如果能构成三角形，判断三角形的类型（等边三角形、等腰三角形、一般三角形），用判定表的方法

file:///C:/Users/Zhang/AppData/Local/Temp/msohtmlclip1/01/clip_image022.png

场景流程分析法：

等价类，边界值测试方法==》对单一功能点进行测试

场景法，状态迁移法测试方法==》对业务类型进行测试，

业务流程业务场景是由多个功能点进行组合

场景法:（对不同的场景进行测试，需要列出相关业务流程图）

场景法主要是针对测试场景类型的，顾也称场景流程分析法。

流程分析是将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例。根据流程的顺序依次进行组合，使得流程的各个分支都能走到

离职流程：

1，登录考勤测试

2，申请离职，填写离职单（离职日期，离职原因，工作交接）

3，提交

4，领导审核

（通过--交接工作--离职成功）

（不通过--重新申请）

5，流程结束

ATM机取钱：

基本流==》一个正常流程

1，插卡

2，验证卡片有效

3，输入密码，校验密码正确

4，输入取款金额

5，取款

6，取卡

备选流==》在基本流过程中可能出现的各种异常情况，分支流程

1，插入无效卡（公交卡，会员卡，失效银行卡，被锁银行卡，过期银行卡）

2，密码错误（没有超过最大次数）

3，密码错误（超过最大错误次数--结束）

4，不输密码

5，不输入取款金额

6,输出超出银行卡余额金额

7，输出超出ATM机余额的金额

8，限额--当日限额，当月限额，卡限额

9，超时不娶款

10，取部分款

11，取了又放回去

12，超时不取卡

基于经验的测试方法

系统异常法===》模拟系统可能出现的故障，来确保软件的容错能力

13，ATM机断网

14，ATM机断电

场景法一般是输出基本流（Xmind画业务流程图），通过分析基本流可能出现的多个备选流（异常的流程），对每个流程进行测试，以覆盖所有可能出现的测试场景，提高测试覆盖率

file:///C:/Users/Zhang/AppData/Local/Temp/msohtmlclip1/01/clip_image024.png

正交表---条件的两两组合，跟判定表一样麻烦，当条件变得复杂时，整个方法列出的场景也会非常的繁杂

状态迁移（和场景法非常像，一般也是和场景法结合使用）：

通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为

基于经验的测试方法

错误推测法：根据自己对系统的了解，根据系统以往出现过的bug，根据以前的测试经验去进行设计测试用例

系统异常法===》模拟系统可能出现的故障，来确保软件的容错能力

例子:电商的主备切换，模拟主服务器出现异常情况，备用服务器能不能快速进行业务切换，相关的订单数据会不会丢失

随机测试==》模拟用户的操作

进行用例评审的流程:

首先先说一下自己本次任务的需求内容，让其他同事知道我对需求内容的了解程度(自己对需求的理解)，一般是讲本次需求的业务流程，说明本次需求的改点

接着就是讲解本次需求任务的测试场景和测试点（测试用例进行讲解)

会议结束后，会根据会议上，其他同事提出的点，对自己的测试用例进行修改或者补充

如果，对应输入框填写异常，提交时，需提示用户，模板为'xxx输入有误，请检查! '

预期结果:护照号输入有误，请检查!

实际结果:护照号输入有误,请重新输入!

测试点的分析思路?测试用例的分析思路?

面试题:你给我讲一下xxx的测试点?（偏实际使用）

1，从页面讲起，检查页面的元素是否美观，信息的描述是否准确，页面的功能按钮是否都正常，操作是否简洁友好

2，接着从各种功能上展开描述，讲─个正常的接多个异常的(购物车加入商品功能:正常的商品有库存时是否能加入购物车，异常的商品库存为0时是否能加入购物车，选择数量大于库存量是否能加入购物车，选择数量超过购物车最大值是否能加入购物车)

3,接着从性能上思考，多人操作的情况，快速的连续提交的操作

4，从网络状态思考，弱网（网络差)，无网络

5，如果涉及安全的，也要考虑安全的问题，一般是接口信息篡改的问题，有没有涉及一些敏感信息(有无做加密出来)

6，考虑兼容性的问题，软件是否适配不同的系统，不同浏览器，各种网络状态的适配

测试用例的分析思路?（偏理论）

面试题:拿到一份需求后你会怎样设计测试用例?怎么保证测试的覆盖率===》通过测试方法方面去思考拿到需求文档之后，我会先分析需求中说明的基本功能，然后对这些基本功能进行业务流程的梳理，进行设计测试用例，包括正常的主体流程和异常的分支流程。

如果涉及到状态转换的场景那么也会对这些场景进行设计测试用例，用于提高业务流程的覆盖情况。

对涉及到边界值的场景会使用到边界值分析法来设计测试用例。

然后也会根据自己对业务和系统的了解来设计测试用例。

如果需求里面的功能涉及到系统的故障恢复能力，容错能力，那么也会使用系统异常法进行设计一些系统异常情况下的测试用例。

如果需求中功能涉及到性能和安全方面的测试，也会设计相关的性能测试用例和安全测试用例