如果利用TestLink + Keyword 来更加方便准确的圈定回归测试的范围

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出去的产品，我想作为一个测试人员应该有一定的信心。当然配合自动化，那就是完美组合了。

以上为个人的一些看法，欢迎讨论。
（以上方法比较适合中大型专案，如果是小型的案子，那就另当别论了！）