BUAA_OO_Unit3_Blog

[22373124-李长佳]

目录

• Part1:分析本单元的测试过程
• 谈谈你对黑箱测试、白箱测试的理解
• 对单元测试、功能测试、集成测试、压力测试、回归测试的理解
• 数据构造有何策略
• Part2:梳理本单元的架构设计，分析自己的图模型构建和维护策略
• 架构设计
• 图模型构建
• 维护策略
• Part3:分析作业中出现的性能问题及其修复情况，谈谈自己对规格与实现分离的理解
• 性能问题和修复情况
• 对规格与实现分离的理解
• Part4:本单元中同学们实现了Junit测试方法，总结分析如何利用规格信息来更好的设计实现Junit测试，以及Junit测试检验代码实现与规格的一致性的效果
• Part5:本单元学习体会

Part1:分析本单元的测试过程

谈谈你对黑箱测试、白箱测试的理解

黑箱测试：随机大量生成数据并运行验证
白箱测试：有的放矢根据规格生成特定数据运行验证

对单元测试、功能测试、集成测试、压力测试、回归测试的理解

单元测试：一般是指类测试，测试单个类各种功能的组合执行
功能测试：一般是指方法测试，测试单个方法的执行
集成测试：在单元测试基础上，由类组装成为子系统或系统，测试各个单元的各种操作组合
压力测试：测试极限情况，既可以是空间复杂度上的，也可以是时间复杂度上的
回归测试：在每次迭代之后，新代码应该能兼容旧代码的功能，保证新代码能通过对旧代码的测试

数据构造有何策略

1. 可以随机生成，进行大量长时间的稳定性测试
2. 可以手动生成，手动构造极限数据进行压力测试

Part2:梳理本单元的架构设计，分析自己的图模型构建和维护策略

架构设计

第三单元的核心在于MyNetwork类，一切指令的直接调用都在于MyNetwork类，依赖关系大致如图所示，在我的实现中，我将所有涉及图的运算都放在Graph类中

图模型构建

碍于空间复杂度，我们不以邻接矩阵之类的数据结构暴力构建图的模型，转而对特定的问题采取特定的策略：
在unit3和图有关的方法中，isCircle最大连通子图有关，而isCircle在其他方法中被高频调用，如果不能较简单地实现最大连通子图的查询而是暴力遍历，将会花费大量时间，因而我们需要寻找合适的策略去保存最大连通子图
保存最大连通子图的一个比较优秀的策略是并查集，简单来说，我们在每个最大连通子图中选取一个结点作为根结点，我们用Map保存每个结点和它对应的根结点。如果两个结点的根结点相同，说明两个结点位于同一个连通子图中，这就是查。如果要新增结点，就将两个结点的根结点修改进行合并，这就是并，具体可以自行查阅资料，csdn上有很多

维护策略

需要维护的数据在下文的性能问题一栏中已提及，这里简单说明维护策略：

1. blockSum
   只需要在addRelation和modifyRelation时检查最大连通子图是否产生变化即可
2. isCircle
   上文已经提及，只需要用并查集的查检验两个结点是否根结点相同即可
3. tripleSum
   只需要在addRelation和modifyRelation时检查修改关系的双方有多少共同好友即可
4. tagValueSum
   只需要在addRelation、modifyRelation(Network中)、addPerson、delPerson(Tag中)时更新valueSum即可
5. tagAgeVar
   用脏位dirty判断是否需要重新计算，在下文性能问题中已说明
6. bestAcquaintance
   用大顶堆保存acquaintances即可，bestAcquaintance即根结点
7. coupleSum
   在MyPerson中设置一个通知方法，在bestAcquaintance修改时通知MyNetwork修改coupleSum，若修改前已成对则coupleSum减1，若修改后新成对则coupleSum加1

Part3:分析作业中出现的性能问题及其修复情况，谈谈自己对规格与实现分离的理解

性能问题和修复情况

性能问题
主要集中在空间换时间，时间换时间上，我们要根据不同的时空间代价，去设计不同的实现策略，举几个例子：

1. 数据规模较小的，每次维护代价较小的，每次查询复杂度较高的:如valueSum，ageSum，coupleSum，bestId，每一次操作对他们的修改所需的代价都是较小的，我们就可以采用cache机制，将这些变量作为一个类的属性去保存并在相关操作执行后进行维护，将单次查询消耗的时间均摊到每次维护，就实现了用一个int类变量的空间和每次修改的时间换取较复杂的查询的时间，这样做在输入中有大量查询时，由于查询只需要访问属性，时间复杂度为O(1)，可以节省大量时间
2. 数据规模庞大的，且维护代价较大的:如shortestPath，如果我们要像上面那样对每个点到其他点的shortestPath记录的话，在点数较多的情况下会占据大量空间，除此之外，对这些shortestPath的维护也很困难，每次维护都相当于执行了一次查询，因此，对于这种方法，我们的策略还是即查询即运算
3. 数据规模较小的，但维护代价较大的:如ageVar，虽然这个变量的保存并不花费太多空间，但是每次维护都相当于执行一次复杂查询，因此，对于这种方法，我们采取脏位的思路，在数据修改的同时置脏位，在每次查询结束后复脏位，查询时，只需要根据脏位是否为true来确定是否需要重新查询即可

修复情况
往往难点在于如何保证维护的全覆盖，很容易疏漏导致出现bug，这需要大量测试来确认

对规格与实现分离的理解

规格保证了一个方法得到正确输入就能提供正确输出，相当于确定了方法运行的开头和结尾
实现采用合适的数据结构和算法，描述了方法从输入到输出的过程
规格和实现分离，保证了方法对调用者透明，即调用者只需要关心输入和输出，不关心开发者如何实现，提高代码的灵活性和封装性，利好多人协同开发

Part4:本单元中同学们实现了Junit测试方法，总结分析如何利用规格信息来更好的设计实现Junit测试，以及Junit测试检验代码实现与规格的一致性的效果

在测试顺序上，我们应由下到上进行测试，比如最基本的：addPerson，addTag等，在保证了这些方法的正确性后，我们再测试上层可能涉及到调用这些方法的方法，如：queryTagValueSum等
在测试覆盖度上，我们应根据规格，对所有前置条件分别对应地生成数据进行测试，保证方法能对各种输入都有正确响应
在一致性检验上，我们应根据规格，对不变式invariant，无副作用对象not_assignable，约束条件constraint，后置条件ensures进行运行前后结果的断言测试assert

Part5:本单元学习体会

1. JML实际上为编写代码减小了很多难度，程序的实现变得有迹可循，便于对照和检查
2. JML为测试提供了便利，便于根据前置条件，后置条件，副作用易于生成方法测试
3. 在采用规格化设计之后，程序的编写难点主要在于规格的编写上，一方面需要用户和开发端的沟通，另一方面需要用逻辑语言完备地描述方法的功能，避免疏漏
4. 即使按照JML编写出了代码，也有可能因为实现方式的不同而产生后置条件的疏漏，这就需要进行充分的测试