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

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

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

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

问题 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 模式，自行百度。建议结合用户操作视角，以及业务聚合视角一起来分层。比如一个接口是获取订单信息，这个接口的用例可能放在订单页模块下，这个模块下又聚合了订单页相关业务的上下游接口。

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

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

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

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

和 RTC SDK 的同学有过一些交流，应该比较接近你说的音视频 SDK，下面观点仅代表我自己的理解。

基本测试 Demo

SDK 最基本的测试方法是写 Demo 调用 SDK 接口去测试，我不清楚楼主提到的【各端全部是手工测试】具体是什么情况，对应的宿主又是啥。

按照我的理解，应该要实现不同端的 Demo，在 Demo 中直接调用 SDK 接口，提供不同的入参以及制造不同的场景，从而实现 SDK 某接口的测试用例。这样算是 SDK 的基本功能测试。

这些测试用例中，有部分是可以轻松自动化的，有部分是可自动化但是需要一些 UI 技术的，有部分是完全无法自动化需要人工操作&断言的，分开来看就好。

性能测试也是差不多，先明确 SDK 接口的性能测试场景，然后围绕 Demo 去实现这个测试场景就是了。

注，SDK 本身也会涉及服务端请求，看你关不关注服务端的质量，关注的话要进一步拓展，上面只说 SDK 客户端。

关于断言

前面说的 Demo 可以理解为测试工具的形态，测试断言是 Demo 里需要重点考虑的一部分。

常见的断言有：接口返回断言、日志断言、数据库断言、埋点数据上报断言、音视频频断言。前四者是明确可以全自动化的，只有音视频断言自动化难度高一些，要引入一些算法来检测音视频质量，如果没有条件那就换人工断言。

完

以上是比较常规的整体建设思路，当然【monkeyrunner + 日志】也算是一种方式，具体看能投入建设的人力和必要性如何。匹配测试人力，能抓到 bug 解决质量问题的建设就是最好的建设。

@Lihuazhang

单就自动化的效能收益指标，参考：

1. 研发测试比（可以是人数比，也可以是需求的开发测试人天比）【有了自动化，相同体量的需求，花更少的人数或时间来测试】
2. 回归测试人天消耗【相同的回归工作量，更快完成】

按照上面的思路，往你希望去衡量的环节中细拆下去。