本文的目的不是將軟件測試流程優化的話題闡述的面面俱到，而是從管理角度談談測試用例在測試活動中的重要性，以及測試用例管理流程的一些改進思路。
    常聞軟件測試者的如此抱怨：
    測試用例在實際中根本沒有起多大作用？
    測試人員在實際測試時都沒有按測試用例來執行？
    測試執行后沒有把需要更新的測試用例補充到用例庫中？
    …… 　　

    當前國內軟件企業測試流程不規范的原因分析：
    1） 從事物的發展規律看，軟件測試行業在我國還是新興行業，目前還處于起步和探索期，雖然國外的同行業發展到了一定階段，但事實上他們也在不斷的否定自我并探索著更成熟的方法、尋求著更有效的方案；而國內的測試行業發展期不過10來年，所謂的測試管理流程不規范，也就情有可原了。

    2） 從企業個體角度講，測試部門的整頓和加強，按照企業自身發展的優先層次，還沒有被納入優先解決的程度，開拓市場、簽訂定單才是首要問題，也是維系企業生存發展的命脈。當然國內很多的大中型軟件公司的測試部門相對完善，如神州數碼、用友、聯想等，他們和大型跨國軟件公司的合作，也從中汲取了寶貴的管理經驗。

    3） 還有一個普遍存在的問題。近幾年國內軟件企業為了加強企業的競爭優勢和名氣提升，通常大搞特ISO/CMM認證；筆者也很支持這么做，但更關注的是通過這些認證后的企業有多少真正按照那些規范、設計的標準在后續的測試或軟件開發管理工作中著手開展下去呢？社會上流傳著這樣的話：任何認證到中國，都免不了砸牌兒！筆者讀書時很多高校搞的MCSE認證，有培訓機構明目張膽聲稱"百分百通過率"！當年也有專門媒體報道此事。聽到這樣的話，我們都會寒心，這里真心希望我們的軟件企業通過ISO/CMM后真正為企業的內部軟件開發流程帶來一點新生的曙光。

    4） 一個原因，我想是企業內部測試管理人員和技術人員技能的不足，還有自身工作態度的不夠端正。有了再好的規范標準，沒人遵守不行！沒人實施不行！應該說，很多中小軟件企業的高層都或多或少的逐漸意識到軟件測試的重要性和必要性，以及它的標準化、流程化改革的緊迫性，但也有很多的工程師、技術人員并不理會這套，常常在實際工作中投機取巧；也有很多測試管理人員后天的經驗不足、技能不夠，對公司測試管理工作考慮不到位，和開發工程師交流不充分，和上層領導反映不及時等等。

    總之，任何問題的出現都不是單方面的原因，從宏觀的社會形勢到微觀的企業個人，都有無可推卸的責任；正因為如此，解決問題也要對癥下藥，如何完善軟件測試流程，就要從小處出發；本文不可能將軟件測試流程優化的話題闡述的面面俱到，因此只從管理角度談談測試用例在測試活動中的重要性，以及測試用例管理流程的一些改進思路。

    強化測試用例在測試活動中的作用
    測試用例在實際中沒有起多大作用,在實際測試時根本沒有按測試用例執行，測試執行后沒有把新的測試用例補充到用例庫中……為何如此？我們分析認為，根本原因是對測試用例重要性的認識不夠，測試流程不完善，針對測試用例的管理流程更不完善，從三個方面具體來說：

    1） 測試用例的重要性是毋庸置疑的，它是軟件測試全部過程的核心，是測試執行環節的基本依據，如果這個依據不能足夠發揮它應起的作用，那是不是說這個依據不明確、依據設計的不合理呢？答案是肯定的！

    2） 制定了完備有效的測試用例，為什么不按測試用例執行測試呢？首先是因為企業沒有嚴格和良好的機制促使和保證測試執行者這樣做；其次是個別測試人員投機取巧心理作祟的表現。

    3） 測試用例設計得不可能天衣無縫，不可能完全滿足軟件需求的覆蓋要求，測試執行過程里肯定會發現有些測試路徑或數據在用例里沒有體現，那么事后該將其補充到用例庫里，以方便他人和后續版本的測試；如果沒有這樣做，那么測試部門負責人和每個測試員都難辭其疚，是該重新坐下來思考一下公司的測試用例管理規范和測試流程了。

    改進測試用例執行過程
    那么究竟如何做，才能盡量避免上述問題呢？我們不妨從軟件開發周期的每個階段就把這些問題考慮進去，以便從初始就力爭將問題縮到小，將其扼殺在萌芽階段，以防后期階段出現問題時互相推卸責任或干脆束手無策！

    1） 軟件需求分析階段，筆者從來認為測試人員從軟件生命周期的需求階段就開始介入。通常測試人員的測試工作開展在開發周期的末尾，如果前期不涉入，如何通曉整個系統的需求和架構而對其充分測試呢？雖然該觀點被大多數同行所認可，但我知道依然有很多公司為了節省費用，不讓測試人員參與前期調研或制定需求，經常的做法是等到系統開發完畢或將近完成，跟測試經理說一聲"這邊有個項目，你找幾個人來測試一下吧！"經驗表明，這樣的做法實不可取。

    測試人員（指項目的測試負責人和測試工程師）在需求階段的任務有：
    參與軟件需求調研，以測試角度分析需求的可測性，可構思將來對其測試的方法、原則等；更重要的是，對不可測或難以測試性問題要及時與客戶或項目經理協調解決。

    全面了解系統需求，從客戶角度考慮軟件測試需要達到的驗證狀態，即何些功能點需重點測試、何些無需，以便將來制定測試計劃。

    推薦企業采用類似于IBM Rational Requisitepro的需求管理工具來制定和管理軟件需求，同時需要測試人員的配合，保證對軟件測試環節的充分考慮。

    2） 軟件分析設計階段，測試人員除制定測試計劃書等基本工作外，筆者認為還有一個相當必要的任務，那就是將系統的可測性落實到書面文檔，以備將來編寫測試用例。

    之所以要這么做，是因為考慮到很多企業編寫測試用例直接參考需求規格說明書或者分析流程圖，這樣跨度大，難度也大，是造成測試用例不完備、覆蓋范圍小的重要原因。

    如果公司采用類似于IBM Rational Rose的建模分析工具和IBM Rational Rose XDE Developer的可視化設計開發環境，這個工作更好執行；如果沒有，那么測試人員更有必要編寫一份《軟件功能點測試描述書》，它是軟件的詳細測試分析文檔，其主旨是將系統分析人員的開發分析文檔加工成以測試為角度的功能點分析文檔，重要的是描述對系統分解后每個功能點逐一的校驗描述，包括何種方法測試、何種數據測試、期望測試結果等，這些信息都是描述性的，無須具體數據；它的作用是據此編寫測試用例，以及測試執行時的參考依據，基于它直接來源于需求，覆蓋當然全，也能貼近客戶要求。

    當然該文檔不是非要不可，筆者只是提倡一種原則，如果有類似的替代文檔或有工具可自動實現此功能，則會倍加受推崇！

    筆者之所以推薦IBM Rational系列產品在軟件項目中的應用，是因為IBM Rational倡導的RUP（Rational Unified Process）方法論采用了用例驅動的原則。所謂用例驅動，是以體系結構為中心，采用迭代、增量方式的開發過程；而其Rational工具系列正是將這一理念進行行為表述，是當前軟件工程領域一套無可比擬的強大工具集，從需求到測試，它都以用例為基本模型，全面貫穿軟件開發的每個環節。

    3） 軟件開發階段，編寫測試用例。我不想從技術角度探討到底如何編寫功能強大、質量的測試用例（可參考筆者主頁轉載的"如何設計編寫軟件測試用例"），這里只想從管理角度和大家談談如何有效控制和增強測試用例在測試活動中的應用。應該遵守的原則是：

    首先，從覆蓋率來說，測試用例庫的用例要達到覆蓋軟件系統的功能點。按照我上述所言的方式，測試工程師從前期階段順次下來，編寫測試用例時，基本上就是將《軟件功能點測試描述書》中的每個功能點進行操作上的細化：一是從步驟上描述到達校驗點的方式，二是從內容上描述以何種數據校驗功能點；如此可實現趨向需求覆蓋率。

    其次，從數量來講，筆者覺得很多公司的測試用例太少，甚至遠遠不能覆蓋系統需求，這也是很多測試人員在測試工作開展初期按照用例執行、而后漸漸憑"意念"去執行測試的原因。應該說測試用例的數量很難用數學模型來模擬，更沒辦法衡量，但憑借個人經驗來說，一個多于半年開發周期（指從編碼開始直到提交客戶的時間段）的軟件系統，它的用例數量不要低于4000個，甚至更多！也許有人驚訝這一數字，不過了解IBM等大公司測試過程的人士會認為4000還是很少的數目。我們試想，對于一個中小型軟件系統，如果設計出5000個用例，那它的測試覆蓋率還怕不高么！

    再次，如此眾多測試用例的管理問題。是的，需要管理工具軟件！筆者從來都反對以word或excel來編寫測試用例：格式上難于編寫--通常方式是企業自己設計表格模版，但編輯上始終存在不便，尤其對于一些共性內容，如測試目標、測試環境、參考說明等，每次都要大量的復制、粘貼。

    其次難于管理--如果把幾千個文檔文件放在一個共享文件夾里，即便以子目錄方式管理，但是每次查找一個特定用例，你的眼睛也必將飽受煎熬！

    更是難于執行--莫非真要針對幾千個用例都是打開一個word-執行測試-輸入測試結果-關閉word嗎？

    重要的是，根本沒辦法追蹤測試結果--在本輪回歸測試輸入完測試結果，但是下一輪結果輸入到哪里？輸入了這些測試結果什么用？能方便的根據其結果統計軟件質量嗎？還有，可以用它追蹤發現的軟件缺陷嗎？有辦法追蹤嗎？

    使用word等軟件編寫測試用例的種種不便大致如上，但換個思路思考一下使用集成工具的種種優勢便更加一見分曉。測試同業者們都了解的測試用例管理工具便是IBM Rational TestManager，它是專業的測試用例管理和測試管理工具，其設計出發點就已經考慮到了我們上述的種種困境，因此給予了良好的解決方案。以其為測試管理平臺，測試人團隊成員可以計劃、管理、組織、執行、評詁以及報告等縱向測試活動，如果與IBM Rational Clearquest集成使用，還可即時跟蹤軟件的需求變更，從而增強整個軟件團隊的橫向溝通與合作。

    而且，個人覺得測試行業的快速發展，必將帶來從每個環節都逐漸向自動化和標準化方向邁進，盡早適應這一趨勢，不僅提高了工作效率，也提高了企業的信譽和名譽。

    ，說一下測試用例格式上一般內容以外的幾個要點：
    一是在測試管理工具中制定適合本公司的測試用例模版
    二是用例模版里要有關鍵字索引，以方便按關鍵字分類查找，如測試方法（分手工/自動兩種）
    三是測試用例要有狀態跟蹤，可根據用例執行狀態索引用例（測試通過、測試失敗、測試中斷等）
    四是執行失敗的用例要鏈接到相應的缺陷報告，如有根據缺陷報告檢索測試用例的試圖更妙，可評估該缺陷影響范圍的大小
    五是測試用例的修改，以及每個測試周期的運行都有日志記錄，以便后期追蹤和新員工參考。

    4） 軟件測試階段，測試負責人劃分不同的測試階段（如集成測試、系統測試、回歸測試、性能測試等），再劃分不同的子測試周期（如前兩個星期做冒煙測試，測試方式是手工/自動，測試版本是**，測試環境是**，包括服務器端與客戶端等；接著做模塊功能測試；如此順次。），再為項目組測試人員分配測試用例（通常原則是每個人負責幾塊區域的測試任務），測試人員則按照詳細的用例文檔去執行測試，測試失敗則提交軟件缺陷報告。這里要遵循的幾個原則是：

    A）有健全且嚴格的體制保證測試執行者嚴格按照測試用例執行測試。這并不妨礙測試者創造力的發揮，因為前期用例的設計和編寫就是項目全體測試人員智慧的結晶！我們一直苦苦追尋眾多測試工程師加班加點辛苦工作的原因，其實大都發生這一階段；如此實施，即便沒有解決根本問題，也會大大提高測試執行效率。

    B）如有對測試用例認識模糊或內容遺漏的地方，可暫做記錄待后期解決，或經測試負責人與項目其他管理人員同意方可更新用例庫。

    C）測試負責人每日負責跟蹤本測試子周期或階段的測試用例執行情況，以及每日提交的缺陷報告，根據執行進展狀態以及缺陷數量或嚴重等級與項目高層或其他人員展開交流，商議解決途徑，并確定或調整未來時間的測試任務。

    D）測試執行者負責執行自己區域的測試用例，還要負責跟蹤該區域軟件缺陷的修改進展，根據其狀態不斷驗證軟件功能點。

    E）應該提及的是，大多數軟件公司都采用集成的缺陷管理工具來管理軟件缺陷，如IBM Rational ClearQuest（變更管理與缺陷管理工具）等，這是值得稱頌的好跡象；這樣的集成工具都提供了清晰的報告模版及強大的追蹤功能，測試團隊的每一成員按照自己的角色和權限訪問缺陷管理工具，并不斷跟蹤軟件缺陷的狀態。

    F）對于自動測試（包括自動化功能測試和性能、壓力測試），有一些特殊要點。本人的原則是自動化測試無須編寫測試用例，只要在編寫時將用例庫里適合或需要自動測試的用例的測試方法（不同工具可能名稱不同）設為自動即可，故而到此階段才提及自動化測試。自動化測試的實施方案有所不同，每款測試工具的使用和測試流程也不同，但都可以從在這一階段編寫測試腳本，并運行自動測試。例如IBM Rational Robot（參考官方說明http://www-900.ibm.com/cn/software/rational/products/robot/index.shtml）或XDE Tester（http://www-900.ibm.com/cn/software/rational/products/xde_tester/index.shtml，現更名為Rational Functional Tester）。針對自動化測試原則，可參閱筆者的"自動化測試要點"譯文，這里要提的其他幾個基本原則是：

    一是選擇恰當的測試工具品牌，并要求提供培訓；
    二是項目的自動化測試工作有專人負責跟蹤，以保證工作質量，他們可不參與日常測試；
    三是確定自動化測試成員在項目中的角色，一般自動化測試成員隸屬于項目測試負責人，負責人同樣跟蹤其工作狀態；
    四是選擇簡單、重用的測試用例使用自動測試方法；

    五是使用工具廠商提供的測試框架編寫腳本，千萬別采用單純錄制-加校驗點-回放的方式，以開發出健壯且重用性強的測試腳本；
    六是有專人更新腳本，也有專人跟蹤自動測試結果；
    七是一般選擇的測試工具品牌和缺陷管理工具品牌是同一廠商，以方便不同類型缺陷的集中管理；

    八是在多人協作開發測試腳本、代碼量相對較大情況下，應考慮使用配置管理工具來管理測試腳本，IBM Rational ClearCase是當前業界功能強大的配置管理工具，可以將開發代碼和測試代碼都集中管理，進行高效的版本控制和工作空間管理，保證多人開發大量代碼的穩定性。對于局域網范圍內的開發工作，使用ClearCase LT版足夠。

    G），由于不同公司開發產品的特殊性，也許需要特殊類型的測試，如安全測試、甚至代碼級單元測試等，這些內容需要酌情考慮測試用例的編寫，以及測試的執行。

    5） 軟件驗收階段，除了提交軟件測試評估報告（各種類型測試結果的評估都應有報告）這些基本工作外，對于測試用例，此時要集中時間更新，更新整個測試周期中一切需要更新的內容，以方便未來新版本的測試。即便您開發的是項目軟件--提交客戶后沒有新版本--那也需要后期維護，維護階段需要重新測試某功能點，然而用例如果不準確，碰巧又是一個新員工來做，那就死翹翹了！

    退一步說，如果您公司的測試部門經歷一次這樣重大的洗禮，有一個項目真正按照此原則實施一次，也必將對未來測試工作的開展發揮推波助瀾的作用、起到事半功倍的效果。

    6） 其他說明：加強測試部門內部人員的培訓教育很重要，包括工作技能與個人素質兩方面，可通過國內主要的培訓機構，也可是購買工具廠商的直接培訓。應該說，很多測試新人對于測試用例的書寫還存在問題，更別提及測試用例的管理或執行；以此可見，我們的測試工程師需要培訓的空間還很大。

    另外，筆者不贊成對人員的強制性管理，例如大張旗鼓整頓公司測試部門的管理，采取缺陷報告數和人員績效掛鉤、不按測試規范執行就適當懲罰等手段；個人認為切不可急功近利，當以人為本，鼓勵+促進甚善然、甚妙哉！

    總結
    綜上所述，我們得出結論-- 測試用例在測試中沒起到應有的作用，是因為測試用例編寫質量不高，覆蓋不夠，執行不利；測試執行時不遵循測試用例，執行后不更新用例庫，是測試部門的整體工作流程不健全、不規范；至于如何解決，筆者提出了微薄建議，供業界朋友參考與交流。

    國內軟件測試行業目前仍處在群雄逐鹿、百家爭鳴的時期，蕓蕓紛說，不如從企業自身出發，確立適合自我的測試管理解決方案，整頓自身的測試工作流程，那才是金玉良言的上上策！