【腾讯Bugly干货分享】移动互联网测试到质量的转变

摘要：每周都会举行嘉宾分享，话题讨论等活动。本期，我们邀请了测试技术社区联合创始人陈晔，为大家分享移动互联网测试到质量的转变。分享内容简介在移动互联网越来越快的迭代项目中，很多测试人员和测试团队都开始觉得力不从心。

本文来自于腾讯bugly开发者社区，非经作者同意，请勿转载，原文地址：http://dev.qq.com/topic/57ee0...

Dev Club 是一个交流移动开发技术，结交朋友，扩展人脉的社群，成员都是经过审核的移动开发工程师。每周都会举行嘉宾分享，话题讨论等活动。

本期，我们邀请了 TesterHome 测试技术社区联合创始人“陈晔”，为大家分享《移动互联网测试到质量的转变》。

分享内容简介：

在移动互联网越来越快的迭代项目中，很多测试人员和测试团队都开始觉得力不从心。很多团队和公司都开始讨论怎么保证质量，事实是单纯的从测试和测试团队出发都无法保证产品的质量了。是时候从技术以及思想上开始转变了。

下面是本期分享内容整理

好的，感谢大家今天晚上能来参加这个分享。时间有限，我先自我介绍下，大家看一下就可以过了。

首先先看下今年我到各个公司交流的时候，大家最常问的一些问题吧。

其实总体来讲测试行业现在还是有很大进步的，既关注了整体策略也关注了技术细节。但其实比较奇怪的是其实大部分人关注的还是别人怎么做，就是特别的缺少的从自己公司的产品业务和团队情况去思考问题。这不得不让我想到“别人家的xxx”这样一个场景。当初我在做这个“测试到质量”转变的时候我就是希望贴近主题尽量从全面的去阐述测试到质量的变化。 总体来讲，还是测试行业太过焦躁，我们总是偶尔的很积极的想去了解，想去学习，但这不可持续发展，这就好像我们会去存很多pdf和网站，但从来不看是一个道理。

今天在群里的都是开发同学，其实就我的了解，大部分的开发同学都知道测试的重要性，但其实本质上并不知道测试具体要做什么或者说怎么做，再比如测试工程师到底应该具备什么样的能力也不清楚，反正就是是一个模糊的概念。

所以我想先强调下，今天我和大家说的并不是一种测试的理想状态，而是现在移动互联网，这样一个快速发展，变化的行业测试应该有的姿态。以前国内互联网行业中的测试相对不是很规范，流程也好，技术也罢。但近几年越来越走向正轨，所以也希望各位开发同学能够一起努力把产品的质量做好。

就如我这边说的，现在快速的发展依靠传统的测试已经不可能完成了。那么什么是传统的测试方式呢？传统的测试方法就是只关注“ui自动化，单元测试，接口测试，持续集成，回归测试，冒烟测试等等”。

这些可以说是测试行业不变的关注点，但在现今的移动互联网，单纯的关注这些已经远远不可能保证我们的产品质量了，希望很多开发和测试都有这样的感觉。所以这就是今天我们要来讲述的测试到质量的转变。只关注测试的测试已经死了，我们所有人都需要把关注点放在质量上

切入点有这样两个：

一个是人，这里的人先还是比较关注在测试身上。

另外一个就是流程，流程中的每个细节都是质量保证的关键点。

由于今天的时间关系，无论人还是质量上面，我都会挑选部分来说，如果大家感兴趣所有的点，以后可以再挑时间来分享哈。

之前有很多文章讨论过所谓的“全栈”，其实至少从现在来看，“全栈”真正的意义随着时间的推移也开始浮出水面——快速学习的能力和驱动持续学习的兴趣。

第二点其实想表述的就是如果我们走出测试来看质量的话，几乎所有事情都不是单纯的测试个体或团队能够完成的。我们需要走出那个“你提需求，别人实现”的时代，取而代之的是“你提需求，你牵头来实现”。我们需要去利用合适的资源去做合适的事情，而不是什么都自己来做。

在我参加的很多大会上都会有这样的问题，一个团队是否都应该是这样一专多能，全栈的人。在我的理解里，一个团队中其实肯定不能没有全栈的人，也不可能都是全栈的工程师。但这里其实特别的去强调了“定位问题”。举个例子来讲，我们在平时测试的过程中发现了一个问题，我们需要有能力去判断这个问题是前端还是后端的，如果是后端的，那么通过各个系统日志和调用关系需要去明白问题出在什么系统上。如果是前端，那么我们需要去发现是框架层的，还是组建层的，还是业务方等等。也就是说其实无论你是功能测试、自动化测试或者架构，定位问题都是通用的要求。

其实之所以要求测试能够有定位问题的能力，本质就是为了提升整个项目流程的效率。因为当我们发现一个问题的时候，以前的方式是测试直接报一个bug。这个bug会描述清楚问题的上下文和现象。但其实开发还是需要去排查问题，然后再fix。也就是说排查问题这个过程是免不了的，而且往往测试并不知道这个问题是哪个开发的头上，容易出现A踢皮球到B，B再踢给A的情况。所以在现在的测试行业中，大部分的公司索性就要求测试需要有定位问题的能力，这也是一项基础的能力。

这点我特别的强调下，因为现在整个行业都在追求技术。我们在很多网站可以看到这里很牛的hook技术，那边有很牛的遍历技术等等。但行业却慢慢的弱化了测试原本需要有的技术能力。比如测试策略的制定，比如测试的方式，测试用例设计的方式等等。我很担心再过10年，测试行业都是一群技术很牛却不懂测试的人。就好像我已经听到很多测试同学和我说，很多公司的测试总监不知道ab test 和灰度发布有什么区别，竟然认为两个是一个东西。让我也是很担心测试行业的发展。

好了。以上我就挑了关于“人”这个方面的几个点和大家阐述下。关于测试流程来讲的话，其实测试本身还有很大的挖掘点。

我给大家举个例子：

其实互联网发展到现在，测试大部分的技术，无论是自动化，还是动态AOP的hook等，其实我们想想，这些技术都是存在于“测试中”或者“测试执行”过程。但我们的流程中还有两个很大的空缺。一个就是测试前，我们叫做测试准备，一个就是测试后，也就是我们的测试结束后。这两个阶段可以说是非常空白的。

测试准备这里其实包括比如说“测试用例的自动生成”，“数据的自动化生成”。我相信很多人听说过“MBT”，就是基于模型的测试，这就是一个比较成熟的case自动化生成的方式。

在移动互联网中，BAT中一些公司会使用线上导流的方式，从而能够直接回放线上用户的行为，这样既能够自动的准备测试数据，也可以省下编写自动化测试用例的时间。但这里要注意的是和用户相关的敏感信息的脱敏。

而在测试结束，也就是我们的灰度以及我们发布之后的话，那就是我们之后说的质量大盘的事情了。让我们接着往下看吧。

由于时间关系，所以我就挑选几个点来讲。首先是自动化，这个可以说是测试比较注重的一块。

UI自动化其实在几年前，整个行业都还是在搭建自己的框架或者自动化团队，包括积累很多的自动化用例。但经过这几年发现基本上是不可行的。最大的原因就是UI自动化的ROI太低了。在现在这样一个快速发展的移动互联网下根本是没有办法可持续发展的。

那么现在的大部分公司为了更好的支持hybrid（混合式应用）的模式，那么选用了开源的Appium。当然这些公司并不会直接使用appium，而是拉出appium比较稳定的一个branch，然后自己来开发，并将appium根据自己的页面封装成适合自己的框架。

而UI自动化不在会是每次迭代都会去增加case了。也就是说会将那些很核心，不怎么变化的流程编写成我们的冒烟case和回归case。而在冒烟的时候，根据提交的代码属于哪个bundle，然后会去调用对应的case，并不会每次打包都跑全量。同时regression的话也是一样的，会有一套稳定的用例。这是基本上现在大部分公司选择的方案。

而自动化中的API会要求比较高，比如API的代码覆盖率，业务链路的覆盖率，本次feature涉及到的API的数量的覆盖率等等。这些数据会完完全全的去影响这个系统是否会发布。因为现在移动互联网的app大部分的逻辑都会在后端，包括现在的hotfix都是依赖服务端的能力，所以对于后端的测试基本上会有一套完整的准入准出标准。但对于app前端就相对会弱点。

我们在App的专项测试中，自动化也会扮演非常重要的角色。如果对于专项测试不了解的朋友，我们以后可以专门开一个专项测试的课，专项测试可以讲2个小时了。自动化在专项中的角色其实主要是为了获取长时间的app性能数据。

比如说我们要获取一个连续支付3000次，或者某个功能连续使用6小时下的耗电量。那么这种情况我们就需要那种能够脱离usb的自动化框架的支持，例如android的uiautomator。

所以总结下，UI自动化其实就是为了保证我们的核心功能是正确的，不会出现很大的regression的问题。我们不可能依赖UI自动化去提升质量。最多也就是保证核心的质量。

然后出现了这样的一个问题。

我相信任何一个人面临这个问题的时候，都是右边的这个脸。我其实很想回答，臣妾做不到啊。

我们的测试人员是有限的，我们的测试环境也和线上环境不同。我们的测试机也不可能有线上用户那么多。你让我说数据要一样，我肯定说不一样，但如果我说不一样，那么老板肯定会想，我投入那么多人力，资金等于没有用啊。所以就会面临两难的境地。

所以就这个问题之后出现了“质量大盘”这个概念

我这里大概的列了质量大盘的一个制作流程，这里我无法和大家说细节了。大家如果有什么问题私下可以咨询我哈。

我说下质量大盘的目的：

为了让所有的人明白现在产品的质量，因为质量大盘上面是会根据一定的公式算出分数。这样无论是不是技术人员都能够一目了然这个产品每天的分数到底怎么样，以及长时间的趋势是怎么样的。

质量大盘会在每个楼层的办公室里public出来，这样也会被动的让那些PM，PD，Dev，Tester去知道自己和别人产品的分数。被动的可以push大家去提升自己负责模块的质量。

能够减少一定的测试工作。因为质量大盘的数据都是通过线上大数据总结得出的。更贴近用户的痛点，这样团队能够第一时间去着手解决用户的痛点问题。而不是仅仅通过测试环境里的数据。

这是我通过百度的echart做的模拟图，基本上就是分成这样两块。一个是每个模块，每个业务的分数（左边的），一种就是总体的分数趋势（右边）。T+1会在质量大盘上显示。

我们再来看下每个公司都会有的这个工具组的境地，基本上每个公司的工具组都会出现这样的问题。做工具的这些同学其实也很苦恼。

之后改变成了，这个工具组会变成一个平台建设组。这个平台建设组就是输出通用的sdk，数据的存储以及前端的展现。至于每个BU自己的需求，每个BU 基于这个sdk和平台的功能自己去封装和实现。虽然我觉得这并不是一个最终的解决方案，但至少比之前的方案来的好，也更容易落地。

所以我们回到这个问题上来，我们怎么很快的迭代下保证产品质量呢？

从本质上我们需要认清，无论是谁，无论什么架构都不可能在移动互联网下去保证产品的质量，这是绝对不可能的。我们只能保证产品核心和很重要的模块的质量，但不可能说我们保证产品的完整的质量。

从思想上，我们需要转变的是，以前我们认为在项目流程中我们通过测试，通过bug bash，通过各种方式在上线前保证我们产品的质量。但现在我们需要转变，我们需要利用线上，利用用户，帮助我们一起去保证产品质量。我们不要担心线上出问题。所以我们需要一套质量体系，当出现问题的时候，第一时间能够预警，能够hotfix，能够动态的更新，能够及时应对。这就是我们在移动互联网下应该有的质量思维。

就如刚刚的这张图。这里所有都是质量体系的一部分。

这张图是电影中的，很多人都知道吧。“楚门的世界”，其实测试就如同楚门，那么多年都在测试这个圈子里走来走去，就好像我一开始说的，关注UI自动化，功能测试，api测试，持续集成等等。其实本质上，关注这些根本无法从本质去保证质量，更不要说提升质量。所以我们只有跳出测试这个圈子，站在质量的这个角度，才能够真正的看到更全面的东西。比如产品的架构，代码的规范，每个milestone的准入准出，怎么灰度，怎么利用大数据等等。这些都是测试需要关注的。也是每个关注质量的人应该关注的。

好了。由于时间关系，今天就是到这里。其实很多扩展的，可以放在以后的课程哈。

谢谢大家！

问：请问单元测试应该由谁来做，是自动化测试的重中之重吗？

你好～单元测试从软件测试的定义上来讲是由Dev来做的，无论测试多么的了解代码都不应该由测试来讲。在以前微软的流程中，有一种测试叫做bvt。也就是每个开发的模块如果要check in，需要代码跑过自己的bvt的单元测试，才能够check in。
另外说比重的话，其实要看测试的对象。不同的对象比重不同。我举个例子，如果是app，现在整个行业的UT的比例很低。但如果是中间件or sdk这种，单元测试可能比重会很高。

问（接上）：非常感谢回答，不好意思因为这个问题困扰很久了所以想再问的细一点。从微信还有手机管家的经验来看，似乎在项目初期并不需要ut，往往要到很后期产品稳定才会做，但是大部分的产品又并不会走到后期，而主流的测试模型又很推崇ut，所以是不是有点矛盾？

并不是。其实这就是我说的测试策略本身。就好像我们说吃饭是对的，喝水也是对的。但如果一天你吃10顿，吃10升的水，你也受不了。所以说本身还是有一定的上下文。首先UT本身其实是为了保证模块，多带带模块或者几个模块耦合度比较高的情况下的质量，也就是所谓的代码质量。这和产品稳定不稳定关系不大。之所以会有这样的理论是因为在不稳定的时候，大部份的开发都在忙着重构或者写功能，没有空去写UT，所以才会说等稳定之后去做。
测试模型推崇UT也是对的，因为测试偏重质量，质量本身，代码的check in就应该有开发的测试。我们叫做自测。那么现在移动互联网下，大部分的公司其实是没有UT的，所以开发就会手工的去跑一些功能测试，以保证自己模块的质量。
所以说从本质上说，这两者并不矛盾，只不过是怎么做效率高，怎么做真的能落地就会怎么做。倒不是说理论or模型说一定这样做就一定这样做。

**问：做了几年测试，今天讲师介绍的很多观点都很认同。想问几个问题：
1，线上导流方式 直接回放线上行为，有哪些实现的方式，能举例介绍一下吗？
2，质量大盘产品不同指标也不同，如何设计认为是能全面合理体现质量标准的呢？能举个具体事例介绍一下吗？如何具体真实的衡量一个产品的质量打多少分？业界哪个公司哪个项目在这方面做的很好能借鉴吗？能介绍一下吗？**

关于第一个问题，我举个例子。比如客户端的h5的测试。那么无论是灰度，还是线上。我们可以通过代理服务器直接透传的方式，记录访问的h5的链接，包括req，res data等。这些数据可以通过在客户端的webview容器直接访问的方式进行回放。当然这个过程中细节很多，可以用的框架比如anyproxy。
第二个问题，我举个实际的例子。比如说每个界面打开的响应时间，那么我们根据每个界面的PV，UV来定每个界面的权重，我们再根据不同的网络状态，不同的手机下去定不同的公式来做计算。当然这个公式是需要大家讨论的，比如Dev，Tester，PD都需要一起讨论。然后最终定出来一个公式，会放入大数据的计算中间。

问：移动端的兼容性自动化测试老师有好的方法成熟的案例介绍吗？

兼容性的自动化有的。如果是你是需要自己公司去搭建 ，那么现在github最好用的就是“STF”，在TesterHome上面你可以找到我写的二次开发“STF”框架的文章，还是很详细的。如果你需要用第三方的话，那么目前已有的几个平台也都是ok的。

问：如果是老师会怎么去衡量一个测试人员的价值？或者怎么去看一个工具的roi？

这个是招聘的要求，其实主要是在经验，技术还可以的情况下，接下来就是看问题的高度和大局观。然后说我们怎么衡量一个人的价值。basic的话其实就是活干的怎么样，其实不一定是发现了多少bug。现在行业中也有EP团队，工程效率团队。也就是说，只要提升了效率，就是有产出的，就是有价值的，这个提升可以是流程任何一个环节。
当然还有一点就是需要有感染力，需要带动测试团队，开发团队。乐于分享，追前沿的技术，包括乐于助人等等。这些都是价值考量的一部分

所以基本上是这样三大类。
工具的ROI，其实就是比较好评估。比如说这个工具能节省多少的人力。现在很大的情况下是用了工具，人力还是要保证一遍。这样等于0。所以就工具而言，一个是改造需要的投入，一个就是真正提升的效率有多少。包括维护成本多少。基本上是这样几个维度。

更多精彩内容欢迎关注bugly的微信公众账号：

腾讯 Bugly是一款专为移动开发者打造的质量监控工具，帮助开发者快速，便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash 根据根因合并分类，每日日报会列出影响用户数最多的崩溃，精准定位功能帮助开发同学定位到出问题的代码行，实时上报可以在发布后快速的了解应用的质量情况，适配最新的 iOS, Android 官方操作系统，鹅厂的工程师都在使用，快来加入我们吧！