TestLink 的應(yīng)用無疑給對測試的規(guī)劃與任務(wù)的分配起到了很好的作用，如果再加上關(guān)鍵字的應(yīng)用，會起到非常好的效果，下面我大概簡單介紹一下我的想法，算是拋磚引玉，歡迎一起探討：
在產(chǎn)品的整個測試的生命周期里，回歸測試應(yīng)該占到很大的比重，所以回歸測試的好壞，無疑對產(chǎn)品品質(zhì)起到至關(guān)重要的作用。那么作為一個測試人員，如何在數(shù)以萬計的Case中圈定每版的回歸測試呢？我想這一直是困擾測試人員的一個難題。為什么這樣講呢？因為這里面有個“度”是很難拿捏的，從我所接觸的情況來看，回歸測試，也可以完成，10天也不會嫌多，這是個無底洞。那么如何做才可以讓我們對Release出去的產(chǎn)品有一定的信心呢？目前我們采用的大概方式如下：
1. 首先執(zhí)行Smoke test 以確�；竟δ軟]有問題（通常Smoke test 時間控制在2~3個小時之間）
2. 針對本版修改的功能進行驗證性測試，確保本版任務(wù)完成。
3. 依據(jù)本版的任務(wù)，進行回歸測試case 的圈定，并執(zhí)行
4. Ad-hoc 測試
從上面的測試安排來看，1，2 很容易執(zhí)行，沒有歧義，問題在 3，4 ，我們先說說4， 一般我們定義Ad-Hoc 測試占本次測試約20%左右，按照這個原則，4也沒有什么問題，后在第三點了，這也是回歸測試做的好與不好的關(guān)鍵所在。
在這里，我們除了要注意一般回歸測試所講的注意點（如：基于風(fēng)險的，基于矩陣的 等）另外我想引入一點是“關(guān)鍵字法”，我們可以對一個產(chǎn)品的STD進行關(guān)鍵字的提取，形成一個關(guān)鍵字表，然后為每條Case 添加關(guān)鍵字，當(dāng)然，這個過程還是需要花費一些功夫，不過磨刀不費砍材功，這個做好后，會后期的幫助會很大。當(dāng)這些Case都導(dǎo)入TestLink 后，后面的工作比較好做了。
首先，按照同樣的方法，對本次Build所修改的內(nèi)容進行關(guān)鍵字的提取，依據(jù)關(guān)鍵字在TestLink 中進行搜索，這樣可以快速的圈定測試范圍，同樣，對本次Build 所解決的Bugs 也進行關(guān)鍵字提�。ㄟ@里可以給Mantis 等這樣缺陷管理工具進行客制化，使其可以給每個缺陷添加關(guān)鍵字，而且可以通過對Bugs的描述，自動的在關(guān)鍵在表中推薦一些Keyword）這樣可以快速的完成上面第三步驟。
這樣下來，我們的測試任務(wù)算是完成，通過這樣的測試所Release出去的產(chǎn)品，我想作為一個測試人員應(yīng)該有一定的信心。當(dāng)然配合自動化，那是完美組合了。
以上為個人的一些看法，歡迎討論。
（以上方法比較適合中大型專案，如果是小型的案子，那另當(dāng)別論了！
