现在开发完，每次自测跑测试用例都是特别痛苦的事情。尤其是现在测试的测试用例基本上也都是ai生成的，随随便便一个功能，动不动就大几百条测试用例，自测的时候还是靠人堆一个个点实在是折磨。 我把测试用例丢给codex，发现他用computeruse跑用例识别成功率比我想象中的还高。 想琢磨琢磨能不能把交互层面的用例让ai来跑了。佬们有没有实践经验可以分享一下的 10 个帖子 - 6 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 **项目地址： GitHub - buer2233/api-test-dwp · GitHub 发布文章的目的 主要的目的还是想跟L站的各位大佬佬友们，一起交流学习成长。希望看完之后感兴趣的佬友们，可以提出一些更好的优化建议，或者分享一下你们各自在自动化测试和AI测试这一块的进展和阶段性成果。 项目说明 当前项目是专门用于给claude code或者codex，编写或维护接口自动化测试用例使用的SKILL。目前已经在我们公司内部推广使用，且已经有了不小的实际提效表现了，项目内有展示我统计的使用该SKILL前5周和后5周的提效数据对比。 核心开发思路 完全复刻个人的日常自动化用例编写流程，加Harness engineering的设计思路。通过强制的前置编写门禁要求，和各种针对性的编写规范要求，加上用例编写完成之后强制要求的pytest测试闭环检查项。解决了直接通过vibe coding编写自动化用例时，会遇到的各种不可控问题和随机性问题，大大提升了AI编写用例的准确性和效率。 独特的设计点 前置门禁要求必须填写新增接口方法/接口用例的位置，避免了AI在编写用例时不知道写在那，而盲目的修改的大量的已有的文件。这也是Harness engineering的思路，给AI加强制缰绳，限制它只能按照我们要求的方向跑。 拆分不同的编写和维护用例方式为子文档，通过前置门禁控制以渐进式披露的方式针对不同的流程读取各种所需的子文档。 设计了抓包服务脚本，可通过抓包数据编写接口自动化用例，大大提高用例编写的效率。 通过初次全量扫描自动化框架内已经实现的接口URL存进sqlite，后续增量扫描追加新接口信息的方式。相当于给已实现的所有接口做了一次索引，刚开始我只是通过这种方式实现让AI快速判断抓包的接口是否为需要新增的新接口。后来我看了codegraph的实现方式后，发现这个扫描出的sqlite给它加上更详细的方法名、引用信息、行号等数据后。直接当作AI编写用例时的查询索引，效率直线上升，较少了AI大量的grep调用次数和token消耗。通过接口URL+method就能毫秒级的通过数据库精准查询到需要调用的接口方法在那个文件的多少行，然后AI直接使用。 补充说明 当前SKILL具有极强的针对性，是完全针对我们现有的自动化测试框架编写的SKILL。不具备通用性，所以大家可能无法直接复用到自己的项目中使用。但感兴趣的朋友，可以尝试改写部分内容来适配到自己的自动化测试框架或项目中。有问题的朋友可以私聊我，一起沟通交流和学习成长。 第一次在L站发开源推广的帖子，如果本文有任何问题，请各位佬友及时指出，我马上改正。 1 个帖子 - 1 位参与者 阅读完整话题
起因是在用playwright写端到端的测试用例，今天都提示2次了，接下来不会要制裁我了吧。 你的对话多次触发网络安全风险提示。由于启用了额外的安全检查，响应时间可能会变长。如要获得从事安全工作的授权，请加入“网络信任访问计划”： 1 个帖子 - 1 位参与者 阅读完整话题
问题 如何根据需求的测试用例去完成自动化测试呢? 背景 我们是一个跨端H5的页面，以webview的形式去嵌套在app中 这个H5涉及bridge调用等原生交互 我们试了几个方案 apm 和 模型整合 问题： apm 的需要模拟器且不稳定 playwright和模型整合 问题： 我们是一个跨端应用、没办法直接在浏览器打开，必须在webview中打开 纯视觉模型配合page-agent做自动化 慢、非常慢且识别不准确 如何处理测试用例和登陆状态的问题 每一个测试用例可能和用户的登陆状态相关，自动化测试如何根据测试用例找不同的登陆用户去登陆 请问下有这方面经验的，可以一起交流下，感谢 1 个帖子 - 1 位参与者 阅读完整话题
1.用例管理 用于查看用例列表、状态流转、创建人和操作入口，支持从列表页快速进入执行、编辑和维护流程。 2. 用例编辑 提供脑图式的测试用例编辑能力，支持节点拆分、标签管理、优先级标记和结构化维护，适合复杂场景下的测试设计。 3. 用例执行 支持执行视图下的用例流转与结果记录，可结合通过率、执行进度和节点状态进行实时跟踪。 4. 用例 AI 生成 内置 AI 辅助能力，可围绕当前节点或业务场景补充测试点、生成用例内容，并辅助测试设计完善。 github https://github.com/thealert/KCase/
之前一直在用superpower，但是也太沉重了，我让它改个字母它都得给我写个测试用例（夸张了），在论坛翻了一下很多佬推荐使用trellis，但是我没太看懂他的使用流程，除了一开始用 /start，然后可以用/record-session记录之外，其余的命令没太确定应该在什么时机去调用。 再提一个点，就是感觉现在大部分的工作量都是一整套从需求到完工的流程，但是我感觉一般大家都是先做MVP，然后逐步迭代，但是在迭代过程中的工作流效果就很差，我看trellis说的是直接提需求就可以，但是它的需求也不会落盘到task，这就导致上下文大了之后还是会丢失状态.. 10 个帖子 - 6 位参与者 阅读完整话题