测试过程
单元测试
注意出错处理！单元测试的数据处理部分请见Junit 单元测试之错误和异常处理-CSDN博客
单元测试准则
白盒：对系统结构非常清楚！就像大题注重过程。
单元测试的测试环境
一定要保证整个环境是完整的，尽管可能没有完全定义好前后文，也要模拟出来。
比如现在要测试上图的B模块，我们如何才能准备好B模块的测试环境呢？
B模块需要调用E， B模块还会被A调用，如果不准备好A和E的环境，那么B所处的环境就是不完全的，B的测试环境就是不全面的！这时候就需要模拟上下层模块：
简而言之就是在Junit中实现mock，可以使用mockito框架辅助！驱动模块调用被测模块，被测模块调用桩模块**！**
集成测试
关注模块外部行为！
一次全部放在一起集成测试：出错的概率会大很多！并且很难找到错误的位置！所以建议一步一步增加模块，逐步增加测试规模的方法。
β测试：开发者不知道用户具体的行为，不受开发者控制。α测试：在开发者控制好的环境下，由开发者监控的测试环境。
作者灵光突现：模拟redis集群失联情况，然后查看一下集群是怎么处理失联的情况，最后重新恢复运行查看效果，应该也算恢复测试！
测试用例的设计方法：白盒和黑盒测试！
当面试官问测试方法的时候，一定要界定测试方法和测试过程！
一句话：白盒测试结构，黑盒测试功能/性能！
白盒测试
看到见的内容到底覆盖了多少！每一个简单的条件，只要含有逻辑值就都需要考虑，不仅仅是分支条件！
语句覆盖中的语句，可以理解为代码中存在的语句，而不是全部的判定语句、循环语句等，他就是走最明显的道路，所以它的覆盖范围是最小的！
在各种流程的唯一出口：增加节点！菱形框中是复合条件的话，必须要拆分成简单条件！否则很有可能会漏测一部分条件！这也是流图的基本要求。
一直围绕程序控制流程进行！如果程序中有太多变量，那么可以看一下程序变量的d-u链！
黑盒测试
最经典的方法：等价类（发现错误的能力上等价），找一组典型的类测试就行，没有必要选取更多的等价类！等价类覆盖到全部输入的区域！不相交！（如果有相交，那么出现错误的时候，这个错误就可能存在交叉区域中，不方便寻找到错误）
黑盒测试本质上对应着软件的规格说明，是否实现了说明书里面要求的功能和性能。
规则有多少种，无效等价类就有多少种！
