在测试的路上,学习无止境。。。 相信自己,快乐每一天。。。 紧急通知: 支付宝急招资深软件测试工程师,详见 http://job.alipay.com/recruit/offerDetail.htm?offerId=21683,同时招聘资深测试开发工程师。有意者投递简历至:xin.maojx@alipay.com

自动化测试&手工测试&测试分析

上一篇 / 下一篇  2009-08-08 16:24:14 / 个人分类:测试技术

最近在内部测试网站上讨论自动化测试的重要性,L君的理由是在集成环境上,实行手工测试,有些较冷的功能没有被执行(注:也不可能全部被执行,毕竟集成测试的时间有限,只有一两天),有可能会产生线上缺陷,如果实现自动化测试,就不会有此类问题了,发现一个解决一个以此降低线上缺陷。

关于自动化我有个疑惑:所有的业务都有必要做自动化么?自动化能将所有的业务都能实现么?成本/产出、维护、效率如何?

如果某些业务长时间没有大的改变,是可以用自动化来实现的,而且一次实现,多次复用。相反,如果某些业务短时间内改动很大,这个对自动化相对来说,前期自动化投入成本、维护成本更大,可以考虑采用人工方式。成本/产出、效率要在一段时间后才能看到,且属于测试管理方面,暂不讨论。

我认为不管是自动化测试,还是手工测试,所做的事情就是一件:按照测试用例或脚本,进行测试执行,报告测试结果。我觉的自动化测试、手工测试只是一种测试执行方式而已。

相比之下,前期的测试分析显的尤为重要。为什么呢?就集成测试而言,它的特点是:时间短、环境完整且相对稳定、代码最新。我们测试人员要在集成环境有限的时间内将以前在开发环境的测试功能点全部测试一遍,如果整体工作量相对较小,还可以承受;如果是一个大的项目发布,在不延长集成测试时间的前提下,如何选择测试用例,做到用例覆盖面较全,能够在有效的时间内产出最大化,这不是一件简单的事情,主要靠测试分析人员的分析,分析结束后,选择什么方式来执行,则是另外一个问题,包括上面提到的成本/产出、效率等。

现在的困难是,如果我们目前做不到将所有的业务自动化,作为测试的我们需要怎么做才能将风险降到最低呢?

我认为经过了开发人员经过自测、code review提交测试后,我们可以能过以下几个步骤尽量避免:

1.测试工程师了解需求,设计相关功能用例和回归用例(回归用例不仅在集成环境上做,建议还在开发环境上做),这一步相当于黑盒测试用例设计;

2.测试工程师了解需求的代码,并对原来设计的用例进行查缺补漏,这一步相当于灰盒测试用例设计;

3. 测试分析人员review用例(review对测试分析人员要求很高,从需求、系统设计、测试用例和影响点、扩展性等各个角度来考虑),这一步相当于测试分析人员再次保证需求用例的完整性;

4.集成环境上由测试分析人员结合本周的发布情况,分析后给出本组测试回归建议,从整个测试组角度来看,是保证回归业务的完整性。

上面讲的需求的测试过程,也就是说,可以能过通过业务分析、代码走读相结合,测试负责人和测试工程师相结合的方法能够提高此类缺陷的发现。

 


TAG:

测试是艺术 引用 删除 elliongong   /   2009-08-25 11:14:15
就我们目前的发布时间要求、回归工作量以及业务发展速度,纯手工与纯自动化都做不到。
纯手工---时间不允许;
纯自动化--投入产出不划算,一直在变的;

所以我赞同上面的一些观点,在功能环境里甚至开发环境里去做局部回归,通过代码阅读完善测试用例......这都是一些很好的想法。多角度去保障我们全站回归的品质和效率。
 

评分:0

我来说两句

Open Toolbar