本文概述
软件测试概述
关于软件测试，它和用Git一样类似，比如有些程序员不习惯用Git或编写测试用例。我刚开始学编程的时候，测试同样也是学了，就是不知道它有个什么用，还有个测试驱动开发，一脸蒙蔽。测试不就是写一段代码就执行一遍么？或者带有UI的程序，自己点击两下测试一下，当然还遇到一些人喜欢静态分析代码的——像考试写完考卷回头静态分析。
所以我开始也是编写单元测试的，后来才放弃这样编写程序，当认为自己写的代码无比正确的时候——运行起来多数情况都会翻车，这是多么烦躁的事情，有时候都在怀疑自己是不是会写程序的，这么笨，写个简单的函数都错。
如果你会一点数据结构和算法，基本上你可以写一个还可以运行的程序出来，但是大部分时候还是在测试和调试，让程序尽量能出来更多情况的问题。这里就不多说明为什么单元测试是必要的——你可以用自己的时间和经验来证明，但我还是建议：节省时间，初学者即使不懂，模仿一下也无妨，有益无害。
软件测试主要分为黑盒测试和白盒测试，上面说的点击UI就是黑盒测试，静态分析代码属于白盒测试，但还是比较低能的。标准来说，通过操作UI来进行黑盒测试，你同样需要预先设计一下，比如输入值的范围和输出预期值。
其中黑盒测试的方法包括：边界值、等价法、错误推测法、功能分解法、因果图、判定表、正交试验法和场景法。
白盒测试的方法包括：代码检查法、静态结构分析、静态质量度量、逻辑覆盖、基本路径测试、域测试、符号测试、Z路径覆盖和程序变异。
黑盒测试主要是根据项目功能需要来测试的，就是看看程序有没有实现预定的功能，是比较宏观的层面的。白盒测试的是微观上的功能，就是实现程序需求后面的具体实现代码，具体到每一行代码上。
测试方法很多，但是我认为并不需要全部都用上，软件的功能可能很复杂都有，在黑盒测试中只要知道输入数据集和输出数据集就可以了，这些数据集需要匹配程序的需求，并且测试是否有预期的输出，而这里说的方法根据不同的软件，你可能无意中都用上了。而对于黑盒测试，除了测试程序是否符合需求功能的预期，其准确度相对白盒测试来说是比较低的。
这里我想侧重讨论白盒测试，其中路径覆盖又是其中一个常用而比较准确的测试方法，而我认为，写一下代码写一下这种测试基本就够了，并且是必要的，你大概能保证程序80%的情况都是正确的——当然，就算你用完所有方法，随着不断的更新程序，你基本不可能写出一个100%完美的程序，所以对于测试用例的数量——适量就好！
单元测试和路径覆盖
我们在编写程序代码的时候，对这段代码进行测试——一般测试的基本单元是一个函数，有人说测试一个函数也不准确呀，你还依赖其它函数呢！——照这样推理，那你还写不写代码的？你写的代码也不准确呢！其它第三方依赖函数不要管！当它们是100%正确就是了，有错的时候再说（而且第三方依赖，对于标准的库，人家都是测试过了的，比如JDK，或者说okhttp这样的库）。
一个函数由多个语句组成，这些语句又分为无分支语句和条件语句（分支语句），我们可以把一段连续的无分支语句表示成一个结点（Node，或节点，还记得数据结构中的节点吗？），两个语句（两个结点）使用有向箭头连接，表示从第一个语句顺序执行到第二个语句：
这个图又像什么？图论算法呢！有没有记得或学过？
路径测试的详细步骤可以参考：
- 首先确定测试和分析的代码，一般是一个函数。
- 根据代码画出程序执行的流程图，就是类似上面这个图。
-
- 一段无分支连续语句的代码作为一个结点，单个语句可作为一个结点。
- 带有条件表达式的代码作为一个结点（如if/while/for/do-while），复杂的逻辑表达式需要分解成单个判断的形式。
- 代码执行结束为一个结点。
- 一个条件表达式产生两个分支，复杂组合的条件判断需要分解成单个条件判断。
- 然后根据这个流程图计算环路复杂度
-
- 环路复杂度描述程序的逻辑复杂性。
- 它的数值表示每条分支至少执行一次的测试用例数量上限。
- 环路复杂度的计算公式有三个：V(G)=E-N+2，其中E为边数，N为结点数；V(G)=P+1，P为判定结点数，就是产生分支的结点；V(G)=A，A为闭合区域数，边和节点围起来叫做一个区域，图形外也算一个区域；如上图的区域数为A=3，判断结点数P=2，边数E=7，结点数N=6，所以环路复杂度为V(G)=3，表示测试这个函数，我们编写至少三个用例就够了。
- 接着确定所有路径。
-
- 由V(G)=3可以得出，这个程序有三条互不相同的路径。
- 这些路径分别是：1-2-4-6，1-3-4-6，1-3-5-6。
- 最后根据每条路径设计测试用例。
-
- 设计每条路径的输入和预期输出（输入集和输出集），确保覆盖每条路径。
- （可选）当前路径输入值的范围（包括正确的范围和错误的范围），确保覆盖每条路径输入的多数值（如基本数据类型、数组、引用类型对应的所有可能值）。
下面我们使用具体的实例来学习路径覆盖测试，其实黑盒测试或白盒测试中的其它方法也是类似的，明白其中的一些要点就行了，比如输入数据集和输出数据集，测试程序的输入和预期输出是对应的，那么就是正确的。
确定测试和分析的代码
这里假设我们设计一个计算器中的一个叠加函数，下面是Java的具体代码（尽管可以使用数学公式快速计算出来，但这里还是用while循环，展示一下常见的模式）：
public class Caculator {
/**
* 计算从整数s开始到e结束，它们相加的和(不包含e)
* */
public int add(int s, int e) throws Exception {
if(s == e)
return 0;
if(s > e)
throw new Exception("s is greater than e.");
int sum = 0;
while(s < e) {
sum += s;
s++;
}
return sum;
}
}根据代码画出程序执行流程图
首先，这段代码有三个条件判断。函数开始执行没有非条件语句，但是我们可以把它看作是执行了一个空语句，也就是说这里有一个结点，然后每个条件判断为一个结点，并且这个几点有两个分支，对于抛出异常我们可以把它等同于结束结点。
该程序的流程图为：
其中，第四个结点表示语句“int sum = 0;”，这个结点其实也可以和第5个结点合并一起，但是这样会更清晰一点。
计算环路复杂度
由上图，我们可以得到E=9，N=7，P=3，A=4，所以V(G)=9-7+2=3+1=4。
也就是说，我们至少编写4个测试用例就能实现全部路径覆盖了。
确定所有路径
这些路径包括：
- 1-2-3-4-5-6-5-7
- 1-2-3-4-5-7
- 1-2-3-7
- 1-2-7
根据每条路径设计测试用例
根据我们的代码，我们可以分析出1-2-3-4-5-7这条路径是绝对不会执行的，就不需要编写这条路径的测试用例了，也就是说，这个while循环至少执行一次，下面是为每条路径设计的输入和输出数据：
- 1-2-3-4-5-6-5-7：（s=-1，e=10）=>（44）
- 1-2-3-7：（s=100，e=10）=>（Exception）
- 1-2-7：（s=e=8）=>0
下面我们用junit编写测试用例：
public class CaculatorTest {
@Test
public void shouldReturn44() throws Exception {
Caculator c = new Caculator();
Assert.assertEquals(44, c.add(-1, 10));
}
@Test
public void shouldReturn0() throws Exception {
Caculator c = new Caculator();
Assert.assertEquals(0, c.add(8, 8));
}
@Test(expected = Exception.class)
public void shouldThrowException() throws Exception {
Caculator c = new Caculator();
c.add(100, 10);
}
}关于测试函数的命名方式，我建议也要有个标准的命名，比如如果规定一个类对应一个测试用例，一个类可能会有多个函数，我们可以使用原来的函数名开头，例如测试add函数，可以这样命名：函数名+should+测试结果描述，例如addShouldReturn44, addShouldThrowsException, addShouldReturn0，这样当我们测试一个类的多个函数的时候就不会看着很乱。另外，我们可能也会对于一个路径使用多个不同的值进行测试，可以用类似的方式，或者在后续会不断更新一个函数的代码，你也可以想一个比较整洁清晰的命名方式，不然的话，测试越写与多，到时你就会发现乱七八糟的名字都没耐心找了。
总结
关于软件测试中的路径覆盖测试就先到这里了，我觉得在我们平时开发中，类似这样编写单元测试基本足够了，或者你也可以横向进行输入值范围的覆盖。而写一些代码就写一个测试是十分有必要的，不然你怎么保证你的代码大部分运行都是正确的？靠想或推理吗？如果推理能保证得了，那么大部分公司就可以省掉测试这部分的支出了。
如果你想进行黑盒测试，那么也可以参考这里的路径覆盖，比白盒测试简单很多，无非就是对照需求手册，考虑输入值的范围（或对输入值进行分类），测试这个程序有没有正确实现需求上面要求的功能。
下一篇正式进入Junit5单元测试的讨论，再次学习Junit，希望能进一步提升编程技能，编程更顺利——可以续命！
