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

发表于:2009-8-12 12:03

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

 作者:dongfangronger    来源:51Testing博客

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

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

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

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

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

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

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

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

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

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

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

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

  (以上言论仅代表作者的个人观点,不代表51Testing观点)

版权声明:本文出自dongfangronger的51Testing软件测试博客:http://www.51testing.com/?188314

原创作品,允许转载,转载时请务必以超链接形式标明文章原始出处、作者信息和本声明,否则将追究法律责任。

《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号