使用功能點估算模型評估軟件測試的工作量(2)

　　在導入twork以后，會在邏輯事務的測試集下，產生一個叫做“買家狀態”的測試集，這些枚舉值將變成輸入條件，而后面的輸出結果，將變成期望結果。如下圖：

　　還有一種輸入項，比如頁面表單的輸入框，會產生一堆輸出：“不能為空”“不能超過20字符”等等，在設計圖中，我們可以把這一堆輸出，直接掛在輸入項下面，這樣，也會產生一組用例，也就是我們常說的頁面校驗。

　　上面所說的，是輸出和輸入緊密關聯的情況，產生的用例比較簡單。除此以外還會出現更復雜的情況，當多個輸入組合在一起的時候，才會產生一定的輸出。這時，就需要把這些有邏輯關系的輸入組織起來，在設計圖里單獨建一個node，注意這個node上不要標記Input，因為它不是一個輸入項，而只是一個分組。真正的輸入項在下面。如下圖：

　　根據這一部分的設計，會生成一組比較復雜的用例，每個輸入項，會成為一列，這里有4個，就是4列，另外再加1列“期望結果”。這是twork中一種新的用例編寫模式，叫做測試數據驅動模式(tdirector/" target="_blank" >testdirector/" target="_blank" >TD驅動)，看起來眼熟，其實就是“判定表”，我們以前用Excel寫用例的時候，就是這么寫的，現在在twork中，更進了一步，用戶可以隨意定義每個測試集的列，而每一行，也作為一個用例對象，保存在數據庫里。如下圖：

　　需要說明的是，這種復雜的組合，程序是無法自動生成用例的，因為要完全排列組合的話，用例太多，不靠譜，而且具體的組合情況，跟需求有很強的關系，程序更是難以了解。程序能做的是，生成用例表格結構，同時創建一些空白的用例，然后我們自己在里面填一下值就可以了，寫用例速度快，而且用例非常直觀。

　　大家注意到了，在設計圖中，輸入、輸出、實體我們都用不同的標記給標識出來，這樣導入twork時，程序便會自動算出每個邏輯事務的功能點指數分值，非常方便，所以文章開頭說，這個指數計算，只是一個副產品。

　　通過上面的分析過程我們可以看出，功能點分析圖與測試用例之間，存在非常緊密的邏輯關系，之前幾篇文章我們也講到，功能點分析是一種非常好的分解分析需求的手段。通過這張分析圖，讀者可以迅速了解設計者的思路，以及了解每個邏輯事務大致的邏輯。這時如果需要看細節，可以進入twork，很快找到這個邏輯事務的測試集，并查看下面的用例。

　　上面的例子，列舉的是Create類的邏輯事務，以及里面兩種最常見的輸入組合。Update類和Delete類事務，跟這個差不多，這里不再細講。它們的共同點在于，輸入一般較多，并且存在一些邏輯組合，而輸出，相對比較簡單。

　　至于Read類和List類事務，在設計圖會有一些區別，這兩種邏輯事務輸入相對較少，而輸出項很多，它們主要的測試重點在于，校驗頁面展示，比如“查看寶貝信息”，輸出項可能會有30個以上，這時，使用check list的方式會比較方便，并不用編寫復雜的用例，只需說明，需要校驗哪些點即可。如果Read類事務也有復雜的輸入，比如查看寶貝信息會有：寶貝類型、寶貝類目、寶貝消保類型這些輸入，那么就參考剛才Create類的方式即可。

　　總之，設計用例重點關注業務邏輯，對于展示類的事務，盡量用簡單的方式完成測試設計，至于有些一看到頁面，就知道應該怎么測試的事務，即使不寫用例，我覺得也問題不大。只要在設計圖中把這個事務的輸入輸出實體都標識清楚，我相信測試工程師就可以很好的完成測試工作。即使交給另一位工程師，只要他也了解這種設計模式，那么也可以測得很好。

原文轉自：http://www.kjueaiud.com