合理的测试覆盖率

回复完这个之后，一个年轻的实习生走到大师身边： “大师，今天我无意中听到了你对同一个代码覆盖率问题给出了三个不同的答案。为什么？” 大师从椅子上站起来：“给我泡点新茶，我们聊聊这个。” 当杯子里倒满了冒着热气的绿茶后，大师开始说： “这第一个程序员是个新手，刚刚开始学测试。目前他有大量的程序都没有测试用例。他有很 长的路要走；现在对他要求代码覆盖率只会打击他，没有什么用处。最好是让他慢慢的学会写 一些测试用例，测试一下。他可以以后再考虑代码覆盖率。” “而这第二个程序员，不论对编程还是测试都是十分的有经验。我以问作答，问她应该往锅里 放多少米，使她明白决定测试用例多少的因素有很多，她比我更知道这些因素——毕竟是她自 己的代码。对这个问题没有一个简单的、直接的答案。以她的聪明完全能明白这个道理，正确 的完成任务。” “我明白了，” 年轻的实习生说， “但是如果没有一个简单直接的答案，那你为什么告诉第 三个程序员‘百分之八十，不能少’呢？” 大师笑的前仰后合，绿茶都喷了出来。 “这第三个程序员只想得到一个简单的答案——即使根本没有简单的答案 „ 而且即使有答案 她也不会按答案做。” 年轻的实习生和头发斑白的大师在沉思中喝完茶。
• 代码覆盖率 ＝ 代码的覆盖程度的一种度量方式
语句覆盖(StatementCoverage) 又称行覆盖(LineCoverage)，段覆盖(SegmentCoverage)，基本块覆盖(BasicBlockCoverage)，这是最 常用也是最常见的一种覆盖方式，就是度量被测代码中每个可执行语句是否被执行到了。 判定覆盖(DecisionCoverage) 又称分支覆盖(BranchCoverage)，所有边界覆盖(All-EdgesCoverage)，基本路径覆盖 (BasicPathCoverage)，判定路径覆盖(Decision-Decision-Path)。它度量程序中每一个判定的分支是
• Q&A
一大早，一个年轻的程序员问大师：“我准备写一些单元测试用例。代码覆盖率应 该达到多少为好？” 大师回答道:“不要考虑代码覆盖率，只要写出一些好的测试用例即可。” 年轻的程序员很高兴，鞠躬，离去。 之后没多久，第二个程序员问了大师同样的问题。 大师指着一锅烧沸的水说：“我应该往这个锅里放多少米？” 这个程序员看起来被难住了，回答道：“我怎么会有答案？这取决于要给多少人吃， 他们饿不饿，有什么菜，你有多少米，等等。” “完全正确，” 大师说。 第二个程序员很高兴，鞠躬，离去。 末了，来了第三个程序员问了大师同样的关于代码覆盖率的问题。 “百分之八十，不能少！” 大师一拳锤在桌子上，用严厉的口气回答道。 第三个程序员很高兴，鞠躬，离去。
• 覆盖率数据只能代表你测试过哪些代码，不能代表你是否测试好这些代 码 • 较低的测试覆盖率能说明我们的测试还不够，反之是不成立的 • 同一模块高覆盖率相对于低覆盖率能说明我们做了更多的测试 • 不要过于相信覆盖率数据。 • 路径覆盖率 > 条件覆盖 > 判定覆盖 > 语句覆盖 • 测试覆盖率100%是一个理想的情况，是很难达到的 • 测试覆盖率100%不能说明我们做了完全的测试 • 测试覆盖率达到多少要考虑到软件整体的覆盖率情况，以及项目成本， 包括人力，时间等等。 • 测试人员不能盲目追求代码覆盖率，而应该想办法设计更多更好的案例， 哪怕多设计出来的案例对覆盖率一点影响也没有。
By Steve Cornett. Copyright © Bullseye Testing Technology 2006-2011. Minimum Acceptable Code Coverage
Summary Code coverage of 70-80% is a reasonable goal for system test of most projects with most coverage metrics. Use a higher goal for projects specifically organized for high testability or that have high failure costs. Minimum code coverage for unit testing can be 10-20% higher than for system testing. In a large system, achieving 100% code coverage is generally not cost effective. Some reasons are listed below.
if (b < 10) {// 分支二 nReturn += 10; } return nReturn;
}
c. 条件覆盖 TestCase1 a = 5, b = 15 nReturn = 1 TestCase2 a = 15, b = 5 nReturn = 10
d. 路径覆盖 TestCase1 a = 5, TestCase2 a = 15, TestCase3 a = 5, TestCase4 a = 15,
集成验证阶段，关心的系统的功能，以及模块与模块之间的 接口，此时出口条件为功能覆盖率。一般业内常用的出口条件 是：功能覆盖率达到90％，对没有覆盖率的需给出合理的说明。
功能覆盖率高、代码覆盖率低： 验证计划不充分，需要增加功能覆盖点。 代码覆盖率高、功能覆盖率低： 设计没有实现指定的功能。
Functional Coverage High Low
Some test cases are expensive to reproduce but are highly improbable. The cost to benefit ratio does not justify repeating these tests simply to record the code coverage. Checks may exist for unexpected error conditions. Layers of code might obscure whether errors in low-level code propagate up to higher level code. An engineer might decide that handling all errors creates a more robust solution than tracing the possible errors. Unreachable code in the current version might become reachable in a future version. An engineer might address uncertainty about future development by investing a little more effort to add some capability that is not currently needed. Code shared among several projects is only partially utilized by the project under test.
• 在测试里面，一般会将测试覆盖率分为两个部分：需求覆盖率和 代码覆盖率 覆盖功能点＋覆盖性能点 功能点＋性能点要求
• 需求覆盖率：
• 代码覆盖率：为了更加全面的覆盖，还需要测试程序的流程，考 虑到函数的数据的输入与输出，甚至是每一行代码的执行情况， 代码的每一条逻辑和分支。测试执行情况就以代码覆盖率来衡量。

否都被测试到了。
条件覆盖(ConditionCoverage) 它度量判定中的每个子表达式结果true和false是否被测试到了，不需要将判定中的每个条件表达 式的结果进行排列组合。 路径覆盖(PathCoverage) 又称断言覆盖(PredicateCoverage)。它度量了是否函数的每一个分支都被执行了。 所有可能的分 支都执行一遍，有多个分支嵌套时，需要对多个分支进行排列组合，测试路径随着分支的数量指 数级别增加。
Need more FC Points, including Corner cases Start of project Good coverage: check bug rate Is design complete? Perhaps try formal tools
Low High Code Coverage
int function1(int a, int b) { try{ if (a < 10 || b < 10) // 判定 { return 0; // 分支一 } else { return 1; // 分支二 } }catch (Exception exp){
功能性代码
预防性代码
logger.error(“get error”,exp); 诊断性代码 } }

a. 语句覆盖
int foo(int a, int b) { int nReturn = 0; if (a < 10) {// 分支一 nReturn += 1; }
TestCase a = 5, b = 5 nReturn = 11 b. 判定覆盖 TestCase1 a = 5, b = 5 nReturn = 11 TestCase2 a = 15, b = 15 nReturn = 0
Ｔｅｓｔ Coverage Introduce
Tom
Tom
24/08/2013
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
1
ຫໍສະໝຸດ Baidu
• 什么是测试覆盖率 • 测试覆盖率的作用 • 合理的测试覆盖率 • BRM 代码覆盖率的分析
• 测试覆盖率是测试结束标准中的一部分
• 测试覆盖率低的模块 和 重要模块的测试覆盖率。这些数据可以帮 助我们快速定位需要更多测试的模块，可以帮助我们了解重要模 块的测试情况，以此来衡量我们测试用例的质量乃至测试的质量。
• 在螺旋式开发模式中，如果我们没有控制好我们上一个迭代中的 测试覆盖率，当一个版本一个版本累加下来后，你就很难确定我 们哪些模块在开发过程中没有给予足够的测试
By Steve Cornett. Copyright © Bullseye Testing Technology 1996-2011. Minimum Acceptable Code Coverage
Summary Code coverage of 70-80% is a reasonable goal for system test of most projects with most coverage metrics. Use a higher goal for projects specifically organized for high testability or that have high failure costs. Minimum code coverage for unit testing can be 10-20% higher than for system testing. In a large system, achieving 100% code coverage is generally not cost effective. Some reasons are listed below.
b=5 b=5 b = 15 b = 15
nReturn = 0 nReturn = 1 nReturn = 10 nReturn = 11
验证阶段可以分为单元验证（UT）阶段、集成验证（IT）阶段 和系统验证（ST）阶段。
单元验证阶段，关心的是模块功能和模块质量，此时出口条 件为代码覆盖率。一般业内常用的出口条件是：行覆盖率达到 100％，分支覆盖率达到100％，条件覆盖率达到95％，对没有 覆盖率的需给出合理的说明。