主要困难点还是在洗数据上面，主要是他多，每个都需要人工过，答复的答案也需要人工一点点矫正，真的是多一点人工多一点 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 语句不行吗，自己插不就好了

你这个不看具体业务肯定不行啊，有些你前置条件就要准备半天或者 dfx 案例要持续观察的，不可能跟点点点的效率一样

换个角度，只是给医生打工而已

我理解集成测一遍，系统应该不用重复测，而是更侧重场景方向的用例

可以先学一下项目是怎么部署的

你是公司的产品就是容器云吗，只是更新容器云这个产品的前后端吗

不太懂开源也算抄袭吗