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