1、这个测试团队遇到什么了？

　　让我们来听听系统功能测试负责人Commi是如何谈论他们的工作的。

　　“这几年做了几个项目，每个项目都是在不断的迭代版本中一轮又一轮地执行用例，特别是到了最后版本将要发布阶段，每新增一个需求，即便这个需求很小，由于担心会出问题，于是放大测试范围，把所有认为相关的用例重新进行测试。这样反复折腾N遍后， 版本终于发布交付给用户了。本来信心满满，可是事情往往并非如你预想的那么美好。每个项目出去后，后续总能收到或多或少的问题反馈”。

　　Commi继续说：“到底我们的问题出在哪里？通过对反馈问题的分析，这些问题大部份都是属没有相关的用例覆盖到，当然用例的路径并非很单纯。是否可通过一种方式，执行过的用例所覆盖到的代码一清二楚，再分析未覆盖到的代码，不就可以找到测试遗漏的路径了吗？但是关于代码覆盖率，通常应用在单元测试中，没听说过可通过系统功能测试得到代码覆盖率进行分析的。”

　　Commi提到的场景，相信很多测试朋友都似曾相识，那么他提到的方案是否可以解决所遇到的问题呢？代码覆盖率又到底可以告诉我们什么呢？带着这些问题我们继续往下看。

　　2、测试覆盖的分类与意义

　　在软件领域，提到代码覆盖率，大家很自然地会联想到语句覆盖、条件覆盖、条件组合覆盖等逻辑覆盖方法。

　　实际上，测试覆盖的范围更大，它包括需求覆盖与代码覆盖，而语句覆盖、判定覆盖（分支覆盖）、条件覆盖、分支—条件覆盖、路径覆盖共六种，都属于代码覆盖的范畴，见图1所示：

图1

　　3、需求覆盖

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

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

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

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

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

表1