我也想说来着,这个应该是刚进公司执行别人写的用例,但是不会执行,是不敢问别人还是别人不教呢,这种应该直接问写用例的同学就可以了
#!/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 案例要持续观察的,不可能跟点点点的效率一样
换个角度,只是给医生打工而已
我理解集成测一遍,系统应该不用重复测,而是更侧重场景方向的用例
可以先学一下项目是怎么部署的
你是公司的产品就是容器云吗,只是更新容器云这个产品的前后端吗
不太懂开源也算抄袭吗
我觉得和业务的复用性太小相关吧,从 A 业务转到 B 业务,如果是相关的还好,不相干的就了解你大致的测试思路和测试思维就行,自动化、性能更加通用一点吧
没别的,就是为了挣钱
但是有个疑问,如果最后都需要手工去覆盖了(因为 UI 自动化暂时不会搞),那跑自动化感觉意义不大啊
感谢老哥,非常全面
sider
链路稳定性、回答准确度、高负载、安全类(爆破、数据篡改等)、训练是否实时训练还是本地训练好抛上来不受影响,还有这种类型问题可以先问问 gpt
这个就是说一点场面话嘛,说说自己的目标,然后你如何分布实现里程碑是什么,不过你在工作中具体实现不实现,听的人也不会关心的