buaa_oo第三单元小结

[22371016-黄圣宇]

buaa_oo第三单元小结

黑箱、白箱测试等：

对于这两种测试的民间解释是白箱是对着代码找bug，黑箱则是对着输出找bug。

而较为正式的解释为，黑盒测试是一种软件测试方法，其中测试人员只关注软件的输入和输出是否符合预期，而不考虑内部的实现细节或代码结构。白盒测试也是软件测试的一种方法，它涉及对软件内部结构和代码的详细检查，目标是评估系统的内部工作方式，验证各个组件的正确性，并确保代码符合编码标准。。

与黑盒测试不同，白盒测试需要测试人员了解软件的内部工作原理和代码逻辑。我们在测试时一般都是写一堆print来推出bug大概的位置，然后再进行代码的分析部分，即白箱测试。本单元总体需要实现部分逻辑很清楚，对性能要求总体在O(n)，这要求使用一些算法，这也相应增加了白箱测试时盯着代码找逻辑漏洞的难度。当然如果将每次评测与互测看作测试，那就是黑箱测试。

对于课程要求中提到的测试，这里简单说一下个人的理解。

单元测试是对代码最小单元的验证，可以理解为是每个函数或方法的测试，通常被测函数与其他函数耦合度较小。

功能测试则比较字面意思了，是验证程序功能，验证软件系统的功能是否符合规格说明和用户需求，即系统能够执行预期的操作并产生预期的结果。

集成测试主要关注系统中各个组件之间的接口、数据传递和交互行为，验证不同组件或模块在相互交互和集成后是否能够正常工作。一般是在各个模块开发完成后，将它们集成在一起，测试它们之间的集成点和交互行为，以确保系统作为一个整体能够正常运行。

压力测试用于评估系统在特定负载条件下的性能表现和稳定性。它主要关注系统在高负载、高并发或长时间运行的情况下的性能表现，以确定系统的极限容量和可能的性能瓶颈。对于强测中对单个方法卡tle的数据点，就属于压力测试。

回归测试用于确认在进行了修改、修复或增加新功能后，软件的原有功能是否仍然正常工作。它旨在确保新的更改没有破坏现有功能，并且没有引入新的错误或问题。

 

 

架构设计

第一次作业

第一次作业相较于往年直接加入了modifyRelation，增加了不少工作量。关于jml本身的内容这里不多赘述，主要讲一下如何维护isCircle以及blockSum。这里有两种方式。

第一种是宽搜。首先，遇到addPerson，block Sum++。遇到加关系，首先进行宽搜，如果两个人原本就有路径，blockSum不变，否则blockSum--。遇到删除关系，先删边，再宽搜遍历，如果找不到，就blockSum++。遇到查询isCircle，则宽搜遍历。这里由于设置vis数组，（注意不能用ArrayList，因为ArrayList的查询操作复杂度是O(n)，而hashset或是数组则为O(1)）整体的复杂度控制在O(n)，不会超时，虽然相较于第二种方法时间开销更大，但不影响通过测试。

第二种是用并查集。首先需要设置并维护一个unionFind的hashmap数组，key表示本人id，value表示其根的id。这里需要注意搭配路径压缩，并且这里需要边搜边压缩，不能采用创建一个stack的方式最后再一起压缩。

即如下图：

 

最麻烦的是维护并查集，首先，每次addPerson，unionFind.put(id, id)并且blockSum++。每次addRelation需要先检查两点是否以前就有路径可到达，若有，则不用管，若无，则blockSum--。最麻烦的在于删除关系，这里采用深搜的方式。首先默认与这两个点相关的可到达的点的unionFind全部无效，然后通过深搜，将id1可到达的点全部以id1为根（包括id1自己）。最后判断id2的根是否为id1，如果不是，那么blockSum++，再重复与id1类似操作，将id2可到达的点都设置为以id2为根。这样就算是维护好了。

 

 

本次作业还有一个tripleSum需要被维护，但较容易实现，这里不多赘述。

第二次作业

本次作业的难点主要在于queryShortestPath宽搜的实现。核心的代码如下：

 

这里需要注意进行一个小优化，即对已经搜索过的两点的最短路可以做一个记录，但是在任意关系的增加或删除都需要清空该记录。

本次作业需要动态维护的较多，但都容易实现。基本如果遇到两个for循环的方法，都需要动态维护。

 

第三次作业

本次src的作业量较前两次少了很多，主要在于本次没有方法需要动态维护，只需要看懂jml即可，但难在test的编写。需要考虑到各种message，以及深克隆判断前后容器内元素是否有按照需要更改删除。

 

性能问题与bug修复

关于性能方面，主要设计各种算法以及容器的选择。本人主要依靠hashmap与hashset，算法方面有并查集、深搜、宽搜，当然如果不嫌麻烦，在维护bestAcquaintance时，可以用大顶堆的方式，这样方面增加或删除关系时方便。

本单元遇到的bug大多数是卡tle，小部分是因为逻辑先后问题或是看错。

 

规格与实现分离

这里很多jml涉及了多重for循环，直接按照原本jml实现肯定是超时的，所以具体的实现有所不同。这次作业复杂度在O(n)范围内才可通过。并且，在压缩代码行数方面提出将jml语言中异常处理先进行，可以省去判断条件的多余，不仅节约时间还节约行数。

 

Junit测试

这里的数据构造主要是对各种图的涉及以及循环次数的设计。对于全零图、完全图、以及稠密图、稀疏图都需要考虑到。个人采用的是随机数的生成，大致将图分为两点间连线的概率为0%、10%、20%……100%，每个类型的图都循环60次左右即可通过测试。

 

学习体会

在这个单元的学习过程中，投入的时间精力相比于前两单元有所减少，但也收获了一些知识。比如对JML的理解和实践，以及解决图论问题的方法都有了提高。但实际操作后发现，图论知识对于本单元来说仅仅是一个可有可无的东西，比如原本以为会用到Dijkstra算法等，都因为一些特殊的限制如边长恒为1等原因没有使用。当然想必是为了给我们减负也是很好，毕竟大一已经有过c语言的折磨了。