为什么互联网公司不开除测试?

发表于:2016-7-13 08:02

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

 作者:IT奶爸    来源:51Testing软件测试网采编

  我是在朋友圈看到有朋友转发了这个,跑来尝试回答一下这个问题。
  看评论,有人说"你不怕只会测试不会写代码的测试杀了你吗?",还有人说"测试跟你有仇啊?"。总之有人开始不冷静了,开始义愤填膺卷街了。这样,是不好的……有问题就问,是好习惯嘛~
  好了,扯淡完毕。让我们抛开各种私心杂念,客观冷静的看看这个问题。题主这个问题问得很好,我很早以前也这样想过。但是后来发现,这个问法本身就是有问题的。
  我尝试从几个角度来分析,在正式分析开始前,我们先把范围划定在软件开发这个圈子里头,再来看题主的问题有哪些问题,并且对这些问题进行解释。
  这部分包括这几点误解:
  将开发阶段、测试阶段完全剥离。
  对测试的理解有些偏差,误认为测试只是在产品做出来之后,使用它,然后挑毛病,找bug。
  误认为测试只有功能性的校验。
  下头对这3点逐一解释:
  1.将开发阶段、测试阶段完全剥离。
  让我们来看看题主的问题:
  为什么互联网公司不开除测试,转而让大众来测,找到一个bug给100元?
  这个问题有个假设,就是开发阶段、测试阶段完全剥离开了。开发阶段单纯地就是开发人员敲代码,然后出来的东西交给测试人员去做测试。
  我不否认,现在依然存在这样的实践方式。但是,这不是一个好的方式。因为这种流程,把发现bug的时间点推迟了。而发现bug的时间点越靠后,修复它所要付出的代价就越大。
  这点应该很容易理解,比如你敲钉子,如果一口气敲完了才发现,敲歪了,那就得拔出来重新来,可是东西上已经有一个很深的洞了。所以,好的方式是敲一敲,检查一下,随时纠正方向,确保前进的大方向是正确的。
  软件更是如此,某个bug可能是在最底层的地方发生的,如果早期发现,定位也容易,修复起来被牵扯到的地方也少,付出的代价可以接受。因为bug的产生可能是多个原因,有可能是功能性的,也有可能是对业务理解的偏差导致开始就做错了。
  如果在产品做出来,发布给最终用户之后才发现。那个时候再排查到底哪里出了问题,就不是一时半会能做到的了,代价很大。
  所以比较好的实践方式,是由专业的业务人员把要做的东西切割成足够小的、彼此独立的、可单独交付的模块,开发、测试以及业务人员及时沟通、及时反馈,一个一个小模块完成,随时做随时测。把发现bug的时间点尽量往前推,这样就可以把修复它的代价降得尽可能小。
  当然,小模块都通过测试,并不意味着所有小模块拼装起来组成的系统一定正确,还需要进行层次高一点的集成测试。这就引出了第2点。
  2.测试就是找bug的?
  对测试的理解有些偏差,误认为测试只是在产品做出来之后,使用它,然后挑毛病,找bug。
  有这样的偏差并不奇怪,因为执这样想法的人太多了,甚至包括一些软件行业的从业人员。比如有这样的说法:
  开发就是敲代码的,测试就是找bug的
  如果是业外人士,我觉得有这样的误解没什么。毕竟,隔行如隔山,但业内人士这样理解的话,真的不知道该说什么好了。开发是不是只管敲代码,这里不谈。这里我们要谈的,是,测试不是单纯的找bug。
  现在我们承接第1点,来说说为什么测试不是在产品做出来之后,单纯的找bug。
  先科普的一个东西,就是测试金字塔。
  
这是MartinFowler的一篇博客中提到的《TestPyramid》。
  看不懂这个图没关系,我来慢慢解释。
  测试是分层的,它真的不是只有在产品做出来后才开始的,并且也不能那个时候才开始。原因在第1点里已经解释过了。一个工程级别的软件产品,它的测试大致覆盖了代码级别的单元测试,模块级别的API测试,还有端到端的集成测试。这并不全面,还有很多其他类型,这里我们只是大概分成这3种,便于解释、理解。
  底部那层,就是代码级别的单元测试。它是发现bug的最前沿阵地,能在这个层级抓住的bug,修复起来的代价,会小很多。而且这部分测试数量很大,验证的东西也不是最终用户所能理解的,通常都是自动化运行,有很多种框架可供选择。只有这层的测试全部通过,才会运行后面更上层的测试。
  中间那层,是service级别的测试,大概可以理解成模块间的API测试。到这一层,基本每个模块的功能都得到了保障,但是他们彼此的协作不一定正常,所以这层集中要测的就是不同模块间的协作、通信了。这部分测试数量第二多,也是自动化运行。通过之后,就可以开始最上面那层的测试了。
  顶部那层,这部分测试的数量最少,是UI级别的测试。测试的过程大致可以认为是,模拟使用产品的过程,最终用户也能理解了。比如从注册用户开始,到注册成功,登录成功,页面正确加载。这种校验最基本功能的测试,叫冒烟测试,确保产品可以正确运行,没有无法启动之类的重大缺陷。除此之外,还有部分不便自动化的测试,需要手动测试,同时还会校验一些边角的情形。
  即便上面说的测试全部通过,也不能确保产品万无一失没有bug,这是不可能的。只能说,通过了那么多层的测试,产品处在一个稳定状态了,最终用户的使用体验良好,绝大部分需求都可以满足。
21/212>
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • tanshunsky
    2016-7-28 10:32:06

    说是那样,但是实际工作中由于时间问题,都是把测试功能点列出来,然后验证的,当然需求评审也要做,我们有些测试人员都不写测试用例的。

  • 甜甜的豆
    2016-7-18 16:19:04

    说的很好

  • aux0
    2016-7-14 07:17:58

    支持分层测试

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号