之五：用户故事树与测试用例/测试结果的关系，总结
陈勇-创业-北京(139107533) 13:59:44
注意看还是刚才那个故事树，右边是他们对应的测试用例。
红边黄底的是危险测试（不能在我们本机上运行的，会跑坏数据库）；白边黄底的是有用例无结果的测试用例
等等，未来还会做更多对应。
但核心内容很简单：
所以，测试必须依据产品功能树来展开，而不是依据凭空产生的测试用例展开。
Tyler-PM-苏州(**025749) 13:58:45
可以统计测试覆盖率吗？
【提示：此用户正在使用Q+ Web：http://w.qq.com/】
不过从上面的图可以清晰看出：有些故事还没有测试用例
鼠标放到测试用例上面，就能知道测试用例测什么，如果你觉得测得不够，就在旁边再加上一个。
总之，测试用例是围绕用户故事树展开的，而不是凭空生成的。
下面说说测试
以往的时候，测试用例基本上是基于测试人员的理解分条目写出来的。那这些条目和用户故事什么关系呢？
这个是我们现在基于用户故事管理测试用例的界面：
以往的时候，测试用例基本上是基于测试人员的理解分条目写出来的。那这些条目和用户故事什么关系呢？
这个是我们现在基于用户故事管理测试用例的界面：
注意看还是刚才那个故事树，右边是他们对应的测试用例。
红边黄底的是危险测试（不能在我们本机上运行的，会跑坏数据库）；白边黄底的是有用例无结果的测试用例
等等，未来还会做更多对应。
但核心内容很简单：
真正的测试经理，不应该关心：我有多少测试用例，测了多少，没测多少，测试通过率多少，缺陷率多少……这些纯测试问题，而是应该和产品经理、高层经理关心相同的问题：
我们产品中哪些功能中还有缺陷，我们依据什么知道这些缺陷的（是否设计了足够多的测试用例），最近哪些功能没有测试通过，他们影响我最近要发布的产品吗……所以，测试必须依据产品功能树来展开，而不是依据凭空产生的测试用例展开。
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. 测试用例，应该基于用户故事树编写；测试结果，应该基于用户故事树呈现。才能有利于产品经理/高层作出质量相关的决策。
好，今天大致到此为止。回顾一下：
1. 若引入故事树和业务数据-业务操作的概念（请参考前两期对这两者的定义），则MVC中的Area/Controller/Action和OO/UML中的NameSpace/Class/Method可以解决很大一部分设计问题。
2. 进而解决需求和编码的对应问题。
3. 测试用例，应该基于用户故事树编写；测试结果，应该基于用户故事树呈现。才能有利于产品经理/高层作出质量相关的决策。
陈勇-创业-北京(**9107533) 14:05:55
程序员之所以被认为很“苦逼”，原因是我们要写太多的互不相干的文档，来“帮助”我们写代码。我未来的想法是：
如果能有一种尽量简化，而又不失去核心价值的方法，一次性简单地把文档写完。
在MUP中，这些核心价值包括：
1. 早期做报价和估算 2. 大量需求的结构化管理 3. 代码的整体架构和分布 4. 测试与需求的关系
本文转自火星人陈勇 51CTO博客，原文链接:http://blog.51cto.com/cheny/1101552
