关于Regression TestCase设计的思考之一: 忽视全局资源管理造成大问题

关于Regression TestCase设计的思考

忽视全局资源管理造成大问题

前段时间做了一个QTP自动化测试项目。这是一个比较小的项目（或许这是唯一比较幸运的地方），实现的testcase数只有80个，时间也不长4个人做了一个月（非full time），但是它却让我得到了做QTP以来最大的一个教训。

这个项目在开发阶段没有什么问题，但是在开发完成后的批量执行中出现了问题，那就是还不到一半的testcase能成功运行。也就是一个testcase，即使他们在开发阶段都能顺利执行，但把他们放在一起批量执行，却是问题多多。

为什么会出现这样的后果，我后来分析，有下面一些原因

1.      全局资源管理不善

在多人进行开发的时候，并不完全清楚系统里哪些资源是可以使用的，哪些资源是不能修改的。导致的后果是，有一些在testcase里引用的资源在批量运行时却不存在，有一些资源的属性的值被一些testcase引用，但却被另外一些testcase修改。

2.      底层函数库不完善。

在底层函数不完善的情况下开始大规模testcase开发，后果是有一些功能被重复实现，另外的情况是顾不上代码重用，先把testcase自动化起来，至于代码是否高质量，就管不上了。

3.      开发人员并没有完全掌握QTP和Framework

部分开发人员本来是做Java开发的，而这些开发人员没有足够时间的学习和培训就开始实行testcase，其结果是testcase的代码质量不高。

在这些问题中，问题2和问题3，实际上项目开始之前我就意识到有问题，并上报了可能的风险， 最后出问题并不奇怪。但是，全局资源管理不够清晰这个问题我开始却没有意识到，因为在以前的开发项目中，全局资源管理并没有真正成为一个问题。

因为以前的项目首先只面对一个产品，但是，这个项目面对的是一个比以前所有项目都要复杂得多的情况，因为它涉及到两个产品的集成。所以在testcase里引用到很多全局资源，但在项目开始之前，所有开发人员并没有对全局资源管理特别留心。这样出现的后果是，全局资源的使用上出现了冲突。比如一个testcase修改了另外一个testcase引用的全局资源，所以也就出现了单个testcase能通过，放在一起运行就fail的情况。

其次以前的项目都是我完成了大部分底层函数库，然后是有经验的开发工程师加入进来，一起大规模的实现testcase，所以也没有问题2）和问题3）。

我们还是回到问题1），为什么这些testcase由人来执行没有问题，由QTP实现出来，执行却有这么大问题呢？毕竟这些自动化的testcase的基础是功能testcase库，里面的testcase已经有tester执行多次。

因为人具有很大的灵活性。相对于程序，人特别善于处理并不精确的描述。在这个case里，就是testcase所依赖的资源描述不精确。

举个例子，如果一个testcase的检查点是关于一个没有“modify rule”权限的用户去modify rule，那么这个testcase就有一个潜在的precondition“系统已经存在用户AAA，没有modify rule的权限“。但是对于自动化脚本来说，有两选择

1） 在testcase里创建AAA

2） 在全局创建AAA，

第一个方法的好处是，没有全局依赖，从testsuite角度来说设计简单，但是可能会存在浪费，因为别的testcase可能也需要这样一个用户，出现重复创建同样性质用户的情况。第二个方法正好相反，它引入了全局依赖，从testsuite角度来说设计更复杂，要全盘考虑，但是整体执行效率更高。

在QTP测试项目开发过程中,全局资源管理是一个值得注意的问题.这就是我从这个失败的项目中获得的教训。这是一个很有意义的教训，但是还没有到此为止。因为后面的两个调查反馈的结果，触及到了我刚开始做QTP时就有的一个疑问：用于自动化testcase的testcase库是否需要专门设计？还是使用已有的为手工测试设计的testcase库？