北京软件测试培训
达内北京亚运村中心

010-62126400

北京软件测试培训 > 疑难解答 >软件开发人员适合做测试的工作吗

软件开发人员适合做测试的工作吗

  • 时间:2019-04-30 11:47
  • 发布:北京软件测试培训
  • 来源:疑难解答

现在包括 Google、Facebook 和 eBay 等一线互联网巨头公司都在逐渐推行“没有专职测试,测试工作由开发人员完成”的全新模式,原本专职的业务功能测试团队的规模逐渐缩小,有些甚至已经完全没有了,而原本的测试开发团队逐渐在向工程效能(Engineering Productivity)团队转型。这些互联网巨头之所以能够很好地落地这种全新的模式,是因为他们都较好地解决了这个模式的两个最大的难题:

开发人员如何能够胜任测试

工程效能团队如何赋能开发人员,帮助开发人员高效地完成高质量测试

本文会围绕这两个问题来展开讨论。首先让我们一起看一下开发人员自己做测试都会遇到哪些问题和阻碍。

开发人员自己做测试会遇到哪些问题人性角度引发的问题

首先从人性的角度来看,开发人员通常是属于“创造性思维”,自己开发的代码就像是亲儿子一样,怎么看都觉得实现很棒;而测试人员则属于“破坏性思维”,测试人员的职责就是要尽可能多的找到潜在的缺陷,而且专职的测试人员通常已经在以往的测试实践中积累了大量典型的容易出错的模式,所以测试人员比起开发人员,往往更能客观且全面做好充分的测试。

思维惯性的问题

刚才是从人性角度上来讲的,如果从技术层面来看,由开发人员自己测试,会存在严重的“思维惯性”,通常开发人员在设计和开发过程中没有考虑到的分支和处理逻辑,在自己做测试的时候同样不会考虑到。比如对于一个函数,其中有一个 String 类型的输入参数,如果开发人员在做功能实现的时候压根没有考虑到 String 存在 Null 值得可能性,那么代码的实现里面也不会对 Null 值做处理,连带结果就是测试的时候就更不会设计 Null 值得测试数据,这样的“一条龙”缺失就会给代码的质量留下了缺陷隐患。更糟糕的是,对于这种情况,即便启用了代码覆盖率指标去衡量测试完整程度,也不能有效暴露这类问题,因为处理 Null 值得代码压根没有写,又何来代码覆盖率一说呐。

被测试环境和测试执行环境的复杂性问题

有专职测试的时候,测试工作是专职测试人员完成的,专职测试人员通常会负责搭建被测试环境以及管理测试执行环境。被测试环境好理解,就是 System Under Test(SUT)。而测试执行环境是指用于执行测试用例的机器,比如对于 Web 的 GUI 测试,最简单的测试执行环境就是你本地机器上的浏览器。但是对于大型互联网企业,测试执行环境远远要比你想象的更复杂。通常都是一些大型的测试执行集群,甚至是内部的测试执行私有云,比如用 Selenium Grid 搭建的 GUI 测试执行环境,往往这样的集群都会有成百上千台机器,再比如用 Appium+Selenium Grid 搭建的移动设备测试集群,也往往会有上千台设备。现在没有了专职的测试人员,那就需要开发人员自己去管理、维护和搭建这些测试基础架构,这样做其实是得不偿失的,工作量本身并没有减少,只是换了一批人来做同样的事情,而且开发的精力往往更应该花在构建新的业务功能上,而不是用在维护测试基础设施。

测试数据准备的问题

测试数据准备是测试过程中必不可少的关键步骤,有专职测试的时候,是由测试人员来准备测试数据的,一方面测试人员往往比开发人员在全局层面上更了解被测系统,所以对于测试数据的设计与生成也会更高效,另一方面测试人员在以往的测试过程中已经积累了很多测试数据生成的方法和小工具。现在这些都需要开发人员自己来完成了,无疑进一步加大了开发人员的工作量,而且开发人员往往对跨模块,跨系统的测试数据准备缺乏系统性的理解,往往为了生成一条非自己业务领域的数据而花费大量的学习成本。举个例子,假设现在“买家模块”的开发人员需要测试“商品买入”的操作,那么就需要事先准备好“可以被卖的商品”,这就意味着“买家模块”的开发人员需要明确知道“卖家模块”和“商品模块”的细节,才能生成“可以被卖的商品”。这类问题在目前主流的微服务架构面前会更严重,原因是为了产生一条测试数据,可能会需要依次调用很多个服务。

测试执行与 CI/CD 集成问题

对于不同的业务开发团队,各个阶段采用的自动化测试框架可能都不同,比如有些会使用基于 Java 的 Selenium,也有些会使用基于 JavaScript 的 Nightwatch 等,有专职测试的时候,各种不同的测试框架与 CI/CD 的集成,都是由各个业务团队的测试人员和 CI/CD 的人员一起完成的,现在没有了专职测试,这部分工作就需要开发人员自己和 CI/CD 人员一起完成,这就要求开发人员不仅需要非常熟悉自动化测试框架的细节(很多时候为了更好地和 CI/CD 集成,会对开源测试框架或者是自研测试框架做二次开发,比如改进 retry 机制,增加覆盖率统计等等),还必须了解 CI/CD 的流水线设计以及脚本设计,然后再将需要支持的自动化测试框架的运行命令行和需要暴露的参数(测试用例 Git 路径、测试执行环境、测试报告路径等等)写进 CI/CD 的脚本。这些工作在很大程度上分散了开发的精力,对于提高开发自身效率是非常不利的。

失败测试用例归属问题

有专职测试的时候,开发人员往往只关注自己修改部分相关的测试用例,模块或者服务的全回归测试中如果有失败的测试用例,通常是由测试人员跟进去分析具体原因,并协调解决然后才能发布上线。但是现在开发人员负责所有测试,他就必须关注全局的测试。举个实际的例子来看,比如“用户登录”服务的开发工程师修复了一个缺陷,然后本地自测通过后递交了代码,然后很不幸,在 CI/CD 的流水线上全回归测试却发现有部分用例失败了,虽然这些失败的用例和这次的代码修改没有任何关系,但是为了保证自己的修改能够顺利上线(CI/CD 的流水线要求只有全回归测试 100% 通过才可以上线),他必须挨个去分析失败的测试用例然后自己去找到对应的人去协调解决,这显然是非常不合理和不敏捷的做法。

归根结底,这些问题的本质都会直接影响开发人员本质工作的进度和效率,那么我们应该如何解决或者在一定程度上缓解这些问题呢?这就是接下来要讨论的问题,工程效能团队如何赋能开发人员,帮助开发人员高效地完成高质量的测试。

本期软件测试培训班学习分享到这里就结束了,下期将为大家带来更多软件测试培训相关知识!

上一篇:如何用python执行接口测试
下一篇:测试开发工程师必须具备哪些技能

马上预约七天免费体验课

姓名:

电话:

如何度量测试开发的价值产出

测试开发工程师必须具备哪些技能

软件开发人员适合做测试的工作吗

如何用python执行接口测试

  • 关注微信公众号

    回复关键字:视频资料

    免费领取 达内课程视频学习资料

  • 视频学习QQ群

    添加QQ群:1143617948

    免费领取达内课程视频学习资料

Copyright © 2018 Tedu.cn All Rights Reserved 京ICP备08000853号-56 京公网安备 11010802029508号 达内时代科技集团有限公司 版权所有

选择城市和中心
江西省

贵州省

广西省

海南省