感谢解答，受益满满，已经明确了需要加强的方向

如果你想试用一下怎么部署到 Jenkins，定时跑任务
1、你把代码上传到 gitlab 或 github，然后本地部署 Jenkins 拉取代码定时跑任务就可
2、也可以购买云服务器，全流程自己走一遍（估计新人购买云服务器，几十元一年）
如果你只是想应对面试，可以直接说你做过 Jenkins 定时任务，监控线上接口运行情况，此时面试官可能问你一下问题
1、你怎么部署环境和进行 Jenkins 配置，配置策略是什么
2、线上定时监控中，发现了哪些常见问题，遇到了什么困难
3、线上监控的意义和作用
4、接口用例维护的频率、项目组内用例维护的分工等
其他，在面试中不断去总结遇到的其他问题，并完善自己的表述，你就是做过了这些内容

感谢解答，目前的测试内容主要是包含几部分：
1、产品文档的实现情况
2、用户提问的实体识别是否准确
3、根据实体召回数据是否正确，召回数据的性能
4、模型生成的 prompt 数据是否正确
5、模型返回的内容是否与 prompt 数据存在相关性
6、模型返回内容的格式是否正确
7、模型的用户提问及返回的敏感词校验
8、模型返回的异常情况验证

以上基本上都是基于黑盒模型的模型应用测试

疑惑点
1、相对传统测试的测试基准变得模糊不清了
2、测试数据的来源、测试数据如何分类等

准确来说，应该是大模型应用的测试

与其说落地了大模型，不如说，对于企业本身，使用 deepseek，具有合规和当前战略性意义。就落地后的效果来说，一言难尽。就如 manus 一样（很多做的离 manus 甚远）

问题疑惑：
1、落地基于现有业务落地大模型，测试除了关注产品文档上那一点黑盒的东西，还应该做些什么？

交友渠道就是扩大圈子

问自己，找一个爱自己的，还是自己爱的

deepseek 让全国各行业工作者都颅内高潮，但是离真正落地结合现有业务达到智能化还有很长的路要走

1、建议分类，简单单接口，不需要复杂判断的，都可以使用 yaml 等
2、多接口或场景用例，需要复杂断言的部分，使用代码去实现
3、使用 pom 来保证接口的复用，减少代码量；对断言进行封装实现基础断言和二次精准断言

为什么不搞成场景用例，多用例组合在一起，有增加有删除，这样不就闭环了（会产生一些垃圾数据）

狭隘了

三部曲，这只是其中一部，而且参考一下得了，起不到什么作用，民族文化和体制不同等，太多因素

把现在要做会做能做的都列出来，把现在在做的写成博客发到社区。把上下游能做的学到用到做到

你是最懂生活的了

旅游不是主旋律，徒步才是真热爱

透支未来的生活方式，无他

这个基本上可以解决多语言问题，之前测试多语言 App，基本上就是关注显示是否完整及页面显示变形等问题；同时应该鼓励产品及设计在需求阶段多使用通用类图标来表达，表达不清晰的，最好是有二级页面去详细说明

不是外企，国内私企

不要这个，穷人没什么可继承的

在现在大环境下，公司还可以，领导也好