WordCountPro小程序

基本任務

1.githu地址

https://github.com/JarrySmith/WordCountPro

2.psp2.1表

3.接口實現

我在這裏負責開發的是核心處理模塊，該模塊的功能為讀取出文本中的內容後對文本中單詞分割，並統計它們的詞頻。具體接口設計如下：

Class WordCount
方法：
1.public Map<String,Integer> wordCount(String path)
{
    String context=readFilecontent(path);
    processString(context);
    
 
//外界調用這個方法，最後返回一個map容器，裏面裝了單詞和相應的詞頻
}

2.public Map<String,Integer> processString(String context)
{
    //遍歷char Of Context進行處理
}

3.public String readFilecontent(String path)
{
    //一次性讀取出path指向的txt文件的所有內容，並以String形式返回　　
}

我所負責的模塊中有三個函數，當需要用到核心模塊的功能時，外界會直接調用裏面的wordCount函數，得到一個裝有單詞和詞頻的map容器實例。wordCount函數會先調用readFilecontent函數，傳遞文件的路徑進入函數，然後來讀取文件中所有的字符，裝入一個String變量中返回。再將這個變量的內容作為參數傳遞給processString來處理這些字符。processString函數會一個個讀入String裏面的內容，然後分析是否是單詞，當是單詞時記錄，並存進map中，如果map中已經有相應的單詞了，則對應的詞頻加一，最後返回這個map容器。

具體代碼請見github內

4.設計測試用例

20個測試用例如下：

在進行設計用例測試時，首先設計時可以看到wordCount函數只有兩句調用，屬於簡單代碼，沒有太大必要進行單元測試，所以單元測試的重點在於另外兩個函數的測試。

對於readFilecontent函數，首先要對這個函數功能進行測試的話，先進行了傳入正確的絕對路徑和相對路徑讀取的測試，之後進行異常值的測試，輸入空的或者錯誤的路徑時，會拋出FileNotFoundExcetion，捕獲異常後對其查看來判斷是否通過單元測試。

對於processString函數，進行了較多的14個測試，會讀取出14個不同文本的內容，測試這14個文本進行單詞計數時結果是否正確。會進行-在單詞的前後中時是否計數，數字是否進行計數，常用符號是否計入，異常符號是否計入，單詞縮寫時的單詞計數，用tab、空格、換行符分隔時單詞的計入等14個情況。基本覆蓋了作者所能找出的所有正確、異常值的測試。

5.單元測試結果

最後編寫好了測試用例後，采用Junit框架來實現單元測試，具體測試代碼請見github內，測試結果如下：

測試結果評價：

測試的用例基本覆蓋了可能出現的輸入情況，但是在對processString函數進行單元測試時，有部分測試用例對一些輸入情況進行了重復測試，具有一定的測試冗余。被測代碼通過所有的測試用例，測試情況較好，被測代碼符合預期要求。

6.小組貢獻分

經過討論，本人在小組中的小組貢獻分為：0.23

擴展任務

1.開發規範

由於我們小組使用了java進行開發，所以采用的是《阿裏巴巴java開發手冊》中的開發規範，理解如下：

《阿裏巴巴Java開發手冊》中指出：【推薦】如果模塊、接口、類、方法使用了設計模式，在命名時體現出具體模式。 說明：為了達到代碼自解釋的目標，任何自定義編程元素在命名時，使用盡量完整的單詞組合來表達其意。

個人體驗：在對變量名進行命名時，如果使用簡單的a、b、c之類的變量名命名，在使用時會出現使用不明確的情況。在進行測試和重構時候更是如此，有時需要花費額外的大量時間來重新理解代碼內容。

2.交叉分析

我對學號U201517088的同小組成員的代碼進行了代碼規範的分析，分析的標準參考的是《阿裏巴巴java開發手冊》。

該成員進行的是輸出模塊的代碼開發工作，對其類outputProcess分析後發現：

一、其覆寫的方法compare()沒有進行覆寫的@override註釋編寫

二、使用了尾行註釋。

三、String類型在擴展時，應使用Stringbuilder的append方式擴展

使用靜態工具分析結果如下：

該成員其他代碼部分基本符合開發規範，全部代碼約40行，簡潔易懂，采用覆寫方法也便於理解不同情況下對compare方法的調用。

3.靜態分析

因為我們采用的是《阿裏巴巴java開發手冊》中的開發規範，所以使用了Alibaba Java Coding Guidelines這一工具對自己的代碼進行靜態分析，經過分析後的結果如下：

4.改進代碼

經過和小組成員的討論後，對之前發現的問題進行了改進，發現的問題和改進方法如下：

一、else後面有地方沒加大括號，這裏應該將單行的代碼也用大括號括起來。

二、使用了未定義的常量，這裏用一個定義final常量再對常量進行使用。

三、未添加作者信息，之後應在.java文件前加上作者信息。

四、使用了尾行註釋，應另起一行。

五、在判斷語句中輸入了復雜的條件，這裏應在前面定義一個boolean型變量，將boolean變量放入判斷條件中。

六、HashMap沒有指定初始化大小，這裏分析了我們進行測試的用例，取了一個滿足較多用例的中間值作為初始化大小。

改進後的代碼使用Alibaba Java Coding Guidelines進行靜態檢查後結果如下：

可以發現，此時代碼已經通過了靜態檢查。

5.小組代碼評價

組內成員代碼在靜態分析上都或多或少的找到了一些文件，比較通有的問題是寫了尾行註釋和缺少對代碼描述的註釋，使得在閱讀代碼時候沒有那麽清晰。

高級任務

1.測試數據集

程序主要花費的時間的地方就是進行對文本統計判斷，為了進行壓力測試，統計文本的txt文件應足夠大，采用了一個12.5MB的txt文件來進行測試。

2.優化前程序性能指標

3.同行評審過程

由全體組員參與，組員徐江南主持，所有人一同評審小組的全部代碼。

經過討論，一致認定

1.在循環內定義變量會增加額外開銷，建議將變量提出。

2.刪去輸入類中方法內對非法字符的判斷不影響程序功能，而且能增強性能。

4.優化設計思路

在對認定的問題進行處理後，即將變量提出循環，刪除合法字符檢測後，程序效率大約提升了20%，與同行評審的結論一致。

5.作業小結

從基礎功能到拓展功能到高級功能，可以說軟件測試貫穿了軟件開發的整個流程，同時軟件測試也抱著了軟件質量能達到基本要求。如果沒有進行基礎功能時候的單元測試，或許在進行接下來的開發時會發現一個一個原先認為的功能不完善，導致WordCountPro的質量變差，而且增加了開發的時間周期。可以說軟件開發、軟件測試、軟件質量是互相聯系的。想要做好軟件開發，就要做好測試。想要達到好的軟件質量，就要在開發時進行優化、測試。同時軟件測試後不對軟件進行維護、或者繼續開發的行為，軟件質量也無法保證。

WordCountPro小程序