1. 如何创建Bug

提 Bug 就是要开发人员进行问题的解决 （1. 尝试复现 2. 代码修复）

创建 Bug 的要素：问题出现的版本、问题出现的环境、出现步骤、预期结果、实际结果等

2. Bug的级别

Bug 存在不同的严重级别

不同的 Bug 等级，惩罚机制不一样

不同的 Bug 等级，也跟开发人员的开发质量能力有直接关系

严重级别：崩溃、严重、一般、次要（具体的级别数量，要看当前公司的规范）

1. Blocker（崩溃）：阻塞开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，数据库连接错 误，主要功能丧失，基本模块缺失等问题

2. Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等

3. Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性

4. Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等

3. Bug的生命周期

测试人员在执行测试的过程中，如有发现 Bug，需要在对应的 Bug 管理平台来创建 Bug

• New：测试人员创建了一个 Bug
• Open：开发人员要去确认是否是 Bug，是 Bug 状态就改为 Open，不是 Bug 就拒绝 （rejected）
• Fixed：开发人员在修复完成之后将 Bug 状态改为 fixed
• Rejected：如果认为不是 Bug，则拒绝修改
• Delay：确认是 Bug 之后，如果 Bug 优先级比较低且开发人员不能立即修复 Bug，状态改为 delay
• Closed：Bug 确认修复完成，测试人员将 Bug 改为 closed
• Reopen：Bug 确认修复未完成，测试人员将 Bug 状态改为 Reopen

4. 面试题：跟开发产生争执怎么办

1. 多反思自己，是不是 Bug 创建的时候描述不太清楚
2. 开发人员对 Bug 级别不认可，Bug 定级一定要有理有据，测试人员需要明确企业 Bug 定级规范，拿着规范和开发人员沟通，为什么这样定级
3. 合理友好的进行沟通，站在用户的角度反问，如果你是用户，你能接受这样的功能吗，提 Bug 必定会增加开发人员的工作量，小问题不想解决
4. 不仅能够发现问题，最好也能够提出解决方案给开发参考
5. 如果确实是 Bug，友好沟通已经不能解决问题了，那就召开 Bug 评审，需要有相关的代表来参加：产品代表、开发代表、测试代表等 （1. 如何解决 Bug 2. 如何预防类似的 Bug 再发生）

5. 设计测试用例的万能公式

假如有一个水杯，如何针对这个水杯来设计测试用例

水杯是否保温、能够盛放多少毫升的水、水杯是否漏水、是否易于携带、有没有问题显示功能、是否抗衰…

如果仅仅通过简单直接的思考来设计测试用例，用例是比较少的

原则上用例的设计不仅要考虑其实现了其应该实现的，还要考虑其未实现其不应该实现的

那么测试用例是否是设计的越多越好？

工作中，测试用例能够更多的覆盖项目测试为最好

面试的时候测试用例设计的越多越好，主要就是面试时考察的是设计测试用例的能力，思维发散能力
万能公式：功能测试 + 性能测试 + 界面测试 + 兼容性测试 + 易用性测试 + 安全测试

功能测试：可能来自于需求文档，也可能来自生活经验

性能测试：功能没有问题不代表性能一定是好的，性能往往表现在一些极端情况下

界面测试：颜色、形状、大小、材质、文字、输入框、图片、下拉框… 所有可以看到的元素

兼容性测试：浏览器的兼容性、版本兼容性、系统兼容性、数据兼容性

易用性测试：软件是否具有简单易上手的属性

安全性测试：密码是否加密，数据库里是否对隐私数据加密、SQL注入

使用万能公式对水杯设计测试用例

兼容性测试中需要注意，不同的浏览器，不同的版本可能会有非常多，难道所有的版本和浏览器都需要进行测试吗，我们选型的标准是什么

1. 大部分用户使用的
2. 在工作中是有数据后台可以检测到大部分用户使用到的浏览器/版本/手机型号… 后台可以将这些数据进行检测和管理起来，就可以参考数据管理平台给出的数据选型

6. 设计测试用例的具体方法

6.1 等价类

用户的密码为 6~12 位，测试的时候使用到的测试数据是什么， 10位？8位？

如果使用穷举法 6,7,8,9…12 全部都测试一遍，这样可以，但是如果把密码位数改为 6~1000位，那么穷举法就不行了

可以根据等价类，来划分测试数据

根据需求将输入划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，就认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题

等价类的划分

1. 有效等价类：针对需求文档的要求是有意义的集合 （6~12位密码）
2. 无效等价类：针对需求文档的要求是没有意义的集合 （小于6位，大于12位的密码）

步骤

1. 确认有效等价类和无效等价类
2. 编写测试用例

1. 输入长度为 6~12 位的密码，具体是 10 位
2. 输入长度为小于 6 位的密码，具体是 1 位
3. 输入长度为大于 12 位的密码，具体是 20 位

6.2 边界类

密码长度为 6~12 位，有效边界值为 6、18 ，无效边界值 5、19

边界值指的是 有效边界 + 无效边界

例如：成绩大于 60 可以获奖，无效边界 60，有效边界 61

数字为浮点数，6~10 有效边界值 无效边界值 到底是单精度浮点型还是双精度浮点型

6.3 判定表

使用场景：输入条件的组合对应不同的结果

1. 确认输入条件和输出条件
2. 找出输入条件和输出条件之间的关系
3. 画判断表
4. 根据判定表编写测试用例

案例：假设业务单据的处理规则为：“淘宝618活动，订单已提交，订单合计金额大于300元或有红包，则进行优惠，否则不优惠”。

1. 确认输入条件和输出条件

输入条件：红包(A)、金额大于300元(B)、订单已提交©

输出条件：有优惠(1)、无优惠(2)

2. 找出输入条件和输出条件之间的关系

先确定输出条件之间的可能组合关系：A、B、C、AB、AC、BC、ABC、null

输出条件：A=2、B=2、C=2、AB=2、AC=1、BC=1、ABC=1、null=2

3. 画判断表

4. 根据判定表编写测试用例

1. 有红包，订单金额小于300，不提交订单，则该订单为无优惠订单
2. 无红包，订单金额大于300，不提交订单，则该订单为无优惠订单
3. 无红包，订单金额小于300，提交订单，则该订单为无优惠订单
4. 有红包，订单金额大于300，不提交订单，则该订单为无优惠订单
5. 有红包，订单金额小于300，提交订单，则该订单为有优惠订单
6. 无红包，订单金额大于300，提交订单，则该订单为有优惠订单
7. 有红包，订单金额大于300，提交订单，则该订单为有优惠订单
8. 无红包，订单金额小于300，不提交订单，则该订单为无优惠订单

因果图法相比于判定表法步骤差不多，只不过因果图法中多了一步叫做 “画因果图”

6.4 正交法(allparis)

正交法用的比较少

正交试验设计法指从大量的试验中挑选出适量的、有代表性的点，依据 “正交表” 从而合理的设计出测试用例

地图软件，从出发地到目的地需要耗时多久

因素：下班的高峰期（水平：是高峰期、不是高峰期）、今天不限号、天气、所经路段红灯时间长、地段（城市路段/郊区）、道路施工、行驶人的驾车技能好坏、车况

如果使用判定表，那么当输入条件过多时，出现的情况太多了，那么判定表就不太合适了，这就可以使用正交表

正交表的表示L4（2^3），4代表的是4组实验（4个测试用例），3代表的因素数（3个输入条件），2代表的每个因素数对应的水平数（输入条件的可能选项）

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

1. 找出因素数（输入条件）和水平数（输入条件的可能选项）
2. 生成正交表（需要借助生成正交表的工具：allparis）
3. 根据正交表来编写测试用例
4. 补充可能存在遗漏但是非常重要的测试用例

案例：

1. 找出因素 和 水平

因素：姓名、电子邮箱、密码、确认密码、验证码

水平：填写、不填写

2. 使用 allparis 生成正交表

（1）将水平和因素写入 Excel

（2）allparis 同级目录中创建一个新的 txt 文件（xxx.txt），复制 Excel 中的因素和水平，粘贴到 xxx.txt 文本中，保存（注意格式，间距）

（3）使用 allparis 工具生成正交表 （cmd）

注意：保存正交结构的文件不需要提前生成，可以是不存在的 txt 文件

打开 20230109jg.txt 文件可以看到

利用 allpairs 生成的正交跟实际的正交可能有出入，但仍然不影响我们使用 allparis 生成正交表

3. 根据正交表编写测试用例

1. 全部填写姓名、电子邮箱、密码、确认密码、验证码
2. 填写姓名、不填写电子邮箱、密码、确认密码、验证码
3. 填写电子邮箱、确认密码，不填写姓名、密码、验证码
4. 填写密码、验证码、不填写姓名、电子邮箱、确认密码
5. 填写姓名、电子邮箱、密码，不填写确认密码、验证码
6. 填写确认密码、验证码，不填写姓名、电子邮箱、密码

4. 补充可能存在遗漏但是非常重要的测试用例

7. 全部都不写姓名、电子邮箱、密码、确认密码、验证码

6.5 场景设计法

作用：进行思路引导

基本事件流和备选事件流

编写测试用例：

1. 基本事件流的用例：先插卡，输入正确的密码，选择取款功能 … 退卡

2. 备选事件流：

   1）插入卡之后，卡被 ATM 卡住 … 退卡

   2）插入卡之后，输入密码错误 … 退卡

   …