BUAA-2024春-OO-Unit3总结

1 测试过程

1.1 黑箱测试与白箱测试

黑箱测试

基于功能需求，不关心内部实现逻辑的测试方式。它通常对功能模块的输入输出进行测试，无需了解代码细节，贴近用户视角，但可能难以分析内部逻辑缺陷。例如评测机。

白箱测试

基于内部逻辑结构，分析程序代码的测试方法。它需要了解被测试软件的内部结构和工作原理，通过检查内部的逻辑、循环、分支等来设计测试，并覆盖各种可能，从而深入检测代码逻辑的缺陷，但测试成本较高。在$Junit$中我们可以进行白箱测试。

1.2 主要测试类型

单元测试

验证单个功能模块或最小可测试单元的测试。通常由开发人员完成，用于发现编码和详细设计缺陷。一般是白盒测试，“代码走读”就属于单元测试。

功能测试

验证软件系统功能是否符合需求的测试。

集成测试

基于单元测试，验证模块之间或子系统之间接口和交互的测试。通常包含非渐增测试（定位错误较困难）和渐增测试。

压力测试

在负载超出正常范围的条件下进行的性能和稳定性测试。强测与互测中对于$qsp$,$qcs$等大量连续的使用就属于此类测试。

回归测试

在修改或修复软件后验证新增和修改前的功能是否正常的测试，课程中主要体现在$bug$修复环节。

1.3 数据构造

先对$network$加入一定数量的$Person$，然后随机添加$Person$之间的$relation$，从而得到社交图。在$hw11$中，还需要添加$emojiId$后再进行会更改$emojiHeat$的操作。

构造一些边界值，比如tag的size为0等情况

增大数据规模，在上述思路中主要是增加$Person$的数量和增加添改$relation$的次数。

2 架构

参考往届博客和讨论区，添加了$DisjointSet$​类

• $qci$ 使用$DisjointSet$中并查集的$find$
• $qbs$ 在$DisjointSet$类中缓存维护，当$merge$时加1，当$mr$需要重构时减1
• $qts$ 在$DisjointSet$类中缓存维护，当$ar$时遍历添加$i{d}_1$和$i{d}_2$的共友个数，$mr$时删除
• $qtvs,qtav$ 在$MyTag$类中缓存维护，方差根据公式$\frac{{\sum }_{k=1}^n{x}^2-2\cdot n\cdot E(x)+n\cdot E^2(x)}{n}$计算，每当$att$和$dft$时进行改变（由于取整精度，若使用$D(x)=E(x^2)-E^2(x)$，数据规模大时与标准答案会有1的误差）
• $qba,qcs$ $MyPerson$类中维护$bestId$变量，计算组合数时检查每个$A$的$bestId$,其对应的$B$是否属于$Persons$且$bestId$是否对应$A$,最后除以2即为所求
• $qsp$ 在$DisjointSet$类中维护了$graph$，使用$bfs$算法求出最短路。其中$graph$采用了$HashMap$结构，$key$是$DisjointSet$中的每个点，$value$采用$HashSet$，表达$key$的点$isLinked$的点的集合

3 性能

$hw9$ 写错了$dfs$算法，使其只遍历了一层就结束，从而$wa$

$hw10$ 对$bfs$的使用较为低效致使$ctle$。初始选择了$ArrayList$作为$queue$，使用$java$自带的$add$和$remove$操作代替$queue$的$add$和$poll$，这也使时间复杂度从$O(1)$变为$O(n^2)$(在最坏情况下)；此外，在实现$tag$的$valueSum$，由于认为查询次数较少而没有进行维护，只是在每次查询时进行计算，并且采用朴素的双重循环操作，从而也致使了$ctle$​的产生

规格与实现分离，在通读规格理解需求后，就主要体现在数据结构和算法层面。

• 在$jml$规格中，通常采用$int[]$型等数组类型，而在本单元作业中，对应$id$的查找操作较为频繁，故基于时间考量，对该存储类型基本采用$HashMap$和$HashSet$。这次作业$bug$频出有一部分原因就是没有理解$ArrayList$的实现机制，它的$remove()$操作的复杂度为$O(n)$，在删除指定变量后，会将后续变量前移，耗费的时间复杂度是较高的，在限制时间的情况下需要谨慎使用。也因此在$hw11$中将$MyPerson$中本来使用的$ArrayList$<$Message$>换为了$LinkedList$，在此过程中还学习到了$removeIf$以简化代码。

• $jml$规格中对于$valueSum$等的查询用到了多层循环结构，如果不做其他处理，面对多次查询相关值的数据，必定将导致$tle$。对于这些指令，一部分可以通过改进算法来改善，例如上一节提及的$qsp$；一部分则需要通过缓存以实现，及新增实例变量，每当遇到修改条件时及时修正，从而使得不必在连续查询时反复重新计算。

4 $Junit$​

构造测试数据时，需要完整覆盖$jml$的情况，对于各种异常和表现均需要测试到。

在检查$pure$等类似需求时，可以在创建对象之处就建立一个副本，测试方法以外的操作完全相同，但同时在$MyNetwork$传入$MyPerson$时，需要注意传入副本的需要是$MyPerson$的副本。

在测试过程中，检验$ensures$要求的正确性时不考虑优化，完全按照规格的方法实现。

在实际使用过程中，由于是基于$jml$规格进行测试，因此在写$Junit$时实现逻辑是对$jml$的复现，与被测试代码不同，从而发现了一系列笔误，更正了自动补全时误写的变量和异常。

5 学习体会

在完成作业时，更多的收获是了解$java$中$ArrayList$等容器的具体实现以及图数据结构的复习，领悟到缓存等有关降低时间复杂度的操作。对于$jml$规格的感受更多体现在$Junit$的编写测试中，完全按照规格的实现进行测试更有利于查找代码中的错误。

而$jml$的编写操作则是在讨论课中进一步体会，(题目为编写“将$word1$转换为$word2$所使用的最少操作数”$jml$规格)，即使经过了组内讨论，有成员已经提出了很好的思路（仿照$hw10$中的最小路径编写）,我在自己实现时针对插入、查找、删除操作分别编写函数，然后苦恼于如何组合和传参，但当看到其他组员编写的即为简练的$jml$规格时，我意识到自己仍困于具体的实现和方法的优化，而事实上，$jml$只是一份使用逻辑语言的需求书，它需要做到的是逻辑严密，需求覆盖完备，但并不需要实现，就像最短路径规格中并没有涵盖具体的从A到B的方法，它只是设定了路径各点$isLinked$的需求，从这个意义上，相较于其他单元，$jml$是一份不会引起歧义的指导书。