【测试-BUG篇】软件测试的BUG知识你了解多少呢？

文章目录

- - 1. 软件测试的生命周期
  - 2. BUG
  - 3. BUG的生命周期
  - 4. 与开发人员起争执怎么办

1. 软件测试的生命周期

🍎软件测试贯穿整个软件的生命周期；
🍎软件测试的生命周期是指测试流程；

①需求分析
用户角度：软件需求是否合理
技术角度：该需求在技术上是否可行
测试角度：是否存在业务逻辑错误、冗余、冲突等问题

②测试计划
什么时候开发测试、什么时候结束测试、测试多久

③测试设计、测试开发：具体详细的测试流程；
参考需求文档、技术文档等编写测试用例，写测试文档，明确标注使用到的测试工具、测试方法、测试形式

④测试执行
充分利用测试用例和测试工具对项目尽可能做到全方面的测试覆盖

⑤测试评估
测试是否通过，本次测试是否有遗留的BUG，最终测试人员需要产出一个测试报告

⑥上线
项目测试结束后，把项目发布到线上环境，测试人员需要跟踪上线并测试线上环境下软件的运行是否正确

注意：“上线“不是直接将软件推到线上，而是在上线之前，需要经过多个步骤：沙盒（企业内部人员进行测试）、小流量（只推送给部分用户）、全流量、全线上

⑥运行维护
测试人员需要参与项目的实施工作，在试运行项目时收集问题并及时反馈相应负责人

2. BUG

🍎BUG概念：没有实现最终用户合理预期的功能要求；
🐧描述BUG的要素

① BUG出现的版本：Chrome浏览器版本 129.0.6668.71（正式版本）（64 位）
② 环境：windows 11
③ 复现BUG的步骤：1>首先打开 Chrome浏览器；2>输入对应的网址；
④ 预期结果：正常显示，不会出现遮挡情况
⑤ 实际结果：出现遮挡情况
🐇BUG定级
①崩溃(P0)：阻碍开发和测试的问题，造成系统崩溃、死机、死循环；

②严重(P1)：系统主要功能部分丧失，用户数据丢失；

③一般(P2)：功能没有完全实现，但是不影响使用；

④次要(P3)：界面、性能缺陷；

3. BUG的生命周期

<1>测试人员在执行测试的时候如有发现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