面向对象第三单元作业总结

[不想打代码QAQ]

序

本次作业围绕JML语言展开（完形填空）

总体设计了一个社交网络，综合了各种java常见用法与一部分算法，可以用两个词概括：规范， 复杂度

就是在满足规范条件的前提下尽可能降低复杂度

一，黑箱测试、白箱测试

黑箱测试

黑箱测试，也称为功能测试或数据驱动测试，其核心思想是将被测软件视为一个“黑箱”，测试人员无需了解软件内部的结构和工作原理。这种测试完全基于软件的外部行为和规格说明书来进行，目的是验证软件是否能够正确地执行其规定功能，即输入是否能产生预期的输出。测试用例的设计主要依据软件的需求规格说明，关注的是软件的界面操作、业务流程、系统间的交互以及用户的角度体验。黑箱测试的优点在于它独立于软件的内部实现，即使软件内部结构发生变化，只要外部功能不变，测试用例仍然有效。

白箱测试

白箱测试，又称结构测试或逻辑驱动测试，与黑箱测试相反，它要求测试人员对软件的内部结构和代码逻辑有深入的了解。在这一过程中，测试者会直接查看和分析源代码，设计测试用例以覆盖尽可能多的代码路径、分支、循环和条件，确保每一部分的代码都经过验证。白箱测试旨在发现编程错误、逻辑错误、安全漏洞等问题，强调的是代码覆盖率和路径覆盖。这种方法有助于提高软件的可靠性和安全性，因为它是从内部结构出发查找潜在问题。

区别分析

• 测试视角：黑箱测试关注外在表现，白箱测试关注内部结构。
• 测试依据：黑箱测试依据功能需求，白箱测试依据代码逻辑。
• 测试目的：两者共同目标是保证软件质量，但黑盒侧重功能正确性，白盒侧重代码质量和安全性。
• 适用阶段：黑箱测试适用于后期的系统测试和验收测试，白箱测试更适用于早期的单元测试和集成测试。

二，各类测试

单元测试（Unit Testing）

• 目的：验证软件中最基本的可测试单元（如函数、类、方法）的正确性。
• 特点：粒度最小，通常由开发人员编写，使用测试框架自动执行，可快速定位错误。
• 方法：白盒测试为主，关注代码逻辑和边界条件。

功能测试（Functional Testing）

• 目的：确保软件的功能符合用户需求和设计规范。
• 特点：从用户角度出发，不关心内部结构，关注整个系统的功能表现。
• 方法：黑盒测试为主，依据需求文档设计测试用例，验证输出是否符合预期。

集成测试（Integration Testing）

• 目的：检查不同模块或服务在组合在一起时能否协同工作，识别接口间的问题。
• 特点：介于单元测试和系统测试之间，验证模块间的交互。
• 方法：可以包括黑盒和白盒测试，逐步集成并测试模块集合。

压力测试（Stress Testing）

• 目的：评估系统在超出正常操作负载条件下的行为和性能极限。
• 特点：模拟高并发访问、大数据量处理等极端情况，检测系统的稳定性和健壮性。
• 方法：通过增加系统负载直至达到崩溃点，观察系统响应时间和资源使用情况。

回归测试（Regression Testing）

• 目的：在软件修改或新增功能后，重新执行之前已通过的测试用例，确认现有功能未受影响。
• 特点：自动化执行较为常见，确保软件的持续稳定性。
• 方法：选择之前成功运行的测试套件，尤其是与修改相关的部分，进行重复测试。

三，数据构造策略

本次作业我的数据构造策略为逐步迭代

就是先对基础功能进行测试，比如加人，加tag，然后根据依赖性逐步加入复杂功能，这样就可以保证功能正确性

但这样的测试并不完全，这只能提高代码覆盖率，不能提高样例覆盖率。所以，针对这一问题，我会对一些边值条件进行单独测试，来提高整体覆盖率，使得测试更加完善

在测试中，我更多倾向于白箱测试，毕竟代码是自己写的，更能知道问题可能在什么方向

四，设计架构

全部类：

具体实现：

network：

这个类完成了程序的主体工作，包括人之间的交互，查询数据，发送信息等

person类：

这个类负责存储人（节点）相关的信息

tag：

这相当于一群人的集合，没什么特别的

五，设计实现细节

这次作业是典型的图相关的数据结构，我采用了存节点的方式存储

但与之相应的，会产生的问题就是如何查找联通

如果使用暴力深搜，那么每次查找时间成本过高，必然不合理

那么，就应该维护一定的数据来使得查找成本转移

我采用了染色法

即：在建立图时进行染色，将相连的人用同一种颜色标记（其实就是一个自增的数字）

这样，在查找联通时只需要看一下他们是否颜色相同就知道是否都联通了

但是，如果删边，那该怎么解决？

删边意味着我不知道是不是该把一个颜色岔拆开，同理，增边也是一样

那么这里就需要动态维护与延迟重建了

通过维护一个block的结构，来使得在增减边时动态调整：非必要不重建

然后，在查询时，先判断之前的颜色还是否有效，如果无效

就这样进行标记，这样就完成了维护+延迟重建

同理，关于之后的数据体，我也大多使用了类似的方法，尽量避免重复查询

六，规格与实现分离

我感觉这一部分我并没有很好的完成，因为前两次作业一直对JML迷迷糊糊，不清不楚。比如第一次作业爆了6个CTLE，原因是我按照JML的要求，对hashmap进行遍历比对查找。但事实上，这是毫无意义的，因为规格只是给出了最低标准。事实上这与黑盒有些相似，因为JML其实也只是告诉你什么要变成什么样，给你划定了一块空间，空间内不会管你如何实现，这便是规格与实现分离。

七，Junit

这个junit测试感觉是彻头彻尾的翻译，要做的事情如下：

• 先用最笨，最不会出错的方法写一遍要测试的功能作为标准
• 然后按照JML，利用断言比对这个标准与测试方法的结果，注意是逐条比对，逐条断言
• 最后构造样例，样例构造方式正如我在前文所说，写一步测一步，逐渐加大数据量，尽可能全覆盖

总而言之，我认为这才是JML的优势，明确了要做出什么样的功能，明确了什么需要测试，怎么测试

跋

写了三个星期JML，感觉比前面轻松不少，毕竟不用从头设计，还是比较惬意

但是确实学到了关于规格设计相关的东西，感觉对于代码具体实现的把控这一部分的理解有所加深，受益匪浅