『 测试 』软件测试全流程与Bug管理核心要点解析

---

1 软件测试生命周期

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

• 需求分析

  测试前需要对需求进行分析, 分析通常站在三个角度去考虑, 即用户角度, 技术角度以及测试角度;

  • 用户角度

    产品需求是否合理;

  • 技术角度

    技术上是否可行, 是否还有优化空间;

  • 测试角度

    是否存在业务逻辑错误, 冗余, 冲突等问题;

• 测试计划

  当需求分析结束后需要对测试进行测试计划, 即什么时候开始测试什么时候结束测试;

• 测试设计, 测试开发

  当测试计划结束后需要进行测试设计与开发;

  在开发过程中将会有一些文档供测试时参考, 如需求文档, 技术文档等文档;

  通过这些文档对产品设计测试用例;

  同样的在测试过程中需要撰写测试文档, 测试文档中需要明确标注一些内容, 如使用到的测试方法, 测试工具, 测试形式等;

• 测试执行

  测试执行为真正的测试动作, 通过侧测试设计时设计的一些测试用例对产品进行尽可能全方面的测试;

• 测试评估

  通常一次测试结束后不表示产品中不存在任何问题, 因此测试结束后需要对所执行的测试进行一次测试评估, 主要评估本次测试是否存在遗留Bug, 产品是否具备可上线的能力;

  因此在测试评估中, 产品测试人员需要产出一份测试报告;

• 上线

  在上线过程中, 测试人员同样要保持测试;

  通常上线分为几个阶段, 通常为沙盒, 小流量, 全流量以及全线上;

  • 沙盒

    沙盒阶段通常为产品部署在企业内部的线上环境中, 通常该阶段为供内部人员进行测试;

    沙盒环境完全模拟生产环境的配置(如服务器, 数据库, 网络等), 但不予真实用户或数据进行交互, 通常是发布前的最后一道安全防线;

    其目的是验证代码在"类生产环境"中的运行情况(如性能, 兼容性)以避免测试过程中对真实用户产生影响;

  • 小流量

    小流量为将新功能或版本逐步开放给一小部分用户, 如内部员工, 特定地区或随机抽样用户, 通过真实流量验证稳定性;

    主要目的是找出在真实场景中暴露的潜在问题, 通过用户反馈快速调整功能;

  • 全流量

    全流量为在验证小流量阶段无重大缺陷后, 将新版本逐步覆盖全部用户, 但仍保留快速回滚能力;

    主要目的是全面验证系统在真实流量下的承载能力, 同时确保新版本在不同用户群体中的兼容性;

  • 全线上

    新版本完全代替旧版本, 所有用户均能使用新功能或产品, 旧版本代码下线;

    主要目的是完成版本的迭代, 确保所有用户获得一致的体验, 并释放资源(如旧版服务器);

  阶段	用户范围	核心目标	风险控制手段
  沙盒	0 真实用户	技术验证(功能, 性能)	隔离环境, 不影响生产
  小流量	1~10% 真实用户	用户体验验证与问题暴露	快速回滚, 定向用户修复
  全流量	50~100% 真实用户	系统稳定性与兼容性验证	分批发布, 实时监控
  全线上	100% 真实用户	完成版本迭代, 统一用户体验	旧版本备份, 紧急回滚预案

  当产品上线后, 测试人员需要跟踪上线并测试线上环境下的产品是否有其他遗留问题;

  本质原因是线上环境与线下环境不一定是完全一致的, 因此需要持续测试保证产品没有重大问题;

• 运行维护

  在运行维护过程中, 测试人员同样还需要保持测试, 测试人员需要定期回归测试;

  通常情况下, 测试人员对项目的业务与操作需要非常了解, 因此测试人员可以参加与用户使用软件的培训, 在运行项目时收集问题并及时反馈给相关负责人;

  同样的, 通常情况下演示会议都是由测试人员来进行演示;

因此, 实际测试人员需要具备一定的开发能力, 并且具备测试能力, 最好还需要具备一定的产品分析能力;

---

2 Bug

2.1 Bug 的概念

Bug的概念本质上分为两点:

1. 当且仅当规格说明是存在的且正确, 程序与规格说明之间的不匹配的才是错误(Bug);
2. 当需求规格说明书没有提到的功能, 判断标准以用户为准, 当程序没有实现其最终用户合理预期的功能要求时, 就是软件错误;

而上述两点锁提到的规格说明即软件需求/需求文档;

假设需求是设计一个杯子, 需求文档为:

• 杯子的形状是兔子的形状, 需要有兔耳朵, 且杯子是马克杯, 不能有盖子, 杯子需要有握把, 而设计师所设计出来的产品为下图的样子;

  

在产品的需求文档中, 设计师确实有按照设计文档进行设计, 如兔子形状, 水杯握把, 有兔耳, 属于符合产品的需求文档需求, 但不代表完全没有错误, 当规格说明书没有提到的问题时, 则需要站在用户的角度进行考虑;

如: 该水杯的兔耳朵是不是太长了, 无法很好的让用户通过这个水杯喝水, 在使用过程中杯子的兔子耳朵形状将会阻碍用户喝水, 因此这样就能判定为该设计构成Bug;

条件	是否符合	结论
需求文档明确要求	是	设计满足兔子形状, 马克杯, 无杯盖, 有握把等显性需求
用户合理预期	否	用户无法正常使用(兔耳过长导致喝水困难), 违背"杯子需具备可用性"的隐性需求

---

2.2 提出清晰的 Bug

作为测试人员, 再向开发人员提出Bug时必须严谨且清晰, 需要提出Bug所在的基本环境等信息;

若是没有合理的向开发人员提出Bug, 那么将会提高开发/测试过程中沟通的成本, 导致工作质量下降;

一般所提出的Bug需要包含这些要素(一般情况下必须存在下列要素):

• 问题出现的版本

  发现Bug的产品/软件对应的版本;

• 问题出现的环境

  产生Bug时产品/软件的运行环境;

• 问题出现的步骤

  如何复现Bug;

• 预期结果

  产品/软件在该操作下的预期结果;

• 实际结果

  实际上出现的产品/软件与预期不符的现象;

一个简单的例子

假设存在一个页面, 其在浏览器1中所显示的画面为如下:

在右上角存在一个可以用来扫码下载的二维码;

而在浏览器2中所显示的画面为如下:

可以发现, 由于不同浏览器的不同或是其他环境因素导致不仅二维码被遮挡, 同时UI错乱;

而若是单纯的提出Bug时只提到"浏览器显示有问题"这种片面的Bug描述, 开发者无法很好的定位问题所在原因;

Ps: 此处为示例, 单纯的调整缩放比例以展示出类似Bug的效果;

在该例子中, 基本的Bug描述如下:

• Bug描述

  • 问题出现的版本

    Microsoft Edge版本 136.0.3240.64 (正式版本) (64 位)

  • 问题出现的环境

    Windows 11 家庭中文版 22H2

  • 问题出现的步骤

    1. 打开Microsoft Edge浏览器
    2. 输入网址https://cn.bing.com/

  • 预期结果

    UI显示正常, 右上角有二维码可进行扫码下载;

  • 实际结果

    UI布局错乱, 右上角二维码被遮挡;

  Ps: 通常网页没有版本, 因此补充的是浏览器的版本, 若是提出一个软件的Bug则是需要给出对应软件的版本;

通常可根据产品/软件的情况添加其他的要素;

---

2.3 Bug 级别

通常情况下, Bug都是分为等级的, 这与开发过程中的错误日志相似, 如开发过程中的错误日志等级通常为DEBUG, INFO, WARNING与 ERROR, 分别表示为调试日志, 正常日志, 警告日志与错误日志, 其中最严重的日志等级为ERROR, 其次是WARNING;

而对于Bug级别而言, 通常从高到低分为几种, 分别为崩溃, 严重, 一般以及次要(或P0, P1, P2, P3), 不同的公司对于Bug级别的定义可能有细微差异, 但总体框架不会脱离该定义;

通过Bug的级别可以明确的看出问题的严重程度, 通常情况下在工作中开发人员必须根据Bug的等级来区分Bug的优先级从而计划解决问题的先后顺序;

同时Bug级别也能够体现出开发人员的开发质量以及开发能力;

Bug级别	影响范围	典型表现	修复优先级	示例
崩溃	导致系统完全无法运行或核心功能瘫痪, 阻碍开发或测试工作的问题	- 程序崩溃, 闪退, 死机 - 数据丢失或损坏(如用户订单无法保存) - 核心功能完全失效(如登录功能不可用)	最高, 需立即修复	用户点击支付按钮后APP闪退导致交易中断
严重	核心功能部分失效或存在重大缺陷, 但系统仍可运行	- 核心业务流程受阻(如购物车无法提交订单) - 数据计算错误(如金额显示错误) - 安全漏洞(如用户密码明文存储)	高, 需在下一个版本修复	搜索功能仅返回部分结果, 导致用户无法找到商品
一般	次要功能异常或用户体验明显受损, 但不阻碍核心流程	- 非核心功能失效(如个人主页头像无法上传) - 界面错位,文字重叠等UI问题 - 操作提示不明确(如错误提示语模糊)	中, 可排期修复	移动端页面在iOS系统下底部导航栏图标显示错位
次要	轻微体验问题, 不影响功能使用	- 拼写错误, 标点符号错误 - 颜色/字体与设计稿轻微偏差 - 控制台非阻塞性警告(不影响用户端)	低, 可累积后批量处理	页面底部版权信息中的年份未更新为当前年份

通过明确Bug级别, 团队可高效分配资源以能优先解决对用户影响最大的问题;

---

2.4 Bug 的生命周期

在实际工作中, 当测试人员在测试执行期间发现Bug, 需要在对应的Bug管理平台中创建Bug;

所谓的创建Bug也是Bug生命的起源, 而最终创建的Bug将会通过一系列的流程被开发人员修复;

• 主要流程为:

  1. 创建Bug

     当测试人员发现一个Bug后将会在对应的Bug管理平台中创建一个Bug, 即New;

  2. 打开或拒绝Bug

     测试人员所创建的Bug不一定是真实有效的Bug, 也可能是因为误操作导致的错误;

     • 真实Bug

       若为真实Bug, 开发人员将会打开Bug, Bug状态将会流转为Open;

     • 无效Bug

       若测试人员所创建的Bug为无效Bug或是因为误操作导致的Bug, 开发人员将可以拒绝该Bug, 将该Bug状态流转为Rejected;

       根据不同企业的代码管理要求不同, 被拒绝的Bug可能直接成为拒绝状态或是再次流转回给测试人员重新确认;

  3. 判断是否修改

     开发人员打开Bug后将会有两种情况:

     • Bug优先级高/时间充足

       若是Bug的优先级高或者是修复Bug的时间充裕, 开发人员将对Bug进行修复;

       修复好的Bug状态将被流转为Fixed状态;

     • Bug优先级低/时间不足

       若是Bug的优先级不足或是修复Bug的时间不足, 开发人员将延迟修复该Bug;

       延迟修复的Bug状态将被流转为Delay状态;

       但最终Delay状态的Bug也将被修复(延迟修复不代表完全不修复);

  4. 重新测试判断是否被修复

     状态为Fixed的Bug将被测试人员再次审核测试, 通常有两种状态:

     • 未被修复

       若Bug未被修复或是产生了新的Bug, 开发人员需要重新打开修复Bug, 对应的Bug状态将会流转为Reopen;

       修复完成后状态将再次流转为Fixed;

       这个步骤是一个循环;

     • 已修复

       若是Bug已被修复, 对应的Bug状态将被流转为Closed;

  5. 结束

     至此一个Bug的生命周期结束;

---

2.5 作为测试人员与开发人员发生冲突怎么办

• 检查自身Bug是否描述不清楚

  当与开发人员发生冲突时首先需要检查自己所创建的Bug是否存在误操作或描述不清的问题;

  Bug按复现概率分为两种, 分别为必现性Bug和偶发性Bug;

  类型	特点	示例
  偶发性	难以稳定复现, 随机出现, 需要通过调试或日志排查	- 多线程并发时偶尔出现的数据竞争导致界面卡顿 - 特定网络延迟下用户支付请求失败
  必现性	测试步骤固定时100%复现, 容易定位	- 点击"提交"按钮后页面崩溃 - 输入纯数字用户名时系统提示"密码不能为空"错误

  测试人员可能也需要反省自己所创建的Bug是一个偶发性Bug且复现步骤是否未描述清晰;

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

  功能是否正常一般只是测试的一部分, 测试人员不仅需要测试功能是否正常, 还需要站在用户的角度去思考用户的使用感受;

  并且以较好的态度与开发人员进行沟通, 使其进行换位思考, 抛出类似于"如果你是开发人员, 出现这样的问题是否会有不好的使用感受";

• Bug定级需要有理有据

  每个企业在开发过程中有属于当前企业的用于参考的Bug定级手册, 在Bug定级过程中不能无视用于参考的手册随意为Bug定级;

  在测试过程中, Bug的定级不仅需要参考需求文档, 还要站在用户的角度去定级, 这意味着在进行Bug定级时公司内部的Bug定级参考与用户的角度是双方面都要进行考虑的;

  可能作为开发组, 开发人员更加看重功能是否可用以及是否出现重大问题, 但实际上用户的使用体验一样也是作为Bug定级的标准;

• 测试人员提高自身业务水平

  一位合格的测试人员不仅需要提出问题, 同样需要对Bug进行分析, 并尽量提供开发人员Bug思路进行定位, 同时给出解决方案;

  同样的在此过程中, 实际上开发人员与测试人员需要站在同一个角度相互讨论(提出建议)而不是拼的你死我活(不能以命令式的口吻命令开发人员按照自己的逻辑来修改Bug);

• Bug 评审

  在创建Bug之后, 如果确认当前创建Bug无误且未出现上述问题时, 测试人员与开发人员无法统一思想时, 必要时可召开Bug评审;

  Bug评审主要解决两个问题:

  1. 决定如何解决处理 Bug

  2. 分析缺陷产生的原因, 找出预防的对策(预防下次开发过程中出现相同或者类似的错误)

  通常情况下, Bug评审会议时需要三类人员在场, 分别为:

  • 测试代表

    测试代表主要从Bug的具体表现, 严重程度等方面提供信息, 并提出自己的看法与对Bug的处理意见;

  • 开发代表

    开发代表主要从修改缺陷的难度和风险出发, 考虑缺陷修改需要付出的代价, 以及可能影响的范围, 可能引发的风险;

    若确定Bug需要修改后, 还要讨论出修改的初步方案;

  • 产品代表

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

    本质上产品代表参加评审会议的主要原因是, 测试团队与开发团队服务于产品, 因此产品代表的意见同样很重要;