前情回顾：
质量内建， 称得上VUCA时代的项目赖以生存的重要实践。任何高速运行的项目都不应该将质量检测作为整个工程周期的之中的一环，所以对质量内建的需求越发广泛。作为质量保证的排头兵--测试工程师，将付出极大的努力将“测试”这个动作转变为“质量保证”这个角色，再进一步进化为“质量内建”的执剑人。
这是个进化的过程。需要一个测试工程师付出很多时间并付诸很多实践。接下来，我想用我的视角去介绍测试可以在质量内建上可以做的事。我将这些事分为了三类：行动，方法，准则。
行动是讲述测试进行或者引导的具体的动作， 这是立竿见影的。
图片.png
虽然我列举出来如此多的行动， 但还完全不足以描述测试人员在质量内建工作中的实践。
因为这些行动都是基于质量内建的方法。符合方法的行动包罗万象， 所以如果要掌握全部的行动， 就需要掌握质量内建的方法，至于质量内建的方法， 请期待我后续的文章[狗头]
好了， 经过了这一波极限拉扯， 我们聊回正题：
下面， 我将给大家一一产出上面列出的质量内建的行动， 这些行动，是对很多项目，技术文章， 经验总结和最佳实践分享的汇总，一旦落地，可以有效的增加你所在的项目的质量内建成熟度。
测试先行
在项目中，往往测试是最被忽略的， 我见过很多不成熟的项目都会将测试视为项目的一个环节， 即开发完成的某个时间段“交”给测试， 或让测试在软件开发某部分之后完成之后再进行投入等等。或许会发现， 这两种情况都有一个隐含的逻辑，即“开发”这个活动和“测试”这个活动有明显的时序性。
或者说，如果将测试活动的时间和开发活动的时间做一个时间轴的话， 你所在的项目是什么样的呢？让我们来尝试着画一下：
也许你的项目是这样的
图片.png
也许你的项目是这样的
图片.png
也或许你的项目是这样的
图片.png
如果你画出的图是图3那样的， 那么恭喜你， 有极大可能你的项目已经处于高度的质量内建成熟度中了！
（不过也有种可能， 是你的项目测试人手不够， 测试的人员的任务一直积压，导致测试不停的加班，也会有这种图出现）
我想大多数同学画出的图，都会和图1， 图2很像。因为我所在的项目也是这个样子，从图中不难看出，测试和开发的关系存在明显的时序关系，就是测试一定是在某些开发活动以后进行的。
为了说明开发测试存在时序会引起的问题，首先引入著名的问题发现与修复成本曲线
图片.png
大家可以看到，大多数缺陷都是在开发写代码的过程中被引入的， 单元测试可以发现一些问题， 但大多数问题都是在功能测试，系统测试（实地测试）中发现的。
这时的问题的修复成本要比在开发阶段修复的成本已经发生了指数级的增长， 因为这时，程序已经形成，代码之间的逻辑复杂度是指数级别的增长的，加上部署后的环境的复杂度，带来了更多的定位后修复的难度，如果遇到了灾难性的架构设计，难免会有“牵一发动全身”、“打地鼠”等等场景出现， 给整个项目组的开发和测试同学带来无尽的伤痛。
同时根据对缺陷出现的根因进行分析，你会发现
一定程度上的缺陷都是基于对需求不理解导致的，项目中不符合需求的缺陷数量是与开发自身的素质、对业务背景的理解和需求清晰度是成反比的
所以，假如一个程序员完成了一个函数之后，在提交代码的时候就会自动有人告诉TA，函数是否是正确的，符合业务逻辑和设计的， 这将发现缺陷的时间点提前了，也就是将修复缺陷成本降低了
我们来粗略的计算一下
假设一个bug在开发阶段修复的成本是0.5人天， 经过了单元测试，功能测试，集成测试，到了发布，他们的修复成本按照指数公式套入
图片.png
我制作了一个表，描述了分别在开发， 单元测试，功能测试，集成测试，发布各个阶段修复成本的预期
图片.png
虽然这是理论值， 不难从这个n与项目周期的各个阶段看出n发布后修复一个问题的成本照比开发时的差异随着n的变化巨大。
所以从理论上缩减修复问题的成本有以下两个途径：
-
尽早的发现问题
-
缩减n
n是价值流从左向右移动的速度参考系数，这是DevOps领域的知识， 在这里不再赘述；接下来，我们要讨论的是如何尽早的发现问题。
这个问题的解决方式很简单，让我们想象一下问题由谁来发现：测试工程师。如何尽早的发现问题：尽早介入。我们来做一个简单的加法从而得出我们这次的主题：让测试工程师尽早的介入
使测试在开发环节就介入的一个重要的实践就是引入TDD，ATDD。
TDD
TDD:TDD是测试驱动开发（Test-Driven Development）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。
TDD中的测试往往是单元测试，很多项目中使用大量的测试去和业务规则进行映射， 建立代码修改的防火墙，在代码创建和修改的时候第一时间验证了代码的正确性。
以下是一个使用TDD构建代码过程闭环：
图片.png
在这个闭环中， 最重要的就是一切的开发活动都是“围绕让测试用例通过进行的”， 所以，在TDD的工程实践中， 是以测试用例为核心进行开发。这与现在大多数项目代码为主，测试用例为辅的模式正好相反。很多的测试用例也是开发为了满足单元测试覆盖率而草草了事的。我个人认为TDD是倒逼开发认真编写测试用例的重要手段。
聊了这么多，你可能会问：测试需要干什么？测试在TDD中合适的介入，是会极大的帮助整个开发过程的， 试想如果写测试用例和写代码的人是同一个开发工程师的话， 他就会有可能因为自己的主观理解错误导致编写的测试用例和代码的错误，这就使得TDD失去了存在的价值。因为测试人员的水平不同， 测试能在这方面做的事情也会不太一样：
如果测试具有开发同等的代码水平， 可以让测试工程师编写测试用例，这会降低因个人对需求理解错误产生的风险，也可以提高开发编写代码的效率（开发可以和测试并行工作）
如果测试具有读代码的能力，可以让测试参与审计开发编写的测试用例，通过测试工程师丰富的业务经验和专业的业务技能来使测试用例更加的完善和准确
此外，测试人员还可以作为观察员， 检测各个节点，设置准入规则， 请开发人员交叉编写测试用例，在开始开发前说明自己的对需求的理解等等非技术性的方式达到落地TDD的目的。
ATDD
这是一种在编码开始之前将客户带入测试设计过程的技术。它也是一个协作实践，用户，测试人员和开发人员定义了自动验收标准。 ATDD有助于确保所有项目成员准确理解需要完成和实施的内容。
图片.png
直观的看上去，这个大的三角形里边包含了很多的TDD， ATDD和TDD都是编程中“以终为始” 的做法，先确定终点，然后再去向终点努力。
但ATDD的视角更高， 它是在“用户验收”这个角度上的观察，所以作为测试工程师，可以确定很多用户验收的用例，这里推荐这样一个时序：
图片.png
这使得开发和测试在原有的传统工程中通过改进流程达到了将测试工作提前至与开发动作开始基本相同的时间点， 作为开发的“守护进程”的角色出现。
好了， 这就是测试可以在质量内建中进行的一个活动： 测试先行中的TDD和ATDD的介绍， 符合测试先行的实践有很多， 真香的有TDD和ATDD，所以着重的介绍。
在TDD和ATDD中， 实践中的技术并不难， 困难的是消除开发同学， 项目同学和业务同学对测试定固有思考：
将测试工程师以质量保证工程师来看待，这将会是公司乃至软件行业的一大进步。
下期预告 ：
打完这次太祖长拳，下期我们来学习测试在质量内建中的第二式：测试金字塔。这将让测试在生成用例的过程中不再迷茫，从一开始就把测试和自动化测试这两件事情做对，做好。
网友评论