测试--bug篇

软件测试贯穿于软件整个生命周期。

软件测试的生命周期

软件的生命周期：

软件测试的生命周期是指测试流程，这个流程是按照⼀定顺序执行的⼀系列特定的步骤，去保证产品 质量符合需求。在软件测试⽣命周期流程中，每个活动都按照计划的系统的执行。每个阶段有不同的 目标和交付产物

需求分析：产品经理拿着需求文档，开发布计划会议(需求评审)，

测试设计与开发：输出测试设计

测试用例：根据需求文档来写

测试评估：描述清楚测试的进度，项目的整体进度，并做出结论是否具备上线条件

沙盒：沙盒是一个环境，企业内部的线上环境，仅供企业内部工作人员访问的线上环境

小流量：线上的部分真实用户可以访问

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

注意：不同公司的叫法可能不一样

Bug

1、bug的概念

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

准确的来说：

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

规格说明书=需求文档=软件需求

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

2、描述bug的要素

为什么描述bug还有要素要求？         在心理学上说，人们在编写文档的时候，经常会出现自己想表达的和写出来的内容往往南辕北辙         bug描述：浏览器打开链接失败         该描述下，没有明确说明哪个浏览器，失败的具体表现是什么，对于开发人员来说无法捕捉到更多有效的信息，会造成沟通效率低下，工作质量低下等问题。

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

问题出现的版本：软甲的版本

问题出现的环境：不同的游览器，不同的操作系统，不同的手机型号，不同的系统版本等

问题出现的步骤：

问题出现的版本：谷歌浏览器版本123.0.6312.123（正式版本）（64位） 问题出现的环境：Windows家庭版 问题出现的步骤：         1、打开古歌浏览器，输入网址101智慧课堂-您身边的智慧课堂－打造智慧教育生态圈         2、等待首页页面渲染完成 预期结果：二维码与登陆模块不会出现遮挡，二维码可以正常扫描 实际结果：二维码被登陆模块遮挡，二维码扫描失败

3、bug级别

        通过定义bug的级别，能够明确看出问题的严重程度。工作中开发人员通常需要按照bug的级别来分配优先级来处理bug，除此之外，通过bug级别也能够体现出开发人员的开发质量。

案例：

        男朋友多看了几眼美女 ：次要         男朋友跟美女加微信聊天：一般         男朋友跟美女私下去吃饭：严重!!!         男朋友跟美女去做头发：崩溃!坚决踹了!!!!

同样的，bug级别⼀般分为：崩溃、严重、一般、次要

1. 崩溃

• 影响：阻碍开发 / 测试工作的死机、死循环；导致系统崩溃、数据丢失；数据库连接错误；主要功能丧失、基本模块缺失。
• 示例：代码错误、死循环、数据库死锁、重要一级功能无法使用。
• 处理：测试中较少出现，一旦出现立即中止当前版本测试。

2. 严重

• 影响：系统主要功能部分丧失；数据保存错误、用户数据丢失；一级功能菜单不可用（不影响其他功能测试）；功能与需求严重不符；模块无法启动 / 调用；程序重启、自动退出、调用冲突；安全 / 稳定性问题。
• 示例：数据保存后数据库显示错误、功能缺失、程序接口错误、数值计算错误。
• 处理：不影响其他功能测试时，可继续该版本测试。

3. 一般

• 影响：功能未完全实现但不影响使用；功能菜单有缺陷但不影响系统稳定性。
• 示例：操作 / 查询时间长、格式错误、边界条件错误、删除无确认框、数据库表字段过多。
• 特点：实际测试中出现最多。

4. 次要

• 影响：界面 / 性能缺陷；建议性问题（不影响功能执行，仅优化体验）。
• 示例：错别字、界面格式不规范、页面显示异常、提示语问题、文字排版混乱、光标位置错误、用户体验差。
• 处理：测试初期较多（优先级低），后期较少（需及时处理）。

4、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

5、与开发产生争执怎么办（高频考题）

        在测试工作中，最常遇到的是和开发人员的PK，作为测试经理还会和项目经理、产品经理的PK进度、 质量。作为一名测试人员，一般会遇到以下几种情况：

遇到争执不要怕，要理性的分析和反馈问题

5.1 先检查自身，是否bug描述不清楚

 如果能正确的、高质量地录入一个Bug，那么基本上已经成功地与开发人员沟通了一大半的关于Bug 的信息。 但是总有“书难达意”的时候，这时就需要测试人员主动与开发人员进行沟通了。如果测试人员发现在写完一个缺陷后，好像还有很多关于Bug的信息没有表达出来，或者很难用书面语言表达出来时 就应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思， 而不要等待开发人员找自己了解更多的信息。

这个问题容易陷入自我认知正确的陷阱，你认为自己的认知是对的，是从你的思考方向，但是，别人也是会思考的，是否跟你的脑回路一模一样，是无法确定的，我们不能固执己见，认为我是测试我测出来的就是bug，你就要给我改。

切记：一定要有批判性思维，一定要能听取到别人的意见

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

        站在用户角度考虑问题应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么？

5.3BUG定级要有理有据

参考公司的bug定档文档         BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别的，需站在用户的⻆度定考虑定位级别。

5.4提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案

        提高自身的业务和技术水平，不但要做到能提出问题，还能够提出解决问题的思路。这样才能更让人信服。在工作中，你会发现同一个bug，资深测试工程师提出和初级测试工程师提出，两者的结果完全不同，两者最大的差别是资深测试工程师往往会提出解决方案。而长此以往，权威性逐渐的建立起来，那么开发人员看到bug的第一反应，就是这是一个bug，而不是这是一个bug吗？

注：可以给出解决方案，但是不能喧宾夺主，命令式让开发人员按照自己的想法来修改。

这时候就可以说，如果我对开发有一定的理解，我能从开发的角度去思考，思考这个解决方案怎么去解决，如何解决，好解决么。必要么等，这样就大大减少与开发人员的冲突

自我实力过硬，就跟抄好学生作业一样，我是好学生我的作业就问题不大，但是如果给你一份差生，你就会思考，这答案对么，就会顺着找错误，按着自己的理解去改答案，就容易与开发人员产生冲突。

5.5 bug评审

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

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

1）决定如何处理bug

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

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

1）测试代表

        测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注意的是，测试人员不应该一味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是个明智的选择。

2）开发代表

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

3）产品代表

        产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见

这里补充一下，可能会有人去问：为啥开发人员不愿意去修复提交的bug呢？？？

        当然，给自己莫名增加工作量谁都会不高兴，但大家都是成年的牛马了，干这点活没啥，但是，咱们牛马得吃草（工资）呀，年终奖金可是与bug每个级别的数量挂钩的呀，要是严重bug太多或者有崩溃bug，分分钟年终奖泡汤那都是分分钟的事，因此作为测试人员，我们再进行操作的时候更因该严谨、准确！！！