UDN-企业互联网技术人气社区

板块导航

浏览  : 1715
回复  : 0

[企业空间] 质量管理部的独白

[复制链接]
瞌睡虫的头像 楼主
发表于 2017-1-17 17:45:18 | 显示全部楼层 |阅读模式
  为什么需要质量管理部?这个部门的价值何在?从需求产出到开发写出代码都会有bug,质量管理部就是为了从需求提出到上线及后期服务,更快更早的发现产品中的bug,从而降低成本,以及需要专业的测试技能才能发现的问题或非常难以发现的问题,最终保证产品能够满足客户的价值。

  怎么在很快的迭代下保证产品质量呢?

  在移动互联网越来越快的迭代项目中,很多测试人员和测试团队都开始觉得力不从心,很多团队和公司都开始讨论怎么保证质量。事实是单纯的从测试和测试团队出发都无法保证产品的质量了。

  测试人员是有限的,测试环境也和线上环境不同。我们的测试机也不可能有线上用户那么多。你让我说数据要一样,我肯定说不一样,但如果我说不一样,那么老板肯定会想,我投入那么多人力,资金等于没有用啊,所以就会面临两难的境地。

NUKGVT_MYL)@276B@}UB%OP.png



  • 从以下两点切入:


  一个是人,这里的人还是比较关注在测试身上。

  另一个就是流程,流程中的每个细节都是质量保证的关键点,都是质量的基础。

ZC_KSL`Z21B)N0QRU`3VD.png



  其实想表述的就是如果走出测试来看质量的话,几乎所有事情都不是单纯的测试个体或团队能够完成的。需要走出那个“你提需求,别人实现”的时代,取而代之的是“你提需求,你牵头来实现”。需要去利用合适的资源去做合适的事情,而不是什么都自己来做。  

  举个例子,在平时测试的过程中发现了一个问题,需要有能力去判断这个问题是前端还是后端的,如果是后端的,那么通过各个系统日志和调用关系需要去明白问题出在什么系统上。如果是前端,那么需要去发现是框架层的,还是组建层的,还是业务方等等。也就是说其实无论你是功能测试、自动化测试或者架构,定位问题都是通用的要求。

  之所以要求测试能够有定位问题的能力,本质就是为了提升整个项目流程的效率。因为当发现一个问题的时候,以前的方式是测试直接报一个bug,这个bug会描述清楚问题的上下文和现象。但其实开发还是需要去排查问题,然后再fix。也就是说排查问题这个过程是免不了的,而且往往测试并不知道这个问题是在哪个开发的头上,容易出现A踢皮球到B,B再踢给A的情况。所以在现在的测试行业中,大部分的公司索性就要求测试需要有定位问题的能力,这也是一项基础的能力。

{MSMBGZ2VO6VX{%VDCRJ]IU.png



  这点特别的强调下,因为现在整个行业都在追求技术。行业却慢慢的弱化了测试原本需要有的技术能力。比如测试策略的制定,测试的方式,测试用例设计的方式等等。再过10年,我们也许都变成一群技术很牛却不懂测试的人。很多公司的测试总监不知道ab test 和灰度发布有什么区别,竟然认为两个是一个东西,很担心测试行业的发展。

  • 质量体系的建设


  互联网发展到现在,测试大部分的技术,无论是自动化,还是动态AOP的hook等,其实这些技术都是存在于“测试中”或者“测试执行”过程。但流程中还有两个很大的空缺。一个就是测试前,叫做测试准备,一个就是测试后,也就是测试结束后。这两个阶段可以说是非常空白的。

  测试准备这里其实包括比如说“测试用例的自动生成”,“数据的自动化生成”。而在测试结束,也就是我们的灰度以及发布之后的话,那就是之后说的质量的事了。

  首先是自动化,这个可以说是测试比较注重的一块。

(FU[UA{NJ40QO5N39PSABS8.png



  UI自动化其实在几年前,整个行业都还是在搭建自己的框架或者自动化团队,包括积累很多的自动化用例。但经过这几年发现基本上是不可行的。最大的原因就是UI自动化的ROI太低了。在现在这样一个快速发展的移动互联网下根本是没有办法可持续发展的。

  那么现在的大部分公司为了更好的支持hybrid

  (混合式应用)的模式,选用了开源的Appium。当然这些公司并不会直接使用appium,而是拉出appium比较稳定的一个branch,然后自己来开发,并将appium根据自己的页面封装成适合自己的框架。而UI自动化不在会是每次迭代都会去增加case了。也就是说会将那些很核心,不怎么变化的流程编写成我们的冒烟case和回归case。而在冒烟的时候,根据提交的代码属于哪个bundle,然后会去调用对应的case,并不会每次打包都跑全量。同时regression的话也是一样的,会有一套稳定的用例。这是基本上现在大部分公司选择的方案。

  在App的专项测试中,自动化也会扮演非常重要的角色。自动化在专项中的角色其实主要是为了获取长时间的app性能数据。比如说要获取一个连续支付3000次,或者某个功能连续使用6小时下的耗电量。那么这种情况就需要那种能够脱离usb的自动化框架的支持。

  所以总结下,UI自动化其实就是为了保证我们的核心功能是正确的,不会出现很大的regression的问题。不可能依赖UI自动化去提升质量。最多也就是保证核心的质量。

}QOQ9F1)5YG}5)RQDNWY9UF.png



  • 从思想本质上改变对质量的认识


  所以回到这个问题上来,怎么很快的迭代下保证产品质量呢?

  从本质上需要认清,无论是谁,无论什么架构都不可能在移动互联网下去保证产品的质量,这是绝对不可能的。只能保证产品核心和很重要的模块的质量,但不可能说保证产品的完整的质量。

  从思想上需要转变的是,以前认为在项目流程中通过测试、bug bash以及各种方式在上线前保证产品的质量,但现在需要转变,利用线上、用户,一起去保证产品质量。不要担心线上出问题。所以需要一套质量体系,当出现问题的时候,第一时间能够预警,能够hotfix,能够动态的更新,能够及时应对。这就是在移动互联网下应该有的质量思维。这里所有都是质量体系的一部分。

DI{)0VJ}IT}9RR@02[@LSHL.png



您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部