第12次作业-第三单元博客作业

[喵喵猫323]

1 分析本单元测试过程

1.1 黑箱测试和白箱测试的理解

黑箱测试：着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试；

白箱测试：必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。

1.2 各种测试类型

单元测试：对软件中的最小可测试单元进行检查和验证；

功能测试：在单元测试的基础上，按照设计要求，把单元测试通过的单元组成单个功能而进行的有序测试；

集成测试：在单元测试的基础上，按照设计要求，把单元测试通过的单元组成系统或子系统而进行的有序测试；

压力测试：在一定压力环境中，测试程序处理问题的能力，通常用于测试程序的性能；

回归测试：对修改后的程序重新进行测试确认原有的缺陷被修复并且没有引|入新的缺陷，同时要确认对其相关联的程序没有影响。

1.3 数据构造策略

（1）按照设计要求设计符合功能需求的简单数据，但要求覆盖所有功能；

（2）按照设计要求设计边界数据，例如空数据或者满数据；

（3）按照设计要求生成部分随机数据。

 

2 分析本单元架构设计

通过分析测试数据发现“add类”指令数量远大于“modify类”指令和输出类指令，因此引入以下图模型的构建和维护策略：

（1）整体上采用“并查集”、“DFS”、“dijkstra最短路”、“单步更新”的设计思路；

（2）当遇到add类指令时，且图模型不为空，更新当前图模型状态（连通情况、最短路等），此时时间复杂度通常为O(1)或O(n)；

（3）当遇到modify类指令时，则直接清空图模型；

（4）当遇到输出类指令时，如果图模型不为空则直接输出，否则重新生成图模型。

此时，最好情况下的时间复杂度为O(nm)，m为add类指令数量，最坏情况下的时间复杂度为O(n^2*m)，m为输出类指令数量。

 

3 分析bug

3.1 第9次作业

（1）对于并查集：修正了addPerson的block合并错误；修正了recalBlock中，没有将当前person加入curBlock的错误；修正了当合并block时，仅修改ar相关person的错误。

（2）对于性能：优化了floodBlock算法，取消了每次调用时curBlock的创建；重新设计了维护算法，减少qts的重复计算。

3.2 第10次作业

（1）修复了Tag求平均数时size为0引发的除法错误；

（2）修复了mr时无条件修改tvs引发的错误。

 

4 分析Junit

（1）为自建类（MyXXXClass）引入类似“equals”函数，辅助Junit中的pure检查；

（2）引入“影子对象”辅助Junit中的ensure检查。

 

5 本单元学习体会

进一步加深了JML和Junit理解。