测试有段经典的对话：

T:测试测不过来

P：请接入XX工具，XX工具，XX工具，然后上BDD、TDD或者数据驱动啊。

T:BDD、TDD很有效，我也认为确实很有效，but，不要一次性变更太多需求。

P:DevOps是这样玩的，因为我是专家。

T:可是我们系统确实关联很多，一个需求，对应一堆爆炸性用例。

P:那是你们自己的原因，你想不想转DevOps，按照我的来。

这也是敏捷和DevOps化后，很多测试无法有效介入的原因，开发和运维玩的一套和测试玩的一套是不同步的，或者测试所做的事情并没有有效接入，导致合作方自己玩自己的，测试去兼容又困难重重。

打破反馈瓶颈，通过赋能，打破瓶颈，让瓶颈可视化。我们要做数据生成，做环境生成等等，大家自己想一想，这是测试做的事情吗？是，可以做，但是要的知识是运维的知识，所以不得不去体验运维。

第一

我们要可视化瓶颈，如果做的好了，先把测试环境申请时间比例降低下来，为什么，只要私有云做的好，运维你要什么环境，点一就下来了，如果这块没有解决的话，你某些事情还很遥远。

第二

测试环境的部署快了，还有测试环境的配置比以前慢得很多，因为现在环境复杂了。而测试的执行的时间通过自动化是明显降低了。

生产环境与测试环境是有的区别，生产环境通用，测试环境定制，测试环境的构建往往过长导致无法有效的完成反馈甚至无反馈，敏捷中有一种测试叫做拔网线测试，就是一种破坏型测试，无论是阿里还是腾讯都有类似的意外导致的系统宕机情况。而这种测试构造环境的周期就比执行要长的多。

DevOps赋能反馈，自动化评估影响范围，如果做这个需求，我能很快得到反馈，需要花多少时间，花多少成本，那么给需求的方做的事情就不一样了；

为设计赋能，为测试赋能，功能测试人员很难懂技术，开发测试很难懂业务，开发测试做出来的测试平台，开发测试人员会用没啥效果，何不为功能测试人员设计平台，让功能测试人员能够用。让功能测试和自动化测试能有效执行，这是值得我们不断的优化；

测试环境及测试数据自动支持，为运维赋能。运维的数据库你有权限连吗？能做脱敏吗？流量会不会做？就算运维数据脱敏给你了，很多数据也是没有用的，你要优化。你要的测试环境，运维知道吗，运维告诉你我怎么给你这个环境，你怎么编排这个环境，甚至你如何把你的测试有历史版本追溯？现在出了一个Bug，你退到这个版本上，运维可以做吗？很难，但测试人员可以做到，因为我们做测试发布的时候，你告诉我一个环境版本（该版本下记录所有服务器的应用版本），我就可以实现版本的统一了；为研发赋能，基于TDD的自动化快速校验质量。

当我们了解反馈很重要的，需要快速反馈。我们怎么做这件事情，首先测试不是替别人擦屁股的，而是提供支撑的，很重要的一件事就是我们需要隔离TestOps体系。

两方面，给出需求，我们生成对需求需要支撑的规范、评估、方案、脚本，就是现在走的测试设计这套东西。

第二，从设计级别完成执行部分，今天提一个需求，今天下午出一个版本，只要你把代码提交了，我们会自动跑整个执行过程，这样就效率比较高（时间关系这里我不会展开介绍），大家要知道，我用最轻的版本反馈别人需要的价值，这是一个优化过程，今天我能够花5分钟反馈几个核心功能，明天我争取多做一两个，而不是说今天把所有问题验了。如果我要两天时间，对不起，这样的代价太大了，用户觉得时间长不做了那才是真正的问题。我们要在质量、成本和效率中间找到平衡点，这就是所谓眼界问题。

现在回答另外一个问题，既然手工测试成本那么低，为什么还要做自动化呢，是因为我们愿意花三倍的代价，在最后上线那个阶段换取反馈的时间周期缩短三倍以上。我做一个测试两小时，我花更长时间先自动化测试，但是上线的时候只要花15分钟即可跑完测试，从而证明这个版本可以上线，我是为了省这个时间一小时四十五分钟，至于自动化做到什么级别，取决于大家所能投入的成本，用成本省时间。

讲个例子：

盒马鲜生有一次出过一次生产事故，把测试数据一百块钱减九十九券发到了线上，买一百块钱东西减九十九瞬间大家都去薅羊毛了，我作为一个服务器能取消订单吗，不行，我得做一个补丁。当我把补丁做完了等待上线的时候，能够等测试人员慢慢测试吗，每多等1分钟可能损失就是几百万！所以我愿意花二十倍的代价确保一件事情，谁能快速告诉我这个补丁上去是对的，不会带来更大的损失。其实谁都不知道你打下回车出去以后还会出什么问题，也就是说持续优化就是我们要做的事情。

很多东西很华丽，但是它没有特别的价值，第一测试开发不能解决真正的问题，只能解决工具的问题，光有微波炉不够，我们还要会做菜，还要切菜，开发、运维、测试都得学，都得会。第二个事情，不要上来一下子就做大饼，先做小的，用最小的投入换取最大的价值逐步优化。

这是我今天要讲的内容，谢谢大家。

QQ群：243771258