Hi, 如果有任何想法与我沟通, 请用: lifr_nj 在 msn.com

关于Regression TestCase设计的思考之二: 自动化的Regression Test的问题

上一篇 / 下一篇  2013-12-15 12:35:08 / 个人分类:QA

自动化的Regression Test的问题

第一个调查是对QA工程师的,让他们给出对现有自动化的testcase的感觉,他们提到“即使跑过了所有的自动化的testcase但对于产品的质量还是没有足够的信心“。

 

另外一个是面向这个项目的开发人员的反馈调查。值得一提的是,这次项目里的开发人员并不是专职的QTP测试开发,他们本来是产品的开发人员,对于Java开发有相当的经验,这是他们第一次开发QTPtestcase他们的反馈非常有意思,因为这些反馈触及到了我初次接触QTP就在心里产生的问题。

 

这些开发人员反馈testcase的覆盖效率不高”,表现在

1.       testcase中很多步骤都是在准备测试,反而真正的验证点不多

2.      很多testcase有重复的步骤

 

所以,综合起来就是,“我们实现了一些testcase但这些testcase的覆盖效率和执行效率都不高,即使自动化执行了所有的testcase我们并没有感到足够的信心“。说实话,对于自动化项目的一个主要实现者来说,这挺让人沮丧的。

 

但是,仔细想来,这样的反馈并不奇怪。我先描述一下我们自动化开发使用的testcasebase我们采用的testcase baseQA功能测试而开发的。这种testcase的特点是,多个testcase围绕一个功能点做多方位的覆盖,以尽可能的发现bug。比如针对一个创建用户的功能,用各种输入组合来测试。所以这种testcase basetestcase量是很大的。

 

Testcase的这种设计思路本身是没有问题的,它非常适合对新功能验证的测试需求。但问题是,这样的testcase适合以regression test为目的的自动化测试吗?

 

一个事实是,QTP开发的自动化的testcase,主要是应用在Regression test中。regression test的目的是:保证产品的已有的功能没有因为新的代码更改而产生质量问题。Regression  test的目的不是穷尽各种方法去发现这些已有功能的bug因为这些功能并不是新功能,而是已有的功能,这些功能的全面测试已经在一起的功能验证测试中执行过了。

 

所以,对于Regression test来说,把所有的功能验证testcase都执行一遍是不经济的,因为执行了十几个testcase却仅仅测试了一个“功能点”。但不幸的是,大多数我经历的测试组织都是简单把功能验证的testcase作为regression  testcase其原因是值得思考的。


TAG:

 

评分:0

我来说两句

Open Toolbar