前情回顾：
上期我们一起了解了在测试的角度对质量内建这个活动的基本操作之一，太祖长拳之--测试先行。如果要落地质量内建，那么就需要充分的发挥质量排头兵--测试工程师的作用， 让测试工程师可以最大限度的发挥质量保障上面的天赋。
同时，软件开发也是一门技术活， 虽然它已经荣获新兴农民工的青睐，但不代表从事软件行业的人员都是农民工， 这就好像在一个建筑工地中， 有着不同的角色， 所以作为开发， 应该尽量的避免让CURD和CV大法作为自己核心技能；而测试，也应尽量避免让点点点和扯皮成为自己的核心技能，然后通过“转职”的路径使自己获取更好的职业发展。以上的做法我不认同也不反对， 我只是觉得作为一个工程师，一位工匠，骨子里应该不断的磨练自己的技能， 不断的打磨自己的方法论， 不断深入自己的行业深度，这样才能获取真正的快乐。好的， 有人一定觉得工作的目的是在赚小钱钱，这没毛病， 我写文章的目的之一也是这个，但这绝不是主要目的。
下面就是从工匠的角度看，一个测试工匠光会使用太祖长拳未免说不太过去， 这如果在电影里，也就是一个镜头就过去了， 凭这一招想成为“扫地僧“多活两集是远远不够的。今天，我就来给大家讲讲质量内建第二式之第八套广播体操：持续集成。
持续集成，故名思议，就是持续的，不间断的将新的功能增量“归集”到现有的产品中，使其“成为”一个新的产品。
如下图所示：
每次一个周期都会产出一个新的增量， 再由一系列的动作将这些增量合并至Release（发布）的实物中，周而复始，这就是持续集成。
那测试可以在持续集成中做什么呢？按照这张图，测试的活动有两个：
1.发布前的测试
发布前的测试即常规软件模型中的测试， 测试的工作是对于开发提交的工件（代码，功能等）进行质量检测，这里要声明一点，质量保证是大家的事情， 质量检测是这一环测试需要做的事情。
2.发布后的测试
发布后需要测试对已经发布的程序进行一轮验证， 这轮验证是即作为测试也是作为用户的。同样的，这轮验证也是一次质量检测的活动。
相信看官们已经看出来了， 单纯的质量检测并不能满足质量内建的要求，因为质量内建的的本质是将质量写入到项目的DNA里边。所以作为测试，可以在这个持续集成的循环中如何做才能将原来的“质量检测”的动作变得更大些呢？
我的答案是两种：
1.更大意义上的质量检测
2.更大范围的质量检测
对于1.我们已经在上一章体现了出来， 测试先行和测试的全覆盖可以将原有仅担任质量检测工作的测试工程师们一跃提升为质量保障工程师，从而去推动质量在项目全方面周期内的保障工作。
对于2.就是今天我想重点讨论的话题：
更大范围的质量检测作为测试和项目组需要共同攻克的难题，是想如果每个环节都进行或多或少的质量把控，那累计到测试工程师手上发现的问题会发生什么样的变化？
所以我们需要在每个项目环节中都将质量检测的动作落实下去。搬出万有软件模型之源：传统的软件工程V模型
单纯的看测试，测试分为：单元测试，集成测试，系统测试，验收测试
通常， 在传统模型中，除了单元测试，剩下的多数都有手工测试参与，而在目前的软件测试体系中，我们可以使用高级单元测试，API自动化测试，UI自动化测试，E2E自动化测试等手段将自动化测试进行模块化，将已经确定功能加入到持续集成中不断的测试，这样的好处就是可以不断的对已有的模块进行回归测试。极大的缩短了历史功能因种种改动出现问题的发现周期。
上述种种测试可以通过自动化方式覆盖整个代码的开发周期，甚至软件的开发周期，如果要覆盖大部分的功能， 需要编写大量的测试，如果编写不当，会造成维护测试用例的成本加大，从而加重测试工程师的负担；又由于测试用例带来的结果不精确，开发人员往往在排错后发现是测试用例的问题造成的测试失效，这也从侧面加重了开发人员的负担。
使用代码测试代码，这是一个悖论，如果软件中一定会有BUG，且自动化测试也是一个软件，那么就无法保证测试代码是没有问题的，所以自动化测试结果严格意义上是不完全可信的。
那么如何规划测试用例，使测试更加的可靠？
我们首先来分析一下各个维度的自动化测试用例的特点
基于如下特性， 一个较优的策略是将稳定性增高，可信性增高，维护成本减低，复杂度减少，代码能力减少，执行时间减少，这显然是不可能的，但也显然是可以权衡的
所以，经过实践和论证， 目前大多数的权衡方式是：
稳定性，维护成本，复杂度，执行实践
这是一个牺牲了可信性的解决方案， 这不意味着这个方案是没有可信性的， 由于在自动化测试中， 牺牲了一部分可信性可以权衡其他的指标性能， 所以大部分会选择通过人工验证去补齐这部分的可信性，因为人工测试的可信性无限趋近于100%。
权衡后，我们得到了当今最为业界承认的自动化架构模型：测试金字塔
这个金字塔描述的各个测试中以面积表示所应包含的测试数量和所应覆盖的测试功能点数量。
建立测试金字塔是非常有效的规划自动化测试的方式，不过有一个很重要的条件制约了这个金字塔，就是干系人。果然，所有的问题最后都会落在人上面啊。这个问题将在后面的文章中描述
另外还有两个知识散点，执行自动化用例是一个需要等待的过程， 很多项目和公司都进行了尝试，确定自动化全部通过以后才可以将代码合并到主干。开始一切都很棒，但自动化慢慢的变得臃肿，执行的时间也慢慢的增加，导致代码提交验证到合并需要半天或者一天， 这大大的增加了合并的难度，造成了极大浪费
同时，由于自动化的失败，去修复自动化用例也是有成本的，大多数自动化都运行在开发环境或者测试环境这种不稳定的测试，或多或少由于环境的问题，数据的问题，代码功能的问题导致少量的失败，所以要控制失败的比例。
统称提交代码到获得自动化构建的结果（包含编译，单元测试，集成测试，冒烟测试，部署等动作）叫反馈弧，那么对反馈弧方面自动化的建议是：
执行时间：10分钟
通过率：90%
好了， 这就是质量内建的行动--持续集成和自动化测试的一些拙见， 在自动化构建中，不同的体系一定会有自己的做法， 我将一些经验分享进行删改和合并分享到这里，供大家增删改查。
下期预告 ：
下面一期， 我想和大家聊聊质量内建的另外一个核心实践：测试也是资产。在这一章，我将和大家介绍如何使用管理代码的思想去管理测试
