Jb的阅读之旅-不测的秘密（1）-CSDN博客

申明

先申明，本文非原创文章，基于书籍内容加上个人理解及观点二次输出；

书籍信息如下：

书名：不测的秘密 精准测试之路
TMQ精准测试实践团队
复制代码

因为边幅较长的原因，会分开几篇文章来展开，本文为第一章，主要介绍理论相关知识；

前言

最近几年互联网的高速发展，变化太快，相对的，用户也变的太快了；

体验真差；
设计太丑，一点审美都没有；
这交互，设计师怕有毒吧；
有bug；
好卡，好耗电；
复制代码

同类产品越来越多，用户就越来越在乎产品的体验、性能，因此，对交付能力的压力也越来越大，加上互联网高速发展，多项目并行已经是常态了，研发测试加班加点赶项目进度已经是常态了，这种情况下，测试往往会出现以下的问题：

无法设计全面的测试用例；
测试时间缩小；
回归测试频次降低；
无法深入理解业务；

因此，需要各种手段来保证质量，比如各种自动化，各种代码检查都是一种手段；

除了工具，还有其他方法：

给开发培养测试思维，增加自测范围跟流程，对于小需求可以免测；
输出主路径用例，让产品、运营进行体验，测试只负责异常场景验收；
集体试用，让项目部的同学一起参与到版本体验；
灰盒测试；
产品、运营、UI走查；

既然免测、不测的诱惑力那么大，肯定要去了解有什么做法啦，后来就发现这本书，当时是刚上市没多久，看着标题就感兴趣啦，懂不懂、能不能做已经不重要了，因此本章就是把书籍的一些信息Mark下来，仅此而已；

本书主要是通过技术的手段来尽可能达到免测的效果，流程组织这块涉及不多；

目标

这个目标是书上写的，同时也是大部分同学的想法；

在不降低质量标准的前提下，探寻缩减测试范围，减少测试独占时长，主要解决的是传统黑盒测试回归内容较多、耗时较长的问题；

测试独占时长是指从最后一个需求的提测时间到测试报告发出的时间；

完整来说，测试独占时长指从开发正式将版本/迭代/需求移交到测试开始，到版本达到可发布状态的时间长度，这里面包括测试活动、开发bugfix时间、新增需求等时间；
复制代码

敏捷下的烦恼

瀑布流

传统行业来说，大部分采用的是瀑布流开发模式，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。

好处就是让各职能只需关心各自负责的事情，阶段效率提升；

坏处

各阶段的人对需求的理解不一样，可能会后期造成返工的情况，而且代码会非常大；
前期的项目进展会影响到后面的工作进度；

在传统瀑布流模式下，理想情况应是这样的：

需求是清晰的；
流程是固化的；
开发是有序的；
系统是可测的；
测试时间是充裕的；
用户是讲道理的；

但实际上，需求经常改、开发交付问题多、测试总是被催、用户骂成狗、压缩测试时间、延期开发计划；

敏捷

而当今互联网发展如此迅速，传统的瀑布流已经满足不了要求，因此有人提出了敏捷开发模式；

敏捷的核心是快速迭代，拥抱变化；

最终目标就是让客户满意，能够主动接受需求变更，设计出来的软件有灵活性，可扩展性；
复制代码

这种情况下，需求说变就变，代码想改就改，早上说的方案，下午就推翻重做，又能如何保障质量？

虽然说，需求变动，就延长测试时间，但这样的做法就跟敏捷的本质相互矛盾，而且实际上，项目也不会给那么充足时间；

温馨提醒，压缩质量得到的进度是不可取的；

回归的痛

身为测试同学，一定会遇到以下的场景：

场景A

运营：线上有用户反馈问题啦，很严重，影响到正常运营工作，需要马上处理；
研发：啪啪啪，修复完了，测试验证下；
测试：改了哪些地方啊，功能影响面呢，会有什么影响？
开发：改了好多地方啊，安全起见，基本功能都回归一下吧；
复制代码

场景B

开发：昨天的修改测试完没啊！
测试：大佬，等下啊，还有XXX个用例要回归；
开发：我只改了一个方法，为啥要测那么多啊？
测试：哥，改动的是公共方法，相关业务都需要回归啊；
复制代码

上面的结果，基本的是以测试加班加点完成回归测试结尾；

到底什么是回归测试？某度上看到是这样定义的：

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误；
复制代码

软件测试的生命周期

问题的定义及规划（开发方与需求方讨论）
需求分析
软件设计
软件编码
软件测试（单元测试、集成测试、系统测试、验收测试）
运营维护阶段

软件测试的基本流程

开发流程

需求分析
得知功能组成和具体逻辑
编写代码
单元测试
打包提交测试
测试提交bug
修复bug
回归测试
N轮迭代
版本上线
面向用户使用
线上bugfix

测试流程

需求分析+原型图理解
编写测试用例
评审测试用例
等开发提测，此时可进行相关测试环境的准备
测试提交bug
修复bug
回归测试
N轮迭代
版本上线
面向用户使用
线上bugfix

行吧，从上面的流程可知，回归测试是整个测试过程中占有很大的工作量，各个阶段都需要进行多次回归测试，而工作内容往往是重复以前执行过的测试用例；

常见的回归测试方式

全面回归

这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。在实际项目里，随着用例不断增加，以及时间成本的要求，这样的回归方式已经是超出了预想的进度；

基于风险选择测试

可以基于一定的风险标准来敲定回归测试的范围。

首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级；

基于操作层面选择测试

如果修改的内容会涉及到用户交互，那可以优先选择那些最重要的功能或用户使用频率高的场景；

只测试修改的部分

如果测试同学知道当时修改点及修改方案，比如通过看diff或看研发提交记录，可以凭借自身的经验及对业务的熟悉程度，只做相关的回归测试；

这种方式，对测试同学的要求就高了，需要评估影响面，在条件允许的情况下，还是需要尽可能覆盖相关联的业务；

自动化

回归测试是重复性较多的工作，容易使测试同学感到疲劳和厌倦，降低测试效率，在实际工作中可以采用一些策略减轻这些问题。

例如，安排新的测试同学完成手工回归测试，分配更有经验的测试同学开发新的测试用例，编写和调试自动测试脚本，做一些探索性测试。

这里谈及到自动化，条件的反射联想到UI自动化、接口自动化，把重复执行的用例固化下来，这样就可以通过自动化来提升回归测试的效率；

但实际在做的时候，会遇到什么问题？你们知道吗？

测试的路在何方

自动化，一个说到烂的话题，但无可否认，这是测试避不开的话题，而一般说到自动化，大部分都是指UI自动化；

犹记得，第一次参与UI自动化，也是因为想减少测试同学在回归测试的工作量，当时的做法是这样的：

挑选合适的UI自动化框架，或用内部其他团队开源的框架；
挑选P0/P1测试用例；
按照手工测试的步骤，把用例转化成测试脚本；

经历了很长一段时间，当最终看到自己写的测试代码都能跑起来的时候，那种自豪感，啧啧啧，有种我很牛逼的错觉；

既然脚本都写好了，肯定是期望有产出，不然如何呈现其价值；

终于，迭代来了，第一次迭代通过了，看吧，以后回归测试就可以自动化处执行了；

随着不停的迭代，自动化呈现了它的价值，大家一看测试报告，就知道这次改动是否正常，是否有影响到其他功能，所有信息一目了然；

这是令人振奋的消息啊！

UI变了

但好景不长，互联网的特点就是快，这个快不单指节奏快，也指产品变得快，产品提出UI改版，这也意味着，UI控件也随之改动，自然会导致所有的UI自动化都执行失败了；

没办法，UI自动化就这样，高度依赖UI属性，一旦UI发生变化，随之而来的就是脚本的维护成本；

有什么办法避免吗？

坦白说，至少jb是不知道的，目前来说，这个问题是业界公认的；

因此，UI自动化建议只做P0级别的，最最重要的功能，用例数量应尽可能少；

传统自动化的价值

发生了这样的事，难免会让人重新审视自动化的价值，那先看，自动化到底有什么价值？

传统自动化的价值

在敏捷的理论里，存在这样的观点：

在传统瀑布流开发模式下，自动化测试的推行是一种进步；而在敏捷开发模式下，自动化是必不可少的环节；
复制代码

那做了自动化，到底有什么好处？

提高效率，缩短测试工作时间；
比人工测试可靠，因为操作步骤都是固定的，忠实可靠；
能加大每一轮回归测试的力度，提高测试覆盖率，但存在用例编写的维护成本；
具备更好地重现bug的能力，因为具备一致性和可重复性；

所以，传统自动化的ROI公式可以这么写：

自动化的收益 = 迭代次数 X 全手动执行成本 - 首次自动化成本 - 维护次数 X 维护成本
复制代码

这个公式有个大前提，那就是测试做的越多越好的情况下；

大多数人对测试覆盖率的理解是这样的：

分子是测试或自动化测试执行过的用例数；
分母是产品所有功能的测试用例总数；
复制代码

这样的理解，是正确但不全面的，这种情况，只有新产品才适用，而在迭代中的产品来说，就不合理了；

因为大部分回归测试，都是因为不确定，可能会导致同一个模块不停的执行回归测试，冗余比例非常高；

测试覆盖率说明

传统测试覆盖率，指的是测试执行的用例总数除以所有测试用例总数；

敏捷下的测试覆盖率，更多指的是测试执行的用例总数除以真正被执行的测试用例总数；

自动化的用途

上面说的自动化，可能更多偏向UI自动化，但是实际的，自动化能做的，不止UI自动化，那还能干啥呢？

测试环境的搭建和管理；
测试环境的检查、监控和预警；
测试代码的静态检查、编译和构建；
测试场景的构造，测试数据的自动化准备；
测试用例的分发和执行；
测试结果的保存与管理；
测试报告的生成；

根据上面可以做的事情，可以划分几种类型：

单元测试；
各种检查/工具，如静态代码检查、文件检查、签名校验、证书检查等各种功能检查；
自动化测试，包括UI跟接口，接口又分本地接口和服务端接口测试，UI则各平台；
性能测试；

自动化的价值

根据上面提及到的内容，简单总结下自动化可能的价值：

帮助回归测试，节省人力成本，同时能执行比较难回归的场景；
自动化构建，包括自动打包、自动部署/发布、数据构建；
前置测试，如静态代码检查、单元测试，在开发阶段暴露更多问题；

但是，无论自动化有牛逼的价值，本质上，就是在按部就班执行设定好的场景，因此，如何让平时较难/无法测的场景变成可以测，这个优先级可能更高，只有丰富了测试场景，再进一步思考如何把自动化价值发挥更多；

路在何方

这个问题，jb每年都会想，但是奇怪的是，每年的答案都不一样；突然想想，测试这岗位从某种意义上来说，就是万金油，需要懂产品、研发、运营、用户、管理、设计，甚至还要懂商务，因此，测试有多个转岗选择，并不是没理由的；

但是，从行业来看，测试的竞争力到底在哪里？

懂业务？懂用户？但是这个能比产品、运营更懂？

懂技术？一般开发都需要深入了解业务逻辑，从这个角度，感觉也不如开发；

测试思维？开发来做测试的工作，并不是说能力不能胜任，而是说不愿意，是思想的问题，换个角度，测试里开发能力很强的人，大部分都转开发了吧？这种开发，会比普通开发更注重质量；

换个角度，从职能部门出发，测试一直是属于技术岗位，如果只会黑盒测试，算技术岗位吗？

现状

来一起看看，从公司发展的角度，测试团队会经历哪些阶段？

公司初创，这个时候，往往是不需要测试人员，因为这个阶段最重要的是产品快速上线，试探市场；
业务扩张，到这步说明产品是有需求，需要大力投入研发跟扩张业务，这时候会不停的投入研发成本，相对的，测试人员也会不断的招聘；
稳定运作，这个时候，公司就需要考虑成本，比如开始裁员，这个时候，测试团队可能就可以缩减，走所谓的精英化；
严格控制每个环节的成本，而测试是贯穿整个环节的一个角色，因此基本是首当其冲的被提出，比如单元测试、开发自测、控制质量、减少测试周期、敏捷、线上质量把控；

从上面的阶段，基本上可以看出，前3个阶段，只需要会黑盒测试即可，这也就是目前测试岗位的现状，入门容易精通难;

绝大部分是黑盒测试/手工测试为主，少部分测试分析人员，自动化测试人员，性能测试人员，极少部分的测试架构师和测试分析专家；

正因测试门槛低，行业才有各种测试培训班，30天培训上岗，甚至是做其他行业转型做测试的，这种发生太多了，因此大部分人对测试的直接是，替代性强，重复工作，没技术含量；

我们没法改变别人对测试的看法，但是可以改变自己，如何让自己在测试岗脱颖而出，就需要自己学习更多的知识，自动化只是最初的一步，如上面说的，自动化可以做的事情实在太多了，有能力的还可以自己搭建测试平台，这就涉及到前后端，只有敢于前进，你才会发现，测试需要学的知识体系实在太庞大了；

代码分析

大多数研发在bugfix时，只会写上已解决，不会谈及问题原因及修复方案，这种情况容易出现修复一个bug导致新的bug，正因为测试不知道修复方案，无法评估影响面；

方案1

要求开发把问题原因跟修复方案描述清楚，这种方案存在依赖性，如果开发不自觉、换了个人、bug数量多等理由推辞，就会很难执行下去；

方案2

既然方案1依赖研发，那就自己分析代码，这里有前置条件，默许有对应项目的代码权限，不然一切都是空谈；

关注开发实现

黑盒测试

在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
复制代码

常见的黑盒测试方法有：

等价类；
边界值；
场景分析；
因果类；
判定表；
错误推测；
正交实验设计；
功能图；

不管是功能简单，还是功能复杂的产品，在黑盒测试方法下，都能快速拆解验收，但是相对的，耗时会比较多，而且一旦迭代较快的情况下，黑盒测试就会显得乏力了；

白盒测试

知道产品内部的工作过程，全面了解程序内部逻辑结构，对所有逻辑路径进行测试可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行；
复制代码

关注开发实现，就是从白盒测试的角度出发，也就只有关注开发实现，才能更加精准的回归，这样尽可能的规避修复5分钟，测试1小时的情况；

常见的白盒测试方法有：

语句覆盖，程序中每一条语句至少被执行一次；
分支覆盖或判断覆盖，程序中的每一个分支至少走查一次，即每一条分支语句的真假值各执行一次；
条件覆盖，当判定式中含有多个条件时，要求每一个条件的取值都要被覆盖到；
判断/条件覆盖，同时考虑条件的组合及判定结果的检验；
路径覆盖，使程序沿所有可能的路径执行；

黑盒与白盒，是两种不同的维度，白盒的优势在于对程序内部实现的了解，而黑盒的优势在于对用户场景的把控，测试本质就是破坏性的工作，因此两者结合才能多维度的保障质量；

因此必须建立在需求本身以及了解实现细节的基础上，根据逻辑、功能、兼容性等方面进行分析，从而得出详细的测试点，而并非一味的覆盖；

测试分析方法

基于需求的测试分析

分析的对象就是需求文档，考虑到需求本身以及需求所影响的功能模块，确认测试范围；

分析的基础：

对业务的熟悉程度；
对用户使用场景的了解；
产品功能矩阵；

分析的方法：

业务流程分析，描述业务的正向流程；
业务状态分析，描述业务对象的状态转换；
测试范围分析，需求本身的功能模块/受影响的功能模块；

业务熟悉程度直接影响到最终效果，而且受影响的功能模块，如果在不了解程序如何实现的情况下，很难界定范围；

基于开发实现的测试分析

功能测试分析

涉及的模块/文件；
模块交互的时序；
接口/类/函数设计；
实现细节；

性能测试详细分析

基于系统资源的性能测试分析
- 性能测试相关点；
- 开发相关实现系列；
- 关键指标；
- 性能测试场景设计；
- 性能测试脚本设计；
基于响应时间的性能测试分析；

接口测试分析

针对本次功能需求，是否具备可测接口，需要描述清楚为什么要测以及测试的范围
- 接口测试覆盖的接口定义描述；
- 接口内部实现的相关逻辑细节；
- 接口测试设计的实现方案；
针对本次需求，是否有接口变更，分析变更影响范围及测试内容
- 变更接口修改实现的相关逻辑细节；
- 变更接口对模块内功能影响分析；
- 变更接口对模块外功能影响分析；

稳定性测试分析

稳定性测试场景设计；
稳定性测试脚本设计；

兼容性测试分析

兼容性测试相关点；
开发相关实现细节；
兼容性场景设计、测试环境说明；

举例

重构，这个词应该是听过很多次了，而重构带来测试工作，是非常痛苦的，一旦重构的业务范围很广，那回归的工作随之增加；

记得很早之前，jb负责升级模块的测试，而对应的业务方有APP升级、组件升级、皮肤升级、主题升级、字体升级、增量升级、静默升级等多种业务，当时每个业务方都自己写一套升级逻辑，随着业务越来越多，升级业务越来越乱，因此提出重构升级模块，把升级功能统一抽离；

当时的做法分两步，第一步是根据原有的产品梳理业务逻辑：

查看需求文档；
找测试用例；
体验功能；

从用户、产品层面理解原来各业务的功能；

第二步，了解开发实现，对于开发来说，需要做这么核心模块的重构，也是需要梳理流程，因此会输出原有产品程序类图、调用逻辑、时序图等产物，然后根据重构的要求，输出新的设计稿、类图、交互时序；

通过这两种方式，得出一份新的测试用例，只有包括三部分：

升级逻辑内部的测试，不同业务其实就是传不同的参数，调用的入口只有一个，关注输入跟输出；
升级时机的测试，包括主动，被动触发；
关联业务方的正常、异常逻辑即可；

通过这样处理，实际要测试的是升级模块逻辑，就无需每个业务逐一进行回归；

而面试别人的时候，但凡听到负责过升级\安装测试，就会很本能的了解，主要是想知道是否有了解过程序是怎么实现的，只有了解过程序的实现，测试才能覆盖全面，比如升级需要下载，下载时出错怎么办、磁盘满怎么办、下载后根据什么条件校验安装包、被劫持怎么办、安装出错或者空间不足如何处理等等，而不是简单的依据，就看看安装后启动是否正常就完了，纯个人观点，欢迎讨论；