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出去的產品，我想作為一個測試人員應該有一定的信心。當然配合自動化，那是完美組合了。
以上為個人的一些看法，歡迎討論。
（以上方法比較適合中大型專案，如果是小型的案子，那另當別論了！
