如果模块就是你负责，其实你正常测试设计的时候是会去了解开发的实现逻辑的，基本看着设计文档也会知道是前端还是后端负责。如果你只是执行，直接提给你们小组的 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 都可以排除。

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

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