测试

211606301 蔡振翼 211605240谢孟轩

单元测试

单元测试的思路：

从运算简单，包含参数较少的方法开始着手。对于含有返回值的方法，测试返回值和预期值是否相等，对于void类型，通过设置flag来检查程序是否有运行。
加减法等运算模块测试数据是否正确，查重模块测试数据是否重复，输入判定模块测试错误数据是否提前结束代码。
分析主干部分的operation方法，对其进行拆分。operation方法的主要作用是调用类中方法将数据写入文件，我们在测试中使用Scanner在这个方法运行结束时按行读取文本，测试文本内容是否有缺漏。
以及手动打开文本，查看文本数据是否存在其他没有想到的错误。

单元测试部分代码：

被测试的examine（）方法是按照将答案和题目中的参数存入集合，使用list.contains(）判断集合中是否已经存在这样一组的数据如果存在就返回false即重复了，否则存入数据返回true。而这个测试可以模拟多道题目在写入文本前查重的一个情况，利用返回值来决定我们的预期和实际得到的数据是什么。如上图简单写了两组数据，第一组测试数据也是第一组我们存入集合的数据，因为此前集合为空，不存在重复，所以我们预期结果为true。第二组输入数据与第一组完全一样，所以我们预期结果为false。

import static org.junit.Assert.*;


import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.HashSet;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

@RunWith(Parameterized.class)
public class MathTest {//测试类
	boolean expected=true;//预期值
	int answer=0;//答案
	int[] sub = new int[6];//一道题目中所包含的多个参数
	Collection<String> list=new HashSet<String>();
	@Parameters
	public static Collection<Object[]> t(){
		int[] str1 = new int[]{1,2,9,4,4,6};
		Collection<String> list=new ArrayList<String>();
		return Arrays.asList(new Object[][]{
			{true,str1,5,list},
			{false,str1,5,list}
		});
		}
	
	public MathTest(boolean expected,int[]sub,int answer,Collection<String> list) {
		this.expected=expected;
		this.sub=sub;
		this.answer=answer;
		this.list=list;
		
	}
	@Test
	public void testexamine() {//MathExam指被测试的三年级代码，examine是查重的单个方法
		assertEquals(expected,new MathExam().examine(sub,answer,list));
	}

}

代码覆盖率

结构优化

UML图

运行流程图

在重构代码之前我们将一二三年级写在同一个方法中，每出一道题目都需要对年级进行一次判定。因为每个年级每个运算方法在取值，在运算符号上都存在一定的差异，导致文本中的答案出现少量题目存在错误，难以检测。于是我们重新延用了第二次作业用到的代码。重写了一个对年级进行分辨的方法，如果是一二年级，就实例化第二次作业的类，如果是三年级就调用当前类中运算方法。最直观的收益是提高了代码的可读性，以及答案的准确性，减少了少量的运算时间，方便了我们在检查和修复bug上的负担，但这样增加了代码量，以及重复的部分。

重构后每个模块的功能

input()方法：对写入的参数进行判断，如果不符合标准则报错。
add(),mul(),div(),sub()四个方法：进行四项加减乘除运算。
operation()方法：生成题目和存入题目。
examine()：查重
grade()：对年级进行判断再调用对应的方法

性能调优

程序的性能瓶颈:
1.代码重复量大
2.运行时间过长
3.参数过多

给出优化方案：
1.查找可共用的代码，对重复代码进行封装简化
2.解决增加循环条件的可能性，减少重复操作
3.删除可被替代的参数

优化效能分析工具:

总结：

因为第二次作业的漏洞较多，导致测试作业比上次更加苦不堪言。如果助教们都在测试我们的代码，那真的是太惨了。
咳咳，每次作业都能get新的知识点，以及学会新的插件使用，过去java课程的课件也使用的十分频繁补缺补漏。从当初想要完成这门科目的主动学习达到14个小时，变成无论如何都会达到14小时以上。大三的忙忙碌碌更像可触及到的现实。为了完善代码而需要去做更多更多，不敢妄想能多早把这项作业完成，因为你总会看到更多需要改善的部分。测试完善是项目中不亚于初期写功能的一个部分。