学号1：211606367 姓名：林恩 学号2：211606445 姓名：肖志豪
一、预估与实际
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 30 |
| • Estimate | • 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 690 | 650 |
| • Analysis | • 需求分析 (包括学习新技术) | 70 | 50 |
| • Design Spec | • 生成设计文档 | 50 | 70 |
| • Design Review | • 设计复审 | 20 | 30 |
| • Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 30 | 20 |
| • Design | • 具体设计 | 185 | 185 |
| • Coding | • 具体编码 | 185 | 185 |
| • Code Review | • 代码复审 | 30 | 30 |
| • Test | • 测试（自我测试，修改代码，提交修改） | 120 | 120 |
| Reporting | 报告 | 60 | 50 |
| • Test Repor | • 测试报告 | 30 | 30 |
| • Size Measurement | • 计算工作量 | 10 | 10 |
| • Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 10 | 20 |
| 合计 | 780 | 730 |
二、需求分析
需要了解Junit如何使用以及相关要求：
测试要求
- 测试方法上必须使用@Test进行修饰
- 测试方法必须使用public void进行修饰，不能带任何参数
- 新建一个源代码目录来存放我们的测试代码
- 测试类的包应该和被测试类保持一致
- 测试单元中的每个方法必须可以独立测试，测试方法间不能有任何的依赖
- 测试类使用Test作为类名的后缀（不是必须的）
- 测试方法使用test作为方法名的前缀（不是必须的）
测试失败的两种情况
- Failure一般由单元测试使用的断言方法判断失败所引起的，这经表示测试点发现了问题，就是说程序输出的结果和我们预期的不一样
- error是由代码异常引起的，他可以产生于测试代码本身的错误，也可以是被测试代码中的一个隐藏的bug
- 测试用例不是用来证明你是对的，而是用来证明你没有错；即测试用例不能证明你逻辑上的错误，只能检测出你代码中的错误
执行顺序
@BeforeClass - @Before - @Test - @After - @AfterClass
@BeforeClass：它会在所有方法运行前被执行，static修饰
@Before：会在每一个测试方法被运行前执行一次
@Test：将一个普通的方法修饰成为一个测试方法
xx.class为捕获异常类
@Test(expected = xx.class)
@Test(timeout = 毫秒)
@Ignore：所修饰的测试方法会被测试运行器忽略
@RunWith：可以更改测试运行器 org.junit.runner.Runner
@After：会在每一个测试方法运行后被执行一次
@AfterClass：它会在所有方法运行结束后被执行，static修饰
- @BeforeClass修饰的方法会在所有方法被调用前被执行
- 而且该方法是静态的，所以当测试类被加载后接着就会运行它
- 而且在内存中它只会存在一份实例，他比较适合加载配置文件
- @AfterClass所修饰的方法通常用来对资源的清理，如关闭数据库的连接
- @Before和@After会在每个测试方法的前后各执行一次
- @Before和@After会在每个测试方法的前后各执行一次
- @Before和@After会在每个测试方法的前后各执行一次
测试套件（批量执行测试用例）
测试套件就是组织测试类一起运行的
写一个作为测试套件的入口类，这个类里不包含其他的方法
更改测试运行suit.class
将要测试的类作为数组传入Suite.SuiteClasses({})
@RunWith(Suite.class)
@Suite.SuiteClasses({TaskTest1.class,TaskTest2.class,TaskTest3.class})
Junit参数化测试
更改默认的测试运行器为RunWith(Parameterized.class)
声明变量来存放预期值和结果值
声明一个返回值为Collection的公共静态方法，并使用@Parameters进行修饰
为测试类声明一个带有参数的公共构造函数，并在其中为之声明变量赋值
三、设计
1. 设计思路
说明你如何设计这个程序
设计单元测试的思路
- assertEquals()和assertRaises()，比对方法返回值和逻辑值的差别，来检验方法的是否执行有效成功
- 若是有的方法没有返回值，则先实例化，然后比对方法中的值和逻辑值的差别也是可以的
- 有些需要赋予某些其它的初始值
单元测试
-
部分单元测试代码
请展示一段程序的关键代码，并解释代码的作用
@Test
public void testMain() {
String[] args = {"-n", "100", "-grade", "3"};
MathExam math = new MathExam();
math.main(args);
assertEquals(true, math.output_boolean);
}
测试方法上有@Test才会进行测试运算。先实例化，然后传参，math.output_boolean初值为false，执行完代码后math.output_boolean会赋值为true，代表执行完成。这时候只需要判断下值是否为true，即可代表main()是否执行成功。
要对各种可能的值进行测试，确保能够实现方法的各种可能
-
单元测试覆盖率截图
单元测试覆盖率
结构优化
- UML类图：
类图
- 程序运行流程图
流程图
程序做出重构的部分，与重构的原因
- 重构了关于两个数字的计算与判断，在原先代码里关于数字的计算判断大量重复，所以我将它生成为一个方法类与生成式子的类合并
- 将生成式子的类从原先类中提取出，专门生成个类来生成式子以及判断，为了让每个类的模块与功能都更加精准、
重构后每个模块的功能
- MathExam类（主类，自身负责生成和写入文件，以及调用其它方法类来生成式子）
- Two_Numbers类（负责生成一年级和二年级式子以及子式判重，防止生成重复的式子包括子式，在生成三年级式子时调用Calculation类）
- Calculation类（负责三年级式子，转成中缀表达式以及后缀表达式求和）
性能调优
- 贴出优化前效能分析工具的结果截图
性能调优前
-
描述程序的性能瓶颈
- 在代码中存在着大量的重复代码，有些代码冗余无法行之有效实现功能
-
给出优化方案
- 进行了一定量的代码缩减提取，删减某些无用或者重复的代码
-
贴出优化后效能分析工具的结果截图
性能调优后
2. 实现方案 写出具体实现的步骤
分为三个步骤：
单元测试
- 针对程序架构，进行单元测试，确保每个模块能够达到预期的要求
结构优化
- 把具有相似功能的代码封装在一起
- 思考代码应该怎么进行结构优化
- 每当代码的一个模块完成了重构，就需要commit
- 为了保证每次重构后代码的正确性，我们需要先进行回归测试，再commit代码
性能调优
- 测试并改进程序生成四则运算算式的效率
- 帮我们分析找到代码中执行效率最差，也就是所谓 效能瓶颈 的部分。就可以把精力花费在改进瓶颈上，从而高效快速地提升程序性能
四、编码
调试日志
记录编码调试的日志，请记录下开发过程中的 debug 历程
比如：
-
在代码的什么位置，代码出现了什么问题，问题会导致什么结果，怎么解决的
- 在调试代码时，一旦更改代码，也需要在测试代码处进行及时的相对应更改
- 对参数的传递方式，有两种，值传递和引用传递，在方法传递的参数中是值传递，更改子方法中的的值是不会修改到父方法相对应的值
-
请说明你如何按照设计思路进行编码，并记录你在开发中遇到的问题，与解决过程
- 在写测试时，查找到有两种方法assertEquals()和assertRaises()。了解到这两种方法各自作用，通过比较object判断不同来返回测试结果，如果相同，测试通过；反之，不通过。这对方法的模块化程度有着一定的要求。后来我想了些方法，不必通过一定要有方法返回值来判断。因为实现方法后，方法内的某些参数必然改变，这时候只要检验到这个方法的应该实现的内容达到逻辑上的值即可。
- 需要对代码的命名，意义，规范有着很深的认识，毕竟不仅仅是自己一个人在编程，需要让其他人看懂读懂，了解代码。也方便自己后期阅读，修改，重构。
五、总结
- 关于计算机题目重复特点，我总结了几个：
- 题目完全相同
- 题目不同，在顺序上不同，式子不同，但是子式相同，只是改变了形式。其实实质是相同的，结果相同
- 比如a + b和b +a，a x b和b x a，
- 最终决定在生成式子时，加上一个采集子式的集合用来判断子式是否重复