MTSC中国移动互联网测试开发大会思考总结

MTSC2019于6.28在北京举办，MTSC是中国测试行业一年一度的顶尖峰会，已经成功举办过四届，每年夏季都会精挑细选出数十个优质的课题供来自全国各地的测试同行们交流学习，课题分别邀请到来自国内外各大公司优秀的团队和讲师前来分享，大会议题主要聚焦在现今测试行业多个方向的前沿技术和优秀实践，涉及到的主题涵盖了移动端、服务端、WEB、IoT智能硬件、持续集成、大数据、人工智能等多个领域，MTSC大会已经逐渐成为了国内外测试行业技术发展的重要风向标。

本人以一个学习者的身份参与了本次会议，在这里简单介绍一些本次的见闻以及感想。由于时间有限，我在参会前确定了自己感兴趣的场次与时间，并在时间表上做好了标记。

议题：持续交付2.0

DevOps是目前业内的一个热点。

亚马逊总裁说，亚马逊的成功是每年、每月、每周、每天进行多次实验的结果。

Facebook总裁说，我最为自豪的事情之一是我们成功的关键在于测试框架。在任何时候，都不只有一个Facebook版本正在运行，而是一万个左右。

他提到了一个3X3的概念，即从提交到发布给内部成员的时长小于3小时，每天Alpha发布3次（11am、1pm、4pm），每周Beta发布3次（1、3、5）。

议题：智能化时代下如何做好持续集成--智能构建和智能测试双引擎

议题：Code Velocity（蚂蚁金融）

代码门禁：

传统先合并，后验证，现在转换成代码先验证，后合并。

为了做到这些，就要求高频、持续：高频跑CI、高频回归、持续测试、持续构建。

其中还提到了一个精准测试的概念，在这里也说明下：

议题：进化的覆盖率-实时代码染色

代码覆盖是软件测试中的一种度量，描述程序中源代码被测试的比例和程序，所得比例称为代码覆盖率，其基本原理如下：

对覆盖率的理解：

一般的代码覆盖率只支持单个客户端的操作数据，为了支持多人协作，他们增加了将客户端的数据传到某个服务器，由务器统一计算和分析，得出总的覆盖率。

同时他们还开发了在页面上实时显示当前操作所应覆盖的代码。

议题：大型游戏项目质量管理与反思

游戏质量管理工作的核心是风险管理，既要提供专业的测试服务，保证产品有更好的质量，也要推动项目组透明的改动、可控的需求、全员质量意识，从而做到更快的发布。

小团队更重视细节和单兵作战能力，大团队要有系统化工具化思维。

通过理解架构可以了解逻辑实现、把握数据流向从而提高测试设计能力。

游戏专项测试一般分3个步骤：场景设计（如何设计覆盖用户的场景）；场景开发；数据分析（结果的专业性代表了测试的水准，结论符合逻辑的，数据和过程是可追溯的）。专项数据本身没有价值（或低），有价值的是场景用例设计以及数据背后的原因。

游戏风险控制包括：事前避免发生、降低概率、控制影响；事中快速恢复安抚玩家；事后总结复盘。

批判性和质疑性思维贯穿整个测试过程；针对每个测试领域尽量多思考，核心关键点尽量把事做到极致。

移动端测试专场

议题包括了：手淘客户端全链路验收、终端软硬件一体化综合测试方案、UC移动云测平台探索、小红书App性能自动化测试平台、移动测试2.0+、基于虚拟化技术的移动真机测试、安卓ROM持续交付及小米云测平台实践、腾讯视频播放下载自动化测试、安全能力SDK交付质量保证实践

大部分项目一开始都是优先业务测试，或者以业务测试为主，随着项目的不断发展，有限的人力难以支撑越来越庞大的业务，就自然产生了自动化测试的需求，而随着自动化测试的不断发展，对平台化、持续集成的要求也就越来越迫切，这个专场主要都是围绕着自动化测试的平台化、持续集成化来展开演讲的，通过平台方便快捷的实现功能测试、性能测试、兼容性测试等，同时结果通过web来展示，达到可视化、可追踪化。

《终端软硬件一体化综合测试方案》提到了：在自动化测试中，利用机械手模拟人手点击滑动拖拽抓取等操作，利用工业相机模拟人眼实现监控设备及录制操作。其中在识别图像这块，运用AI技术（图标识别、OCR识别）

《小红书App性能自动化测试平台》提到了：在电量测试中，智能插座使用NodeMCU（ESP-8266），通过连接到NodeMCU创建的Wifi后想NodeMCU发送指令来控制电源开关。即类似树莓派这种可编程硬件来达到目的。同时他们分享了在测试中发现的一个经验，就是华为使用户对线程数量有要求，超过了就会引起进程被杀。

《移动测试2.0》提到了：介绍Soloπ测试工具，它是一个无线化、非侵入式的Android自动化工具，公测版拥有录制回放、性能测试、一机多控三项主要功能，能为测试开发人员节省宝贵时间。虽然在我们游戏测试中应用的可能性不大，但还是由值得借鉴和学习的地方。

《腾讯视频播放下载自动化测试》提到了：自动化测试中对于常见的播放器问题如何定位的方法：

其中黑屏检测流程：

《安全能力SDK交付质量保证实践》提到了：如何对sdk进行安全合规的测试。为何要进行安全合规测试，因为国内工信部app隐私保护条例、应用市场隐私条例、欧盟GDPR规则、美国COPPA法规。

第一种是通过网络抓包，然后对数据结果进行人工分析，看看是否有不合规的情况。

第二种是动态隐私代码监测。监控sdk运行时是否有调用系统隐私api接口。

高新领域专场

《智能设备硬件准入标准建设》提到了：AI智能设备的特点具有语音交互能力，重点包括听、说和语义理解。AI智能设备的首要挑战是听清，针对不同类型的用户（口音、年龄、地域等）和使用环境（信噪比、距离），AI设备均能听清。听清受到软硬件影响：

测试一般采用下面的方法：

《爱奇艺推荐质量保证》提到了：通用推荐系统测试方法一般包括下面3种：

离线实验：在离线数据集上通过离线指标预测算法推荐效果。但其痛点是离线实验无法准确评估对产品线上指标的影响。

用户调查：通过真实用户给出主观反馈，评估产品的体验。但其痛点是用户调查成本高、实施难。

在线实验：能评估产品指标（商业指标），比如人均点击、次日留存等。但其痛点是在线实验周期长、反馈模糊。

面临的挑战是如何把真实感受量化为指标、如何在线上快速收集反馈并聚焦发现问题。

针对上述三个涉及的痛点，爱奇艺推荐质量保证进行的完善：

线下测试：通过正确性测试和合理性评估，达到快速交付的目的。

其中正确性测试保证没有严重功能及体验性问题，涉及点如下图：

合理性预估通过建立离线指标基准线，校本化执行并自动分析结果，确保上线后没有明显的复现波动。这些基准线包括：算法实时性、内容时效性、内容多样性、互动指数等。

小流程实验：效果指标统计及分析。产品指标横向对比评估结果，结果回溯定性分析聚焦问题。横向对比效果指标，通过指标波动衡量效果：展示量、点击量、CTR、UCTR、次留、人均播放时长等。

线上质量：质量监控。监控及时发现问题，定期评测产品体验。核心指标波动幅度异常马上报警，功能性问题能马上召回。

《基于深度学习的UI异常检查》提到了：初衷是基于下面的4个痛点提出的：

1：目前市场上有很多?自动化测试框架（UIAutomator，Airtest）他们可以基于一定的验证点来判断成功失败，但是对于一些UI样式异常比较难于验证

2：长期以来对于UI样式问题，多数依赖于人工手动测试发现

3：前端自动化测试在发现UI样式异常方向一直是比较空缺的

4：随着移动时代的快速发展，越来越多的移动设备、操作系统版本导致组合爆炸，UI样式异常可能被测试人员遗漏

UI异常一般有文案出现重叠或遮挡，文案出现乱码等情况。类似这些问题出现的位置，出现的文案内容均有不同，在不同的机型，不同系统版本上出现的表象不一样，使用经典自动化测试工具设置验证点检查难度非常大。这里使用了基于深度学习的一种检测方法。

深度学习首先要收集学习资料。通过爬虫在公司的bug库中，提取有问题的图片作为学习样本，同时也通过手动构建训练样本，比如设置代理，限制网速，复现部分场景、模拟问题表象，使用绘图工具扩充样本内容、四个方向分别平移若干像素，缩小和放大。

最后形成如下图所示的一套针对UI的自动化测试流程框架：

算法在测试中的实践—如何进行自测评估提到了：这里他们做了一个比较有意思的东西，就是当开发人员提交相关代码后，通过这个算法模型去判断需不需要QA人员进行测试。如果测试就通知QA，不需要就直接进入版本库。好处是：减少沟通，减少测试人员工作量，开发自测缩短交付时间，减少了代码评审时间。

这个算法模型大致是通过词法语法分析、计算调用频度、建立相似度计算模型，以及历史日志，两个维度去训练数据，最后达到一个预测的目标。

语音识别评测体系及其自动化提到了：语音识别的关键指标如下：

1：唤醒率：不同角度、距离，不同噪音环境下唤醒率

2：识别率

3：识别速度：不同网络下统计从发送语音指令到播报响应内容的时延

4：误唤醒：播放一段不包含唤醒词汇的常规音频，测试24小时统计唤醒次数

测试的语料一般来自合作厂商提供、自己录制以及TTS合成。然后结合adb，使用脚本控制声音通过不同的通道输出到不同位置的音箱，最后通过日志监控、官方后台监控、人工听取应答的三种手段获取语音识别结果。

质量保障专场

同时他们也提到了，即将开源一个全新的针对小程序的自动化框架。

《质量罗盘—看得见的质量》提到了：比较有用的一点是，当看到现状存在问题，提出解决方案并且实施的时候，要指定要观测的数据，即在执行的前后，要有可视化数据进行对比，这样才能有说服性。还有一个值得我们思考的问题是，如何在自己的游戏项目中，指定一些可视化的数据，去定量的分析目前的版本质量，甚至，不同项目的数据如何进行一个横向的对比，这些值得根据自己项目的实际情况去思考。

优酷视频生产质量保障提到了：视频生产质量保障体系主要分为3大类，用下图表示：

日常质量保障中，生产链路自动化测试指的是从上传入口到转码完成，监控各个异步消息、节点日志，检测转码完成后的数据，检测转码完成后的视频质量。

在上诉视频检测能力的基础上，开发了视频质量平台，其架构如下：

《科大讯飞百亿级交互业务的缺陷预防之路》提到了：从3个角度阐释引入缺陷预防的必要性：

1：从qa的角度，qa同学每日烦恼

2：从项目组的角度，需求返工、功能不符合预期、风险不可控、发布推迟

3：从用户的角度，用户反馈不好用，不是想要的

缺陷预防的七大实践：

1：需求解耦。我理解的就是各个功能尽量保证小、轻

2：需求测试：就是需求评审

3：jira构建规范：就是技术方案评审

4：版本质量考核体系：开发自测。建立合理的考核标准，建立奖罚制度，按月汇总，将版本质量考核成绩变现为研发绩效加分，并在团队内公示形成浓郁的质量内建之风。

5：版本发布构建规则：有序的发版制度；规范CI构建说明；diff代码，重视每一行提交的代码

6：缺陷复盘

7：版本粒度精准切割。我理解的就是每个发布版本的内容要合理规划，不能有时很多，有时又很少。

《微医多维一体化监控平台实践》提到：监控一般有黑盒监控和白盒监控。

黑盒监控：通过测试某种外部用户可见的系统行为进行监控、面向现象，代表了目前正在发生的问题，即什么东西出故障了；黑盒监控可保证系统在某个问题正在发生，并造成某个现象的时候就会发出报警。

白盒监控：依靠系统内部暴露的一些性能指标进行监控，如日志分析、链路分析等；面向现象和原因，依赖对系统内部信息的检测，感知为什么故障；白盒监控可以检测到系统即将发生的问题以及分析系统出现问题的原因

常见的监控分类有：

应用层面的监控：包括服务的可用性、请求量、链路状态等，以及APP 端的 Crash 率，卡顿、ANR等。这里要特别说下链路监控，我们是链路监控呢？链路监控的原理最早是由Google Dapper 提出的，是一个分布式的监控系统。链路监控（TracingAnalysis）为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等工具，能够帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈，提高微服务时代下的开发诊断效率。那为什么需要链路监控呢？随着微服务架构的实施，各大型系统解耦成多个微服务，一个完整的调用过程可能横跨多个服务，各服务调用情况会变得很复杂，复杂的调用导致很难对故障进行定位。

运维层面的监控：包括主机服务器资源，如CPU、内存、网络吞吐和带宽的情况，以及服务器上的各类中间件运行状况等。

业务层面的监控：包括核心的业务指标，用户行为，以及用户舆情等。

安全层面的监控：如安全态势感知，用户行为风控等。安全分为系统安全和业务安全。系统安全一般包括主机安全、网络安全、数据库安全、威胁情报（开放漏洞、代码平台、云盘）；业务安全包括行为风控（登录、注册、找密、交易、优惠券）和内容风控（文字、图片、语音、视频）

《网易云音乐质量可视化实践》提到了：如何进行研发质量可视化和产品质量可视化。

可视化是工具，质量可视化的重点仍在质量上

流程标准化是基础，要确定权威性，要平台化

管理可视化是重要组成部分，有助于标准化落地

产品质量可视化使得线上监控手段融合成为一个线上监控体系

TTF开源专场&质量保障专场2

《混沌工程在创业公司的实践》提到了：在生产环境开展一些系统弹性的测试。混沌工程的基本实施步骤如下：

混沌工程的第一步就是要进行故障场景的抽象：

然后进行故障模拟：

那么如何判定系统的防御能力呢？一般有如下的指标：

当然有些故障发生的时候，系统并不能自愈，需要开发人员介入，但这个也可以作为混沌工程的一个测试维度，即检查开发人员的响应速度：

工程效能专场：

《陆金所造数服务》提到了通过mock造数以及可视化造数，从而提高测试效率。

《流量回放在多耦合系统重构中的实践之路》和《测试和流量博弈的实践之路》都是介绍在流量回放对全链路进行测试过程中遇到的一些问题，比如测试如何流量提取、测试过程中如何降噪处理、测试流程如何绕过鉴权控制、测试流量如何编辑；如何在海量流量中，挑选出流量最小集以达到最高覆盖思路和方法，突破了传统随机流量选取的局限性，减少重复或无用流量消耗，提升测试的覆盖度和稳定性。

《苏宁易购亿万规模性能实践之sql调优》提到了：数据库架构设计的基本原则：

以及数据库优化的维度：

衡量sql性能好坏的标准是：执行耗时短、资源开销小、执行计划好。一般sql优化的主要思路有：减少sql的执行时长、减少IO的消耗、减少cpu的消耗和减少sql的调用解析次数，最终达到数据的高性能访问的目的。

一般监控mysql的工具是showlog和innotop这两个工具。

创建高效索引一般的方法如下：

Sql优化的一般流程如下：

结合他们公司的经验，给出了几点建议：

《百度持续集成发展、挑战与愿景》和《持续集成领域的智能调度探索及实践》提到了百度在持续集成方面的探索和目前取得的成绩。

《机器学习在提升持续集成构建准确性和召回率的应用和思考》提到了：随着工程能力的建设，环境依赖复杂度增加，带来更多测试结果验证的置信度问题，比如及时相同版本间的测试结果，依然存在3%+的性能gap，这个报告结果是否准确？一些指标的变化达到9%+，这种变化是否合理，这个合理是否可以通过？

通过分析，发现影响报告结果置信度低下的因素主要有两个：阈值和误差。

阈值主要是因为人工设定阈值无依据。阈值设定随意，无任何实际及理论依据支持；迭代升级，维护频繁。然后他们采取了一种动态阈值预估计算方法（分位数和指数平滑法）：通过对历史的报告结果分析，预估出该系统所处测试环境下的各个指标的系统波动区间，作为该指标最终的阈值区间。

误差主要是因为：

1：模块自身随机逻辑。当模块有大量随机逻辑时，及时同版本压测结果也依然存在大量的diff

2：不同机器间的结果对比。不同性能配置的机器，压测结果可对比性差。

3：流程构成时刻变化。线上流量构成千变万化，不同流量命中不同逻辑分支，测试结果影响极大。

然后他们采用L-R机器学习（L-R线性回归模型），对结果进行预估。

《图像识别在测试领域的运用》提到了：目前UI视觉分析在前端测试领域现状：

UI视觉技术应用的痛点是多机兼容性差和动态内容干扰。然后介绍了百度的iCheck技术框架，这是一个基于easyDL的深度学习对象检测方法。

游戏测试专场

《画面异常检测的三阶段及AI实践》提到了：运用深度学习的方法自动检查游戏画面中的异常，和之前的的分享课题《基于深度学习的UI异常检查》有点相似。最后他做到的效果如下：

《如何做好游戏项目的性能管控》提到了：如何用uwa工具去跟进游戏研发过程中的性能问题。

一个团队之所有优秀，并不是因为他们从来不出问题，而是因为出了问题之后可以快速调整、迅速解决。质量管控就是其中的关键。

《图像识别及自动探索在UI自动化中的应用》提到了：基于图像的UI自动化正在逐渐成为UI自动化测试的主流。Wetest对图像识别算法进行优化，满足了基于UI的自动化测试需求。

服务器压测主要包括三个：容量测试、12小时稳定性测试、容灾测试。

《企鹅电竞直播质量体系建设分享》提到了：对于直播，质量的度量标准一般是：

其对应的测试方法一般是：

目前的直播间压测方案如下：

线上直播质量监控维度如下：

同时也引入了AI对直播画质异常检测，方法如下：

《游族服务端专项测试》提到了：服务端安全和服务器性能。服务端安全的话，通过hook客户端的部分方法，将消息进行展示，修改后，放回客户端，通过后续逻辑，进行发送。

《多维度版本质量的提升与保障》提到了：客户端性能内存参考值：

Cpu占有率参考值：

帧率参考值：

机型适配基础要求：

最后还有4个分享是来自腾讯互娱天美工作室，由于保密原因，他们的ppt没有公布出来，我听了下来，对我们项目有参考意义的几点是：

1：他们再做FPS游戏的中，会对场景中的物件做一个自动化的浮空检查，是否提问了其实现的原理，其问题说就是用unity中的射线检测法。首先获取整个物件的坐标，然后从这个物件是发出射线，看看和地面的碰撞距离。

2：web端实现接口测试。比如成就系统的接口测试。

3：之前流行的探索性测试，在游戏行业实行起来比较难，主要是当你完成探索性测试的时候，很难回答是否测好了这个问题，而这个问题，是项目组关心的，项目组希望质量是数据化、可视化的。

首次参与MTSC会议，总体来说，不论是当前的一些趋势走向，还是各个大厂的实践思路，都还是带给我不少的收获与启发。作为一个游戏行业的测试人员，听一些其他行业的测试人员分享的测试方法，有些方法真是大开眼界，非常有趣，可能对工作没有很大用处，但的确开了眼界了，不然就像井底之蛙。同时也意识到，我们做的还远远不够，还有很多东西可以去做、应该去能、能够做的更好。

建议大家在参与会议之前针对自己挑选的议题做一些简单的调研和预习，避免在演讲时陷入一脸懵逼的状态（比如我这次在听midway框架的分享时，由于不太清楚其诞生的背景，全程就有点迷）。

最大的遗憾是没能去跟讲师多做沟通，个人感觉分享的内容再怎么精彩，能带来的收获终归还是有限的，能与技术大牛现场直接沟通技术细节才是参与大会最大的优势，可惜这次没能好好利用。