301
社区成员
发帖
与我相关
我的任务
分享北航OO第三单元总结
测试分析
1.黑箱测试
以输入数据和输出数据的对应关系为出发点，只使用程序的输入输出接口，不考虑内部结构和内部实现，检查程序能否接收数据并且正确的输出数据。具体而言，对拍和评测机都是黑箱测试。
2.白箱测试
针对程序具体的内部实现逻辑，在程序各个部位进行检测，希望逻辑上和结果上俩个方面均正确，比较耗时，具体形式有JUNIT，而对于OO作业而言，如此耗时的测试方法并不适合。
3.单元测试
单元测试是针对软件中最小的可测试单元进行的测试，通常是对单个函数、方法或类进行测试。本质是一种白箱测试，检查代码的逻辑和输出是否正确。
4.功能测试
顾名思义，对功能进行测试，本质是黑箱测试，只关注单个或单组功能的实现，不关注功能与功能之间的影响。只要实现功能，即视作通过功能测试，所谓“黑猫白猫，抓住老鼠的就是好猫”
5.集成测试
对整个系统的测试，检查功能与功能之间的联动是否正确，可以检测接口问题，数据传输问题以及模块之间的兼容性问题。
6.压力测试
构造极端条件的数据对程序进行测试，具体为构造数据范围内的最大样例和调用大量线程，模拟大量用户并发和大数据量，并且限制系统的处理时间，观察系统能否在规定时间内处理大量数据，从而监测系统的性能，资源消耗情况和死锁等问题。
7.回归测试
一般在迭代开发中使用，如果已测试过的代码被修改后，需要保证仍然可以实现预期的行为，并且不会引入新的错误而对其重新进行测试，保证代码的增量是符合正确性的。
测试工具
JUNIT可以进行单元测试，自动生成测试框架，但其实框架当中的内容仍然需要自己填写，使用JNUIT本质上增加了测试的工作量，不如直接编写测试点，所以我并没有使用测试工具JUNIT。
数据构造
对于高开销指令针对性的构造压力测试，具体方法为提高此种指令在全部指令中的占比。
对于稀疏图和稠密图分别进行测试，覆盖全部指令。
规格与实现分离
性能问题：举例而言，queryBlockSum函数的JML提出的方法是O(n^2)的复杂度，qcs本身的JML复杂度是O(n^2)，但qcs内部调用的方法复杂度是O(n)，这导致qcs本身的复杂度达到了O(n^3)。
我想，在这种情况下，除非数据点比较宽容，否则这样的复杂度是很难通过测试的。
因此，需要理解JML规格的意义，其意义在于明确了方法的功能，指出需要改变的变量，挑明返回的值和前置条件。但规格所提供的的方法并不适合直接翻译，而需要我们在实现的时候选取合适的数据结构，恰当的算法，以满足规格的形式下实现。
架构设计
阅读JML之后，总结出这两个方法本质上就是要计算图中的连通块个数还有查询两点是否连通，显然这是很典型的并查集算法的应用。为符合面向对象设计规范，我将并查集算法封装成了DisjointSet类，减少MyNetwork类的复杂度，也便于调试。
根据并查集算法，我在DisjointSet类中pre数组，用来记录每个节点的祖先，在这里使用HashMap<人的id, 其祖先的id>实现。
对于删边操作，采用重构并查集的方式。
对于最短路径计算，额外创造图类使用迪杰斯特拉算法即可。
性能问题
本单元作业我大致采用了三种方法来提高程序的性能，降低时间复杂度
数据结构
使用Map的键值对获取数据，是一种方便快捷的方法。这就让大量的查询操作复杂度从O(n)降到了O(1)
动态维护
本单元作业中有一部分方法可以通过在ap、ar、mr时动态维护，记录下当前数据，在需要查询时直接返回值就可以。比如像第一次作业的qts，可以在ar时遍历acquaintance数量较少的一个人的所有acquaintance，再看另一个人有没有相同的acquaintance，若有，则tripleSum++，在删除关系时同理维护tripleSum即可；
Junit测试
Junit测试的过程中，总结了以下两点经验：
- 根据规格文档设计测试用例，尝试覆盖各种情况，确保覆盖所有功能需求和边界情况。
- 随机化生成多种测试数据
心得体会
经过本单元的训练，慢慢理解规格的意义，理解规格与实现分离的思想。
同时，对于测试的理解更加深入，理解了上述讨论的测试方法。重温了图算法和并查集算法，学习了Junit测试方法，对于软工中springboot框架的单元测试提供支持。
...全文
请发表友善的回复…
发表回复
