从面试官角度给一些建议：

• 使用 “高级” 词汇来包装：看简历的第一眼就能从用词上对这个同学的视野和经历有个基本印象，一般互联网大厂都有些黑话，而越是级别往上走黑话只会更多不会更少。我大概捏造的例子：

“熟悉 xxx 业务流程，有功能、性能、稳定性等测试经验” 改成 “熟悉 xxx 业务流程，能够从功能、性能、稳定性等维度把控业务的质量风险”

当然不是黑话越多越好，但是在某些场合上说说黑话容易给人一种你懂的更多的感觉。

• 不要把 “亮点” 挖掘局限在技术性事情上：不是每个测试同学都适合搞技术，测试岗位也不是一个技术好就能做得好的岗位，它更多的是一个综合性质岗位。所以不会搞自动化、不会搞框架不代表没有其他优点。比如有敏锐的问题感知能力，很熟悉业务的上下游架构和流程，线上线下有问题你甚至可以脱离研发独立定位到，或者对研发定位给予关键的作用，有实际案例的话都是很不错的优点。

• 有些事情看起来简单但是做起来很难，能做得成也是亮点：比如业务经历了快速发展，一堆历史质量债务，包括但不仅限于代码基础质量差、业务兜底未考虑、线上监控缺失等等各种回头补起来很痛苦的事情，你通过系统的数据分析找到问题，通过项目管理和里程碑拆，牵头带大家把整个事情一点点做好了，有不错的业务结果，也是值得肯定的事情。毕竟有些事情的难度大家都懂。

大学毕业前夕自己啃完了《Orange'S : 一个操作系统的实现》，前大半都有跟着写代码去跑。实话说现在已经完全记不住书里的内容了，也很难想得起来一些什么技术细节。

我觉得这种东西其实就是一个思维训练。技术很久不用自然会忘记，但只要你曾经真正的理解过，重新再翻看时很多东西马上能回忆起来，重新学习的效率很高。假如某一天你真的遇到了应用场景，那会是很大的优势吧。

同理，算法，编译器，图形学在我眼里也都是一种计算机学科的思维素养训练。

一把好椅子的重要性，就如同趁手的键鼠和高配的电脑一样。现在出租屋里用的椅子是 800 块的，用了 5 年了，开始感觉不太好使了，尤其是靠背倾斜角度无法调节导致脖子很难受。

7 楼的确太假了，本来想来删掉突然发现没了，可能是他自己删了或者被其他管理员删了

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

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

前几个月有个技术很厉害的测开（自己看书钻研编译器实现公司的静态代码检查，自己开发 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 点有些跑题，但是刚好联想到，试着探讨了做自动化的一些前因后果】

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

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

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

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

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