BUAA_OO第三单元总结

张若辰-22230601 学生 2024-05-15 21:19:52

本单元的测试
黑箱测试和白箱测试
对单元测试、功能测试、集成测试、压力测试、回归测试的理解
数据构造策略
本单元的架构设计，以及图模型构建和维护策略
作业中出现的性能问题及其修复情况，兼谈规格与实现分离
利用规格信息设计实现Junit测试
本单元学习体会

本单元的测试

黑箱测试和白箱测试

根据我在网络的查询和理解，我得到“黑箱测试是一种功能测试，测试人员只关注软件的输入和输出，而不考虑内部的实现细节”而“白箱测试也称为结构测试或逻辑测试，测试人员需要了解软件的内部结构和源代码”，相比较来看，我认为白箱测试是执行者在完成代码后对于代码的每一个方法想要实现的功能的检测，由于了解软件的内部结构和源代码，可以全面的进行覆盖率分析，保证每一行代码的正确性；而黑箱测试则是一个验收者对于代码功能的最终检测，虽然不知道每一行的细节，但可以对最终想要实现的内容进行压力、边界的测试，在测试过程中专注于代码要完成的需求。

对单元测试、功能测试、集成测试、压力测试、回归测试的理解

单元测试是指对代码某一个模块或方法的测试，验证方法是否正确；功能测试是指对于实现功能能的最小单元进行测试，观察功能的实现；集成测试是指将不同的模块聚合在一起验证实现是否正确；压力测试是指对于大规模的数据或边缘测试是否可以满足要求；而回归测试是代码在修改过后是否还能实现原有功能。

数据构造策略

在三次迭代中，我在第一次测试中除了junit外没有进行自己的测试，只是使用了大佬分享的测评机；由于在第一次测试收获了惨痛的结果，开始对问题进行分析，并在第二次作业中进行了综合junit和测评机的测试，并在第三次作业中对于测评机进行了迭代，完成了第三单元的测试。

其中在junit的测试中，我主要针对的是需要的方法构造测试数据，queryTripleSum、queryCoupleSum和deleteColdEmoji在数据构造上各有不同，如queryTripleSum、queryCoupleSum重点在于构造人和人之间的关系，要满足生成的图达到一定的多样性和复杂性才可以更好的而完成任务，而deleteColdEmoji则存在两个人和关系即可，重点在于message构造的多样性，要考虑到不同的message的情况。但这些经验都是根据官方的测试点得来，事实上如果junit都要提交三、四遍才能通过测试，我很难想象我独立进行的代码测试到底有多大的可靠性，因此我对junit的强度抱有一定的怀疑态度（主要是对我目前构造数据能力强度的怀疑）。

在第一次作业中，我在deleteRelation时只删除了单方向的（原意并非，没想到代码写两年了会出现这么幼稚的错误），后来发现错误使我感受到这样的问题只要自己进行测试对拍，是百分百能找到的，于是开始了第二次作业完成的测评机。在生成数据时，我考虑到数据生成的强度，对personId进行存储，主要测试了图相关的指令，生成了稀疏图和稠密图，进行大量测试，没有发现问题，而对于简单的add、delete方法，我使用了junit进行测试，确保正确性。第三次作业中，主要测试message相关指令，我选择生成少量person，以及大量多样的message，并通过存储messageId确保sendMessage可以成功发送信息，并在发送过程中随机穿插各种指令，有效发现了问题（指发现了一个jml阅读bug以及两个让人尬得抠脚的bug）。然而数据构造也并非全面，在由于messageId进行了保存，后续在别人的测评机上发现了message_id_not_found并没有正确实现，可见数据构造还是很考验水平的，在数据生成之初没有考虑到的问题，在测试时即使增大数据量也无法实现相应的功能。个人觉得考虑的完备性即使是面对这样一个简单的任务也还是有一定难度的，比较简单的解决办法是利用不同同学生成的数据，集思广益，不同的人生成数据的思路可能完全不一样。这样也可以减少遗漏。

本单元的架构设计，以及图模型构建和维护策略

根据课程组的接口，我实现了以上8个类，除MyMap外均为官方接口的实现，我还实现了Acquaintance类、Counter类（官方提示）以及自定义的比较器（实现TreeMap），其中myMap通过HashMap<Integer,HashSet>维护一张无向图，用来实现图的相关算法（参考讨论区的大佬）。其中几个要点是容器的选择、动态维护与否以及时机，重要的是时间复杂度的分析，从讨论区也学到很多。

作业中出现的性能问题及其修复情况，兼谈规格与实现分离

在第一次作业中，我阅读完jml后盲目的按照规格实现功能，在基本全部完成后即将测试时才迟迟考虑到时间复杂度等问题（？），连夜在博客、讨论区、舍友学习，最后实现了并查集维护好友的连通图以及删除关系后bfs重建关系，修改了容器的错误选择，领略了动态维护的思想，虽然结果差强人意，不过确实从一周的一波三折里学到了不少。随后第二次作业就丝滑了许多，查询最短路径使用双向bfs实现，tripleSum等在学会动态维护的思想后自己也在变量发生变化时尽量进行动态维护，尽管因为没有动态维护tagValueSum而失掉了一个测试点的分数，但对比同一个测试点动态维护前后的运行时间长度之差之巨大，也从更可视化的角度感受到动态维护的必要性。第三次作业可能为数不多的要注意的就是容器的选择（时间）以及大量重复代码可能导致的笔误（正确性）。

利用规格信息设计实现Junit测试

这周让人痛苦的一部分可以说是junit了，第二次作业提交了6次才通过全部测试点。Junit测试中，实现方法是依照jml内容的，比如queryTripleSum的三重循环和真正实现的动态维护，可以说jml提供了测试思路。然而我认为一个好的测试并不是看着jml就能完成的，就好比第二次作业中我们需要生成多样的图。根据我的经验，我生成了稀疏图、稠密图、全连通图和不连通图才通过了测试，仅仅是这样简单的一个方法就需要耗费心机的构造数据，想做好junit还是很困难的，在测试过程中利用到覆盖利率工具可能实现更好的效果，但也不能保证是一个全面的测试。一个单元的体会下来，先是发掘测试的重要，接着怀疑测试有多大概率能排查出问题，最后感叹测试既有作用、也可能需要比完成作业更多的智慧和精力。