前段時間將專案中的測試用例進行了一次大規模的整理，從工作量出發認識到了測試用例書寫及管理規範的重要性。規範的測試用例管理可以為後續的測試工作節約不小的工作量。

隨著網際網路時代的到來，專案迭代的頻率越來越快。測試用例的可持續性尤為重要。如何有效的將測試用例進行編寫及管理慢慢也成為測試工作者思考及修正的必修課。下面我將針對自己在測試工作中的一些積累及個人認為有助於有效管理測試用例的小技巧整理出來分享給大家。以下內容將會從兩個方面進行表述：一，測試用例的編寫；二，測試用例的管理。

一，  測試用例的編寫

測試用例編寫總體分為兩個階段：1，需求分析；2，用例設計。為什麼我這裡用詞是設計而不是編寫，下文中會進行進一步的說明 

1.需求分析

專案中的需求分析是重要的一環無論是自研還是外包，有的夥伴可能會說：我們公司小，需求完全靠口，文件基本沒有。但是需求評審無論文件有無都是可以進行的。只是進行的方式不同，同時要做好文件記錄的工作，為專案後續測試工作做好準備，下面我會對不同有無文件進行一個整理

有需求文件：在做需求文件分析的時一般我會從幾個方面進行分析：入口，條件，異常，結果，以及需求邏輯。為什麼要說到需求邏輯，因為需求也是人設計的那麼就一定會有沒有考慮到的邏輯，或者說是潛意識的“順理成章”比如：點選事件觸發結果就僅有成功和失敗嗎？其實還有一種結果位於成功與失敗的中間“等待過程”。一般這時間是短暫，短暫到人們忽略它。如果在“等待過程”中我們進行了另一個事件的觸發可能就會導致程式的異常。

那我們就用“某某寶”支付類APP中的掃碼功能為例進個說明。

                       入口：一般我們會需求進行一個簡單的分類。那麼我們要考慮的入口就會有：主頁面的“掃一掃”和標題欄中“+”號中的掃一掃。

                       條件：簡單來說就是“***條件下”“***情況中”條件就有“網路狀態”“攝像機狀態”“攝像許可權狀態”等

                       異常：可以理解為邏輯之外，包含非APP本身的條件。異常就有“返回後臺”“關閉許可權”“電話”“斷網”等

                       結果：這裡主要指在不同入口及條件下展示的結果不一樣，如：關閉攝像機許可權-無法開啟攝像頭，沒有攝像頭彈框提示“未安裝攝像頭”等

                       需求邏輯：這個就要對產品有進一步的整理後才能發現，或者說文案中暫時沒有邏輯上的問題

無需求文件：在沒有需求文件的時候，更需要測試者重視對於文件輸出。測試時一個伴隨開發而進行的持續性的工作，只有了文件的支援在後續的工作中才能有效規範的對自己及團隊的工作量進行合理的管控，降低產品測試風險。相對於有文件的需求分析，無文件需要更多的是聽與記和集中的頭腦風暴。有如下幾個有效方式：

~。開會討論產品邏輯：參與人員最好包含非技術人員，這樣才能最大可能的從普通使用者的角度發現產品使用上的“彆扭”

~。合理設想異常情況：只有包含了足夠的異常情況，產品產能夠穩定。但要注意合理

~。並不是“老大”說的就一點是對的：只有不斷的懷疑，才能不斷的發現。

所有的需求分析都一定要有文件進行輸出，只有文件才能有效的記錄整個需求分析中的點滴，完善自己對於產品的理解。並且文件的輸出並不是團隊中一個人去完成的，每個人都應該有一份自己的需求文件輸出。一是：鍛鍊團隊的文件的輸出能力，二是：有效的整合每個人的不同理解與角度，三是：有效的增強會議的嚴肅性團隊的積極性。

文件中的測試點需要進行各級分類，建議使用腦圖進行書寫，有效且直觀。一般一個需求模組為一個檔案。等級規劃如下：中心》》模組》》分類》單獨測試點》》說明，其中可以進行備註及優先順序的劃分

2.用例設計

作為測試的基本功，大家第一時間就會想到：等價類，邊界值，流程圖等等。如何合理的使用以上方法對測試點進行完整的覆蓋。這就是一個設計過程，他是一個需要構圖及創作的過程。測試用例用作自己團隊及第三方進行測試工作的指導書。

怎麼才能讓用例看起來簡潔明瞭。咱們首先重視的應該是用例的標題，相信大家每次看新聞的時候第一眼看的也是標題，眼就能知道這個新聞說的是什麼是什麼型別的。同樣測試 用例也是一樣，測試標題應該有如下幾個組成部分：需求+入口+前提+加操作+其他。              格式為：“【需求】入口-前提-操作/其他”。如：【登入優化】QQ賬號登入-檢測到多個QQ登入-點選QQ賬號登入/選擇第一個

第二就是前提條件：通過編號進行不同型別的備註就好。如：1.有網/網路穩定；2.QQ瀏覽器；3.同裝置中有3個QQ賬號登入

第三用例步驟：步驟描述需要清晰，每一步都要“在什麼地方怎麼操作”讓每一個操作描述都是唯一的，以免操作錯誤對測試結果造成影響

第四預期結果：每個結果都需要對應一個操作步驟，但不是每個步驟都需要結果。我們需要註明的只有我們關心的預期

第五用例等級：等級分類三級“高，中，低”。高：對應基礎功能，中：異常操作，低：不變文案及非主要UI

第六點也是設計部分的重點部分“用例分類”：這個包含我們設計用例的的方法，就是前文中提到的：等價類，邊界值，流程圖等等。一般我們將基礎操作流程定為“基礎用例”；主流程之外的分支流程為“分支用例”；之後就是基礎設計方式“等價類”“邊界值”等按照實際情況進行劃分；還有就是“異常操作”如切後臺，斷網，殺程序等，還有一點也是在測試點升級的一個點“探索類”，下面會重點進行一下說明。

為什麼要講探索測試提出來進行強調說明，是因為這不僅是一種測試方法。更多的應該是一種測試的思維技術，它沒有繁瑣的測試歸類及手段。更多的是強調了測試人員的主觀性，在碰到問題時及時改變測試策略。下面我也僅對探索測試進行一個整理和歸類：

探索測試之“乖孩子法”：也就是針對測試點進行覆蓋。
       探索測試之“壞孩紙法”：輸入錯誤內容，錯誤順序操作等

探索測試之“買一送一法”：如“同一使用者操作該內容”和“不同使用者操作該內容” 等

探索測試之“強迫症法”：反覆進行一項操作

探索測試之“懶惰法”：什麼都不選就確定，什麼都不輸入就確定等

探索測試之“搗蛋法”：環境破壞（網路，操作，外界干擾，小記憶體裝置）資料破壞，許可權破壞等

探索測試之“反悔法”：正在執行停止它，正在下載停止它，正在查詢停止它等

探索測試之“極限法”數值調整到最大或最下，網路1Kb，執行幾天幾夜，低記憶體下執行

一，  測試用例的管理
            隨著應用程式的不斷迭代我們會發現，其實有很多用例是需需要清理的。但是在實際工作中最讓人頭痛的就是用了的合併了，為了能夠在測試工作中減少用例管理工作，一般都會借用一些第三方管理工具進行管理。這裡就不對第三方的管理工具進行說明了，下面主要是對管理的思路進行一個整理。

      在管理目錄中應該是存在兩級目錄的：1.全量用例管理；2.歷史用例管理。在全量用例中我們將用例按照功能模組進行劃分；歷史用例管理中我們主要對不同版本新編寫的用例進行管理（這樣是為了保留測試思路及做總結時可以參考的點）

       1.新版本用例編寫：僅對新需求設計及關聯的相關功能模組進行用例的重新書寫
              2.新版本用例存檔：將新的有效用例存檔到歷史用例管理目錄中

        3.新版本用例合併：將新版本用例合併到全量用例中，切記幾點原則：無效用例清除；重複用例直接進行替換；部修改任何歷史用例；涉及多個模組執行重複（命名上進行區別）
            在使用第三方工具進行用例管理的同時，建議保留傳統表格方式進行用例管理：一般第三方工具都僅對用例執行進行了有效的設計，管理方面都會偏弱。