閱讀本文大概需要 5 分鐘。
經過近一個月的反複宣講，以及通過用例評審反複和大家溝通意見建議，我們用思維導圖寫測試點的格式已經基本固定了下來。
基礎的内容，請回看前兩篇文章：
《思維導圖編寫測試用例的兩種格式》
《用思維導圖寫測試點的幾點說明》
今天是在這些内容基礎上的再補充。
1.表示層和邏輯層測試目的的區分
表示層測試點的測試目的應該是針對業務邏輯的覆寫，是以表示層測試點的描述，可能會被誤以為是需求的描述，其實不一樣，需求隻是描述業務的展現形式，測試點是要驗證産品滿足了要求的展現形式，并且在驗證時，我們把需求進行了顆粒度的拆分，逐點進行驗證。
邏輯層測試點的測試目的應該是針對實作邏輯的覆寫，是以邏輯層測試點的描述，都應該是邏輯實作本身，隻是某些情況，無法通過針對性的邏輯結果來确認測試結果，我們就會用表示層的現象來間接證明，一般不建議這麼做，但如果隻能這樣，那就特殊說明下，畢竟針對同一個業務邏輯，表示層和邏輯層測試點的操作步驟幾乎是一樣的，隻是關注點不同。
這麼說起來比較抽象，我還是拿個例子來說吧。
需求：有一個程式，在自己退出時，會把自己的啟動時間通過 http 打點上報給服務端。
針對這個需求，如果是表示層的用例，隻需要下面兩條就夠了：
但是，經過和開發詳細溝通後發現，他們的實作邏輯是這樣的：
程式在啟動時，把啟動時間記錄在一個本地檔案中，程式退出時會從本地檔案中讀取啟動時間，并且進行 http 打點。
知道這個邏輯後，我們可以補充相應的邏輯層測試點如下：
和前面的測試點對比，能看出來差異吧？第一種測試點隻關注業務，第二種測試點同時也關注了實作。
也許有人會說我給的例子不恰當，沒有人會這麼去實作，嗯，意會下就行了，主要的意思是，針對業務的表示層和針對實作的邏輯層，我們都應該有對應角度的測試點去覆寫，這也是我們早前說的
測試深度
，至于深度要挖到什麼程度，請根據自己項目特點合理判斷。
從例子中我們還能看出來前面說的，邏輯層的測試點，實際的用例執行步驟和表示層是一樣的，隻是關注點不同，我們去區分表示層和邏輯層，隻是借助這個概念去讓我們知道，需要去關注哪些内容，是以在某些情況下，不要過分糾結一個測試點屬于表示層還是邏輯層，隻要能滿足預期的覆寫度就行了。
2.驗證沒有少做事，也要驗證沒有做多餘的事
繼續上面的例子，不管是表示層還是邏輯層的測試點，絕大部分都是在驗證程式沒有少做事，這是我們主要的測試目的之一。
我們的另一個測試目的是「驗證程式沒有做多餘的事」，比如我們看到邏輯層驗證有一個測試點是「驗證本地檔案被占用時，程式直接傳回不做任何處理」，這屬于異常處理的一種，但是需求中并沒有明确要求應該怎麼做，是以可能會有開發實作為「檔案被占用，就換個檔案名建立」，反正不會抛出異常就可以。
碰到這種情況，一定記得要同開發、産品三方溝通确認預期。
關于這點，還有一個類似的情況，比如在程式的設定項中勾選一項設定，理論上程式隻需要調用修改系統資料庫值的函數，把對應系統資料庫值做個修改即可，但是有些開發圖省事，打開設定時，讀取一下所有設定項的值，關閉設定時，按照目前設定值全部重寫一遍。
從表示層看功能符合預期，從邏輯層看沒有少做事，但是增加了不必要的開銷，做了多餘的事。
3.分類是為了條理更清晰，不要在分類标準的選取上糾結
上面例子中的邏輯層測試點，我們寫了 10 條，放在一個節點上已經顯得有點多，這時候就可以把測試點做個分類。
比如下圖，是我按照本地檔案的寫入和讀取分成兩類：
這樣看起來是不是清晰了很多？主要是測試目的會清晰，當然有同學會問，我換個分類标準行不行？必須行呀，如下圖，是我按照程式啟動和退出也分成了兩類：
看，沒啥差別，
分類是為了讓衆多測試點更清晰易懂，最後面的測試點才是重點
，針對本次測試點，甚至還可以按檔案操作和打點操作分，還可以按正常情況和異常情況分等等。
總之，不要在分類标準選取上糾結，原則就是提取合适的公共屬性，讓整個測試點看起來更清晰即可。
4.維持平衡，不要鑽牛角尖
不要在表示層和邏輯層的劃分上鑽牛角尖，你完全可以取一個自己喜歡的名稱，也完全可以不區分這個層級，隻要有辦法保證測試點的覆寫度即可。
不要在邏輯深度的挖掘上鑽牛角尖，理論上我們能挖多深就挖多深，發現深層次的實作問題，肯定更有成就感，但一定要基于項目的現狀和需要去平衡投入産出比。
不要在需求/邏輯/實作是否對錯上鑽牛角尖，一切都是為了産品服務，測試目的當然也是，是以适合的就是最好的。
不要在分類條件的選取上鑽牛角尖，如果選不出來概括性完美的分類标準，也可以不分類，或者選一個能概括大部分測試點的分類條件即可，時間要花在刀刃上。
以上，我基于目前實踐的現狀，總結了思維導圖寫測試點的額外關注點，不知道你是否認同，或者有啥額外補充。歡迎留言說說你的想法。