BUAA-OO-三单元阶段总结

[李首墨-22371327]

• 分析本单元的测试过程

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

  黑箱测试

  黑箱测试也称为功能测试，数据驱动测试或基于需求规格说明书的功能测试。该类测试注重于测试软件的功能性需求。主要特点包括：

  • 不需要了解代码的内部结构和实现细节。
  • 测试目标是检查系统的功能是否符合需求。
  • 常用的测试方法包括等价类划分、边界值分析、决策表、状态转换等。
    我在测试中主要使用了等价类划分和边界值分析。

  白箱测试

  白箱测试也称为结构测试，又称为结构测试或逻辑驱动测试，它是把测试对象看成一个透明的盒子，它允许测试人员利用程序内部的逻辑结构设计测试用例，对程序所有逻辑路径进行测试。主要特点包括：

  • 需要对代码的内部结构有深入了解。
  • 重点在于代码的逻辑覆盖，如语句覆盖、分支覆盖、路径覆盖等。
  • 主要目标是检测代码中的错误、漏洞和不合理之处。

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

  • 单元测试（unit testing），
    单元测试是指对软件中的最小可测试单元进行检查和验证。
    “单元”可以是一个函数、方法、类、功能模块或者子系统。单元测试通常和白盒测试联系到一起。
    基于这个理解，我们编写的Junit的前置条件，后置条件，其他都要进行相关的测试断言，和白盒测试的作用大体相同。

  • 功能测试
    功能测试就是对各个方法的各功能进行验证

  • 集成测试
    顾名思义就是在完成各个功能测试之后将不同功能集成起来一起进行测试

  • 压力测试
    就是在长时间运行，高密度输入输出的情况下的大量测试

  • 在本单元中表现为大量求值操作的重复运行导致的CTLE问题，例如 大量qtvs，qts，如果这些被反复调用的方法的复杂度过高就会导致CTLE问题，一般认为复杂度在 O(n²)以下的复杂度是可以接受的

  • 回归测试
    回归测试(Regression Test)是指在软件项目中，开发人员在修改了软件的代码以修复已经发现的bug后，测试人员在需要重新测试前面已经测试过的内容，以确认此次修改没有引入新的错误。
    落实到我们的代码中，修复Bug后的代码不改变修改前正确的测试样例。例如，Bug修复部分需要保证修复后的代码不会引起新的错误，否则无法提交。

  • 数据构造有何策略

  对于编写Junit的数据构造（属于白箱测试），我们应当尽量提高数据的覆盖率，考虑到尽可能多的情况进行测试，主要对于代码中的明显漏洞与逻辑错误进行排查。

  而对于互测/自测的数据构造的情况就更复杂一些，我们需要考虑CTLE/RTLE的代码问题，通过生成大量数据进行压力测试，由于评测机与本地评测速度有显然的速度差别，因此需要尽量进行优化，防止优化速度不足。

  在历次迭代过程中，需要注意的方法主要有：

  在第一单元储存人物关系时，考虑使用并查集，并且考虑对于并查集删边的优化，同时对于tripleSum类型的数据，我们需要进行动态维护

  第二单元则新增了tag方法，对于valueSum与coupleSum需要进行额外的优化，对于最短路径方法也要考虑使用DFS/迪杰斯特拉算法。

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

本单元的代码整体架构基本均由课程组提供，我们仅需在理解代码含义的情况下进行优化即可，在整体架构下，我们不难发现，整个项目维护了一个NetWork图，存放了形形色色的人与不同个人发出的消息，为了合理存放这些信息（独一无二的id），在该项目中广泛使用了HashMap的容器结构，同时为了方便查找任意二人之间的关系，我们还选用并查集来存储关系结构，同时，对于许多需要进行查询的量进行了动态的维护来优化性能。

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

在第一次作业中出现的性能问题主要在于对动态维护属性并不熟悉，同时对于边的关系的存储结构并没有很好的理解。采用的是随用随查的递归形式来完成判断两个人是否存在关系等操作，经过优化采用并查集的数据结构来储存关系可以初步进行优化，但是并差集并没有非常契合关系的删除操作，因此，这一步有两种选择，构建一个优化的并查集提高储存信息量。或者优化重建并查集操作，我使用的是后者，在删除边后，仅重建与该边相关的人的并查集，成功优化到合规范围。

而在第二次迭代中出现性能问题的主要存在对value的总和统计以及最短路径的判断。最短路径这里采用的是迪杰斯特拉的优化算法，采用传统算法易导致造成问题，对于value的总和统计也是选用动态维护的方法即可。

第三次对性能的要求并没有很强，只需要保证正确性即可。

• 本单元中同学们实现了Junit测试方法，总结分析如何利用规格信息来更好的设计实现Junit测试，以及Junit测试检验代码实现与规格的一致性的效果

许多同学在设计Junit测试方法时仅仅是将代码中实现的优化算法复制一遍，个人认为这种方法并不合适，因为Junit的首要检查任务还是检测自己设计的算法的正确性，因此我在Junit选择的是最简单（规格的直接转述实现）的计算方式来做结果对比，并且，我们可以发现这三次作业中，课程组要求实现的Junit都是可以直接转述规格进行实现与检测的。依照这种方式可以保证Junit设计上的正确性，避免导致检测函数错误的情况。也就是相当于满足Junit的要求就是符合规格的合适的实现代码。

• 本单元学习体会

刚刚进入本单元时对于本单元有些轻视，简单的以为完成了前两单元的任务后面就不存在难点了，事实上，在第三单元失分情况比前两单元频繁的多，主要存在与性能上的优化不足，没有分配很多时间到OO的思考上，同时个也意识到我对于算法的学习十分的不足，拿到题目的第一想法永远是简单的低效实现，除此之外，因为过于轻视三单元的作业，在前两次强测中均出现了WA的逻辑错误问题，经事后排查发现都是一些小的Bug由于没有二次检测并且中测难度并不高没有发现，造成了令人追悔莫及的大量失分。在下面的单元我一定要端正态度，绝不掉以轻心。