这个解读角度确实新鲜 ，内核也是同一个意思

观点和楼主一致。

实话实说，我认为的测试互卷（往往都是测试人说的），无非就是测试门槛确实足够低，从业人员水平参差不齐，总有部分不思进取的人通过各种说法来掩饰倦怠，尝试拖同行后腿，抱着 “我不进步你也别想进步” 的心态。

我专栏里的材料够你使用一阵子：https://testerhome.com/columns/zingphoy

我日常健身，听起来似乎很健康，但是脱离了二十来出头的年纪后，上强度太狠或者动作不正确就容易运动伤病……

这几年前后照核磁共振不下 4 次了，麻……

主要是，工资好像也没太低吧。就实际情况，为什么测试从业吸引力大，这么多人转行要过来，不就是比从事其他行业工资相对高一些吗？

如果是指 “我不会代码，从事测试工作为什么比其他人会代码的人工资更低”。那也很合理，企业为额外的技能付钱，这些技能可以帮企业解决更多问题。

甘拜下风，回答逻辑很不错，举的例子也很到位，比我的回答可高明太多了

这种话题没有谁能争得赢，就直接是对立面的话题，上来就是吵架。

最后结果要不就是一群人报团取暖，要不就是两拨人争得面红耳赤。有意思吗？

有这个时间还不如理性认真分析分析行业，真觉得不合适那就转行，有手有脚只要肯干还不至于饿死吧。每个行业都有一些规则，说得难听点，不是适应就是离开。

有些人接受行业规则，提高了技能水平，也接受加班，就被说成 996 推崇者，先来一波道德压制。我真的看不下去了……

也不是说都需要代码能力，但是你想拿得更多，总得有方式证明你的技能比别人更好，那代码能力不就是最直接的吗？

1. 操作数据的账号是被标记的测试账号，其数据库增删改权限有限制，产生的数据可以通过账号来辨识以跟踪，实现和线上真实用户的数据隔离
2. 操作数据本身是有明确测试特征的数据，可被辨识并删除

同意恒温，我们这边的提效的最终目标，也是铆定优化研发测试比去搞的（如降低外包同学的数量，从而节省人力的经济成本），或者在相同的人口和保持相同质量的前提下接更多的活干。但研发数量不变的前提下，测试活就这么多，业务盘子也不会突然增大，所以更多时候还是选择优化研发测试比。

【提效从来不意味着降本，如果你是想通过自动化测试，来减少测试人员的数量，节约人力成本，以此为目标的话，大概率是失败的。个人认为，自动化测试的意义在于构建快速反馈的能力，不论是集成在 CICD 流水线上，还是作为线上巡检的一部分，都能够提升质量反馈的速度。在敏捷研发的大环境下，快速反馈能力是必不可少的。不能让测试执行成为团队交付瓶颈】

对于这段话，我的理解不太一样。

1. 注意主语是【自动化测试】，然后才泛化成【提效】。自动化早期建设它反而会带来成本，要建设就需要人力代价，而收益也只会在建设完成之后才会拿到。来到现实上，很多自动化建设因为里程碑拆分不清晰，或者阶段性建设没想清楚，往往都是憋大招的形式去搞，周期长难度大，但凡中间翻车了就是 0 收益，剩余的全是成本。所以才会给人带来一种错觉：自动化建设需要很大的成本，而这个成本往往大于收益（因为收益根本就没出来过）。

2. 自动化测试确实构建了快速反馈的能力。举个例子，有一个未知的线上问题，因为自动化巡检，让研发测试提前于用户发现出来并修复，这里面包含质量和效率的双重收益。【质量】体现于早于用户发现问题然后解决，那对于用户来说这个问题就不存在了，质量就更好；【效率】体现于因为自动化建设，有了明确的复现路径，不需要很费力排查与定位。那这种【快速反馈的能力】是不是就是提效，是不是就能让本来 2 个人做的事情缩减成 1 个人做的事情？所以换句话说，做自动化就是提效->降本的一种路径，当然它不是唯一路径。

3. 举的例子存在我个人认知的局限性。以互联网的常规操作说，多数先从获取流量开始，然后考虑变现。获取流量需要在短时间内快速占领市场，这种行为本身有巨大成本，包括但不限于招聘超出业务所需的人来迅速支撑业务盘子。当业务发展起来，大环境如果不好，就面临一个多少有点卸磨杀驴的问题：“早期为了业务发展搭建了偏冗余的团队，造成相对大的信息流通和决策执行成本，现在希望通过精简团队的方式来让团队对市场响应更敏捷，决策落地更迅速，同时增大业务利润率，我能通过什么方式来让同样的钱做更多的事/节省开支？”，大概率不会是 “我是不是要花更多钱招人，把质量做好，从而获客更多”。之所以这么说，我认为当产品质量到达一个阈值之后，再提升质量 ROI 就很低，所以质量和效率在业务不同阶段各有侧重，效率引出来就是人力成本。【第 3 点有些跑题，但是刚好联想到，试着探讨了做自动化的一些前因后果】

按规范，后端需要做限制。

不能只在前端做，因为可以通过接口直接请求到后端。后端接口才应该是限制加最多的地方，前端限制只是为了用户体验。当然如果没什么质量或者业务风险，倒也无所谓。

产出本质上就是围绕质量和效率这两个维度。

质量无非就是线上事故、线上问题、用户反馈等等，最终这些指标会影响到产品的业务指标；效率无非就是研发测试比、需求回归所需的测试人天时长……

至于具体倾向于哪个数据，和产品所在的阶段相关。比如产品正在快速起量占领市场，这个时候可能效率优先于质量，能容忍一点线上问题但是不能丢市场；比如产品已经十分成熟体量庞大，可能质量优先于效率，因为基础体量大线上一旦有小问题都会演变成大问题，最终引发很大的业务损失。

面试别人次数多了，自己就能说一点门道。我还以前的老板批评过我不会面试别人，说我把一个本来能通过的人面挂了，太菜了

【看起来很好回答，但是总感觉，说出来的跟想的不一样，总是表达不到位，没有思路，条理。】

原因是：一方面自己没有真正的总结过，所谓【想的】更多是脑海中一个个碎片临时凑起来，固然没有条理；另一方面是自己没给别人讲过，于是乎也不知道别人想听什么，如何才能让人听明白。

我的回答是基于上面的原因假设：

问题 1：你简单介绍一下，你最近负责的业务，最熟悉的业务，简单讲一下有哪些业务流程？

回答顺序：

1. 业务几句话总结，给用户解决 XX 问题提供 XX 价值。如果担心自己说不清楚，说个市面上的知明竞品，别人一下子就明白了
2. 从用户角度看，业务的核心流程是什么，或者用户操作起来的流程（到这里就算回答完了）
3. 核心流程背后对应的前后端服务是什么，互相之间是什么关系，各自又承接什么功能（进阶，带一定技术视角的解释，但不要陷入细节）

问题 2：讲一下，你是怎么测试某个功能的？

1. 如果一下子总结不了方法套路，那就拿一个具体需求来说，方便自己临场按着感觉来回答
2. 【怎么测试】这个问题可深可浅。浅的话就理解成需求理解、用例设计与用例执行；深的话就理解成综合性的质量保障，从需求产出到需求交付上线你所做的全部事情。

666

听说这么操作会影响公司与外包公司之间的合作关系，然后未来的外包简历推荐都更难了

看 TesterHome 有没有帖子需要审核

每个人的工作都会有替代性的，如果以前做过的事情确实不复杂，那都是过去历史了没法改变，咱就不纠结这点。针对这个我给点建议：

1. 是不是你做过的工作真的这么简单？还是你当时把它想的太过简单（言下之意是，试图将视野上升，从老板视角去通盘考虑你的工作，你的工作在全局中属于哪一环，起到什么作用，上下游要有一些什么等等）？把这些全想一遍，虽然比不上做一遍，但至少让你在面试时有话可说。
2. 是不是在做工作时，有些难题被你忽略了，比如遇到某个业务或者技术难题，为了快速做出来你选择了一个简单路线去绕过问题。这种也能捡回来思考一下，在面试时候说一说

对于第二个问题。测试的日常工作就是质量把控和交付，常规迭代测试是工作中一半甚至更大部分，这些东西大家都懂，就不要浪费时间说太多，因为是本分工作。除非有特别的亮点，比如一些 bug 分析和问题排查比较出彩，一些突发事情处理比较合理严谨，一些业务决策比较逻辑清晰…… 这些细碎的闪光点很容易忘记，你要自己去想想有没有。

面试官面试角度看，一般会把简历上体现的内容问一遍，先判断内容的真实性，再判断内容的包装度（做得有多深）。

相比于找一个事事都干过，但都是简单实践级的选手，倒不如找一个某方向耕耘做成熟、踩坑多、有心得的选手。

为什么会有这样的选择倾向？因为简单的实践不太需要脑力思考，只要解决过程中遇到的问题，进展就能一直推进，这些问题往往有直觉答案，不复杂，问题能定义清楚，解法能直接搜索到；而耕耘得深，遇到的问题越抽象，可能一个数据不好，要花很大力气去拆分不同数据再分析，为了达成一个指标要推导很多计划，铺垫很多事情，对人的锻炼效果是不一样的。

所以，我的建议是你先把你自己认为做得最好的放在第一位展开说，即使你这个最好的其实也还不够好，但至少是你最能说的。其他比较简单的被问到就说，没问到就提一下过了。

1. 先看其他公司公开的招聘中，你想要面试的岗位有哪些要求，收集下来
2. 审视自己的技能是否达到要求，如果达不到要求就找办法迅速提高

在深圳 MTSC 2023 上有团队分享，把 gpt 结合到变更分析里头，让 gpt 分析变更代码的影响范围，并按照变更给出用例设计的参考思路。

就上面这个案例当然我也觉得很鸡肋，但这肯定只是开端。

看完了，若有所思

如果是在广东，那十分合理。好多人都不一定有

可以考虑咸鱼卖我，我刚需要一个哈哈哈

是啊，很多基本操作如果不规范，就像是地基不牢固，在上面继续发展就会越来越摇晃，牵一发动全身

其实最关键的就是去砍手工用例，正如大家说，自动化用例执行本身就不会花费多少人力，所以砍自动化用例不痛不痒。跟手工用例关联的重点就是覆盖率录制，录制这个行为确实有成本，但是大体还是可控的，看业务情况可以不定期录制。