0. 開始之前
在第一個實踐作業中，我們分別實現了一個WordCount小程序，並實現了初步的單元測試。但僅僅滿足功能要求就可以了嗎？軟件開發的最終目標是滿足用戶對軟件產品的質量要求，讓我們一起來把這個小程序升級為能穩定運行，給用戶提供高質量服務的軟件吧。
三個臭皮匠，頂個諸葛亮。本次作業將從個人英雄主義時代進入協作時代，作業將通過小組來完成，希望組員們在組長的帶領下精誠合作。
1. 截止日期和提交通道
本次作業的提交截止時間：2018年4月9日00:00。
本次作業需要在如下通道進行提交：
（1）在Github提交代碼。作業涉及的源代碼及文檔材料，根據作業要求，分期在Github上進行提交。對應網址：https://github.com/；
（2）在博客園提交博客作業。小組作業涉及的博客需在博客園的班級博客中提交作業。即發布博客后，需在班級博客的作業中提交。對應網址：https://www.cnblogs.com/；
（3）在課堂平台的作業中提交。請到第4周課程內容中查看第4周小組作業，將博客地址粘貼在作業中，提交即可。對應網址：https://elearning.hust.edu.cn。
2. 作業目標和要求
作業簡述：根據需求，完成WordCount的改進版，並對其進行一系列測試和優化。
作業目標：通過基於框架的單元測試、靜態測試、以及性能測試，發現編碼的問題，提升軟件性能，打造能穩定運行的軟件。
本次作業分為三步，具體要求說明如下。
2.1 基本任務：代碼編寫+單元測試
注意：所有小組成員完成基本任務要求即可，視完成情況，最高可得本次作業滿分的約70%。
任務簡述：仔細閱讀需求（見附錄1：WordCount優化版功能需求說明），改進程序並將功能封裝成獨立模塊，編寫單元測試。
2.1.1 任務說明
如果程序中不同功能的代碼混雜在一起，會對后期的維護造成很大的麻煩，我們應該精心優化程序的組織結構。
所以，任務要求各組把各部分功能封裝成獨立模塊，分別由不同的組員負責。每個組員在提交代碼之前，要使用單元測試框架，對自己的模塊進行單元測試。盡量降低自己模塊的修改對其他模塊造成的影響。
建議封裝成以下這些模塊：
（1）輸入控制
對輸入進行有效性校驗，識別和處理無效輸入，並針對有效輸入，從中提取所需數據。
（2）核心處理
對輸入進行處理，如單詞詞頻統計，排序等，完成對應業務需求。
（3）輸出控制
對結果以合理方式輸出，將單詞詞頻排序的結果輸出到文件。
（4）其他
一些特殊模塊，如和架構相關的（例如main函數等）。
2.1.2 項目要求
圍繞2.1.1的說明，各小組應完成下述任務：
（1）給出任務分工，商議好模塊間的接口，將項目框架和分工提交到小組Github；
（2）各組員獨立完成自己所負責的模塊的編碼，並提交到小組Github；
（3）各組員針對自己的代碼，采用黑盒和白盒測試方法，設計至少20個測試用例，填寫測試用例清單，整理測試數據集；
（4）各組員采用單元測試框架，編寫單元測試腳本，並提交到小組Github，測試結果不需要提交；
（5）將所有代碼集成，打包成exe文件，提交到小組Github。
（6）使用git tag stage1，標記基本任務已經完成。往Github提交時，使用--tags參數，將tag推送到Github。
注：
建議另外創建小組的Git，也可以是組長的Git；測試用例文檔模板見附錄2：測試用例文檔模板。
對測試用例、測試數據集、測試腳本的要求詳見評分細則。
2.1.3 博客要求
（1）博客開頭給出Github項目地址；
（2）預估項目完成時間，完成PSP表格填寫（程序完成后，需再次在PSP表格中記錄實際花費的時間）；
（3）在自己的個人博客中說明對該接口的實現，請勿簡單貼代碼；
（4）說明如何考慮測試用例的設計，如何滿足測試效率的要求，請勿簡單羅列測試用例；
（5）給出單元測試的運行截圖，評價測試質量和被測模塊的質量；
（6）根據小組討論的結果，說明自己的小組貢獻分。
注：PSP最新表格見附錄3：PSP2.1表格；小組貢獻分的說明，詳見評分細則。
2.2 擴展任務：靜態測試
注意：小組中學有余力的同學，可繼續完成擴展任務要求，視完成情況，最高可得本次作業滿分的約85%。
且如果全部組員均完成本次擴展任務，則每個成員本次作業最終得分為原始分的105%。
2.2.1 任務說明
基本任務中，大家完成了對代碼的動態測試。
然而，在提交代碼之前，最好能利用工具，對代碼進行靜態掃描，以達到以下效果：
（1）確保整個小組中所有人員的代碼不會有一些常見的漏洞；
（2）確保整個小組中所有人員的代碼符合行業規范；
（3）確保整個小組中所有人員的代碼符合最基本的行業質量要求的。
2.2.2 項目要求
圍繞2.2.1的說明，各小組針對本組選定的開發語言，應完成下述任務：
（1）各組員閱讀對應開發規范，選擇其中部分規范，舉例說明自己對該規范的理解。
（2）各組員參照選定的那部分規范，對小組中另一個組員的部分代碼進行評價。
（3）各組員選擇至少一款靜態代碼檢查工具，對自己的全部代碼進行掃描，統計發現的錯誤和警告。
（4）各組員結合掃描的結果和其他人的意見，分析並改進自己的代碼，再次運行單元測試，觀察和之前有何不同。
（5）共同對整個小組的代碼進行評價，反思主要存在的問題，並改進代碼。將改進后的代碼提交到Github。
（6）使用git tag stage2，標記擴展任務已經完成。往Github提交時，使用--tags參數，將tag推送到Github。
注：
Java和C++語言的開發規范詳見附錄4：開發規范說明。（建議從我們給的開發規范中選擇，也可以自己選取其他的規范文檔）
靜態代碼檢查工具詳見附錄5：靜態代碼檢查工具。
【對規范的理解】范例如下：
《阿里巴巴Java開發手冊》中指出：【推薦】如果模塊、接口、類、方法使用了設計模式，在命名時體現出具體模式。 說明：將設計模式體現在名字中，有利於閱讀者快速理解架構設計理念。
根據我的實踐體會舉例如下：在代碼“public class OrderFactory;”中，類名稱的命名就體現了工廠模式的使用。
2.2.3 博客要求
（1）說明選擇了哪種開發規范文檔中的哪一部分；如果選擇的不是附錄4中的規范，說明選擇的理由，並給出該文檔的鏈接。
（2）說明使用該規范分析了哪位組員（說明學號后5位即可）的代碼，並說明其代碼有什么問題，或者說明其代碼遵循了哪些好的規范。
（3）說明選擇的是什么靜態代碼檢查工具，給出工具的下載地址。
（4）說明工具對代碼掃描的結果，應給出界面運行截圖。並說明代碼存在的問題和改進的方法。如果實在找不到問題，也可分析一下自己的代碼遵循了哪些好的規范。
（5）說明整個小組的代碼主要存在的問題，並說明代碼改進的方法，最好能給出圖、表等形式。
2.3 高級任務：性能測試和優化
注意：小組中學有余力的同學，可繼續完成高級任務要求，視完成情況，最高可得本次作業滿分的100%。
且如果大部分組員（僅缺席一名組員）均完成本次擴展任務，則每個成員本次作業最終得分為原始分的110%。高級任務與擴展任務的獎勵分數不疊加。
2.3.1 任務說明
對於一個執行統計和排序的程序來說，內存的占用，運算的速度，都是要滿足一定要求的。
所以我們需要設計程序的性能測試，來了解我們的程序是否符合這方面的要求，並根據測試的結果進行優化和改進。
2.3.2 項目要求
圍繞2.3.1的說明，各小組應完成下述任務：
（1）考慮多大的數據量會給程序帶來壓力，並由此構建測試數據集，即一個在內容上能造成足夠壓力的txt文檔。
（2）使用測試數據集，對當前程序的主要性能指標（即處理時長，以毫秒計算）進行測試和記錄。
（3）通過組內所有成員展開同行評審，針對可能影響或制約程序性能指標的主要因素加以討論。
（4）通過測試，發現影響或制約程序性能指標的主要因素，並與同行評審的結論進行比較，看二者是否一致；
（5）對程序代碼加以改進，優化程序性能（此步驟可選）；
（6）使用git tag stage3，標記高級任務已經完成。往Github提交時，使用--tags參數，將tag推送到Github。
注：
處理時長：在程序讀取txt文件時開始計時，一直到程序將所有結果輸出到結果文件時結束；
同行評審的內容和過程詳見附錄6：同行評審和代碼復審；
2.3.3 博客要求
（1）說明測試數據集的設計思路。
（2）說明優化前的程序性能指標。
（3）說明同行評審的過程，包括有哪些人參加，誰主持，誰評審，對什么進行評審，提出了什么意見等。
（4）說明實際測試后得到的結論，即影響性能指標的主要因素是什么，如果與同行評審的結論不一致，分析為什么會不一致。
（5）說明優化的設計思路，並給出優化后的程序性能指標。
（6）結合本次作業實踐，說明通過基本任務、擴展任務、到高級任務的完成，如何體現軟件開發、軟件測試、軟件質量之間的關系。
2.4 附加題
通過圖形用戶界面提供WordCount優化版的功能。形式如下：
wcPro.exe -x //該參數單獨使用，如果命令行有該參數，則程序會顯示圖形界面，用戶可以通過界面選取單個txt文件，程序就會對該文件進行單詞詞頻統計和排序，結果仍以指定格式輸出到默認文件中。
3. 附錄
3.1 附錄1：WordCount優化版功能需求說明
WordCount優化版的需求可以概括為：對記事本（txt）文件進行單詞的詞頻統計和排序，排序結果以指定格式輸出到默認文件中，並要求能夠快速地完成整個統計和結果輸出功能。
可執行程序命名為：wcPro.exe，該程序處理用戶需求的模式為：
wcPro.exe [input_file_name]
存儲統計結果的文件為result.txt，放在與wcPro.exe相同的目錄下。
具體細則見2.1.1到2.1.7的說明。
3.1.1 被處理的文件
第一，僅處理txt文件，不處理其他類型的文件。
第二，一次僅處理一個文件，不同時處理多個文件。
3.1.2 文件內容
文件中僅包含單詞（a-z， A-Z）、常見字符、數字(0-9)。不包含其他內容。
3.1.3 對單詞的規定
滿足如下兩個條件中的任意一個條件，則視為單詞，
第一，由連續的若干個英文字母組成的字符串，例如，software，
第二，用連字符（即短橫線）所連接的若干個英文單詞也視為1個單詞，例如，content-based，視為1個單詞。
注意，單詞不區分大小寫，不考慮英文以外的其他語言，且僅考慮半角。
有關單詞識別的部分典型情況的說明：
第一，Let’s，這種包含單引號的情況，視為2個單詞，即let和s。
第二，night-，帶短橫線的單詞，視為1個單詞，即night。
第三，“I，帶雙引號的單詞，視為1個單詞，即i。
第四，TABLE1-2，帶數字的單詞，視為1個單詞，即table。
第五，(see Box 3–2).8885d_c01_016，帶數字、常用字符和單詞的情況，視為4個單詞，即see, box, d, c。
3.1.4 對常見字符的規定
文件中包含的常見字符如下表所示，該表以外的特殊字符不考慮。
| 字符 |
~ |
` |
! |
# |
% |
^ |
& |
* |
_ |
... |
| 含義 |
波浪號 |
重音符號 |
感嘆號 |
井號 |
百分號 |
指數符號 |
與符號 |
星號 |
下划線 |
省略號 |
| 字符 |
( ) |
[ ] |
+ |
= |
- |
: |
; |
“ |
‘ |
| |
| 含義 |
左右 小括號 |
左右 方括號 |
加號 |
等於號 |
短橫線 |
冒號 |
分號 |
雙引號 |
單引號 |
豎線 |
| 字符 |
< |
> |
, |
. |
/ |
? |
|
|
|
|
| 含義 |
小於號 |
大於號 |
逗號 |
點 |
反斜杠 |
問號 |
空格 |
換行符 |
水平制表符 |
|
3.1.5 對詞頻的定義
詞頻即某單詞在文檔中出現的次數。
3.1.6 對輸出的規定
僅輸出單詞詞頻從高到低排序的前100個（從1到100），每行分別給出一個單詞及其詞頻，單詞按小寫形式給出，單詞和詞頻之間空一格。對於單詞詞頻相同的情況，按照單詞所包含的每個字母從a到z的次序依次排列。輸出文件末尾多余的換行符應去除。
形式如下：
| this 200 i 180 ij 180 the 180 |
3.1.7 對語言的規定
程序要求用Java或C++實現，其他語言恕不接受。
3.2 附錄2：測試用例文檔模板
測試用例設計清單(模板)。（受版權限制，測試用例設計清單請在課程平台的作業內容中點擊鏈接下載）
注意：填寫測試用例時，請在備注中說明使用的測試用例設計方法。
3.3 附錄3：PSP2.1表格
最新的PSP2.1表格如下表所示。
PSP2.1表格
| PSP2.1 |
PSP階段 |
預估耗時 （分鍾） |
實際耗時 （分鍾） |
| Planning |
計划 |
||
| · Estimate |
· 估計這個任務需要多少時間 |
||
| Development |
開發 |
||
| · Analysis |
· 需求分析 (包括學習新技術) |
||
| · Design Spec |
· 生成設計文檔 |
||
| · Design Review |
· 設計復審 (和同事審核設計文檔) |
||
| · Coding Standard |
· 代碼規范 (為目前的開發制定合適的規范) |
||
| · Design |
· 具體設計 |
||
| · Coding |
· 具體編碼 |
||
| · Code Review |
· 代碼復審 |
||
| · Test |
· 測試（自我測試，修改代碼，提交修改） |
||
| Reporting |
報告 |
||
| · Test Report |
· 測試報告 |
||
| · Size Measurement |
· 計算工作量 |
||
| · Postmortem & Process Improvement Plan |
· 事后總結, 並提出過程改進計划 |
||
| 合計 |
3.4 附錄4：開發規范說明
軟件開發，當然是要有規范的。正所謂：碼出高效，碼出質量。代碼評審，當然也是要采用一定的評審標准的。沒有標准，如何評審代碼？
Google很早就這樣做了。Google將公司內部采用的所有語言的編碼規范（其稱為Style Guide）都開源在Github上。這份清單中包括了C++、Objective-C、Java、Python、R、Shell、HTML/CSS、JavaScript、AngularJS、Common Lisp、Vimscript等語言的編程規范。並且Google還發布了一個用於檢查樣式合規性的工具cpplint以及在Emacs中使用Google編程樣式的配置文件google-c-style.el。
阿里巴巴也在做相同的事情，《阿里巴巴Java開發手冊》就是阿里巴巴集團技術團隊的集體智慧結晶和經驗總結，經歷了多次大規模一線實戰的檢驗及不斷的完善，於2017年11月30日正式對外發布，后經多次優化改版。
3.4.1 代碼規范與復審（精簡版）
如果你不想花太多精力來看幾十頁的代碼規范，不妨直接去看鄒欣老師在講義“現代軟件工程講義 3 代碼規范與代碼復審”中所討論的有關代碼規范與代碼復審的內容。內容短小精煉，適合快速入門。
3.4.2 阿里巴巴Java開發手冊
如果你選用Java為開發語言，請直接到官網查看完整的阿里巴巴Java開發手冊。
3.4.3 谷歌C++風格指南
如果你選用C++為開發語言，請閱讀Google之C++風格指南（中文版），查看谷歌如何從頭文件、作用域、類、函數等方面對編碼進行規定。如果你希望閱讀原汁原味的英文原版，請訪問：https://github.com/google/styleguide。
3.4.4 其他語言代碼規范
如果你想順便了解其他語言代碼規范，請訪問如下地址：https://blog.csdn.net/lavorange/article/details/51441695。
3.5 附錄5：靜態代碼檢查工具
代碼評審，全靠人工，可能是一件痛苦而低效的事情，通過采用靜態代碼檢查工具，可以大大提高工作效率。
對於使用Java為開發語言的小組，不妨閱讀靜態代碼檢查工具簡介來初步了解和篩選合適的靜態代碼檢查工具。
對於使用C++為開發語言的小組，則可通過谷歌的cpplint、cppcheck等工具來執行靜態代碼掃描。
當然，也可以訪問課程資源，了解有關國內自主產權的代碼掃描工具CodeAnalyzer（CA）工具。
3.6 附錄6：同行評審和代碼復審
有關同行評審和代碼復審的內容，大家可以閱讀鄒欣老師的博客：“代碼規范與代碼復審”，也可以到課程平台的第3周 白盒測試（續），觀看和了解相關內容。
4. 評分細則
本次作業總分66分。具體細則如下表所示。
| 基本任務評分細則 |
|||||
| 序號 |
評分項 |
評分子項 |
評分細則 |
備注 |
滿分 |
| 1 |
程序作業 (30分) |
獨立模塊編碼 |
代碼符合接口設計，設計合理，注釋合理 |
個人分 |
5分 |
| 測試用例設計 |
測試用例格式規范，設計合理，至少20個，至少能結合課堂介紹的方法來設計測試用例。 |
個人分 |
3分 |
||
| 單元測試腳本 |
能使用測試框架編寫測試腳本，測試腳本設計合理，滿足對測試用例的覆蓋要求，與測試數據獨立，便於重用，便於管理，注釋合理，能體現單元測試的運行及結果。（可參照課堂講解來編寫腳本） |
個人分 |
8分 |
||
| 接口及框架搭建 |
接口定義清晰，框架設計合理。 |
小組分 |
4分 |
||
| 源代碼管理 |
通過源代碼管理中的commit注釋信息，增量修改的內容，是否有運行說明、任務分工等給分。 |
小組分 |
5分 |
||
| 程序正確性 |
應圍繞需求，滿足基本的正確性要求，運行結果應正確無誤，有exe文件。 |
小組分 |
5分 |
||
| 2 |
博 客 (15分) |
Github項目地址 |
在文章開頭給出Github項目地址，地址缺失或錯誤均不得分。 |
個人分 |
1分 |
| 填寫PSP表格 |
包括程序開發前預估的各模塊開發時間， 及程序各模式的實際開發時間。 |
個人分 |
2分 |
||
| 描述代碼設計思路 |
說明如何設計實現該接口。 |
個人分 |
3分 |
||
| 測試設計過程 |
如何設計測試用例，如何滿足測試效率的要求。 |
個人分 |
3分 |
||
| 測試運行和評價 |
給出單元測試的運行截圖，評價自己的單元測試效果以及被測模塊的質量水平。 |
個人分 |
4分 |
||
| 作業改進 |
對老師和助教的點評做出了中肯的回應，包括回復評論與改進博客，可得2分； 否則，如不回應老師和助教的點評，或不改進博客，或隨便敷衍老師和助教的點評（例如，“嗯嗯”“好”等），則不得分 |
個人分 |
2分 |
||
| 3 |
|
小組貢獻率 |
應清晰說明小組貢獻率的分配方案。 |
不適用 |
|
| 擴展任務評分細則 |
|||||
| 序號 |
評分項 |
評分子項 |
評分細則 |
備注 |
滿分 |
| 1 |
程序作業 (6分) |
源代碼管理 |
通過源代碼管理中的commit注釋信息，增量修改的內容 |
小組分 |
1分 |
| 交叉代碼評審 |
對其他組員的代碼進行檢查。 |
小組分 |
1分 |
||
| 靜態代碼掃描 |
使用代碼掃描工具檢查代碼，檢查自己的所有代碼。 |
個人分 |
2分 |
||
| 代碼改進和單元測試 |
代碼改進，重新運行單元測試。 |
小組分 |
2分 |
||
| 2 |
博客 (5分) |
開發規范說明 |
說明選定的開發規范，以及用於檢查代碼的內容。 |
個人分 |
1分 |
| 交叉代碼評審 |
說明代碼評審對象，分析結論清晰，有理有據。 |
個人分 |
1分 |
||
| 靜態代碼掃描 |
說明使用的掃描工具，給出下載地址。 說明掃描結果，給出運行截圖，分析結論清晰，有理有據。 |
個人分 |
2分 |
||
| 組內代碼分析 |
說明整個小組的代碼質量，分析結論清晰，有理有據。 |
個人分 |
1分 |
||
| 3 |
|
小組貢獻率 |
應清晰說明小組貢獻率的分配方案。 |
不適用 |
|
| 高級任務評分細則 |
|||||
| 序號 |
評分項 |
評分子項 |
評分細則 |
備注 |
滿分 |
| 1 |
程序作業 (5分) |
測試數據集 |
測試數據集設計合理。 |
小組分 |
1分 |
| 性能指標記錄 |
記錄程序優化前和優化后的處理時長 |
小組分 |
1分 |
||
| 同行評審 |
能展開同行評審 |
小組分 |
1分 |
||
| 性能分析和優化 |
找到制約性能的因素，提升性能 |
小組分 |
2分 |
||
| 性能排名 |
按照程序處理時長（耗時最短）排名，前30% |
附加分 |
3分 |
||
| 2 |
博客 (5分) |
測試數據集 |
說明測試數據集的設計思路，描述清晰。 |
個人分 |
1分 |
| 同行評審過程描述 |
過程描述清晰，結論明確。 |
個人分 |
1分 |
||
| 性能分析 |
能清晰說明同行評審與實測的差異，得出有關影響程序性能的因素分析的結論。 |
個人分 |
1分 |
||
| 性能優化 |
清晰說明性能優化的設計思路 |
個人分 |
1分 |
||
| 作業小結 |
能結合本次實踐來談軟件開發、軟件測試、軟件質量之間的關系。論述清晰。 |
個人分 |
1分 |
||
| 3 |
|
小組貢獻率 |
應清晰說明小組貢獻率的分配方案。 |
不適用 |
|
| 附加題評分細則 |
|||||
| 序號 |
評分項 |
評分子項 |
評分細則 |
備注 |
滿分 |
| 圖形用戶界面 |
按照2.4節完成WordCount的圖形用戶界面功能，且運行正確。 |
附加分 |
5分 |
||
4.2 小組貢獻率及其與作業分的關系
小組作業中，每個同學都是為了小組榮譽而“戰”，采用小組貢獻率來評價大家的貢獻，要求如下：
（1）小組貢獻率在0到1之間取值；
（2）每人的貢獻率不能相同；
（3）所有成員的貢獻率總和應等於1；
（4）貢獻率精確到小數點后2位。
個人作業最終得分 = 小組分 * 實際貢獻率 / 人均應貢獻率 + 個人分 + 附加分。（附加分不計入作業映射分）
以4人小組為例，在基本任務中，小組分為12分，甲、乙、丙、丁四人對小組的貢獻率分別為0.3, 0.25, 0.35, 0.2。此時，人均應貢獻率為0.25（即1/4），而甲的個人分為26分，則甲的最終得分 = 12 * 0.3 / 0.25 + 26 = 40.4分。
4.3 補充說明
（1）對於完成了擴展任務，甚至完成了高級任務的小組而言，小組貢獻率在全部作業完成后一並給出，例如，某小組在完成基本任務的基礎上，還完成了擴展任務，則給出的小組貢獻率是針對基本任務和擴展任務的總體貢獻率，不單獨計算針對每個任務的小組貢獻率。
（2）對於完成了擴展任務，甚至完成了高級任務的小組而言，博客一次性提交，即，基本任務、擴展任務、高級任務的博客作業對應一篇博客。按照各次作業的博客內容要求，分標題撰寫即可。不必寫多篇博客。針對博客評論的改進同此要求。
5. 其他注意事項
注意按時提交作業。
- 按時間完成並提交——正常評分
- 晚交一周以內——0分
- 遲交一周以上或不交——倒扣本次作業分數
- 抄襲——按本次作業滿分的兩倍倒扣分數。【嚴禁代碼與博客等一切形式的抄襲！請各位同學千萬不要觸碰底線！】