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

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

1. 测试已死，关注质量才是王道

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

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

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

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

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

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

2. 一专多能

切入点有这样两个：

一个是人，这里的人先还是比较关注在测试身上。
另外一个就是流程，流程中的每个细节都是质量保证的关键点。

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

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

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

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

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

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

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

3. 质量体系的建设

我给大家举个例子：

其实互联网发展到现在，测试大部分的技术，无论是自动化，还是动态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自动化去提升质量。最多也就是保证核心的质量。

4. 测试技术还只是刚刚起步，将来是数据的天下

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

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

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

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

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

我说下质量大盘的目的：

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

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

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

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

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

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

5. 从思想本质上改变对质量的认识

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

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

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

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

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