一、软件测试生命周期

软件测试生命周期是贯穿软件全流程的测试步骤，核心是通过有序步骤保障产品质量，各阶段目标与交付物明确：

各阶段具体内容：

阶段	核心内容
需求分析	从用户、技术、测试维度验证需求合理性（如业务逻辑是否冲突）
测试计划	制定测试范围、时间、资源、周期等规划
测试设计与开发	参考需求 / 技术文档编写测试用例，明确测试方法、工具、形式
测试执行	利用测试工具全面覆盖测试项，尽可能发现 BUG
测试评估	输出测试报告，确认剩余 BUG 并评估测试完成度
上线	测试人员参与上线实施，跟踪线上环境稳定性
运行维护	参与用户培训，收集试运行问题并反馈相关负责人

二、BUG 相关内容

1. BUG 的定义：指计算机程序中的错误、缺陷等问题，导致程序无法正确运行
2. 判定标准包括：

• 程序与（正确的）规格说明不匹配；
• 未实现最终用户合理预期的功能（需求未明确时以用户为准）。
• BUG 描述的核心要素需包含 “版本、环境、步骤、预期结果、实际结果”，否则会降低沟通效率。
• 案例示例（以 101 教育云网站为例）：

• 版本：谷歌浏览器 123.0.6312.123（64 位正式版）
• 环境：Windows 家庭版
• 步骤：打开谷歌浏览器→输入网址https://www.101eduyun.com/→等待页面渲染
• 预期结果：二维码与登录模块无遮挡，二维码可正常扫描
• 实际结果：二维码被登录模块遮挡，扫描失败

2.1BUG 级别的分类与解读

级别	核心影响	处理优先级	典型场景
崩溃	系统崩溃、数据丢失，阻断测试 / 开发	最高，立即处理	代码逻辑错误、数据库死锁、服务宕机
严重	主功能缺失 / 异常，不阻断其他测试	高，优先修复	用户登录失败、核心业务流程中断、数据计算错误
一般	功能未完全实现，不影响核心使用	中，按计划修复	操作步骤冗余、非核心功能弹窗提示错误
次要	界面 / 体验类缺陷，无功能影响	低，版本后期优化	文字排版错乱、按钮样式不统一、非关键提示错别字

2.2BUG 生命周期核心流程

1. New → 测试人员发现并提交新 BUG
2. Open → 测试负责人确认是有效 BUG，指派开发
3. 处理分支
   • 拒绝修复 → Rejected（需标注原因）
   • 延后修复 → Delay（明确修复版本）
   • 确认修复 → 开发修复后标记 Fixed
4. 验证分支
   • 回归通过 → Closed（BUG 闭环）
   • 回归失败 → Reopen（重新指派开发）

BUG 级别决定了处理优先级（如 “崩溃” 级需立即响应），而生命周期流程则保障了 BUG 的全流程跟踪，避免问题遗漏。

三、测试与开发的争执处理方法

测试过程中与开发的争执（如开发认为 “不是 bug”“级别太高” 等），可通过以下步骤理性解决：

1. 自查 BUG 描述：确保 BUG 信息（版本、环境、步骤等）完整清晰；若表述模糊，需主动向开发解释说明，避免信息偏差。
2. 站在用户角度沟通：向开发强调 BUG 对用户的影响（如 “如果你是用户，能否接受这个问题？”），推动开发重视修复。
3. BUG 定级有理有据：定级需结合 BUG 级别标准 + 用户视角，说明其对业务流程的实际影响，而非仅依赖测试内部标准。
4. 提升技术与业务能力：不仅提出问题，还可给出解决方案（如建议的修改思路），建立专业权威；但需避免强制开发按自己的方案修改。

四、BUG 评审的流程与角色职责

若友好沟通无法解决争执，需召开 BUG 评审，核心目标是确定 BUG 处理方案 + 分析原因并预防，参与角色及职责如下：

角色	核心职责
测试代表	提供 BUG 的表现、严重程度等信息，提出处理意见；同时需权衡修改的回归风险与工作量。
开发代表	评估 BUG 修改的难度、风险、影响范围，若确定修改，需给出初步方案。
产品代表	从产品计划、用户需求角度，判断 BUG 修改的必要性、时间及版本安排。

处理争执的核心是 “以事实和用户价值为依据”，而 BUG 评审则是通过多方协商解决分歧，同时实现问题的根因预防。

五、测试用例的概念

测试用例（Test Case）是实施测试的依据，包含测试环境、操作步骤、测试数据、预期结果等要素；其设计原则之一是 “必须定义预期输出 / 结果”。

5.1测试用例示例（以 “成功注册网易邮箱” 为例）

要素	内容
用例编号	test-01
标题	成功注册网易邮箱
测试方式	手工测试
功能模块	注册登陆
重要性	重要
测试前提	系统运行正常，邮件服务器已开启
测试环境	win10 Chrome 版本 103.0.5060.66（正式版本）（64 位）
测试数据	邮箱地址：996402440@qq.com；密码：123456；手机号：12312341234
测试步骤	1. 打开谷歌浏览器，输入网易注册地址；2. 填写信息 + 输入验证码 + 勾选协议；3. 点击注册按钮
期望结果	显示注册成功页，且账号可正常登录进入邮箱首页

5.2测试用例的必要性

不编写测试用例会导致：

1. 无法确认功能是否被全面测试；
2. 测试覆盖率难以衡量；
3. 新版本回归测试难以高效实施；
4. 冗余测试影响效率；同时，测试用例也可避免测试人员因产品问题被追责。

5.3设计测试⽤例的万能公式

现在有⼀款产品，要求我们对“⻔锁”设计测试⽤例，假如你是测试⼈员，你会怎么设计呢？

⽤例设计最重要的⼀点是保证功能是正确的。上图给出的案例，缺乏经验的同学往往以这样的思路去设计。

5.4测试用例的设计思维

常规思维 + 逆向思维 + 发散性思维

1. 覆盖有效 / 预期输入与无效 / 未预期输入两种场景；
2. 既要验证 “程序做了该做的事”，也要验证 “程序没做不该做的事”；
3. 测试计划中不预设 “不会发现错误”。

测试用例设计的 “万能公式”

通过功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试的维度覆盖测试场景，各维度说明如下： 

测试维度	核心说明
功能测试	验证程序与需求规格的一致性（黑盒操作）；需求不明确时，可通过查文档、参会、评审、用产品、看历史 Bug 等方式补充
界面测试	验证界面与设计要求一致，覆盖界面元素、控件操作等细节
性能测试	验证 “程序做得好不好”（区别于功能测试的 “程序做没做”）
兼容性测试	验证软件在不同环境（如不同系统、机型、浏览器）下的可用性；优先选产品 top 机型、主流环境覆盖
易用性测试	验证产品对新用户的 “易上手程度”
安全测试	验证隐私保护、防 SQL 注入、防越权等安全风险

补充测试类型

除万能公式外，常见的补充测试类型包括：

1. 弱网测试：目的是保障弱网环境下的用户体验，关注关键点：
   • 页面响应时间（热 / 冷启动、页面切换、首屏等）；
   • 页面呈现一致性；
   • 超时文案、异常信息的合理性；
   • 超时重连机制；
   • 安全风险（如 DNS 劫持、IP 频繁更换）；
   • 大流量操作风险（如弱网下更新安装包）。

      2.安装卸载测试（通常验证软件安装 / 卸载的流程、残留等问题）。

1.Fiddler 的弱网相关功能

Fiddler 可用于弱网测试的核心操作包括：

1. 配置代理；
2. 桌面 / 移动端抓包；
3. 构造弱网条件。

2.Fiddler 构造弱网的步骤

通过 “开启弱网设置 + 编写弱网脚本” 实现，具体流程：

1. 开启弱网设置选项打开 Fiddler，通过Rules → Performance → Simulate Modem Speeds勾选，开启弱网模拟的基础开关。

2. 配置弱网脚本（自定义速率）

   • 打开Rules → Customize Rules，进入脚本编辑界面；
   • 在脚本中添加弱网控制代码，示例中通过oSession["request-trickle-delay"]（控制上传速率，单位 ms）和oSession["response-trickle-delay"]（控制下载速率，单位 ms）定义网络延迟，实现弱网环境的模拟。

3.工具说明

Fiddler 是一款常用的 HTTP/HTTPS 抓包工具，除抓包外，其 “弱网模拟” 功能可通过控制请求 / 响应的延迟，还原低带宽、高延迟的网络环境，用于验证软件在弱网下的表现（如响应时间、异常处理等）。