腾讯iOS测试实践.html.pdf

《腾讯iOS测试实践.html.pdf》由会员分享，可在线阅读，更多相关《腾讯iOS测试实践.html.pdf（177页珍藏版）》请在三一文库上搜索。

1、作者简介 丁如敏，毕业于北京邮电大学，腾讯Android自动化测试实践的作者之一，拥有10年以上软件测试和项目管理的经验，精通移动终端性能、自动化测试、敏捷测试等各种测试技术。在腾讯工作期 间，带领团队共发明了50多项专利，开发了10多门内部培训课程，喜欢挑战软件领域的各项前瞻技术，并有丰富的实践经验。 王琳，腾讯高级测试工程师，2012年中山大学硕士毕业后加入腾讯。积累了五年多的iOS客户端测试经验。在探索式测试方面有深入的研究和实践，在测试过程的优化提升方面颇有心得。致力于将业 界先进测试理论落地到iOS平台测试实践中，实战经验丰富。 程春林，腾讯专项技术工程师，从事过传统汽车行业、通信行

2、业、互联网软件开发以及自动化测试开发工作，拥有海外工作经验。目前任职于腾讯，负责手机QQ浏览器（iPhone）端专项测试工作， 专注于iOS端自动化测试研发与实践，并撰写了多项iOS相关发明专利。 纪文静，2015年西安电子科技大学硕士毕业后加入腾讯。入职后负责QQ浏览器（iPhone）端功能测试，主要致力于推动测试流程优化落地的工作，在缺陷分析方面有较丰富的经验。 叶方正，2008年加入腾讯，专注于移动智能平台性能以及自动化测试。有10年以上的智能移动平台测试及开发的经验，精通主流的智能移动平台性能测试和调优，以及各种工程工具开发和平台搭建。 在腾讯工作期间，先后负责过手机QQ、手机QQ浏览

3、器、腾讯微博、应用宝、手机管家等相关业务的测试。 张锦铭，毕业于中山大学数学系，2011年入职腾讯，专注于iOS端性能测试和自动化测试，有丰富的iOS自动化测试经验，拥有性能和自动化测试相关的12项专利。目前负责QQ浏览器（iPhone）端的 性能测试相关工作。 前言 为何编写本书 随着移动互联网的兴起，移动终端的测试也进入火热的时代。两大主流操作系统Android和iOS占据了移动端的主要市场份额，其中iOS系统只能在苹果系列的移动终端使用，也就是说，在苹果系列的 移动终端产品上，操作系统都是清一色的iOS系统，这就形成了硬件和系统同属于一家公司的独特现象。每年苹果公司发布新机型或者新操作系

4、统时，都会引起全球果粉的疯狂。如此火热的平台，如何保证 其App的质量就显得尤为重要。 长久以来，市面上单独讲解iOS平台测试相关知识的书籍比较少见，对于做iOS测试的同行来说，可参考的国内资源十分匮乏，他们往往需要借助外文网站和博客上的片段资料进行学习和整合。随着 iPhone和iPad等移动终端设备的兴起和流行，越来越多的开发者和测试人员投入到iOS平台软件的研发中，而中文参考资料的缺失，确实在一些程度上阻碍了国内测试人员进军iOS平台的步伐。市场上也渴 望有一本相对系统而翔实地讲解iOS测试的书籍，由此，本书应运而生。 QQ浏览器（iPhone）测试团队自2012年年初组建以来，一直致力

5、于探索基于iOS平台的各种测试技能和实践方式，经过近5年的经验积累，在整体测试观、功能测试、性能测试、自动化测试方面总结 出独特的经验，团队本着开放、分享的精神撰写了本书，希望借本书和业界同行们进行分享和交流。 正式起草本书是在2015年下半年，历时半年完成初稿，于2016年下半年正式启动本书出版流程，再用半年时间修改原稿，进行内容更新和丰富，目的是使书中涉及的案例和框架更加贴合当前实际。故 本书总体耗时一年半，在这一年半的时间里，各位作者各尽所长，加班加点，力求为读者呈现一本相对系统化、可读性高、与时俱进的iOS平台专业测试书籍。 参与本书编写的有程春林、丁如敏、纪文静、王琳、叶方正、张锦铭

6、（按姓氏拼音排序），且都是来自腾讯QQ浏览器（iPhone）测试团队的领头人及骨干员工。 读者对象 本书是一本结合实际案例的iOS平台实践总结书籍，内容贴近一线测试，语言朴素易懂。适合新手入门，也能够为有一定经验的测试人员提供思路扩展和理论抽象的借鉴。这里根据行业实际需求给出适 合阅读本书的相应的读者群体： 对iOS平台测试感兴趣的人； 有一定iOS平台测试经验并想提升的人； 即将开展iOS平台测试的团队； 开设相关课程的院校师生。 本书特色 本书立足于iOS平台，结合最新的理论和工具使用案例，对测试工作进行了系统的思考和梳理。内容涵盖了iOS平台上常用的各种测试方式、工具、理论，可以作为新手

7、入门，以及有一定经验的测试人 员扩展思路使用。 本书分为三大部分：测试观、iOS特色测试、通用测试实践。 在开篇的测试概述里，我们首先为读者介绍了测试观，这是本书的一个综合性观点，也是后续章节的地图，这里不拘泥于iOS平台，是对整个测试工作的思考和总结。第1章也是整本书的纲领性章节， 是从一个比较高的视角俯瞰整个测试活动，能为读者带来系统性的视野。 在iOS特色测试部分，我们主要介绍的是与iOS平台强相关的测试内容。包括iOS平台的一些特性问题、兼容性测试、性能测试等内容，还包括各种自动化工具的使用方法、自动化框架的二次开发实践 等内容。这部分是本书的核心，也是区别于业界同类书籍的重点部分。

8、在通用测试实践部分，主要介绍了一些不分平台性的测试实践，包括测试界流行的探索式测试实践、我们团队自创的标准化测试实践，以及测试工程师必做的缺陷分析等。这部分是一些与iOS非强相关 的内容，在其他平台上也可以借鉴使用。 如何阅读本书 如果您是一位有丰富iOS平台测试经验的工程师，本书可以为您提供思路拓展，建议重点阅读第1章，寻找与自己有共鸣的点。然后可以重点阅读第6章，这一章涵盖了我们对自动化测试的深入实践和 思考。 如果您是一位想尝试和学习iOS平台测试的新入行者，那么应该恭喜您遇到本书，因为本书将帮您轻松进入iOS测试之门。故建议从头逐章阅读，尽量不要跳章，读完本书基本可以掌握iOS平台上所

9、有 主流的测试技能和经验。 如果您是一位非iOS平台的测试工程师，想从本书中寻找启发，建议重点阅读本书通用测试实践部分，这里介绍的测试方法在各个平台都通用。还可以尝试阅读第1章和第二部分中感兴趣的章节。 勘误和支持 由于作者水平所限，书中难免会出现一些错误或者不准确的地方，恳请各位读者批评指正。如果您在阅读本书时遇到任何问题，欢迎提出，我们将尽力为您提供最满意的解答。 我们的邮箱： 我们的专用QQ：2698884730 致谢 感谢腾讯科技MIG无线研发部总经理冼文佟、副总经理陈诚，是你们的鼓励助我们完成本书的撰写。 感谢腾讯科技MIG浏览器产品部QQ浏览器（iPhone）项目团队总监俞旭明和全

10、体成员对我们的指导和帮助，本书的全部案例都来自这个项目团队。 感谢腾讯科技MIG无线研发部品质中心（TMQ）的同事，在整个写作过程中，你们帮助我们进行的内容调整和资源校对，是本书高质量呈现的保障。特别感谢陈勉荣、马识佳和樊林三位同学对本书进 行的积极校对和评审工作。 感谢机械工业出版社华章公司的编辑杨福川、孙海亮，是你们给予的专业指导和鼓励，引导了本书的完成。 第一部分 测试观 第1章 测试观概述 第1章 测试观概述 1.1 引言 在正式介绍iOS测试前，先为读者引入一个思考问题：一千个人有一千种测试观，那么测试人员到底应该持有何种测试观？我们先来看看测试的定义发展史。 20世纪60年代：软件

11、开发过程中，将测试等同于“调试”。 1957年，软件测试区别于调试，成为一种发现软件缺陷的活动。 1972年，在北卡罗来纳大学举行了首届软件测试正式会议。 1975年，John Good Enough和Susan Gerhart在IEEE上发表了文章测试数据选择的原理，从此软件测试被确定为一种研究方向。 1979年，在Glen ford Myers的软件测试艺术中，定义“测试是为发现错误而执行的一个程序或者系统的过程”。 1983年，Bill Hetzel在软件测试完全指南中指出，“测试是以评价一个程序或者系统属性为目标的任何一种活动，是对软件质量的度量。” 2002年，Rick和Stefan

12、在系统的软件测试一书中对软件测试做了进一步定义，“测试是为了度量和提高被测试软件的质量而对测试软件进行工程设计、实施和维护的整个生命周期过程。” 软件测试的经典定义：在规定的条件下对程序进行操作，以发现程序错误、衡量软件质量，并对其能否满足设计要求而进行评估的过程。百度百科 以上测试（软件测试）的定义都没错，那么测试工程师应该怎么做呢？ 通俗一点来解释，笔者理解的测试为：测试=工程效率+品质管理。相应地，测试人员做的事情就是提升工程效率，做好品质管理。引用谷歌团队的一段话1：Essentially，every day we ask ourselves，“How can we make our

13、software development process more efficient to deliver products that make our users happy？”其中“make process more efficient”可以理解为工程效 率，“make users happy”可以理解为品质管理。就像上面谷歌团队的这段话，测试人员应该每天思考怎样提升团队的研发效率，怎样提升产品品质来让用户满意。 第1章 测试观概述 1.1 引言 在正式介绍iOS测试前，先为读者引入一个思考问题：一千个人有一千种测试观，那么测试人员到底应该持有何种测试观？我们先来看看测试的定义发展史。

14、20世纪60年代：软件开发过程中，将测试等同于“调试”。 1957年，软件测试区别于调试，成为一种发现软件缺陷的活动。 1972年，在北卡罗来纳大学举行了首届软件测试正式会议。 1975年，John Good Enough和Susan Gerhart在IEEE上发表了文章测试数据选择的原理，从此软件测试被确定为一种研究方向。 1979年，在Glen ford Myers的软件测试艺术中，定义“测试是为发现错误而执行的一个程序或者系统的过程”。 1983年，Bill Hetzel在软件测试完全指南中指出，“测试是以评价一个程序或者系统属性为目标的任何一种活动，是对软件质量的度量。” 2002年，

15、Rick和Stefan在系统的软件测试一书中对软件测试做了进一步定义，“测试是为了度量和提高被测试软件的质量而对测试软件进行工程设计、实施和维护的整个生命周期过程。” 软件测试的经典定义：在规定的条件下对程序进行操作，以发现程序错误、衡量软件质量，并对其能否满足设计要求而进行评估的过程。百度百科 以上测试（软件测试）的定义都没错，那么测试工程师应该怎么做呢？ 通俗一点来解释，笔者理解的测试为：测试=工程效率+品质管理。相应地，测试人员做的事情就是提升工程效率，做好品质管理。引用谷歌团队的一段话1：Essentially，every day we ask ourselves，“How can w

16、e make our software development process more efficient to deliver products that make our users happy？”其中“make process more efficient”可以理解为工程效 率，“make users happy”可以理解为品质管理。就像上面谷歌团队的这段话，测试人员应该每天思考怎样提升团队的研发效率，怎样提升产品品质来让用户满意。 1.2 工程效率 总体来说，工程效率就是研发效率（包含测试效率）。这里我们会把测试效率单独提出来进行说明，因为这是与测试工程师相关度最大的工作。研发效率，

17、其实就是让产品上线的时间更快（在品质有 保障的前提下），大多数时候是说与研发流程相关的（不局限于敏捷流程，Feature Team研发模型），例如包含但不局限于以下活动。 需求评审：需求评审机制以及更新通知，避免需求有改动而没有及时同步到相关角色。 代码质量：静态代码扫描，千行代码缺陷率等。 架构评审：代码架构的讨论以及评审。 Bug流程：Bug生命周期，避免随便修改Bug状态以及备注缺失。 Code Review：代码评审，如果有代码评审委员会就更好了。 Dogfood：自己做的产品自己（项目各成员）先体验。 Showcase：完成某个特性，可以通过会议针对某个特性进行展示，一般由产品经理主

18、持。 上面提到的活动，只有通过整个项目团队（各个角色）的通力配合，才能更加高效。 再提一下测试效率，这大多数由测试工程师主导，也是测试工程师最主要的工作内容。测试效率包含但不局限于以下这些活动。 测试周期：测试与研发周期是密切关联的，包括迭代测试、集成测试、回归测试、上线测试等，每个阶段都要把握好测试效率和测试资源分配。 测试设计：包括需求覆盖度、用例覆盖度、用例执行效率等。 自动化测试：使用自动化执行的方式进行测试，可以快速得出测试结果，节省人力成本。 静态代码分析：使用一定的工具来对代码进行静态扫描，提前发现代码隐藏的问题。 测试技术创新：通过对测试技术的创新，例如精准测试、机器学习等方式

19、，来变更测试方式，大幅度提升测试质量和效率。 接下来举两个例子具体看下。 1.2.1 自动化测试 自动化测试于20世纪90年代才开始逐渐成熟，特别是敏捷研发的流行以及推崇的TDD模式，自动化测试也逐渐流行起来。对于自动化测试，我们还是得多关注其投入产出比（ROI），特别是对于UI自 动化测试。业界自动化测试金字塔模型建议做单元测试或者接口测试多于UI自动化测试。关于自动化测试投入产出比，请参阅第6章介绍的内容。 对于iOS平台上的自动化测试实践，我们也有在不同方向上的尝试（参见第5章），并都有不错的收获。相关自动化测试的开展还需要有一些自动化测试框架的支持（详细自动化测试框架的内容会在第 7章

20、介绍），QQ浏览器（iPhone）测试团队主要移植Google开源的EarlGrey框架来作为自动化测试的基础框架。本节先简单介绍几种主流自动化测试类型。 1.BVT（Build Verification Test） 业界现在流行持续交付的模式。那么每次持续集成编译出包后，自动化会运行一些基础功能测试用例，保证版本基础功能可用，而不会因为新代码合入影响基础功能。这部分主要介绍UI自动化测试， 当然，随着版本需求的变更，维护成本也会增加。但对于QQ浏览器的UI变更还不是很频繁，维护成本还相对可控，整体的投入产出也不错，具体可参考第6章的内容。 2.监控类 根据产品的业务特点，我们会对产品进行一些

21、监控，例如手机QQ浏览器（iPhone）项目实现了三种类型的监控测试，即终端视频嗅探监控、终端feeds流短视频可播性监控、终端资讯类监控。这部分 监控的基础框架和BVT实现是一致的，只是基于业务形态做了调整，采用的也是EarlGrey框架并进行了二次开发。可参考第6章关于测试框架的二次开发。 3.性能自动化测试 性能测试涉及各种数据的采集和分析，而数据采集往往很复杂并且非常耗时，性能自动化测试也都集中在数据采集这一块。目前我们针对页面速度、产品稳定性、电量、流量、内存等各个方面进行性 能自动化测试的尝试，详细内容请参见第4章。 1.2.2 静态代码分析 静态代码分析就是在不执行代码的情况下，

22、通过一定的算法规则（词法分析、语法分析、单函数分析、代码段分析、数据流分析、资源分析、依赖链分析、更高级的智能逻辑分析）对整个工程的代码 进行分析，以此来找出代码中的缺陷。这样就可以提早发现问题，大大降低研发成本。美国软件工程专家Capers Jones提出的软件测试缺陷价值图如图1-1所示。 图1-1 软件测试缺陷价值图 图1-1中的三条曲线分别代表引入的缺陷、发现缺陷、缺陷修复成本。越是在前期发现的缺陷，修复缺陷的成本越低，越是到后期，修复缺陷的成本越高。通常来说，发现缺陷主要在功能测试、集成测 试阶段。 如果能够在Coding阶段发现大部分缺陷，就能大大降低修复缺陷的成本。静态代码分析技

23、术恰恰能够很好地在Coding阶段发现部分代码问题，这样就能够大大节约软件开发成本。 经过实践论证，iOS平台比较好用的两款工具如下。 Clang的Scan-Build工具（下载地址：http:/clang-analyzer.llvm.org/scan-build.html）。 FaceBook的Infer工具（下载地址：https:/ 目前这两款工具都是开源的，除了能够使用其基本的功能外，如果还有其他的业务需求，可以对这两款工具进行二次开发：添加自己的静态分析规则和分析算法。 QQ浏览器（iPhone）项目采用Scan-Build工具发现代码缺陷，如图1-2所示。 图1-2 Scan-Bui

24、ld工具发现代码缺陷统计图 采用Infer工具发现代码缺陷统计图如图1-3所示，共发现1275处缺陷。 图1-3 Infer工具发现代码缺陷统计图 每日构建版本时，配置工程会自动采用这两款工具对工程代码进行静态代码分析，这样在测试任务前就能发现代码缺陷，大大降低软件缺陷修复成本。 1.3 品质管理 品质管理分为两大类，即研发品质和线上品质。 研发品质：包括品质体系（性能指标+用户评测）、测试过程数据（Bug、通过率）。 线上品质：包括线上数据、用户反馈、漏测率。 品质体系，除产品本身的特性功能外，还包含流畅度、内存、耗电量、启动速度、弱网络等功能，是用户体验能感知或者影响用户口碑的。同时需要思

25、考各个指标的比重（主要考虑对用户的影响程 度），这样可以更好地优化核心指标。 线上品质，研发品质的指标都可以通过预设在被测App里的埋点上报上来，这样就有了线上数据。用户反馈主要是通过各反馈渠道收集用户的反馈信息。通过对用户反馈信息的分析，可以得知哪些问 题是应当提前发现而漏出去的。漏出去的问题有些可能是因为测试工程师测试设计覆盖不全导致的，有些可能是因为开发直接修改没经过测试引起的，有些可能是运营活动引起的。 上面提到了品质体系，那么具体的产品品质如何衡量？很多公司都以Bug来衡量，除Bug外，还有一些指标大家会用到，例如代码质量、代码覆盖率、测试过程数据。性能指标、用户评测、用户反馈 和线

26、上数据。具体解释参考如下。 代码质量：指静态代码扫描、架构评审、代码规范、代码评审。 代码覆盖率：指行覆盖、类覆盖、条件覆盖、分支覆盖。 测试过程数据：指测试通过率、回归通过率。 性能指标：指启动时间、响应时间、内存、流畅度（FPS）、CPU、耗电量。 用户评测：指产品进行用户调研、用户体验、用户问卷调查等。 用户反馈：指用户反馈的问题或者建议。 线上数据：指上线后的产品数据，如启动时间、用户行为数据。 Bug：指Bug模块分类（FT分布）、Bug各研发阶段数据、Bug分析。 对于产品度量，腾讯各产品的度量方式也各有特色，图1-4所示是浏览器品质体系的一小部分，仅供参考。 图1-4 浏览器品质

27、体系（部分） 关于产品品质的衡量，不少公司还是以Bug来衡量的，下面先重点介绍Bug维度。 引用Elisabeth Hendrickson在文章BETTER TESTING-WORSE QUALITY？中的图来说明“质量”的相关概念，如图1-5所示。 图1-5 Bug分析模型 图1-5中左边的三部分是跟Bug相关的，分别是“已知Bug”“未知Bug”和“预防Bug”，右边两部分分别是开发质量工作和测试质量工作。 开发质量工作：涉及架构评审、代码规范、代码评审、单元测试、开发自测等。 测试质量工作：需求评审、用例设计（利用测试建模、测试分析等方法来提升测试设计覆盖度）、自动化测试（BVT或者接口

28、测试等）、性能测试、精准测试、探索式测试、基于风险测试 （RBT）、Bug大扫除、Bug分析、Bug统计、众测等。测试质量工作涉及的内容很多，可以考虑再抽练几个分类，如图1-6所示。 而这些测试质量工作的开展还需要借助一些平台和工具才可以更高效地完成，如图1-7所示。 测试质量工作除品质体系外，还包含工程效率。对于工程效率，测试团队一般围绕两个主题来开展：测试效率提升和可测性扩展。 测试效率提升：可以通过项目流程的规范、测试方法论应用、自动化测试的应用等工作，从而更高效地达到工作预期。 图1-6 测试质量工作分类 图1-7 测试平台和工具 可测性扩展：可以联合开发做一些可测性提升的工作，例如接

29、口暴露、代码解耦等。当然，也可以尝试覆盖更多没有覆盖的内容，例如有些项目终端类测试开展不错，就可以考虑加强后台接口的覆 盖；还有黑盒类测试，可以考虑白盒类测试或者灰盒类测试等。 总的来说，测试质量工作一方面是做得更快，另一方面是做得更多。 通过上面对各个模块的分析，我们再把上面提到质量保证的各项工作映射到Elisabeth Hendrickson的图上，如图1-8所示。 1.已知Bug 团队成员在测试过程中发现的Bug（包括但不局限于Code review、show case、dogfood、测试发现的Bug等）。这些Bug一般都会记录到Bug系统中（例如腾讯的TAPD），这样就可以方便进行分

30、 析，例如Bug分布模块（浏览模块、支付模块、个人中心等）、各FT的分布（有可能跟模块有关联）、各研发阶段（迭代、集成、上线前等）、严重级别等。通过对Bug系统性分析来评估待发布产品的质 量风险，这样可以给予决策者更好的数据支持。当然，有些Bug是可以挂起的，不一定所有都需要修复。 图1-8 Bug分析及测试工作模型 2.未知Bug 产品发布之前未发现的Bug，发布后通过海量用户反馈的问题或者通过统计埋点上报的问题。因为用户的机型网络以及数据环境等因素可能触发潜在Bug（而这些Bug是整个团队研发过程中很难出现或 者偶尔出现漏过的），借助海量用户可以放大出现的概率，然后用户主动反馈或者被动埋点

31、上报可以收集到这类潜在Bug。 一般产品里都有用户反馈意见的入口，通过这个入口可以收集用户使用过程中的问题或者意见。同时有些产品会对某些关键逻辑路径进行埋点，这样，只要用户使用过程中触发这个埋点，就会自动上 报到后台。主动上报的数据就可以进行统计分析，这类数据统计可能区别于用户行为的统计，更多的是某个逻辑或者路径的上报。针对这些上报的数据进行数据挖掘，可以帮助发现某些问题最有可能出现 的场景，进而可以再结合众测用户进行重现，最后解决这些问题。 3.预防Bug 主要通过一些流程或者机制充分体验产品，提前发现一些潜在Bug，例如通过需求评审、Showcase、DogFood等手段，全员积极参与各阶

32、段产品的体验，就可能提前发现一些需求问题或者设计问题 等。 需求评审：需要各方角色（产品、开发、测试、PM、设计等）都能投入精力讨论PK，这样可以提前把不合理的需求扼杀在摇篮中。 Showcase：各个迭代完成后，PM可以组织各个角色参与体验，尽早发现潜在问题，例如某些设计问题或者体验上的问题，快速返工，避免后期返工带来更大的人力消耗。 DogFood：通过持续集成编译出版本后（有重点需求说明），发送给团队各成员体验，及时快速发现问题。这里更强调产品质量需要全员的参与。 质量工作涉及方方面面以及各个角色，同时必须考虑人力、时间等因素，还得考虑项目的市场竞争状况，这样才能平衡好以上各项措施的选择

33、。 1.4 测试分析 1.4.1 黑盒测试分析 “黑盒测试是软件测试的主要方法之一，也可以称为功能测试、数据驱动测试或基于规格说明的测试。测试者无须了解程序的内部情况，无须掌握应用程序的代码、内部结构和编程语言的知识，只要 知道程序的输入、输出和系统的功能即可。这是从用户的角度针对软件界面、功能及外部结构进行测试，而不考虑程序内部逻辑结构。”这段关于黑盒测试的定义参考自维基百科。 黑盒测试也是应用最广的方法之一，不少公司都是以黑盒测试为主。那么黑盒测试有什么不足呢？我们先看看微软的软件测试之道对黑盒测试的分析，如图1-9所示。 图1-9 黑盒测试分析图 图1-9中的A代表黑盒测试的没覆盖部分，

34、B代表黑盒测试的冗余部分，C代表黑盒测试的有效部分。 从业界的统计数据来看，有效测试部分的百分比范围为35%65%。从图1-9来看，要提升有效测试部分比例，就要把右边的圆（B+C）往左移动，尽可能使两个圆重合面积（C）增大。可以看出优化 测试策略有两个方向：一是增加有效测试，二是减少冗余测试或者无效测试。 1.增加有效测试 增加有效测试的方法有两种：一是加强相关评审，二是应用业界的测试方法或者测试建模思想。 加强相关评审是从源头的需求抓起，加强对需求的评审，多从用户角度思考相关可用性及可能场景等。测试用例设计的评审，以及加强对产品开发等角色用例的评审。 应用业界的测试方法或者测试建模思想（详细

35、方法参考第3章的内容），需要在测试用例设计的时候尽可能地覆盖更多功能，这就需要大家充分利用业界各种先进的测试模型来设计测试用例，这样可以 更科学、更高效地扩大有效测试范围。如果有条件的话，可以通过阅读开发代码来梳理相关逻辑，这样用例设计的覆盖面会更全。 2.减少冗余测试 减少冗余测试可以通过减少无效用例或者低成效的用例、优化精简测试用例等方式进行。 减少无效用例或者低成效的用例，详细方法可以参考1.6节的数据反推。根据用例模块化划分，对Bug根据模块（TAPD上相应的模块选项）进行分类，统计每个模块出现Bug的个数，如果多次执行后 Bug个数少的模块，优先级就降低。如果客户端架构稳定后，对于后

36、续新功能没有涉及的这些模块，则可以考虑不执行相关用例。后续在每次集成测试后，测试结果都必须保存，统计经常出现Bug的相关 用例，优化和增加相关测试用例，并且同步到各个平台。 优化精简测试用例，可以借助代码覆盖率作为标准，执行原来的用例和精简优化后的用例，如果两者的代码覆盖率差不多，那就达到目的了。通过代码覆盖率测试，还可以找出没有执行过的冗余代 码，这样可以减少安装包的大小。借助精准测试方法，通过精准测试系统，分析测试用例以及代码映射关系，可以进一步确定测试用例的覆盖情况。这样就可以选择适当的测试用例保证合理的覆盖度。详 细的原理方法可以参见第10章。 1.4.2 白盒测试分析 上文提到的优化

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

38、例设计，再到各类数据的分析等。下面我们择取主流的理论来看一下。 1.5.1 探索式测试 探索式测试是目前业界比较流行的一种测试风格，是由测试专家Cem Kaner博士于1983年提出的，后来经过James Bach、James Whittaker等人的发展流行起来。国内大多数人是因为James Whittaker撰写了Exploratory Software Testing（探索式软件测试）一书才了解探索式测试，并逐渐开始应用探索式测试，国内的互联网公司基本都会使用探索式测试。 探索式测试建议在整个项目过程中将测试学习、测试设计、测试执行和测试结果解读作为相互支持的活动，并行地执行。可用图1-

39、10来说明。 图1-10 探索式测试模型图 探索式测试目前已经充分应用到腾讯公司的各个产品中，具体实践案例请参见第8章的介绍。 1.5.2 基于模型的测试 基于模型的测试（Model-Based Testing，MBT）是根据用户的需求建模，进而根据模型自动生成用例、自动执行验证过程的测试方式。图1-11引用自什么是基于模型的测试2。 基于模型的测试在传统软件行业应用较多，例如爱立信以及西门子使用比较广泛，国内的华为也有一些改进应用。互联网公司如BAT也有一些尝试，不过没有太大规模应用起来。在腾讯内部，有些项 目也在尝试MBT，不过目前还没有很好的典型案例，这里就不展开介绍。MBT对测试人员的

40、建模能力有很高的要求，同时学习成本也相对较高，整体收益周期较长，所以比较难普及起来。 图1-11 基于模型的测试 1.6 数据反推 1.6.1 测试过程中的数据 测试数据反推充分利用各类测试数据的优化流程，进一步保障产品的质量。在各阶段的测试过程中会产生大量数据，例如Bug数据、测试通过率、回归通过率等。那么如何充分利用这些数据呢？ 前面已对已知Bug以及未知Bug进行了讨论。现在换个角度，从Bug产生的阶段来分析，图1-12是不同阶段Bug修复成本曲线。 图1-12 不同阶段Bug的修复成本3 针对Bug各阶段的分析，根据图1-12中Bug越早发现解决成本越低的结论，需要尽可能在最早引入的阶

41、段发现Bug。针对某些阶段漏过的Bug分析，要尽可能完善测试设计覆盖，避免Bug都留到集成阶 段发现，降低版本延期发布风险，从而开发出更高效的发布版本。 例如某个项目，集成测试发现的Bug占比只有整个版本（所有各分支版本）发现Bug的3%6%，这些Bug大多是分支合流跟主干耦合的问题，还有一些是机型覆盖或者运营配置问题。大多数Bug都已 经在各FT（Feature Team，特性模块）分支上发现了，这样集成后的发布风险就会大大降低，加快了发布速度。图1-13是FT分支的合流模型，各个分支FT都能充分保证质量，这样合流后集成测试问题就 很少了。 图1-13 分支合流研发模式 也许有人会说3%6%

42、并不算少，确实，不同项目有不同要求。这里介绍的思路就是充分利用这些数据去思考与分析，推动团队采取动作，逐步降低该比例，逐步降低发布风险，提升发布效率。分支合 流模型的测试如何开展是另外一个话题，不过大体思路都差不多，除了基本持续集成外，还需要自动化测试（BVT、接口测试、终端性能测试等）的支持，才能快速支持分支合流的快速研发模型。 再举一个例子，Bug各模块分布，有些模块Bug问题比较多，可能需要特别关注测试，因为根据测试的二八法则80%的缺陷出现在20%的代码中，所以对这些模块需要多分析多做测试，这样可以 更大可能发现潜在问题。一般来说，不同模块会对应不同的开发团队或者FT，也可以通过Bug

43、来评估开发团队（或者FT）的成熟度，根据不同的开发团队（FT）制定相应的改善措施，用数据说话，这样更 好地推动团队的正向优化。表1-1所示的是另外一个项目团队某个版本的各个FT存在的缺陷占比，从表中可以看出模块A是缺陷高发区，出现这种情况需要和对应模块的负责人进行沟通，细查原因，以利于 改进。 表1-1 场景操作讲义及举例 以上仅仅是从Bug模块分布来分析Bug数据，其实还可以从很多维度（从开发人员的维度、用户行为的维度等）去挖掘Bug数据，充分利用Bug数据来优化测试设计，提升测试效率。 1.6.2 线上数据 以上介绍的大多是与研发过程品质相关的，其实还有一个很重要的方向就是线上品质，通过线

44、上海量用户上报的数据来度量产品品质。大多数情况下，研发过程品质始终无法保证线上品质。比如用户 反馈的重现问题，就是线上用户反馈的问题我们怎么也重现不了，即使严格按照用户的步骤、机型、网络等场景也重现不了。研发过程中测试的数据跟线上用户的数据对应不上，例如某个产品的启动速 度，研发过程中测试的启动时间是2.3秒（测试20次取平均值），而线上用户上报的数据是3.2秒（20万个用户上报的平均值）。 业界也有相关测试方法，例如微软公司提出的TiP（Testing in Production），就是通过版本上线后海量用户上报各类数据来发现潜在的问题。测试人员需要关注各类性能数据，例如启动速度、内存、 流

45、畅度、响应时间、Crash率等。因为用户的机型、网络、地域、数据环境不同，所以不同用户上报的数据差异很大，这里需要做一些数据统计的分析处理，才能更好地展现出来。由于线上环境的复杂 性，线上数据反映的结果会比测试数据差一些。 那么如何通过线上数据来分析定位问题呢？主要的方法就是对某些指标进行详细埋点上报，这样才能获得更详细数据并进行分析，最后找到问题所在。还是以某个产品的启动速度为例来说明（启动速 度是指用户点击应用图标开始到拉取完数据展示给用户的这个时间段）。 App启动后就会到后台服务器拉取数据，从大的方向来看，需要区分后台服务器耗时以及App处理的耗时，这样可以方便前端或者后台解决问题。如

46、图1-14所展示的，“等待响应”就是后台服务器耗 时（其中也包含网络传输的耗时）。一般可以通过抓取网络包分析得出相关耗时。 图1-14 启动模型 图1-14中的RTT（Round-Trip Time）是客户端到服务器往返所花的时间。 当然，只区分客户端跟后台服务器各自的耗时是远远不够的，还需要细分到每个主要函数的耗时，这样才能更好地定位具体是哪部分耗时。图1-15所示的是某个App对关键函数（节点）的日志统计。 图1-15 关键函数（节点）的日志统计 图1-15只是启动速度这个指标需要记录的数据，可能发现需要记录的数据非常多，对这些记录的日志也会进行分级，线上发布版本的日志会尽量少一些，不过关

47、键的地方还是需要记录的。当然，版本 加了日志会对性能有所损耗，不过在可接受的范围内，还是有必要的；通过线上版本的数据上报，可以得到用户真实的数据，发现潜在问题并逐步优化，给用户更好的体验，提升产品口碑。 注意 如果品质体系的各个指标都有数据上报，那么数据量将非常大，对数据分析挖掘要求就会更高，当然可能产生的价值也会更大，这样更要重视数据的测试。这也是我们强调线上数据测试的 原因。 测试数据还可以预测即将发布版本的质量，不管是研发过程还是灰度阶段，都将会产生很多测试数据。那么是否可以充分利用这些数据来预测上线版本的质量趋势呢？这确实是一个方向，但是需要大 量的测试数据才可能有机会预测靠谱。因为线

48、上用户的各种机型系统、网络状况、用户环境数据，这些都很难在上线前的环境覆盖到，所以就很难预测线上版本的质量。如果灰度群体足够，那么还是有机 会的。腾讯内部的很多项目，产品稳定性问题（Crash率）都是通过灰度来发现问题的，Crash率达到一定程度，就可以进一步扩大灰度规模，逐步迭代放大灰度数量，直至上线。 1.7 未来的测试 这一节内容都是笔者畅想的，如有雷同，纯属意外。 移动互联网时代，特别是Native的App，版本更新的成本很高（除时间成本，还有对用户体验的影响），所以大多数App都会经过充分的测试再发布版本。 随着热补丁（hotfix）技术的演进以及H5的流行，可以不需要发布新版本而发

49、布一个补丁就可以发布新功能或者修复问题（而且用户基本无感知，不需要安装过程，下次启动就自动更新了），这样就 可以在没有充分测试的情况下，快速通过用户来验证。这样对测试的依赖可能会越来越小。那么未来的产品都是通过用户（灰度或者正式上线）直接验证吗？ 应该不可能全部都通过用户来验证（灰度或者正式上线），不经过测试而直接上线，可能出现问题的概率会增大，如果真的出现问题，那么会对产品的口碑带来很大的影响。但是热补丁技术确实是可 以快速修复问题的方案，以后会被逐步应用。即使利用热补丁技术，还是需要度量产品品质的，例如线上用户各类性能指标以及用户反馈等，对于品质的追求还是始终存在的，也就是仍需要有人来做品质 这样的工作。 1.7.1 线上数据挖掘 既然线上数据会越来越重要，那么就需要一整套埋点上报体系（终端是SDK形式，服务端存储各类数据），同时对上报数据进行数据分析，可能需要利用到机器学习等技术分析数据，判断是否有潜在 问题。数据上报体系是每个App都有的基本功能，包含需要关注具体上报什么信息，例如， （1）路径埋点：关键路径的埋点。 （2）错