根据一句话，给你编出 prd 来，再编出测试用例，你就说牛不牛

你是不是偷看我工作了，刚刚还在百度：AI 生成 PRD

都很急，急到 忘了物联网、忘了 VR、忘了 5G、忘了元宇宙

公司引入了 GPT3.5，给所有员工使用，没有强制要求去提效。但是不得不说是真好用，安装部署过程出现的各种各样的问题，80% 都能给个解决方案，不仅运维在使用，测试和开发也在使用 GTP 写脚本、还有测试会拿来分析日志的报错的原因

以下是我在公司大模型 ai 助手中的一个测试用例设计的问题，结果可以参考，但是离直接用还有点差距。
这是输入：-------------------------------------------------------------
需求：用户名称长度 4-30 位，支持汉字，大小写字母和数字；用户密码长度为 4-16 位，格式为大小写字母和数字，输入异常时给出文本提示信息。针对此需求设计新增用户的测试用例。

以下是输出：-----------------------------------------------------------
为了确保新增用户时用户名和密码符合需求，并在输入异常时提供正确的文本提示信息，我们需要设计一系列的测试用例。以下是详细的测试用例设计：

用户名测试用例
测试用例 1：用户名长度为 4 位，包含汉字
描述：用户输入长度为 4 位，包含汉字的用户名，验证通过。

前置条件：无

测试步骤：

打开注册页面。
输入用户名 测试用户。
输入符合要求的密码。
提交表单。
预期结果：

系统提示 “用户名设置成功” 或允许继续操作。
测试用例 2：用户名长度为 30 位，包含大小写字母和数字
描述：用户输入长度为 30 位，包含大小写字母和数字的用户名，验证通过。

前置条件：无

测试步骤：

打开注册页面。
输入用户名 Abcdefghijklmnopqrstuvwxyz1234。
输入符合要求的密码。
提交表单。
预期结果：

系统提示 “用户名设置成功” 或允许继续操作。
测试用例 3：用户名长度小于 4 位
描述：用户输入长度小于 4 位的用户名，验证失败。

前置条件：无

测试步骤：

打开注册页面。
输入用户名 abc。
输入符合要求的密码。
提交表单。
预期结果：

系统提示 “用户名长度必须在 4 到 30 位之间”。
测试用例 4：用户名长度大于 30 位
描述：用户输入长度大于 30 位的用户名，验证失败。

前置条件：无

测试步骤

打开注册页面。
输入用户名 abcdefghijklmnopqrstuvwxyz1234567890。
输入符合要求的密码。
提交表单。
预期结果
系统提示 “用户名长度必须在 4 到 30 位之间”。
密码测试用例
测试用例 5：密码长度为 4 位，符合格式
描述 用户输入长度为 4 位且包含大小寫字符及數值之密碼 , 驗證通過

前置條件 無

測試步驟 1 . 打開註冊頁面 2 . 輸入有效長度 (如 : usertest) 3 . 輸入密碼 : aA12 4 . 提交表單

預期結果 系統應當顯示 " 設立成功 " 或允許繼續操作

測試案例 6 : 密碼長度為 16 位且格式正確
描述 使用者輸入長度為 16 且含大小寫字符與數值之密碼 , 驗證通過

前置條件 無

測試步驟 1 . 打開註冊頁面 2 . 輸入有效長度 (如 : usertest) 3 . 輸入密碼 : Abcde12345FGHijk 4 . 提交表單

預期結果 系統應當顯示 " 設立成功 " 或允許繼續操作

測試案例 7 : 密碼長度小於 4 位
描述 使用者輸入長度小於規範 (如: abc ) , 驗證失敗

前置條件 無

測試步驟 1 . 打開註冊頁面 2 . 輸入有效長度 (如 : usertest) 3 . 輸入密碼 : abc 4 . 提交表單

預期結果 系統應當顯示 " 密碼需介於 4 ~16 位之間 "

測試案例 8: 密碼長度超過 16 位
描述 使用者輸入長度超出規範 (如: abcdefghijklmnopqrs ) , 驗證失敗

前置條件 無

*測試步驟 * 1 . 打開註冊頁面 2 . 輸入有效長度 (如 : usertest) 3 . 輸入密碼 : abcdefghijklmnopqrs 4 . 提交表單

*預期結果 * 系統應當顯示 " 密碼需介於 4 ~16 位之間 "

測試案例 9: 僅含小寫字符之密碼
*描述 * 使用者僅含小寫字符且符合規範 (如: abcdefg ) , 驗證失敗

*前置條件 * 無

*測試步驟 * 打開註冊頁面
輸入有效長度 (如 : usertest)
輸入密碼 : abcdefg
提交表單

預期結果 : 系統應當顯示" 必須同時具備大小寫字符及數值 "

測試案例 10: 僅含大寫字符之密碼
描述 : 使用者僅含大寫字符且符合規範 (如: ABCDEFG ) , 驗證失敗

前置條件 : 無

測試步驟 : 打開註冊頁面
輸入有效長度 (如 : usertest)
輸入密碼 : ABCDEFG
提交表單

預期結果 : 系統應當顯示" 必須同時具備大小寫字符及數值 "

測試案例 11: 僅含數值之密碼
描述 : 使用者僅含數值且符合規範 (如:1234567 ) , 驗證失敗

前置條件 : 無

測試步驟 : 打開註冊頁面
輸入有效長度 (如 : usertest)
輸入密碼 :1234567
提交表單

預期結果 : 系統應當顯示" 必須同時具備大小寫字符及數值 "

測試案例 12: 含特殊符號之密碼
描述 : 使用者含特殊符號 (例如:@#%$ 等) 且符合法定規格, 驗證失敗

前置條件 : 無

測試步驟 : 打開註冊頁面
輸入有效長度 (如 : usertest)
輸入密碼 :abc@123 或 ABC#456
提交表單

預期結果: 系統應當顯示" 僅允許由英文字母及數值組成 "

綜合測驗案例 :
案例 13: 正確格式下邊界值分析 - 密码最短与最长情况 :
描述: 测验边界情况, 最短与最长合法组合下能否通过验证 :

前提条件: 无:

测试步骤: 打开注册页 分别输入最短合法组合 (aA12) 和最长合法组合 (A123b456C789d012) 提交:

预期结果: 系统应显示" 设置成功" 并允许继续操作;

综合上述各项正常与异常情境下所需执行操作与其对应期待效果, 能全面检验新增用户过程中所设立帐户名称与密码是否均符合法定规范, 确保系统整体安全性。

想说下 ai 真的没那么智能，我就特别喜欢玩狼人杀，问豆包模型狼人杀基本游戏规则，还是可以说的出来，但是问一些特有的，比如禁天毒是什么意思，不知道就回答不知道嘛，直接给我说禁天毒是禁止白天用毒药，给我一个不是新手的玩家都弄得很懵圈

感觉这才是 AI 的正确作用吧，辅助工作，让人工减少查询资料的时间

我个人不太看好 AI 生成测试用例，AI 精准测试这些方向的。 行业中没听说过有非常成功的案例。 搞这些的成本也很高， 你需要大量的很规范的产品文档和用例文档。 但这些都不是现在的国内公司有精力去搭建维护的。

GPT 直接生成用例一步到位我个人也不太看好: 每个产品, 开发, QA 的水平都不一样, 简单需求还 ok, 复杂需求人理解起来都费劲, 需要反复拉通对齐, 你指望 GPT 能一步输出测试用例属实有些不现实. 我觉得倒不如统一用例格式规范, 让 GPT 来做用例评估, 提高测试用例的覆盖率, 相对来说可靠一些..

这跟之前的 5G 远程医疗，5G 无人驾驶一样，场景不合理且成本高，属于强行赋能，最后都会不了了之

领导一意孤行，主打一个想什么就去做什么。

有，老板已经在鼓励我们去发现工作中的问题，落地 AI 去提效实际工作，已经有同事在跟进调研了

提效了，把你们裁掉。

先等等，等等自动生成 prd，自动根据 prd 生成业务代码先

真是闲的蛋疼

我理解需求提出 -- 需求细化为精准需求 -- 排期落地为开发设计稿 -- 再进行测试设计以及用例编写，前面三步都是不同的处理方式，你不可能说需求提出就直接变用例，我就算 AI 现在已经非常强这些都能做，至少这几步你得让 AI 分别进行吧。就像起楼一样，你不可能说你喜欢这栋楼的 3 楼，就只要 3 楼不要 1、2 楼吧。

为啥不先自动跑出去做市场调研，再自动设计产品……或者直接自动印钱

AI 的话最好在公司内部署一套大模型，用网上的再好用，也会泄露公司隐私和内部资料以及代码的，不安全

印钱咋说？ 我负责搞定无酸纸

AI 再厉害，用例还是人工执行和协调的，情况没变

印钱会导致通货膨胀，这不是资本想要的。资本想要的是少投入，高产出，用 AI 代替所有人工做的事，想把整条软发产品线都替换掉。

只需要人工执行其实就说明可能业务只需要外包出去就行了，复杂的设计都被解决了的话

AI 写用例这一套目前有很大的问题：

1. 上下文理解问题。单纯一篇 PRD，一些内部共识的信息很大概率会在脑子里自动补全而不体现在文档中，这部分不告诉 AI 就会生成的很差，轻则用例缺漏，重者驴唇不对马嘴。尝试过接入历史需求、历史用例和历史缺陷，但是又碰到信息过时、场景描述上的省略等等问题，花了很多时间去学习 RAG 相关的知识，然后又花了很多时间去优化，最终效果都很差，反而小伙伴怨声载道。从最开始的积极配合到疑虑重重再到最后消极怠工。
2. 二次评审问题。既然 AI 一次性生成的效果总是难以做到非常好，那我们后面暂行了一个评审 AI 用例的流程。现在事后看来，效果也很差。阅读 AI 写的用例，总会有一种坐副驾驶位上的昏睡感，会导致自己看 AI 生成的用例时难以投入，一些细节错误没发现、该增加的用例没评审到等等问题。甚至本来还算顺畅的用例评审都遭到了各个开发的投诉，说的结结巴巴，甚至要临时调整，完全没有评审自己写的用例时流畅。
3. 维护问题。这个问题我们没有实际经历过，但是在做的时候就有预想。每个迭代都会产生新的历史需求、历史用例、历史缺陷，而这三者的处理逻辑各不相同，尝试过完全让 GPT3.5 去按照预设逻辑处理，但是效果并不好，完全能用的数据只有 30% 左右（可能还高估了），剩下的都要人工处理，即便是人工处理也不能完全保证可用性。而用 GPT4 处理，效果会好很多，但是成本也没办法承受。

上面这些问题，或许交由更专业、更专心的团队去处理，还有机会处理好，但是内中的细节问题、效果问题上应该还会有一大堆又一大堆要进行处理。
在做之前，我其实也已经跟领导说过这些问题了，但是一句试一试吧，让我没办法反驳。只能当做一次技术上的实践去做了。

就冲第一句，严重怀疑你是我上家公司的。

需求一句话，你平时用例怎么写的。

常规的规则验证用例，外包可以执行，但是涉及到一些内部系统配置的，基本都卡住了吧
而且越复杂的场景，越是需要跨几个部门沟通

正在探索，继续探索

先让他们解决一句话需求的问题吧

有的，我们公司的 UI 自动化、接口自动化、用例生成都引入了大模型，效率提升了很多，尤其 UI 自动化表现更突出，直接使用自然语言即可编写自动化测试用例，无需自己定位元素，也不存在跨端的问题，比传统的 UI 自动化要好维护很多

能请教下你们公司如何实现的大模型编写 UI 自动化测试用例的吗，那些定位元素如何处理的

简单来说就是把自然语言描述的用例步骤发给大模型，然后获取到当前页面的控件树，让大模型根据当前用例步骤自己去做决策并执行，然后根据执行结果做断言

去年开始试着 AI 用例生成，现在部门内在推广用，好处是用例格式统一，写用例提效能感觉有 30-50% 吧
现在上面要找相关行业对标 这类信息太少了

是不是得 PRD 写的比较规范？

不是，PRD 不规范可以自己拆 PRD 的需求，这点 AI 也能帮着做。主要提效还是靠减少写的时间和生成的准确性