AI测试 - 产品调研和需求分析

我们通过一个实战项目 hylms ， 完整的把软件项目生命周期经历一遍。

本实战项目 hylms 是一个 企业培训学习、考试 系统。

而你，作为本项目的测试人员，跟着来做一遍，

就会知道在每个阶段测试人员应该做什么，怎么做，

怎么利用AI来提升效率。

这个AI测试实战锻炼项目，特别适合 找工作的应届毕业生 或者 刚入职的测试新手 。

准备工作

AI工具准备

锻炼过程中，我们会 大量使用 AI 开发智能体 来帮我们完成任务。

目前，

国际上比较流行的有： Claude Code ，Codex ， OpenCode ，等等；

国内的有 腾讯的 CodeBuddy， 阿里的 Qoder CN ，智谱的 ZCode ，等等。

这种智能体发展飞快，很难说谁会一直是最好的选择。 选择你喜欢的来完成实战任务。

在实战讲解时，我使用的 AI智能体是 Codex App，国内安装使用方法可以 点击参考我的这篇文章

产品调研阶段

首先，我们来看看产品调研阶段。

产品调研阶段通常是 老板 和 产品经理做的事情，就是调研 想做的产品

• 大体有哪些功能？

• 到底有没有价值？

• 到底能不能做？

我们的 hylms 项目不是先自研产品然后推出去卖的那种。 而是下面的情况：

这个企业 各种内部的流程技能培训非常的多，客户领导决心要做这个系统，来提升员工的培训效率和培训质量。

对方的原始需求很简单，就几句话，如下：

我们需要开发一个企业内部的 培训学习/考试 系统。


- 可以设定企业 部门组织架构，为树状关系

- 用户角色 包含 `管理员` 和 `员工`

  所有员工必须归属一个（或多个）`部门`
  
  每个部门可以设定 一个（或多个） `部门领导`

- `课程` 分为 必修/选修 

- `课程` 可以包含多个 `课时`，每个课时 学完 可以做 `练习考试`

- 课程里面的课时学习内容 是 富文本，可以包含图片，视频， 甚至 word/excel文件

- 管理员可以 `指定哪些员工` 可以 制作课程， 分派课程给员工学习
  
  分派时，可以指定部门，该部门（包括所有子部门）全部被指派学习任务 

- 员工可以在 学习中心 看到被分派的课程， 学习课程， 做练习考试

- 管理员和部门领导可以查看 学习/考试 统计数据， 包括员工的学习/考试情况， 学习/考试的通过率等等。

公司 和 客户 关系比较好， 这些都是常规需求， 没有任何法律法规风险。 当然要做，没啥好说的。

就像在前面的测试流程视频里讲过的, 在 产品调研阶段 ，测试人员通常不会介入

这里，你只要知道，在这个阶段， 领导和你说过 客户原始需求 大体上面说的那样 就行了。

在某些小公司里面，测试也可能会参与到产品调研阶段。

可以把 AI 用在产品调研阶段，来帮你分析竞品，分析用户需求，分析用户痛点，分析用户的反馈等等。

但是这等于是缺人，把你当老板参谋和产品经理来用了。 这种情况很少见，我们就不锻炼了。

决定立项之后，公司 这个项目安排了 一个产品经理， 开发团队3人， 测试团队2人。

需求分析-产品设计 阶段

在这个阶段主要工作是： 产品经理团队设计产品具体的功能 。

产品经理完成后，发给大家评审，提交的 产品功能设计文档 第1版， 点击这里下载查看。

给出的文档格式是markdown格式，大家可以选择你喜欢的工具来查看这个设计文档。

比如在vscode里面preview markdown打开。

个人建议在AI时代文档使用markdown格式这样便于使用AI工具来分析和处理了。

当然如果你们团队就用word或者其他工具来写设计文档，给AI时，使用相应工具转化成markdown格式就好了。

你作为 测试人员主要做： 了解产品需求设计， 评审设计，整理测试需求。

有些公司要求这个阶段，还要出测试计划，甚至测试用例。

但是我觉得这个阶段出 测试计划/测试用例 还为时过早， 因为这个阶段的设计还不够稳定。

在将来开发编码阶段，很可能还会有比较大的变更。

这个时候出 测试计划/测试用例 将来也要跟着改， 反而增加了不必要的工作量。

整理测试需求

为什么要有 整理测试需求 这个工作？ 直接等设计经过几轮 定了， 再根据设计终稿，来编写测试用例不就行了？

因为3个原因：

1. 现实世界中，项目周期都很紧，设计文档往往写的很简陋，甚至没有。

   即使有，往往也是赶出来的，不会被精心维护的。后面设计文档很可能就不更新了， 和实际实现有很大的偏差。

   这时需要测试人员来整理测试需求， 作为后续编写测试用例的依据。

2. 即使终稿写的比较好，往往也不是很适合直接转化成测试用例的。

   测试需求文档是以测试人员角度写的， 以功能点为单位，列出测试需求。

   这种文档已经非常接近测试用例了，最终变成测试用例，往往只需要进行格式转化就可以了。

   设计文档是 以产品经理角度写的，目标是方便大家理解产品设计。

   里面有会有一些内容，用来介绍核心概念（比如本项目中的：核心业务对象）， 以及解释某个重点功能为什么这样设计的说明，

   测试需求文档，不需要这些。

3. 测试需求文档 是一个很好的设计评审工具。 通过整理测试需求， 可以很快的发现设计文档中的问题， 比如功能点不清晰 有矛盾， 有遗漏等等。

了解产品需求设计， 评审设计，整理测试需求，这3个工作其实是紧密联系在一起的，我推荐的做法如下：

• 先读几遍文档，大体弄清楚产品主要功能是什么。

• 然后就开始整理测试需求了，以你认为合适的（看着舒服，容易理解）格式，以功能点为单位，列出测试需求。

  这时可以让AI 来帮你先整理测试需求的初稿， 然后你再人工审阅完善AI整理的测试需求。

  我们先创建测试项目目录，创建2个文件夹 docs/开发文档/ 和 docs/测试文档/，这样项目目录结构如下：

  hylms-testing/
  ├─ docs/
  │  ├─ 开发文档/
  │  ├─ 测试文档/
  

  然后把下载的设计文档 PRD-v1.md 放到 docs/开发文档/ 目录下， 作为输入文档。

  然后，给AI工具提任务，推荐的提示词：

  你是一名资深测试工程师，
  
  根据 `docs/开发文档/PRD-v1.md`  整理一份测试人员角度的 测试需求文档，**以功能点为单位**，列出测试需求。 
  
  要求该文档适合将来作为测试用例的输入文档，进行格式整理，就可以转化成测试用例了。
  所以不需要设计文档中的说明性内容了。
  
  每个功能点下面 要加上 可能影响该功能点行为的数据环境（将来好作为测试用例的前置数据环境）。
  
  整理测试需求的过程中，如果发现设计文档中的功能点不清晰，互相矛盾，遗漏 等问题， 也请你记录下来。
  
  最终保存到 `docs/测试文档/测试需求-v1.md`
  

  AI会根据设计文档，整理出一份测试需求文档的初稿， 你再人工审阅完善这份测试需求文档。

评审需求文档

首次评审

评审需求文档，我的经验是3种方法一起用：

✳️ 1. 整理测试需求

在整理测试需求的过程中， 你会发现有些功能点不清晰，或者有些功能点可能有矛盾，或者有些功能点可能有遗漏。

把这些问题记录下来。

✳️ 2. 对照评审checklist

对照下面这些 评审checklist，到需求文档中对应查看

业务目标与操作场景描述是否清楚？

各个业务操作流程是否合理？能达到完成目标的效果吗？

关键的操作数据对象的 增加/修改/查询/删除 是否描述完整，权限和流程设计是否合理？

不同角色能执行哪些操作是否清楚？这些操作能处理的数据范围是否清楚？

文档是否有性能指标部分 作为 性能测试的需求？

把发现的问题也记录到评审意见文档中，作为你的评审意见，提交给产品经理。

✳️ 3. 使用AI智能体

使用AI智能体来帮你评审这个文档，建议的AI评审提示词：

你是一名资深产品经理，请帮我评审这个需求设计文档: `docs/开发文档/PRD-v1.md`，

评审意见保存到 `docs/测试文档/评审-PRD-v1.md`

请注意：文档中如果有界面示意图，后续很可能调整，因此不要重点评审界面细节。

重点从“业务逻辑是否合理、业务规则是否完整、流程是否闭环、权限是否安全、异常场景是否覆盖、是否存在误操作或风险漏洞”的角度进行评审。

请重点检查以下方面：

1、业务目标与场景是否清楚

* 这个功能要解决什么业务问题？
* 目标用户是谁？
* 使用场景是否明确？
* 用户为什么需要这个功能？
* 是否存在需求目标模糊、业务价值不清的问题？
* 是否能判断这个功能完成后是否达到预期？

2、业务流程是否合理

* 主流程是否完整闭环？
* 每一步的前置条件和后置结果是否清楚？
* 用户从开始到完成业务目标，流程是否顺畅？
* 是否存在流程断点、跳转不明、状态不明的问题？
* 是否存在重复流程、无效步骤、职责不清的问题？
* 是否存在用户做完操作后系统状态没有明确变化的问题？

3、业务规则是否完整
请重点检查文档是否说明清楚，比如：

* 谁可以发起？
* 谁可以审批/处理？
* 谁可以查看？
* 谁可以修改？
* 谁可以删除/取消/撤回？
* 什么情况下允许操作？
* 什么情况下不允许操作？
* 操作后状态如何变化？
* 是否允许重复操作？
* 是否允许撤回、驳回、重新提交、作废？
* 超时、过期、失效后怎么处理？
* 历史数据是否保留？
* 操作记录是否需要留痕？

4、状态流转是否完整
请检查是否存在完整的状态设计，包括：

* 状态是否够用？
* 状态名称是否清楚？
* 状态之间如何流转是否明确？
* 每个状态下允许哪些操作是否明确？
* 是否存在无法结束的状态？
* 是否存在状态冲突？
* 是否存在重复提交导致状态错乱的问题？
* 是否需要状态机表或状态流转图？

5、权限与安全性
请重点检查：

* 不同角色的权限边界是否清楚？
* 是否存在越权查看、越权修改、越权审批、越权删除的风险？
* 是否需要数据权限，例如只能看本人、本人部门、下级部门、全部数据？
* 是否涉及敏感信息展示？
* 关键操作是否需要二次确认？
* 高风险操作是否需要审批、留痕或审计？


6、数据一致性与留痕
请检查：

* 关键业务数据来源是否明确？
* 是否存在多个系统数据不一致的问题？
* 操作成功后哪些数据要变化？
* 操作失败后如何回滚或恢复？
* 是否需要保存历史版本？
* 是否需要操作日志？
* 是否需要审批记录？
* 是否需要状态变更记录？
* 是否需要记录失败原因？
* 用户能否追踪当前进度和历史处理过程？

7、通知与提醒逻辑
请检查：

* 哪些节点需要通知用户？
* 通知谁？
* 通过什么方式通知？
* 通知内容是否明确？
* 通知失败是否影响主流程？
* 是否需要重试？
* 是否需要避免重复通知？
* 是否需要站内消息、企业微信、邮件、短信等多渠道？
* 用户是否可以查看历史通知或处理记录？

8、风险与误操作控制
请检查：

* 用户是否可能误提交、误删除、误审批、误取消？
* 关键操作是否需要确认？
* 是否支持撤销或补救？
* 是否存在不可逆操作？
* 是否需要防重复点击、防重复提交？
* 是否需要限制频率？
* 是否存在业务规则被绕过的可能？
* 是否存在审核流被跳过的可能？

9、性能与稳定性
请检查：
* 业务流程中是否存在明显性能问题？
* 是否存在可能导致系统崩溃的操作？
* 是否有性能指标？例如响应时间、并发量、数据量等？

评审完成后， 你会得到一份AI评审意见文档， 你可以根据这个文档来修改完善（合并你的人工评审意见）， 最后提交给产品经理。

🚩 实战锻炼

实战班学员，根据讲解演示，仿照操作，完成如下任务：

仔细阅读 需求文档初稿 PRD-v1.md ，进行：

• 了解产品需求设计
• 评审设计
• 整理测试需求

假设白月黑羽就是产品经理， 在这个过程中，对需求/设计/开发计划 有疑问的地方， 可以直接找我来沟通。

最后，提交 评审意见 和 测试需求 文档给白月黑羽老师。

再次评审

通常，产品经理团队根据评审意见，修改完善设计文档，然后再让大家评审。

测试团队可以继续评审，再给产品经理修改， 如此循环，直到评审通过为止。

后续评审的方法和第一次评审类似， 你可以继续使用上面提到的3种方法来评审，这里不再赘述了。

本实战项目，我们假定需求阶段 最终定稿的需求设计文档为 第2版： PRD-v2.md（点击可下载）。

这时候，你就可以根据最终版本的设计文档来再次整理测试需求了。

推荐首先让AI帮你产生修改初稿，提示词类似：

你是一名资深测试工程师，

前面你已经根据 `docs/开发文档/PRD-v1.md` 整理了一份测试需求文档 `docs/测试文档/测试需求-v1.md`， 

现在产品经理根据评审意见修改完善了设计文档， 新版本是 `docs/开发文档/PRD-v2.md`。

要求你： 根据 新版本的更新内容， 更新测试需求文档， 保存到 `docs/测试文档/测试需求-v2.md`。

要求该文档适合将来作为测试用例的输入文档，进行格式整理，就可以转化成测试用例了。

每个功能点下面 要加上 可能影响该功能点行为的数据环境（将来好作为测试用例的前置数据环境）。

然后你再人工审阅完善AI整理的测试需求。

🚩 实战锻炼

实战班学员，根据讲解演示，仿照操作，完成如下任务：

仔细阅读 需求文档 终稿 PRD-v2.md，进行：

• 了解更新后的产品需求设计
• 修改测试需求

假设白月黑羽就是产品经理， 在这个过程中，对需求/设计/开发计划 有疑问的地方， 可以直接找我来沟通。

最后，提交 测试需求 文档 给白月黑羽老师。