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

【提效从来不意味着降本，如果你是想通过自动化测试，来减少测试人员的数量，节约人力成本，以此为目标的话，大概率是失败的。个人认为，自动化测试的意义在于构建快速反馈的能力，不论是集成在 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 分析变更代码的影响范围，并按照变更给出用例设计的参考思路。

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

看完了，若有所思

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

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

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

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

1. 业务体量复杂，肯定是基于业务架构和业务链路来说的复杂，和用户量没有关系。
   典型如大厂里平台性质的业务，拿大家都知道的淘宝天猫来说，app 抽象起来就是一个平台，上面承载这五花八门各个团队的业务，而这些业务之间也不完全是互相独立的，常常是网状关系，技术和业务多少有关联。这种情况下就可以定义为业务体量复杂。
   假设现在就是一个数字计算器工具 app，即使成千上万的人在使用，它一样是一个很简单的技术实现，从代码量、调用链路、技术结构、开发人员等各个维度来说都不复杂。

2. 【但是呢，重复的多少？没人愿意去重新搞搞清楚的可能也是有的？】我没有很理解在问哪一方面，是指回归用例是否存在重复吗？我猜测可能会有但是不多，因为回归用例要定期 review 保鲜，增加或删减回归用例是经常的事情。
   这个质疑出发点是好的，至于别人的业务是不是这样就不清楚了。

3. 【为什么要全量回归用例】，首先这几万条用例本身并不是全量用例，它就是经过筛选的回归用例，很不可置信对吧 ，我也这么觉得。
   另外这是客户端形态的业务，回归测试是端到端的行为，也就是从客户端做测试执行，一并覆盖到业务视角的重点服务端链路。发版好像是三周或一个月一次。
   可能楼主对服务端更熟悉，下意识认为这个是服务端的回归。但往往 ToC 的业务，更重视客户端回归，因为面向用户的就是一个客户端或 app。服务端回归相对简单，想什么时候跑接口自动化就什么时候跑，只要保证环境隔离，不太需要绑定具体的时间节点或者外部配合。
   业务拆分就如上所说，一个平台类型的 app，不可能一个团队回归，比如淘宝直播有直播的团队回归，钱包优惠券有支付的同学回归……，所以这个几万条用例也可能不是一个团队的用例。

4. 优先级概念的确很有用，但是优先级概念是业务视角出发的一种概念。精准测试是技术视角出发的概念，本质是面向任何变更，回归用例的精简只是它一个落地场景，它和按优先级砍用例在结果上有一定相似与重合，但是在过程上不是一回事。
   肯定不能说 “对于所有代码变更，我一律只跑 P0-P2 的用例，业务就没有质量问题” 对吧？同理，精准测试是一种门槛更高的补充手段。这里说的用例，都是指一个完整的测试执行和断言过程，精细到具体操作，这些基本概念我理解大家都是对齐的。

那大概是业务体量还不够复杂。

公司内某业务回归几万条用例，几个外包测几天才能回归完成，如果精准测试能将这几万条缩减成几千条，就可以省了若干外包的人力成本。多出来的人力可以考虑裁掉节省开支，也可以拿来支持其他业务需求，还是很划算的。

另外，精准的作用不能只是捞对应的自动化用例，手工用例也应该捞出来。否则这个精准测试就做得很有问题了。

今天 6 号上完最后一天班，7 号开始请假跑路

哈哈哈，很有经验。曾经在前司安全团队，线上安全产品出问题了，国庆假期回来研发才慢悠悠地看，就是典型的业务本身不太重要的案例。

还没听过有人在测试上使用 Rust。

测试选择的编程语言应该主要考虑开发效率，而且开发的测试系统一般只对内不对外，无需过重考虑质量（当然特殊场景除外，case by case 谈），选择 Rust 看起来似乎和前面的点矛盾。至少我觉得 Rust 没有加持反而是 Debuff，就像没测试会用 C++ 开发测试系统一样（还是那句话，特殊场景除外，比如测底层硬件或者啥）。

绝大多数业务都还不一定考虑 Rust 来开发，所以我在看到这个帖子的时候双眼是瞪大了的

你可以再详细描述一下你的现状。按照目前我获得的信息，我的更多建议：

信息 1：有了 Demo 后，SDK 接口的测试，转化成面向 Demo 的手工点点点

如果用例明确可以自动化，你可以在启动 Demo 的时候就自动触发这些用例的运行与断言，或者设置一个按钮一键把所有自动化用例运行起来，免去人工点击才触发用例运行，从而提升执行效率。

信息 2：【突然想到可以先对经常回归的一些测试场景做 UI 自动化，然后空闲时再把对 SDK API 进行封装，做成一个测试 Demo，通过服务下发通知，自动跑自动化】

单纯靠这些信息我推断不出来你们现有的 Demo 是什么形态，是不是我理解的类似于 App 的感觉；也不知道你这里说的 UI 自动化，是解决触发 Demo 运行用例的问题呢？还是解决某些测试场景就是要 UI 点击才能完整跑完的问题？如果是前者，看上面我的建议；如果是后者，引入 UI 自动化是可行的，不过经验上稳定性会很低，要谨慎考虑。

1. 我们的用例是以 json 形式来表达，里面会包含用例描述、用例优先级、用例编号、用例入参、用例断言等相关信息。如果你觉得用例有必要做参数化处理，你就考虑把用例单独拎出来存放，大前提是这些用例共享同一套运行逻辑，或者框架能很好解读用例并执行；否则就是在增加无效工作量，尤其是用例数量不多时（比如只有两位数）
2. PO 模式，自行百度。建议结合用户操作视角，以及业务聚合视角一起来分层。比如一个接口是获取订单信息，这个接口的用例可能放在订单页模块下，这个模块下又聚合了订单页相关业务的上下游接口。

本质原因是社区早期的人员都是来自一个精华小圈子，社区知名度不高所以更多在高级圈子内传播，这批成员的平均水平相对高，分享的东西往往都是经过精心组织与整理的。

当现在社区知名度提上来后，传播得也更广泛，加入门槛更低，随着各式各样不同处境不同阶段的成员加入，整体肯定越来越平均化，也就更多一句话伸手党水贴，还有很多和技术无关但偏向职场的八卦讨论，关键是这些内容有很强感染力而且发布门槛很低，很容易成为最大体量的内容，于是乎精华内容占比就越来越低。

参考知乎社区的内容发展，各类社区发展都有这种规律，不容易逆转，所以这些年出现付费社区，做社区与成员的双向选择。

以上纯属个人观点，和本社区无关哦~