【第三章】Bug篇

软件测试的生命周期

软件测试贯穿于软件的整个生命周期，具体的软件开发到维护的每一个阶段都需要有测试步骤去保证产品质量。下面简要分析软件测试的具体流程：

描述BUG的具体要素：问题出现的版本、问题出现的步骤、预期结果、实际结果

简单来说就是，谁出现了错误，是怎么犯错的，如果没犯错会怎么样，犯错导致了什么实际后果

比如现在某一个网页上面出现了文字乱码，我们就可以这么描述这个错误：

通过定义bug的级别，开发人员可以根据优先级来处理bug，除此之外，bug级别也能检测开发人员的开发质量。

具体来说，bug一般分为：崩溃、严重、一般、次要

简单提炼一下就是：

崩溃：大部分甚至全部主要功能散失、重要数据大量丢失

严重：部分主要功能散失，数据部分丢失

一般：主要功能正常，部分功能存在缺陷不影响系统稳定

次要：没有功能缺失，但是出现界面缺陷，性能缺陷

当测试人员发现了一个bug，需要先将bug分级并描述 ，再交给开发人员修复，整个过程需要测试人员追踪且跟进 。具体处理流程如下：

这是一个很常见的问题，作为测试人员，我们既要保证产品上线后的质量，也要保持与开发人员的积极沟通。有些时候，开发人员可能会不认可测试人员提出的bug,认为bug分级太高了，或者认为一些小bug不算bug从而拒绝改bug。一旦产生了争执，测试人员需要采取有效的方式来与开发人员进行有效地沟通：

先检查自身是否真的将bug描述清楚。 这个跟测试人员的表达能力有关。
站在用户的角度抛出问题 。开发出来的产品最终还是要被用户使用的，测试人员应该站在用户的角度去描述bug，可以告诉开发人员：如果你是用户，你可以接受吗？
BUG分级要有理有据。BUG定级时不仅要考虑bug会不会影响流程，也要考虑对用户带来的体验。有的时候从程序上来说，某一个bug不会影响主要功能，但是会严重影响用户体验。所以需站在⽤⼾的⻆度定考虑定位级别。
最高给出解决方案。如果测试人员能在找出bug的同时再给出合适的解决bug的建议，这样会提高整个开发流程的效率，而且也更让人信服。
bug评审
如果跟开发人员沟通无效，且测试人员确认bug分级正确，那就可以召开bug评审会议。
bug评审会议主要解决以下问题：
- 决定如何处理bug
- 分析bug的原因，制定预防策略

bug评审需要项目组各个方面的代表参加：

测试代表
测试代表主要从Bug的具体表现、严重程度等⽅⾯提供信息，并提出⾃⼰对Bug的处理意⻅。需要注意的是，测试⼈员不应该⼀味地要求对Bug进⾏修改，因为修改可能带来回归的⻛险，同时带来的是回归测试的⼯作量，如果时间⽐较紧迫，修改后剩余的时间若不⾜以做⼀次有效的回归测试，可能不修改是个明智的选择。
开发代表
开发代表主要从修改缺陷的难度和⻛险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的⻛险等，如果决定要修改，还要讨论出修改的初步⽅案。
产品代表
产品代表主要从产品的整体计划、⽤⼾的要求等⽅⾯对缺陷的修改必要性、缺陷修改的时间和版本提
出⾃⼰的意⻅