想清楚这4个问题,也就明白测试策略了

发表于:2020-12-07 09:41

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

 作者:钟表匠拍拍手    来源:简书

分享:
  在软件质量行业工作了很多年,自己主导或者参与了不少测试自动化项目,也见过很多同行做测试自动化的工作,满眼看到满耳听到的,大家都是在谈这个技术那个技术,这个框架那个框架,听到大家讨论测试自动化策略的,很少,有的同行写了很多代码,自动化了很多用例,搭建了颇复杂的自动化平台,可是要解决啥问题?怎么去解决?现在解决了吗?说不清楚,自己觉得很好,别人看了摇头。
  然而自动化的目标是啥,要解决啥问题,从什么角度去解决,用什么方法去解决,现有的资源能不能解决,这些都是基础性的问题,回答了这些问题,也就想清楚了自己的测试自动化策略是什么。
  测试自动化的目标
  1.用自动化进行回归测试:这算是最常见的自动化测试目标了。在互联网行业,技术负责人如果要求测试团队开展自动化工作,大多数都是出于这个目的。我们国内的互联网公司,多是缺少足够的质量成本意识的,老板们不满意软件质量太差,线上问题太多,也不满意投资足够的软件测试或者质量工程师,看到线上bug来气,听到测试负责人的招聘请求也光火,又要马儿跑又要马儿不吃草,听人说有这么一种技术,用机器自己完成软件测试,哎唷,不错哦,测试负责人你过来,给你个任务,搞测试自动化。。。
  2.用测试自动化来简化手工测试,这也是一种自动化目标。有些软件测试的工作,流程简单,执行枯燥,同时应该要覆盖的场景或者数据类似而大量,测试执行的重复性又很高,手工测试就很乏味无趣,测试者可谓不堪其苦,用自动化来执行,不失为一个好的想法。也有一些测试工作,手工操作很困难,而代码执行却很容易,自动化也是解决这种困境的一个有效工具。
  3.用自动化来监控产品质量:现在的产品质量是个广义的范畴,除了开发者开发的代码之外还有其他很多影响运行质量的因素,比如系统库,第三方服务,软件/硬件/网络环境等等,每个因素都可能存在变化进而影响系统质量。自动化可以进行持续监控,帮助及时发现相关的问题。
  4.用自动化来提高测试覆盖面或者测试深度,进而提高测试质量:自动化测试擅长进行重复性的工作,手工测试一般集中在测试功能,但是不同测试数据的测试覆盖有限,使用自动化,可以容易的针对大量的测试数据进行功能验证,提高交付的质量信心。
  所处的研发环境
  想清楚了测试自动化的目标,还要想想测试自动化所处的研发环境。熟话说,看人说话,看菜下饭,到了哪个山头唱哪个山头的歌,研发环境的不同,也可以影响甚至决定你的测试自动化目标是否可行。
  在稳定的研发环境中,产品研发周期长,产品规划合理,需求演进稳定,上述四种策略都是可以实现的。然而更多的情况下,测试团队很难有幸运在这样的研发环境中工作,更常见的是情况是研发速度快,需求混乱或者不稳定,系统功能复杂,以及随之而来的软件提测质量差。
  在一个成熟稳定的研发环境中,上述的四个测试自动化目标,都是有机会达成的,但是如果你像大多数同行一样工作在一个快速而混乱的研发环境中,试图用自动化来进行回归测试还是困难的,自动化目标更多可以考虑后面三种策略。
  测试自动化的切入点
  多数研发模式,瀑布也好敏捷也好,一个产品的研发,大多要经历一个信息转换的流程,从需求分析,到架构设计,系统设计,代码开发,最后到测试验证交付,质量风险和问题,往往在一个研发过程的不同阶段引入,而这些引入的问题,其发现和修复成本,会随着时间的推移而放大,越早介入自动化,实现成本越低,发现问题越容易,但是发现的质量风险可能也相对局限,这个话题比较大,以后有机会再细聊。? ?
  很多测试自动化,上马就要搞自动化系统测试,基于GUI操作,完全替代手工操作,有的甚至要跨平台,甚至跨多个产品或者系统做全流程测试,想法是美好的,然而失败的往往居多,成功的罕见,啥原因呢?系统级别,特别是GUI Based测试自动化,稳定性,可维护性,可靠性,执行效率都面临很大的挑战,这种挑战不仅来自于测试自动化设计和实现本身的质量,更来自于被测系统的设计甚至是业务逻辑的频繁变更,在产品快速迭代,产品规划混乱,技术债务重的研发环境中,自动化系统测试,成本高,收益低,挑战大。
  更合理的测试自动化实施策略,是分析质量风险的分布,结合系统变更的定位来进行设计,一般而言,质量风险在哪里,就在最靠近这些风险的地方去检测它,精准直接不饶弯子,脸上长没长痘痘,手一摸镜子一照就知道了,用不着去验个血号个脉。常见的互联网产品来说,常常将被测功能拆分成三个部分:内容,业务逻辑,展示与交互,结合每次提测的变更点分析,从不同的部分去覆盖质量风险,内容可以从数据质量进行检测,业务逻辑可以从后端进行API测试,而GUI based的自动化可以对前端进行展示和交互的验证。这样一来,既避免了大量使用低效而不稳定的测试自动化手段对系统进行验证,也可以在成本可控的基础上有效的覆盖足够的质量风险。当然,其他类型的软件产品功能,设计,实现或者质量需求不同,但是因地制宜,对症下药的道理是一样的。
  自研,还是选择商用工具平台,以及测试团队的研发能力
  在这个问题上,测试团队常常可能走两个极端,一个是过度迷信商用平台,特别是那些吹嘘不需要代码开发能力就能完成自动化的测试工具,另一个极端是完全自研,从基础框架,到日志系统,测试调度,测试报告系统,多数自己开发,如果测试团队有充分的时间和经验丰富的工程师,能自己全部搞定当然也很牛,但实际上测试自动化生态圈中已经有了很多可以定制和使用的工具,完全没必要重复造轮子。
  商用测试平台,往往用很酷炫的功能来包装自己,然而完全不依赖编程能力就能实现高效自动化的工具,我真的还没有遇到过,决定自动化成败的不是工具,而是人。但是相比较自己从头开发,很多成熟的商用工具确实提供了更加易用的接口,更加丰富的辅助功能,更加稳定的平台,如果提供了足够的培训,对团队自动化能力和经验的要求,相对也要低一些。
  选择自研,要结合团队研发能力以及能控制的研发周期来考虑,有多大能力办多大事情,开源社区有不少优秀的工具和模块可以集成和使用,在资源和能力有限的情况下,可以利用,集成和改造现有的系统先把自动化跑起来,毕竟自动化最后的成败,还是要看是不是在可控的ROI下达成了测试自动化的目标,短期内可能还是要看测试覆盖率,稳定性,可靠性等,当然中长期看开发和维护一个高效的,成熟的,易用的自动化测试平台也是必要的。
  写了那么多,总结一下,还是想强调测试自动化工作中目标和策略的重要性,很多测试自动化失败在设计上,实现上,或者实施上,但是更多的自动化,一开始就失败了,因为选择了一个不合理或者不现实的自动化策略,只有解决了策略的根本问题,结合团队能力,以及所处的研发环境的特点,选择对了自动化的方向,后续的工作才有成功的可能,测试自动化的价值才有机会体现。

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

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号