碼市：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 | |
| · Design Spec | 生成設計文檔 | ||
| · Design Review | 設計複審 | ||
| · Coding Standard | 代碼規範 | 0.1h | 0.2h |
| · Design | 具體設計 | ||
| · Coding | 具體編碼 | 1h | 2h |
| · Code Review | 代碼複審 | 0.6h | |
| · Test | 測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | 2.6h | |
| ·Test Report | 測試報告 | ||
| · Size Measurement | 計算工作量 | ||
| ·Postmortem & Process Improvement Plan | 并提出過程改進計劃 |