Web项目测试流程
- 1.需求分析与评审
- 2.编写测试计划和测试方案
- 3.测试用例设计和评审
-
- 业务测试用例设计
- 单模块测试用例设计（功能+非功能）
- 单模块测试设计难点
-
- 上下级关联条件的组合测试
- [图片上传（大小 + 格式 + 数量）测试](#图片上传（大小 + 格式 + 数量）测试)
- 多条件搜索测试
- 4.测试执行并提交缺陷
- 5.编写测试报告
1.需求分析与评审
评审目的：理解需求，查漏补缺
评审内容：产品需求文档，UI原型图
评审方式：会议
评审人员：产品、开发、测试、其他
评审结果：评审通过没有异议的需求文档
2.编写测试计划和测试方案
目的：确保测试工作的有序进行
测试计划的核心内容
测试计划是管理型文档，描述"测什么，谁来测？"
- 测试目标：最终要达成的要求
Web测试范围：测什么- 功能测试：业务测试、功能模块测试、接口测试、权限测试
- 非功能测试：兼容性测试、易用性测试、安全性测试、性能测试
- 测试角色与职责：什么人干什么事
- 测试进度和资源：花费多长时间，需要哪些资源
- 风险预估和解决方案：可能遇到的风险以及如何应对
- 测试准入准出标准：什么时候开始，什么时候结束
测试方案的核心内容
测试方案是技术型文档，描述"怎么测"
- 测试策略：具体使用的方法，
- 测试环境准备：具体实施需要的测试环境
- 测试工具选择：具体实施测试工作可能需要的一些工具
AI编写测试计划和测试方案提示词
你以测试leader身份，帮我制定一份xxx项目类型的测试计划与测试方案
要求：
1.包含内容：上述测试计划和测试方案核心内容
2.测试范围：覆盖核心业务+核心功能（非功能）；测试时间：xxx个月；测试资源：xxx个人xxx台电脑....
3.测试环境：本地测试环境、预发布环境
4.核心业务主要：xxx业务、xxx业务、xxx业务、xxx业务
输出一份md格式的测试计划与测试方案
3.测试用例设计和评审
测试用例设计遵循先业务场景、后单功能的思路：先通过业务测试覆盖完整业务流程，保证业务闭环可用；再通过单功能测试覆盖各功能点的等价类、边界值与异常场景，保证功能细节无漏洞。
业务测试用例设计
业务测试是以用户视角出发的端到端流程测试，核心目标是：模拟用户真实操作，验证完整业务流程的可用性、正确性，确保业务链路跑通。
开展业务测试主要遵循以下步骤：
步骤一：根据业务流程梳理路径，梳理测试点
在写用例之前，必须先理清业务的流转逻辑。顺着流程图，找出用户操作的主线和各类异常分支，从而梳理出核心的测试点。
流程图来源：
- 产品提供：直接参考产品经理出具的官方原型图或业务流程图，这是最权威、最标准的路径依据。
- 测试自绘：当产品文档不清晰时，测试工程师需要根据对项目业务的理解，自行绘制业务流程图。
步骤二：根据路径编写测试用例
将梳理好的业务路径，转化为测试人员可执行的用例。每一条清晰的业务路径，都对应一条完整的业务用例。不仅要验证正向流程（上传成功、提现成功），还要覆盖反向流程。
示例
下单业务
下单业务分为立即购买和购物车购买两大核心场景，测试遵循「先正向主流程、后异常分支」的原则。
下单业务测试点
业务测试用例的核心是先保证业务能跑通，在此基础上，再针对单个功能点开展单功能测试用例设计，覆盖细节校验。
单模块测试用例设计（功能+非功能）
1.分析需求： 测试目的+测试条件（长度、类型、规则）
2.设计测试点，覆盖需求：
功能：
- 显示：是否正常
- 操作（含规则）：能否成功
- 其他
非功能（B/S)：兼容性、易用性、安全性、性能
3.将测试点转化为可执行的用例文档
4.测试用例评审
5.执行测试用例
6.缺陷管理
示例
登录模块
| UI展示效果 | 需求说明 |
|---|---|
 |
账号：已注册用户名/邮箱/手机号 密码：与账号注册密码一致 其他：点击忘记密码图标跳转至密码重置页面、点击马上注册跳转至注册页面 |
设计测试用例
AI编写测试用例提示词
你以软件测试工程师身份，按照测试用例8要素模版帮我编写测试用例，
要求覆盖上述图中的测试点，输出md格式的测试用例
注意事项：正向业务用例优先级为P0 逆向业务用例优先级为P1
单模块测试设计难点
上下级关联条件的组合测试
先确定上级前提条件，按有效 / 无效拆分；下级仅在上级有效时再拆分，最后组合。
组合策略:
- 全量有效场景：上级有效 + 下级各类有效值组合
- 异常场景：
- 上级无效 + 下级有效值
- 上级无效 + 下级无效值
图片上传（大小 + 格式 + 数量）测试
- 格式
有效：需求支持的格式（jpg/png/jpeg/webp 等）
无效：不支持的格式（pdf/psd/gif/bmp/ 空文件） - 大小
有效：0 < 大小 ≤ 限制值（包含等于限制值、略小于限制值）
无效：大小 = 0KB（空图片文件）、大小 > 限制值（超出上限） - 数量
有效：1 ≤ 数量 ≤ 最大允许张数（包含等于上限）
无效：数量 = 0（未选择任何图片）、数量 > 最大允许张数 - 组合测试规则
上传成功：格式有效 且 大小有效 且 数量有效
上传失败：格式 / 大小 / 数量 任一不合法即失败
格式无效 + 大小有效 + 数量有效
格式有效 + 大小无效 + 数量有效
格式有效 + 大小有效 + 数量无效
任意两项及以上同时无效
全部三项均无效
多条件搜索测试
核心难点：搜索条件多，需要考虑组合场景。
- 单条件测试
针对每个独立搜索条件（按控件类型分为下拉框、输入框、时间选择器等）分别设计用例，覆盖有效值、无效值、边界值；对于文本输入框，同步拆分精确匹配、模糊匹配两种场景，确保单个条件功能正常。 - 多条件组合测试
由于多条件组合场景繁多，重点覆盖两类关键组合：一是不同控件类型（输入框、下拉框、时间选择器等）的双条件组合，二是所有条件同时生效的全条件组合；并且在每类组合中，都同步考虑精确匹配与模糊匹配的场景。 - 异常场景测试
覆盖条件逻辑异常（如开始时间晚于结束时间）、空值组合等场景，进一步完善测试。
4.测试执行并提交缺陷
核心目标：按照用例执行测试，发现缺陷、跟踪缺陷，保障产品质量符合上线标准。
核心工作流程
测试执行
执行前置条件
正式执行测试前，需满足以下条件，确保测试可顺利开展：
- 冒烟测试通过（核心主流程可正常跑通，无严重阻塞问题）
- 严格按照测试计划约定的时间启动执行
- 测试用例、测试环境、测试数据已全部准备就绪
用例执行原则与顺序
- 执行顺序：先业务测试，后单功能测试（先跑通主流程，再测细节）
- 用例执行方式 ：
- 按优先级执行：主业务正向为P0，逆向为P1，单功能正向P2，逆向为P3。先执行 P0 核心用例，再执行 P1、P2、P3 用例
- 按模块重要性逐一执行：优先覆盖核心业务模块，再验证边缘功能
- 逐条执行：严格对照用例步骤操作，避免漏测、跳测
执行结果记录
执行用例后，需按标准标记结果，并留存测试截图、日志等佐证材料，常见执行结果如下。
| 执行结果 | 含义说明 |
|---|---|
| PASS | 测试通过（实际结果与预期结果完全一致） |
| FAIL | 测试不通过（实际结果与预期结果不一致，需提交缺陷） |
| BLOCK | 阻塞（依赖功能未完成 / 环境异常，导致用例无法执行下去 |
| N/A | 不适用（当前用例因需求变更等原因，暂时无需执行） |
为保障测试追溯性，执行用例时建议同步记录以下信息。
| 字段名称 | 填写要求 | 作用说明 |
|---|---|---|
| 测试（执行）结果 | 必填 | 明确用例执行状态，是测试报告的核心数据 |
| 测试版本号 | 建议填写 | 方便后续回归测试，明确缺陷修复的版本范围 |
| 测试人员 | 建议填写 | 明确测试责任主体，避免问题追溯时权责不清 |
| 备注（关联 bug） | 建议填写 | 关联对应缺陷 ID，清晰掌握用例对应的 bug 状态 |
缺陷提交
缺陷提交规范
缺陷核心描述要素
提交缺陷时，需完整覆盖以下核心内容，确保开发能快速定位问题：
- 缺陷的标题：描述缺陷的核心问题，简洁清晰
- 缺陷的预置条件：缺陷产生的前提（如登录状态、商品库存等）
- 缺陷的复现步骤：复现缺陷的完整操作过程，保证可复现
- 缺陷的预期结果：希望得到的正常结果
- 缺陷的实际结果：实际得到的错误结果
- 缺陷的必要附件：图片、日志等证据信息（附件可按需补充）
缺陷提交管理要素
在缺陷管理工具中，需补充以下维度信息，用于缺陷分级与跟踪：
- 缺陷报告编号：缺陷的唯一性标志，用于缺陷追溯
- 严重程度 ：严格按标准标注
- 严重（S1）：主功能异常，阻塞核心业务
- 一般（S2）：次要功能异常，不影响主流程
- 微小（S3）：易用性、界面类问题
- 建议（S4）：优化建议类问题
- 缺陷优先级 ：明确修复时效要求
- Priority 0：24小时之内解决
- Priority 1：发布前必须修复
- Priority 2：可在下一个版本中修复
- Bug类型：标注缺陷所属类别（代码错误、兼容性问题、设计缺陷、性能问题等）
- 缺陷状态：跟踪缺陷生命周期（New:新建、Open:打开、Closed:关闭、Postponed:延期等）
缺陷报告示例
以下为标准缺陷报告模板，可直接参考编写：
以下是生成的表格格式（Markdown）：
| 缺陷 ID | 缺陷标题 | 缺陷状态 | 严重程度 | 优先级 | 所属模块 | 缺陷描述 | 附件 |
|---|---|---|---|---|---|---|---|
| bug1 | 订单支付时，点击去付款无响应，未唤起支付渠道 | new | P0 | P0 | 购买核心业务 | 打开购物网页； 选择商品并加入购物车，完成下单流程； 进入订单详情页，点击「去付款」按钮。 预期结果:页面能够正常唤起支付宝 / 微信 / 银行卡等支付渠道。 实际结果:页面无响应 | 问题截图、操作日志 |
缺陷跟踪管理
- 跟进缺陷 ：
- 每日跟进缺陷管理工具上的缺陷情况
- 优先级较高的缺陷要及时驱动开发进行修复，同步修复进度
- 回归缺陷（回归测试） ：
- 对于BUG状态为「已解决」的问题，及时执行回归测试
- 回归测试时，需保障测试环境已更新修复bug的版本
- 回归范围：覆盖修复的缺陷 + 关联功能，避免修复引入新问题
- 全量回归：版本迭代、重大缺陷修复后，执行全量用例回归，保障整体质量
5.编写测试报告
核心目标：总结测试全过程，评估产品质量，为上线决策提供依据。
核心内容：
- 测试概述：测试范围、测试环境、测试时间、测试人员
- 测试执行情况：用例执行率、通过率、未执行用例原因
- 缺陷统计分析：缺陷总数、缺陷分级占比、缺陷修复率、遗留缺陷说明
- 质量评估：是否符合上线准出标准、产品质量风险评估
- 测试总结与建议：本次测试的经验、后续优化建议、上线建议
AI编写测试报告提示词
你以软件测试工程师身份，帮我编写xxx项目的测试报告
要求：
1.覆盖核心内容：项目概述、测试概述、测试执行情况、缺陷统计分析、质量评估、总结改进
2.项目概述：要求介绍项目类型、核心业务（xx业务、xx业务...）、核心功能（xxx、xxx...）等
3.过程回顾：项目周期xxx个月，测试人员xxx人，电脑和手机、服务器若干，测试环境两套：本地测试环境、预发布测试环境
4.统计分析：用例数xxx条左右，bug数xxx个左右，其中致命bugxxx个，严重bugxxx个，其他中等bug占比约xxx%，剩余其他为轻微bug
5.结果确认中：需要描述能上线的标准，确认能否上线发布
输出：md格式的文档