<如何編寫有效測試用例>這本書里面有很多概念很不錯,每讀一遍都有收獲.下面從what 和how講一下這本書關於編寫測試用例的那些好的觀點
什么是好的測試用例？(what)
一、 多寫海平面以上的用例
海平面以上的用例,是指多從用戶的意圖出發去編寫用例,而不是拘泥於某個用戶操作界面。這里書中寫了個小技巧：每次編寫用例可以多問自己，執行者執行完此用例可以達到什么目的。判斷的標准可以是以下
1、執行者執行完一次用例可以愉快離開
2、 執行者(雇員)多次執行這一用例可以加薪
3 、一個人在一個地方執行2-20分鍾的操作
二、 有考慮項目相關人員的利益
什么是項目相關人員？常見的有客戶,操作這個系統的主要執行者(雇員) ,還有經常漏掉的雇員的老板。其實老板的權限應該比雇員高,不僅能有雇員的操作權限,還有更高一級。只有老板才能解鎖的權限。常見的項目相關人員及利益有以下:
1 、公司的利益：保證主執行者不能免費得到某些利益，或得為他所得付費
2 、管理部門利益：確保公司能夠遵循一定的准則，然后保存某種類型的數據
3 、項目相關人員的典型利益：從事務失敗恢復機制收益，需要更多記錄。
三、.用例的合理划分
用例長度:一般用例的長度一般在5～9個步驟比較合適，如果長度過短就要考慮用例的層次是否過低，那就要多問自己用戶的意圖，以此來獲得更高層次的用例。如果用例過長就要考慮是否步驟划分太細小，這個時候就可以考慮將一些步驟進行合並。
用例的擴展:一般把失敗的步驟都寫在這里,方便維護
基用例和子用例:適當使用基用例和子用例可以讓文檔更精簡和清晰,可以使用超鏈接鏈接起來
如用戶尋找一件失物,這里可以鏈接到子用例.
四、 關於條形褲
用例無論有多少場景，總共有只有兩種結局：成功和失敗，而走向成功和失敗有很多場景和路徑，殊途同歸，就像條形褲一樣。
五、 良好的用例編寫格式
好的用例編寫語言習慣：
1 使用簡單語法（不要遺漏了主語）：
主+謂+賓+前置短語 eg： 系統...從用戶余額中扣除...一定數量
2 明確寫出“誰控制球”
在同一個場景使用相同的結構，執行者就像球員，是主語，而球是執行者和執行者傳遞的信息或數據。
3、從俯視的角度來編寫用例
為了避免出現從系統內部去看待世界這種思維定式，可以學會用俯視角度來編寫用例，像編劇描寫一部劇一樣。
比如
用戶：插入ATM卡並輸入PIN
系統：從用戶金額扣除一定數量
4、顯示過程向前推移
可以將一些由同個執行者執行又處於同個方向操作步驟小的操作（靛青色的用例）進行合並，避免用例文檔過長的情況
5、顯示執行者的意圖而不是動作
6、包含合理的活動集
7、“確認而不是檢查是否”
“確認”這個動詞比“檢查是否“更能體現過程更進一步的過程和系統的意圖。
8、可選擇地提及時間限制
大多數的用戶步驟都是緊跟上一步，但是有時候也會這么寫
在步驟3和步驟5的任何時候，用戶將......
9 習慣用語“用戶讓系統A和系統B交互”
笨拙的寫法：用戶通知系統B獲取數據
系統B從系統獲取數據
好的寫法：用戶命令系統B從系統獲取數據（體現了誰控制球）
10 習慣用語：循環執行步驟X到步驟Y，直到條件滿足
為了讓場景容易閱讀，可以把循環重復步驟放在步驟的后面
eg 1、顧客提供賬號名字或地址
2、系統查出用戶的愛好
3、用戶選擇一個商品，並做一個購買標記
4、系統把用戶選購的商品放入購物車
顧客 重復步驟3~4，直到顧客選購完所有的商品
5 顧客購買完購物車的商品
六、關於用例的擴展
擴展條件就是在一些條件下系統會完成不同的動作，之所以用擴展，是因為有失敗和成功兩種情況。
用“檢測到什么”來編寫條件，不要寫什么顧客忘記密碼，系統是不可能發現顧客忘記密碼，系統只能檢測到等待時間超出了限制，應該這樣寫，系統檢測到用戶輸入密碼等待時間超出限制。
如果使用編號，可以在編號后面加上字母，像2a 2b什么的
我們可以采用一個簡單簡短的主成功場景和一個擴展列表，為了避免列表過長，可以采用以下方法
1、刪除多余的條件，按照以下兩個標准，判斷哪些不符合以下標准的條件便可以刪除。
a 系統能檢測到條件
b 系統必須完成的檢測的條件
2、可以合並對系統來說等價的條件，可以合並一些低層次的失敗用例。
3、擴展用例常見的有調用子用例和基用例的擴展。
判斷是用子用例還是基用例的擴展可以采用以下標准判定。
如果觸發條件包括了基用例應負責的事件：即基用例知道什么時候/在什么地方調用第二個用例，應該采用調用子用例的方式
如果觸發條件包括了第二個用例應負責的事件：即第二個用例知道什么時候/在什么地方調用第二個用例，采用擴展基用例的方式
4、盡量不要用擴展用例，后期維護比較麻煩。
下面是關於如何編寫有效測試用例的一些干貨(how)
1 、 每個用例都是一篇散文
2 、使用用例易於閱讀，可以按照以下一些技巧來達到這個目的
a 讓用例短小，切題
b 從頭開始，以一條主線貫穿始終，頂部是對全局有重要意義的用例，並分離出用戶用例和最終子用例
c 用動詞短語來編寫用例，這些動詞表明了這些用例想要達到的目的
d 從觸發條件開始一直繼續，直到目標被實現或取消，並且系統完成與這次事務處理相關的記錄的保存
e 用完整的主動語態語句來描述所要完成的子目標
f 確保每一步執行者及其意圖是可見的
g 突出失敗條件，使失敗恢復動作可讀，最好不必為每個步驟編號，人們可以清楚知道下一步要做什么
h 將可選的行為放在擴展部分而不是放在用例條件的主體語句中
i 只有在非常必要的情況下擴展用例
3 僅用一種句型，主用例和擴展可以用不同語法格式用於區分
主用例格式： a 現在時態語句
b 在主動語態用主動動詞
c 描述執行者成功到達某個目標，這個目標推動了整個過程的前進
擴展格式： a 采用過去時態
b 采用句子片段而不是完整句子
c 用冒號結束而不是句號結束
4、 包含子用例
5 、誰控制球
6 、正確得到目標層（更高層次、海平面以上）
7 、不考慮GUI界面（避免寫死后后面一旦更改給維護帶來負擔）
8 、兩個結果：成功和失敗
9 、項目相關人員需要的保證（利益、最小成功保證）
10 、前置條件
11 、對用例的通過和失敗進行測試
關於<編寫有效測試用例>這本書的一些表也值得推薦，在文中的P97的11章
輸入輸出表
系統設計范圍表
用戶目標級別表
書里還介紹的一種很特別的方法，對於前期寫用例能夠更好地提供思路：寫故事
給自己的用戶寫幾個故事，往往會有意想不到的效果。
最后是日常工作的時候,我領悟到的一些方法
1 前期梳理業務:思維導圖
所需要的工具非常簡單：一只筆,一張白紙。
可以按照主成功場景,寫執行者執行步驟,.畫一個路徑圖,注明下一步的出發條件,開啟分支則注明分支條件,對於前期梳理業務非常有幫助。
2 編寫文檔時,可以先寫主成功場景,寫完后,在擴展這一下失敗場景,不容易亂
前期以主成功的業務場景為主，不要把自己過多陷入各種失敗場景中，只會把自己繞暈。最好的方式是先把業務關系梳理清楚再去擴展失敗的場景豐富用例。
3、多寫海平面以上的例子，這也是書中一直強調，這有個好處，就是既可以精簡用例，又可以在閱讀用例的時候留下想象的空間，更好地去提問，去發現問題，而底層用例不僅用例多而且不利於思考。
4、借鑒文中的編寫格式,可以更好維護測試文檔。尤其在需求變更很快的情況下,可以更好地應對。