用 AI 写代码节奏很快，不管是新功能的上线，还是一些 bug 的修复。
但如果上线给用户用，出问题了总会是很麻烦的事情。
大家现在有什么样的技巧或者方式去做测试呢？ DDD ？自动化测试？还是有什么测试 Harness ？
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 59 days ago, the information mentioned may be changed or developed.
 |
1
那就让 AI 把测试也搭建起来跑。
|
 |
2
自己写的/别人写的就放心上线？也许你只是缺个背锅的
|
16 |
vance123Sep 12
3
自动化测试, 要做到 agent 自我迭代
|
 |
4
ai 写完了会自己驱动浏览器、命令行工具或上服务器实测的，比人测的还全面
|
 |
5
先自测，再互测,codex 写 claude 测，claude 写 codex 测
|
 |
raycoolSep 12
6
AI 写的代码目测比绝大部分程序员写的好。
同时测试覆盖度也还可以。 |
 |
kujouSep 12
7
我自己用当然不放心，但是大多数人写代码都是给老板写的，都是给别人写的，只要说一句，写代码又不会死人，就安心的交付了。
|
 |
ChuckleSep 12
8
看客户，客户要速度，不嫌 bug 多，弄点灰度、AB 集群兜底就行了，有故障就修。要是要质量，那就老老实实测吧，出了问题也是自己的锅。ai 又不懂业务，不懂客户要什么，没啥办法。
|
 |
noahhhhSep 12 via Android
9
写好文档，把测试方法和边界扔给 AI ，SOTA 模型基本都能搞定
|
 |
MindMindMaxSep 12
10
@milkleeeeee 没有人类专业 QA 覆盖的全。
|
|
milkleeeeeeSep 12
11
@MindMindMax 是的，但这就不是我关心的事情了，公司愿意花钱请人类专业 QA 最好，反正 ai 测的比我自己一个人测的又快又好
|
 |
12
那 leader 按排下属写的代码怎么放心上线的。
|
 |
13
我的项目在收尾，刚巧问了 Gemini 这个场景。这句格言引用的很有意思：
Software is never finished, only released. 只要是软件都有 bug ，这不是摆烂的理由，但要接受这个事实，不要因此而焦虑。 没发现 bug 说明根本没人用，追求完美是永远无法发布的。 |
 |
z1154505909Sep 12
14
我只能确保按照我的理解的业务逻辑让 ai 进行测试覆盖，至于你硬要去啤酒馆硬点鲱鱼罐头蛋炒饭，不在我考虑范围内
|
 |
afkoolSep 12
15
我以前也很焦虑，但上线了以后发现，也就那样。。关键的东西都走内网，走不了的都在 nginx 层面加 IP 白名单。
|
 |
zeni123Sep 12
16
自己写代码的时候 我也不放心自己写的代码上线。但是无论任何时候，产品经理都放心得很...
|
 |
wangcongmingSep 12
17
自己再用 ai 过下 cr ，现在发现其实用上 ai 后，整个后端的代码质量是提升的，事故也大大减少
|
 |
MYDBSep 12
18
自己先用一遍，就能发现 90%的常见 bug 了，用户一般发现的都是罕见 bug ，用户提交这种 bug 我都是直接给一笔余额，不过不能提现/不能代充
|
 |
19
@yidinghe APP 测试怎么搭？我之前没写过 APP 代码，现在都是 AI 写，测试只能自己点点点，但架不住覆盖不全。所以想着有没有什么 AI 自动化测试的轮子
|
|
20
@vance123 有什么轮子吗？
|
|
21
@milkleeeeee APP 的怎么搞？
|
|
22
@wildwind2333 用 ADB 啊，我之前手机发现后退按钮总是不灵，我让 AI 连上 ADB 帮我调试，全程 AI 自己规划，要我帮忙开什么权限我就照做，最后 AI 找出来是有个 app 故意在屏幕上放了一个 1x1 透明悬浮窗，定时抢走焦点导致的。我就取消掉了其悬浮窗权限，问题解决了。
|
 |
deplivesSep 12
23
现在的 ai 写代码的水平至少能秒掉 95% 以上的程序员
|
 |
V2TrySep 12 via iPhone
24
ChatGPT 家的模型真的太爱测试了，我没有测试的项目他也会自己搭一套。
|
 |
itbunanSep 12
25
只要不涉及付钱，放心大胆的搞吧。 我仔细看过了，我比较菜。比 AI 菜多了，AI 都想不到的问题，我更想不到了。
|
 |
abbycinSep 12 via Android
26
ai 写代码，然后 ai 先 review ，然后人工 review ，关键的地方用 tla+做形式化验证，反正我是这么来的
|
 |
layxySep 12
27
不放心，我一般会 review 一遍
|
 |
28
AI 是这样自我评价的
 |
 |
blSep 12
29
ai 写完自己验证结果
|
|
milkleeeeeeSep 12
30
@break AI 的自我评价挺中肯的
|
 |
31
跑了 1 年，我就一个结论。不要相信 ai 写的单元测试…因为他的单元测试永远挡不住问题，永远是看了代码写的单元测试。我现在不 review 代码，只 review 单元测试代码，狗屁的强太多。一半的的测试都是看起来正确。
|
 |
AEDaydreamerSep 12
32
单独一个 agent 写集成和 e2e 用例，并且人类 review ，然后 simulator 测试，就是比较费 token 。
|
 |
mushuanlSep 12
33
AI 写的代码人类难以 review. 我一般先 ai 出一个原型然后完善，然后自己调整框架架构，对主要功能流程觉得合理后，
自己先跑跑，收集信息，记录功能性和非功能性问题是否存在，然后解决，迭代几个周期基本稳定后上线拿用户当小白鼠。 |
 |
413420Sep 12
34
上线了再说
|
 |
eagleoflqjSep 12 via iPhone
35
同事都用 AI ，还不一定有你测得全，不必内耗
一个 session 写，一个 session 审，直到收敛 不要看代码，只要看更改的文件范围是否符合预期 AI 的单测要有，这是你没有乱改的唯一证据 自己在测试服手动跑一遍 happy path ，unhappy paths 太多了根本跑不过来，有问题是下一个 ticket 的事 |
 |
659746321Sep 12
36
如果你自己的想法你应该有明确的产品流程，然后慢慢的测试 bug ，让 codex 审查代码，修改后 claude 在查一遍，第一步能查出非常多问题修复后基本都是没为什么问题。服务器安全可以让 codex 攻击自己的服务器也会很明确安全策略。普通的人写的代码真多还不如 ai 写的。bug 更多。
|
 |
yunyuyuanSep 13
37
开发的时候让 AI 遇事不决多停下来问，开发完成之后自己测试常见 case ，pr 让其他模型交叉 review ，就上线，发现 bug 再修呗。
|
 |
issakchillSep 13
38
没办法 ai 落地之后 需求给的时间更短了 ai 做完 用 ai review 然后再用 ai 修修补补推上去好了
|
 |
gloeaerrisSep 13
39
你要是带过团队，你手下的人的代码你是怎么放心上线的，agent 的代码就怎么放心上线，这有什么区别吗，还是说 agent 开发的代码你直接不测就上线？
|
 |
strobber16Sep 13 via Android
40
boom ，先爆炸，炸一次你就知道了
|
 |
wangxiaoerSep 13
41
@milkleeeeee #4 不是很理解，他怎么知道页面里面加载的数据正常呢？ 比如这个查询接口筛选的数据根本就不对。
|
 |
LockroachSep 13
42
做好单元测试和回归测试，再完成前端自动化测试，如果接入支付这些重要系统则自己 review 一下
|
 |
x86Sep 13
43
自己写的就更不放心了🤣
|
 |
SinkskySep 13
44
听过一个新能源汽车的分享
产品开发本质都是风险管理，只要风险可控范围内不出大问题上线，就算成功 |
 |
jackkkieSep 13
45
领导都让你娱乐 vibe 了，你还担心上线？
|
 |
laizenanSep 13
46
和手工一样啊，灰度/遥测/关键代码保证热更新能力
|
 |
RightHandSep 13 via Android
47
反正自己不会用，能过测试就行。你们会用自己公司的服务么？
|
 |
anjingdexiaocaiSep 13 via Android
48
线上崩了关我什么事呢？我只是按领导要求办事，更何况也通过测试那关了呀，除非你公司没有测试。
|
|
milkleeeeeeSep 13
49
@wangxiaoer ai 会直接去数据库里查。从调用接口、验证数据库里的数据、确认页面展示它会整个链路查一遍，如果你放心的话它也可以直接查生产数据库的数据
|
 |
disoundSep 13
50
@z1154505909 通透
|
|
disoundSep 13
52
@SuperDaniel313 智慧！
|
|
disoundSep 13
53
@milkleeeeee 确实
|
 |
hdfg159Sep 13 via iPhone
54
写好测试直接推
|
 |
Genshin2020Sep 13
55
不放心又如何，打不过就加入，相信后人的智慧
|
 |
zuokanyunqishiSep 13
56
你们是怎么控制 Ai 不跑偏的 ,我拿 deepseek 写 agent 都按任务切片了,还能自己另辟蹊径跨契约层直接调用..
|
 |
0x0xSep 13
57
|
|
0x0xSep 13
58
@0x0x 现在已经有很多类似的开源在做这一块的了。shopify 从 rn 切回 native ，看他们的文章，内部也是实现了一个用来真实验证 coding 正确性的框架
|
 |
nekooooooSep 13
59
这有什么放心不放心的？那你得想，老板凭什么放心他底下的那些人写完的程序可以上线？产品负责人，他凭什么放心？如果不放心，那就安排测试去测，Agent 又不是不能去测试。老板或产品负责人，他们也都是听测试说有没有问题。那你现在就是这个角色，你要做的就是让测试去做，优化测试的能力，然后相信测试就行了。要不然你自己会累死的。
|
 |
yexiaoqiSep 13
61
多写测试，不断总结经验，逐步完善
|
 |
A1188Sep 13 via Android
62
让 AI 发动自己的雷霆大思考，自己实机测试自己找 Bug ，自己修 Bug
|
 |
zed1018Sep 13
63
@wildwind2333 #18 这方面叫 E2E ，web 的话 playwright ，ios 的话 facebook 有一个 idb 工具可以通过模拟器让 AI 操作。Android 可以通过 ADB
|
 |
SHIINASAMASep 13
64
过度担忧会错失机会，先上线再说
|
|
65
@0x0x 这个看起来不错 试试
|
|
66
看到阿里开源的这个 code review 项目 ，也准备试试
https://github.com/alibaba/open-code-review |
 |
vultrSep 13
67
不同的项目有不同的技巧的，我在写 tcptun-go 的时候，最简单的验证方法就是给它构建真实环境，让 GPT 自己不断测试完善，验收的时候我只需要看它是不是稳定，是不是真的比别的协议更快。
|
 |
zengxsSep 13
68
简单写个单元测试很容易，但是要写出好的测试用例是很难的
生产路径上很多测试用例都是从用户奇奇怪怪的输入累积的，以及测试工程师根据经验构造 我目前的体验是，ai 写的测试基本只能覆盖最基本的路径 而且几个模块耦合比较紧会互相影响的时候，ai 还经常破坏回归，改完这边那边坏了但是没测出来 所以上线之前最好还是自己把主要路径都体验一下，简单人工验收一下 |
 |
jackOffSep 14
69
我觉得 dsh 的沙箱机制和开发设计里的微服务设计可以很好的隔离 ai 开发风险，首先前者是杜绝 ai 把手伸到不该去的地方，项目开发分微服务的话配合这个简直自律性拉满，其次后者在没有 ai 的时代就已经有隔离的作用
|
 |
BornThisWaySep 14
71
首先 ai 会 review 和自测代码
其次 我会大概 review 下代码是否是我想要的 再次 我会简单自测主流程 再其次 有测试.. |
|
BornThisWaySep 14
72
@BornThisWay 反正和前 ai 时代比 我觉得代码质量总体来说是更强效率更高的
想要完全没 bug 那不可能 光是 ui 给的 figma ai 就不可能完全还原 就不说格式不对和有很多隐藏图层了 兼容设备 动画部分很多这种比较主观的 ai 没法替你决策 得再进化一波才行 |
 |
airqjSep 14
73
把线上数据库扒下来脱敏后
让 AI 做端到端测试  |
Select Language