211606301 蔡振翼 211605240 谢孟轩
一、单元测试
说明自己设计单元测试的思路
从运算简单，包含参数较少的方法开始着手。对于含有返回值的方法，测试返回值和预期值是否相等，对于void类型，通过设置flag来检查程序是否有运行。
加减法等运算模块测试数据是否正确，查重模块测试数据是否重复，输入判定模块测试错误数据是否提前结束代码。
分析主干部分的operation方法，对其进行拆分。operation方法的主要作用是调用类中方法将数据写入文件，我们在测试中使用Scanner在这个方法运行结束时按行读取文本，测试文本内容是否有缺漏。
以及手动打开文本，查看文本数据是否存在其他没有想到的错误。选择部分单元测试代码发布在博客中，并说明测试的函数，构造测试数据的思路
@Test
public void testMath() throws FileNotFoundException{
math1.math(ope,grade);
File file =new File("out.txt");
int i=0;
Scanner scanner = new Scanner(file);
while(scanner.hasNextLine()) {
scanner.nextLine();
i++;
}
scanner.close();
assertEquals(ope*2+1,i);
}
testMath()方法是对输入文本进行检测。我们文本里需存放题目和答案及空行，而根据用户所需要的题数ope，所以文本里正常运行情况下会存入2*ope+1行数据，因此，我们只需验证文本存入的行数是否与我们的预期值相等即可。博客中附上单元测试得到的测试覆盖率截图
二、结构优化
在博客中给出程序的UML类图
在博客中给出程序的运行流程图
详述程序做出重构的部分，与重构的原因
在重构代码之前我们将一二三年级写在同一个方法中，每出一道题目都需要对年级进行一次判定。因为每个年级每个运算方法在取值，在运算符号上都存在一定的差异，导致文本中的答案出现少量题目存在错误，难以检测。于是我们重新延用了第二次作业用到的代码。重写了一个对年级进行分辨的方法，如果是一二年级，就实例化第二次作业的类，如果是三年级就调用当前类中运算方法。最直观的收益是提高了代码的可读性，以及答案的准确性，减少了少量的运算时间，方便了我们在检查和修复bug上的负担，但这样增加了代码量，以及重复的部分。详述重构后每个模块的功能
input()方法：对写入的参数进行判断，如果不符合标准则报错。
add(),mul(),div(),sub()四个方法：进行四项加减乘除运算。
operation()方法：生成题目和存入题目。
examine()：查重
grade()：对年级进行判断再调用对应的方法三、性能调优
贴出优化前效能分析工具的结果截图
这个，为什么会这样。。。我，也很郁闷！描述程序的性能瓶颈
1.代码重复量大
2.运行时间过长
3.参数过多给出优化方案
1.查找可共用的代码，对重复代码进行封装简化
2.解决增加循环条件的可能性，减少重复操作
3.删除可被替代的参数贴出优化后效能分析工具的结果截图
