目录

一软件测试的生命周期

二BUG

1概念

2描述Bug

3Bug级别

4Bug的生命周期

三与开发人员发生争执怎么办

​编辑1先自省：是否Bug描述不清晰 

2站在用户角度考虑并抛出问题

3Bug定级有理有据

4不仅要提出问题，还要给出解决方案

5Bug评审

5.1解决的问题

5.2三种角色

---

一软件测试的生命周期

软件测试贯穿软件的整个生命周期：对于测试人员来说，不仅要具备开发能力，测试能力，还要有一定的产品分析能力来保证产品的质量；

软件测试的生命周期指按照一个系统的流程去执行，确保软件的质量符合需求；以下是具体内容

需求分析	测试计划	测试设计与开发	测试执行	测试评估	上线	运行维护
从用户角度：需求是否合理； 从开发角度：技术上是否可行，是否有优化空间； 从测试角度：需求是否符合逻辑	测试的时间要计划多久	参考需求文档，技术文档编写测试用例； 编写测试文档要明确标注使用到的测试方法，测试手段，测试工具等	利用测试用例与测试工具对软件进行全方位的覆盖测试	测试是否通过？测试是否有遗留的BUG?测试人员要结合测试实际编写一份测试报告	上线分为四步骤：沙盒，小流量，全流量，全线上	测试人员参与项目的实施工作，收集用户问题反馈给相关负责人

所以说：测试执行完成后不能就说软件100%的问题被解决了，有些问题可能很难被发现，需要用户体验一段时间后才暴露出来；

项目测试完成后要把它推送上线，可不是像我们一样就直接push代码到远程机器上就好了：因为一个项目可能是有多个团队共同开发完成的，一同推上面可能会有冲突；再加上线下环境与线上环境的不同，可能线下环境没问题，一上线就会出现各种报错，所以上线分为四步：

• 沙盒：企业内部的内部的线上环境供测试人员测试；
• 小流量：先让一小部分用户进行体验，测试人员除了要线上测试外，还要看是否有错误日志；
• 全流量：全部用户都能使用到；
• 全线上：项目正式推送上线；

二BUG

1概念

• 当且仅当规格说明（需求）是存在并且正确时，程序与规格说明不匹配时就是Bug；
• 当规格说明没有提到的功能，判断以用户为准：程序没有实现用户合理预期的功能也是Bug；

一切以需求出发：来验证产品的特性是否返回用户的需求！

2描述Bug

当出现了Bug后，测试人员也要能很好地描述清楚：

• 问题出现的版本；
• 问题出现的环境；
• 问题出现的步骤；
• 预期结果；
• 实际结果

案例：101智慧课堂-您身边的智慧课堂 

之前（现在修复了）登录以上网站的登录页面时：在ie浏览器上正常，在谷歌浏览器上发现登录旁的二维码被遮挡了，此时如果你是测试人员要怎么跟开发人员描述Bug呢？

直接说：在浏览器上出现页面遮挡二维码的Bug，要马上进行修复！

开发人员此时就登上浏览器后发现没有测试人员描述的情况：你是不是想找茬？

所以此时描述Bug时，我们可以应该这样来描述：

• 问题出现的版本：⾕歌浏览器：123.0.6312.123（正式版本）（64位）
• 问题出现的环境：Windows 家庭版
• 问题出现的步骤：1.在搜索框上输入网站；2.等待网站页面渲染完成；
• 预期结果：二维码没有被遮挡，可以使用微信扫一扫二维码进行登录‘
• 设计结果：二维码被登录页面遮挡，扫描二维码失败！’

尽可能详细清楚去在线Bug出现的场景，给开发人员去复现Bug后进行能及时进行修复

3Bug级别

通过定义Bug级别来看出Bug的严重程度，根据Bug优先级的顺序俩处理Bug；除此之外，Bug级别也决定着你的年终奖的高低：写出几个严重的Bug可能就要就要跟你的奖金说再见了~

• Bug级别一般分为：次要，一般，严重，崩溃；（但并不绝对，具体看公司的Bug描述文档）

次要	一般	严重	崩溃
界面，性能缺陷，建议类问题：如：百度页面的百度一下变成了百度两下；优先度较低	功能没有完全实现但不影响用户正常使用；菜单功能存在缺陷但不影响系统稳定性；如：百度页面的百度一下按钮点击没反应，但可以通过回车键进行搜索；优先级低	系统主要功能部分丧失，数据库保存调用错误，用户数据丢失，一级菜单不能使用但不影响其它功能测试；一般出现较少	严重阻碍开发与测试的工作，造成系统崩溃，死机，死循环，导致数据库数据丢失；出现极少

4Bug的生命周期

当测试人员发现Bug时，要提交到对应的Bug管理平台，对Bug进行持续追踪与测试，确保Bug能被顺利解决掉：这就是一个Bug的生命周期

三与开发人员发生争执怎么办

因为年终奖的利益关系，测试人员与开发人员通常会在Bug问题上发生争执：开发人员认为这不应该是一个Bug；Bug的级别太高了；你是不是故意找一个无效的Bug来增加自己的奖金...面对各种可能的出现情况，测试人员怎么就决定了争执的走向~

1先自省：是否Bug描述不清晰  

• 反省是否对Bug描述不清楚或者是自己误操作；
• 如果发现是自己的原因，在Bug提交后主动去找开发人员解释，而不是等开发人员来找自己

2站在用户角度考虑并抛出问题

• 功能正常只是测试的一部分，还要考虑用户体验感受；
• 如果开发人员不认同，我们可以反问他：如果你是用户，你也接收这样的体验吗？？

3Bug定级有理有据

• Bug定级不仅要参考Bug文档，也要站在用户角度上；
• 开发人员不认可Bug定级时：拿出Bug描述文档与Bug表现进行匹配；

4不仅要提出问题，还要给出解决方案

• 在你的技术能力范围内：可以给开发人员一个解决方案，但不能是以命令的口吻去要求

如果以上措施还得不到解决，接下来就要进行Bug评审

5Bug评审

5.1解决的问题

• 如何处理Bug；
• 分析Bug产生的原因，找出预防对策（不能犯同样的错误）

5.2三种角色

• 测试代表：从Bug的具体表现，严重程度上提供信息，并给出意见；
• 开发代表：从修改缺陷的难度和⻛险等角度分析，给出初步方案；
• 产品代表：从产品计划时间，用户要求等方面，给出意见；

以上便是全部内容，有问题欢迎在评论区指正，感谢观看！