Fork me on GitHub
Google

自动化测试介入的时机

自动化测试介入的时机

今天,在我建的一个测试群里看到有位同学抛出了这个一个问题

自动化测试是在开发阶段就介入呢,还是等手工测试结束之后,系统功能稳定后,介入?

当时没时间去回答,就找了以前在淘测试上看到的一篇文章发给他了。回到家之后,我在跑步机上想了下这个问题,现在我在做的自动化测试,会怎么去判断准入条件呢?

首先,搞清楚自动化的目的是什么?

  • 提供工作效率,运行自动化测试用例可以同时做其他的工作,而且测试效率有了提升,大量case可同时运行
  • 提供运行的准确性和稳定性,避免外界因素的影响
  • 避免重复劳动,防止大量的手工回归测试,节省成本
  • 对测试人员而言,也是提高技能的一种手段

上面的4点,是我对自动化测试目的一个总结,我对自动化是否有意义的判断也是基于上面的认知。当然你也可能会有其它一些想法。

对于上面提到的那个问题, 我觉得还是不好解释,毕竟场景不同,其对应的方案也会不一样。从我现在所在的团队来看,这样的问题,我会从整个项目的周期来判断,下面是目前我们的一个做法,当然并不是很完整,我简单说一下过程。

软件开发流程,大家比较清楚的可能是瀑布流程,敏捷开发这些。不管采用什么样的流程,测试的工作如何接入配合到开发流程中才是最重要的,最关键的。而不是去考虑什么时间去做自动化测试,自动化测试应该是在合适的时间就得开展。

现在,我们不会去区分角色,功能测试人员和自动化测试人员应该就是一个人,测试人员应该对应于一个产品,而不是一种技能。

项目前期,kickoff结束,测试同学就应该参与到项目中,对项目的需求进行一定的把握。下面的流程是我们测试的一些关键时间点:

  1. 需求评审 这个阶段可以了解项目的背景,并开始和开发,PD沟通一些功能上的设计问题。为后面设计case提供一些思路。

  2. 开发设计&&测试用例设计 有些工作并不一定要等到开发全部完成再进行,紧密沟通合作,保证项目向前推进。在开发设计阶段就可以参与进来,并在开发设计完成后,对应完成测试用例的设计,明确哪些case可以实现自动化,并选择好测试框架和工具。

  3. 分层测试&&可自动化的部分先行 在未得到稳定的测试版本之前,可以准备测试数据,一键部署的脚本,已经对应测试框架,测试代码的编写。不一定要全部完成,但至少准备工作都得做好。

  4. 冒烟&&测试执行 提测之前,对部分重点功能进行常规冒烟测试。达到预期后,进行功能测试。这个测试工程中,即可以对一些自动化测试的case进行编码调试,后面这些功能可以在回归执行中有非常大的作用。

  5. bugfix版本,自动化回归 对应一些bugfix的版本,除了验证bug之外,还得将之前的功能进行回归,这个阶段,自动化的case将节省不少的精力。

  6. 稳定版本,自动化回归,预发环境自动化验证 在发布上线之前,会准备一个稳定的环境,做一次全量的测试执行,当然自动化case也是这个时候的重点。

  7. 发布上线,冒烟 待上述测试执行都结束了,意味着项目也就安心上线发布了。这个时候需要简单的冒烟测试即可。

经历这么一个项目的过程,自动化的case肯定是需要占有一定的比例。当然,大家肯定还是存在下面的一个疑问?

开发还未提交测试,或者功能也未稳到,如何进行自动化的测试?

这个问题,我从下面的2点进行解释,其实前面我也有提到这些。

  • 接口测试:待测的接口肯定需要事先定义好,这里更多的应该是测试数据的准备,已经测试类的编写,case的逻辑可以体现出来,当然调试case需要放到功能开发出来,但是我们的准备工作要都搞定。
  • UI自动化:大家都会说页面还没出来,怎么写?道理是一样的,设计出来的场景是事先通过需求文档,交互PRD这些进行确认过的,同样,需要的测试数据可以先准备出来,代码的逻辑也可以写出一部分,这个时候缺的应该就是页面元素。

如果设计的合理,我们的case应该做到测试数据和测试代码进行分离,这样你需要的部分可以配置为参数的形式,后期传入。

现在,在阿里不管是接口测试还是UI自动化,基本上都是在与开发同步进行,我们需要将自动化的作用最大化,提高测试的效率。

所以,我最终的建议是尽量提前来做,将自动化的价值最大化。

comments powered by Disqus

top