从QQ到腾讯云，一款优秀产品的开发实战经验分享。
作者：rexchang 腾讯CSIG通信终端研发中心总监 导语 | 我在 2008 年进入公司后，做的一直是面向 C 端用户的客户端产品QQ，产品的可测性是很强的，虽然功能很多，但测试团队总是能成为产品质量的坚强后盾。 2016 年团队加入腾讯云后，依然在客户端方向，但所做的产品已经不再是一款软件，而是一套音视频通信领域的 PaaS SDK，即 TRTC SDK 和 IM SDK。 相比于 QQ 只需要做好一款 App，我们要面对的是服务好几千个客户的 App，而于此同时，测试资源又是有限的。在这种情况下，如何确保产品质量呢？
从一个小故事开始讲起
在几年前我们刚开始做 ToB 的 SDK 的时候，曾经对接过一家做社交 App 的公司，对方的技术负责人很年轻也很务实。在商务大哥给力的努力下，客户成功完成了产品的接入，并进入线上灰度阶段。
然而，在开始灰度的那天晚上，线上用户出现了很多消息延迟大的投诉，用户的一条消息需要很长时间才能发出去。客户虽然对我们很失望，但依然很努力地在配合我们排查和修复问题。
在两天的时间里，我们给客户改进了多个版本，每次给版本的时候我们都说“已经找到问题了，这个版本肯定可以”，但每次效果都不理想。两天之后，客户的技术负责人很严肃地询问了我们一个问题：“从这两天的排障过程和修复过程来看，我想确认一下你们这是一款商用级的产品吗？”
在那个晚上，我们开始冷静地思考一个问题：一款优秀的商用级 SDK 应该怎么做？
一年的努力功亏一篑
最近教育行业被政策打压地非常厉害，但在两年前，这是个 PaaS 服务的兵家必争之地。我们有一家做在线英语教学的客户，一直在对接我们的 TRTC。这个客户对质量要求非常苛刻，他们很早便引入了赛马机制，将多家 PaaS 服务商拉入到自己的供应商集群，互为灾备，并进行质量评估，看谁的质量好就用谁的产品。
在最开始对接的时候，我们的产品质量还不是很优秀，几个关键指标跟竞品都有差距。这倒不是问题，优化总要有一个过程，于是我们一个迭代一个迭代地去跟进。因为客户的版本发布速度非常慢，所以我们需要在两个版本之间都做好问题分析和优化落地，稳抓稳打地慢慢降低工单率。就这样，经过了将近一年的时间，产品各项指标都已经很不错了，我们非常有信心在下一个版本超过友商获得质量上的领先地位。
但就在我们信心满满地等待客户上线的灰度反馈时，客户突然抛出一个问题：“你们的 SDK 有一个对音频模块的自动重启逻辑，这个逻辑会在切换线路时影响到其他供应商的音频模块， 这是绝对不能容忍的”。因为引入多家供应商赛马的意义就在于保证可以有灾备，如果一家供应商影响了其他供应商的稳定性，这个灾备便没有了意义，因此客户对我们异常失望，放量计划无限期搁置。
面对一年的努力功亏一篑，我们开始接受一个现实：每位同事都可能会因为手滑引入缺陷，但对团队而言代价却是难以承受的，怎么办？
回到正题，接下来我会介绍一下过去的这些日子里，我们怎么去应对这个问题。不过在此之前，我需要先介绍一下我们的产品：
我们是做什么的？
我们团队所开发的是一套面向企业级客户的 SDK，包括用于实时音视频通讯的 TRTC SDK；用于消息通信的 IM SDK；用于直播推流和播放的LIVE SDK ；以及用于短视频录制和编辑的 UGC SDK。
客户所属行业分布广，教育、泛互、金融，不同的客户对产品的需求差异性大。
客户接入周期长，大客户在接入过程中会不断追加新需求和新特性，与此同时，客户对交付周期要求又很苛刻。
SDK 对专业性要求是比较高的，别人家的客户都只需要理解 http 的 get 和 post 就行了，俺们家的客户就得知道多线程安全、内存泄漏、前后台切换，苹果隐私合规要求，还有 android 的 gradle 配置方法和 windows 的 stl 兼容问题...
涉及平台众多，iOS、Android、Windows、Mac、Web，每个方向都需要很长时间的积累和沉淀。同时，在微信的强大的影响力面前，我们又增加了一个新的平台——微信小程序。
SDK 完成接入后，成不成要依赖客户的最终反馈，但往往客户的反馈周期很长，迭代周期也很长。
SDK 版本多，平台多，这也就意味着测试工作是海量的。就说一个细节，这么多平台和版本，全量编译都需要两个小时，转测和发版就更不用说了。
研发体系的优化
1. 怎么做需求评审？
2. 怎么做技术评审？
3. 怎么做代码合入？
CR 一级：模块的维护者来 review，这一级的目的是让模块的稳定性能够得到保障。毕竟在别人家的田间地头种自己的庄稼，你总不能背着这块地的主人搞小动作不是。
CR 二级：自己的 leader 来 review，这是我们整个 CR 的核心基石。很幸运团队有像 taopu 一样负责和认真的 leader，会非常细致的 review 大家的每一行代码，并积极提出意见和建议，在 CR 中提升大家的技术水平。
CR 三级：总监负责 review 和 代码合入，这一步更多是抽检，看看哪些同事是真正地爱这款产品，哪些同事则是不那么负责的架构破坏者。
4. 怎么做功能测试？
怎么确认画面出来了？
怎么确认声音是正常的?
怎么构造复杂的测试流程和测试序列?
怎么保证测试环境的稳定和不被干扰?
还有最艰苦的：怎么找到足够多又耐操的手机，尤其是水果牌的。
产品体系的优化
方法一：通过场景落地来验证产品质量
方法二：通过数据体系来评估产品质量
不同的客户关注的点是不一样：比如教育客户关注的是稳定性，电商直播关注的是清晰度，秀场直播关注的则是音质。如果我们给一个在线教育客户去过度地优化画质，客户不仅可能不买账，还可能因为我们的优化影响了其他指标而弃用我们的产品。
音视频的表现不是简单地靠 DAU、成功率来衡量的。比如“切课率”这个指标，影响因素非常多，比如网络波动呀，硬件发热呀，麦克风阻抗大呀，显卡驱动不匹配呀，还有可能是用户心情不好砸键盘呀。就说我们有个客户，发现上课的声音效果不好，结果客户很负责，亲自到了学生家去确认，最后发现是 iPad 的保护套把麦克风给遮住了，你说这找谁说理去？
数据体系建设
排障体系
总结