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. 回归测试人天消耗【相同的回归工作量，更快完成】

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

【试用期不给配电脑】我感觉更像是创业公司或者某个老板养的工作室

这个可能看他怎么布局，因为他做鸿蒙的一个目标是作为一个全场景全设备的操作系统，可以让华为在不同的设备上实现更好的连通性和互联互通。本质上就是想把生态做得更好，把钱赚得更多。就这愿景上，国产友商除了小米外，没一个能跟他掰手腕的。至少从饼来看还是香的。

至于其他趋势，现在也就是瞎评论一下，未来无法猜测

就这个事情来说，我感觉应该先把服务重启列进去研发和测试上线的 checklist 中去。

也很奇怪，服务升级部署本身不就是重启的过程吗？

上次去深圳的 MTSC，刚好鸿蒙团队有讲他们和 Cocos 的合作的事情。

首先对于【怎么把原本只支持 apk 打包的平台也纳入鸿蒙（如 Unity/Unreal）】，本质上就是他们双方合作在一起，鸿蒙底层给 Unity 实现所需要的接口，上层也会做一些定制开发和调试，这个问题是双向的，引擎侧想拓展市场就要去和华为合作，华为想支持上也要找引擎合作，这个是双赢的。不过 Cocos 是国内团队制造的，Unity 那些不是，所以成本肯定会高一些。

至于谁制裁谁，我觉得终究还是看市场占有率，对比互联网一样，流量才是基本盘，华为在国内市场占有率这么高，只要能保持 Top App 正常运作，很容易实现大量用户的无痛迁移。我觉得至少在国内华为会赢下来。

后面看小米的澎湃 OS 会不会也逐渐走出自己的路 。

思路应该一直是这些，不过公司内部不一定就做得这么完整，往往因为人力和资源问题，多多少少有变形或者偏离。所以我们看这些东西的时候主要是理解他的思路，他本身的实践就当个案例去参考，让我们更好的理解其表达思路

不就是一个 notepad 插件而已，集成度看起来也不高，并不方便高效。

网上有很多 navicat 破解版，如果要规避版权风险也可以选择免费开源如 DBeaver

可以再整理归纳一下，有些属于测试基础术语，有些属于业务术语，有些是技术概念等等…… 这样子新人看起来都更爽了

是啊，运营得很不错，一直都有比较高质量的文章贡献出来。这些东西里就美团给我是全公司统一的输出渠道，阿里、百度、腾讯等各个大厂都是各个团队各个部门各搞各的，在不同的渠道发，乱

我就理解成是对 shell 不熟悉吧。

shell 是靠多用多查。常用命令其实不需要背，只需要熟悉并且在面对场景时快速反映出大概用什么方式去实现就行，这种东西去记忆也是浪费时间，手册一查全都有。

另外，要知道常用的管道命令组合，很多典型的场景会有对应的命令组合去解决，这些需要一定的记忆和训练。

我建议是上网找找常见的 shell 场景题，然后去自己写命令实现出来，训练量上来这个就差不多了。

一是去接入外部的自动审核服务要💰；
二是自动审核但凡逃逸了一个问题也可能带来毁灭性的后果吧？

我也不知道这些内部事务，我只是帮忙审核的志愿者。

在审核队列里等了好多天，终于放出来让我审核通过了，舒服了。

楼主对自己的现状写得比较简单，所以不好评价。

如果让我真诚来评价，仅仅只针对上面体现的这些，我的答案是会有难度。

对 6 年工作经验的定位，首先不应该再是一线执行。分方向看：

• 业务方向，要能胜任某个业务方向的质量负责人（负责人不等于 leader），整体负责这一块业务的全面质量建设（服务端 + 客户端）。业务大还是小就看面试表现和实际能力，能力越强给的业务范畴就越大，对应的问题就更复杂；
• 技术方向，要能独立识别业务问题，转化出技术方案快速实现，推进落地协助业务拿到质量和效率的结果，解决过越难的问题越加分，对业界相关建设越熟悉越加分；

一些自测点参考：

1. 有无清晰的数据导向思维
2. 有无某个方向完整的经历。假设是走业务方向，那接手一个业务后会怎么着手做质量建设，思路如何，说个一二三
3. 能不能写明白半年规划
4. 是否有了解过他人是怎么做，能不能总结出常见的建设套路

【叠甲自保，我这也只是嘴炮，我自己来做估计也不太行】

不仅字节是这样，其他大厂对外包的要求应该都类似。外包同学还是以业务测试为主（就是真正的点点点执行和业务场景分析），要求是业务理解力、基本技术基础（至少可以跟研发平等沟通）、良好沟通素质、抗压能力综合衡量。

不是所有业务都有自动化，也不是所有自动化都是给外包维护，这些都要看情况，很多业务其实质量建设并不成熟，自动化等基本工作可能正式同学一样在做。

我身边的外包同学，感觉超过 80% 以上是一点都写不了的，剩下的会写代码那部分，也有不少是来到之后被迫写起来，只是依葫芦画瓢的水平，变一下就不会了。
正式同学肯定人人都能写，熟不熟悉快不快好不好就是另外一回事。