在白盒測試中，基本路徑測試方法當然是最優秀的一種測試方法，根據流程圖畫出控制流圖，再畫出控制流圖的時候，我們要注意兩點
一：＆＆和｜｜組合條件需要拆開，即改成單一條件
二：關于求解路徑條數的時候，用判定點來算路徑總數是有風險的
1.else語句不存在 2.case 語句也稱為判定點，是不穩定的，舉個例子，case情況有很多且每種情況沒有其他判定，這么算來，總的路徑條數就會變少。
所以我建議大家還是使用數圈圈的個數即 N+1 或者也可以為 E-N+2 其中 E 為邊的條數，N 為結點個數，兩者的值是相等的。
?。P于case 如果把它描繪成各個判定點的話，也可以用判定點的個數+1 來進行計算得到，且由case得到的判定像是一個樓梯一樣的判定哦！?。。?/p>
三：防止犯了先驗性錯誤（極容易犯錯，導致路徑丟失）這也是我要在這邊特別強調的（本人就是在這個問題上糾結了個把個小時，終于找出來了）
為什么會有這種錯誤呢，因為我們在分析了程序之后，潛意識中把實際代碼中，邏輯相互矛盾，不可能出現的路徑給排除了?。。〉胶髞頃l現怎么總缺少一點。
從程序的環路復雜性可導出程序基本路徑集合中的獨立路徑條數，這是確定程序中每個可執行語句至少執行一次所必須的測試用例數目的上界。從這里我們也可以看出一點，并不是每條測試用例會設計出一個測試用例?。?！
這么講未必抽象了點，我來舉一個今晚我做的實驗吧，控制流圖已經畫出如下所示：
注意路徑4 為 我一直被我潛意識排除的那條！??！
因為實際中，我們在設計路徑的時候是不該考慮這種情景是否會出現的?。?！
而且 我們也可也發現，白盒測試也是很脆弱的了，若沒有 2 29 2001 本身這是不符合實際的，但若在白盒測試中沒有用到這個用例，也是無法檢測出錯誤來。所以現在業內有些人就開始發問，白盒測試是在浪費時間，它的功能完全可以用黑盒測試來取代，遺憾的是，到現在為止還沒有被證明哈！
路徑1：1-2-3-4-5-6-7-8-31-33
路徑2：1-3-4-5-6-7-8-31-33
路徑3：1-3-5-6-7-9-10-12-31-33
路徑4：1-3-5-7-8-31-33
?。ㄗ⒁猓哼@條路徑被我先驗性得排除了，以至于一直少了一條，雖然不存在，但在設計用例的時候應該要考慮進去的）
路徑5：1-3-5-7-9-10-12-31-32-33
路徑6：1-3-5-7-9-10-11-31-32-33
路徑7：1-3-5-7-13-16-31-32-33
路徑8：1-3-5-7-13-14-15-31-32-33
路徑9：1-3-5-7-17-18-19-31-32-33
路徑10：1-3-5-7-17-18-20-21-22-31-32-33
路徑11：1-3-5-7-17-18-20-21-24-31-32-33
路徑12：1-3-5-7-17-18-20-23-21-22-31-32-33
路徑13：1-3-5-7-17-18-20-23-21-24-31-32-33
路徑14：1-3-5-7-17-18-20-23-24-31-32-33
路徑15：1-3-5-7-25-26-27-28-31-32-33
路徑16：1-3-5-7-25-26-27-29-31-32-33
路徑17：1-3-5-7-25-26-30-31-32-33
