第1章 测试观概述

1.1 引言

在正式介绍iOS测试前，先为读者引入一个思  考问题：一千个人有一千种测试观，那么测试人员到底应该持有何种测试观？我们先来看看测试的定义发展史。

20世纪60年代：软件开发过程中，将测试等同于“调试”。

1957年，软件测试区别于调试，成为一种发现软件缺陷的活动。

1972年，在北卡罗来纳大学举行了首届软件测试正式会议。

1975年，John Good Enough和Susan Gerhart在IEEE上发表了文章《测试数据选择的原理》，从此软件测试被确定为一种研究方向。

1979年，在Glen ford Myers的《软件测试艺术》中，定义“测试是为发现错误而执行的一个程序或者系统的过程”。

1983年，Bill Hetzel在《软件测试完全指南》中指出，“测试是以评价一个程序或者系统属性为目标的任何一种活动，是对软件质量的度量。”

2002年，Rick和Stefan在《系统的软件测试》一书中对软件测试做了进一步定义，“测试是为了度量和提高被测试软件的质量而对测试软件进行工程设计、实施和维护的整个生命周期过程。”

软件测试的经典定义：在规定的条件下对程序进行操作，以发现程序错误、衡量软件质量，并对其能否满足设计要求而进行评估的过程。——百度百科

以上测试（软件测试）的定义都没错，那么测试工程师应该怎么做呢？

通俗一点来解释，笔者理解的测试为：测试=工程效率+品质管理。相应地，测试人员做的事情就是提升工程效率，做好品质管理。引用谷歌团队的一段话[1]：Essentially, every day we ask ourselves, “How can we make our software development process more efficient to deliver products that make our users happy? ”其中“make process more efficient”可以理解为工程效率，“make users happy”可以理解为品质管理。就像上面谷歌团队的这段话，测试人员应该每天思考怎样提升团队的研发效率，怎样提升产品品质来让用户满意。

1.2 工程效率

总体来说，工程效率就是研发效率（包含测试效率）。这里我们会把测试效率单独提出来进行说明，因为这是与测试工程师相关度最大的工作。研发效率，其实就是让产品上线的时间更快（在品质有保障的前提下），大多数时候是说与研发流程相关的（不局限于敏捷流程，Feature Team研发模型），例如包含但不局限于以下活动。

❑需求评审：需求评审机制以及更新通知，避免需求有改动而没有及时同步到相关角色。

❑代码质量：静态代码扫描，千行代码缺陷率等。

❑架构评审：代码架构的讨论以及评审。

❑Bug流程：Bug生命周期，避免随便修改Bug状态以及备注缺失。

❑Code Review：代码评审，如果有代码评审委员会就更好了。

❑Dogfood：自己做的产品自己（项目各成员）先体验。

❑Showcase：完成某个特性，可以通过会议针对某个特性进行展示，一般由产品经理主持。

上面提到的活动，只有通过整个项目团队（各个角色）的通力配合，才能更加高效。

再提一下测试效率，这大多数由测试工程师主导，也是测试工程师最主要的工作内容。测试效率包含但不局限于以下这些活动。

❑测试周期：测试与研发周期是密切关联的，包括迭代测试、集成测试、回归测试、上线测试等，每个阶段都要把握好测试效率和测试资源分配。

❑测试设计：包括需求覆盖度、用例覆盖度、用例执行效率等。

❑自动化测试：使用自动化执行的方式进行测试，可以快速得出测试结果，节省人力成本。

❑静态代码分析：使用一定的工具来对代码进行静态扫描，提前发现代码隐藏的问题。

❑测试技术创新：通过对测试技术的创新，例如精准测试、机器学习等方式，来变更测试方式，大幅度提升测试质量和效率。

接下来举两个例子具体看下。

1.2.1 自动化测试

自动化测试于20世纪90年代才开始逐渐成熟，特别是敏捷研发的流行以及推崇的TDD模式，自动化测试也逐渐流行起来。对于自动化测试，我们还是得多关注其投入产出比（ROI），特别是对于UI自动化测试。业界自动化测试金字塔模型建议做单元测试或者接口测试多于UI自动化测试。关于自动化测试投入产出比，请参阅第6章介绍的内容。

对于iOS平台上的自动化测试实践，我们也有在不同方向上的尝试（参见第5章），并都有不错的收获。相关自动化测试的开展还需要有一些自动化测试框架的支持（详细自动化测试框架的内容会在第7章介绍）, QQ浏览器（iPhone）测试团队主要移植Google开源的EarlGrey框架来作为自动化测试的基础框架。本节先简单介绍几种主流自动化测试类型。

1．BVT（Build Verification Test）

业界现在流行持续交付的模式。那么每次持续集成编译出包后，自动化会运行一些基础功能测试用例，保证版本基础功能可用，而不会因为新代码合入影响基础功能。这部分主要介绍UI自动化测试，当然，随着版本需求的变更，维护成本也会增加。但对于QQ浏览器的UI变更还不是很频繁，维护成本还相对可控，整体的投入产出也不错，具体可参考第6章的内容。

2．监控类

根据产品的业务特点，我们会对产品进行一些监控，例如手机QQ浏览器（iPhone）项目实现了三种类型的监控测试，即终端视频嗅探监控、终端feeds流短视频可播性监控、终端资讯类监控。这部分监控的基础框架和BVT实现是一致的，只是基于业务形态做了调整，采用的也是EarlGrey框架并进行了二次开发。可参考第6章关于测试框架的二次开发。

3．性能自动化测试

性能测试涉及各种数据的采集和分析，而数据采集往往很复杂并且非常耗时，性能自动化测试也都集中在数据采集这一块。目前我们针对页面速度、产品稳定性、电量、流量、内存等各个方面进行性能自动化测试的尝试，详细内容请参见第4章。

1.2.2 静态代码分析

静态代码分析就是在不执行代码的情况下，通过一定的算法规则（词法分析、语法分析、单函数分析、代码段分析、数据流分析、资源分析、依赖链分析、更高级的智能逻辑分析）对整个工程的代码进行分析，以此来找出代码中的缺陷。这样就可以提早发现问题，大大降低研发成本。美国软件工程专家Capers Jones提出的软件测试缺陷价值图如图1-1所示。

图1-1中的三条曲线分别代表引入的缺陷、发现缺陷、缺陷修复成本。越是在前期发现的缺陷，修复缺陷的成本越低，越是到后期，修复缺陷的成本越高。通常来说，发现缺陷主要在功能测试、集成测试阶段。

如果能够在Coding阶段发现大部分缺陷，就能大大降低修复缺陷的成本。静态代码分析技术恰恰能够很好地在Coding阶段发现部分代码问题，这样就能够大大节约软件开发成本。

经过实践论证，iOS平台比较好用的两款工具如下。

❑Clang的Scan-Build工具（下载地址：http://clang-analyzer.llvm.org/scan-build.html）。

❑FaceBook的Infer工具（下载地址：https://github.com/facebook/infer）。

目前这两款工具都是开源的，除了能够使用其基本的功能外，如果还有其他的业务需求，可以对这两款工具进行二次开发：添加自己的静态分析规则和分析算法。

QQ浏览器（iPhone）项目采用Scan-Build工具发现代码缺陷，如图1-2所示。

采用Infer工具发现代码缺陷统计图如图1-3所示，共发现1275处缺陷。

每日构建版本时，配置工程会自动采用这两款工具对工程代码进行静态代码分析，这样在测试任务前就能发现代码缺陷，大大降低软件缺陷修复成本。

1.3 品质管理

品质管理分为两大类，即研发品质和线上品质。

研发品质：包括品质体系（性能指标+用户评测）、测试过程数据（Bug、通过率）。

线上品质：包括线上数据、用户反馈、漏测率。

品质体系，除产品本身的特性功能外，还包含流畅度、内存、耗电量、启动速度、弱网络等功能，是用户体验能感知或者影响用户口碑的。同时需要思考各个指标的比重（主要考虑对用户的影响程度），这样可以更好地优化核心指标。

线上品质，研发品质的指标都可以通过预设在被测App里的埋点上报上来，这样就有了线上数据。用户反馈主要是通过各反馈渠道收集用户的反馈信息。通过对用户反馈信息的分析，可以得知哪些问题是应当提前发现而漏出去的。漏出去的问题有些可能是因为测试工程师测试设计覆盖不全导致的，有些可能是因为开发直接修改没经过测试引起的，有些可能是运营活动引起的。

上面提到了品质体系，那么具体的产品品质如何衡量？很多公司都以Bug来衡量，除Bug外，还有一些指标大家会用到，例如代码质量、代码覆盖率、测试过程数据。性能指标、用户评测、用户反馈和线上数据。具体解释参考如下。

❑代码质量：指静态代码扫描、架构评审、代码规范、代码评审。

❑代码覆盖率：指行覆盖、类覆盖、条件覆盖、分支覆盖。

❑测试过程数据：指测试通过率、回归通过率。

❑性能指标：指启动时间、响应时间、内存、流畅度（FPS）、CPU、耗电量。

❑用户评测：指产品进行用户调研、用户体验、用户问卷调查等。

❑用户反馈：指用户反馈的问题或者建议。

❑线上数据：指上线后的产品数据，如启动时间、用户行为数据。

❑Bug：指Bug模块分类（FT分布）、Bug各研发阶段数据、Bug分析。

对于产品度量，腾讯各产品的度量方式也各有特色，图1-4所示是浏览器品质体系的一小部分，仅供参考。

关于产品品质的衡量，不少公司还是以Bug来衡量的，下面先重点介绍Bug维度。

引用Elisabeth Hendrickson在文章《BETTER TESTING-WORSE QUALITY? 》中的图来说明“质量”的相关概念，如图1-5所示。

图1-5中左边的三部分是跟Bug相关的，分别是“已知Bug”“未知Bug”和“预防Bug”，右边两部分分别是开发质量工作和测试质量工作。

❑开发质量工作：涉及架构评审、代码规范、代码评审、单元测试、开发自测等。

❑测试质量工作：需求评审、用例设计（利用测试建模、测试分析等方法来提升测试设计覆盖度）、自动化测试（BVT或者接口测试等）、性能测试、精准测试、探索式测试、基于风险测试（RBT）、Bug大扫除、Bug分析、Bug统计、众测等。测试质量工作涉及的内容很多，可以考虑再抽练几个分类，如图1-6所示。

而这些测试质量工作的开展还需要借助一些平台和工具才可以更高效地完成，如图1-7所示。

测试质量工作除品质体系外，还包含工程效率。对于工程效率，测试团队一般围绕两个主题来开展：测试效率提升和可测性扩展。

❑测试效率提升：可以通过项目流程的规范、测试方法论应用、自动化测试的应用等工作，从而更高效地达到工作预期。

❑可测性扩展：可以联合开发做一些可测性提升的工作，例如接口暴露、代码解耦等。当然，也可以尝试覆盖更多没有覆盖的内容，例如有些项目终端类测试开展不错，就可以考虑加强后台接口的覆盖；还有黑盒类测试，可以考虑白盒类测试或者灰盒类测试等。

总的来说，测试质量工作一方面是做得更快，另一方面是做得更多。

通过上面对各个模块的分析，我们再把上面提到质量保证的各项工作映射到Elisabeth Hendrickson的图上，如图1-8所示。

1．已知Bug

团队成员在测试过程中发现的Bug（包括但不局限于Code review、show case、dogfood、测试发现的Bug等）。这些Bug一般都会记录到Bug系统中（例如腾讯的TAPD），这样就可以方便进行分析，例如Bug分布模块（浏览模块、支付模块、个人中心等）、各FT的分布（有可能跟模块有关联）、各研发阶段（迭代、集成、上线前等）、严重级别等。通过对Bug系统性分析来评估待发布产品的质量风险，这样可以给予决策者更好的数据支持。当然，有些Bug是可以挂起的，不一定所有都需要修复。

2．未知Bug

产品发布之前未发现的Bug，发布后通过海量用户反馈的问题或者通过统计埋点上报的问题。因为用户的机型网络以及数据环境等因素可能触发潜在Bug（而这些Bug是整个团队研发过程中很难出现或者偶尔出现漏过的），借助海量用户可以放大出现的概率，然后用户主动反馈或者被动埋点上报可以收集到这类潜在Bug。

一般产品里都有用户反馈意见的入口，通过这个入口可以收集用户使用过程中的问题或者意见。同时有些产品会对某些关键逻辑路径进行埋点，这样，只要用户使用过程中触发这个埋点，就会自动上报到后台。主动上报的数据就可以进行统计分析，这类数据统计可能区别于用户行为的统计，更多的是某个逻辑或者路径的上报。针对这些上报的数据进行数据挖掘，可以帮助发现某些问题最有可能出现的场景，进而可以再结合众测用户进行重现，最后解决这些问题。

3．预防Bug

主要通过一些流程或者机制充分体验产品，提前发现一些潜在Bug，例如通过需求评审、Showcase、DogFood等手段，全员积极参与各阶段产品的体验，就可能提前发现一些需求问题或者设计问题等。

❑需求评审：需要各方角色（产品、开发、测试、PM、设计等）都能投入精力讨论PK，这样可以提前把不合理的需求扼杀在摇篮中。

❑Showcase：各个迭代完成后，PM可以组织各个角色参与体验，尽早发现潜在问题，例如某些设计问题或者体验上的问题，快速返工，避免后期返工带来更大的人力消耗。

❑DogFood：通过持续集成编译出版本后（有重点需求说明），发送给团队各成员体验，及时快速发现问题。这里更强调产品质量需要全员的参与。

质量工作涉及方方面面以及各个角色，同时必须考虑人力、时间等因素，还得考虑项目的市场竞争状况，这样才能平衡好以上各项措施的选择。

1.4 测试分析

1.4.1 黑盒测试分析

“黑盒测试是软件测试的主要方法之一，也可以称为功能测试、数据驱动测试或基于规格说明的测试。测试者无须了解程序的内部情况，无须掌握应用程序的代码、内部结构和编程语言的知识，只要知道程序的输入、输出和系统的功能即可。这是从用户的角度针对软件界面、功能及外部结构进行测试，而不考虑程序内部逻辑结构。”这段关于黑盒测试的定义参考自维基百科。

黑盒测试也是应用最广的方法之一，不少公司都是以黑盒测试为主。那么黑盒测试有什么不足呢？我们先看看《微软的软件测试之道》对黑盒测试的分析，如图1-9所示。

图1-9中的A代表黑盒测试的没覆盖部分，B代表黑盒测试的冗余部分，C代表黑盒测试的有效部分。

从业界的统计数据来看，有效测试部分的百分比范围为35%～65%。从图1-9来看，要提升有效测试部分比例，就要把右边的圆（B+C）往左移动，尽可能使两个圆重合面积（C）增大。可以看出优化测试策略有两个方向：一是增加有效测试，二是减少冗余测试或者无效测试。

1．增加有效测试

增加有效测试的方法有两种：一是加强相关评审，二是应用业界的测试方法或者测试建模思想。

加强相关评审是从源头的需求抓起，加强对需求的评审，多从用户角度思考相关可用性及可能场景等。测试用例设计的评审，以及加强对产品开发等角色用例的评审。

应用业界的测试方法或者测试建模思想（详细方法参考第3章的内容），需要在测试用例设计的时候尽可能地覆盖更多功能，这就需要大家充分利用业界各种先进的测试模型来设计测试用例，这样可以更科学、更高效地扩大有效测试范围。如果有条件的话，可以通过阅读开发代码来梳理相关逻辑，这样用例设计的覆盖面会更全。

2．减少冗余测试

减少冗余测试可以通过减少无效用例或者低成效的用例、优化精简测试用例等方式进行。

减少无效用例或者低成效的用例，详细方法可以参考1.6节的数据反推。根据用例模块化划分，对Bug根据模块（TAPD上相应的模块选项）进行分类，统计每个模块出现Bug的个数，如果多次执行后Bug个数少的模块，优先级就降低。如果客户端架构稳定后，对于后续新功能没有涉及的这些模块，则可以考虑不执行相关用例。后续在每次集成测试后，测试结果都必须保存，统计经常出现Bug的相关用例，优化和增加相关测试用例，并且同步到各个平台。

优化精简测试用例，可以借助代码覆盖率作为标准，执行原来的用例和精简优化后的用例，如果两者的代码覆盖率差不多，那就达到目的了。通过代码覆盖率测试，还可以找出没有执行过的冗余代码，这样可以减少安装包的大小。借助精准测试方法，通过精准测试系统，分析测试用例以及代码映射关系，可以进一步确定测试用例的覆盖情况。这样就可以选择适当的测试用例保证合理的覆盖度。详细的原理方法可以参见第10章。

1.4.2 白盒测试分析

上文提到的优化测试策略都是从黑盒的角度进行分析的，因为黑盒测试有局限性，测试有效代码覆盖率只有35%～65%，那么如何保证黑盒测试没有测试到的部分代码的稳定性和可靠性，就需要进行白盒测试。业界通常采用的是单元测试。通过合适的单元测试，可以让代码覆盖率达到75%以上。但是由于单元测试的工作量比较大，刚开始不可能对全部代码进行单元测试，所以可以考虑先用黑盒测试，借助代码覆盖率工具，找出黑盒测试没有覆盖到的代码或模块（有可能某些代码属于冗余或者死代码），然后对这部分代码进行单元测试，这样可以最大限度地提高覆盖率，更好地保证代码质量。

1.5 测试设计

测试设计是一个系统性工程，涉及内容比较多，从前期需求分析到用例设计，再到各类数据的分析等。下面我们择取主流的理论来看一下。

1.5.1 探索式测试

探索式测试是目前业界比较流行的一种测试风格，是由测试专家Cem Kaner博士于1983年提出的，后来经过James Bach、James Whittaker等人的发展流行起来。国内大多数人是因为James Whittaker撰写了《Exploratory Software Testing》（探索式软件测试）一书才了解探索式测试，并逐渐开始应用探索式测试，国内的互联网公司基本都会使用探索式测试。

探索式测试建议在整个项目过程中将测试学习、测试设计、测试执行和测试结果解读作为相互支持的活动，并行地执行。可用图1-10来说明。

探索式测试目前已经充分应用到腾讯公司的各个产品中，具体实践案例请参见第8章的介绍。

1.5.2 基于模型的测试

基于模型的测试（Model-Based Testing, MBT）是根据用户的需求建模，进而根据模型自动生成用例、自动执行验证过程的测试方式。图1-11引用自《什么是基于模型的测试》[2]。

基于模型的测试在传统软件行业应用较多，例如爱立信以及西门子使用比较广泛，国内的华为也有一些改进应用。互联网公司如BAT也有一些尝试，不过没有太大规模应用起来。在腾讯内部，有些项目也在尝试MBT，不过目前还没有很好的典型案例，这里就不展开介绍。MBT对测试人员的建模能力有很高的要求，同时学习成本也相对较高，整体收益周期较长，所以比较难普及起来。

1.6 数据反推

1.6.1 测试过程中的数据

测试数据反推——充分利用各类测试数据的优化流程，进一步保障产品的质量。在各阶段的测试过程中会产生大量数据，例如Bug数据、测试通过率、回归通过率等。那么如何充分利用这些数据呢？前面已对已知Bug以及未知Bug进行了讨论。现在换个角度，从Bug产生的阶段来分析，图1-12是不同阶段Bug修复成本曲线。

针对Bug各阶段的分析，根据图1-12中Bug越早发现解决成本越低的结论，需要尽可能在最早引入的阶段发现Bug。针对某些阶段漏过的Bug分析，要尽可能完善测试设计覆盖，避免Bug都留到集成阶段发现，降低版本延期发布风险，从而开发出更高效的发布版本。

例如某个项目，集成测试发现的Bug占比只有整个版本（所有各分支版本）发现Bug的3%～6%，这些Bug大多是分支合流跟主干耦合的问题，还有一些是机型覆盖或者运营配置问题。大多数Bug都已经在各FT（Feature Team，特性模块）分支上发现了，这样集成后的发布风险就会大大降低，加快了发布速度。图1-13是FT分支的合流模型，各个分支FT都能充分保证质量，这样合流后集成测试问题就很少了。

也许有人会说3%～6%并不算少，确实，不同项目有不同要求。这里介绍的思路就是充分利用这些数据去思考与分析，推动团队采取动作，逐步降低该比例，逐步降低发布风险，提升发布效率。分支合流模型的测试如何开展是另外一个话题，不过大体思路都差不多，除了基本持续集成外，还需要自动化测试（BVT、接口测试、终端性能测试等）的支持，才能快速支持分支合流的快速研发模型。

再举一个例子，Bug各模块分布，有些模块Bug问题比较多，可能需要特别关注测试，因为根据测试的二八法则——80%的缺陷出现在20%的代码中，所以对这些模块需要多分析多做测试，这样可以更大可能发现潜在问题。一般来说，不同模块会对应不同的开发团队或者FT，也可以通过Bug来评估开发团队（或者FT）的成熟度，根据不同的开发团队（FT）制定相应的改善措施，用数据说话，这样更好地推动团队的正向优化。表1-1所示的是另外一个项目团队某个版本的各个FT存在的缺陷占比，从表中可以看出模块A是缺陷高发区，出现这种情况需要和对应模块的负责人进行沟通，细查原因，以利于改进。

以上仅仅是从Bug模块分布来分析Bug数据，其实还可以从很多维度（从开发人员的维度、用户行为的维度等）去挖掘Bug数据，充分利用Bug数据来优化测试设计，提升测试效率。

1.6.2 线上数据

以上介绍的大多是与研发过程品质相关的，其实还有一个很重要的方向就是线上品质，通过线上海量用户上报的数据来度量产品品质。大多数情况下，研发过程品质始终无法保证线上品质。比如用户反馈的重现问题，就是线上用户反馈的问题我们怎么也重现不了，即使严格按照用户的步骤、机型、网络等场景也重现不了。研发过程中测试的数据跟线上用户的数据对应不上，例如某个产品的启动速度，研发过程中测试的启动时间是2.3秒（测试20次取平均值），而线上用户上报的数据是3.2秒（20万个用户上报的平均值）。

业界也有相关测试方法，例如微软公司提出的TiP（Testing in Production），就是通过版本上线后海量用户上报各类数据来发现潜在的问题。测试人员需要关注各类性能数据，例如启动速度、内存、流畅度、响应时间、Crash率等。因为用户的机型、网络、地域、数据环境不同，所以不同用户上报的数据差异很大，这里需要做一些数据统计的分析处理，才能更好地展现出来。由于线上环境的复杂性，线上数据反映的结果会比测试数据差一些。

那么如何通过线上数据来分析定位问题呢？主要的方法就是对某些指标进行详细埋点上报，这样才能获得更详细数据并进行分析，最后找到问题所在。还是以某个产品的启动速度为例来说明（启动速度是指用户点击应用图标开始到拉取完数据展示给用户的这个时间段）。

App启动后就会到后台服务器拉取数据，从大的方向来看，需要区分后台服务器耗时以及App处理的耗时，这样可以方便前端或者后台解决问题。如图1-14所展示的，“等待响应”就是后台服务器耗时（其中也包含网络传输的耗时）。一般可以通过抓取网络包分析得出相关耗时。

图1-14中的RTT（Round-Trip Time）是客户端到服务器往返所花的时间。

当然，只区分客户端跟后台服务器各自的耗时是远远不够的，还需要细分到每个主要函数的耗时，这样才能更好地定位具体是哪部分耗时。图1-15所示的是某个App对关键函数（节点）的日志统计。

图1-15只是启动速度这个指标需要记录的数据，可能发现需要记录的数据非常多，对这些记录的日志也会进行分级，线上发布版本的日志会尽量少一些，不过关键的地方还是需要记录的。当然，版本加了日志会对性能有所损耗，不过在可接受的范围内，还是有必要的；通过线上版本的数据上报，可以得到用户真实的数据，发现潜在问题并逐步优化，给用户更好的体验，提升产品口碑。

测试数据还可以预测即将发布版本的质量，不管是研发过程还是灰度阶段，都将会产生很多测试数据。那么是否可以充分利用这些数据来预测上线版本的质量趋势呢？这确实是一个方向，但是需要大量的测试数据才可能有机会预测靠谱。因为线上用户的各种机型系统、网络状况、用户环境数据，这些都很难在上线前的环境覆盖到，所以就很难预测线上版本的质量。如果灰度群体足够，那么还是有机会的。腾讯内部的很多项目，产品稳定性问题（Crash率）都是通过灰度来发现问题的，Crash率达到一定程度，就可以进一步扩大灰度规模，逐步迭代放大灰度数量，直至上线。

1.7 未来的测试

这一节内容都是笔者畅想的，如有雷同，纯属意外。

移动互联网时代，特别是Native的App，版本更新的成本很高（除时间成本，还有对用户体验的影响），所以大多数App都会经过充分的测试再发布版本。

随着热补丁（hotfix）技术的演进以及H5的流行，可以不需要发布新版本而发布一个补丁就可以发布新功能或者修复问题（而且用户基本无感知，不需要安装过程，下次启动就自动更新了），这样就可以在没有充分测试的情况下，快速通过用户来验证。这样对测试的依赖可能会越来越小。那么未来的产品都是通过用户（灰度或者正式上线）直接验证吗？

应该不可能全部都通过用户来验证（灰度或者正式上线），不经过测试而直接上线，可能出现问题的概率会增大，如果真的出现问题，那么会对产品的口碑带来很大的影响。但是热补丁技术确实是可以快速修复问题的方案，以后会被逐步应用。即使利用热补丁技术，还是需要度量产品品质的，例如线上用户各类性能指标以及用户反馈等，对于品质的追求还是始终存在的，也就是仍需要有人来做品质这样的工作。

1.7.1 线上数据挖掘

既然线上数据会越来越重要，那么就需要一整套埋点上报体系（终端是SDK形式，服务端存储各类数据），同时对上报数据进行数据分析，可能需要利用到机器学习等技术分析数据，判断是否有潜在问题。数据上报体系是每个App都有的基本功能，包含需要关注具体上报什么信息，例如，

（1）路径埋点：关键路径的埋点。

（2）错误码信息：统一错误码设计，方便排查。

（3）调用堆栈：堆栈调用信息。

（4）方法跟踪：函数方法的链条。

（5）用户动作：用户操作路径（可以详细到用户何时点击哪个控件）。

（6）机型网络信息：基础手机信息收集。

（7）性能指标（内存/CPU/FPS）：各类性能指标的消息速度/流量/函数调用时间。

在对App全方位埋点后，就会有上报的数据，哪些数据需要进行分析，具体分析方法各种各样，如图1-16所示。该图主要描述了一种线上数据分析模型，包括数据收集容器、数据分析容器、Bug处理容器三个部分。

如果埋点上报体系建设完善，任何人（Dogfood、Showcase、众测、灰度等）只要体验产品，就是给产品做测试，这样就会上报很多数据，再系统分析这些数据，进而找到某些潜在问题。

1.7.2 人工智能

最近，Facebook发布聊天机器人Chatbot, Google发布Google Assistant以及Google Home音箱，Amazon也发布Echo音箱，整个业界的发展趋势变成从App演进到Bot。同时，Google的战略也从Mobile First转变为AI First。那么对于人工智能（Bot），应该怎么测试呢？

业界暂时还没有开源或者公开的测试方案，可能各公司也都在探索中，传统上针对AI的算法测试也是持续演进的。我们先回到人工智能本身，其实就是对数据的智能处理（这也是拥有大数据的Google等公司的人工智能快速发展的原因之一），那么人工智能测试还是得围绕数据进行测试。当然，这样的数据是海量的，因此要采用抽样模型进行评测。总的来说，就是构建以及收集数据样本。数据样本的构建，需要对具体处理数据结构足够了解，然后通过自动化方式生成样本数据。同时，除了构建样本数据，还可以通过另外的渠道来收集用户数据，例如众测或者众包的方式收集样本数据。

除了对数据的测试外，在人工智能出现后，人机交互方式会出现大的变化，语音交互可能是主要交互模式之一，那么如何保证优秀的用户体验呢？交互评测需要真实用户的参与，首先设计合理的评测问卷，然后通过众测或者众包等平台引入不同用户的参与，通过双盲测试收集各类数据。同时也会通过AB Test来收集线上用户的反馈，不断改善用户体验。

总的来说，人工智能测试除了对AI算法的测试外，还需要关注数据类测试+交互类测试。

1.7.3 众测

上面提到的线上数据挖掘（需要各种机型、网络、数据环境等）以及人工智能（数据样本采集）都需要有一定量的真实用户参与，才能更好地评测产品品质。那么可能就需要用共享经济的方式，快速集合一群合适用户来帮忙做评测（收集数据或者产品体验等），这就是最近几年业界流行的众测（众包）模式。众测（众包）模式的优点如下。

（1）闭环时间短，沟通效率高：因为有报酬等激励，众测（众包）用户积极度更高。

（2）定向用户属性支持：众测（众包）平台会收集用户属性，例如性别、年龄、职务、学历等，更有针对性地向合适人群做评测。

（3）定向设备属性支持：众测（众包）平台会收集设备属性，例如机型、ROM、网络、地域等，更有针对性地向合适人群做评测，特别是对于地域有特殊要求的，可以快速响应。

（4）用户行为高度可控、可刷机、可支付。众测（众包）平台的用户都是相对狂热的粉丝，可以帮助做一些特殊操作，例如重复刷机、重复尝试某个问题。

众测（众包）的具体使用模式大概有以下几类。

（1）需求评测（评估需求的适用范围等）。

（2）机型覆盖测试（覆盖各类机型适配情况）。

（3）重要问题复现（某些问题的复现）。

（4）大量数据收集（数据标准类）。

（5）问卷调查收集（用户调研）。

（6）复杂环境评测（某些功能的评测）。

众测（众包）使用可能是一个趋势，有能力的公司可以逐步建设这样的平台，这样能更快地验证产品，产品验证的成本会更低。

1.8 小结

通过本章的内容，先和读者建立了一个测试基础共识，便于接下来的章节理解。总体来说，我们认为测试=工程效率+品质管理，如何提升工程效率和品质管理是测试提升的核心内容。在测试的不同阶段，测试分析、测试设计、数据反推都能发挥一定的作用，未来的空间很大，需要我们一起去探索。