需求覆盖的度量与方法

 需求覆盖，指测试用例对需求的1：1，或1：N的对应索引关系，是测试用例覆盖需求程度的一种度量方式。由于需求有粗细之分，常见的如一级需求、二级需求、三级需求，指的就是需求的粒度。用例对需求的覆盖度，目前有一些文档管理工具可自动建立它们之间的索引对应关系，如doors,testlink，也可采用excel人工建立体现覆盖情况的追溯关系表。由于文字描述的需求层次划分的主观性较强，度量本身难于精确化。

对于需求覆盖与软件质量的关系，我们可以问一个这样的问题，需求覆盖率达到了100%，就表示所有需求点都有测试用例对应了吗，回答这一点，我想是很容易的。因为在过去的经历中，测试需求总会大于软件需求，如软件对异常情况，边界值的处理（有些需求是来自设计的限制）。需求一般不会描述如此详细，往往会出现有些用例没有需求对应，或者说用例对需求的覆盖可达120%，甚至150%的覆盖，但就能说明软件质量可靠、稳定吗。只能说用户需求确认已实现，测试的程度（全面性）如何，只能是在一个较低要求的层次上回答了这个问题，就好象是解决了温饱问题。再具体一点，例如，张A问李B，“李B，你吃了饭吗？”，李B回答说：“吃了”，那么说用例对需求的覆盖达到了100%，意思就好比此场景的回答。至于李B吃的什么，有哪些菜，有哪些配料组成，它们是如何搭配的，营养结构是否全面、合理，是否影响身体健康。回答这个问题，犹同回答测试全面性与充分性的问题。

我们都清楚，在软件生命周期中需求经常会发生变化，需求测试对于测试来说是一个不可忽视的阶段，它同软件设计一样，是一个迭代的过程。那么需求覆盖是对需求测试的一种反馈，但绝对又不止这些，需求测试在实际工作可以如何开展，有哪些注意问题，有兴趣的读者可以参阅我的<<软测之魂—核心测试设计精解>>第八章的需求测试部分（http://product.china-pub.com/197462）

下面就需求覆盖的追溯方法与大家分享下个人的一些体会：

  下图是以用例为主线(逆向追溯），设计的每一条用例依据都是需求，用例与需求的对应关系体现出一对一，一对多的关系。

另一种方法是以需求为主线（正向追溯），从需求出发，检查每一需求是否有对应的用例，从而确定对需求的覆盖是否达到了100%。下图是以需求为主线的需求与用例索引矩阵图。

 优点是什么呢？需求点明确，可以保证每一需求点都有测试用例与之对应。不象用例为主线的方法，把用例对应的需求点分散在不同的地方，如果有小需求点漏了，也不足为怪哦。

无论以用例为主线，还是以需求为主线，建立需求与用例的追溯表，有一个问题很容易暴露出来。细心读者也许你已注意到，用例T1.5怎么没有需求与之对应呢？紧扣需求设计用例本身是没错。如果只看需求，不关心系统的设计或其他相关模块的需求，会使我们陷入只看到局部的需求，以为只要覆盖了需求说明书中的点，即达到了100%覆盖。而实际上，一个软件系统，由若干模块组成，模块与模块之间会存在一些藕合关系。或者有人会认为模块与模块之间接口关系不是集成测试关心的吗？没错，集成测试是要关心，但也没有说系统测试不要关心。到后期系统测试阶段，随着需求的变更，模块之间的接口可能会发生变化，如一些全局数据结构，全局变量等。这样，在系统测试阶段关心模块间的接口显得必不可少。