【deepseek用例生成平台-32】熟悉平台项目代码和原始需求永久存储

俗话说，写完代码的时候，只有上帝和自己能看得懂。

但现在有日子没更新了，所以只有上帝还记得这些代码逻辑了，所以现在我要先带着粉丝们回忆一下之前的逻辑和开发进度：

本章内容并非没用，而是也可以当做熟悉和快速学习任何一个新平台项目的实践哦~ 

先来看看界面：

图片

点击左上角项目列表，进入具体项目

图片

点击需求配置：

图片

原始需求粘贴进来后，先进行需求分解：

图片

然后分解后的一大堆子需求，再依照我们提前设置好的各方法进行优化：

提前设置好的：

图片

图片

这些具体的文案，需要大家结合项目需求或者自己的智能体，自行多多尝试提示词了。效果需要不断的打磨。

完成后，点击开始优化即可。

图片

如上图所示，res字段，就应该是符合的需求子功能列表了。只是我这里用的都是mock的数据展示教学用。

图片

实际通过智能体是可以区分出，哪些子需求功能适合哪个用例设计方案的。

最后，就是把我们新整理好的这一大堆分解后的结果经过人工的修正后，给到实际的用例生成模块，让其生成真正的测试用例就好了。最后肯定会生成一个数量极多的用例，其中一定会有相当的重复和不符合现实的用例出现，还需要请AI模型再次的筛选。

这些，就是用例生成模块的事了。

此刻，我们需要先点击保存按钮，以免好不容易生成的结果丢了：

图片

点击保存后，这些结果就被永久存入了数据库中。

图片

图片

 通过观察models.py的表结构，我们得知这些分解优化后的具体的srs，存放在了DB_new_srs表，并且只有一个project_id能代表哪一些是一起的。

之后我们通过用例生成模块开发的时候，也肯定要利用这个project_id才能找齐所有关联的srs，来逐条生成用例。

那么现在来讨论下，生成用例都需要些什么字段：

1. 需要project_id ，我们有

2. 需要分解后的这一大堆srs ，我们也有

2. 需要原始需求，也就是原始需求的那一段内容，不过很可惜，我们没有...

所以每次你刷新页面都会发现，原始需求不见了：

图片

当然，永久保存这个原始需求开发来说没有任何难度，我们稍后就可以搞定这个事，而现在，我们还是先来理清，我们为什么要用这个原始需求吧？

用例生成的计划是：用每一个分解优化后的小需求，都+上原始需求，来按照对应的用例设计方法来生成用例。

这样才能确保不脱离原始思路，防止AI开始对原始需求进行联想和幻觉。

我们现在还是先来搞定这个原始需求保存吧，我觉得，既然一个项目只有一个原始需求，那么就可以把这个原始需求字段放在DB_project里：

图片

执行两句同步脚本：

图片

然后，就是要搞定展示功能：

打开前端的SrsSet.vue文件，注意箭头的部分：

图片

我们可以看到，进入需求配置页面时候，是通过这个函数来触发获取分解结果的，那么我们现在可以再增加一个新的请求，来获取原始需求并展示在页面上，所以这么写：注意新增的路由中的new改成了old，下面的赋值参数也这么改：

图片

然后去urls.py中设置好：

图片

最后再去views.py中：

图片

好了，到此，我们搞定了展示old_srs的功能。

欢迎下节课追更：保存old_srs的功能和用例生成模块的设计~