OO-Unit3-总结

测试分析

黑箱测试：完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试。只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
白箱测试：测试中，可以深入了解软件的内部结构和代码逻辑，从而检查软件中的每个执行过程是否按照软件说明书的规定正常进行，透明性高，面向细节，高效。
单元测试：针对软件中的最小可测试单元进行检查和验证。在编程中，一个“单元”通常指的是最小的测试块，它可以是方法、函数、模块、类或组件。
功能测试：用于验证软件是否按照需求规格说明书的规定正常实现各项功能。它主要关注于软件的功能性需求。
集成测试：在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，然后进行的测试。它的目标是检查软件模块之间能否正确集成，以及集成后系统能否按需求规格说明书的要求正常运行。
压力测试: 模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，以测试被测系统的性能、可靠性、稳定性等。
回归测试：修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

数据构造策略

1.根据数据限制范围构造边界数据。
2.根据功能要求构造功能测试数据。
3.根据各个功能的逻辑关联，构造复杂的数据。
4.根据功能实现时的时间复杂度，针对性的构造压力测试。
5如果有规格，可以根据规格要求构造单元测试。

本单元架构梳理

本单元核心为network类，作为实现和外部交互的类，它可以对社交网络进行各种修改查询操作，而person作为图节点，人与人的关系作为无向边，社交关系数作为权值，tag为关系分组，类似一个群体，message作为流动在社交网络中传递信息的对象，以及各种不合法操作对应的异常类。

图模型构建和维护策略

我的图模型采用的结构为“HashMap嵌套HashMap,即一个能够hash查询的邻接表。维护策略为动态维护与实时计算结合，耦合度低的动态维护，高的就查询修改后重新计算（这就导致有时候会超时，主要我没上过算法课，而且用java写算法各种别扭，就摆烂了，高耦合的不想费脑子卷）。

性能问题及其修复情况

就如我上面所说，部分高耦合数据维护起来属实费劲，还容易出bug（第三次作业强测不及格就是教训啊），所以放弃解决这种类型的性能问题。

规格与实现分离的理解

规格与实现分离优点缺点都有。
优点：规格的限制让程序更可靠，编写规格时能够让人专注于需要实现的功能，和不能更改的限制，思考会更全面，不受实现的干扰，实现时只要充分相信规格就行。
缺点：规格阅读增加工作量，规格的存在限制了实现上的灵活和思维上的闪光点，而且一旦规格出错，实现必定出错，或者规格编写者抽象层次高，没有考虑到部分细节，会导致实现者理解偏差。（小声bb，我因为规格理解偏差强测炸了，烦人）。

如何利用规格信息来更好的设计实现Junit测试，Junit测试检验代码实现与规格的一致性的效果

充分测试ensure，assign部分，规格信息一定程度降低了测试思考成本，可以提高测试的针对性和高效性，如果需要，还可以测试require。

本单元学习体会

本单元难度都在理解JML和算法数据结构，说实话我没学过多少数据结构和算法，大一那点皮毛早忘干净了，所以因为各种考虑性能反而提高了bug出现概率，导致这个单元得分偏低，其实我更希望课程组提示一下需要学习哪些算法数据结构，或者直接给出学习链接，而JML在实现简单功能时异常的可靠，但实现复杂功能时，其实个人觉得不如自然语言，巨大的篇幅和奇奇怪怪的嵌套，偶尔带入离散，更容易产生二义性，语言本来就是严谨的，限制这份严谨的是语文水平，（某种意义上和JML定位相同）。