一、软件测试的生命周期（软件测试的流程是什么？）

需求分析——测试计划——测试设计/开发——测试执行——测试评估

需求分析对需求进行合理化筛选，分析需求对需求明确细化

测试计划： 测试进行的人员、时间、测试范围、测试目的等具体进行计划

测试设计/开发： 根据需求提炼出的功能点开发测试用例

测试执行 执行测试用例 找BUG 回归测试

测试评估 评估本次测试的情况

二、如何描述一个BUG？

首先BUG就是和需求分析说明书中不匹配的功能，我们在实际测试中就需要将测出来的BUG记录在BUG管理工具（禅道，tapd,jira）里,以便开发人员查看，为了能让开发人员更能清楚的了解到BUG，我们就要规范书写BUG，包含以下内容等

（1）测试版本

（2）测试环境

（3）测试步骤

（4）实际结果

（5）预期结果（和需求一致）

（6）其他附件（错误截图，错误日志等）

BUG的级别：

一. 严重问题（Blocker）

定义： 不能完全满足系统要求，系统停止运行，系统的重要部件无法运行，系统崩溃或挂起等导致系统不能继续运行。修改优先级为最高，该级别问题需要立即修改。

系统崩溃

导致程序重启,死机或非法退出

死循环

数据丢失或异常

数据通讯错误。

硬件故障，系统悬挂

二. 高级问题（Critical）

定义： 严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，系统无法满足主要的业务要求，性能、功能或可用性严重降低。 修改优先级为高，该级别需要程序员尽快修改。

功能不符合用户需求

数据计算错误

业务流程错误

程序接口错误

因错误操作迫使程序中断；

系统可被执行，但操作功能无法执行（含指令）；

功能项的某些项目（选项）使用无效（对系统非致命的）；

功能实现不完整，如删除时没有考虑数据关联；

功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用，对数据库的操作不能正确实现。

三. 中级问题（Major）

定义： 系统可以满足业务要求，系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。

修改优先级为中，该级别需要程序员修改。

数据长度不一致

内容或格式错误

响应时间较慢

功能性建议

提示信息不太准确

操作界面错误（包括数据窗口内列名定义、含义是否一致）；

简单的输入限制未放在前台进行控制；

虽然正确性不受影响，但系统性能和响应时间受到影响；

不能定位焦点或定位有误，影响功能实现；

增删改功能，在本界面不能实现，但在另一界面可以补充实现。

四. 低级问题（Minor）

定义： 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题修改优先级为低，该级别需要程序员修改或不修改。

界面不规范；

辅助说明描述不清楚；

输入输出不规范；

长时间操作未给用户提示；

提示窗口文字未采用行业术语；

可输入区域和只读区域没有明显的区分标志；

必填项与非必填项应加以区别；

滚动条无效；

键盘支持不好，如在可输入多行的字段中，不支持回车换行；

界面不能及时刷新，影响功能实现。

三、测试用例的设计方法

首先从整体的角度设计分析测试用例（基于需求），验证需求的正确性和合理性，分析需求，细化需求，从需求中分解出测试项，根据测试项找出功能，进行测试用例的编写。

3.1 等价类

等价类就是把输入划分成若干个等价类，从每一个等价类中取出一个测试用例，如果这个测试用例能够通过，那么我们就说这个
测试用例代表的等价类测试通过。

有效等价类： 对于程序规格说明来说，是合理的，有意义的输入数据构成的集合。

无效等价类：对于程序规格说明来说，是不合理的，无意义的输入数据构成的集合。

设计测试用例时，要同时考虑有效等价类和无效等价类。

适用场景： 测试用例过多，无法一一进行测试。

3.2 边界值法

针对输入输出的边界值进行测试的一种黑盒测试用例，通常情况下边界值法是对等价类方法的补充

在平时测试中得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。边界值分析法的测试数据必须在等价类的边界值附近选取；边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

例如 我们需要购买3000元以下的耳机 通过等价类和边界值法就可以得出：

有效等价类：小于3000元；

无效等价类：大于3000元；

边界值 就是 2999元 3000元 3001元。

3.3 因果图法

当输入很多，并且不同的输入组合对应着不同的输出，这种场景就利用因果图法来分析不同输入组合和输出之间的对应关系。

因果图就是逻辑图 ，其中包含与或非恒等

因果图法设计步骤：

1. 分析出所有输入和输出之间的关系；

2. 找出输入和输出的关系；

3. 画因果图；

4. 根据因果图画判定表；

5. 把判定表转换成测试用例；

一定要要将所有结果写出来。

3.4 场景设计法

现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流,
该方法可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,使测试用例更容易理解和执行。

这里我们举个详细的例子来介绍场景设计法：

ATM机上取款 ： 插卡——输入密码——选择取款业务（输入钱数）——取款 主要功能，核心流程

（1）插卡 ：卡插反了，差错卡了，卡正确但是消磁了，卡冻结了，里面有上一个人的卡插不进去 —— 插入正确的卡

（2）输入密码： 密码位数不够，密码输入错误，密码输入错误达到上限， —— 密码输入正确

（3）选择取款业务（输入钱数）： 选错业务 ， 输入钱数大于卡内余额，输入钱数大于ATM机内余额，累计取款额数达到今日上限，超过每次取款上限，超过每天取款次数限制——正确钱数

（4）取款： ATM吐出来少钱，多钱， ATM吐出钱有破损 ，ATM是否吐钞，超过超时没有取出来

ATM 机 的断网 断电等异常

插卡插反了，但是第二次插正确了，仍然可以正常取钱

卡注销/冻结 无法正常取钱，会给用户提醒，“卡已注销”

密码第一次输入错误，但是第二次输入正确也能进行取钱操作

密码输入三次错误，账户被冻结 无法取钱，

即我们利用场景法设计测试用例时，先把主要的功能，核心流程列出，之后再进行细化来根据场景描述测试用例。

3.5 正交排列法

正交排列法引入就是解决因果图法测试用例太多的问题。正交试验设计是研究多因素多水平的一种设计方法,它是根据正交性,
由实验因素的全部水平组合中挑选出部分有代表性的点进行实验,通过对这部分实验结果的分析了解全面试验的情况,找出最优的水平组合,
正交试验设计是一种基于正交表的,高效率,快速,经济的试验
根据正交性选出最优的水平组合进行试验，用实验的结果来分析这个测试用例的结果

正交排列法的目的就是为了减少用例的数量，用尽量少的用例，覆盖输入的两两组合

因素数：变量的个数

水平数： 变量取值的最大个数

正交表的构成：

行（（水平数-1）*（因素数+1））和列（因素数）

正交表的性质：

1. 每一列不同数据出现次数一样多；

2. 任意两列各数据组合出现的次数一样多。

正交表设计测试用例的步骤：

1. 找出所有的输入变量个数（确定因素数）；

2. 确定变量的取值，（确定水平数）；

3. 确定正交表的行和列；

4. 根据正交表的性质来填写正交表；

5. 把正交表的每一行对应写成一个测试用例；

6. 补充你认为重要的但是却没有出现再正交表中的测试用例。

根据一个简单例子来熟悉

例子：用户注册邮箱时（用户名，邮箱，密码，确认密码，验证码）

1. 变量数 5 用户名，邮箱，密码，确认密码，验证码

2. 水平数 2 输入 和不输入

3. 确定正交表的行和列 即正交表的列为5，行数为 6

4. 根据正交表的性质来填写正交表

   
   

5. 把正交表的每一行写成对应的测试用例：

（第一行）姓名输入，邮箱不输入，密码输入，确认密码输入，验证码不输入；

（第二行）姓名输入，邮箱输入，密码不输入，确认密码不输入，验证码输入；

（第三行）姓名不输入，邮箱输入，密码输入，确认密码输入，验证码不输入；

（第四行）姓名不输入，邮箱不输入，密码不输入，确认密码输入，验证码输入；

（第五行）姓名输入，邮箱不输入，密码输入，确认密码不输入，验证码输入；

（第六行）姓名不输入，邮箱输入，密码不输入，确认密码不输入，验证码不输入；

6.可以补充重要的测试用例

全部输入和全部不输入

（第一行）姓名输入，邮箱不输入，密码输入，确认密码输入，验证码不输入；

（第二行）姓名输入，邮箱输入，密码不输入，确认密码不输入，验证码输入；

（第三行）姓名不输入，邮箱输入，密码输入，确认密码输入，验证码不输入；

（第四行）姓名不输入，邮箱不输入，密码不输入，确认密码输入，验证码输入；

（第五行）姓名输入，邮箱不输入，密码输入，确认密码不输入，验证码输入；

（第六行）姓名不输入，邮箱输入，密码不输入，确认密码不输入，验证码不输入；

（第七行）姓名输入，邮箱输入，密码输入，确认密码输入，验证码输入；

（第八行）姓名不输入，邮箱不输入，密码不输入，确认密码不输入，验证码不输入；

更复杂的情况下，可以查询（正交表查询）来设计更复杂的正交表

3.6 错误猜测法

根据测试人员的知识、经验和直觉，判断软件哪一部分有问题，专门针对性的设计测试用例

适合作为一种补充设计测试用例的方法

作者：caiyec

原文链接：https://blog.csdn.net/weixin_51601437/article/details/119392085