2024BUAA-OO-UNIT3总结

[袁嘉22230606]

本单元测试过程

黑盒测试：测试人员将软件视为一个黑盒子，只关注输入和输出之间的关系。由于并不需要了解内部结构和实现逻辑，所以测试数据在压力过小时可能无法验证正确性。

白盒测试：测试人员根据软件的内部实现原理，设计测试用例并验证软件的每个逻辑路径是否正确。这样的测试更有可能找到问题，但是过于针对软件逻辑，可能忽略不同功能间联系细节出现的问题，导致测试不完整。

不同具体测试方法

单元测试：单元测试又称为模块测试，是指针对系统最小单元进行测试。其目的是检验软件基本组成单位的正确性。我认为在软件重构过程中单元测试是执行最多的测试方式。

功能测试：通过模拟用户的操作执行测试。黑盒测试中可能调用软件留有的测试专用接口。而功能测试完全从用户接触层面出发，保证软件的正确、可靠、易用。

集成测试：是将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。

压力测试：用于确定系统在高负载下的行为和性能极限。验证系统的稳定性和可靠性、识别系统的瓶颈问题、确保系统在极限情况下的数据完整性和错误处理机制。在压力测试中，需要让系统超负荷运作，通过观察其反应来了解其弹性和极限性能。

回归测试：回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

数据构造

由上述说过的原因，不管是随机生成数据（类似黑盒测试）还是手动构造数据（类似白盒测试）都可能存在缺漏。我的数据构造策略是在随机生成数据时手动涵盖极端情况。如：完全图，空图，以及数值的最大值，0，和中间的随机数值。
在随机数据构造中，参数的大小也影响测试效果。如：在100个点的图中，若只随机生成20条边，那么这一百个点永远无法连接起来。而若在100个点中随机生成一万条边，那么极大的可能这个图是完全图，哪一种都无法测试全面。而若点和边的数量都随机，那么在组数不多的测试中也很有可能无法完全测试到。

本单元架构设计：

使用邻接表存储图结构，经实测，qbs使用深搜实现可以满足性能要求，所以没有采用重建并查集。而对于qts、qcs，则使用维护的方式保证查询效率。在维护过程中，可能有多个不同方法会更改维护值，而这不能从jml中读出，需要自己进行判断。

出现的性能问题：

hw9中由于对作业理解不到位，出现了完全翻译jml，导致时间复杂度爆炸的错误。还有并没有翻译jml，但是由于实现出现问题，导致超时的错误。在这单元的作业中，方法的复杂度控制在n方以下基本就不会超时。
我认为规格只是一种表示程序逻辑的语言。虽然jml可以帮助我们编写单元测试，然而毕竟jml无法自动编写并完成测试，也就是jml的目的不是测试本身。jml相比于自然语言，可以更加准确的传达程序的逻辑。例如在 hw11 message 中的 tag 存储的是tag的引用。这表明在删除这个tag之后仍然可以通过原来的tag发送消息。如果用自然语言表述，就很容易出现疏漏了。

规格和实现分离，使得完全依照jml测试会存在困难。比如对于数组的查询，选用hashMap存储id和对象，可以大幅缩减通过id查找的复杂度。然而倘若需要在测试时比较前后变化，获取这个数组，那么在执行方法前后多次调用getvalues() 可能返回不同顺序的内容，导致assert失败。

根据jml编写junit，完全翻译jml就可以保证内容完全正确。如exist和forall表述中，使用循环遍历，并且设置flag位，可以完美表述jml的逻辑。对于需要在执行前后保持对象不变的判断，由于获取方法可能返回的是浅克隆，使得junit测试本身必须保存一份原来内容的拷贝。在junit内部实现对象本身不支持的深克隆可能有些复杂。在这一单元的作业中，我使用镜像network。对于每一个person，克隆创建一个新的person，使得其中的初始值完全相同。之后原始person在network对象内构造，而新克隆的person使用一个新的镜像network。这个network不参与junit的评测，而只是在数据准备阶段让克隆出来的person隐含的内容与原始person相同。例如：每一个person会记录自己的邻居。然而我们无法直接更改邻居这个数组。只能在镜像network中进行相同的操作，使得每一个对应person的邻居数组相同，而对象的引用都不同，这样得到一个深克隆的对象数组。

学习体会

jml这个工具可能不是我想象中的完美工具，不过学习jml也让我体会到不同测试的重要性。在几万行的随机数据测试都没有问题的程序中找出的bug，结果发现通过单元测试可以非常容易的定位并解决。这一单元也改变了我原来“都用java了就别考虑性能了”的不太成熟的认知。对于软件开发过程中的性能和效率有了更多的关注。