应付 KPI 的话，可以尝试 MCP 方向：写点查询业务数据、调用自动化、辅助工作流方向

1、这里只是举了一个简单表单例子，如果是复杂的长流程过程，是要事先准备好自动化脚本的
2、playwright/mcp 本身只是一个 Tools，如果要很智能的完成输入"帮我完成这个表单"就能自动填写表单，需要你对接的大模型或智能体 “足够智能”，但也会面临一大堆失败/错误，需要你不断对话调整的过程：可以尝试一下或参考之前论坛中的帖子。
而如果使用一般的大模型，你就需要重复的如下进行：
AI："你是否做 xx1？" - 你：” 是的 “
AI："你是否做 xx2？" - 你：” 是的 “
AI："你是否做 xx3？" - 你：” 是的 “
...
这样效率不高的
3、但 playwright/mcp 可以录制你的过程变成脚本，倒是方便不少

其实是把 MCP 作为一个工作智能助手，在浏览器相关测试中，可以通过 prompts

• 操作页面或抓取信息 (playwright/mcp)
• 将页面操作自动生成自动化脚本 (playwright/mcp)
• 调用自动化脚本快速完成一些常用流程操作 (自定义 mcp 调用 playwright 脚本)
• 通过页面字段，快速查询库表中相关信息核对（自定义 mcp 编写模板化 sql 查询库表工具）
• 获取截图 + 问题描述快速提交 BUG 到你们的项目平台（自定义 mcp 调用 API）
• 获取截图 + 描述通过内部通信工具快速发送给相关同事（自定义 mcp 调用 API） 等等

以前的笔记，可以参考以下（可能有错误）

同样是 10 多年前，南京华为，很多人一起模拟团队那种面试，不知道这做叫什么

最近的：https://www.infoq.cn/article/dd52FPTw9XqEjkmY5ZRj

没必要吐槽 RF 和使用 pytest 写脚本证明啥的。
夸张的说 python 现在的支持的库多的几乎没有没不涵盖的，这和什么测试框架没有关系。

刚做自动化时自然会接触 RF，本能就 skip 了，因为也搞过个使用 excel+unittest 做类似关键词驱动的东西玩玩，太不灵活了，哪有写脚本灵活。但对于项目关联角度来说，选择框架还是很有用的，pytest 也是目前最好的选择了。

有的项目已经 7、8 年了，用了目前看来已经 “过时” 的框架，如果这块业务还在运营，大裁员环境下，还有人有多的余力去大改造吗，小改小调是不是还得懂些 “过时” 的框架.

至于 “培训” 嘛，只能说挣钱不寒碜

市面上有不少基于百度脑图开发的思维导图在线用例工具

我前年兑换的杯子依然等待发货....

首先 metersphere 使用 python 的第三方包，先参考：
https://zhuanlan.zhihu.com/p/446668517?utm_id=0
按这里做法，我尝试是可以的

多年以来，UI 自动化都是虎头蛇尾的多，很少持续 2 年以上的：
除了自动化技术的迭代，更多是因为大环境下，很多业务持续的时间不够长，对应 UI 更不用说了。

相对的更有效的是接口自动化测试、甚至流量回放测试，UI 的部分靠人工保证是更有性价比的

如果能被自动化【轻易】搞定的验证码，那还搞的目的是什么？
验证码的目的本来就是要区分人和机器，最低目的也是要大大增加自动化验证的成本。
所以如果对自己公司的系统：
测试环境：给自动化测试提供直接跳过的功能，至于验证码本身功能通过人工去测试。
生产环境：先人工完成登录，然后通过 connect 的方式去执行自动化脚本

昨晚又出故障了，最近 openAI 升级后各种故障：

今天服务挂了，现在应该好了

content/page.on("request", handler)，在 handler 中打印一下你的请求头看看、检查一下。

只是对卷心菜这个说法感觉有意思：在一个都是低水平的地方卷，卷的再好，在外面来看还是低水平。

裂开了则不是我思考的地方

最简单的方法其实就是最古老的方法：ASP 的上传下载服务

5 年前也有一样的问题，搜刮全网，开源的普遍的是 php，少量 java，而且不好用；最后跟领导说一下，最后决定自给自足了。

自研的话可以契合本公司/部门的需求。
我们这里是偏业务的公司，测试用例几乎可当需求归档的。
而且用例容量日积月累，层级复杂。一些开源工具的的层级管理就不太满足了，所以要自研。
至于备份，定时任务 dump 就好了。

如果性能能这样计算，也
一个应用调用链涉及到多个服务，每个服务都是影响性能的。
代码写的差，再好的硬件也救不了
不能充分利用多核，cpu 再多核心也没用

没有特别去找过特定的论坛，但 github 上有相关项目是关于 chatgpt prompt 的：https://github.com/f/awesome-chatgpt-prompts
我们这个例子中的提示语是不断完善出来的，把大家日常中遇到的各种异常都存下来，逐渐调试出来的。

同意
不是人人都有大厂中各种先进技术栈锻炼的机会的，就算自学也只是了解而无真正实践经验的。
他能一个人完成各项目的测试工作，如果能完成的好且有系统化总结的话，肯定也不是 1-3 年的能比的。

虽然经历看着平平，倒也反应了真实的日常工作。

测试生涯不是什么都追求技术，往测开方向的——测试的本职还是测试，成为测试专家、测试管理也是路

过期了

工具扫描不能代表安全的全部：
1-工具的指纹库是否持续更新：比如缺少新的漏洞信息，或者无法识别使用的中间件或工具
2-工具扫描的路径是否全面：有些 url 路径需要通过一定操作才能访问到
3-一些漏洞可能需要通过多次转换才能判断，这个一般工具不具备（自动化的内容一般都是简单遍历 payload），尤其 sql 注入
4-功能权限校验类需要人去做，工具可不知道业务上那些功能有权限区分
5-需要多步校验中逻辑漏洞、敏感信息、短信类滥用则需要人工和工具结合...
...

tips:安全测试水很深

啥时候增加 http 代理服务功能