这个应该会是趋势的

我的思路和你的差不多，不过你这里应该还可以继续细分知识类别，并加入知识库的标识特征，让他检索的时候可以减少检索的量，可以加快答案回复的速度

茅塞顿开

思路打开，写一个定时任务定期去触发接口拉取 token，比如 token 有效期是 30 分钟，你就 30 分钟触发一次呗，这个应该也不会频繁过期

只需要人工执行其实就说明可能业务只需要外包出去就行了，复杂的设计都被解决了的话

我理解需求提出 -- 需求细化为精准需求 -- 排期落地为开发设计稿 -- 再进行测试设计以及用例编写，前面三步都是不同的处理方式，你不可能说需求提出就直接变用例，我就算 AI 现在已经非常强这些都能做，至少这几步你得让 AI 分别进行吧。就像起楼一样，你不可能说你喜欢这栋楼的 3 楼，就只要 3 楼不要 1、2 楼吧。

其实我觉得测试项目有 bug 是很正常的情况，和你用什么方式测试没什么关系，重点还是看你们项目的测试策略，评估项目的侧重点，是不是为了项目进度就是可以牺牲掉一点已知的模块质量。但是如果是确实是验证了但是漏测，这个就比较难受了

主要困难点还是在洗数据上面，主要是他多，每个都需要人工过，答复的答案也需要人工一点点矫正，真的是多一点人工多一点 AI，想看有没有大佬能答复

这个属于痛点需求，好思路

如果模块就是你负责，其实你正常测试设计的时候是会去了解开发的实现逻辑的，基本看着设计文档也会知道是前端还是后端负责。如果你只是执行，直接提给你们小组的 TL，他会去转的。不过一般和开发关系好，爱咋提咋提，培养其实也很简单，自己负责开发的模块这么多 bug，开发对测试一般都是比较感激的，还是比较好培养的。

这样吗，而且有个问题上级注意这个 bug 好像也没什么啊，这样反而会去推开发改进转测质量吧

那就写执行了多少用例、回归了多少 bug，产出了什么文档或者其他什么，把自己的工作量化出来

期待连续剧

主要还是代码能力这个对于测试来说是加分项，但是对于开发那是基础，就像别人开发的代码都卷到什么程度了，我们测试的绝大部分其实也就是自动化、性能、稳定性、写写脚本写写平台，搞搞流水线，说句不好听其实还是很基础的

我也想说来着，这个应该是刚进公司执行别人写的用例，但是不会执行，是不敢问别人还是别人不教呢，这种应该直接问写用例的同学就可以了

#!/bin/bash

获取所有命名空间

namespaces=$(kubectl get namespaces -o jsonpath='{.items[*].metadata.name}')

遍历每个命名空间

for ns in $namespaces; do
echo "Processing namespace: $ns"

# 获取当前命名空间中的所有 Pod
pods=$(kubectl get pods -n $ns -o jsonpath='{.items[*].metadata.name}')

# 遍历每个 Pod 并删除
for pod in $pods; do
# 检查 Pod 是否处于 Running 状态
pod_status=$(kubectl get pod $pod -n $ns -o jsonpath='{.status.phase}')
if [ "$pod_status" == "Running" ]; then
echo "Deleting pod: $pod in namespace: $ns"
kubectl delete pod $pod -n $ns

# 等待 Pod 恢复
while true; do
# 检查 Pod 是否重新创建并处于 Running 状态
new_pod=$(kubectl get pods -n $ns -o jsonpath="{.items[?(@.metadata.deletionTimestamp==null && @.status.phase=='Running')].metadata.name}" | grep -v $pod)
if [ ! -z "$new_pod" ]; then
echo "Pod $new_pod in namespace $ns is running."
break
fi
echo "Waiting for pod in namespace $ns to be recreated and running..."
sleep 5
done
else
echo "Pod $pod in namespace $ns is not in Running state, skipping."
fi
done
done

echo "执行完毕"

首先你要明确出这个题的背景，写书到出版况且要几年，从出版再到由此出题又要几年，这样的题针对现实工作肯定是有区别的，甚至是比较大的区别，说不定这个对应的开发模型可能比瀑布模型都还要早，考试就考你在一段时间能在指定的知识里能学到多少，不用纠结工作实践，我理解书本和实际脱轨这是普遍现象。最后第一题以我目前的经验应该也会选 D 因为 ABC 都可以排除。

应该是你的项目慢慢进入稳定盈利阶段了吧，然后又没有新的发展方向，很多成熟产品都这样，一般这个时候就会把人员调到其他部门或者咔嚓了，留一点运维就行

测试永远只有有限的质量的，在有限的时间内提供需求侧要求的场景质量，你再牛逼也只有这个程度，这是上限了

换个角度想说明测试能力过硬，在未入职的情况下探索性测试取得显著成效

要区分一下，你是要测 AI，比如测大模型。还是用 AI 测你自己当前的业务

肯定是交互或者设计对接啊，测试对接是去背锅吗

总之活到最后的就是最强的吧

是这样的，一般会把自动化用例和正常的手工用例一样会区分是特性级别的用例（只验证功能可不可以用），还有全链路用例（把涉及到的部分全部跑一遍），你按自己的需要来就行

写 insert 语句不行吗，自己插不就好了