【软件测试】从软件测试到Bug评审：生命周期与管理技巧

一、软件测试的生命周期

软件生命周期

我们知道：软件生命周期（Software Development Life Cycle，SDLC） 是指从软件的构思、开发、维护到退役的全过程。它描述了软件产品从初始阶段到最终废弃的各个阶段及其相互关系。软件生命周期的目的是确保软件的开发和维护过程是系统化、规范化的，以便高效地交付满足需求的高质量软件。

软件的生命周期即：

需求分析 — 计划 — 设计 — 编码 — 测试 — 运行维护

而与之对应的软件测试也有生命周期：

软件测试生命周期

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

各阶段内容

阶段	任务	内容
需求分析	用户角度	软件需求是否合理
	技术角度	技术上是否可行，是否还有优化空间
	测试角度	是否存在业务逻辑错误、冗余、冲突等问题
测试计划	测试计划	何时开发测试，何时结束测试，耗时多久
测试设计与开发	编写测试用例	参考需求文档、技术文档等编写测试用例
	编写测试文档	明确标注使用到的测试方法，测试工具，测试形式等
测试执行	充分利用测试用例和测试工具	上线测试评估，测试是否通过
	项目测试结束后评估	测试人员需求，跟踪上线环境，确保BUG修复
运行维护	测试人员参与项目实施工作	测试人员对产品业务和操作理解较高，沟通表达能力强，可以参与软件的培训，收集问题并及时反馈给相关负责人
	测试报表	产出一个最终的测试报告，确认软件运行是否正确

---

二、Bug

bug 的概念

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

准确的说：

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

bug 要素

在软件测试中，清晰、准确地描述Bug是确保开发团队高效修复问题的关键。以下是描述Bug的核心要素：

1. Bug标题（Summary）

   • 简洁明确：用一句话概括问题本质，避免模糊表述。
   • 示例：
     ❌ “功能不正常”
     ✅ “用户登录时，输入正确密码仍提示‘密码错误’”

2. 环境信息（Environment）

   • 明确Bug出现的具体环境，包括：
     • 操作系统（如Windows 11、macOS Ventura）
     • 浏览器/设备（如Chrome 120、iPhone 14）
     • 软件版本（如v2.5.0）
     • 网络环境（如4G/Wi-Fi）
   • 示例：

     “环境：Android 13, App版本v3.1.2, 华为P50 Pro”

3. 重现步骤（Steps to Reproduce）

   • 分步骤：按顺序列出操作步骤，确保开发人员能复现问题。
   • 示例：
     1. 打开应用，点击"注册"按钮。
     2. 输入邮箱test@example.com，密码123456。
     3. 点击"提交"后，页面卡死无响应。

4. 实际结果（Actual Result）

   • 描述Bug的具体表现（错误提示、界面异常、崩溃等）。
   • 示例：

     “实际结果：点击提交后，页面弹出‘服务器500错误’，且未跳转至首页。”

5. 预期结果（Expected Result）

   • 说明正常情况下应发生的行为。
   • 示例：

     “预期结果：用户成功注册，跳转至欢迎页面。”

6. 严重程度（Severity）

   • 评估Bug对系统的影响：
     • 阻塞（Blocker）：系统完全不可用。
     • 严重（Critical）：核心功能失效。
     • 一般（Major/Minor）：非核心问题。
     • 建议（Enhancement）：优化建议。

7. 优先级（Priority）

   • 修复紧迫性（如P0-P3），通常由项目需求决定。
   • 示例：

     “优先级：P1（需24小时内修复）”

8. 附加信息（Attachments）

   • 日志文件：错误日志或控制台输出。
   • 截图/视频：直观展示问题（如界面错位）。
   • 测试数据：触发Bug的特定数据文件。

9. 其他可选信息

   • 模块/功能：如"支付模块-信用卡验证"。
   • 发现时间：帮助追踪问题周期。
   • 测试人员：便于后续沟通。

---

bug 级别

通过定义 bug 的级别。可以明确看出问题的严重程度。工作中开发人员通常需要按照bug级别分配优先级处理bug。且通过bug级别和数量可以体现出开发人员的代码指令。

可以以以下两种角度对bug进行分级：

1. Severity：从技术影响评估Bug的严重性（开发视角）。
2. Priority：从业务需求决定修复顺序（产品/管理视角）。

1. 按严重程度（Severity）分类

级别	影响范围	示例场景	修复紧迫性
阻塞/致命（Blocker/Critical）	系统完全不可用，核心功能中断	服务器崩溃、用户无法登录	立即修复
严重（Major）	核心功能部分失效	支付失败、数据丢失	高优先级
一般（Minor）	非核心功能问题	次要按钮无响应、UI错位	中优先级
轻微/优化（Trivial/Cosmetic）	界面/文案细微问题	错别字、颜色偏差1px	低优先级

详细的说：

1. 对于阻塞BUG：
   • 阻碍开发或测试工作的问题；
   • 造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单
   • 功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）
2. 对于严重BUG：
   • 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。
   • 功能设计与需求严重不符，模块无法启动或调用，程序重启自动退出，关联程序间调用 冲突，安全问题、稳定性等。
   • 如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）
3. 对于一般BUG：
   • 功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
   • 如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等（该问题实际测试中存在最多）
4. 对于次要BUG：
   • 界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
   • 如：错别字、界面格 式不规范,页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低;在测 试后期出现较少，应及时处理）

2. 按优先级（Priority）分类

优先级	定义	对应场景	关联Severity
P0	必须立即修复	生产环境崩溃、法律合规问题	Blocker/Critical
P1	高优先级，尽快修复	核心功能异常（如订单无法提交）	Major
P2	正常排期修复	非关键功能问题（如辅助按钮失效）	Minor
P3	低优先级，可后续优化	文案优化、控制台警告日志	Trivial/Cosmetic

示例冲突场景

• 低Severity高Priority：

  公司Logo颜色错误（UI问题，但影响品牌形象，需优先修复）。

• 高Severity低Priority：

  老旧浏览器兼容性崩溃（严重但用户量极少，优先级低）。

---

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

---

三、测试时与开发人员意见不统一

测试或开发工作中，测试人员和开发人员之间的battle几乎是不可避免的。测试经理也会和项目经理和产品经理比对进度质量。

• “这个不是bug，是特性”
• “这个bug级别标高了”
• “这个bug不该给我，我不负责”
• “这个暂时没办法修改，评审吧”

这是工作时无法避免的，但遇到这种情况，也一定要理性分析和反馈问题。

Bug 是否描述清楚？

一个正确的、高质量的Bug描述，基本上已经成功地将一大半的Bug信息告知了开发人员。
但描述总会有不那么直观的情况，或是开发人员无法复现场景。所以就需要开发与测试的沟通。

如果测试人员发现在写完一个缺陷后，好像还有很多关于Bug的信息没有表达出来，或者很难用书面语言表达出来时，就应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思:分 不要等待开发人员找自己了解更多的信息。

---

站在用户角度重新思考问题

开发人员对于项目的某些问题或操作可能认为很明确或理所当然，因为是以开发(技术)的视角出发的；而对于用户来说并不一定直观。所以在争论问题时，首先自己要站在用户角度思考bug，随后再让开发人员以用户角度去评判。

Bug 定级要有依据

Bug定级时，既要参考Bug级别，也要靠哦了Bug是否影响流程。即定位Bug时也是要站在用户的角度思考问题。

Bug 评审

如果对于Bug，测试开发双方不能达成共识。此时就需要进行评审。

Bug评审主要用于解决：

1. 判断该问题是否是Bug
2. 决定如何处理Bug
3. 分析问题产生的原因，找出预防对策
4. 对于修复工作量大的， 是否需要转需求

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

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

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

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