關於敏捷開發中書寫Story,AC,TC的一些見解

1、前言

在現在的一些中大型軟件項目中，許多開發團隊都有本身的一套需求分析及測試步驟與方案。而在敏捷開發中也有相應的需求分析及測試方法與過程。好比：Story（用戶故事）,AC（驗收標準）,TC（測試案例） 這些就是在敏捷開發中經常使用的一些概念。

在敏捷開發團隊中，他們的需求及測試文檔大概會是下面這樣：

正如上圖所示：一個 Feature（功能）會由幾個Story組成。若Story過大，還可能會拆分紅子Story。若Story描述的比較具體，則能夠直接拆分出幾個AC。每一個AC又能夠拆分出幾個TC來做爲實際編碼與測試的準則。不管是Story,AC仍是TC，都應儘量知足這些特色：完整性，正確性，可行性，可驗證性，無歧義性，一致性，必要性，劃分優先級。

2、Story

做爲用戶故事：其描述的是用戶的需求，是功能的簡短描述，細節應該在客戶團隊和開發團隊的討論中產出。也就是說，用戶故事不是肯定不變的詳細設計說明書。
壞例子：
Story:當用戶進入首頁，他應該看到推薦職位，以便他快速找到想要的工做。
好例子：
Story:做爲一名首次使用求職軟件用戶，我想要在明顯的地方看到推薦職位，來幫助我快速找到合適的工做。
像這樣站在需求者的角度來思考問題，纔可以挖掘出真正有價值的需求。以便設計開發出符合需求的功能。

3、AC

做爲驗收標準：不是大而全的詳細設計，AC只是故事完成的必要的條件。AC的內容也只是關於關鍵或重要事情的簡短描述，是客戶或PO驗收功能的主要依據。
壞例子：
given:用戶已掛機
when:用戶再次登陸
then:提示「您的帳號已被封停」
好例子：
given:用戶掛機超過5分鐘
when:用戶再次登陸該帳號
then:在登陸界面彈出「您的帳號已被封停，15天后解封」提示彈窗
AC應當具備完整性（完整列出Story的驗收標準），正確性（應符合天然邏輯），可驗證性（能夠很方便的進行驗證），無歧義性（所使用的描述語言應儘可能嚴謹，規範，通用，標準，專業），一致性（AC或Story之間不能有邏輯衝突）。

4、TC

做爲測試案例：也是User story的一個重要補充，是AC的具體實現。TC應該比AC更加詳細，不止包括AC的全部內容，還應包括不少異常測試用例，以確保系統對異常能正確的處理。
例如： 註冊帳號時密碼應該由6到18位數字和字母組成。
壞例子：
given:用戶已在帳號輸入框輸入帳號："test123"
when:用戶在密碼輸入框輸入："abc123"
then:彈出「註冊成功」提示框，並在3S後跳轉登錄頁
好例子：
測試用例01（長度和組合條件都不知足）：
given:用戶已在帳號輸入框輸入帳號："test123"
when:用戶在密碼輸入框輸入："12345"
then:彈出「密碼必須由6-18位字母和數字組成」提示框
測試用例02（長度和組合條件都不知足）：
given:用戶已在帳號輸入框輸入帳號："test123"
when:用戶在密碼輸入框輸入："abcde"
then:彈出「密碼必須由6-18位字母和數字組成」提示框
測試用例03（長度不知足）：
given:用戶已在帳號輸入框輸入帳號："test123"
when:用戶在密碼輸入框輸入："123ab"
then:彈出「密碼必須由6-18位字母和數字組成」提示框
測試用例04（長度不知足）：
given:用戶已在帳號輸入框輸入帳號："test123"
when:用戶在密碼輸入框輸入："123456789abcdefghij"
then:彈出「密碼必須由6-18位字母和數字組成」提示框
測試用例05（組合條件不知足）：
given:用戶已在帳號輸入框輸入帳號："test123"
when:用戶在密碼輸入框輸入："123456"
then:彈出「密碼必須由6-18位字母和數字組成」提示框
測試用例06（組合條件不知足）：
given:用戶已在帳號輸入框輸入帳號："test123"
when:用戶在密碼輸入框輸入："abcdef"
then:彈出「密碼必須由6-18位字母和數字組成」提示框
測試用例07（都知足）：
given:用戶已在帳號輸入框輸入帳號："test123"
when:用戶在密碼輸入框輸入："abc123"
then:彈出「註冊成功」提示框，並在3S後跳轉登錄頁
測試用例08（都知足）：
given:用戶已在帳號輸入框輸入帳號："test123"
when:用戶在密碼輸入框輸入："abc1234"
then:彈出「註冊成功」提示框，並在3S後跳轉登錄頁
能夠看到，好的測試用例必定是很是全面的，可以覆蓋正常和異常的全部狀況，經常使用的測試覆蓋方法的覆蓋率從弱到強依次有：語句覆蓋，斷定邏輯覆蓋，條件邏輯覆蓋，判斷邏輯條件覆蓋，條件組合覆蓋，路徑覆蓋。