第1章 测试观
11.1引言
在正式开始谈iOS测试前，先为读者朋友引入一个思考问题：千百个人有千百种测试观，那么到底测试人员应该持有何种测试观呢？我们先来看下测试的定义发展史，经历了如下历程：
20世纪60年代：软件开发过程中，将测试等同于“调试”
1957年“软件测试区别于调试，成为一种发现软件缺陷的活动。”
1972年在北卡罗来纳大学举行了首届软件测试正式会议。
1975年John Good Enough和Susan Gerhart在IEEE上发表了《测试数据选择的原理》的文章软件测试被确定为一种研究方向。
1979年Glen ford Myers的《软件测试艺术》中，定义“测试是为发现错误而执行的一个程序或者系统的过程”
1983年Bill Hetzel在《软件测试完全指南》中指出“测试是以评价一个程序或者系统属性为目标的任何一种活动测试是对软件质量的度量。”
2002年Rick和Stefan在《系统的软件测试》一书中对软件测试做了进一步定义“测试是为了度量和提高被测软件的质量对测试软件进行工程设计、实施和维护的整个生命周期过程。”
“软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。”---百度百科
以上测试（软件测试）定义都没错，那么测试工程师应该怎么做呢？
通俗一点来解释，笔者理解的测试：测试=工程效率+品质管理。相对应的，测试同学做的事情就是提升工程效率，做好品质管理。引用谷歌团队的一段话：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研发模型），例如包含但不局限以下活动：
（1）需求评审：需求评审机制以及更新通知，避免需求改动没有及时同步到相关角色。
（2）代码质量：静态代码扫描，千行代码缺陷率等。
（3）架构评审：代码架构的讨论以及评审。
（4）Bug流程：Bug生命周期，避免随便修改Bug状态以及备注缺失。
（5）Code Review：代码评审，如果有代码评审委员会就更好了。
（6）Dogfood：自己做的产品自己（项目各个成员）先体验。
（7）Showcase：完成某个特性，可以组织会议针对某个特性进行展示，一般产品经理主持。
上面提到的活动，都是需要整个项目团队（各个角色）通力配合，才能更加高效。
再提一下测试效率，这个大多数是测试工程师主导，也是测试工程师最主要的工作内容。测试效率包含不局限这些活动：
（1）测试周期：测试与研发周期是密切关联的，包括迭代测试、集成测试、回归测试、上线测试等等，每个阶段都要把握好测试效率和测试资源分配。
（2）测试设计：包括需求覆盖度，用例覆盖度，用例执行效率等。
（3）自动化测试：使用自动化执行的方式执行测试，快速出测试结果，节省人力成本。
（4）静态代码分析：使用一定的工具来对代码进行静态扫描，提前发现代码隐藏问题。
（5）测试技术创新：通过对测试技术的创新，例如精准测试、机器学习等方式，来变更测试方式，大幅度提升测试质量和效率。
接下来举两个例子具体看下。
1.2.1自动化测试
其中关于自动化测试，这里着重讲一下。自动化测试在20世纪90年代才开始逐渐成熟，特别是敏捷研发的流行以及推崇TDD模式，自动化测试也逐渐流行起来。对于自动化测试还是得多关注投入产出比ROI，特别是对于UI自动化测试。业界自动化测试金字塔模型也是建议多做单元测试或者接口测试多于UI自动化测试。关于自动化测试投入产出比，本书将于第六章介绍。
对于iOS平台上的自动化测试实践，我们也有在不同方向上的尝试（见第五章介绍），并都有不错的收获。相关自动化测试的开展还需要有一些自动化测试框架的支持（详细自动化测试框架的介绍将会在本书第七章），QQ浏览器（iPhone）测试团队主要移植Google开源的EarlGrey框架来作为自动化测试的基础框架。本节先简单介绍几种主流自动化测试类型。
（1）BVT（Build Verification Test）
业界现在都流行持续交付的模式，那么每次持续集成编译出包后，自动化运行一些基础功能测试用例，保证版本基础功能可用，确保不会因为新代码合入影响基础功能。这部分主要是UI自动化测试，当然随着版本需求变更，维护成本也会增加。不过对于QQ浏览器的UI变更还不是很频繁，维护成本还相对可控，整体的投入产出还不错，可参考第六章内容。
（2）监控类
根据产品的业务特点会对产品做一些监控，例如手机QQ浏览器（iPhone）项目实现了三种类型的监控测试，分别是终端视频嗅探监控、终端feeds流短视频可播性监控、终端资讯类监控。这部分监控的基础框架和BVT实现是一致的，只是基于业务形态做了调整，采用的也是Earlgrey框架进行二次开发。本书没有进行一一罗列，可参考第六章关于测试框架的二次开发。
（3）性能自动化测试
性能测试涉及到各种数据的采集和分析，而数据采集往往很复杂并且非常耗时，我们的性能自动测试也都集中在数据采集这一块。目前我们针对页面速度、产品稳定性、电量、流量、内存等各个方面作出性能自动化测试的尝试，详细内容请见第四章。
1.2.2静态代码分析
所谓静态代码分析就是在不执行代码的情况下，通过一定的算法规则（词法分析、语法分析、单函数分析、代码段分析、数据流分析、资源分析、依赖链分析、更高级的智能逻辑分析）对整个工程的代码进行分析，以此来找出代码中的缺陷。这样就可以提早的发现问题，大大降低研发成本。美国软件工程专家Capers Jones的软件测试缺陷价值图如图1-1所示。
图1-1 软件测试价值图
三条曲线分别代表引入的缺陷、发现缺陷、缺陷修复成本。越是在前期发现的缺陷，修复缺陷的成本越低，越是到后期修复缺陷的成本越高。通常发现缺陷主要是在功能测试、集成测试阶段。
如果能够在Coding阶段就发现发部分缺陷，就能大大降低修复缺陷的成本。静态代码分析技术恰恰能够很好的在Coding阶段发现部分代码问题。这样就能够大大节约软件开发成本。
iOS平台经过实践论证比较好用的两种工具如下所示。
（1）Clang的Scan-Build工具（下载地址：http://clang-analyzer.llvm.org/scan-build.html）。
（2）FaceBook的Infer工具（下载地址：https://github.com/facebook/infer）。
目前这两个工具都是开源的，除了能够使用其基本的功能之外，如果还有其它的业务需求，可以对这两个工具进行二次开发：添加自己的静态分析规则、分析算法。
QQ浏览器（iPhone）项目采用Scan-Build发现的代码缺陷，如图1-2所示。
图1-2 Scan-build缺陷发现统计图
采用Infer发现的代码缺陷统计如图1-3所示，共计发现1275处缺陷。
图1-3 Infer缺陷发现统计图
每日构建版本时配置工程会自动采用这两个工具对工程代码进行静态代码分析，这样在提测试任务前就能发现代码缺陷，大大降低软件缺陷修复成本。
本文选自《腾讯iOS测试实践》第一章，本站经机械工业出版社和作者的授权。
版权声明：51Testing软件测试网获机械工业出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
