首页 » 技术分享 » Vip Test 联合创始人陈霁谈 Testops 最优质量反馈

Vip Test 联合创始人陈霁谈 Testops 最优质量反馈

 

陈霁:很高兴和大家聊这个话题,开始正式话题之前我想问大家一个问题,大家觉得我像谁?

是不是很像某个知名的公子,每次都有人拿这个说我,搞的我也不好意思。那么我为什么会问这个问题,是因为我想看看是不是真的很像,是朋友忽悠我么?现实中大家都非常需要反馈,特别是在自然群体中获取认可,我美么?我做的对么。所以我想说的是,在我们现在做的所有的一切事情中,大家都在谈我该怎么做,但是有没有想过一件事情,我做的事情,未必是别人想要的事情!自我YY是不太合适的。今天借助NCTS大会跟大家分享一下在TestOps上面如何做一个优秀的测试价值反馈。

Vip Test 联合创始人陈霁谈 Testops 最优质量反馈

 

话题包括四件事情(DevOps中的反馈需求、反馈局限、打破反馈瓶颈、最优质量反馈)

首先为什么会做敏捷,DevOps中的反馈需求,不但要做的快,还要做的对。

我们做测试,会想一件事情,要学自动化测试。为什么,因为它快、懒(其实是工资高),做适配有那么多的手机,拿自动化点一下就行了,当然还要学习写脚本,学工具。在这个时候面临一个问题,就是我们非常需要反馈,我到底怎么算学会自动化了。我看到大家笑了,作为测试人员,我们代表用户反馈价值,我们也是客户,那么我们怎么知道我们代表了客户反馈了正确的价值。

第一,用户需要反馈,确定自己的商业计划能够完美实施,实现了是不是客户想要的,这是测试要代表的,不要过了一个礼拜以后客户看到产品说对不起这不是我想要的(然后需求、开发、测试重来一遍)。

例如:有一个人做过这么一件事情,他在咖啡厅遇到一位美女怦然心动,于是走过去对她说“我想每天早晨醒来第一眼见到的就是你”。这种表达方式是相对委婉的,直接的这里就不说了。其实这就是一种获取反馈的方式,如果美女答复你是臭流氓,她对你反馈了你知道答案了,如果不答复这是冷暴力,你还是不知道到底结论是什么(是她没听懂,还是你们两个不合适,还是她只是不好意思在等待你进一步)。第一价值是什么,就是用户价值,用户价值的实现是最优先考虑的。所以这里我要提一件事情,很多测试为了证明自己技术很牛做了一个什么平台,但是并没想过,这个东西做的是不是有投资回报比,有无有效的反馈价值。

Vip Test 联合创始人陈霁谈 Testops 最优质量反馈

 

怎么反馈价值?需求端做了吗?流水线做了吗?我们从自动化金字塔做到菱形,从UI做到接口做到单元,再往前一些,甚至Kanban、UserStory的反馈,其实大家做的都很辛苦,而且并不见得效果很好。在我看来,要改变很多事情,主要在思想和思路上的改变。

第二件事情,领导需要什么反馈?

确定能否按时按质完成任务获得回款,领导想看到每天大家都在写代码,以前写代码,我的Git/SVN上有记录就行了,目的就是考核大家工作量,能够看到大家在做事就行了。但是其实会发现,这种反馈没多大实际意义,因为反正只要代码跑起来了,开发就能说我工作完成了。开发就写代码就行了,时间到了就说软件做出来了,至于好不好用,还有运维时间和修复时间。于是你会发现,这个软件到处都是Bug,随着时间的推移越来越多,也就是本质上你看代码是没有真正实现的。为什么?要赶工期,所以领导需要的不仅是写代码快,而且”还要”真正的实现了,这个反馈谁来给?大家也许有孩子,会发现每天老师在群里会发一下,今天孩子在学校学了什么,今天回家家长要考一下孩子掌握了没,这就是老师给家长的反馈检查方法。

真正有价值的反馈是什么呢?是员工的反馈或者开发的反馈?大家想一想,整个软件成功的要素是什么?给最终用户快速反馈:用户说的需求我懂了,并且做出了东西。今天早上客户给需求,今天下午出版本,晚上给客户看,这就是敏捷快速交付。

以前怎么解决的?会做UI原型,但是这个东西照着UI做出来,按照这么用是对的,一旦上了环境或者某些特殊机制上就错了,因为我们需求上的分解是不够的,最终导致用户验收的反馈误差。

当我们需要反馈的时候,DevOps谈了一个三步法,第一,从左到右,快速流动,工作可视化,小批量,打造持续交付流水线;可靠的自动化测试,低风险自动化发布;第二持续反馈;第三精益(我们今天不谈)。

接着问大家一个问题,“我们在需求阶段,实现阶段,发布阶段,我们做反馈怎么做的?”,我怎么告诉别人我做的东西对不对?从设计阶段到实现阶段,我们做了什么东西给别人参考的信息。在软件研发中,测试是立法的,而别人是实现的,怎么告诉别人这么做一定是对的?Ops能解决Dev需要的反馈么,当我们发布的时候,我们怎么解决质量问题。

我们首先看一下需求阶段,大家有多少人在用看板?将所有价值可视化,我们不知道别人在干什么,还有多少事情要干。开发团队为什么没有给版本,说好下班给的,等到明天还没有给,一问还没下班。我们在做需求阶段,第一是用户需求前置的验证,甚至邀请用户参与这件事;第二就是通过看板提醒,在公司墙上有一个看板,知道有多少需求在这里,价值是在什么阶段,瞬间就能知道。如果大家没有使用kanban可视化的时候,你会发现每个人都很忙,但不知道忙什么,导致一个问题,我们并不知道用户所要的价值是否最先被实现了。

Vip Test 联合创始人陈霁谈 Testops 最优质量反馈

 

接着我们看一下实现阶段,高级一点的静态走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 最优质量反馈,转载请注明来源!

0