軟測第4周小組做業：WordCount Pro

小組github項目地址：https://github.com/SSS-SY/wordcount-pro

基礎功能：

一. PSP表格

PSP2.1	PSP階段	預估耗時 （分鐘）	實際耗時 （分鐘）
Planning	計劃	20	15
· Estimate	· 估計這個任務須要多少時間	30	15
Development	開發	360	605
· Analysis	· 需求分析 (包括學習新技術)	60	80
· Design Spec	· 生成設計文檔	0	5
· Design Review	· 設計複審 (和同事審覈設計文檔)	0	0
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	10	10
· Design	· 具體設計	20	30
· Coding	· 具體編碼	180	360
· Code Review	· 代碼複審	40	60
· Test	· 測試（自我測試，修改代碼，提交修改）	60	100
Reporting	報告	60	85
· Test Report	· 測試報告	40	60
· Size Measurement	· 計算工做量	10	5
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	10	20
	合計	440	705

二.代碼實現

在討論事後，咱們將任務劃分爲四個模塊，具體模塊和分工以下：

1. 詞頻統計

功能描述：統計各個單詞的出現次數

接口描述：輸入一個字符串，輸出一個map結構

負責該模塊的小組成員：庹舒月

2. 詞頻排序

功能描述：將統計結果進行排序

接口描述：輸入一個map結構，輸出一個vector結構

負責該模塊的小組成員：俞亮

3. 輸出模塊、構造和析構函數、文件長度函數

功能描述：

(1). 輸出模塊：輸出結果到result.txt文件

(2). 構造和析構函數：類的構造和析構函數

(3). 文件長度函數：獲取輸入文件長度

接口描述：

(1). 輸出模塊：輸入一個vector結構，輸出一個result.txt文件

(2). 構造和析構函數: 無

(3). 文件長度函數：輸出文件長度

負責該模塊的小組成員：辜之皓

4. 輸入模塊、主函數和架構設計

功能描述：

(1). 輸入模塊：讀取文本爲一個字符串對象

(2). 主函數：調用其餘小組成員的接口，是主要邏輯

接口描述：

(1). 輸入模塊：輸出一個字符串對象

(2). 主函數： 無

負責該模塊的小組成員：唐明華

實現描述 

我負責詞頻統計的模塊

在通過考慮以後，爲了提升開發的效率和結果的準確性，我最終決定使用正則表達式來進行單詞的分割處理

在查閱了C++的正則表達式使用方法以後，我試了不少個正則表達式，最終選定了最爲正確的一個

具體實現的代碼以下：

WC::WordMap word_count(string buff) {
  WC::WordMap smap;
  regex rgx("[A-Za-z]+([A-Za-z-]?[A-Za-z]+)*");
  sregex_token_iterator iter(buff.begin(), buff.end(), rgx);
  sregex_token_iterator end;
  for (; iter != end; ++iter) smap[*iter]++;

  return smap;
}

三.測試用例

咱們決定使用google test框架進行測試

我設計了20個測試用例，對詞頻統計的準確性進行了全方位的測試

首先測試了統計多個、重複單詞的基本功能

再測試了分割數字、特殊字符的功能

最後重點測試了處理'-'字符的部分，對"a-", "-a", "a-b"等等狀況進行了測試，保證可以正確的處理'-'字符的影響

測試用例清單以下：

單元測試運行截圖：

測試質量和評價：

測試用例把可能的狀況都基本覆蓋了

在通過屢次修改以後，經過了全部的測試用例

四. 小組貢獻

通過討論，各個小組成員根據本身的參與狀況、代碼質量和代碼量得出了以下評分：

庹舒月:   0.28   

辜之皓:   0.26

唐明華:   0.23

俞亮:   0.23

擴展任務

一.代碼規範

由於咱們選擇了C++語言進行開發，因此參考了google style guide

我仔細地閱讀了google style guide，在include頭文件順序方面，我以前一直都沒有一個很好的指導規範，在閱讀了這個文檔以後，瞭解到應以本文件對應頭文件、C系統文件、C++系統文件、其餘庫的.h文件、本項目內的.h文件的順序來include

而關於類的繼承方面這一塊我以前都不怎麼熟悉，在閱讀以後瞭解到使用組合經常比使用繼承更合理. 若是使用繼承的話, 定義爲 public 繼承的準則

這些東西對我往後編寫C++代碼很是有指導意義

二.選擇靜態測試工具

使用了google官方提供的cpplint工具進行測試

下載連接：https://github.com/cpplint/cpplint

三.同行評審

通過必定的討論，咱們決定唐明華和庹舒月之間進行代碼互評，辜之皓和俞亮之間進行代碼互評

仔細審閱了唐明華的代碼以後，由於小組成員都統一配置了代碼自動格式化工具，因此在代碼風格方面沒有什麼問題

在設計思路方面，都嚴格按照了規範來處理

使用工具對代碼進行掃描，輸出的結果以下：

從新運行單元測試，結果如圖：

 

四.問題總結和反思

使用工具大大提升了咱們在開發中在代碼規範方面的效率，不須要特別地去注意像大括號換不換行這種問題

測試框架極大地簡化了單元測試的工做

閱讀像google style guide這樣的規範文檔對代碼的編寫有極大的提高

 

 

 

 

高級任務

一.測試數據

咱們找了莎士比亞全集的英文版txt文檔，有5Mb大小

使用這個數據，咱們測試後發現大體須要3秒的時間才能處理完整個文件，運行截圖以下：

二.組內評審

針對可能影響程序性能（制約因素），咱們小組進行了組內評審，討論。

主持：

庹舒月

評審：

唐明華、辜之皓、俞亮

評審主題：

1.影響程序性能的主要因素

2.有何建議

討論結果：

咱們討論以後認爲，主要的性能瓶頸在於須要讀取整個文件以後再開始統計，由於磁盤讀寫的速度很是慢，致使了整個程序運行效率低

解決方案：

使用多線程，一邊讀取數據，一邊開始統計讀取部分的數據，以後再將各個部分的統計結果合併，能夠大大提升性能

三.修改以後的結果

修改以後程序性能有了成倍的提升，運行時間大概在0.7秒左右，提升了大約4倍的性能

運行截圖以下：

四.心得體會

本次做業讓我大大認識到了軟件測試和實際開發的密不可分的關係

參考連接：

1. c++參考手冊：

http://zh.cppreference.com/

2. goole style guide：

https://github.com/google/styleguide/

1. di2/(優先位置, 詳情以下)
2. C 系統文件
3. C++ 系統文件
4. 其餘庫的 .h 文件
5. 本項目內 .h 文件