WordCount 優化版測試小程序實現
Stage1:代碼編寫+單元測試
Github地址：
https://github.com/245553473/wcPro.git
PSP表格:
|
PSP |
PSP階段 |
預估耗時(分鐘) |
實際耗時(分鐘) |
|
Planning |
計劃 |
10 |
5 |
|
Estimate |
估計這個任務需要多少時間 |
10 |
5 |
|
Development |
開發 |
60 |
50 |
|
Analysis |
需求分析(包括學習新技術) |
5 |
5 |
|
Design Spec |
生成設計文檔 |
5 |
5 |
|
Design Review |
設計復審 |
5 |
5 |
|
Coding Standard |
代碼規範(為目前的開發制定合適的規範) |
5 |
5 |
|
Design |
具體設計 |
5 |
5 |
|
Coding |
具體編碼 |
40 |
30 |
|
Code Review |
代碼復審 |
5 |
5 |
|
Test |
測試 |
20 |
10 |
|
Reporting |
報告 |
10 |
10 |
|
Test Report |
測試報告 |
10 |
10 |
|
Size Measurement |
計算工作量 |
10 |
10 |
|
Postmortem & Process Improvement Plan |
事後總結,並提供過程改進計劃 |
5 |
5 |
|
|
合計 |
205 |
165 |
接口的設計與實現:
該程序設計了三個接口：String input(), List<WordInfo> handle(String input), void output(List<WordInfo>), WordInfo為包可見的數據類。
WordInfo設計實現如下：
該類用於保存各類不同的單詞及統計數目，通過實現Java.lang.Comparable<T>接口並實現CompareTo方法，使得在對該對象數組進行排序時由數目進行排序，當數目相同時根據字符串的大小比較進行排序。
String input()方法為包可見內部類的輸入方法，該方法根據內部處理類的路徑path獲得所需處理的文件名，並讀取文件信息至字符串中並進行返回，其實現如下：
List<WordInfo> handle(String input) 函數為該程序的核心處理函數，將調用input()函數後輸出的返回字符串作為輸入並對其進行處理，保存至List中，並對其進行排序處理，將結果List集輸出，其代碼如下：
void output(List<WordInfo> handle) 函數為將核心處理函數輸出的List集寫入到本地文件"result.txt"中，其代碼如下：
測試用例的設計：
用於測試的文件，將邊緣字符信息分別復制多次、隨機選擇長文章進行測試、隨機生成字符組成輸入文件進行測試。白盒測試使用JUnit框架先對輸入進行測試，輸入測試能成功運行則將輸入函數的輸出作為處理函數的輸入進行測試，若測試成功則將處理函數的結果作為輸出函數的輸入進行測試，最後將幾個函數的整合進行測試。 黑盒測試通過.bat文件即命令行形式進行輸入測試，檢查輸出的文件結果與預期結果的吻合度。
測試代碼截圖如下:
單元測試運行結果截圖:
Junit測試結果運行截圖:
評價：
通過不同核心處理方法所耗費的時間進行對比，該小程序在相同數據量的情況下所耗時間更短，對多種邊緣測試輸出都能很好地進行處理，程序性能良好，評價較優。
Stage2:靜態測試
規範選擇：
選取阿裏巴巴JAVA開發規範，其中方法名、參數名、成員變量、局部變量都統一使用lowerCamelCase風格，必須遵從駝峰形式。
組內分析：
組內提交的代碼基本符合JAVA編程規範，如我的代碼存在耦合性較高的問題，代碼間依賴性有待降低。
靜態代碼檢查：
選擇工具：FindBugs 3.0.1
下載鏈接：http://findbugs.sourceforge.net/
檢查結果:
結果分析:
對equals方法的重寫不符合規範，由於這是對特殊情況的特殊處理，故暫且保留。
Stage3:性能測試和優化
待更新。
WordCount 優化版測試小程序實現