問題描述：在階段編寫的
測試用例
少則幾百，多則過萬，花費時間很多，而且有相當一部分用例只執行一兩次，復用性不佳。這裡想討論一下如何提高用例的復用性，尤其是不同專案之間。系統測試
精彩答案：
對於測試用例的復用，我想很多測試工程師都會非常有話說，系統變更頻繁，業務變化大，流不統一等等，很多現實存在的問題，都阻礙了測試用例的復用發展程序，但是金融風暴下，越來越多的it公司都在為了降低成本而做不屑的努力，如解決方案的產品化、搭建軟體系統的可復用平台、開發可復用的功能元件等等，毫無疑問的，這些都會為了我們能夠提高測試用例的復用性打下了基礎，拋開開發人員的因素不談，而我們在這裡也只針對如何從測試人員自身來提高測試用例的復用性來討論吧：
工作
這裡需要首先區分一下，是手動測試用例還是自動測試用例？
一、對於自動測試用例，首先就是要改變指令碼的開發方法，如：
1.資料驅動指令碼：將測試資料從指令碼中分立，儲存在外部檔案中，當資料發生變化時，就不再需要更改**，指令碼的維護成本也比較低
2.關鍵字驅動指令碼：把指令碼中的檢查點和執行操作的控制都維護在外部檔案中，同樣的，資料也會與**分離開，可以說是結合了資料驅動的指令碼開發方法，提高了測試指令碼的共享和復用，缺點就是指令碼開發需要更多的程式設計經驗和設計能力
二、對於手動測試用例，那麼我們就需要解決如下問題：
1.測試用例管理工具：之前看到很多討論，都沒有提到這個，但我想說的是，工欲善其事，必先利其器，良好的測試用例管理工具，絕對會為測試用例的復用帶來簡單、方便和快捷，也比office文件更適用於測試用例庫的建設和維護
2.測試用例的設計策略：測試策略無非有兩種，基於功能和基於風險，之前也在論壇裡提到過，還有筒子回貼說，測試策略就是基於功能的，這點我不敢苟同，基於風險的測試用例，往往才是最能被復用的，對於任何同型別產品來說，無論如何進行功能公升級，其失效模式也一定大同小異，比如：汽車的失效模式之一——剎車失靈，這個不論是小汽車、三輪車、還是大卡車，都會存在同樣的問題，但是功能和效能上，三者之間的差異就比較大了，所以我才會提到我們需要在測試開始前考慮這樣一種基於風險的測試策略
3.業務抽象：對於測試來說，同樣需要跟研發的系統分析師有相當水平的測試設計師存在，他們的工作職責是分析系統需求、抽象業務用例、設計測試方案來指導測試用例的進行，測試用例的復用也應該在這一環節被考慮，因為一條一條的去查詢和審閱相同和相似的測試用例，對於龐大的系統來說，由於海量測試用例的存在，無疑為大海撈針，但是從更高層次的業務用例中去尋找相似性，一定是更快捷的方法，但這也同時需要清晰合理的、能夠與分解後業務用例對應的、可跟蹤可追溯的測試用例庫結構，基於此，我才把管理工具放在了第一位
以上是我對於「如何提高測試用例復用性」的問題答案，其中不考慮「如何正確編寫測試用例？」「如何進行測試用例設計」等問題。
如何編寫測試用例
一 準備工作 要全所有的相關文件 1 產品需求文件 prd 2 用例說明 3 產品的設計原型 4 產品的效果圖 二 分析整個系統 軟體 的結構和業務流程 1 確認好功能點及需求，對存在分歧的或是可優化的部分可以及時與產品經理進行溝通。2 核對好產品功能和效果圖是否完備，如果存在問題要與產品 ui設計...
如何設計測試用例
測試基礎 測試用例 測試用例 test case 是為某個特殊目標而編制的一組測試輸入 執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求。測試用例作用 檢驗是否滿足客戶需求 度量測試人員的工作量 展現測試用例的思路。測試用例包含 用例編號 唯一的編號。用例名稱 言簡意賅，描述準確...
如何組織測試用例？
如何組織 測試用例 比如何寫測試更重要。個人的一些經驗總結在此。1.使用describe 和 context 來區分 不同的測試分類和同乙個測試的不同方面 describe 一般用作分類，需要測試什麼東西 context 用來對需要測試的東西的不同方面 比如 descirbe order do 分類...