码市：https://git.coding.net/pyj76566/Homework.git
组员 201421123085 童毅南
201421123086 潘益靖
上一周大家为四则运算程序设计了2-3个新功能，本次在隔了一周之后，我们循序渐进地进阶。本次目标：
- 把计算模块提取出来，单独创建一个类。
- 针对提取出来的计算类的接口函数做单元测试
a、需求分析：单元测试能够让我们写的代码更加健全，能够让程序能够不用牵一发而动全身，大大
的改善了后期的维护花费的工作量。我们把四则运算提取出来做单元测试
--加法运算--
首先我们提取的是加法，产生两个新分数后调用Calculator.add()方法，在和我们算出的答案用JUNIT中的asserEquals方法比较答案是否一致。
当我们把分母替换成0时候，这行代码就没有通过了
--减法运算--
我们默认的分数都是正数的，所以当出现1-2=-1时候程序并没有执行下去
--乘法运算--
乘法我们测试了有的功能，都能执行过
--除法运算--
不仅四则运算，我们还测试了其他的一些功能，有关分数的例如：
--判断一个数是否是分数--
其中我们用到了assertFalse（）方法
用法：assertFalse(boolean condition);
condition:如果condition结果为false,则通过测试.
图中我们可以看出缺少分母的数判断是否为分数的结果是false所以是通过了，同理缺少分子，不是数字，分母为零，分子为零，分数误输入为“O”（字母O）结果都是false
--计算分子分母的最大公约数--
当我们故意输入一个错的最大公约数，自然是通过不了。
--判断两个分数是否相等--
主要适用于测试两个分数是否相等的功能，这个方法用于比较系统算出的答案和用户输入的答案书否相等。
--代码覆盖率--
计算模块的：
分数模块的：
--小结与感受--
之前的代码我们已经做到了至少是好一些的规划，每每要用到一个新方法时候，都不在这个方法里面直接写，而是重新写一个目标方法，单元测试我觉得很有意义，能够让我写代码时候能够把一个方法写到尽量
完美无缺，减少了以后的修改量，还是得代码，条理清晰，一看到就能知道功能，不用再从头开始想，这段代码的意义。
--体会--
（1）良好的设计
在设计程序之前一定要想好自己要设计什么，功能有哪些，可能会出现的错误，不考虑这些的话最后只能是想到一点儿改一点儿，别人提出建议改一点儿，又浪费时间又费事。
（2）编码规范
这次这么费劲儿的修改，我们知道以后写程序的时候模块化，函数独立的好处了，就不会修改一点儿就要大幅度改动了，写程序的时候变量名称最好有意义，才能方便以后的读改。
（3）必要的注释
这个是早有体会，以后会一直这样做的。
PSP(Personal Software Process)表格
| Personal Software Process Stages | Time (%) Senior Student | Time (%) | |
| Planning | 计划 | ||
| · Estimate | 估计这个任务需要多少时间 | 6h | 7h |
| Development | 开发 | ||
| · Analysis | 需求分析 (包括学习新技术) | 0.5h | 0.5h |
| · Design Spec | 生成设计文档 | 0 | 0 |
| · Design Review | 设计复审 | 0 | 0 |
| · Coding Standard | 代码规范 | 0.1h | 0.2h |
| · Design | 具体设计 | ||
| · Coding | 具体编码 | 1h | 2h |
| · Code Review | 代码复审 | 0.5h | 0.6h |
| · Test | 测试（自我测试，修改代码，提交修改） | 2h | 2h |
| Reporting | 报告 | 2h | 2.6h |
| ·Test Report | 测试报告 | 0 | 0 |
| · Size Measurement | 计算工作量 | ||
| ·Postmortem & Process Improvement Plan | 并提出过程改进计划 |