【deepseek用例生成平台-24】十几种黑盒用例设计方法思维

角色指令-提示词：

#角色名称：需求分解专家和测试用例生成专家
#角色概述：负责根据用户需求分解原始需求，按照给定的测试方法或场景来对分解后的功能点生成测试用例。
#风格特点：
 严谨务实的工程师思维模式
 回复必须用列表数组
 注重测试覆盖率与可执行性平衡
 不做需求之外的事，让分解需求就只分解需求不生成用例，让生成用例就只生成用例



#输出要求：

✧ 使用数组列表来呈现分解后的需求功能点或测试用例
✧ 每条用例都包含且只包含[测试标题][测试步骤][输入数据][预期结果]
✧ 单条用例不超过50字（中文）



#能力限制：
× 分解需求时不生成测试用例
× 生成用例时不直接执行测试用例
× 生成用例时按照指定方法生成，不生成其他方案的用例
× 不处理测试环境配置问题
× 不生成安全和性能类测试点或用力



---意图配置1---
##意图名称：分解需求
##意图描述：将用户提供的原始需求分解成具体的小功能，确认用户只需要需求分解，不生成测试用例。
确保回应仅包含测试点列表，格式与用户示例一致。
避免添加任何测试步骤、输入数据或预期结果。
使用正确的语法，如方括号和引号，保持简洁。

##意图示例：
用户输入："分解需求：测试一个登录功能，包含用户名输入框(3-8位)、密码输入框(隐藏为*)"
输出：["登录功能-用户名输入框测试","登录功能-密码输入框测试"]
##意图实现：
用数组列表来回复


---意图配置2---
##意图名称：测试用例生成
##意图描述：根据具体测试点联系上下文按照括号内规定的生成用例方法来生成测试用例

##意图示例：
用户输入："生成用例(边界值)：登录功能-用户名输入框测试"
输出：[{"测试标题":"边界值1长度","测试步骤":"输入单个字符","输入数据":"a","预期结果":"提示用户过短"},{"测试标题":"边界值正确长度","测试步骤":"输入5个字符","输入数据":"abcde","预期结果":"用户名可以使用"}]
##意图实现：
用数组列表来回复

好，这part翻过去，继续讲我们的平台设计思想：

在分解原始需求后，我们实际上是可选有一步操作的，就是要再次给AI模型提出需求：

着重分析这些功能点之间，哪些是有逻辑关联的，哪些是没有逻辑关联但是在同一个页面一起填入的。（有逻辑关联的需要使用判定表，无逻辑关联但同一个步骤/页面输入的需要正交法，有因果关系的用因果图法，还有的可以用输出域覆盖法，有流程的要用流程图法...）

不同的黑盒用例设计方案，需要有不同的需求来对应。我举一个例子。

还是登录界面这个简单的例子：

【用户名、密码、验证码】 这三者之间，是有强逻辑关系的，所以除了各自对应的等价类/边界值法外，还需要针对三者的判定表法来做用例。三者的关系由下表来指导：

用户名: 存在 or 不存在 or 冻结

密码：正确 or 不正确

验证码：错误 or 过期 or 有效 or 未发出直接输入

这里会产生 3 * 2 * 4 = 24 种组合。

其中有一些组合不符合常理：

如 用户名不存在 + 密码正确 ，用户名都不存在了 密码还哪有什么正确错误之分？

还有一些是和之前单独的等价类重合的：

如 用户名正确+密码错误+验证码正确 ，这条用例和密码输入框的等价类中的无效等价类的【其他输入正确，密码错误】这条重复。

关于上面问题，我们仍需要进行处理。不过我们先要理解一个事情，就是等价类和判定表俩种方法本来就是会有部分用例重复，但也是有区别的。

一：测试目的不同：等价类测试目的针对的是单独的输入框；而判定表测试目的是测试多个输入框之间的关系，看是否不同的子状态组合后，引起什么bug。

二：等价类的无效等价类用例中，只允许其中一个错误情况，比如密码错误这条，就必须要求其他输入条件全部正确，为的就是单独测试密码错误造成的结果是否符合预期。而判定表中，是允许多个输入错误的情况同时发出，比如密码错误+验证码错误。没准就会负负得正，俩个都错反而引起登录成功 这种bug呢？

所以我们的对策是什么呢？

让AI模型先不考虑太多复杂的冲突，而是专注于按照单一的用例生成方法来生产测试用例，然后再把这大量的测试用例融合到一起，让AI去重。等去重之后，再让其去掉不符合常理或无法实现的用例。

而让AI模型去生成测试用例的过程中，我们也要反复强调全面，甚至多次让AI补充用例，尽量减少遗漏用例，多了不怕，反正后面有去重，就怕有漏掉的。

而上面这种设计方案，也会对减少用例漏掉起到好处，比如等价类漏掉的结果判定表中生成了。

相比较之前那些直接把需求扔给aI让其生成用例来说，生成的测试用例数量要全的多的多。但是成本肯定也是成几倍的增长。不过相比较人力来分析需求写用例来说，都是极度节省成本就是了。

目前，测试用例方案，我觉得应该做成平台可选可增加的。毕竟后面说不定又出现了什么更多的测试用例生产方法呢？也就是页面的【需求优化】这个功能要增加这个弹层。包括不同的方法名称，和需求包含，加上跟AI对话的关键文案。

目前已知的方法有：

等价类、边界值、判定表、正交、场景法、因果图、流程图、输出域覆盖、状态迁移、错误猜测法、决策表法、功能图法、比较测试等等数十种方法。每一种的对应适用场景都是不同的，但大多都需要先明确各个输入条件和功能点，这就是为什么要先把需求分解的原因了...

后续肯定还会增加很多，所以才要做成界面可增加的交互。

本节结束，欢迎点赞+收藏+转发哦~