OO课程第三单元总结

OO第三单元总结

测试过程

黑盒测试，白盒测试

我理解的黑盒测试是：

• 测试人员不关心软件内部的逻辑结构和代码，只关注软件的输入和输出。
• 测试人员像普通用户一样，通过给软件输入数据，检查输出的结果是否符合预期。

白盒测试是：

• 测试人员需要了解软件的内部逻辑结构、代码和数据结构。
• 测试人员通过检查代码来查找程序中的错误，如检查代码的逻辑、路径和条件等。

（好比互测时有人直接交样例，有人还要读代码

本单元中，我综合应用了这两种方式：用同学的评测机进行了黑盒测试；同时阅读自己的代码看看是否符合JML规范，进行白盒测试

各种测试

• 单元测试：我理解的单元测试就像是我们在pre课程中写的Junit，为每一个方法都编写测试函数进行测试。本单元三次作业里也都要求对某一种方法进行Juit测试。
• 功能测试：旨在全面验证软件产品的各项功能是否按照需求规格说明书和设计文档的要求正确实现。功能测试确保系统能够执行用户所期望的各项工作，从而满足业务需求并达到预定的质量标准。在进行功能测试时，测试人员会模拟用户操作，向软件输入各种预期的数据和指令，然后观察并验证系统的输出是否符合预期结果。这一过程覆盖了软件产品的所有功能模块和业务流程，以确保系统的完整性、准确性和稳定性。
• 集成测试：可能所有方法单独运行都没问题，组合起来就出bug，此时需要考虑对各种方法进行组合测试（但是我觉得出现这种情况的根本原因还是在于小的单元有问题）
• 压力测试：本单元是真的感受到压力测试的恐怖了。。。hw10里面就被强测的压测搞出CTLE了——模拟一堆极端样例，去测试代码能否还能如预期所料那样运行。
• 回归测试：这个就像是我们的bug修复环节，修好bug后再测一遍。

数据构造

本单元中除了评测机随机生成的数据，我还有如下的思路自己构造一些样例：

1. 针对每次作业测试当次作业新增的指令——默认前面的作业是没有问题的；
2. 构造一些极端的样例，但是本地环境运行的挺快的，看不出超时问题；

架构设计

由于本单元给出了JML规格，似乎大家能自己发挥的空间并不是很多？唯一有区别的一点可能是我在第一次作业时除了维护一个邻接表外还维护了一个并查集，用于快速判断两点是否连通。

我想本单元的重点并不在于大家的架构，而在于动态维护的意识。

性能——动态维护

本单元虽然给出了JML规格，但是其实只进行了行为的约束，而没有对实现方式进行规范。

本单元的性能差异主要体现在对各种数据的动态维护与索引查找上上：

1. 很多对象都有一个id字段，且唯一，所以可以用Map去存这些对象，方便我们快速查找；
2. qts,qbs,qtvs,qtav,qsv这几个指令所查询的数据都可以在程序运行过程中，增删改时进行维护，方便以O（1)的复杂度进行查找；
3. 有些维护成本高的地方，可以采用脏位的思想进行维护：只有改变过，并且再次被查找时才进行计算。

bug分析

我的bug就出在了hw10里，主要是上述第二点的问题，我忘记了动态维护，导致CTLE

Junit测试

hw9时候因为Junit而提交了10次，正好用光了次数，后面两次作业Junit测试也磕磕绊绊，主要有如下两点原因：

1. 构造的数据强度不够，往往一开始由于偷懒而随便写几个点以为能混过去，后面还要把数据强度改上去。
2. 忽略了方法中的 pure 等副作用限制或检查不足。对于副作用的检查，不仅要采用类似影子电梯式的构造方法防止浅拷贝，还要对每一属性进行检查，同时对数据生成也要保证有所覆盖。

心得体会

本单元的压力骤减，较之赫赫有名的前两个单元，本单元所占用的时间没有那么多。

深入学习JML后，我对其在软件开发中的作用有了更深刻的认识。JML作为一种行为接口规格语言，不仅使代码逻辑更加清晰，更有助于团队成员之间的理解和沟通。它让我意识到规格化编程的重要性，不仅提高了代码的可读性和可维护性，也大大减少了潜在的错误和冲突。通过掌握JML，我能够更严谨地编写代码，确保软件的质量和稳定性。这次学习经历让我受益匪浅，为未来的软件开发之路奠定了坚实的基础。

但是本单元的体验感有待提升，主要有这样几个地方我认为需要改进：

1. 课程设计的不到位，指导书频繁修改，强测居然还能重测？？？我认为应当让本单元作业体系成熟后再来发布，而不是拿学生的时间来试错；
2. 作业要求不合理：既然作业考察算法的时间复杂度，那是不是应该明确指出各个方法要求我们实现复杂度为多少的算法？不然优化的方式可多了，我们也不知道什么样的算法能通过强测。
3. 代码风格限制：JML规格都写出超过500行了。。。那一个network类里面缝合了太多业务，我觉得有些臃肿。