打算考哪里哦？我身边有些年轻同事也有类似想法，在互联网干几年积累点本钱之后就考公上岸，在这个行业大家脑筋都挺灵活，只要不是硬考一线城市概率还是很大的

没有上限，越广越好，自己🐔自己，作为测试最好能掌握部分产品和研发的技能，尽量把在这个行业的退路铺广一点。

前几个月有个技术很厉害的测开（自己看书钻研编译器实现公司的静态代码检查，自己开发 vscode 插件做调用链的可视化调试，重点是这些他以前都没做过）突然转做技术 pm，把我吓一跳。

一机多控这块了解不多，好像也没多少成熟的实践。有使用过 solopi 去尝试解决吗？没使用过的话或许可以试试

• 方法一：老老实实写 ui 自动化脚本，准备好长期的维护人力来跟进问题
• 方法二：让研发开个后面实现登录，比如和研发约定，在测试包里，可以通过将账号密码的配置文件放在某个目录让研发在登录时默认读取并完成登录（这个取决于你要不要测登录这个功能本身）

业务视角：

1. 业务发展良好，能盈利赚钱，不亏钱
2. 业务前景看好，有大把投资人的钱可以继续试错一些时间

团队视角：

1. 测试岗位不冗余，测试同学的工作相对饱和
2. 有实际招聘除了业务测试外的其他测开效能岗位（代表团队整体更成熟）
3. 测试老板能不断拉到不错的测试活，并且老板的综合素质客观比较高
4. 团队里测试同学的平均水平比市场的高，或者说高于公司内其他测试团队

以上仅是个人观点

python 的 psutil 简单又实用

有一说一，3 年级这字写得很好看

这么说也是能理解，从我自身来看，最近两年的奋斗欲望也明显降低了，当看到越来越多不可逾越的障碍，以及听到越来越多遥不可及的江湖能人传说，就开始选择接受自己的平庸。

不过依然坚信，幸福是自己给自己的，选择大于努力，选不好就自己🐔自己，也越来越理解 “人生是一场马拉松”。

可能因为是隔着文字去理解会有偏差，其实没有批评的意思，只是分享我自己的亲身经历和真实想法。

但是内核还是鼓励大家努力去争取自己想要的，并不希望测试行业的风气是天天问 “为什么你要卷我” 。

我是 17 年毕业的，当时毕业进百度测试岗本科生白菜价 11k，我就是这个价钱没得谈，要不就不接 offer。

后来 19-20 年的毕业生，那时候入职的薪资就是我当年毕业的 2 倍，我当时薪资都快要被本科毕业生倒挂了。

要是非得说个先来后到，我是真心觉得我上下的两三届才是卡在最惨的时机。早几年出生的能吃到移动端红利跟随大公司成长拿股票，晚几年出生能拿到很不错的起始工资，只是我夹在中间的时间里外不是。

然而抱怨这些历史既没用也说明不了什么，还不如向前看。

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

观点和楼主一致。

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

我专栏里的材料够你使用一阵子：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

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