誰 cover 誰

Jan. 14 23:00~ 15 00:12

話說當年 Teddy 在修『軟體測試與驗證』 這門課的時候，老師曾經花了不少時間教導如何判斷測試是否足夠的條件（test adequacy criteria）。總的來講（Teddy 內心獨白：劉老師，Teddy 對不起你。內容忘的差不多了，趕快偷看一下當年的上課投影片）program based structural test adequacy criteria 可分為兩大類：

• control-flow criteria
• data-flow criteria

其中 control-flow criteria 又包含：

• statement coverage
• branch coverage
• condition  coverage
• relation coverage
• branch/condition coverage (BCC)
• compound condition coverage
• modified condition/decision coverage (MC/DC)
• path coverage

而 data-flow criteria 又包含：

• all-paths
• all-du-paths
• all-uses
• all-defs
• all-c-uses
• all-p-uses
• all-c-uses/some-p-uses
• all-p-uses/some-c-uses

正常的人類看到這邊差不多快吐了，如果你以為就只有上面這些 test adequacy criteria 那你就太單純了。所有的分類一定少不了『其他』這一類：

• function coverage
• linear code sequence and jump (LCSAJ) coverage
• call coverage
• object code branch coverage
• race coverage
• weak mutation coverage
• table coverage

套句電視模仿節目的台詞：『台灣媒體這麼多，新聞怎麼報？就亂報嘛！』...『Test adequacy criteria 這麼多，怎麼測？就亂測嘛！』當年 Teddy 聽完這一『拖拉庫』的方法之後心都涼了一半。如果是有規模且上軌道的軟體公司（很抱歉，這種公司好像大部分都不在台灣），上述方法當然是用來評估『測試是否足夠』的重要參考。但是，在寶島台灣，也許 90% 以上的軟體專案人數都在 10 人以下，更別奢望有專屬的測試團隊來協助開發人員測試軟體。所以，假設鄉民們就是這『微型開發團隊的一 元 員』，那您要如何做測試？

Agile methods 有教，要寫 unit tests，做 TDD 或是 ATDD (Acceptance Test Driven Development)。問題是，常常寫了一堆 test cases 全部都通過，此時不禁懷疑這些『測試案例的有效性（能不能真的找到 bugs）』。

除了基本的單元測試以外，另外還有一招 Teddy 覺的是滿有用的，就是當發生 bug 的時候，先寫（後寫也行啦，但是記得一定要寫）一個可以反應出該 bug 的測試案例，等修完 bug 之後這個測試案例就通過了。這樣可以確保已經發生過的 bug 萬一以後再發生的話有測試案例可以抓到它。聽起來很簡單也很有道理，不過說真的要持續做到不太容易。大體上 programmers 都會想趕快看 code 或用 trace 的方式來找出問題。一旦問題解決後，常常會懶的補測試案例。

最近 Teddy 發現，用 Robot 寫 acceptance tests 來確保功能錯誤不再發生是一個不錯的作法。開發團隊可以在每個 sprint 安排一個 story 專門為系統的某個（或某些）功能『補寫』 acceptance tests。至於要寫哪些 acceptance test cases 可以用兩個很簡單的方式：

• 如果有軟體的使用手冊，就依據手冊上面操作軟體的方法來設計 acceptance tests。
• 找出所有使用者或是自己開發軟體時所發現的 bugs，寫 acceptance tests 來確認這些 bugs 已經消失了。

Teddy 認為以上作法對於『微型開發團隊』還滿有用的。不過，要真正落實這一點，有一個先決條件，就是要建制一個『自動化測試環境』，並且要讓在這個環境中加入一個 acceptance tests 這件事變得很透明且很簡單 （這是要花時間滴）。例如，如果要開發跨平台軟體，就要考慮到如何讓這些 acceptance tests 可以『自動的』被佈署到不同的平台上測試；如果要測試 Web 應用程式的介面，則可能要熟悉類似 Selenium 這一類的工具。能夠做到這一點，要持續增加新的 acceptance test cases 就變得比較可行。

結論：空有武林秘笈，沒有弟子來練功也是白搭。

***

友藏內心獨白：與其說把這些 coverage 忘的差不多了，還不如承認當年根本沒學好...XD