感谢认可

需要结合下一篇文章一起看，这个功能可以理解成一个编辑入口，下一篇文章中介绍了使用 AI 解析需求文档生成对应格式的测试场景，是这篇文章的前置动作。这样可以少了手动录入的环节

输出格式的话，每家公司的测试用例组织形式不同，方案思路是通用的。可以考虑抽离 prompt 作为配置项，支持多种输出格式。

因为录入的信息是综合编写天数：AI+ 人工=8 日，而 AI 的生成占比 0.3，实际是几乎不占用编写天数的，所以总天数 *0.7=综合编写天数 8 天，计算总天数 (纯人工方式，不依赖 AI) 的方式就是 8/0.7

欢迎大家讨论

这篇文章没有提要从零开发什么功能，用的是 elements 的上传组件，文章说的是如何在不具备 OSS、Nginx 的情况下使用 django 代理图片的过程，重点不在于上传这个功能。

涉及到产出归属问题，现阶段不能开源

欢迎留言交流

你的联系方式可以私信或者评论给我，用仅楼主可见

私信吧

当然可以互相交流

需求确实是由公司业务产生的，不过实现的思路和方案是通用的。

一般来说，在自动化脚本已经编写的基础上，只需要关注替换的值就可以了，比如 A 字段是时间戳，在自动化脚本里要做时间戳的格式转换，加减计算等操作，最后得到一个处理后的 A‘字段，那么 replaceData 里只需要传入你需要的 A’ 字段即可，无需再进行额外的处理逻辑；若是真的需要，那只能额外加一些定制函数进行处理了。

所以这里的效率更多考虑的不是代码执行效率，而是人工改动的效率。

替换方案确实很多，之所以采用这种方案，是考虑到如何从已经编写好的自动化脚本中快速形成造数脚本。按照本篇文章的方案，编写造数脚本，可直接将已经成熟的自动化脚本整体拷贝，移除非必要校验逻辑，增加一行替换代码就可以了，成本比较低。

有更好方案也欢迎留言

欢迎讨论

欢迎留言讨论

欢迎留言讨论

欢迎留言讨论

欢迎留言讨论

欢迎留言讨论

欢迎留言讨论

如果过度追求这个数字，确实会导致这个问题。这是一个侧面反馈指标，不能作为绝对指标。
其次代码统计的数据很难做得十分精确，这要求了分支的开启与结束时间需要十分准确，而这些信息由 QA 维护会存在一定的偏差
另外来说有些公司有代码编写规范，code review 一定程度上能够限制这种情况。我们更关注的是缺陷的情况，缺陷的相应周期、超时情况等

目前不会开源