ITPub博客

首页 > 自动化运维 > 大规模网络运维 > 避免大量实现类bug的可行性办法:研发质量保证前置

避免大量实现类bug的可行性办法:研发质量保证前置

原创 大规模网络运维 作者:博为峰网校 时间:2019-04-25 18:43:17 0 删除 编辑

摘要:在实际项目中,抛开产品需求的质量不说,但就研发质量保证而言,测试人员在测试阶段发现大量的实现类bug,每天拉着开发人员修bug;要么在临近上线的时候,发现了一个重大问题,导致修复验证时间不够,但又只能“硬着头皮”上线。解决这些问题的方法或许多种多样,但这里来聊聊如何使用研发质量保证前置来尽可能避开这些问题。


关键词:研发质量,质量保证前置,尽早暴露问题,上线风险

  背景

  在实际项目中,抛开产品需求的质量不说,但在研发质量保证上面,测试人员往往需要时不时的面对不少头痛的情况:

  开发团队来了一个新人,本来需求量不大,但测试人员在测试时发现连主流程都跑不通,无法走下去;

  这次有一个从零起步的大项目,涉及多个模块的交互,但QA在测试时发现,实现与需求不一致,不得不重新拉产品同学、开发同学重新对需求;

  需要要重构一个核心需求,结果由于排期紧张,导致提测后不仅改坏了很多老功能,新功能也各种不通;

  改动了一个各种交互场景十分复杂的业务,由于开发耗时,测试周期本来就被压缩了,外加上大部分场景模拟、测试很耗时,临到上线勉勉强强测完,虽然不是很有信心,但由于项目紧急只能硬着头皮上线了;

  要改一个与第三方业务交互十分复杂的业务,由于需要第三方配合才能100%覆盖场景,但由于环境问题、第三方人员时间问题导致测试被block住很久;

  无论这些问题你是都遇到过,还是遇到过其中的几个,这些问题可能都给上线质量带来了或多或少的影响,甚至直接带来了线上故障。这些问题都有一个共同的特征:大部分问题的暴露都集中到了测试阶段。这里抛开需求方面问题,就自己的项目经验,聊聊与实现相关的研发质量保证前置方面的心得与体会。

  什么是研发质量保证前置

  质量保证想必大家都不陌生了,就是通过各种手段保证产品保质保量上线,说白了就是线上尽量少出故障,最好不出故障。研发质量保证是指代码实现层面的质量了,研发质量对应的bug是实现类bug,换句话说是实现与需求不符合导致的bug了。而研发质量保证前置是指将实现类bug的暴露时间点提前。

  实现类bug的暴露阶段通常为:技术设计、技术评审、代码实现、提测时的冒烟测试、测试阶段、线上。研发质量保证前置就是让实现类bug的暴露更加提前,最好在技术设计阶段就发现。

研发质量保证前置的几种手段

  前面说过实现类bug暴露有不同的阶段,但就其中的技术设计而言,目前还是开发人员为绝对主导的阶段,而且极其依赖开发人员的经验,就目前接触的众多实际项目而言,测试人员直接参与技术设计的阶段的机会还比较少,因而技术设计质量这里暂时不做过多讨论了。下面就其余的几个阶段聊聊自己的一些经验,欢迎大家补充。

 一、在技术评审中确认各种场景的实现

  这里的技术评审推荐开发人员主导,测试人员参加的评审会。站在测试人员的角度,虽然评审会的具体形式不限,但应该达到如下的目的:

  业务需求中的各种场景都覆盖了

  涉及的原有业务都覆盖了

  各种异常场景处理符合需求或产品公共处理

  当然了,技术评审本身需要测试人员对产品业务、技术实现都非常熟悉,否则即使参与评审,恐怕效果也微乎其微了。这里为了让开发人员积极配合技术评审,可以考虑以下实践:

  将技术评审加入到项目流程中,具体形式可以依据项目大小而定;

  为了鼓励大家参与的积极性,不妨想些针对性的鼓励方法;

  每次评审,可以总结优化点、修改点 ,并做周知,让团队成员认可评审的价值所在;

 二、在代码实现阶段鼓励微服务测试

  众所周知,单元测试主要是为了从底层代码更快发现问题,尽量避免直接测试一个大的模块,这样排查问题会比较耗时。不记得有多少次,开发人员为了排查一个问题不得不打个断点,debug几次才能真正定位到问题代码了。出现此问题除了log日志不太全外,就是组装成模块的更小模块、方法缺少必要的关键单测了。当然了,实际项目大家对单元测试的态度往往是:尽管爱,但很难真正行动。就自己接触的众多项目而言,开发人员可能通过日志自检,或者就针对某一些方法简单跑下测试,把单元测试当成工作的团队还真没有接触过。于是乎,在实际项目中,通过和开发人员达成共识,在代码实现阶段,针对某个独立服务测试自检。

  适合微服务测试的业务大致有以下几个特点:

  业务除了API接口外,更底层实现是通过若干微服务搭建起来的

  涉及的微服务逻辑复杂,集成测试很难100%覆盖

  涉及的微服务频繁业务修改,并且需要独立上线

  微服务测试实现最好使用自动化。自己在实际的业务中,已经将微服务的测试完全通过自动化的手段实现,测试用例的维护由测试人员维护,在需要测试时,开发人员只需要点击一键执行,几分钟后就可以直接查看结果了。当然了,除了自动化手段外,如果某个服务不易100%自动化,可以结合自己的业务特点考虑有无辅助方案。

三、在提测时做好冒烟测试

  想必无论是开发人员,还是测试人员,在针对同一个测试用例执行结果时,往往都会有类似的体会:开发人员认真执行了没有发现问题,但测试人员随便试用两下却发现问题了。当然这排除掉开发人员,测试人员执行测试时的视角不同外,恐怕就是对同一个测试用例的执行步骤理解不一致了。

  这里有几个自己的一些实践经验:

  QA将核心主流程用例,指派给具体的开发人员执行;

  QA人员提供类似一键自测的自动化工具,供开发人员执行;

  复杂的需要创造场景的用例,QA辅助开发人员一起执行

  具体哪种方式,依据各自业务特点、需要而定,但要切记:不可把冒烟测试当做一种流程对待,执行是只是走个过场。

 四、在测试时快速发现问题

  快速发现问题是问题的暴露尽可能在测试周期前半段时间,避开诸如在测试周期快结束的1天突然发现了很多问题,导致bug 修复、回归验证的时间都不够了。因而,快速发现问题最核心的目标是尽可能早的暴露问题。

  要想让问题提前暴露,当然除了测试方案的完备性、人员经验等因素外,还可以从测试效率提升入手做些事情:

  自动化覆盖。这是效率提升常用的一种技术手段,只要自动化用例覆盖全面,外加上一键执行,问题几分钟可以暴露出来。

  提前准备好测试需要的“一切”。这里的“一切”,不仅仅包括测试数据、测试设备,还包括当存在与第三方交互时,需要对方做的一些事情,需要提前打好招呼,约定时间等等。力求达到不会因为前期准备不足而耽误测试执行。

  尽可能让更多人参与测试。看到这里,你可能会说: 测试除了测试人员外,还有其他人需要参与,更何况其他人也不想参与啊。对,确实有这方面的问题。但这里是说,质量保证涉及方方面面的事情,不是测试人员一个人的事情;而且测试人员也有经验、视角的局限性,很可能很明显的问题恰恰漏掉了。因而测试人员不妨引导团队其他人员 参与测试,比如让产品人员/开发人员参与主功能的验收,设计人员参与UI/UE校对等等。在自己实际的项目中,感受最深的一点是,团队人员的参与,可以以“小白用户”心态来看待产品,因而更能发现一些体验方面的问题,而这恰恰因为测试人员接触产品过多而容易漏掉的。

 写在最后

  研发质量的保证需要开发人员、测试人员齐心协力、共同努力,需要二者对质量保证都谨慎对待。有时在想,如果开发人员写的代码没有实现问题,那么测试人员的工作就可以大大减少了,少了问题排查、修复、验证的耗时,验证几遍就可以上线发布了。但这种显然在实际项目中不太可能实现了:越来越复杂的产品设计,产品迭代速度越来越快,产品需求量有增无减...

  认清了研发质量保证的各种阻碍之后,不妨摆正心态,认真做些事情,来把研发质量保证前置,以求尽可能减少产品发布风险吧!

欢迎加入  51软件测试大家庭,在这里你将获得【最新行业资讯】,【免费测试工具安装包】,【软件测试技术干货】,【面试求职技巧】... 51与你共同学习,一起成长!期待你的加入: QQ                     群:                    755431660


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31407649/viewspace-2642567/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2016-11-02

  • 博文量
    157
  • 访问量
    98229