产品经理必懂的测试基础知识(黑盒、白盒、冒烟、回归等)

测试基础知识

找实习工作的过程中总结了下测试基础知识，编程能力重要，测试基础同样重要，希望对大家有帮助

软件测试方法：静态测试和动态测试

白盒测试和黑盒测试

传统测试与面向对象测试

软件测试过程：单元测试，集成测试，系统测试，验收测试

按测试类型：功能、性能、界面、易用性测试、兼容性测试、安全性测试、安装测试

（单元测试：在编码过程中，对每个小程序单元测试）

（集成测试：将单元集成在一起后，可称为组件）

回归测试、冒烟测试、随机测试

（冒烟测试：是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。专门针对某一项功能的测试—主干功能）

测试流程：编写测试计划，编写测试用例，搭建测试环境，，实施测试，测试评估，测试总结。

测试计划：就是在测试实施之前确定测试对象，并对测试对象进行资源，时间，风险，测试范围，预算等方面的综合分析。

测试计划的内容：简介，项目说明，范围，测试手段和策略，项目通过和失败的标准，暂停/重启测试的标准，测试任务分配，职责等等

测试用例三要素：测试步骤，输入数据，期望结果

测试用例内容：项目名称，测试环境，预置条件，用例编 ，测试步骤，输入数据，预期结果。

测试数据是写好测试用例的关键？

测试用例内容，写好测试用例的关键

功能测试，性能测试

黑盒测试（也称为功能测试或数据驱动测试）

黑盒测试分为：等价类划分法，边界值分析法，因果图法，决策表法，正交实验法，场景法，错误推测法，常用控件测试（文本框，按钮，单选按钮，复选框）（要知道各种方法的实际应用场景）

黑盒测试在程序接口进行测试，只检查程序功能是否按规格说明书的规定正常用，也被称为用户测试。

集成测试/系统测试/验收测试：黑盒测试

黑盒测试与软件的实现过程无关，在软件实现过程发生变化时，测试用例仍可使用

黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间

等价类划分法：有效等价类，无效等价类（计算1-100之间的和，登录注册对密码位数的要求）

设计一个新用例，使它能够覆盖尽量多尚未覆盖的有效等价类，重复该步骤，直到所有有效等价类均被用例覆盖

设计一个新用例，使它仅覆盖一个尚未覆盖的无效等价类，重复该步骤，直到所有无效等价类均被用例覆盖

三角形测试用例

题目：输入三个数a、b、c分别作为三边的边长构成三角形。通过程序判定所构成的三角形是一般三角形、等腰三角形还是等边三角形时。用等价类划分方法为该程序设计测试用例。

在三角形计算中，要求三角形的三个边长：A B C。

1、 当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。

2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。

3、若是等边三角形，则打印：“等边三角形”。

4、画出程序流程图并设计一个测试用例。

（三角形问题复杂之处在于输入与输出之间的关系比较复杂）

一、等价类划分法：大多数从输入域划分等价类，此处可从输出域划分等价类，且为最简单的方法。有五种可能的输出情况，一般三角形，等腰三角形，等腰直角三角形，等边三角形，非三角形

R1={<a,b,c>:边为a,b,c的等边三角形}

R2={<a,b,c>:边为a,b,c的等腰三角形}

R3={<a,b,c>:边为a,b,c的等腰直角三角形}

R4={<a,b,c>:边为a,b,c的一般三角形}

R5={<a,b,b>:a,b,c构不成三角形}

用例编	a	b	c	预期结果
01	3	3	3	等边三角形（R1）
02	2	2	3	等腰三角形（R2）
03	3	4	5	等腰直角三角形（R3）
04	5	6	8	一般三角形（R4）
05	2	3	4	非三角形（R5）
06	7	4	2	非三角形（R5）
07	0	2	3	非三角形（R5）
08	1	4	0	非三角形（R5）
09	-1	3	5	非三角形（R5）

程序流图

二、边界值：由于三角形的边可是整数，也可是小数，无需对长度测试，无需边界值分析。

三、因果图法：三角形的三条边输入值的组合

条件：

C1:A>0

C2:B>0

C3:C>0

C4:A+B>C

C5:A+C>B

C6:B+C>A

C7:A=B

C8:A=C

C9:B=C

C10:A^2+B^2=C^2

C11:A^2+C^2=B^2

C12:B^2+C^2=A^2

动作：

E1：非三角形

E2：普通三角形

E3：等腰三角形

E4：等边三角形

E5：等腰直角三角形

中间结果：

B10：边范围正确

B11：可构成三角形

B12：存在两边相等

B13：三边两两相等

B14：存在两边平方和等于另一边平方和

百度答案：https://wenku.baidu.com/view/2a601f1714791711cc791776.html

因果图

应用场景：输入条件过多时，输入与输出之间的关系，防遗漏

自动售货机，三角形的问题

命题

有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。

分析

根据该命题，我们可以分析出，自动售货机的业务中一共存在5个条件和5个结果，分别是：

条件：

1.售货机有零钱找

2.投入1元硬币

3.投入5角硬币

4.押下橙汁按钮

5.押下啤酒按钮

结果：

1.售货机〖零钱找完〗灯亮 当售货机中没有零钱的时候就有亮红灯

2.退还1元硬币 当投入1元，而且售货机中没有零钱可找的时候

3.退还5角硬币 当投入1元，而且售货机中有零钱可找的时候

4.送出橙汁饮料

5.送出啤酒饮料

因果图－画条件和结果

因果图－画简单关系

在画完空白的条件和结果之后，我们可以将题目中最直接和简单的因果条件标出

1、条件“有零钱”和结果“红灯亮”是一个“非”的关系，当“有零钱”的时候，红灯是不亮的，而当售货机中“没有零钱”的时候，红灯必须要亮的。

2、条件“投1元”和条件“投5角”是一个“E”的关系，这两个动作不可能同时发生，即同时投入1元钱和5角钱（不能同时为真）；但是我们允许即“不投入1元钱”也“不投入5角钱”（可以同时为假）。

3、条件“选啤酒”和条件“选橙汁”是一个“E”的关系，这两个动作不可能同时发生，即同时“选择啤酒”和“选择橙汁”（不能同时为真）；但是我们允许即“不选择啤酒”也“不选择橙汁”（可以同时为假）。

4、条件“选啤酒”和条件“选橙汁”对于程序处理过程是等价的，即二者无论是价格还是系统的处理方法都是相同的，因此这两个条件可以合并为一个中间节点。而且这两个条件之间使用“或”的关系。

5、注意，条件“投1元”和条件“投5角”不是等价关系，表面上看，他们都是“钱”，好像差不多，但是对于程序的处理过程确实完全不同的，“投5角”后完全不用判断当前售货机中是否有零钱（因为题目中规定所有的商品都是5角钱），而“投1元”就不行了。

因果图－送出商品

现在我们从结果的角度考虑，要想“出啤酒”或者“出橙汁”，从现实买卖中分析必须要有什么先决条件呢？是的，就是“你的钱要付清”，而且你一定要选择了“啤酒”或者“橙汁”才行。而在上面的已有因果图中，我们无法找到“钱付清”的因素，因此这时候我们可以试着再加一个中间节点，就叫“钱付清”吧。

要想获得选中的商品，则条件“钱付清”和条件“选啤酒/选橙汁”必须要同时成立，因此是“与”的关系。

因果图－应该找零钱

根据题意，当投入1元钱，而且又选中了某一种商品的时候，系统是需要找零钱的。而现有条件和结果中并没有涉及到“应该找零钱”这种情况，因此我们还需要增加一个中间节点“应该找零钱”。

条件“投1元”和条件（中间节点）“选商品”与结果（中间）“应该找零钱”是“与”的关系，即这两个条件必须同时满足。

因果图－能够找零钱

上面已经确定了“投入1元钱”并且“选商品”，系统应该找给客户5角钱，那么接下来就要看当前售货机中是否有零钱可找了，庆幸的是，存在“有零钱”的条件；

现在系统“应该找零钱”给客户，而且恰恰又“有零钱”找给客户，那么就可以确定系统“能够找零钱”给客户了，所以这里我们又可以增加一个中间节点“能够找零钱”。

条件“有零钱”和条件（中间节点）“应该找零钱”与结果“能够找零钱”之间是“与”的关系。

因果图－1元钱付清

现在已经确定客户“投入1元钱”并且“选商品”后，系统“有零钱”可找，那么紧接着就可以找钱给客户了。

条件“能够找零钱”和结果“找5角”是“恒等”的关系；

条件“能够找零钱”和结果（中间节点）“钱付清”也是“恒等”的关系；

因果图－5角钱付清

考虑完投入1元钱后系统的处理情况，我们再来看投入5角钱后系统是如何处理的。因为售货机中的全部商品都是5角钱的，因此就不存在找零的问题了，只要客户“投入5角”并且按下相应的商品选择按钮就好了。

所以，条件“投5角”和结果（中间节点）“钱付清”直接是“恒等”的关系。

另外，条件“投5角”和条件（中间节点）“能够找零钱”都代表金额的计算已经结束，即“钱付清”，因此条件“投5角”和条件（中间节点）“能够找零钱”与结果（中间节点）“钱付清”之间是“或”的关系。

因果图－退还1元

我们考虑完了投入5角钱及投入1元钱并找零后，最后在考虑一下退还1元钱的情况。毫无疑问，当投入1元钱，并且选择了某种商品的时候，如果当前售货机中没有零钱可找，那么只能退还用户这1元钱了。

因此，条件“没零钱”和条件“应该找零钱”与结果“找1元”之间应该是“与”的关系，而且我们的条件中关于零钱是用了肯定的描述，即“有零钱”，要想表示没有零钱，直接使用一个“非”关就可以了。

判定表

去除无效用例

合并判定表

决策表法

因果图和决策表的区别：

没有太大区别，因果图法强调的是使用图形来分析被测对象的特点，重点在于图形分析四个字。尤其对于逻辑结构比较复杂的测试对象，先用因果图分析，再用判定表来总结因果图，最后写出测试用例，这样下来会很直观，思路会很清晰。当然对于比较简单的测试对象，有时也可以忽略因果图，直接使用判定表。说白了，就是分析的两个步骤，你可以省略第一个步骤，直接做第二步，这些都根据实际的测试情况来运用。

适用情况：输入输出较多，输入之间和输出之间相互制约的情况条件比较多

优点：能把复杂问题按各种情况列举出来，简明而易于理解，可避免遗漏

缺点：不能表达重复执行的动作，例：循环结构

应用：

NextDate函数需求：

NextDate函数输入为month(月份)、day(日期)和year(年)，输出为输入后一天的日期。例如，如果输入为：1964年8月16日，则输出为1964年8月17日。要求输入变量month、day和year都是整数值，并且满足以下条件：

Con1 1≤month≤12

Con2 1≤day≤31

Con3 1900≤year≤2050

答案

条件为：month，day，year

操作为：day加1；day复位为1；month加1；month复位为1；year加1

考虑规则个数：

1． D1：day值在1-27之间（包含边界值）

2． D2：day=28

3． D3：day=29

4． D4：day=30

5． D5：day=31

6． M1：month有30天

7． M2：month有31天（12月除外）

8． M3：month是12月

9． M4：month是2月

1. Y1：year为闰年

11．Y2：year不是闰年

这里有三个条件，每个条件的取值分别为5,4,2，因此规则的个数应为5*4*2=40

正交实验法

就是使用已经造好的表格，正交表来安排实验并进行数据分析的一种方法。（计算表格化，应用好）

应用：平台参数配置或兼容性测试

与因果图的区别：因果图是同类输入当中各元素不可同时发生，而对于不同类的输入之间，每次必须要产生一种情况，这样我们可以将需求中的各项输入分别来组合一遍。这样测试会非常充分，但不可避免的会产生非常庞大的组合数字。

9：最大构成用例数

4：最大分类数

3：各分类下的最大元素数

具体实例见PPT（ 站的兼容性，PowerPoint打印功能不同选择的结果）

场景法：运用场景对系统的功能点和业务流程进行描述。

一般包含基本流和备用流，从一个流程开始，通过描述要经过的路径来确定过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括四种：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

实际应用：银行ATM

设计用例场景：每个经过用例的可能路径，可确定不同的用例场景，从基本流开始，将基本流与备选流结合起来，得到用例场景。

场景1.基本流

场景2.基本流 备选流1

场景3.基本流 备选流1 备选流2

场景4.基本流 备选流3

场景5.基本流 备选流3 备选流1

场景6.基本流 备选流3 备选流1 备选流2

场景7.基本流 备选流3 备选流4

场景8.基本流 备选流4

设计步骤：1.根据说明写出基本流与备选流

2.根据基本流和各项备选流生成不同用例场景

3.对每一个场景生成对应的测试用例

4.对所有生成的测试用例进行复审，去除多余的

5.对每一个测试用例确定测试数据值

白盒测试（也称为结构测试或逻辑驱动测试）

白盒测试需要完全了解程序结构和处理过程，他按照程序内部逻辑测试，检验程序中每条通路是否按预定要求正常工作，也被称为程序员测试

单元测试：白盒测试

针对被测单元内部是如何进行工作的测试，根据程序的控制结构设计测试用例

特点：主要检查程序的内部结构、逻辑、循环和路径

白盒测试可分为静态测试和动态测试

静态测试：代码走查，代码审查……

动态测试：边界值测试（防止数组越界，int类型的范围），逻辑驱动覆盖……

逻辑驱动覆盖

可分为：语句覆盖，判定（分支）覆盖，条件覆盖，判定-条件覆盖，条件组合覆盖

语句覆盖

语句覆盖：比较弱的测试标准。选择足够的测试用例，使程序中每一个语句至少被执行一次

判定覆盖：比“语句覆盖”稍强的测试标准，选择足够的测试用例，使程序中每个分支至少被执行一次

条件覆盖：较强的测试标准。选择足够的测试用例，使得判定中每个条件获得各种可能的取值。

判定条件覆盖：更强。选择足够的测试用例，使得每个条件获得各种可能的取值，每个判定取到各种肯能的结果

条件组合覆盖：更更强。选择足够的测试用例，使得判定条件中的每个组合都至少出现一次。

基本路径测试法

步骤：

1. 根据源程序画出程序流程图和控制流图
2. 根据控制流图计算题目的圈复杂度
3. 找出控制流图中的各条独立路径
4. 根据各条独立路径，设计测试用例

程序的环路复杂度即圈复杂度V(G)（即该程序独立路径的条数）

V(G)=边-节点+2

V(G)=节点+1

V(G)=G中区域的数量

序	路径	测试用例	预期结果
1	4-14	iRecordNum<=0	X=0,y=0
2	4-6-7-14	iRecordNum=1;iType = 0	X=2,y=0
3	4-6-9-10-13-4	iRecordNum=1;iType = 1	X=10,y=0
4	4-6-9-12-13-4	iRecordNum=1;iType = 2	X=20,y=0

软件缺陷

满足以下5个规则之一，称为缺陷

1. 软件未实现产品说明书中要求实现的功能
2. 软件实现了产品说明书中未要求的功能
3. 软件出现了产品说明书中指明不该出现的错误
4. 软件未实现产品说明书中虽未明确提及但却应该实现的功能
5. 软件不易使用，难理解，运行缓慢或者最终用户认为不好

软件缺陷-严重性

Fatal：致命错误，造成系统或应用程序崩溃，死机，系统悬挂，或造成数据丢失，主要功能丢失等

Critical：严重错误，主要指功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明

Major：主要错误，这样的错误虽然不影响系统的使用，但没有很好的实现功能，没达到预期效果。如提示信息不太准确，或用户界面差，操作时间长

Minor：一些小问题，对功能几乎没有影响，产品及属性仍可使用

Suggestion：一些友好建议

缺陷级别定义

A类bug：

Blocker级-阻塞、倒闭：必须立即解决，根据情况可以要求项目组立即发布版本，导致开发或测试无法进行，或程序无法运行

严重级：导致系统崩溃，数据丢失，严重系统资源泄漏等，关键功能缺失或错误

B类bug：

关键级：功能缺失或错误，界面关键信息的错误

C类bug：

次要级：界面非关键信息的错误

D类bug：

易用级：使用不方便的问题

缺陷优先级用A-D或者1-4表示，A（1）表示最高级，D（4）表示最低级

最高优先级：立即修复，停止进一步测试

次高优先级：在产品发布之前必须修复

中等优先级：如果时间允许应该修复

最低优先级：可能会修复，但也可能不修复

一般情况：严重程度高的，优先级高

特殊情况：不成正比

严重情况与优先级无必然联系

缺陷生命周期：测试人员提交缺陷 告，开发人员处理缺陷 告，测试人员回归测试，关闭缺陷 告

单元测试（使用白盒测试法）

需求分析说明书——>概要设计说明书——>详细设计说明书——>源程序代码

系统测试 集成测试 集成测试 单元测试

先静态检查代码是否符合规范，再动态检查

单元测试针对每个程序的模块主要测试五个方面：

模块接口，局部数据结构，边界条件，独立路径，错误处理

模块接口：对模块接口的测试，检查进出程序单元的数据流是否正确。需再其他测试前进行。

测试重点：

调用所测模块时，输入参数与模块的形式参数的个数，顺序，属性上是否匹配

所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数，顺序，属性上是否匹配

是否修改了只做输入用的形式参数

全局变量的定义在各模块中是否一致

注：主要关注单元中的输入和输出

局部数据结构

测试模块内部的数据是否能保持完成性，包括内部数据的内容，形式，相互关系不发生错误。

常见错误：

不正确或不一致的类型说明

错误的初始化或默认值

错误的变量名，如拼写错误或书写错误

上溢，下溢或者地址错误

注：主要关注与被测单元内部相关的数据的类型

路径测试

针对程序路径进行测试，尤为重要。主要关注由于计算错误，不正确的判定或不正常的控制流而导致的错误

常见问题：

误解的或不正确的算数优先级，混合模式的运算，错误的初始化，精度不够精确，表达式的不正确符 表示，不正确的或不存在的循环终止，当遇到分支循环时不能退出，不适当的修改环境变量

主要关注：程序的逻辑分支问题

边界条件

采用边界值分析法设计测试用例，重点关注程序边界处

注：主要针对程序中的边界问题

出错处理

重点关注模块在工作中发生错误时，出错处理设施是否有效。

常见错误：对运行发生的错误描述难以理解

所 告的错误与实际遇到的错误不一致

出错后，在错误处理之前就引起系统的干预

例外条件的处理不正确

提供的错误信息不足，以至于无法找到错误的原因

注：主要针对程序中的错误提示

单元测试的执行过程

单元测试时，如果模块不是独立的程序，需要设置一些辅助测试模块

辅助测试模块类型：

驱动模块：用来模拟被测模块的上一级模块，相当于被测模块的主程序，用来接收数据，将数据传给被测模块，启动被测模块，并打印出相关结果

桩模块：用来模拟被测模块工作过程中调用的模块，他们一般只进行很少的数据处理

如何进行单元测试或白盒测试：

直接使用mian函数调用测试代码

借助测试工具执行测试代码

单元级测试工具：C++Test，JUnit，NUnit

集成测试

测试内容：单元间的接口，及集成后的功能

重点关注：数据穿越接口是否丢失

一模块是否会破坏另一模块的接口

子功能组装是否达到所要求的主功能

全局数据结构是否出问题

误差积累问题

黑盒+白盒=测试技术

非增量式+增量式=测试形式

非增量式测试：采用一步到位的方法来构造测试

优点：节省时间

缺点：一次集成模块较多时，容易出现混乱

故障定位和纠正困难

新旧故障混杂，难上加难

增量式测试：采用逐步集成方法实现测试

增量集成测试的三种方式：

自顶向下增量式测试：深度优先，广度优先

主控模块：即关键模块

主控模块特征：（至少具备其一）

满足某些软件的主要需求

在程序的模块结构中位于较高层次（高层控制模块）

较复杂，较易发生错误

有明确定义的性能要求

（在回归测试中也应集中测试关键模块的功能）

自顶向下集成测试过程：

主控模块作为驱动模块，根据集成方式，下层桩模块一次一次被逐步替换为真正的模块

在模块集成时必须进行单元测试

自顶向下集成测试方式：

深度优先：首先集成在结构中的一个主控路径下的所有模块

主控路径选择任意

广度优先：首先沿着水平方向，把每一层中所直接隶属于上一层的模块集成起来，直到底层。

自底向上增量式集成

混合增量式测试：自顶向下测试+自底向上测试

常见的两种混合增量式测试方法：

衍变的自顶向下：首先对输入输出模块和引入新算法模块的测试

自底向上-自顶向下：含读操作：自底向上，含写操作：自顶向下

非增量式测试：先分散再集中

若在模块接口处存在错误，只在最后集成测试时一下子暴露，修改难度大

增量式测试：逐步集成和测试

差错分散暴露，一些模块得到较多次的考验

不同集成方式方法的比较

自顶向下增量式测试：

优点：自然的做到逐步求精，开始就能看到系统的框架，发现上层接口错误，不需要驱动模块

缺点：需要提供桩模块，低层关键模块中发现错误较晚，在输入/输出模块接入系统以前，在桩模块中表示数据有些困难

自底向上增量式测试：

优点：工程实践中常用的方法，可发现低层模块错误。由于驱动模块并模拟了所有要调用的参数，即使数据流并未构成有向