OO第三单元总结

一、分析本单元的测试过程

1、谈谈你对黑箱测试、白箱测试的理解

• 黑箱测试
  把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和特性的情况下，在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构。

• 白箱测试
  需要全面了解程序内部逻辑结构，必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。

评测机大规模测试属于黑盒测试
走查代码，针对自己的实现逻辑编写针对性的测试数据属于白盒测试

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

单元测试、功能测试、集成测试、压力测试和回归测试是软件开发中常用的测试方法。这些测试方法分别针对软件开发不同阶段和不同目的进行测试，以确保软件的质量和稳定性。

• 单元测试
  单元测试是针对软件的最小功能模块进行测试的方法。编写针对每个函数或方法的测试用例。目的是尽早发现和解决代码中的错误和缺陷。作业要求的Junit单元测试，从名字也能看出，是一种单元测试。

• 功能测试
  功能测试是对整个软件系统的功能进行测试的方法。根据需求规格说明书编写测试用例，通过操作软件的不同功能来验证软件是否满足设计要求。目的是确保软件能够按照用户需求的要求正常运行，并能够正确地处理各种情况。

• 集成测试
  集成测试是在单元测试之后，将各个功能模块组装在一起进行测试的方法。验证各个模块之间的接口和交互是否正常，并且整个系统能够正常协作。目的是确保各个模块之间的集成能够正常工作，不会产生冲突和错误。

• 压力测试
  压力测试是对软件系统在高负载和大并发情况下进行测试的方法。模拟大量用户同时访问系统，并且增加系统负载，以评估系统的性能和稳定性。目的是找出系统的瓶颈和性能问题，并且确定系统在高负载情况下的性能指标。强测中针对某个功能，如qtvs，进行大规模测试，检查性能是否符合要求，便是压力测试。

• 回归测试
  回归测试是在软件系统进行修改或升级后，重新运行之前的测试用例以验证修改是否引入新的错误或导致原有功能出现问题的方法。目的是修改或升级后，原有的功能和性能没有受到影响。本单元作业我每写完一次作业，就重新进行前一次作业的强测，想必就是回归测试。

3、数据构造有何策略

• 覆盖率
  要覆盖所有实现的功能、指令、方法进行测试。同时，对于每个方法，要根据规格测试到所有的normal_behavior和exceptional_behavior，即提高分支覆盖率。

• 边界
  涉及到的数字变量，要根据其类型考虑其取值边界的情况。如int类型取-2,147,483,648和2,147,483,647附近的值。

• 随机生成大量数据

二、梳理本单元的架构设计，分析自己的图模型构建和维护策略

1、架构设计

除了自己实现的一个Protect类专门用于实现维护操作，其他架构实现与JML基本一致

2、图模型构建

所有的person组成的就是一个邻接表形式的无向图，value是权值

3、维护策略

• query_circle和query_block_sum

  • 本质是分析图的连通分支。采用并查集的方法，并实施路径压缩，只记录每个节点的根节点，每次修改并查集前先更新相关节点的根节点；实施按秩合并，设置容器记录连通分支的秩（节点数量），缩短更新根节点的时间。
  • 动态维护，删边后，令端点成为新的根结点，从一个端点dfs遍历到另一个端点，途中实时重置新根节点；根据另一端点染色情况判断是否还连通。若否，则从该端点dfs遍历重置新根节点

  query_circle根据两节点更新根节点后是否同根判断是否处于同一连通分支，即是否有通路。query_block_sum则为O(1)。

• query_tag_value_sum

  • A进出B的tag，而value没有改变
    只需在Tag类的addPerson和delPerson方法中遍历persons容器维护即可
  • A与B的value改变
    遍历A的acquaintance，对于与BisLinked的人，遍历其所有tag，将其中AB都在的tag更新维护。若value为负导致删边，仍需调同时用delPerson方法实现维护。

• query_tag_age_var

由于JML中用的平均值是调用了getAgeMean方法，其运算结果经过了整除运算，会偏离实际值，这就导致方差公式展开后带着平均值的项中的平均值不是实际的平均值，只能把他当做一个常数看待，不能将其化简，否则会产生偏差

$$\sum _{i=1}^n(x_i-\overline{x}{)}^2=\sum _{i=1}^n{x}_i^2-n{\overline{x}}^2\text{\hspace{1em}(1)}$$$$\sum _{i=1}^n(x_i-\overline{x}{)}^2=\sum _{i=1}^n{x}_i^2-2\overline{x}\sum _{i=1}^n{x}_i+n{\overline{x}}^2\text{\hspace{1em}(2)}$$
$(1)$是有偏差的；$(2)$是合理的。因为$\overline{x}\ne \frac{{\sum }_{i=1}^n{x}_i}{n}$

• query_best_acquaintance和query_couple_sum
  对于qba，简单设立了一个HashMap，储存对应的最好朋友，并动态维护，value增加则维护复杂度O(1)，value减少且恰为最好朋友则维护复杂度为O(n)，否则不用更新
  这样qba为O(1)，qcs采取遍历所有人，判断他们的最好朋友的最好朋友是否为自己，复杂度为O(n)

• query_shortest_path
  采用bfs遍历或双向bfs

• delete_cold_emoji
  先遍历emojiList，将要删的存入HashSet中，并迭代器删除，再遍历messages，将涉及HashSet中emoji的迭代器删除，复杂度为O(m+n)

三、分析作业中出现的性能问题及其修复情况，谈谈自己对规格与实现分离的理解

本单元强测及互测均未出现bug

• 规格描述了程序应该如何工作，即软件的行为和功能需求。规格通常不涉及如何实现这些功能的具体技术细节。
• 实现是软程序按照规格进行工作的具体方式或手段，包括代码、算法、数据结构等。
• 规格和实现分离使得我们的程序更加清晰也更加可维护，可以通过编辑规格文档以及使用接口等方式进行实现。

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

• 覆盖每一个normal_behavior
• 对于pure方法，要检测所有可见类成员变量和输入对象不能被修改；否则检测所有not_assigned的元素不被修改
• 检查方法实现逻辑正确性，是否实现预期功能，assignable元素是否按要求修改
• exception_behavior：没有异常行为的方法，检测不可以抛出异常；有异常行为的，对应异常出现时，要抛出正确的异常
• 若有返回值，保证\result正确性

五、学习体会

规格是需求的形式化表述，可以避免自然语言带来的歧义，不涉及如何实现这些功能的具体技术细节。实现时，要在实现规格要求的基础上，运用高级的算法、数据结构等提高性能。
接触了规格化设计，这种极其重要的约定手段。实际应用了很多算法知识，以及数据结构，使我对数据结构的理解更深一步。