BUAA_OO_Unit3_Blog

22373124-李长佳 学生 2024-05-16 16:45:56

目录

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

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

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

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

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

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

数据构造有何策略

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

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

架构设计

img

第三单元的核心在于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编写出了代码,也有可能因为实现方式的不同而产生后置条件的疏漏,这就需要进行充分的测试
...全文
36 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复

301

社区成员

发帖
与我相关
我的任务
社区描述
2023年北航面向对象设计与构造
学习 高校
社区管理员
  • YannaZhang
  • CajZella
  • C_ecelia
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧