熟悉測試理論的人都知道，路徑覆蓋是白盒測試中一種很重要的方法，廣泛應用於單元測試。那麼基於路徑覆蓋的分析方法是不是只能應用於單元測試呢，能不能將其推而廣之呢。一般而言，在單元測試中，路徑就是指函式**的某個分支，而實際上如果我們將軟體系統的某個流程也看成路徑的話，我們將可以嘗試著用路徑分析的方法來設計測試用例。採用路徑分析的方法設計測試用例有兩點好處：一是降低了測試用例設計的難度，只要搞清了各種流程，就可以設計出高質量的測試用例來，而不用太多測試方面的經驗；二是在測試時間較緊的情況下，可以有的放矢的選擇測試用例，而不用完全根據經驗來取捨。下面就具體的介紹一下如何用路徑分析的方法編寫測試用例。
首先是將系統執行過程中所涉及到的各種流程圖表化，可以先從最基本的流程入手，將流程抽象成為不同功能的順序執行。在最基本流程的基礎上再去考慮次要或者異常的流程，這樣將各種流程逐漸細化，這樣既可以逐漸加深對流程的理解，還可以將各個看似孤立的流程關聯起來。完成所有流程的圖表化後就完成了所有路徑的設定。
找出了所有的路徑，下面的工作就是給每條路徑設定優先順序，這樣在測試時就可以先測優先順序高的，再測優先順序低的，在時間緊迫的情況下甚至可以考慮忽略一些低優先順序的路徑。優先順序根據兩個原則來選取：一是路徑使用的頻率，使用越頻繁的優先順序越高；二是路徑的重要程度，如果失敗對系統影響越大的優先順序越高。將根據兩個原則所分別得到的優先順序相加就得到了整個路徑的優先順序。根據優先順序的排序就可以更有針對性的進行測試。
為每條路徑設定好優先順序後，接下來的工作就是為每條路徑選取測試資料，構造測試用例。一條路徑可以對應多個測試用例，在選取測試資料時，可以充分利用邊界值選取等方法，通過**將各種測試資料的輸入輸出對應起來，這樣就完成了測試用例的設計。
對於測試人員而言，測試用例的設計是一件非常困難的工作，而同時測試用例的設計好壞又直接關係到整個系統的設計質量。本文介紹了一種更理論化的設計方法來盡量簡化這種工作，將一般應用於單元測試的路徑分析方法推廣到整合測試、系統測試等後續測試過程中，希望能給大家一點啟示。我會將自己嘗試過的一些感受以及具體例子跟在本貼之後。
如果想讓本方法很好的用在實際的工作中,那麼流程就必須明確的規範的（就是有畫出相應業務或者功能走向圖）,這樣就可以極大的加快了用例編寫的速度和質量，但是如果碰到沒有明確流程圖的時候，可能會花不少的時間去捉摸功能點的流程走向問題，這又讓工作進度慢了下來（流程不明確是因為需求沒有明確表述和設計沒有相應流程描述）,所以在實際工作中想使用這種方法來加快和改進測試用例的進度和質量，還要說服專案組盡可能的規範需求和設計的文件規範性，畢竟軟體質量的控制不是我們一組人就能做到的。
拿到這個流程時，第一眼看上去，是不是有點暈暈的呢，確實如此，因為這不能稱為標準的流程圖，我們需要做一些改進，不妨事先約定，畫流程圖時，在有判定條件處，就往下走，而就往左走，以下是簡化後的流程：
上面這個流程圖看上去是不是清晰很多,確實如此,從心理學的角度來講,正常人的思維是很難接受乙個橫向很複雜的事物。而且上面的流程圖也更規範一點,所以建議大家以後這樣畫流程圖。下圖是作進一步的改進:這個流程圖是不是更方便你設計用例呢,尤其是用路徑分析法,是不是很方便就能找出其中的路徑。
這個流程圖是不是更方便你設計用例呢！尤其是用路徑分析法,是不是很方便就能找出其中的路徑。
用路徑分析法來編寫測試用例
熟悉 測試理論的人都知道，路徑覆蓋是 白盒測試中一種很重要的方法，廣泛應用於 單元測試。那麼基於路徑覆蓋的分析方法是不是只能應用於單元測試呢，能不能將其推而廣之呢。一般而言，在單元測試中，路徑就是指函式 的某個分支，而實際上如果我們將軟體系統的某個流程也看成路徑的話，我們將可以嘗試著用路徑分析的方法...
測試用例設計 邊界值分析法
我們在進行軟體測試之前，為了能夠邏輯清晰的 更好的沒有重複的去執行測試，所以會編寫測試用例。在測試用例編寫好之後，可以直接按照測試用例來進行測試。那我們用來設計測試用例的方法有很多種，邊界值分析法就是裡面最常見的一種。因為我們發現大部分的錯誤是發生在輸入輸出資料範圍的邊界上，所以我們採用邊界值分析法...
測試用例設計 邊界值分析法
在前面的測試用例設計 等價類劃分法中，我們使用等價類劃分法給兩位數加法器設計了測試用例，但在測試過程中我們發現了乙個問題。為什麼我們用等價類法設計的測試用例沒有發現這個問題呢？檢視一下 發現程式設計師粗心，邊界條件設定錯誤了。無數的測試實踐表明，大量的故障往往發生在輸入定義域或輸出值域的邊界上，而不...