1.基本任務

小組github地址：https://github.com/LongtermPartner/ExtendWordCount

PSP表格：

接口的實現：

計數模塊，由CountAndSort類中的parse函數實現，主要功能是對有效的輸入文件進行讀取並統計其單詞詞頻。

由main函數調用，傳入參數為輸入模塊分析得出的有效文件名，統計出各單詞詞頻後，放入一個Map中（key為單詞名，value為單詞詞頻），返回值為此Map，供後面的排序模塊使用。

測試用例的設計：

此模塊共使用了20個測試用例，由於模塊功能較少，既采用白盒測試覆蓋各判定，又有黑盒測試， 包括：

>>字母與數字的組合

>>字母與各種常用字符的組合

>>短橫線在字母前

>>短橫線在字母後

>>短橫線在單詞中間

>>字母大小寫是否對單詞有影響

等各種情況。

每個測試用例針對性較強，且單詞數不多，都不可缺少，能較好地滿足測試效率的要求。

單元測試及其評價：

如圖所示，對計數模塊編寫了測試腳本並進行了單元測試，20個測試用例通過。

此次測試根據需求列舉了各種可能出現的情況，使這次測試可信度很高，且測試效率較高；

對被測模塊，20個測試用例都通過了，在功能方面滿足了用戶提出的需求。

2.擴展任務

對開發規範的理解：

鄒欣老師對代碼規範和代碼復審的討論：http://www.cnblogs.com/xinz/archive/2011/11/20/2255971.html

（1）斷行與空白的{ }行：

鄒欣老師在博客中指出，為了程序精簡、調試、結構清晰，盡量每個“{”或“}”都獨占一行，即

if ( condition)
{
    DoSomething();
}
else
{
    DoSomethingElse();
}

我認為這一點很容易被忽視，比如我由於個人習慣，經常將左大括號寫在前一行，雖然沒影響，但看上去可能沒那麽清晰。

（2）命名：

對於一個好的命名，盡量使用匈牙利命名法，且讓程序員一眼就能看出變量的含義甚至類型，避免在使用中出錯。比如對一個簡單的int變量，我們最好不要直接用i、j、k這種簡單但完全看不出含義的變量名，而應該用能看出其含義的命名，易於自己、他人閱讀代碼，弄清含義，可讀性高，且可維護性好。

（3）縮進：

在Eclipse中，換行時會自動進行縮進，但是在編寫代碼的過程中不斷的增加、刪除還是會出現縮進格式不太整齊的現象。

根據規範分析小組成員代碼：

對17067負責模塊的代碼，就以上標準進行分析。

斷行與空白的{ }行、命名規範：較為標準，如wordsCount、valueComparator等變量的命名，都較為規範、易於理解。

縮進：有些地方的縮進格式較為混亂，不容易一眼看清層次，如

private int getInt(String key) {
                
                int i=0;
                try{
                Pattern pattern=Pattern.compile("^\\d+");
                Matcher matcher=pattern.matcher(key);
                if(matcher.find()){
                    i=Integer.valueOf(matcher.group());
                }
                }catch(NumberFormatException e){
                    e.printStackTrace();
                }
                return i;
            }
            };

靜態代碼檢查工具：

PMD，在Eclipse中的安裝方法如下

選擇Help菜單項，選擇Install From Site...，並點擊add鍵，在Name一項填“PMD for Eclipse Update Site”，Location一項填

運行截圖及掃描結果：

存在的主要問題如下：

（1）AvoidCatchingGenericException：即拋出異常時最好指定異常的類型，而不是直接用Exception類型。

改進方法：因為要對某特定異常進行處理，改為catch(FileNotFoundException e)。

（2）Avoid printStackTrace(); use a logger call instead.：即在catch中最好不要直接用e.printStackTrace()，如果不對異常進行處理，可以直接throw拋出，若要處理則用自己的方法處理。

改進方法：由於已經要對此異常進行處理，刪除e.printStackTrace()即可。

（3）無用的括號：某些表達式裏沒必要加括號的地方多加了括號。

改進方法：去掉某些無用的括號。

（4）IfElseStmtsMustUseBraces：即if或else語句必須用大括號括起。

改進方法：用大括號括起，更規範。

（5）LocalVariableCouldBeFinal：即某些局部變量可以被定義為final類型。

改進方法：將某些變量設定為final類型，更安全。

（6）OnlyOneReturn：即在try裏有一個return，外面又有一個return。

改進方法：去掉try裏的return語句，將return語句放在外面。

小組代碼主要問題：

代碼沒有太大問題，但不夠規範，有些小問題，可以盡量改的規範一些。

3.高級任務

測試數據集：

如圖，測試數據集使用了一個1600多行的文本文件test.txt，其中包含了各類單詞。

處理時長：

如圖，經過多次試驗，處理此測試數據集的時間在300ms~400ms左右。

同行評審：

每位小組成員都作為作者、講解員、評審員、記錄員等身份進行了評審。

經過評審，我們得出結論：影響程序性能的主要因素是計數和排序兩個模塊，即計數時對單詞的判定方法和排序的算法快慢。

實際測試：

通過測試，我們發現制約程序性能指標的主要因素是計數和排序兩方面，即和同行評審結果相似。

軟件開發、軟件測試、軟件質量的關系：

在本次實踐作業中，軟件開發主要是第一階段，即基本任務的完成，而二、三階段要對軟件進行修改，再提交，即二、三階段也能反映開發過程；而軟件測試則是貫穿整個始終，在一、二、三階段都有體現，也反映了軟件測試的重要性；軟件質量則是在各階段一點點變好。不論是單元測試、靜態測試還是最後的壓力測試，都影響著軟件開發過程和軟件質量。

>>小組貢獻分:

經過小組討論，小組貢獻分為0.29。

WordCount項目優化