TestLink 的应用无疑给对测试的规划与任务的分配起到了很好的作用,如果再加上关键字的应用,会起到非常好的效果,下面我大概简单介绍一下我的想法,算是抛砖引玉,欢迎一起探讨:
在产品的整个测试的生命周期里,回归测试应该占到很大的比重,所以回归测试的好坏,无疑对产品品质起到至关重要的作用。那么作为一个测试人员,如何在数以万计的Case中圈定每版的回归测试呢?我想这一直是困扰测试人员的一个难题。为什么这样讲呢?因为这里面有个“度”是很难拿捏的,从我所接触的情况来看,回归测试,也可以完成,10天也不会嫌多,这是个无底洞。那么如何做才可以让我们对Release出去的产品有一定的信心呢?目前我们采用的大概方式如下: 1. 首先执行Smoke test 以确保基本功能没有问题(通常Smoke test 时间控制在2~3个小时之间) 2. 针对本版修改的功能进行验证性测试,确保本版任务完成。 3. 依据本版的任务,进行回归测试case 的圈定,并执行 4. Ad-hoc 测试
从上面的测试安排来看,1,2 很容易执行,没有歧义,问题在 3,4 ,我们先说说4, 一般我们定义Ad-Hoc 测试占本次测试约20%左右,按照这个原则,4也没有什么问题,后在第三点了,这也是回归测试做的好与不好的关键所在。 在这里,我们除了要注意一般回归测试所讲的注意点(如:基于风险的,基于矩阵的 等)另外我想引入一点是“关键字法”,我们可以对一个产品的STD进行关键字的提取,形成一个关键字表,然后为每条Case 添加关键字,当然,这个过程还是需要花费一些功夫,不过磨刀不费砍材功,这个做好后,会后期的帮助会很大。当这些Case都导入TestLink 后,后面的工作比较好做了。 首先,按照同样的方法,对本次Build所修改的内容进行关键字的提取,依据关键字在TestLink 中进行搜索,这样可以快速的圈定测试范围,同样,对本次Build 所解决的Bugs 也进行关键字提取(这里可以给Mantis 等这样缺陷管理工具进行客制化,使其可以给每个缺陷添加关键字,而且可以通过对Bugs的描述,自动的在关键在表中推荐一些Keyword)这样可以快速的完成上面第三步骤。
这样下来,我们的测试任务算是完成,通过这样的测试所Release出去的产品,我想作为一个测试人员应该有一定的信心。当然配合自动化,那是完美组合了。
以上为个人的一些看法,欢迎讨论。 (以上方法比较适合中大型专案,如果是小型的案子,那另当别论了!