一期：活動描述，之一，之二，之三，之四，之五

二期：活動描述，之一，之二，之三，之四，之五，之六

三期：活動描述，之一，之二，之三，之四，之五

之五：使用者故事樹與測試用例/測試結果的關係，總結

陳勇-創業-北京(139107533) 13:59:44
下面說說測試
以往的時候，測試用例基本上是基於測試人員的理解分條目寫出來的。那這些條目和使用者故事什麼關係呢？
這個是我們現在基於使用者故事管理測試用例的介面：
注意看還是剛才那個故事樹，右邊是他們對應的測試用例。
紅邊黃底的是危險測試（不能在我們本機上執行的，會跑壞資料庫）；白邊黃底的是有用例無結果的測試用例
等等，未來還會做更多對應。
但核心內容很簡單：真正的測試經理，不應該關心：我有多少測試用例，測了多少，沒測多少，測試通過率多少，缺陷率多少……這些純測試問題，而是應該和產品經理、高層經理關心相同的問題： 我們產品中哪些功能中還有缺陷，我們依據什麼知道這些缺陷的（是否設計了足夠多的測試用例），最近哪些功能沒有測試通過，他們影響我最近要釋出的產品嗎……
所以，測試必須依據產品功能樹來展開，而不是依據憑空產生的測試用例展開。

Tyler-PM-蘇州(**025749) 13:58:45
可以統計測試覆蓋率嗎？
【提示：此使用者正在使用Q+ Web：http://w.qq.com/】陳勇-創業-北京(139107533) 14:00:14@Tyler：現在還不直接提供這個功能。
不過從上面的圖可以清晰看出：有些故事還沒有測試用例
滑鼠放到測試用例上面，就能知道測試用例測什麼，如果你覺得測得不夠，就在旁邊再加上一個。
總之，測試用例是圍繞使用者故事樹展開的，而不是憑空生成的。

總結

陳勇-創業-北京(**9107533) 14:01:59
好，今天大致到此為止。回顧一下：
1. 若引入故事樹和業務資料-業務操作的概念（請參考前兩期對這兩者的定義），則MVC中的Area/Controller/Action和OO/UML中的NameSpace/Class/Method可以解決很大一部分設計問題。
2. 進而解決需求和編碼的對應問題。
3. 測試用例，應該基於使用者故事樹編寫；測試結果，應該基於使用者故事樹呈現。才能有利於產品經理/高層作出質量相關的決策。 

陳勇-創業-北京(**9107533) 14:05:55 
程式設計師之所以被認為很“苦逼”，原因是我們要寫太多的互不相干的文件，來“幫助”我們寫程式碼。我未來的想法是： 
如果能有一種儘量簡化，而又不失去核心價值的方法，一次性簡單地把文件寫完。 
在MUP中，這些核心價值包括： 
1. 早期做報價和估算 2. 大量需求的結構化管理 3. 程式碼的整體架構和分佈 4. 測試與需求的關係 

注：好像迭代計劃的事情沒說，日後再說吧，我會寫個部落格單獨說一下，和這個的關係有，但沒有今天說的這些內容這麼深。