和 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% 以上是一点都写不了的，剩下的会写代码那部分，也有不少是来到之后被迫写起来，只是依葫芦画瓢的水平，变一下就不会了。
正式同学肯定人人都能写，熟不熟悉快不快好不好就是另外一回事。

你开头摆的数据对于我们这些外人来说没法理解，思路是先去拆分数据分析，可能你已经清楚怎么做了，为了回答完整我还是补一下：

1. 先回捞数据，佐证是不是线上 Bug 是不是真的多（为什么别人感知到多？直觉是客诉反馈多而且有比较严重的级别）
2. 假设就是客诉多给了别人线上 Bug 多的感觉，那逐个 Bug 分析归类，找出 Top 原因，常规操作吧
3. Top 原因中，对应要什么改进就能解决这些问题。改进动作项对应的评价指标是啥？比如你前面说到【用例评审覆盖 100% 版本，技术方案评审覆盖 100% 版本】，那就得想办法去衡量好，怎么搞要看你们的研发系统是啥，支不支持这么干，或者有没有数据 api 给你们去拉数据。这里没法给你共苦或指标建议，工具依赖于你们的研发系统，指标依赖于你的改进事项
4. 建设好持续的度量，同步好这个事情，定期放出数据让大家保持关注。

这些思路我看你的回答都是有的，应该没什么问题。【上面想要我做的是先分析出问题，然后针对问题去考虑动作。直接做动作会被喷】这个是必然的，不然就是盲目在做事情。分析问题是为了能论证出你做的动作是能解决问题，而不是靠直觉或者拍脑袋

那投入时间是肯定的了，没有什么问题不投入就会自己好，人越多的团队这种方式就越好使。

有数据之后能自证问题，也能持续给老板反馈（现在怎么样，做了改进后怎么样，重点抓哪些地方改）。所以搞测试，本身也要把不少时间在质量运营上。

对于这种问题，常用的做法是你建立一个数据看板，每日自动统计你关注的这个口径（至于需要多少开发量和工作量，得看你们内部系统是怎么样的）。目的是在周会或者什么会议上放出这个数据，表扬头部做得好的，批评尾部做得差的。这样运作一段时间平均水平就会逐渐上来。关键是背后得有老板支撑，老板也要偶尔关注到这个数据，否则也很难做好，因为大家都觉得无所谓。

建议先明确自己的需求，然后再去市面看看有没有现成合适需求的东西上手就用，最后实在找不到合适的再考虑自己造。

除非你真的什么事都没有，需要找点特别的事情来做做。

可以啊，这种方式很不错。

付费是一种门槛，门槛越高客源的质量也高（当然对应的受众人群也会越小）。以后等我没那么菜了，我也学学这样搞。

经典一句话需求

最近我的小买卖也搞起来了，认识到一个不太稳定的尾货批发商，从里面低价入一些玩具再卖掉赚点差价，预期利润 10%~20%，唯一问题是投入成本没法扩大，规模太小，长期看一个月撑死赚个三四百。目前首月暂时赚了一百多一点点，也满足了。

说到生蚝批发，看来楼主也是广东人哈哈哈哈

和别人一起买了个一千多的极客 vip 账号，结果没看两章一年就过去了，然后到期，我是 fw 😭