2018年3月29日23:59 php
要求html
1. 對源文件（*.txt,*.cpp,*.h,*.cs,*.html,*.js,*.java,*.py,*.php等，文件夾內的全部文件）統計字符數、單詞數、行數、詞頻，統計結果以指定格式輸出到默認文件中，以及其餘擴展功能，並可以快速地處理多個文件。java
2. 使用性能測試工具進行分析，找到性能的瓶頸並改進git
3. 對代碼進行質量分析，消除全部警告github
http://msdn.microsoft.com/en-us/library/dd264897.aspx編程
4. 設計10個測試樣例用於測試，確保程序正常運行（例如：空文件，只包含一個詞的文件，只有一行的文件，典型文件等等）windows
5. 使用Github進行代碼管理編程語言
6. 撰寫博客 工具
基本功能post
1. 統計文件的字符數（只須要統計Ascii碼，漢字不用考慮）
2. 統計文件的單詞總數
3. 統計文件的總行數（任何字符構成的行，都須要統計）
4. 統計文件中各單詞的出現次數，輸出頻率最高的10個。
5. 對給定文件夾及其遞歸子文件夾下的全部文件進行統計
6. 統計兩個單詞（詞組）在一塊兒的頻率，輸出頻率最高的前10個。
7. 在Linux系統下，進行性能分析，過程寫到blog中（附加題）
注意：
a) 空格，水平製表符，換行符，均算字符
b) 單詞的定義：至少以4個英文字母開頭，跟上字母數字符號，單詞以分隔符分割，不區分大小寫。
英文字母：A-Z，a-z
字母數字符號：A-Z，a-z，0-9
分割符：空格，非字母數字符號
例如：」file123」是一個單詞，」123file」不是一個單詞。file，File和FILE是同一個單詞。
若是兩個單詞只有最後的數字結尾不一樣，則認爲是同一個單詞，例如，windows，windows95和windows7是同一個單詞，iPhone4和IPhone5是同一個單詞，可是，windows和windows32a是不一樣的單詞，由於他們不是僅有數字結尾不一樣
輸出按字典順序，例如，windows95，windows98和windows2000同時出現時，輸出windows2000
詞組的定義：windows95 good， windows2000 good123，能夠算是同一種詞組。按照詞典順序輸出。三詞相同的情形，好比good123 good456 good789，根據定義，則是 good123 good123 這個詞組出現了兩次。
c) 輸入文件名以命令行參數傳入。須要遍歷整個文件夾時，則要輸入文件夾的路徑。
d) 輸出文件result.txt
characters: number
words: number
lines: number
<word>: number
<word>爲文件中真實出現的單詞大小寫格式，例如，若是文件中只出現了File和file，程序不該當輸出FILE，且<word>按字典順序（基於ASCII）排列，上例中程序應該輸出File: 2
e) 根據命令行參數判斷是否爲目錄
f) 將全部文件中的詞彙，進行統計，最終只輸出一個總體的詞頻統計結果。
項目管理
1. 分析整理需求，完成PSP表格
PSP是卡耐基梅隆大學（CMU）的專家們針對軟件工程師所提出的一套模型：Personal Software Process (PSP， 我的開發流程，或稱個體軟件過程)。
一個功能完備的程序不是一蹴而就的。經過將詞頻統計的需求劃分爲4個部分，可將一個大任務劃分爲可操做的小任務，同時最好按照任務難度或緊急程度指定各個任務的完成次序。所以，在動手開發以前，要先估計將在程序各模塊開發所需耗費的時間，以及完成整個項目所需的時間，將這個[估計值]記錄下來，寫成PSP 的形式。
PSP的目的是：記錄工程師如何實現需求的效率，和咱們使用項目管理工具（例如微軟的Project Professional，或者禪道等）進行項目進度規劃相似。
有關PSP的更多內容，請自行閱讀鄒欣老師的博客：
http://www.cnblogs.com/xinz/archive/2011/10/22/2220872.html
PSP可用teambition工具製做
2. 使用Github進行代碼管理
使用PSP作好規劃以後，第二步固然是進行編碼實現，此時，除了選擇合適的編程語言，還須要學會良好的源代碼管理。
請閱讀鄒欣老師的博客：源代碼管理，瞭解源代碼管理的10個實踐問題。
本次做業要求使用Github進行源代碼管理，代碼有進展即簽入Github。簽入記錄不合理的項目會被助教抽查詢問項目細節。
對代碼簽入的具體要求以下：根據需求劃分功能後，每作完一個功能，編譯成功後，應至少commit一次。本例中，至少應區分基本功能和擴展功能，即分別針對基本功能、擴展功能，編譯成功後，總共至少應commit兩次。具體的功能劃分，請自行定義，並在撰寫博客時體現出來，遵循本身對需求的功能劃分來提交代碼便可。
對Commit不是很熟悉的話，請閱讀阮一峯的博客：Commit message 和 Change log 編寫指南，瞭解更多細節。
3. 設計測試用例，編寫單元測試
做爲一門測試的課程，測試纔是重點。請根據本身以往積累的測試經驗，結合本週介紹的測試用例設計方法，在編碼完成以後，提交產品以前，設計測試用例，並編寫單元測試，對本身的項目進行測試。
首先，至少應採用白盒測試用例設計方法來設計測試用例，其餘測試方法不限。其次，要設計至少10個測試用例，確保你的程序可以正確處理各類狀況。最後，結合測試評估的要求，對本身的測試設計進行評價，這些測試用例能知足該程序測試的要求嗎？
另外一個重要的措施是要把單元測試自動化，這樣每一個人都能很容易地運行它，而且可使單元測試天天都運行。每一個人均可以隨時在本身的機器上運行。團隊通常是在每日構建中運行單元測試的，這樣每一個單元測試的錯誤就能及時被發現並獲得修改。
推薦閱讀鄒欣老師關於單元測試和迴歸測試的博客：
http://www.cnblogs.com/xinz/archive/2011/11/20/2255830.html
博客要求
1. 需求分析，估計各部分所需時間，給出PSP表格
2. 記錄實際完成各部分時間
3. 對代碼質量和性能進行分析
4. 測試用例設計和分析過程
5. 描述你在次項目中得到的經驗
評分標準
1. 統計文件的字符數(2分)
2. 統計文件的單詞總數(2分)
3. 統計文件的總行數(2分)
4. 統計文件中各單詞的出現次數(2分)
5. 對給定文件夾及其遞歸子文件夾下的全部文件進行統計(4分)
6. 統計兩個單詞（詞組）在一塊兒的頻率，輸出頻率最高的前10個(4分)
以上六個結果輸出錯誤則對應子任務得-2分，所有輸出正確則按運行時間肯定排名(用時按升序前30%得滿分16分，30%-70%得15分，後30%得14分)。
7. 博客撰寫(代碼實現過程，性能分析、優化報告等)(4分)
8. 在Linux系統下，進行性能分析，過程寫到blog中（附加題，2分）
代碼提交地址：
https://github.com/eudaem/homework1
注意：做業延遲，1周內補交，0分；不交做業-10分。