使用用例覆蓋需求和指導代碼實現

前情描述

這兩天和團隊小夥伴在討論關於如何使用用例描述需求的問題，通過咱們的激烈討論和大神的指點以及本身的理解，
簡單的總結一下，以備給沒有使用過用例描述需求以及使用的有疑惑的小夥伴一點思路，確定有缺陷，互聯網不就是講究迭代嗎，
相信有思考，有討論，有總結總會玩得轉的。
咱們團隊主要拿着用例作兩件事：
1.保證覆蓋全部產品的需求，拿着用例和產品去溝通。
2.保證咱們開發人員在開發的時候不用重複思考，由於咱們的用例要作到僞代碼級別。
3.自測，演示，內測，公測階段均可以參考你的用例。
多說一句，寫代碼的時候不適合思考，寫代碼就是體力活。有些小夥伴喜歡需求在寫代碼的時候去推理，每每着急動手，
到後來就會各類重寫，各類推翻。不要笑，說的就是你。
言歸正傳，下面就介紹如何編寫用例

1、寫描述

用例的兩種表達形式一種是用例圖，一種是用例描述。
這裏咱們使用的是用例描述。
描述用例的要素：
1.參與者（角色）
參與或操做(執行)該用例的角色。
2.動做（活動）
用例每每會體現一個動做，這個動做就是系統須要完成的功能。
3.目的
簡要的描述一下本用例的需求(做用和目的)。
格式大體爲：咱們一般使用這樣一個模板：「做爲一個…（角色）我但願可以…（動做）這樣我就能夠…（目的）」
好比：做爲一個網站註冊用戶（角色）我能夠在網站上張貼簡歷（動做），這樣我就可讓招聘者看到個人簡歷（目的）。

2、前置條件

就是用戶使用這個用例以前須要具有的客觀條件，不符合就不能使用這個用例。
好比：某個用例在使用以前要求用戶必須是付費的，必須登陸的，必須設置過身份證。
這些要求就是這個用例前置條件，咱們在實現這個用例的時候必須考慮到這些前置條件。

3、檢查項

檢查項是做爲咱們是否完成這個用例的尺子，因此它很重要有用例必然要有檢查項，誰也不肯意作沒有完成結點的任務。
檢查項不只從正常的狀況思考，還要從嚴謹，安全，異常的狀況去思考。
好比下面的用例：
做爲網站的註冊用戶我能夠進行網站登陸操做，這樣我就能夠作其餘的操做。
針對這個用例的檢查項：
從產品需求的維度：
1.可使用設置本身我的信息的功能。
2.能夠在頁面頭部看到用戶的部分信息如頭像，暱稱等。
從系統的維度：
1.多中角色互相訪問時會出現什麼狀況。
2.重複操做某一個功能時。
3.有順序要求的顛倒一下順序訪問時。
4.用戶重複登陸的狀況要給予提示。
5.暴力破解密碼的狀況要給予處理。
6.用戶沒有填寫正確的用戶名，密碼，驗證碼等。
7.用戶在多處登陸用一帳號要將另一個帳號強行退出。
總之檢查項能夠幫助咱們驗證咱們的用例是否完成，完整。

4、寫執行步驟：

執行步驟主要從系統角度觸發實現這個用例所須要的事情。
這一點和標準的用例有區別，標準的用例只從用戶角度描述。
咱們是從系統角度去看找執行步驟。
不論是系統仍是用戶角度都是在描述同一件事只不過是關注點不一樣。
好比：你老闆讓你給他倒一杯茶。
對於你老闆來講就是用戶，他只關心你是否可以給他倒一杯茶。
對於你來講你就是系統，你不只要知道倒茶還要考慮如何實現倒茶的細節，
你須要關心哪裏有熱水，要放什麼茶葉，溫度合適不，老闆的喜愛是濃仍是淡等等。
因此從系統的角度來描述執行步驟其實就是在描述具體的實現，甚至是僞代碼。
注意：
在抽取用例執行步驟的時候，請使用統一抽象層次（咱們抽象不超過5個的步驟）。
用例的步驟描述要到僞代碼或者原子級別，什麼是原子 ：有對象或者對象的屬性。

5、後置條件

後置條件:用例執行完畢後的結果或者狀態。
咱們將後置條件做爲了用例的檢查項。

6、分析頁面交互：

頁面上的功能能夠單獨寫一個用例，不過要做爲這個頁面的主用例的子用例。

7、預估時間

每個用例保證一到兩天可以完成，太大請拆分。
拆分的時候請注意：
保留主用例的檢查項，被拆分的用例也要有檢查項。

8、使用worktitle編寫用例

1、編寫用例描述

2、編寫前置條件

3、編寫用例檢查項

4、編寫執行步驟