對于測試用例的復(fù)用，我想很多測試工程師都會非常有話說，系統(tǒng)變更頻繁，業(yè)務(wù)變化大，
工作流 不統(tǒng)一等等，很多現(xiàn)實存在的問題，都阻礙了測試用例的復(fù)用發(fā)展進程，但是金融風(fēng)暴下，越來越多的IT公司都在為了降低成本而做不屑的努力，如解決方案的產(chǎn)品化、搭建軟件系統(tǒng)的可復(fù)用平臺、開發(fā)可復(fù)用的功能組件等等，毫無疑問的，這些都會為了我們能夠提高測試用例的復(fù)用性打下了基礎(chǔ)，拋開開發(fā)人員的因素不談，而我們在這里也只針對如何從測試人員自身來提高測試用例的復(fù)用性來討論吧：
這里需要首先區(qū)分一下，是手動測試用例還是自動測試用例？
一、對于自動測試用例，首先就是要改變腳本的開發(fā)方法，如：
1.數(shù)據(jù)驅(qū)動腳本：將測試數(shù)據(jù)從腳本中分立，保存在外部文件中，當(dāng)數(shù)據(jù)發(fā)生變化時，就不再需要更改代碼，腳本的維護成本也比較低
2.關(guān)鍵字驅(qū)動腳本：把腳本中的檢查點和執(zhí)行操作的控制都維護在外部文件中，同樣的，數(shù)據(jù)也會與代碼分離開，可以說是結(jié)合了數(shù)據(jù)驅(qū)動的腳本開發(fā)方法，提高了測試腳本的共享和復(fù)用，缺點就是腳本開發(fā)需要更多的編程經(jīng)驗和設(shè)計能力
二、對于手動測試用例，那么我們就需要解決如下問題：
1.測試用例管理工具：之前看到很多討論，都沒有提到這個，但我想說的是，工欲善其事，必先利其器，良好的測試用例管理工具，絕對會為測試用例的復(fù)用帶來簡單、方便和快捷，也比office文檔更適用于測試用例庫的建設(shè)和維護
2.測試用例的設(shè)計策略：測試策略無非有兩種，基于功能和基于風(fēng)險，之前也在論壇里提到過，還有筒子回貼說，測試策略就是基于功能的，這點我不敢茍同， 基于風(fēng)險的測試用例，往往才是最能被復(fù)用的，對于任何同類型產(chǎn)品來說，無論如何進行功能升級，其失效模式也一定大同小異，比如：汽車的失效模式之一——剎 車失靈，這個不論是小汽車、三輪車、還是大卡車，都會存在同樣的問題，但是功能和性能上，三者之間的差異就比較大了，所以我才會提到我們需要在測試開始前 考慮這樣一種基于風(fēng)險的測試策略
3.業(yè)務(wù)抽象：對于測試來說，同樣需要跟研發(fā)的系統(tǒng)分析師有相當(dāng)水平的測試設(shè)計師存在，他們的工作職責(zé) 是分析系統(tǒng)需求、抽象業(yè)務(wù)用例、設(shè)計測試方案來指導(dǎo)測試用例的進行，測試用例的復(fù)用也應(yīng)該在這一環(huán)節(jié)被考慮，因為一條一條的去查找和審閱相同和相似的測試 用例，對于龐大的系統(tǒng)來說，由于海量測試用例的存在，無疑為大海撈針，但是從更高層次的業(yè)務(wù)用例中去尋找相似性，一定是更快捷的方法，但這也同時需要清晰 合理的、能夠與分解后業(yè)務(wù)用例對應(yīng)的、可跟蹤可追溯的測試用例庫結(jié)構(gòu)，基于此，我才把管理工具放在了第一位
以上是我對于“如何提高測試用例復(fù)用性”的問題答案，其中不考慮“如何正確編寫測試用例？”“如何進行測試用例設(shè)計”等問題。