覆盖率动静美
覆盖率是用于确定测试所执行到的覆盖项的百分比。其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等。测试覆盖率可以表示出测试的充分性，在测试分析报告中可以作为量化指标的依据(例如我们在twork中生成的项目测试日报)。虽然说测试覆盖率越高效果越好，但覆盖率不是目标，仅仅只是一种手段。
测试覆盖率包括功能点覆盖率和结构覆盖率。功能点覆盖率用于表示软件系统已经实现的功能与软件需要实现的功能之间的比例关系；而结构覆盖率主要适用于白盒测试中，如语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等。
在测试活动中，覆盖率无处不在，从TC的编写，到测试的执行，不管是黑盒的路径，还是白盒代码中的REVIEW，在测试分析报告中，测试覆盖率是最最有力的数据。总结这些覆盖率的类型，无非两种，一种是静态的覆盖率，一种是动态的覆盖率，这就是覆盖率的动静之美。
静态的覆盖率包括testcase覆盖率，静态代码REVIEW覆盖率，功能自动化脚本覆盖率以及测试分析报告中以数据形式表示的覆盖率等等。在静态覆盖率中，最重要的是TC覆盖率，其次是静态代码REVIEW覆盖率。
TC覆盖率
TC是测试执行之始，也可以把TC当成测试执行活动的数据，TC的覆盖率直接影响测试活动的质量。可以不先考虑TC的粗细程度，但不得不考虑TC覆盖的范围与正确程度。覆盖率强的TC可以发现更多不易发现的路径，测试更多应用场景，从而揭露出更多隐藏的bug，尤其是在测试淘宝的应用时。记得在测试一个日常时，因为没有考虑到同一个应用下模块间的影响关系，在设计TC时没有覆盖到这条路径，导致上线后这个bug由卖家报给我们，很悲剧。不过从这个bug中让我们这些新人意识到，我们在设计TC和测试中，要提高测试覆盖，或许这样才可以减少bug的遗漏。这也是TC覆盖率美之处在！
或许在设计TC时，作为新人，不可能达到很高的覆盖程度，但在执行测试活动时，要潜意识中记得，把思维发散开来，用执行测试的覆盖率弥补TC 中的覆盖缺陷，之后再完整我们的TC，让覆盖率更高的TC入库。在这方面，还有一段路要走，共勉！
静态代码REVIEW覆盖率
静态代码REVIEW覆盖率现在在国内用得不多，可能和重视程度有关，相关的资料也只是在某些专业的资料中见见。但少见并不意味它不重要，因为在代码阶段发现bug的修复成本远远比在页面上发现bug的修复成本低。静态代码REVIEW还有一个优点就是已经实现工具化，现在有不少开源的工具可以做到，又免费又好用，何乐而不为呢。
静态代码REVIEW主要对代码中的词法，语法，数据类型和单位，引用，表达式，接口进行分析，绘制成各种表进行分析，如变量引用表，函数表，等价表和常数表等，不同工具不同方法分析方式有所不同。
覆盖率还有动态之分，这是一种让人惊叹的覆盖率，出场于代码运行过程中，主要用工具来实现。当执行者运行某一功能时，动态覆盖率工具会以红绿两种颜色分别标识此功能没有运行的代码和此功能涉及到的代码，这里的执行者可以是开发同学，也可以是测试同学。
有些代码覆盖率工具可以当eclipse的插件使用，如eclemma，它可以做到对类覆盖、函数覆盖、语句块覆盖、分支覆盖，并生成覆盖率数据以界面形式显示出来，如下是一个简单的应用场景：
以eclemma行动代码后可以很清楚地看到执行过的代码和没有执行过的代码，并在控制台上显示工程，包，类方法的覆盖率具体的数据报告。此外还提供最近两个时间段的报告用于比较。
还有一些已成系统的代码覆盖率工具，如开源的clover，EMMA以及基于此的TCC，这些工具的功能可以在它们的官网详细查阅到。它们都实现了获取动态运行代码的覆盖率，并以一定的形式给出分析报告，以供开发和测试人员参加。
有人说程序之美始于静，用之于动，测试之美则是始于动，归之于静，如果要用工具去表达这种美，那么上面三种或是其它更多的则足已让你惊叹。
That’s all，测试之美系列，从开始学习软件测试到参加工作以来的一部分感悟，望大家多多指点。
相关链接：
