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

4. 与开发人员起争执怎么办

• 🐧①
  

• 🍎②站在用户的角度抛出问题，反问开发人员，如果你是用户，把这个软件的功能设计成为这个样子你觉得怎么样；
  

• 🐇③ BUG评级要有理有据
  

• ⚽④提⾼⾃⾝技术和业务⽔平，做到不仅能提出问题，最好也能给出解决⽅案

• 🏀⑤BUG评审