软件测试查漏补缺（二）——测试基本标准、测试分类、单元测试

软件测试查漏补缺（二）——测试基本标准、测试分类、单元测试

一、测试基本标准

(1)所有的测试都应追溯到用户需求。
(2)应当把“尽早地和不断地进行软件测试”作为座右铭。
(3)pareto原则：测试发现的错误中80%很可能起源于20%的模块中。
(4)完全测试是不可能的，测试需要终止。
(5)应由独立的第三方来构造测试。
(6)充分注意测试中的群集现象。
(7)尽量避免测试的随意性。
(8)兼顾合理的输入和不合理的输入数据。
(9)程序修改后要回归测试。
(10)应长期保留用例，直至系统废弃。

二、测试分类

主要记录一下集成测试，详细分类请转至：https://blog.csdn.net/daboluo521/article/details/81385017

集成测试分为增量式集成测试和非增量式集成测试两类。

增量式集成测试：需要开发桩模块、模块集成时首先集成主控模块、能及时发现设计上的错误，分为自顶向下和自底向上两类。

自顶向下测试：是从程序的初始模块开始测试。
（1）能在早期发现顶层的错误。
（2）早期的程序框架可以进行演示
（3）需要开发桩模块辅助测试。有些甚至需要多个桩模块辅助，加大了桩模块本来的错误影响。
（4）测试完一个上层模块后，挑选哪个模块作为下一个测试模块，以及测试的顺序没有唯一的界定标准。
优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。
缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。

自底向上测试：是从程序的底层模块开始测试。
（1）I/O操作可以提前测试，更好提交测试用例。
（2）测试后比较容易观察输出。
（3）需要开发驱动模块。
（4）直到最后一个模块提交，程序才能完整的系统测试。
优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。
缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。

非增量式集成：在对每个单元进行充分测试后，将所有单元全部集成起来，一次性地进行集成测试

三、单元测试

单元测试工具：https://blog.csdn.net/qq_42434318/article/details/109272438

单元测试的策略：逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、静态数据流分析

依靠于mock、stub和驱动函数：

mock：对代码中某些不容易获取的对象创建虚拟对象来测试

stub：桩函数是代替某些被调用了但是没有编写代码，一般再增量迭代自底向上的过程中不用编写。再自顶向下的过程中需要编写

驱动函数：调用被测函数，给被测函数传参

测试桩：代替被测模块调用的子模块的实体，该实体一般为桩函数，这个测试桩就是我们所说的桩函数
stub函数,叫它桩函数，存根函数都可以，用一个桩函数替换一些接口函数，用于测试当前函数的特性。
譬如说,要测试一个函数 f()
void f()
{
var = g(…);
}
f()函数中调用了函数 g(),但是在测试f()的时候g()函数可能还没有写出来这时可以写一个g()的存根(stub)函数,来模拟g()函数,例如让它仅仅返回一个值.这样的话就可以完成对函数f()的测试了

单元测试路径数量
1、V（G）=P+1 （P是判定节点）
2、V（G）=D （D是区域数）
3、V（G）=E-N+2（E是边的条数，N是节点数）

六种覆盖方法：覆盖准则由弱到强依次是语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖

语句覆盖是使得程序中每个语句至少被执行一次；
判定覆盖是使得程序中的每个分支至少都通过一次；
条件覆盖是使得判定中的每个条件获得各种可能的结果；
判定/条件覆盖是使得判定中的每个条件取到各种可能的值，并使每个判定取到各种可能的结果；
条件组合覆盖是使得每个判定中条件的各种可能组合都至少出现一次；

比较判断与控制流常常紧密相关，测试时注意以下错误：

1. 不同数据类型的对象之间进行比较;
2. 错误地使用逻辑运算符或优先级;
3. 因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等;
4. 比较运算或变量出错;
5. 循环终止条件或不可能出现;
6. 迭代发散时不能退出;
7. 错误地修改了循环变量。