【正文】 verWorker，并啟動 ReceiverWorker線程。 ReceiverWorker 線程執(zhí)行的是 ReceiverStart()方法。在 ReceiverStart()中，創(chuàng)建一個 TcpListener 的實(shí)例 tcpListener，其監(jiān)聽局域網(wǎng)內(nèi)的任意 IP 地址在 8088 端口號上是否有傳入的連接嘗 試。 當(dāng) ReceiverWorker線程監(jiān)聽到遠(yuǎn)程用戶的文件傳入請求，彈出消息提示框，用戶可以選擇同意或拒絕文件傳入請求。若同意，用戶選擇文件保存路徑后，向發(fā)起方發(fā)送同意接受信號，并開啟計(jì)時器，讀取傳入的文件流并將其保存到本地文件，文件接收完畢時關(guān)閉計(jì)時器。若用戶拒絕文件傳入，則向遠(yuǎn)程主機(jī)發(fā)送一個拒絕信號。最后，執(zhí)行關(guān)閉 BinaryReader，關(guān)閉 Socket 等操作 。 當(dāng)用戶打開文件發(fā)送窗體，主窗體調(diào)用其帶 ip參數(shù)的構(gòu)造方法，實(shí)參為當(dāng)前與之建立連接的遠(yuǎn)程主機(jī)的 ip 地址，用于發(fā)送文件時建立 socket連接使用。 當(dāng)用戶向 txtFile 文本框內(nèi)輸入所選取的待發(fā)送文件后，用戶單擊“開始”按鈕， 24 開啟用于向遠(yuǎn)端發(fā)送文件的 SenderWorker線程。 SenderWorker線程執(zhí)行 SenderStart()方法。 SenderStart()方法將創(chuàng)建一個 TcpClient 的實(shí)例 tcpClient，嘗試連接指定的ip地址的 8088 端口，將文件的信息發(fā)送給遠(yuǎn)程主機(jī)并等待遠(yuǎn)程主機(jī)的確認(rèn)。若接收方同意接收文件，則啟動計(jì)時器并打開 BinaryWriter，將本地文件發(fā)送給遠(yuǎn)程主機(jī)，文件傳輸完畢時關(guān)閉計(jì)時器。若遠(yuǎn)程主機(jī) 拒絕接收，則關(guān)閉此次 socket 連接，等待下一次文件發(fā)送事件的觸發(fā)。 用戶管理模塊實(shí)現(xiàn) 用戶管理模塊概述 不管是任何系統(tǒng)，都必然會有用戶這個角色，因此用戶管理是每一個應(yīng)用中必不可少的部分。由于 企業(yè)內(nèi)部的信息越來越私密，企業(yè)只希望員工通過內(nèi)部局域網(wǎng)進(jìn)行溝通與交流，所以 在本局域網(wǎng)聊天工具中，設(shè)計(jì)一個簡單用戶管理模塊，對接入服務(wù)器的用戶進(jìn)行管理，能在一定程度上解決安全性問題。本模塊實(shí)現(xiàn)采用了 xml 技術(shù)，二次開發(fā)時，通過一定的修改，能夠很好的移植到數(shù)據(jù)庫上。 用戶數(shù)據(jù)模型 本模塊實(shí)現(xiàn) 一個簡單的用戶管理，所管理的目標(biāo)是局域網(wǎng)內(nèi)客戶端用戶。模塊中只涉及到用戶一個模型，涉及到的屬性項(xiàng)目有 用戶 ID、 用戶名 (姓名 )、 密碼 、 注冊時間 等，其 ER 圖如圖 59所示。 圖 59 用戶信息 ER 圖 25 XML 文檔結(jié)構(gòu)設(shè)計(jì) XML 分為文件序言（ Prolog）和文件主體兩個大的部分。在此文件中的第一行即是文件序言。它主要是告訴 XML 解析器如何工作。其中， version 是標(biāo)明此 XML 文件所用的標(biāo)準(zhǔn)的版本號 ， encoding 指明了此 XML 文件中所使用的字符類型為 utf8。 文件的其余部分都是屬于文件主體， 文件的內(nèi)容信息存放在此。文件主體是由開始的 userInfosList和結(jié)束的 /userInfosList控制標(biāo)記組成，這個稱XML 文件的“根元素”； user是作為直屬于根元素下的“子元素”；在 user下又有userName、 userPwd、 datesInsert這些子元素。 id 是 user元素中的一個“屬性”，“ 1001”、“ 1002”等則是“屬性值”。 文檔結(jié)構(gòu)如圖 510所示。 圖 510 用戶信息的保存 通過服務(wù)器監(jiān)聽，接收到客戶端的注冊請求后，獲取注冊用戶的信息，判斷用戶是否為第一個注冊用戶，若是，則創(chuàng)建 文檔，進(jìn)而創(chuàng)建 userInfoList 根節(jié)點(diǎn)，在 userInfoList 內(nèi)創(chuàng)建用戶 user 節(jié)點(diǎn)，設(shè)置 id 屬性，然后在 user 節(jié)點(diǎn)下創(chuàng)建用戶名、密碼、創(chuàng)建時間等節(jié)點(diǎn)，將相應(yīng)的信息保存到各節(jié)點(diǎn)中。若 已存在，遍歷 userInfoList，查找該注冊用戶名在 中是否已存在。若用戶名不存在，則在 userInfoList 內(nèi)創(chuàng)建新的 user 節(jié)點(diǎn)，然后在 user 節(jié)點(diǎn)下創(chuàng)建用戶名、密碼、創(chuàng)建時間等，將用戶信息添加進(jìn) 文檔中。若用戶名已被注冊，則通過服務(wù)器向客戶端返回用戶名已經(jīng)被注冊的提示信息。保存數(shù)據(jù)的流程圖如圖 511所示。 26 圖 511 保存數(shù)據(jù)的程序流程圖 用戶數(shù)據(jù)的遍歷 在新用戶注冊或者已注冊用戶登錄時，需要在 文檔中查找用戶名是否存在，這個就涉及到 xml 文件的遍歷。遍歷 xml 文件的主要流程是，先進(jìn)入userInfoList根節(jié)點(diǎn)，開始對 user節(jié)點(diǎn)進(jìn)行遍歷。若 user節(jié)點(diǎn)不存在，則返回不存在信息，結(jié)束遍歷；否則進(jìn)入 user節(jié)點(diǎn)，對其子節(jié)點(diǎn) userName進(jìn)行對比。若匹配成功，則返回用戶名存在信息；若不匹配，則繼續(xù)遍歷下一個 user節(jié)點(diǎn)。工作流程圖如圖 512 所示。 是否是第一個注冊用戶？ 是 獲取最后一個用戶的 ID號并將 ID加 1作為該user的 ID屬性值 否 創(chuàng)建 XML文檔 創(chuàng)建根節(jié)點(diǎn) 向 user節(jié)點(diǎn)中添加 用戶名、密碼、注冊時間節(jié)點(diǎn) 在根節(jié)點(diǎn)內(nèi)添加user節(jié)點(diǎn) 設(shè)置 user的 ID屬性值 1001 用戶是否已存在？ 否 是 返回用戶已存在 在根節(jié) userInfosList內(nèi)添加 user節(jié)點(diǎn) 開始 結(jié)束 27 圖 512 用戶數(shù)據(jù)的遍歷 程序流程圖 返回不存在 進(jìn)入 user 節(jié)點(diǎn) 用戶名匹配？ Y 返回存在 進(jìn)入根節(jié)點(diǎn) 第 i個 user結(jié)點(diǎn)是否存在 否 是 否 是 i=1 i=i+1 開始 結(jié)束 28 第 6 章 系統(tǒng)測試 系統(tǒng)測試概述 測試的 目的是為了發(fā)現(xiàn)功能是否達(dá)到，或者是否有更多的缺陷！ 這里的缺陷是泛稱的，它可以指功能的錯誤，也可以指性能低下，易用性差等。測試總是先假設(shè)程序中存在缺陷，再通過執(zhí)行程序來發(fā)現(xiàn)并最終改正缺陷。理解測試的目的是個很重要的意識問題。如果說測試的目的是為了說明程序中沒有缺陷，那么測試人員就會向這個目標(biāo)靠攏，因而下意識地選用一些不易暴露錯誤的測試示例。這樣的測試是虛假的。 測試只能證明缺陷存在，而不能證明缺陷不存在。 這個真理告訴我們，對于一個復(fù)雜的系統(tǒng)而言，無論采取什么樣的測試手段都不能證明缺陷已經(jīng)不復(fù)存在。“徹底地 測試”只是一種理想。在實(shí)踐中，測試要考慮時間、費(fèi)用等限制，不允許無休止地測試。 測試有助于提高軟件的質(zhì)量，但是提高軟件的質(zhì)量不能依賴于測試。 因?yàn)樽鰹橐粋€本科畢業(yè)設(shè)計(jì)，本系統(tǒng)并不會真正發(fā)布到廣大的用戶群中去，所以只能做α測試，而無法完成β測試。 關(guān)于測試人員的安排，由我本人和莫景順一起做白盒測試，由同學(xué)幫助做黑盒測試。 白盒測試 測試環(huán)境配置 白盒測試可在開發(fā)系統(tǒng)的本機(jī)上直接進(jìn)行，所以不需要進(jìn)行特殊的配置。 正確性測試 正確性測試檢查軟件的功能是否符合規(guī)格說明。由于正確性是軟 件最重要的質(zhì)量因素，所以其測試也最重要。 在集成 P2P文本聊天時，最開始只能發(fā)起一次連接，通信雙方斷開連接而不退出程序時，再次連接就提示套接字已被占用異常。通過在 disconnect時關(guān)閉當(dāng)前的套接字，使之可以進(jìn)行多次連接。 當(dāng)兩個客戶端在建立連接時，出現(xiàn)過程序假死異常。分析代碼發(fā)現(xiàn)，線程調(diào)度出錯，接收消息線程 th還未創(chuàng)建和啟動，監(jiān)聽線程 wait已經(jīng)被銷毀了！修改代碼，給出兩種解 29 決辦法： 在 th線程的執(zhí)行方法中，將 wait線程銷毀；在 th線程銷毀前，重新開啟 wait線程。 wait線程不銷毀。設(shè)置一 bool類型變量 isconnected，當(dāng)已經(jīng)建立連接后，isconnected=true，若再有其他的連接請求到達(dá)，自動將其他連接請求拒絕。連接斷開后，重置 isconnected=false，將處理移交給用戶。我采用了第一種方法，調(diào)試之后，問題解決。 在程序退出時，常常發(fā)生錯誤，異常退出，造成表面上看程序已結(jié)束，但卻仍然駐留在內(nèi)存中的現(xiàn)象。經(jīng)過反復(fù)分析代碼，最終確定問題出在程序退出處理流程上，通過修改和調(diào)試，問題解決。 整個開發(fā)過程中，共歷經(jīng) 200多次相互斷開、連接測試， P2P文本聊天模塊終于可以正常運(yùn)行。借 助在 P2P文本聊天模塊開發(fā)過程中積累的經(jīng)驗(yàn)，較順利的完成了 P2P文件傳輸模塊的開發(fā)。通過在總集成后的程序的各個流程中添加消息提示框顯示程序內(nèi)部數(shù)據(jù)、對象的狀態(tài)，并插入斷點(diǎn)進(jìn)行單步跟蹤發(fā)現(xiàn)各模塊工作正常，數(shù)據(jù)也未發(fā)生異?，F(xiàn)象。 黑盒測試 測試環(huán)境配置 用兩臺或兩臺以上機(jī)器通過交換機(jī)等構(gòu)成一個局域網(wǎng)，進(jìn)行正確的網(wǎng)絡(luò)配置，每臺機(jī)器上都安裝了 WINDOWS操作系統(tǒng) 、 DirectX SDK 以及 .NET ，并安裝了本軟件的正確拷貝。 功能性測試 先在其中一臺機(jī)器 A上啟動服務(wù)端軟 件，開啟監(jiān)聽服務(wù)。當(dāng) A機(jī)器和 B機(jī)器啟動了客戶端軟件后，向服務(wù)器進(jìn)行登錄操作，服務(wù)器端驗(yàn)證了用戶的登錄后，向局域網(wǎng)廣播客戶端的登錄狀態(tài)。 A客戶端收到服務(wù)器發(fā)來的信息后，更新自己的用戶表，然后此時，不管 A,B雙方，只要雙擊用戶列表中相應(yīng)的項(xiàng)目，即可啟動發(fā)信對話框，若 B當(dāng)前為空閑狀態(tài)，則雙方建立 TCP連接，開始進(jìn)行聊天通信，可以進(jìn)行信息的輸入與發(fā)送，發(fā)起語聊，傳輸文件等。同時，對方均可進(jìn)行正確的接收和回復(fù)。所以，功能測試為成功。 容錯性測試 容錯性測試是檢查軟件在異常條件下的行為。容錯性好的軟件能確保 系統(tǒng)不發(fā)生無 30 法意料的事故。 經(jīng)檢查，當(dāng)用戶輸入無效操作時，系統(tǒng)總是能檢測到無效操作，對用戶進(jìn)行相應(yīng)的信息反饋，并合理的做出內(nèi)部處理。當(dāng)系統(tǒng)本身發(fā)生錯誤，比如網(wǎng)絡(luò)初始化失敗，綁定套接字失敗，數(shù)據(jù)讀取失敗等，都會進(jìn)行相對應(yīng)的正確處理。 例如當(dāng)文件傳輸時，用戶輸入的文件不存在，而單擊“開始”時，會有如圖 61所示的錯誤提示。 圖 61 用戶操作出錯信息提示示意圖 性能與效率測試 關(guān)于性能的問題，在語聊時，未對語音輸入設(shè)備采集到的信息進(jìn)行編碼，緩沖數(shù)也較少，所以當(dāng)用戶所處環(huán)境較狹小時，回音將產(chǎn)生嘯叫 。改用麥克風(fēng)和耳機(jī)之后，一定程度上阻斷回音的影響，通話質(zhì)量基本上能滿足要求。 文件傳輸?shù)臅r候，通過對文件長度以及已傳輸信息量的相減運(yùn)算，顯示出當(dāng)前傳輸狀態(tài)，需要占用較多的系統(tǒng)計(jì)算資源和時間，而且傳輸速度相對 IPMSG等軟件，慢太多。這個問題，我通過對文件流緩沖的字節(jié)數(shù)進(jìn)行增大，設(shè)置為 8KB后，計(jì)算量減少，傳輸速度明顯加快，通過計(jì)時器計(jì)時，最后得出的傳輸速率與 IPMSG相比，大致一樣。因?yàn)閷τ趲捪鄬^大，至少都是 10Mbps的局域網(wǎng)來說，信息的發(fā)送和接收，在局域網(wǎng)內(nèi)幾乎就是瞬間響應(yīng)，造成速度瓶頸的不是網(wǎng)絡(luò)傳 輸因素，而是頻繁的對磁盤設(shè)備進(jìn)行讀寫所致，而傳輸過程中頻繁的計(jì)算也是造成系統(tǒng)資源消耗過大的一個原因。通過改進(jìn)算法后，文件傳輸效率基本上能滿足用戶要求。另外，此設(shè)計(jì)中未限制傳輸文件的大小，經(jīng)測試， 5GB以上的文件也能夠通過文件傳輸模塊進(jìn)行傳輸。因此，和其他的類似軟件相 31 比較，有更大的應(yīng)用范圍。 易用性測試 易用性測試沒有一個量化的指標(biāo)，主觀性較強(qiáng)。一般認(rèn)為，如果一個系統(tǒng)可以讓用戶不查閱手冊即可正確使用其所有功能，那么這個系統(tǒng)就具有良好的易用性。本聊天工具使用過程中提示信息詳細(xì)，界面友好，操作簡單，新 用戶能夠很快學(xué)會使用，所以具有比較好的易用性。 文檔測試 在本系統(tǒng)的開發(fā)過程中，因?yàn)槭潜究飘厴I(yè)設(shè)計(jì)，所以具有完備的開題報(bào)告，文獻(xiàn)綜述，任務(wù)書，以及最終的論文做總結(jié)闡述，整個文檔所以說文檔方面也比較完整。 32 第 7 章 主要問題及解決 多線程問題 因?yàn)楸鞠到y(tǒng)的客戶端程序采用 P2P 模式，每個用戶即可以使服務(wù)的發(fā)起端，又可以使服務(wù)的接收端，所以必須在程序加載時對網(wǎng)絡(luò)進(jìn)行監(jiān)聽，監(jiān)聽聊天連接請求和文件傳輸連接請求，并能夠?qū)悍桨l(fā)起的事件進(jìn)行處理，因而必須在此應(yīng)用程序中使用多線程技術(shù)，耗時的任務(wù)可以在后臺執(zhí)行，而使應(yīng)用程序窗口和控件保持響應(yīng)。對于應(yīng)用程序監(jiān)聽功能，多線程處理提供了用不同線程處理每個傳入請求的能力。否則，在完全滿足前一個請求之前，將無法處理其他的新的請求。在兩個用戶的通信過程中，任何一方斷開連接之后，要像對方發(fā)送斷開信號，而對方接收到傳入的斷開信 號后，需斷開 Socket、NetStream 等，并重新開啟監(jiān)聽線程，銷毀接收消息線程。在開發(fā)的時候，經(jīng)常因?yàn)榫€程的創(chuàng)建和銷毀不當(dāng)，而造成程序假死或者異常退出，卻沒有釋放其占用的端口等資源。另外一個問題，程序退出的時候，未將線程處理好，同樣造成