从测试到全栈：AI 时代的测试与开发工作流实践

https://www.deepseek.com/harness/

蹭一下dsh的热度，哈哈

从测试转全栈

公司要求从测试转全栈开发，陆陆续续开始接一些开发的需求，从实际工作下来看，在cc的帮助下，确实没有什么难度

了解底层原理和业务流程，对代码架构有一定了解，让ai分析后编写相关代码，完全可胜任。

虽然如此，我开发后还是加了3个开发人员review code，作为测试人员谨慎一点。

项目测试与文档仓库

项目的测试工作主要还是我来负责，全栈以后新建了一个仓库，结合obsidian来管理项目相关的文档

目前来看效果不错，需求分析、测试分析和生成的用例质量都提升，

整体使用渐进式披露设计，其他新人下载仓库以后都能很快上手，了解业务和进行测试

前期搭建：离不开人审核的三个环节

对于前期搭建来说，几个地方还是离不开人的审核，

1. 需求审核

第一是需求分析整理，这一块可以借助ai整理，但是人一定要审核

很多时候是让自己清楚这个迭代要做些什么东西，看需求和开发排期是否对得上，以及一些文档中模糊的东西甄别出来落实

特别是ai工具使用多了以后，ai的幻觉会转换为人与人之间的幻觉

2. 测试分析

第二是测试分析，一般结合系分、仓库中历史数据，以及你的描述，生成一个测分内容，

需要人审核确认，对错误、模糊的内容需要二次确认、修改、优化等

3. 测试用例

第三是测试用例，生成的测试用例需要审核，修改，完善

我觉得这三个部分在前期搭建ai测试流程中不可或缺，当仓库建立完善后，慢慢审核的内容就会变少，

后续ai生成的文档内容不会漂移

后期提效

后期文档仓库成熟以后，提效明显，我刚开始做已经感觉到很不错了

自动化：从"手搓"到 AI Native 的思考

对于自动化来说，我也算老油条了，毕竟去年还在手搓自动化代码，思维固化，对于自动化用例框架的使用

但最近我在思考，这样的自动化其实不够另外，不够ai native，ai还是按照你编写的案例去编写、执行，不过灵活

如何将上面的测试流程的东西和ai 自动化结合起来，我有一些基础的想法

接口自动化：AI 命令行工具

对于接口自动化来说，使用AI开发一个命令行工具给ai来使用，通过说明文档、skill等指导这个命令工具的用法，

从前后端开发代码直接同步相关的接口信息，登录获取认证，去做单接口的调用和编排，这一块目前还在实践中

没有真正的run起来，因为之前只是想做个命令行工具，后面发现可以给ai直接调用

这块后面有时间了可以写个工具，自己玩一下，如果可以好用的话可以分享一下；

UI 自动化：ai-ui-testing

另外一块是ui自动化，这一块其实我做得不多，因为本身我们产品跟关注底层的引擎和资源的调度，

所以一直没有补齐相关的自动化，但是这一块其实可以去做的，我的想法很简单，我希望有个工具，我给ai说访问什么地方，怎么操作

ai自己去尝试写自动化用例，生成后自己总结用例和索引，以及使用方法等，后面ai可以调用，我也可以进行ci

所以昨天晚上用dsh写了一个工具，今天到公司尝试了一些，可以解决自己的编写自动化用例的问题

告诉资源地址，告诉他目标，然后ai就在后台自己调试写用例，写好告诉我，我就让他有头跑一下，实际效果还不错

整体实现也很简单，有需要的可以看下：https://pypi.org/project/ai-ui-testing/0.2.2/

写代码+发布到pypi，使用deepseek-v4-flash 大概花了3块钱左右吧

DeepSeek Harness 体验

另外一块就不得不提deepseek harness，从deepseek发布新的flash和pro以后，我就一直在关注

发布后发现居然是web 应用，通过npm我是没安装成，还是源码构建的方式安装了

实际体验很丝滑，我一句话完成了博客的创建，自动对接了meoo cli并发布了应用

https://cooklikehoc.soilzhu.su/

哈哈，这里插播一个之前看到的别人发的菜谱网站

https://ex805e7x7n8p.meoo.pub/

目前还在探索中，一切皆插件的思想确实很爽，claude code还在用，但比较费token，自己环境可能都优先使用pi

测试集群部署 dsh

办公本身有token额度，所以不怎么用dsh，而且我们的内部工具内嵌了deepseek harness，所以我就没怎么折腾了

但是对应到上面的仓库，实际驱动还是ai，所以我的想法是在测试集群部署一个dsh供大家来一起使用

说干就干，进入测试集群，我先从源码构建了dsh，运行起来准备访问，我靠，居然只能127.0.0.1，--host指定0.0.0.0不行

试了一圈方法，ai提供的方法都有问题，进入dsh后发现模型配置加载不出来，反正各种问题

后面尝试了一些插件，让dsh支持--host 0.0.0.0，但多多少少都有bug，前端无法配置自定义模型

但是好就好在源码构建，直接ai分析源码，现场编写了一个支持--host 0.0.0.0的创建插件，大概花了5毛钱就完成

安装新写的插件后就可以配置自定义的大模型服务了，配置了qwen3.5-35b-a3b，虽然只有256k的上下文，

但是用来排查集群pod日志，去skill调用前面仓库写的ui和接口自动化已经完成没有问题

后续考虑部署新出的qwen3.8-27B，目前的卡资源可能只能勉强部署FP8版本，长上下文Kvcashe占用比较大

---

后续考虑将一些问题排查经验变成文档或skill，放到对应的项目目录中，其他人访问dsh对应的项目就能方便的使用排查了，

所有项目人员都可以通过对话的方式进行测试、日志排查等操作了。

在对接一些聊天软件的webhook，做监控，定时任务什么的都很方便，或者在集群中测试，故障注入什么的都可以

这样一部署，思路瞬间打开，我自己都想high了

泼一盆冷水：安全与管控

但必须泼一盆冷水，虽然能力开放，但是还要注意安全，这种方式如果没有防火墙等限制，公网就是活靶子，而且还要考虑数据安装

因为我们对接自定义模型，所以风险会小一些

另外就是对大模型的限制，harness不好，限制好模型，小心模型闯祸

实际搭建这一些简单，但是如果组织好使用、管理好，防止ai闯祸是我们更应该思考的，也是我现在担心和在想办法优化的地方

结尾

以上就是最近工作的一些记录，自己想high了，忍不住说两句，哈哈哈

插播一下qwen ai的39 code plan是坑，办公分分钟用完，建议别买