git强制覆盖：
git fetch --all
git reset --hard origin/master
git pull

 


git强制覆盖本地命令（单条执行）：

    git fetch --all && git reset --hard origin/master && git pull

 

第一个是：拉取所有更新，不同步；

第二个是：本地代码同步线上最新版本(会覆盖本地所有与远程仓库上同名的文件)；

第三个是：再更新一次（其实也可以不用，第二步命令做过了其实）

 

备注： 命令连接符 && 的意思是 前一条命令执行成功才执行后一条命令。

扩展：命令连接符 ;; 的意思是 不论前一条是否执行成功都继续执行后一条命令。

 

奇怪的姿势又增加了！！！G_G

文章转自：https://blog.csdn.net/virus2014/article/details/51217026

更新时间： 2019.10.22 13:06

1语句覆盖

每个可执行语句都走一遍即可，即测试用例要覆盖所有的语句（来源：软件开发的技术基础）

 

2判定覆盖（分支覆盖）

 针对判断语句，在设定案例的时候，要设定True和False的两种案例；与语句覆盖不同的是增加了False的情况



3条件覆盖

针对判断语句里面案例的取值都要去一次，不考虑条件的取值

另注：条件覆盖保证判断中的每个条件都被覆盖（来源：软件开发的技术基础）



4判定/条件覆盖

判定覆盖各条件覆盖交叉，针对于判定中的条件取值 



5组合覆盖

判定-条件覆盖的加强版 



6路径覆盖

 

 

定义：

　　白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，白盒指的是程序的内部结构和运作机制是可见的。
白盒测试的目的：

　　通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设置检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
**白盒测试的方法：**大致分为静态方法和动态方法两大类。
A. 静态分析：

　　是一种不执行程序而进行测试的技术。静态分析的主要目的是检查软件的表示和描述是否一致,没有冲突或者没有歧义。
B. 动态分析：

　　当软件系统在模拟或真实的环境中执行前、过程中和执行后,对其行为分析。它显示了一个系统在检查状态下是否正确。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。
符号说明：
^   代表逻辑运算符   &&  或者  ||

　　

　　T 代表  True            F 代表   False

　　

　　A / B 代表条件表达式
（1）语句覆盖
使程序中的每个可执行语句都能执行一次的测试用例
测试用例条件： A ^ B = T

（2）判定覆盖（分支覆盖）
对于判断语句，在设计用例的时候，要设计判断语句结果为True和False的两种情况

　　

测试用例条件：

　　　　　　　A ^ B = T

　　　　　　　A ^ B = F

　　　　　　　
（3）条件覆盖
设计用例时针对判断语句里面每个条件表达式true 和 false各取值一次，不考判断语句的计算结果
测试用例条件：

　　　　　　　A=T         　　　　A=F

　　　　　　　B=T        　　　　B=F

　　　　　　　
（4）判定条件覆盖（分支条件覆盖）
设计测试用例时，使得判断语句中每个条件表达式的所有可能结果至少出现一次，每个判断语句本身所有可能结果也至少出现一次。
测试用例条件：

　　　　　　　A ^ B = T  　　   A ^ B = F

　　　　　　　A=T　　　　　A=F

　　　　　　　B=T　　　　　B=F

（5）条件组合覆盖
设计测试用例时，使得每个判断语句中条件结果的所有可能组合至少出现一次
测试用例条件：

　　　　　　　A= T　　　 B= T

　　　　　　　A= T 　　　B= F

　　　　　　　A= F　　　 B= T

　　　　　　　A= F 　　　B= F

（6）路径覆盖
设计测试用例时，覆盖程序中所有可能的执行路径
优点：这种覆盖方法可以对程序进行彻底的测试用例覆盖，比前面讲的五种方法覆盖度都要高。
缺点：于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。路径覆盖虽然是一种比较强的覆盖，但未必考虑判断语句中条件表达式结果的组合，并不能代替条件覆盖和条件组合覆盖。

在做单元测试时，代码覆盖率常常被拿来作为衡量测试好坏的指标，甚至，用代码覆盖率来考核测试任务完成情况，比如，代码覆盖率必须达到80％或 90％。于是乎，测试人员费尽心思设计案例覆盖代码。用代码覆盖率来衡量，有利也有有弊。本文我们就代码覆盖率展开讨论，也欢迎同学们踊跃评论。

首先，让我们先来了解一下所谓的“代码覆盖率”。我找来了所谓的定义：

代码覆盖率 ＝ 代码的覆盖程度，一种度量方式。

上面简短精悍的文字非常准确的描述了代码覆盖率的含义。而代码覆盖程度的度量方式是有很多种的，这里介绍一下最常用的几种：

1. 语句覆盖(StatementCoverage)

又称行覆盖(LineCoverage)，段覆盖(SegmentCoverage)，基本块覆盖(BasicBlockCoverage)，这是最常用也是最常见的一种覆盖方式，就是度量被测代码中每个可执行语句是否被执行到了。这里说的是“可执行语句”，因此就不会包括像C＋＋的头文件声明，代码注释，空行，等等。非常好理解，只统计能够执行的代码被执行了多少行。需要注意的是，单独一行的花括号｛｝ 也常常被统计进去。语句覆盖常常被人指责为“最弱的覆盖”，它只管覆盖代码中的执行语句，却不考虑各种分支的组合等等。假如你的上司只要求你达到语句覆盖，那么你可以省下很多功夫，但是，换来的确实测试效果的不明显，很难更多地发现代码中的问题。

这里举一个不能再简单的例子，我们看下面的被测试代码：

int foo(int a, int b)

{

   return  a / b;

}



假如我们的测试人员编写如下测试案例：

TeseCase: a = 10, b = 5

 

测试人员的测试结果会告诉你，他的代码覆盖率达到了100％，并且所有测试案例都通过了。然而遗憾的是，我们的语句覆盖率达到了所谓的100%，但是却没有发现最简单的Bug，比如，当我让b=0时，会抛出一个除零异常。

正因如此，假如上面只要求测试人员语句覆盖率达到多少的话，测试人员只要钻钻空子，专门针对如何覆盖代码行编写测试案例，就很容易达到主管的要求。当然了，这同时说明了几个问题：

    1.主管只使用语句覆盖率来考核测试人员本身就有问题。

    2.测试人员的目的是为了测好代码，钻如此的空子是缺乏职业道德的。 

    3.是否应该采用更好的考核方式来考核测试人员的工作？ 

为了寻求更好的考核标准，我们必须先了解完代码覆盖率到底还有哪些，如果你的主管只知道语句覆盖，行覆盖，那么你应该主动向他介绍还有更多的覆盖方式。比如：

2. 判定覆盖(DecisionCoverage)

又称分支覆盖(BranchCoverage)，所有边界覆盖(All-EdgesCoverage)，基本路径覆盖(BasicPathCoverage)，判定路径覆盖(Decision-Decision-Path)。它度量程序中每一个判定的分支是否都被测试到了。这句话是需要进一步理解的，应该非常容易和下面说到的条件覆盖混淆。因此我们直接介绍第三种覆盖方式，然后和判定覆盖一起来对比，就明白两者是怎么回事了。

3. 条件覆盖(ConditionCoverage)

它度量判定中的每个子表达式结果true和false是否被测试到了。为了说明判定覆盖和条件覆盖的区别，我们来举一个例子，假如我们的被测代码如下：



int foo(int a, int b)

{

    if (a < 10 || b < 10) // 判定

    {

        return 0; // 分支一

    }

    else

    {

        return 1; // 分支二

    }

}





设计判定覆盖案例时，我们只需要考虑判定结果为true和false两种情况，因此，我们设计如下的案例就能达到判定覆盖率100％：

TestCaes1: a = 5, b ＝ 任意数字  覆盖了分支一

TestCaes2: a = 15, b = 15          覆盖了分支二

 

设计条件覆盖案例时，我们需要考虑判定中的每个条件表达式结果，为了覆盖率达到100％，我们设计了如下的案例：

TestCase1: a = 5, b = 5       true,  true

TestCase4: a = 15, b = 15   false, false



通过上面的例子，我们应该很清楚了判定覆盖和条件覆盖的区别。需要特别注意的是：条件覆盖不是将判定中的每个条件表达式的结果进行排列组合，而是只要每个条件表达式的结果true和false测试到了就OK了。因此，我们可以这样推论：完全的条件覆盖并不能保证完全的判定覆盖。比如上面的例子，假如我设计的案例为：

TestCase1: a = 5, b = 15  true,  false   分支一

TestCase1: a = 15, b = 5  false, true    分支一

 

我们看到，虽然我们完整的做到了条件覆盖，但是我们却没有做到完整的判定覆盖，我们只覆盖了分支一。上面的例子也可以看出，这两种覆盖方式看起来似乎都不咋滴。我们接下来看看第四种覆盖方式。

4. 路径覆盖(PathCoverage)

又称断言覆盖(PredicateCoverage)。它度量了是否函数的每一个分支都被执行了。 这句话也非常好理解，就是所有可能的分支都执行一遍，有多个分支嵌套时，需要对多个分支进行排列组合，可想而知，测试路径随着分支的数量指数级别增加。比如下面的测试代码中有两个判定分支：



int foo(int a, int b)

{

    int nReturn = 0;

    if (a < 10)

    {// 分支一

        nReturn += 1;

    }

    if (b < 10)

    {// 分支二

        nReturn += 10;

    }

    return nReturn;

}





对上面的代码，我们分别针对我们前三种覆盖方式来设计测试案例：

a. 语句覆盖

TestCase a = 5, b = 5   nReturn = 11

 语句覆盖率100％

 

b. 判定覆盖

TestCase1 a = 5,   b = 5     nReturn = 11

TestCase2 a = 15, b = 15   nReturn = 0

判定覆盖率100％ 

 

c. 条件覆盖

TestCase1 a = 5,   b = 15   nReturn = 1

TestCase2 a = 15, b = 5     nReturn = 10

条件覆盖率100％ 

 

我们看到，上面三种覆盖率结果看起来都很酷！都达到了100％！主管可能会非常的开心，但是，让我们再去仔细的看看，上面被测代码中，nReturn的结果一共有四种可能的返回值：0，1，10，11，而我们上面的针对每种覆盖率设计的测试案例只覆盖了部分返回值，因此，可以说使用上面任一覆盖方式，虽然覆盖率达到了100%，但是并没有测试完全。接下来我们来看看针对路径覆盖设计出来的测试案例：



TestCase1 a = 5,    b = 5     nReturn = 0

TestCase2 a = 15,  b = 5     nReturn = 1

TestCase3 a = 5,    b = 15   nReturn = 10

 

TestCase4 a = 15,  b = 15   nReturn = 11

路径覆盖率100％ 





太棒了！路径覆盖将所有可能的返回值都测试到了。这也正是它被很多人认为是“最强的覆盖”的原因了。

还有一些其他的覆盖方式，如：循环覆盖(LoopCoverage)，它度量是否对循环体执行了零次，一次和多余一次循环。剩下一些其他覆盖方式就不介绍了。

总结

通过上面的学习，我们再回头想想，覆盖率数据到底有多大意义。我总结了如下几个观点，欢迎大家讨论：

a. 覆盖率数据只能代表你测试过哪些代码，不能代表你是否测试好这些代码。（比如上面第一个除零Bug）

b. 不要过于相信覆盖率数据。

c. 不要只拿语句覆盖率(行覆盖率)来考核你的测试人员。

d. 路径覆盖率 > 判定覆盖 > 语句覆盖

e. 测试人员不能盲目追求代码覆盖率，而应该想办法设计更多更好的案例，哪怕多设计出来的案例对覆盖率一点影响也没有。