会员
qdyzw (卡丁车卡丁丁)
第 50224 位会员 / 2020-01-22
44 篇帖子 • 503 条回帖
-
14 个赞 / 7 条回复
-
2 个赞 / 13 条回复
-
1 个赞 / 8 条回复
-
1 个赞 / 29 条回复
-
1 个赞 / 4 条回复
-
1 个赞 / 19 条回复
-
1 个赞 / 3 条回复
-
0 个赞 / 2 条回复
-
0 个赞 / 11 条回复
-
0 个赞 / 3 条回复
-
0 个赞 / 5 条回复
-
0 个赞 / 10 条回复
-
0 个赞 / 3 条回复
-
0 个赞 / 3 条回复
-
0 个赞 / 3 条回复
-
0 个赞 / 2 条回复
-
0 个赞 / 3 条回复
-
0 个赞 / 2 条回复
-
0 个赞 / 0 条回复
-
0 个赞 / 7 条回复
-
0 个赞 / 1 条回复
-
0 个赞 / 5 条回复
-
0 个赞 / 25 条回复
-
0 个赞 / 5 条回复
-
0 个赞 / 2 条回复
-
在 “0-1 完成即提测” 的惯例下，是否有必要建立轻量化提测标准？ at 2026年02月28日
这不就是自测吗？把每个功能的主要用例都给开发测试，测试通过了才提测，能做到就不会存在功能没做了
-
【Recalling】浏览器的记忆管家 ①——事情写在笔记软件里，要用经常找不到，所以我做了一款不用找的笔记插件 at 2026年02月24日
好像 edge 也有一个集锦？和你这个差不多
-
性能测试关键概念和操作澄清手册 at 2026年02月13日
还有个问题，agent 流输出的话，首字符开始后，后续各个字符之间的响应时间会再做分析吗？还是总的时间不超时就行？
-
性能测试关键概念和操作澄清手册 at 2026年02月13日
还有一个老生常谈的问题——“拐点”。现在各种缓存、消息队列等中间件都比较成熟了，系统到达最大处理容量后 tps 一般会维持在高点附近，或者来回抖动，从图上很难看到真的 “拐” 的地方
-
性能测试关键概念和操作澄清手册 at 2026年02月13日
"正确的做法应该是：第 1 秒内通过异步任务启动接口一次性触发 10 个任务后，便不再持续发压，观察系统能否在 10 分钟内完成这批任务。10 分钟后再通过异步任务启动接口启动 10 个任务，确保流水线中并发处理的任务数始终维持在 10 以内。"
这个不敢苟同，流量不一定按你所想的进来，确保系统能同时处理 10 个任务之外还得继续提交任务的，因为要验证系统的排队能力，即时不能并发处理过多的任务也要保持任务队列正常运行，或者说系统的限制功能正不正常，对应八股文中的最小线程数，最大线程数，队列长度，饱和策略等
-
使用 AI 写用例的提示词 at 2026年02月10日
good
-
独自 CI/CD 实践 at 2026年02月02日
像 jenkins 这种容器化的优势在哪里呢
-
BYD 离职潮 vs 黑天鹅 at 2026年02月02日
byd 也能停业吗
-
Agent 性能测试全方案：核心维度、方法与落地实践 at 2026年01月29日
怎么做的？监听到消息后怎么去和压测线程交互？
-
Agent 性能测试全方案：核心维度、方法与落地实践 at 2026年01月29日
JMeter 这种同步线程的工具，没办法去做像 sse 这类需要异步监听的压测吧？