TiD质量大会在北京召开，有幸去参加了两场，都挺有收货，下面把大会分享的内容，以及一些自己的简单想法写下来，希望能多多少少帮助到一些人。
第一场参加的是Monkey的《移动互联网测试到质量的转变之路》，入这行的人应该都知道Monkey吧，我就不多啰嗦了，下面看看真人：
Monkey对自己的自我介绍：
下面是我相信这些不论是大公司还是小公司都会面临的一些问题：
而这其中最为关键的一点就是：
在迭代如此之快的互联网产品中，如何在这么短的测试时间内保证业务的质量？
这个问题不着急回答，首先我们看看下面这个比较直观的一个期望：
首先提到的是人，也就是测试人员，我们看看对测试人员的期望是哪些：
首先是测试技术：
看到这幅图非常的赞同，我们可以看到金字塔的塔尖就是所谓的“高大上”的测试开发的技术，现在整个行业都太过于浮躁，都是过分的看中测试人员的技术，这样会使得我们脱离我们的本质，我们是测试工程师，但是对测试理论的概念和理解却越来越淡薄，如果整个行业都是这样一直下去的话，那么我们测试行业就会挺危险的，真的有一天可能就会被所谓的测试开发（开发人员）或者是运营测试（运营人员）所取代，因此这里我们一定要注重测试本身的一些理论知识。
接着是一专多能，这里写的比较直观，多说一嘴就是定位问题，取个例子，当我们在测试过程中如果发现一个界面的list滑动特别的卡顿，这个时候就去提交一个bug的时候，开发很容易给你打回来，因为这个是一个主观的东西，这种问题很有可能开发就会说这里不卡啊，然后把bug给你踢回去，这样踢来踢去没有任何的意义，我们需要做的是，最好能直接定位卡顿的问题，然后报给开发，这样我相信开发就不会轻易的给你踢回来了吧。
业务质量占比到KPI的60%，可以看到业务质量是我们必须要保证的，我这里想说说技术提升，这里不是说你学会了哪些哪些技术，而是你学会了哪些哪些技术后落地到了你的项目，并且取得的一定的效果，千万不要纯粹为了提升自己的自己自嗨，这样也不是测试团队的希望的。
最后一个是人员招聘，这个我没有招聘过人，没有话语权，用Monkey的话说就是你会什么并不重要，最low的面试官就是用自己擅长的东西去考察别人，没有任何意义，招聘人员应该注重应聘者学习能力，学习的途径，以及看问题的高度。
Monkey说他之前和一家公司的测试经理交流，那位测试经理告诉他我们的自动化、专项已经做很好了，也投入了大量的人力，为什么我们在整个测试中还是感觉有点把控不住质量的呢？其实这些所谓的自动化、专项在整个产品的过程中是属于比较下游的东西，而把握好上游，就需要我们站在质量的高度去看待问题，这幅图有些看不清楚，等PPT出来之后，我会替换一张清楚的图，这里就是我们需要关注到的一些质量的细节的部分。
接下来讲的是下游的东西：
这里对它提到的三点进行说明一下：
1、客户端ui自动化只适用于冒烟和回归
2、后端的API、接口需要覆盖
3、当需要做类似扫描支付这样的耗电量的时候，往往是配合自动化一起来完成
这个说的很实在不像有些吹的说，我们的自动化覆盖率90%以上，一听就是吹牛。这里提到一个这样一个事情，就是滴滴这样的产品，涉及到司机端和乘客端的时候，这个时候可能就需要一套框架和框架间通信的自动化工具了。
专项测试，这里他建议专项测试招聘一些有经验的人，因为做业务测试的同学大多数情况下是知道了预期结果然后和实际结果比对，而专项测试在得到一个耗电量的指标之后，他也不知道这个指标是好是坏，这个时候就需要用经验值来判断了，另外就是弱网络模拟2G的时候，到底上下行以及抖动、时延该设置多少，这些都需要有经验的人来做。
这里列了一个测试网络的时候需要考虑的到的一些内容：
接下来是质量大盘：
这个比较有意思，
首先说这是什么？这个是每个模块的好坏进行的一个打分评估。
为什么要对这些模块进行评估呢？因为有些场景（例如页面启动时间）测试人员在测试环境下测出的数据往往和线上真实用户才的数据不一致，无法判断是否会对线上用户有影响。
通过什么样的方式呢？通过埋点，在灰度时候的进行评估。
如何埋呢？和普通埋点有什么不一样？首先他们把业务的代码分成了三个层，底层框架层，埋的是普通的事件，其次组件层，埋例如网络相关的，看网络延迟，最上层业务层埋启动时间等等。在得到这些大数据之后，对数据进行一个清洗，然后通过复杂的公式得到一个打分的值。
项目流程比较清洗，没什么多说的。
平台的演变比较有意思：
之前是工具组给业务组做工具，业务组总是抱怨工具组的东西不接地气，并且难用，工具组的同学迫于kpi压力，不断研发新需求，而不修改一些bug，这样导致互相抱怨。改版后，工具组只提供底层基础的服务，业务的同学用工具组提供的能力来开发适用于自己业务的东西。这让我想起了小松鼠和GT。
最后回到最初的问题，而答案呢？就是：
楚门的世界。