QA Review UT的那些事儿

发表于:2018-1-09 11:58

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:李春辉    来源:简书

  一个风和日丽的下午,眉清目秀的Dev小乒挺了一下腰,喊了BA,UX还有QA小乓一同SignOff,十几分钟后,场景验收完毕,BA和UX退位,只有QA小乓还定坐在那里,斩钉截铁地说了句:“看下UT吧……”,故事也就从这里开始了。
  “嗯?还要看UT?” Dev小乒一脸突然。
  “嗯,看下吧” QA小乓谈定的说。
  “好吧……”Dev小乒边回话边打开Git翻找,嘴里还好像在嘀咕着什么。
  “这部分测了保险单的消息提醒功能” Dev小乒随手打开一个测试文件。
  “那理财单的消息提醒测了没?” QA小乓追问道。
  “没测,不用测,实现都一样!” Dev小乒顺口答道。
  “只测保险单,那理财单的挂了怎么办,它们是不同的业务,难道,还得手动一遍遍测试?” QA小乓皱了皱眉看了一眼Dev小乒。
  “不用,相信我,我们是TDD,测试驱动开发,再加也驱动不出新代码,再说实现都一样,加了也是重复代码。”
  说完这段话后,Dev小乒身子往后一靠、椅子向后一滑,身体转向QA小乓,语重心长地说:“小乓呀!我觉得吧,你不用看UT,对你没啥用,再说都跟实现相关的,也很难给你讲清楚……”
  此处的QA小乓仿佛看到了无数只黑乌鸦从眼前飞过……
  这就是我们项目在尝试“QA Review UT”实践后出现的一个真实场景,从中可以看到这个新的实践所面临的挑战,那问题来了?对呀,为什么QA要Review UT呢?
  为什么要Review UT
  1、先从UT的重要性说起
  根据测试金字塔,UT处于测试金字塔的最底端。其特点是更贴近于代码,运行速度快,成本相对较低,对问题的反馈也更准确。所以通常情况下绝大部分的业务代码都会在UT层被覆盖,也就意味着有近70%或更高的业务逻辑会由UT来保护。
  
测试金字塔
  2、再从QA对UT不可见的弊端谈谈
  作为把控质量的QA,对于这类在测试策略中占比最大的单元测试(UT)却通常是不可见的。因为UT通常都是开发人员编写,与实现紧密相关,又纷繁复杂,所以QA通常都不知道在UT中到底测了哪些没测哪些。这样一来,只能通过手动一遍遍测试或编写更加昂贵的UI回归测试予以保障,这样不仅耗费了很多精力,而且可能还会与UT测试有很大的重复。
  但如果加入了UT Review,使UT对QA可见,可以让QA更好的了解产品的质量情况,制定更加有效的测试策略,就可以在增加整个团队对于产品质量信心的同时,使工作更加高效合理,测试策略更加的精简有效。
  由于QA对于业务的理解也比较深入,有时还能在Review中发现漏掉的测试场景,在更早期识别风险,避免更大问题的产生。
  由此可见,Review UT很必要,可是往往好事多磨,就像一开始的故事,QA小乓就遇到了很多困难。
  Review UT过程中的那些困难
  
Review UT中
  1、开发人员内心排斥QA Review UT
  回想一下一开始的场景,Dev小乒对QA小乓要Review UT表现得有些突然,包括Dev小乒最后语重心长的那句话。从Dev的角度,UT是与实现相关的,与技术架构,工具选型,甚至是底层设计相关,QA又不懂。另外,QA要Review他们写的UT,可能会让Dev觉得这是对他们的不信任。再者,Signoff加入Review UT后,时间变的更长,成本也会相应变高。所以,在刚开始推行Review UT的过程中,会出现双方合作不畅的情况。
  【解决方案】:在Review UT这件事上团队内必须先达成共识,通过沟通使团队明白QA Review UT不是因为对于Dev的不信任,也不是为了专挑刺儿;而是为了挖掘前文中为什么要Review UT章节中阐述的QA Review UT能给项目带来的好处。另外,作为QA也需要了解些代码方面的知识,比如:系统架构、DEV用的TDD等,便于更好的理解UT,最终通过双方的努力,不断的降低Review UT带来的成本,实现利益的最大化。
  2、测试结构乱,看不懂
  开始Review UT就发现,UT结构零散,经常需要在不同代码库,文件、及Commit中跳来跳去,全程Review下来经常会感觉一片混乱,也搞不清哪些测了哪些没测。甚至还会引起双方怨念四起、互相嫌弃,QA嫌弃Dev写的乱、又讲不明白,Dev嫌弃QA看不懂、还嘚吧嘚!
  【解决方案】:首先Review UT对QA提出了更高的要求,要对代码架构提前有个了解。而Dev在写UT时,也要尽可能写的结构清淅易读,命名准确。在每张卡Signoff时,开发人员可以先简短介绍清楚UT的结构(也可以简单画一画),再介绍哪部分Test Case放在了哪里,然后去对应的结构里看相应的测试 。这样整个过程才会更加的顺畅,也才能真正的起到预期的作用。
  3、根据现有实现,不需要再加
  开发人员有时会说:“根据现有实现不需要加,这个业务和另一个业务实现代码是一样的。再比如,这方法的实现是用数组,你提到的两种业务场景在这里就是数组里的1和2,处理上没区别”。
  【解决方案】:测试验证的应该是业务价值,而不是具体的实现方式。而在业务价值不变的前提下,实现代码却可能会发生变化,比如:代码可能被重构。所以测试也不该根据代码实现来设计CASE,更应该从业务价值来设计。当然实际情况中会有一些特殊情况,但总体原则不变,即我们应该更多的通过测试来保障我们交付价值而不是具体实现。
  收获
  经过一段时间的实践QA Review UT,我们发现在不同程度上,都有了很大的收获。
  1、及时发现了UT上的一些问题并改进
  Review UT以后,Signoff时发现了不少漏掉的测试场景,让一些Defect提前被识别出来,避免了更大的损失和风险。
  2、QA越来越熟悉Code&Test结构
  要想Review好UT,QA要大致了解系统的技术架构,而且每次Review UT前,开发人员还会给介绍或画一下测试结构,时间久了,对于代码和测试的结构就会越来越熟悉,从而让整个Review过程变得越来越有效率。
  3、QA和开发人员更近了
  在Review UT的过程中,QA和开发人员之间更多的交流,介绍测试结构时,会提到实现架构与实现等,渐渐QA对Dev的术语也懂的多了,也更了解了开发人员的测试思维,沟通合作起来更顺了,Review UT过程中遇到双方争异也更易解决了。
  4、DEV测试sense提高
  QA更多地从业务角度以及从测试专业角度思考问题、交流,在QA潜移默化地影响下,开发人员对于测试和质量的Sense也有了提升,UT的质量也有了明显的提升。
  5、团队对质量更有信心
  QA参与和开发人员一同严格把控了重要的UT环节,也清楚了哪些业务价值已经在UT中被覆盖,所以在设计更高层次的测试时就会更加有针对性,减少了重复测试带来的浪费,同时团队对产品质量也更有信心了。
  6、QA做更多有价值的事儿
  被UT覆盖的业务价值对于QA来讲不需要做完整的细枝末节的手动回归测试了,只需要做一些针对性的探索性测试,这样QA就有了更多的时间做更有价值的事情。比如:更早参与需求分析、Review Story,写Regression测试,实施內建安全&性能, 以及生产环境下QA的事儿等等!

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号