bug的概念
定义：⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错误。
准确的来说：
当且仅当规格说明（需求文档）是存在的并且正确，程序与规格说明之间的不匹配才是错误。
当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误
描述bug的要素
错误案例：这个按钮不好看（按钮是太大了？太小了？颜色？形状？），描述不清晰，不具体，无法通过描述来快速定位问题，可能会提高了沟通成本，降低工作质量
在⼼理学上说，⼈们在编写⽂档的时候，经常会出现⾃⼰想表达的和写出来的内容往往南辕北辙。
描述bug的基本要素：问题出现的版本，问题出现的环境、问题出现的步骤、预期结果、实际结果
问题出现的版本（浏览器的版本、软件产品的版本）：⾕歌浏览器版本 123.0.6312.123（正式版本） （64 位）
问题出现的环境（产品的运行环境）：Windows家庭版
问题出现的步骤：
1、打开谷歌浏览器，输⼊⽹址https://www.101eduyun.com/
2、等待⾸页页⾯渲染完成
预期结果：⼆维码与登陆模块不会出现遮挡，⼆维码可以正常扫描
实际结果：⼆维码被登陆模块遮挡，二维码扫描失败
版本和环境没有强区分，就算把浏览器版本写在环境里也是可以的，只要能够给上关键的信息供开发人员去复现就可以的。
bug级别
- 定义bug的级别的意义在哪里？
程序员A：一周开发了10个bug，存在2个严重bug，5个一般bug，3个次要bug
程序员B：一周开发了10个bug，存在5个严重bug，2个一般bug，3个次要bug
- 评估程序员的开发能力
- 年终奖与bug存在挂钩
- 根据bug的严重顺序进行修复
- 如何定义bug的级别？
男朋友多看了几眼美女：次要
男朋友跟美女加微信聊天：一般
男朋友跟美女私下吃饭：严重
男朋友跟美女去做头发：崩溃！！
bug级别一般分为：崩溃、严重、一般、次要（基础的定义）
| 崩溃 | 阻碍开发或测试⼯作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发⽣死锁、重要的⼀级菜单功能不能使⽤等（该问题在测试中较少出现，⼀旦出现应⽴即中⽌当前版本测试）。 |
| 严重 | 系统主要功能部分丧失、数据库保存调⽤错误、⽤⼾数据丢失，⼀级功能菜单不能使⽤但是不影响其他 功能的测试。功能设计与需求严重不符，模块⽆法启动或调⽤，程序重启、⾃动退出关联程序间调⽤冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显⽰错误，⽤⼾所要求的功能缺失，程序接⼝错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。 |
| 一般 | 功能没有完全实现但是不影响使⽤，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间⻓、查询时间⻓、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多） |
| 次要 | 界⾯、性能缺陷，建议类问题，不影响操作功能的执⾏，可以优化性能的⽅案等。如：错别字、界⾯格 式不规范，⻚⾯显⽰重叠、不该显⽰的要隐藏，描述不清楚，提⽰语丢失，⽂字排列不整⻬，光标位置不正确，⽤⼾体验感受不好，可以优化性能的⽅案等（此类问题在测试初期较多，优先程度较低；在测 试后期出现较少，应及时处理） |
bug的生命周期
测试⼈员在执⾏测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug（bug⽣命起源），创建好的bug需要被开发⼈员修复，以及测试⼈员的持续跟踪和测试。
-
New:新发现的Bug，未经评审决定是否指派给开发⼈员进⾏修改。
-
Open：确认是Bug，并且认为需要进⾏修改，指派给相应的开发⼈员。
-
Fixed:开发⼈员进⾏修改后标识成修改状态，有待测试⼈员的回归测试验证。
-
Rejected：如果认为不是Bug，则拒绝修改。
-
Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
-
Closed：修改状态的Bug经测试⼈员的回归测斌验证通过，则关闭Bug。
-
Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发⼈员重新修改。
-
⽆效的bug：open->closed open-rejected-closed
与开发人员产生争执怎么办？
bug的级别和bug的数量都会影响到程序员的年终奖，所以很多测试人员和开发人员都会因为bug产生争执。
作为一名测试人员，一般会遇到这几类情况：
- 这不是bug
- 这个bug级别太高了
- bug影响不大，暂时不影响
遇到争执不要争吵。
先检查自身，是否bug描述不清楚
反省自己：是不是在测试的时候出现了误操作，bug描述是不是没有写清楚。
站在用户角度考虑并抛出问题
功能正常只是测试的一部分，还需要考虑用户的使用感受。
“如果你是用户，你能接受这样的界面/功能/使用”。
BUG定级要有理有据
bug定级描述文档拿出来，然后将bug的表现和bug定级描述文档进行匹配，说服开发人员
提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案
- 测试小白：更多的是提出问题（bug）
- 测试大牛：除了提出问题也能够定位到问题，给出解决方案
但是这里一定不要以命令式的口吻要求开发人员按照自己的逻辑来修改。
如果开发人员不听建议，就需要进行bug评审
bug评审需要有三个代表：测试代表、开发代表、产品代表
bug评审主要解决俩个问题：
- 决定如何处理bug
- 分析缺陷产生的原因，找出预防的对策，不能重复犯相同的错误
bug评审⾄少需要项⽬组各个⽅⾯的代表参加：1）测试代表：测试代表主要从Bug的具体表现、严重程度等⽅⾯提供信息，并提出⾃⼰对Bug的处理意⻅。需要注意的是，测试⼈员不应该⼀味地要求对Bug进⾏修改，因为修改可能带来回归的⻛险，同时带来的是回归测试的⼯作量，如果时间⽐较紧迫，修改后剩余的时间若不⾜以做⼀次有效的回归测试，可能不修改是个明智的选择。2）开发代表开发代表主要从修改缺陷的难度和⻛险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的⻛险等，如果决定要修改，还要讨论出修改的初步⽅案。3）产品代表产品代表主要从产品的整体计划、⽤⼾的要求等⽅⾯对缺陷的修改必要性、缺陷修改的时间和版本提出⾃⼰的意⻅
