关于“OO第三单元总结”这件事

[22371207石伊聪]

关于本单元的测试过程

1. 黑箱测试与白箱测试

• 黑箱测试：测试者不关心程序的内部细节。只要对于测试者提供的合法输入，程序能产生符合规格的输出，那么程序就被认为是正确的。举例来说，OO的弱/中/强测，Junit测试点和互测均为黑箱测试。
• 白箱测试：测试者不仅希望程序通过黑箱测试，也希望通过了解源代码，根据程序的逻辑结构进行测试。单元测试就是一种白箱测试。

2. 单元测试，功能测试和集成测试

• 单元测试：针对软件中最小的可测试单元，如函数或方法的测试，旨在保证每个单元的实现的正确性

• 功能测试：验证程序的每个功能是否能实现规格所要求的功能

• 集成测试：将多个单元或模块集成在一起进行测试，以检查各单元的交互是否正常

3. 压力测试与回归测试

• 压力测试：通过模拟极端条件（超大数据量或高并发等情况）来对程序进行稳定性测试
• 回归测试：添加新功能或修复问题时进行的测试，目的是确保修改没有引发新的问题。Bug修复环节即需要执行回归测试。

4. 数据构造策略

1. 手动构造特殊数据（如空图，完全图等）来测试边界条件的程序表现
2. 随机生成数据
3. 手动构造包含大量特定指令（如qtvs）的数据来测试程序性能

关于架构设计

图的结构

我采用与规格书说的道理类似的方式存储图的结构：

// MyNetwork.java
private final HashMap<Integer, MyPerson> personMap = new HashMap<>();
// MyPerson.java
private final HashMap<Person, Integer> acquaintance = new HashMap<>();

性能问题与优化

三次作业中均有需要优化性能的指令

1. qci/qbs

   采用并查集维护连通子图

2. qts

   在添加/删除关系时维护qts的缓存

3. qtvs

​ 添加/删除关系时更新受影响的tag

4. qsp

​ 采用BFS

关于BUG修复

得益于JML的强大约束力，本单元的bug主要体现在性能问题导致的CPU超时，而不是实现错误。只需根据flamegraph找到耗时较多的方法并进行针对性优化即可解决。

关于Junit测试

测试主体根据JML的约束一一翻译即可：保证不变量不变，保证改变的量符合规格。

我认为难点在于测试用例的生成，要采用人工编写和随机生成相结合的方法才能覆盖更多的情况。

关于学习体会

三次作业的内容大同小异，学习体验大同小异，“读JML->写代码->优化性能”的流程也大同小异。

通过三次作业的学习，我“深刻”地认识到了JML和契约式编程的重要意义，太好了。