BUAA OO UNIT3 总结

黄弘烨-22371430 学生 2024-05-19 14:06:06

测试过程

黑箱测试与白箱测试：
- 黑箱测试，只需要测试程序的输出是否与输入相符合，而程序运行的过程与细节不需要了解。
- 白箱测试则相反，需要验证程序运行的流程与逻辑是否正确。确保每个部分都是正确的。
对单元测试、功能测试、集成测试、压力测试、回归测试的理解：
- 单元测试：
  指对小部分代码的测试，一般测试的单位是函数、方法与某个类。
- 功能测试：
  测试某个模块的功能，这个模块能否获得正确的结果
- 集成测试：
  与单元测试相对，用于验证各个单元之间的联系配合是否正确。
- 压力测试：
  用于测试极端条件下程序是否运行正确。
- 回归测试：
  在某个模块变更后重新测试，确保变更之后不会影响其他部分的内容和程序的正确性。
数据构造：
采用随机生成数据的方式，随机生成一定的人数和关系数，再根据人数和关系数随机生成人与关系。
生成的关系的值可正可负，进而保证可以存在删边的情况。
通过testNum次测试确保正确性。

架构设计

图模型构建：
大致按照JML的基本要求。在数据结构方面基本使用HashMap，以id为索引查找顶点和边。
维护策略：
对于新增加的功能，根据JML直接在类内添加方法。
时间复杂度如果不高，则直接采取暴力的方式解决。但由于时间复杂度的限制，个别函数的暴力解的时间复杂度会达到 $O(n^2)$ 或者以上，所以需要维护个别的变量。
- queryCircle和queryBlockSum，这是经典的无向图联通问题，使用dfs即可满足性能要求，在此之上的并查集可以不做优化。
- tripleSum，三元组，典型的维护变量，只需要在添加和删除边的时候维护即可。
- bestAcquaintance，直接维护即可，会导致人的关系变更的只有Person内的add、del和modify三种操作，不要遗漏即可完整维护。
  
  坑点：Integer的比较在(-128, 127)之间是可以直接比较的（JAVA自带实例化，类似BigInteger.one），但是在此之上的数值比较相等必须要用equals！！
- coupleSum：在维护了bestAcquaintance之后，查询复杂度可以降到O(n)
- tagValueSum：比较麻烦，Tag内所有边权之和，由于不仅加减人会影响，中途改变Tag内的人际关系也会影响。只能直接查询，复杂度O(n^2)会超时。可以通过遍历点+边的方式，将复杂度变更为O(n*m)，由于数据的特殊限制，边普遍远少于点，这样可以通过。

性能问题

总的来说因为自己大（tou）意（lan），有一些地方可以优化但是懒得优化（其实是我觉得这单元大概不是考算法），所以有一些地方超时了。稍加修改即可通过。
大意与轻敌才是最大的敌人！！
同时，在繁杂的异常处理和各种特殊情况的处理过程中，我们很容易可以发现规格分离的优势之处。通过规格分离，异常处理变得有迹可循，每个地方都限制死了副作用、入口与出口，所有的异常都已经被规划好。在某个函数中，我们不必再过多担忧诸如零值、空值之类的特殊异常情况，也避免了大量因为遗忘特殊情况导致的低级bug。

JUNIT相关

数据一定要均匀
不管是大的数据还是小的数据，都有测试的价值所在，测试的组数也不是越多越好，总之一定要均匀合适！

血的教训：由于过于追求数据的复杂性，生成的图永远较为复杂，进而导致测不出某个简单图才能测出的bug，被单个junit测试点卡了几个小时！！
注意相对顺序
在运用断言检测条件时，一定要注意各个条件之间的蕴含、先后关系。
关注深浅克隆