上一篇我们去分析了在传统的研发场景下，程序员会遇到哪些会影响他们效率的问题，这一篇，我们再继续进行分析。 正常研发同学再将自己的需求完成开发后就会交付给测试同学测试，如下是研发同学和测试同学经常出现的真实场景： 1、这个流程今晚再帮忙测试一下； 2、我再等bug，你等等(然后测试同学不小心等了一个通宵)； 3、你怎么没测出我这段程序有空指针的异常(测试同学送你一个谜之微笑)。 当然测试同学也经常会和研发同学发生如下的真实场景： 1、bug改完了吗？ 2、bug改完了吗？ 3、bug改完了吗？ 所以，研发和测试其实也是一对冤家，而且假如遇上很苛刻的测试同学，研发同学肯定会遇上灾难。 但其实在我看来，研测双方其实是一体，你中有我，我中有你。 我们先看一下测试同学日常测试的工作量分配情况。
从如上的图我们可以分析到，抛却测试同学日常的案例编写，我们可以发现整个测试工作分为如下几个方面。 按照二八定律，我个人觉得测试同学有80%的工作都在功能性测试和案例回归的重复性测试上，而有20%的工作在于比如压力测试、安全测试支持、接口的MOCK上。所以人工进行功能与流程重复性测试的工作量占据了大头。 对于研发同学来说，其实也需要事先对自己的代码进行测试，这就要求研发同学经常去编写单元测试案例，所以研发同学千万不要以为写单元测试是给自己加需求，其实是本质工作。 所以我们会发现测试工作按照角色来划分其实分为面相于研发同学和面相于测试同学。 对于研发同学来说，往深点分析，其实就是如何去更好地进行测试驱动开发，即TDD的研发方式，我个人理解它的核心本质就是： 用代码去重试每个案例的失败。 对于测试同学来说，很多工作都集中在日常的重复性功能与案例回归上，所以我理解它的核心本质就是： 用生命去重试每个案例的失败。 这么一说，测试同学估计看得都觉得很委屈，所以研发同学日常在保证自己迭代速度的同时，也要多关注一下质量，毕竟代码的好丑会影响测试同学睡眠的多少。 那么，我把以上的测试总结为：Test for failure。 用上一篇的一句很流行的话总结就是：通过不断地失败来避免失败。所以测试过程中的案例失败其实对整个研发交付流也很有价值，其是最终真正交付必须经历的一个过程，也是保证生产质量的一个重要途径。 那么，我们如何能够去将重试的价值释放得淋漓尽致呢？我们看一下研测双方工作对标的情况。
我们来观察一下整个测试的要素其实分为如下几类： 1、UI测试。常规来说就是界面测试。 2、接口报文测试； 3、数据探索。其实就是去看整个测试流程中的数据质量如何； 4、流程理解与测试； 5、MOCK。 我们再观察一下研发同学的系列研发要素，分为如下几类： 1、UI设计。其就是美工和前端所涉及的工作； 2、接口设计与研发； 3、数据库设计； 4、业务架构设计以及业务流程梳理； 5、单元测试。 从以上的这个流程中，我们可以去进一步探索出如下的结论： 首先，研测双方针对于UI、接口报文等，其实可以进行复用性的探索，而复用性探索的目的就是如何将来进行复用内容的自动化测试。 接着数据以及业务流程，其实是研测双方的业务互动，而这样的互动其实就是帮助研测双方对业务目标进行对齐，而不是到测试的时候才发现原来大家理解的业务流程是不一样的。 最后，研发同学为什么要做单元测试？其实就是在保证自己代码质量的同时，也是提高测试同学MOCK的准确率。 所以，测试同学对于研发同学来说是缺不了，另外，我们从其上也可以发现，保持互动，是保证DevOps价值流持续推进的重要因素之一。 然而，有些场景还真没有测试…… 比如代码的规范检查、代码的一些可观测的BUG、单元测试的覆盖率保证。 我把以上称为压在程序员身上的三座隐形大山。 那我们怎么去相对释放这三座大山呢？
我把常规的打包构建分为两个过程，分别是代码编译构建和打包。 那么我们就可以思考，加入我在这两个过程之前先进行一轮释放三座大山检测呢？
所以我们通过将一些检测环境进行前置，或许可以给我们带来一些帮助，然而，我们也会遇到其他的一些问题，比如技术债务的解决时效，比如单元测试覆盖率的债务，而这些债务因每个企业研发的情况，正常都会通过灵活的阈值去满足不同的情况。 最终经历了测试过程后，我们就可以正式交付上线了，那么在上线过程中，我们又会遇到哪些问题呢？我们下一篇继续进行分析。
—————–EOF——————