目录

一、软件测试的⽣命周期

二、BUG

2.1 bug的概念

2.2 描述bug的要素

2.3 bug级别

2.4 bug的⽣命周期

💡2.5 与开发产⽣争执怎么办（⾼频考题）

---

💡 推荐

前些天发现了一个巨牛的人工智能学习网站，通俗易懂，风趣幽默，忍不住分享一下给大家。点击跳转到网站

---

一、软件测试的⽣命周期

💡软件测试贯穿软件的整个生命周期

各阶段具体内容：

测试人员不仅要具备开发能力，测试能力，最好具备一定的产品分析能力

测试执行结束后，不能认为项目100%的问题都被发现了，问题是不可能被完全发现的

上线：

学习中，本地写的代码提交到码云/部署到服务器上，可以称为一个上线流程

实际在工作中，上线要分为多个步骤：沙盒，小流量，全流量，全上线

沙盒：企业内部的线上环境，可以供内部人员进行测试

小流量：部分线上真实的用户可以使用到，测试人员要在线上手动测试，还要观察有没有错误日志（真实用户在使用过程中是否出现了问题）

全流量：所有的真实用户都可以使用到

因为上线的过程中可会存在问题，线下测试没有问题，如果直接推到线上可能会发现问题

线上环境和线下环境并不是完全一样的，因此每一步都需要跟进测试

---

二、BUG

2.1 bug的概念

定义：⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错误

💡准确来说：

（1）当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误

（2）当需求规格说明书没有提到的功能，判断标准以最值的用户为准；当程序没有实现其最终用户合理预期的功能要求时，就是软件错误

---

2.2 描述bug的要素

|为什么描述bug还有要素要求？

在⼼理学上说，⼈们在编写⽂档的时候，经常会出现⾃⼰想表达的和写出来的内容往往南辕北辙

|错误的bug描述：浏览器打开链接失败

该描述下，没有明确说明哪个浏览器，失败的具体表现是什么，对于开发⼈员来说⽆法捕捉到更多有效的信息，会造成沟通效率低下，⼯作质量低下等问题

💡描述bug的基本要素：问题出现的版本，问题出现的环境，问题出现的步骤，预期结果，实际结果

bug的基本要素包含但是不仅限于这些

例子：

1.问题出现的版本：版本124.0.6367.202(正式版本）（64位）【浏览器的版本，软件产品的版本】

2.问题出现的环境：window系统的版本xxx 【产品的运行环境】

3.问题出现的步骤：

（1）打开谷歌浏览器

（2）输入网址：http：//xxxxx

（3）找到登陆窗口

|上面都是通过具体信息来还原bug

4.预期结果：二维码没有被遮挡，可以微信扫描添加二维码用户 【复现bug】

5.实际结果：二维码被遮挡，微信无法添加二维码用户

---

2.3 bug级别

|为什么要定义bug级别？

(1)评估程序员的开发能力

(2)年终奖

(3)给bug修复顺序排序

💡bug级别⼀般分为：崩溃、严重、⼀般、次要

崩溃	严重	⼀般	次要
阻碍开发或测试⼯作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发⽣死锁、重要的⼀级菜单功能不能使⽤等（该问题在测试中较少出现，⼀旦出现应⽴即中⽌当前版本测试）。	系统主要功能部分丧失、数据库保存调⽤错误、⽤⼾数据丢失，⼀级功能菜单不能使⽤但是不影响其他功能的测试。功能设计与需求严重不符，模块⽆法启动或调⽤，程序重启、⾃动退出，关联程序间调⽤冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显⽰错误，⽤⼾所要求的功能缺失，程序接⼝错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。	功能没有完全实现但是不影响使⽤，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间⻓、查询时间⻓、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）	界⾯、性能缺陷，建议类问题，不影响操作功能的执⾏，可以优化性能的⽅案等。如：错别字、界⾯格式不规范，⻚⾯显⽰重叠、不该显⽰的要隐藏，描述不清楚，提⽰语丢失，⽂字排列不整⻬，光标位置不正确，⽤⼾体验感受不好，可以优化性能的⽅案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

---

2.4 bug的⽣命周期

测试⼈员在执⾏测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug（bug⽣命起

源），创建好的bug需要被开发⼈员修复，以及测试⼈员的持续跟踪和测试

---

💡2.5 与开发产⽣争执怎么办（⾼频考题）

（1）先检查自身，是否bug描述的不清楚

反省自己：是不是在测试的时候出现了误操作，bug描述是不是没有写清楚

（2）站在用户的角度并抛出问题

功能正常只是测试的一部分，还需要考虑用户的使用感受，如果你是用户，你能接受这样的界面/功能/使用吗？

（3）BUG定级要有理有据

bug定级描述文档拿出来，然后将bug的表现和bug定级描述文档进行匹配，说服程序员

（4）提⾼⾃⾝技术和业务⽔平，做到不仅能提出问题，最好也能给出解决⽅案

但是给出解决方案一定不要以命令的口吻要求开发人员按照自己的逻辑来修改

测试小白：更多的是提出问题（bug）

测试大牛：除了提出问题也能够定位到问题，给出解决方案

（5）bug评审

如果确实是bug，友好沟通不能解决问题，那么就召开bug评审

bug评审主要解决两个问题：

|（1）决定如何处理bug

|（2）分析缺陷产⽣的原因，找出预防的对策

bug评审⾄少需要项⽬组各个⽅⾯的代表参加：

1）测试代表

测试代表主要从Bug的具体表现、严重程度等⽅⾯提供信息，并提出⾃⼰对Bug的处理意⻅。需要注意的是，测试⼈员不应该⼀味地要求对Bug进⾏修改，因为修改可能带来回归的⻛险，同时带来的是回归测试的⼯作量，如果时间⽐较紧迫，修改后剩余的时间若不⾜以做⼀次有效的回归测试，可能不修改是个明智的选择。

2）开发代表

开发代表主要从修改缺陷的难度和⻛险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的⻛险等，如果决定要修改，还要讨论出修改的初步⽅案。

3）产品代表

产品代表主要从产品的整体计划、⽤⼾的要求等⽅⾯对缺陷的修改必要性、缺陷修改的时间和版本提出⾃⼰的意⻅