Hi, 如果有任何想法与我沟通, 请用: lifr_nj 在 msn.com
关于Regression TestCase设计的思考之二: 自动化的Regression Test的问题
上一篇 /
下一篇 2013-12-15 12:35:08
/ 个人分类:QA
自动化的Regression Test的问题
第一个调查是对QA工程师的,让他们给出对现有自动化的testcase的感觉,他们提到“即使跑过了所有的自动化的testcase,但对于产品的质量还是没有足够的信心“。
另外一个是面向这个项目的开发人员的反馈调查。值得一提的是,这次项目里的开发人员并不是专职的QTP测试开发,他们本来是产品的开发人员,对于Java开发有相当的经验,这是他们第一次开发QTP的testcase。他们的反馈非常有意思,因为这些反馈触及到了我初次接触QTP就在心里产生的问题。
这些开发人员反馈“testcase的覆盖效率不高”,表现在
1. testcase中很多步骤都是在准备测试,反而真正的验证点不多
2. 很多testcase有重复的步骤
所以,综合起来就是,“我们实现了一些testcase,但这些testcase的覆盖效率和执行效率都不高,即使自动化执行了所有的testcase,我们并没有感到足够的信心“。说实话,对于自动化项目的一个主要实现者来说,这挺让人沮丧的。
但是,仔细想来,这样的反馈并不奇怪。我先描述一下我们自动化开发使用的testcase的base。我们采用的testcase base是QA为功能测试而开发的。这种testcase的特点是,多个testcase围绕一个功能点做多方位的覆盖,以尽可能的发现bug。比如针对一个创建用户的功能,用各种输入组合来测试。所以这种testcase base的testcase量是很大的。
Testcase的这种设计思路本身是没有问题的,它非常适合对新功能验证的测试需求。但问题是,这样的testcase适合以regression
test为目的的自动化测试吗?
一个事实是,QTP开发的自动化的testcase,主要是应用在Regression test中。而regression test的目的是:保证产品的已有的功能没有因为新的代码更改而产生质量问题。Regression test的目的不是穷尽各种方法去发现这些已有功能的bug,因为这些功能并不是新功能,而是已有的功能,这些功能的全面测试已经在一起的功能验证测试中执行过了。
所以,对于Regression test来说,把所有的功能验证testcase都执行一遍是不经济的,因为执行了十几个testcase,却仅仅测试了一个“功能点”。但不幸的是,大多数我经历的测试组织都是简单把功能验证的testcase作为regression testcase。其原因是值得思考的。
收藏
举报
TAG: