【第三章】Bug篇
软件测试的生命周期软件测试贯穿于软件的整个生命周期，具体的软件开发到维护的每一个阶段都需要有测试步骤去包管产风致量。下面简要分析软件测试的具体流程：
[*]需求分析
[*]测试操持
[*]测试设计
[*]测试执行
[*]测试评估
[*]上线
[*]运行维护
https://i-blog.csdnimg.cn/direct/98b5509ef092499b9d8a5e0fc26554b5.png
BUG分级
怎样描述BUG
描述BUG的具体要素：问题出现的版本、问题出现的步骤、预期效果、现实效果
简朴来说就是，谁出现了错误，是怎么犯错的，假如没犯错会怎么样，犯错导致了什么现实效果
比如现在某一个网页上面出现了文字乱码，我们就可以这么描述这个错误：
[*]问题出现的版本：windos下的xxxxxx版本的谷歌浏览器
[*]问题出现的步骤：
[*]打开浏览器并输入网站xxxxx
[*]期待响应后并切换到该网站
[*]预期效果：页面文字清楚没有乱码
[*]现实效果：页面文字出现乱码，极大影响用户体验
BUG分级
通过定义bug的级别，开发人员可以根据优先级来处理bug，除此之外，bug级别也能检测开发人员的开发质量。
具体来说，bug一样寻常分为：崩溃、严重、一样寻常、次要
https://i-blog.csdnimg.cn/direct/9b7322bd071b4b7ab416883f7037f104.png
简朴提炼一下就是：
崩溃：大部门甚至全部主要功能散失、紧张数据大量丢失
严重：部门主要功能散失，数据部门丢失
一样寻常：主要功能正常，部门功能存在缺陷不影响体系稳定
次要：没有功能缺失，但是出现界面缺陷，性能缺陷
BUG的生命周期
当测试人员发现了一个bug，需要先将bug分级并描述，再交给开发人员修复，整个过程需要测试人员追踪且跟进。具体处理流程如下：
https://i-blog.csdnimg.cn/direct/2b45a389aaa249f0b92ac1dcad7d88f2.png
在工作中与开发人员产生辩论怎么办
这是一个很常见的问题，作为测试人员，我们既要包管产品上线后的质量，也要保持与开发人员的积极沟通。有些时间，开发人员可能会不认可测试人员提出的bug,以为bug分级太高了，或者以为一些小bug不算bug从而拒绝改bug。一旦产生了辩论，测试人员需要采取有用的方式来与开发人员进行有用地沟通：
[*]先检查自身是否真的将bug描述清楚。 这个跟测试人员的表达本领有关。
[*]站在用户的角度抛出问题。开发出来的产品终极照旧要被用户使用的，测试人员应该站在用户的角度去描述bug，可以告诉开发人员：假如你是用户，你可以继承吗？
[*]BUG分级要有理有据。BUG定级时不但要思量bug会不会影响流程，也要思量对用户带来的体验。有的时间从程序上来说，某一个bug不会影响主要功能，但是会严重影响用户体验。所以需站在⽤⼾的⻆度定思量定位级别。
[*]最高给出解决方案。假如测试人员能在找出bug的同时再给出合适的解决bug的发起，这样会进步整个开发流程的服从，而且也更让人佩服。
[*]bug评审
假如跟开发人员沟通无效，且测试人员确认bug分级精确，那就可以召开bug评审聚会会议。
bug评审聚会会议主要解决以下问题：
[*]决定如那边理bug
[*]分析bug的缘故原由，订定预防计谋
bug评审需要项目组各个方面的代表到场：
[*]测试代表
测试代表主要从Bug的具体表现、严重程度等⽅⾯提供信息，并提出⾃⼰对Bug的处理意⻅。需要注意的是，测试⼈员不应该⼀味地要求对Bug进⾏修改，因为修改可能带往返归的⻛险，同时带来的是回归测试的⼯作量，假如时间⽐较紧迫，修改后剩余的时间若不⾜以做⼀次有用的回归测试，可能不修改是个明智的选择。
[*]开发代表
开发代表主要从修改缺陷的难度和⻛险出发，思量缺陷修改需要付出的代价，以及可能影响的范围、可能引发的⻛险等，假如决定要修改，还要讨论出修改的初步⽅案。
[*]产品代表
产品代表主要从产品的团体操持、⽤⼾的要求等⽅⾯对缺陷的修改必要性、缺陷修改的时间和版本提
出⾃⼰的意⻅
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]