OO第三单元总结

OO第三单元总结

测试过程

黑箱测试和白箱测试

• 黑箱测试：是根据功能需求来测试程序是否按照预期工作,是要从用户的角度分析.尽量发现代码所表现的外部行为的错误.黑盒测试应该是由测试团队来完成的.根据某个给定的输入,应该能够理解并详细说明程序的预期输出

黑盒测试流程:
功能需求–>产生测试用例–>被测程序–>输出实际结果–>与预期结果比较–>分析功能是否实现

• 白箱测试：是测试人员要了解程序结构和处理过程,按照程序内部逻辑测试程序,检查程序中的每条通路是否按照预定要求正确工作.它主要的针对被测程序的源代码,测试着可以完全不考虑程序的功能

白箱测试流程:
源程序–>分析程序内部逻辑结构–>流程图–>制定测试用例–>被测程序–>执行路径–>覆盖情况分析

单元测试

• 单元测试：对软件中的最小可测单元在与其他程序其他部分相隔离的情况进行检查和验证的工作，这里的最小可测单元指的是类或者函数

功能测试

• 功能测试：对产品各个页面进行功能验证的过程，根据功能测试用例执行软件功能测试，逐一检查产品的各项功能是否正常，能否达到客户的要求

集成测试

• 集成测试：在单元测试的基础上，将所有模块按照设计要求组装成子系统或系统进行的测试活动。

压力测试

• 压力测试：模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等

回归测试

• 回归测试：对软件进行修正后进行的有选择的重新测试过程.一般要重复已用的测试用例.目的是检验软件在更改后所引起的错误,验证软件在修改后未引起不希望的有害效果

数据构造的策略

• 对于数据构造，我一直感觉比较玄乎（应该是理解不到位）。由于测试时src提供的是别人的代码，所以要检测出bug应当是自己所构造的图包含某些特定的子图，所以我的数据构造都是先确立一个大的图，然后再通过评测的结果进行删改。总体上没有什么具体的思路。

架构设计、图模型构建和维护策略

架构设计

• 同JML保持一致

图模型构建

• 本单元的作业引导我们自己去构建一个社交网络，与离散数学中图的概念和知识相吻合。在本单元作业中，每一个人可以看作是图中的一个点，而两个人之间的关系用边来表示。整个社交网络是一个无向图，我们可以在这个模型基础上对每个方法进行具象。

维护策略

维护是本单元作业的特色之一，因为基本上不维护就TLE社交网络的规模可能比较大，如果不进行维护的话，当输入中查询类的指令过于密集，就会进行多次的显式遍历以返回所需的查询量，从而导致CTLE

• HW-9：对blocksum和triplesum进行维护，即将这两个数据量作为MyNetwork的属性量，在调用查询方法时直接返回属性量的值，而将这些属性量的更新放置在其他方法中，可以节约查询的时间。例如对于blocksum的维护，即对连通分支的查询，应该在AP，AR和MR方法中进行维护。由此可见，如果要进行某个属性量的维护，应该在可能改变这个属性量的方法中进行维护，从而保证属性量的结果正确性。

• HW-10：本次作业维护的数据量更多，对MyPerson中的bestid和bestvalue进行维护；对MyTag中的valuesum以及agesum和agepow进行维护。维护的道理没有太大的区别，但是其中让我印象最深刻的就是对于valuesum的维护。在与同学进行讨论时，我一度认为维护这个属性量没有必要，因为我想当然觉得这条指令不会多次出现，归根结底还是意识不到位。这导致在互测结果公布前我看到我们房间基本都hack成功并感慨大家都好厉害的时候，丝毫没有意识到其实所有的刀都插在了我一个人头上哦吼吼。当然，这是一次很好的教训，以后在思考到用户相关需求的时候，我们应该做好充分的准备，对是否需要维护进行正确的选择。

• HW-11：本次作业相对前两次增加的代码没有进行特别的维护。

性能问题及规格与实现分离

性能问题

本单元作业我的性能问题实在是层出不穷

• HW-9 :第九次作业强测一开始我出现了3个CTLE，在重测之后发现少了两个，只有一个CTLE。一开始我还不服气，但后来当我发现我的问题之后，我觉得我的运气真是有够好，还能少错两个点。我错误的原因在于在dfs选择容器存储已访问节点的时候使用的是ArrayList而不是HashMap，这样就导致在判断是否contain的时候时间复杂度相对更高。当更换容器之后时间快了很多，从7000ms压缩到1000ms左右,通过了BUG修复。可见容器的选择十分重要，我们需要明确使用这个容器的目的是什么，并依此选择合适的容器。

• HW-10：第十次作业我又出现了CTLE，是因为没有对valuesum进行维护。维护之后通过了BUG修复。

• HW-11：第十一次作业没有出现性能问题，但是涉及到关键的容器选择，那就是在Person类中的信息数组应该选择用链表容器进行存储。因为JML规格规定对于每个人的信息数组，新来的信息要插在容器的头部，此时运用链表容器最为合适。这提示我们，JML规格告诉我们最终要实现的效果，但是实现过程中可以使用的方法多样，我们应该根据具体要求选择使代码性能最佳的容器。

规格与实现分离

谈到规格与实现分离，我认为规格与实现只不过是“形”离，而“神”未离。规格是给定的JML语言，而实现则是我们自己编写的代码。规格与实现分离的含义只不过是可能有些方法我们并未严格按照规格所给出的逻辑来进行书写。
举个例子，在NetWork的JML规格中，查询三角形个数的方法使用了三重循环。如果我们的代码中也通过三重循环来实现的话，虽然能够保证正确性且只需要在这一个地方进行计算，但是随着此类指令的增加，代码的运行效率会大大降低，这不是我们想看到的。
因此，我们不能完全被JML规格束缚住手脚，我们只需要明白JML规格要我们干什么事情，然后我们再通过思考和分析，实现最后的效果即可。还是拿查询三角形个数举例，我们并没有使用三重循环，而是给了MyNetwork一个属性并进行维护，这就是规格与实现分离。规格与实现分离是一个明智的选择，既能充分发挥JML的作用，也能融入我们自己的思考与判断，让代码变得更加高效。

Junit测试

规格信息是编写测试代码的最好根据。在编写测试代码的时候，我们要仔细阅读规格语言，并时刻关注一系列关键字，观察哪些量是能够改变的，哪些量是不能够被改变的。在编写测试时，一开始我忽略了深浅克隆的问题。如果不进行深克隆而直接通过get来执行整个操作过程，那么测试函数的编写就失去了意义，每一个assert一定会成立，因为比较的都是一个对象。只有实现深克隆，即创建两个相同的社交网络才能正确地完成测试，我认为这是理解中十分关键的一环。
总的来说，我认为测试不过就是自己编写数据加上对规格语言的翻译。但是这一过程中的难点在于翻译的过程，我们需要保证逻辑的正确性以及调用方法的合理性。

学习体会

本单元相比前两个单元难度下降很多，写代码的过程还算比较顺利，如果有不熟悉的算法可以及时进行复习巩固。架构设计也不需要费劲，课程组已经给出。本单元相对来讲最难的地方就在于debug的过程和及时维护的意识。同时，这个单元给我带来的最大收获就是知道了JML规格这种实现方法，给了编写程序的人一个可以依靠的模版。同时，JML规格还能够为编写测试的人提供便利，即当完全不知道被测试代码的情况下依然能够进行正确的测试编写。
总的来说，JML规格拓宽了我的视野，现在我才能够理解了JML规格的存在意义。