陈霁：很高兴和大家聊这个话题，开始正式话题之前我想问大家一个问题，大家觉得我像谁？
是不是很像某个知名的公子，每次都有人拿这个说我，搞的我也不好意思。那么我为什么会问这个问题，是因为我想看看是不是真的很像，是朋友忽悠我么？现实中大家都非常需要反馈，特别是在自然群体中获取认可，我美么？我做的对么。所以我想说的是，在我们现在做的所有的一切事情中，大家都在谈我该怎么做，但是有没有想过一件事情，我做的事情，未必是别人想要的事情！自我YY是不太合适的。今天借助NCTS大会跟大家分享一下在TestOps上面如何做一个优秀的测试价值反馈。
话题包括四件事情（DevOps中的反馈需求、反馈局限、打破反馈瓶颈、最优质量反馈）
首先为什么会做敏捷，DevOps中的反馈需求，不但要做的快，还要做的对。
我们做测试，会想一件事情，要学自动化测试。为什么，因为它快、懒（其实是工资高），做适配有那么多的手机，拿自动化点一下就行了，当然还要学习写脚本，学工具。在这个时候面临一个问题，就是我们非常需要反馈，我到底怎么算学会自动化了。我看到大家笑了，作为测试人员，我们代表用户反馈价值，我们也是客户，那么我们怎么知道我们代表了客户反馈了正确的价值。
第一，用户需要反馈，确定自己的商业计划能够完美实施，实现了是不是客户想要的，这是测试要代表的，不要过了一个礼拜以后客户看到产品说对不起这不是我想要的（然后需求、开发、测试重来一遍）。
例如：有一个人做过这么一件事情，他在咖啡厅遇到一位美女怦然心动，于是走过去对她说“我想每天早晨醒来第一眼见到的就是你”。这种表达方式是相对委婉的，直接的这里就不说了。其实这就是一种获取反馈的方式，如果美女答复你是臭流氓，她对你反馈了你知道答案了，如果不答复这是冷暴力，你还是不知道到底结论是什么（是她没听懂，还是你们两个不合适，还是她只是不好意思在等待你进一步）。第一价值是什么，就是用户价值，用户价值的实现是最优先考虑的。所以这里我要提一件事情，很多测试为了证明自己技术很牛做了一个什么平台，但是并没想过，这个东西做的是不是有投资回报比，有无有效的反馈价值。
怎么反馈价值？需求端做了吗？流水线做了吗？我们从自动化金字塔做到菱形，从UI做到接口做到单元，再往前一些，甚至Kanban、UserStory的反馈，其实大家做的都很辛苦，而且并不见得效果很好。在我看来，要改变很多事情，主要在思想和思路上的改变。
第二件事情，领导需要什么反馈？
确定能否按时按质完成任务获得回款，领导想看到每天大家都在写代码，以前写代码，我的Git/SVN上有记录就行了，目的就是考核大家工作量，能够看到大家在做事就行了。但是其实会发现，这种反馈没多大实际意义，因为反正只要代码跑起来了，开发就能说我工作完成了。开发就写代码就行了，时间到了就说软件做出来了，至于好不好用，还有运维时间和修复时间。于是你会发现，这个软件到处都是Bug，随着时间的推移越来越多，也就是本质上你看代码是没有真正实现的。为什么？要赶工期，所以领导需要的不仅是写代码快，而且”还要”真正的实现了，这个反馈谁来给？大家也许有孩子，会发现每天老师在群里会发一下，今天孩子在学校学了什么，今天回家家长要考一下孩子掌握了没，这就是老师给家长的反馈检查方法。
真正有价值的反馈是什么呢？是员工的反馈或者开发的反馈？大家想一想，整个软件成功的要素是什么？给最终用户快速反馈：用户说的需求我懂了，并且做出了东西。今天早上客户给需求，今天下午出版本，晚上给客户看，这就是敏捷快速交付。
以前怎么解决的？会做UI原型，但是这个东西照着UI做出来，按照这么用是对的，一旦上了环境或者某些特殊机制上就错了，因为我们需求上的分解是不够的，最终导致用户验收的反馈误差。
当我们需要反馈的时候，DevOps谈了一个三步法，第一，从左到右，快速流动，工作可视化，小批量，打造持续交付流水线；可靠的自动化测试，低风险自动化发布；第二持续反馈；第三精益（我们今天不谈）。
接着问大家一个问题，“我们在需求阶段，实现阶段，发布阶段，我们做反馈怎么做的？”，我怎么告诉别人我做的东西对不对？从设计阶段到实现阶段，我们做了什么东西给别人参考的信息。在软件研发中，测试是立法的，而别人是实现的，怎么告诉别人这么做一定是对的？Ops能解决Dev需要的反馈么，当我们发布的时候，我们怎么解决质量问题。
我们首先看一下需求阶段，大家有多少人在用看板？将所有价值可视化，我们不知道别人在干什么，还有多少事情要干。开发团队为什么没有给版本，说好下班给的，等到明天还没有给，一问还没下班。我们在做需求阶段，第一是用户需求前置的验证，甚至邀请用户参与这件事；第二就是通过看板提醒，在公司墙上有一个看板，知道有多少需求在这里，价值是在什么阶段，瞬间就能知道。如果大家没有使用kanban可视化的时候，你会发现每个人都很忙，但不知道忙什么，导致一个问题，我们并不知道用户所要的价值是否最先被实现了。
接着我们看一下实现阶段，高级一点的静态走Java的阿里代码规范，普通一点就跑一下Sonar就行了。开发者写代码一提交，Findbug系统告诉开发这个代码上面有很多的问题，这个反馈很快，至少你知道这个代码有问题了，但是有一个缺点，误报率非常高，你的代码一千行丢进去，一千五百行错误出来了。其次很多时候我们使用TDD单元测试，请问单元测试有反馈吗？大多数情况开发自己做的单元测试，开发懂业务吗，很少能做到，所以开发做不到真正从用户的角度做系统测试的落地。除非是规范性的测试用例，比如天天都在说写登陆的测试用例，这个还是可以规范出来的，开发可以自己测试落地，微服务的契约测试也是可以做到的。
在实现阶段后面我们再做什么反馈呢？第一手工，其实我是非常反对自动化的，不一定每件事做到自动化就有价值，你最快的时间告诉人家对不对就可以了，自动化未必就比手工快。你觉得你衣服上面有污迹非要拿到洗衣店还是自己直接擦掉快？技术是一种手段，但是价值是看你的反馈。我以前是做性能测试出身的，我会明确的告诉大家，你做性能测试的目的不是要花多少钱解决问题，而是你能省多少钱解决问题。现在微服务下服务性能的问题，几乎都可以花钱解决。所以反馈可以通过手工测试，也可以通过自动化，甚至还有灰度发布这些东西。
为什么我们要做自动化，自动化有时候性价比不高，甚至在国内大多数自动化是没有性价比的，原因是因为我们在适应开发者，而不是开发者适应测试框架。自动化测试如果你用现在标准的前端很容易实现，比如前面茹老师提到的自动化页面分析形成PO。但是你遇到过iframe套iframe的系统吗？我就遇到过，大家努力做一些框架，目的是去适合于被测对象，就像在一个不对的基础上发明一个东西来适应，发明一个自动收垃圾机器一定合适么？其实外面没有垃圾桶不就没有垃圾了嘛，因为没有垃圾桶大家就不会随便在路上产生垃圾。大家现在可以理解日本为什么那么干净，日本在路上是没有垃圾桶的，垃圾桶越多，垃圾越多。不同的阶段有不同的反馈，这些反馈做的都不够好，所以我们要想想怎么解决整个DevOps反馈的需求。
在DevOps流水线上，大家一定要做到可视化反馈周期。
我们的需求是按每个小时级别提的，构建是按秒实现的，测试是按天做的，而部署是按分做的，大家各个公司都在做DevOps持续集成流水线的，有没有想过一件事，如何可视化CI流水线时间？就像在性能测试中，整个全链路的响应时间分析，我要知道每个节点在页面刷新多长时间，后端数据验证多长时间。有没有仔细想想看，怎么样可视化解决反馈周期，怎么提高速度，因为我们要快，我们要就要降低等待时间，我们把等待时间浪费在哪里？现在看看都是在测试阶段。自动化测试和部署开发是脱节的，大家知道我们的环境在哪里，怎么部署呢（瓶颈）？DevOps其实并没有有效解决这样问题，它慢在什么地方，只有测试才知道。开发者会告诉你，敏捷教练告诉你，我们做的很规范，我们都是标准化的，让大家遵守，减少沟通成本与维护成本。运维端，有CMDB与封装的原子交易等，统一标准化。开发端，有配置管理，纪律化的CI等。
测试有段经典的对话：
T:测试测不过来
P：请接入XX工具，XX工具，XX工具，然后上BDD、TDD或者数据驱动啊。
T:BDD、TDD很有效，我也认为确实很有效，but，不要一次性变更太多需求。
P:DevOps是这样玩的，因为我是专家。
T:可是我们系统确实关联很多，一个需求，对应一堆爆炸性用例。
P:那是你们自己的原因，你想不想转DevOps，按照我的来。
这也是敏捷和DevOps化后，很多测试无法有效介入的原因，开发和运维玩的一套和测试玩的一套是不同步的，或者测试所做的事情并没有有效接入，导致合作方自己玩自己的，测试去兼容又困难重重。
打破反馈瓶颈，通过赋能，打破瓶颈，让瓶颈可视化。我们要做数据生成，做环境生成等等，大家自己想一想，这是测试做的事情吗？是，可以做，但是要的知识是运维的知识，所以不得不去体验运维。
第一我们要可视化瓶颈，如果做的好了，先把测试环境申请时间比例降低下来，为什么，只要私有云做的好，运维你要什么环境，点一就下来了，如果这块没有解决的话，你某些事情还很遥远。
第二测试环境的部署快了，还有测试环境的配置比以前慢得很多，因为现在环境复杂了。而测试的执行的时间通过自动化是明显降低了。
生产环境与测试环境是有的区别，生产环境通用，测试环境定制，测试环境的构建往往过长导致无法有效的完成反馈甚至无反馈，敏捷中有一种测试叫做拔网线测试，就是一种破坏型测试，无论是阿里还是腾讯都有类似的意外导致的系统宕机情况。而这种测试构造环境的周期就比执行要长的多。
DevOps赋能反馈，自动化评估影响范围，如果做这个需求，我能很快得到反馈，需要花多少时间，花多少成本，那么给需求的方做的事情就不一样了；
为设计赋能，为测试赋能，功能测试人员很难懂技术，开发测试很难懂业务，开发测试做出来的测试平台，开发测试人员会用没啥效果，何不为功能测试人员设计平台，让功能测试人员能够用。让功能测试和自动化测试能有效执行，这是值得我们不断的优化；
测试环境及测试数据自动支持，为运维赋能。运维的数据库你有权限连吗？能做脱敏吗？流量会不会做？就算运维数据脱敏给你了，很多数据也是没有用的，你要优化。你要的测试环境，运维知道吗，运维告诉你我怎么给你这个环境，你怎么编排这个环境，甚至你如何把你的测试有历史版本追溯？现在出了一个Bug，你退到这个版本上，运维可以做吗？很难，但测试人员可以做到，因为我们做测试发布的时候，你告诉我一个环境版本（该版本下记录所有服务器的应用版本），我就可以实现版本的统一了；为研发赋能，基于TDD的自动化快速校验质量。
当我们了解反馈很重要的，需要快速反馈。我们怎么做这件事情，首先测试不是替别人擦屁股的，而是提供支撑的，很重要的一件事就是我们需要隔离TestOps体系。
两方面，给出需求，我们生成对需求需要支撑的规范、评估、方案、脚本，就是现在走的测试设计这套东西。
第二，从设计级别完成执行部分，今天提一个需求，今天下午出一个版本，只要你把代码提交了，我们会自动跑整个执行过程，这样就效率比较高（时间关系这里我不会展开介绍），大家要知道，我用最轻的版本反馈别人需要的价值，这是一个优化过程，今天我能够花5分钟反馈几个核心功能，明天我争取多做一两个，而不是说今天把所有问题验了。如果我要两天时间，对不起，这样的代价太大了，用户觉得时间长不做了那才是真正的问题。我们要在质量、成本和效率中间找到平衡点，这就是所谓眼界问题。
现在回答另外一个问题，既然手工测试成本那么低，为什么还要做自动化呢，是因为我们愿意花三倍的代价，在最后上线那个阶段换取反馈的时间周期缩短三倍以上。我做一个测试两小时，我花更长时间先自动化测试，但是上线的时候只要花15分钟即可跑完测试，从而证明这个版本可以上线，我是为了省这个时间一小时四十五分钟，至于自动化做到什么级别，取决于大家所能投入的成本，用成本省时间。
讲个例子，盒马鲜生有一次出过一次生产事故，把测试数据一百块钱减九十九券发到了线上，买一百块钱东西减九十九瞬间大家都去薅羊毛了，我作为一个服务器能取消订单吗，不行，我得做一个补丁。当我把补丁做完了等待上线的时候，能够等测试人员慢慢测试吗，每多等1分钟可能损失就是几百万！所以我愿意花二十倍的代价确保一件事情，谁能快速告诉我这个补丁上去是对的，不会带来更大的损失。其实谁都不知道你打下回车出去以后还会出什么问题，也就是说持续优化就是我们要做的事情。
很多东西很华丽，但是它没有特别的价值，第一测试开发不能解决真正的问题，只能解决工具的问题，光有微波炉不够，我们还要会做菜，还要切菜，开发、运维、测试都得学，都得会。第二个事情，不要上来一下子就做大饼，先做小的，用最小的投入换取最大的价值逐步优化。
这是我今天要讲的内容，谢谢大家。
本文来自：2018中国首届云测试峰会，举办方：Testin 云测
Testin云测，让应用更有价值：www.testin.cn
转载自原文链接, 如需删除请联系管理员。
原文链接：Vip Test 联合创始人陈霁谈 Testops 最优质量反馈，转载请注明来源！