OO unit3总结

1. 测试过程

黑箱测试和白箱测试是软件测试中常用的两种方法，它们针对软件的不同方面进行测试，以确保软件的质量和稳定性。

1.1 黑箱测试

黑箱测试是一种功能性测试方法，我们不需要了解程序内部的工作原理和代码结构，而是将其视为一个黑箱子，只关注输入与输出之间的关系。在黑箱测试中，测试人员通过输入不同的数据或操作，观察软件的行为和输出结果，以验证软件是否按照预期的方式运行，并发现潜在的功能性问题。
缺点：无法发现软件内部的逻辑错误或缺陷。

1.2 白箱测试

白箱测试则是一种结构性测试方法，测试人员需要深入了解软件的内部结构、代码逻辑和算法等，以便有针对性地设计测试用例。在白箱测试中，测试人员通常会直接查看软件的源代码，通过代码覆盖率、路径覆盖等指标来评估测试的完整性和质量。白箱测试能够发现黑箱测试无法触及的内部逻辑错误和潜在的安全漏洞。
缺点：需要更多的技术和专业知识以及大量时间去阅读代码

1.3 单元测试

单元测试是针对软件中最小的可测试单元进行测试的过程，通常是对单个函数、方法或类进行测试，旨在验证其功能是否符合设计要求。这种测试通常在开发过程的早期进行，验证细节部分的功能是否正确。

1.4 功能测试

功能测试是一种黑箱测试方法，旨在验证软件的功能是否符合用户需求和规格说明书。在功能测试中，测试人员会模拟用户的操作行为，通过输入不同的数据或操作来验证软件的各项功能是否按照预期工作。

1.5 集成测试

集成测试是在单元测试之后，将多个单元组合在一起进行测试的过程。其目的是验证这些单元的集成是否能够正常工作，确保软件各部分之间的协作和交互符合设计要求。

1.6 压力测试

压力测试是一种性能测试方法，旨在评估系统在特定负载条件下的稳定性和性能表现。通过增加系统的负载，观察系统的响应时间、资源利用率等指标，以确定系统在高负载下是否能够正常运行，并找出性能瓶颈和优化空间。

1.7 回归测试

回归测试是在软件发生变更或更新之后，重新运行之前已经通过的测试用例，以确保软件的新版本没有引入新的错误或破坏已有功能。回归测试旨在验证软件的稳定性，并确保新的修改不会影响软件原有的功能和性能。

1.8 数据构造策略

主要是构造压力数据：例如，本次作业qtvs部分同学使用直接遍历的方法，时间复杂度为n^2,我们可以在加好点和关系之后，一直使用“qtvs”指令去查询，这可能导致超时，这就是压力数据。

2. 架构设计

2.1 图模型构建

使用hashmap来储存大部分数据，例如：persons,values,messages,emojis;
hashmap的查询要远优于arraylist，时间复杂度是O(1);因此，arraylist并不是一个好的选择，容易超时。
在Mynetwork中，将persons中每一个person视为一个结点，而边的信息完全存储在person的属性acquaintance中，需要使用边时，根据点去拿就可以了。

2.2 维护策略

对于图的修改仅有两种：

1. 增删结点：直接对persons操作，时间复杂度O(1);
2. 增删边：找到边的两个结点，分别对这两个结点的acquaintance操作，时间复杂度O(1);

3. 性能问题及设计与规格相分离

3.1 性能问题

本次作业有几个指令进行了性能优化：

1. qci和qbs：这两个其实可以用一个并查集的思路来解决，并查集的核心就是要设计一个“代表元素”来代表可联通的所以有点，因此我为MyPerson添加了一个属性parentID，每次对于图中边的修改都去维护这个代表元素，那么qci只需要判断两个点的代表元素id是否相同，qbs只需要遍历所有persons，看有几个点的代表元是自己。时间复杂度都很低。
2. qts：如果直接翻译jml，时间复杂度为O(n^3),这个是一定会超时的，所以选择动态维护，也就是对于边的增删时，进行判断，维护Mynetwork中的cntTri属性。
3. qtvs：2种思路：一个是动态维护，另一个是在两层遍历时第二层不对persons遍历，而是对第一层的person的朋友进行遍历，这样也不超时，实现上来说，第二种更简单，但第一种会更安全一些，毕竟可能存在极端数据（完全图的压力测试）可能会超时。
4. qba：qba使用了一个hashmap进行维护，维护每一个person对应的最好的朋友。
5. qcs：因为维护了qba，所以这里直接遍历时间复杂度为O(n)，是可以接受的。
6. qsp：直接使用BFS遍历，时间复杂度O(n)。

3.2 设计与规格相分离

从上面对方法以及属性的设计我对设计与规格相分离有了更深的思考：
规格与设计相分离是在软件开发过程中，需求规格和软件设计应该在逻辑上相互独立，即规格描述了软件应该做什么，而设计描述了如何实现这个功能。
具体来说，规格指的是用户和系统之间的接口，描述了软件的功能需求和行为规约。
设计则是根据规格确定的需求，选择合适的架构、算法和技术来实现软件功能，这些算法、架构都有我们自由选择，目的是优化时间、空间，在实现功能的同时还可以保证时间复杂度不至于过高，这是相当重要的。

设计与规格相分离的好处：

1. 易于理解和沟通：规格描述了用户需求和期望，设计描述了实现方案和技术细节，将二者分开可以更清晰地传达不同层次的信息，帮助团队成员更好地理解和沟通。
2. 灵活性和可维护性：当规格与设计相分离时，修改需求或更新功能时可以更容易地调整设计，而不必修改规格，从而降低了系统的耦合度，提高了系统的灵活性和可维护性。
3. 更好的验证和测试：规格描述了用户期望的功能，可以作为验证和测试的基准，设计则是实现这些功能的方式，可以更容易地针对规格编写测试用例，并验证系统是否符合规格要求。

总的来说，规格与设计相分离是为了更好地组织和管理软件开发过程中的需求和设计，帮助开发团队更高效、协作地完成软件开发任务。

4. Junit测试

4.1 数据生成器

这里的数据生成主要是生成一个图，所以就要考虑到一些特殊图：完全图，无边图等，这些都要涉及才能保证数据覆盖性足够高。

4.2 Junit测试检验代码实现与规格的一致性的效果

我这里主要是对JML的要求一条一条去编写验证，这样的好处是：1.容易找到是哪里出了错误，从而快速定位到源码的bug位置。 2.不会遗漏一些关键的ensures；

5. 学习体会

这个单元我受益匪浅,，主要是两点：

1. 程序一定要按照最坏数据情况的标准去写，这样的话，强测不管怎么测，算法效率都不会出锅。我就是在此方面有了疏忽, 才使得有部分点ctle。
2. 一定要严格按照JML去写，不要以自己的理解去写，否则容易出很大的问题。

除此之外，通过本单元的学习，我第一次了解了使用规格语言辅助的思想，通过这种方式，我们可以通过规范注释描述方法的前置条件、后置条件和类的不变式等，达到在代码中明确规定预期行为的目的，以帮助我们尽可能地避免编写错误的程序。同时，这一单元涉及了很多关于图论的算法知识，比如BFS最短路径，并查集，动态维护等算法和思维，还是很有收获的。