【正文】 另外一個問題，程序退出的時候，未將線程處理好，同樣造成資源占用。在兩個用戶的通信過程中，任何一方斷開連接之后，要像對方發(fā)送斷開信號，而對方接收到傳入的斷開信 號后，需斷開 Socket、NetStream 等，并重新開啟監(jiān)聽線程，銷毀接收消息線程。對于應(yīng)用程序監(jiān)聽功能，多線程處理提供了用不同線程處理每個傳入請求的能力。 文檔測試 在本系統(tǒng)的開發(fā)過程中，因為是本科畢業(yè)設(shè)計，所以具有完備的開題報告，文獻綜述，任務(wù)書，以及最終的論文做總結(jié)闡述，整個文檔所以說文檔方面也比較完整。一般認為，如果一個系統(tǒng)可以讓用戶不查閱手冊即可正確使用其所有功能，那么這個系統(tǒng)就具有良好的易用性。因此，和其他的類似軟件相 31 比較，有更大的應(yīng)用范圍。通過改進算法后，文件傳輸效率基本上能滿足用戶要求。這個問題，我通過對文件流緩沖的字節(jié)數(shù)進行增大，設(shè)置為 8KB后，計算量減少，傳輸速度明顯加快，通過計時器計時，最后得出的傳輸速率與 IPMSG相比，大致一樣。改用麥克風(fēng)和耳機之后，一定程度上阻斷回音的影響，通話質(zhì)量基本上能滿足要求。 例如當文件傳輸時，用戶輸入的文件不存在，而單擊“開始”時，會有如圖 61所示的錯誤提示。 經(jīng)檢查，當用戶輸入無效操作時，系統(tǒng)總是能檢測到無效操作，對用戶進行相應(yīng)的信息反饋，并合理的做出內(nèi)部處理。 容錯性測試 容錯性測試是檢查軟件在異常條件下的行為。同時，對方均可進行正確的接收和回復(fù)。當 A機器和 B機器啟動了客戶端軟件后，向服務(wù)器進行登錄操作，服務(wù)器端驗證了用戶的登錄后，向局域網(wǎng)廣播客戶端的登錄狀態(tài)。 黑盒測試 測試環(huán)境配置 用兩臺或兩臺以上機器通過交換機等構(gòu)成一個局域網(wǎng)，進行正確的網(wǎng)絡(luò)配置，每臺機器上都安裝了 WINDOWS操作系統(tǒng) 、 DirectX SDK 以及 .NET ，并安裝了本軟件的正確拷貝。借 助在 P2P文本聊天模塊開發(fā)過程中積累的經(jīng)驗，較順利的完成了 P2P文件傳輸模塊的開發(fā)。經(jīng)過反復(fù)分析代碼，最終確定問題出在程序退出處理流程上，通過修改和調(diào)試，問題解決。我采用了第一種方法，調(diào)試之后，問題解決。設(shè)置一 bool類型變量 isconnected，當已經(jīng)建立連接后，isconnected=true，若再有其他的連接請求到達，自動將其他連接請求拒絕。分析代碼發(fā)現(xiàn)，線程調(diào)度出錯，接收消息線程 th還未創(chuàng)建和啟動，監(jiān)聽線程 wait已經(jīng)被銷毀了！修改代碼，給出兩種解 29 決辦法： 在 th線程的執(zhí)行方法中，將 wait線程銷毀；在 th線程銷毀前，重新開啟 wait線程。通過在 disconnect時關(guān)閉當前的套接字，使之可以進行多次連接。由于正確性是軟 件最重要的質(zhì)量因素，所以其測試也最重要。 白盒測試 測試環(huán)境配置 白盒測試可在開發(fā)系統(tǒng)的本機上直接進行，所以不需要進行特殊的配置。 因為做為一個本科畢業(yè)設(shè)計，本系統(tǒng)并不會真正發(fā)布到廣大的用戶群中去，所以只能做α測試，而無法完成β測試。在實踐中，測試要考慮時間、費用等限制，不允許無休止地測試。 這個真理告訴我們，對于一個復(fù)雜的系統(tǒng)而言，無論采取什么樣的測試手段都不能證明缺陷已經(jīng)不復(fù)存在。這樣的測試是虛假的。理解測試的目的是個很重要的意識問題。 是否是第一個注冊用戶？ 是 獲取最后一個用戶的 ID號并將 ID加 1作為該user的 ID屬性值 否 創(chuàng)建 XML文檔 創(chuàng)建根節(jié)點 向 user節(jié)點中添加 用戶名、密碼、注冊時間節(jié)點 在根節(jié)點內(nèi)添加user節(jié)點 設(shè)置 user的 ID屬性值 1001 用戶是否已存在？ 否 是 返回用戶已存在 在根節(jié) userInfosList內(nèi)添加 user節(jié)點 開始 結(jié)束 27 圖 512 用戶數(shù)據(jù)的遍歷 程序流程圖 返回不存在 進入 user 節(jié)點 用戶名匹配？ Y 返回存在 進入根節(jié)點 第 i個 user結(jié)點是否存在 否 是 否 是 i=1 i=i+1 開始 結(jié)束 28 第 6 章 系統(tǒng)測試 系統(tǒng)測試概述 測試的 目的是為了發(fā)現(xiàn)功能是否達到，或者是否有更多的缺陷！ 這里的缺陷是泛稱的，它可以指功能的錯誤，也可以指性能低下，易用性差等。若匹配成功，則返回用戶名存在信息；若不匹配，則繼續(xù)遍歷下一個 user節(jié)點。遍歷 xml 文件的主要流程是，先進入userInfoList根節(jié)點，開始對 user節(jié)點進行遍歷。保存數(shù)據(jù)的流程圖如圖 511所示。若用戶名不存在，則在 userInfoList 內(nèi)創(chuàng)建新的 user 節(jié)點，然后在 user 節(jié)點下創(chuàng)建用戶名、密碼、創(chuàng)建時間等，將用戶信息添加進 文檔中。 圖 510 用戶信息的保存 通過服務(wù)器監(jiān)聽，接收到客戶端的注冊請求后，獲取注冊用戶的信息，判斷用戶是否為第一個注冊用戶，若是，則創(chuàng)建 文檔，進而創(chuàng)建 userInfoList 根節(jié)點，在 userInfoList 內(nèi)創(chuàng)建用戶 user 節(jié)點，設(shè)置 id 屬性，然后在 user 節(jié)點下創(chuàng)建用戶名、密碼、創(chuàng)建時間等節(jié)點，將相應(yīng)的信息保存到各節(jié)點中。 id 是 user元素中的一個“屬性”，“ 1001”、“ 1002”等則是“屬性值”。 文件的其余部分都是屬于文件主體， 文件的內(nèi)容信息存放在此。它主要是告訴 XML 解析器如何工作。 圖 59 用戶信息 ER 圖 25 XML 文檔結(jié)構(gòu)設(shè)計 XML 分為文件序言（ Prolog）和文件主體兩個大的部分。 用戶數(shù)據(jù)模型 本模塊實現(xiàn) 一個簡單的用戶管理，所管理的目標是局域網(wǎng)內(nèi)客戶端用戶。由于 企業(yè)內(nèi)部的信息越來越私密，企業(yè)只希望員工通過內(nèi)部局域網(wǎng)進行溝通與交流，所以 在本局域網(wǎng)聊天工具中，設(shè)計一個簡單用戶管理模塊，對接入服務(wù)器的用戶進行管理，能在一定程度上解決安全性問題。若遠程主機 拒絕接收，則關(guān)閉此次 socket 連接，等待下一次文件發(fā)送事件的觸發(fā)。 SenderStart()方法將創(chuàng)建一個 TcpClient 的實例 tcpClient，嘗試連接指定的ip地址的 8088 端口，將文件的信息發(fā)送給遠程主機并等待遠程主機的確認。 當用戶向 txtFile 文本框內(nèi)輸入所選取的待發(fā)送文件后，用戶單擊“開始”按鈕， 24 開啟用于向遠端發(fā)送文件的 SenderWorker線程。最后，執(zhí)行關(guān)閉 BinaryReader，關(guān)閉 Socket 等操作 。若同意，用戶選擇文件保存路徑后，向發(fā)起方發(fā)送同意接受信號，并開啟計時器，讀取傳入的文件流并將其保存到本地文件，文件接收完畢時關(guān)閉計時器。在 ReceiverStart()中，創(chuàng)建一個 TcpListener 的實例 tcpListener，其監(jiān)聽局域網(wǎng)內(nèi)的任意 IP 地址在 8088 端口號上是否有傳入的連接嘗 試。 主窗體加載時，創(chuàng)建文件接收監(jiān)聽線程 ReceiverWorker，并啟動 ReceiverWorker線程。 否 執(zhí)行監(jiān)聽線程，監(jiān)聽端口 是 否 啟動計時器，接收文件流，顯示文件接收狀態(tài)信息 終止 保存文件 開始 是 是 否 接收端允許？ 啟動計時器，發(fā)送文件流，顯示文件 發(fā)送狀態(tài)信息 將本地文件發(fā)送至接收端 發(fā)送文件？ 否 是 有文件傳入請求 允許接收？ 23 圖 58 文件發(fā)送窗體界面 文件傳輸窗體主要控件屬性見表 52。當用戶未選取文件前，開始按鈕不可用，當用戶輸入的文件不存在時，彈出消息提示框，提示文件不存在錯誤。設(shè)計的時候，采用了一些簡單按鈕，布局也和常用的窗體類似。 P2P 文件傳輸工作流程圖如 圖 57所示。當有文件傳入請求，用戶可以同意或者拒絕接收，若同意接收，則按照文件傳輸接 收端模塊工作流程執(zhí)行。這樣就實現(xiàn)了 P2P模式對等傳輸。文件傳輸發(fā)送端工作流程圖如圖 56所示。 20 圖 55 文件傳輸接收端程序流程圖 文件傳輸發(fā)送端工作原理 開啟窗體后，發(fā)送端選擇用戶需要發(fā)送的文件，向接收端發(fā)起的文件傳輸請求，若接收端端同意接收，開啟計時器，將本地文件通過網(wǎng)絡(luò)發(fā)送給接收端，并在文件傳輸過程中對文件傳輸狀態(tài)進行反饋，文件發(fā)送完畢，關(guān)閉計時器，關(guān)閉文件流，并在狀態(tài)欄上顯示出完畢狀態(tài)。若拒絕接收，則向發(fā)送端返回拒絕信號，繼續(xù)執(zhí)行監(jiān)聽線程，等待下一次的文件傳入請求。當接收到客戶發(fā)起的文件傳入請求后，彈出消息提示對話框，提示用戶對請求進行處理，同意或者拒絕接收。由于 TCP協(xié)議能 保證數(shù)據(jù)包的準確到達以及各數(shù)據(jù)包到達的順序和數(shù)據(jù)包發(fā)出的順序相同， 出于可靠性和效率考慮，本模塊也采用 TCP 協(xié)議來進行用戶之間文件的傳輸。通過文件共享， 企業(yè)能提高信息交換的速度，從而提高工作效率。若是關(guān)閉窗體，還需將 wait 線程關(guān)閉。 send_Click 事件主要是將用戶的輸入通過Socket，采用網(wǎng)絡(luò)流的形式傳輸給遠程用戶，編碼采用 Unicode，同時在聊天記錄框里面顯示出來。若有，創(chuàng)建TcpClient的對象 tcpc，并嘗試連接遠程主機。讀取到的消息如果不為斷開 連接信號，則在聊天記錄框里面顯示出來；若為斷開信號，則執(zhí)行 disconnect()方法關(guān)閉當前連接。若用戶拒絕遠程接入請求，則關(guān)閉網(wǎng)絡(luò)流 nss，關(guān)閉 tcps，并調(diào)用 disconnect()重新初始化相關(guān)變量。 當 wait 線程監(jiān)聽到 19 遠程用戶的接入連接請求，彈出消息提示框，用戶可以選擇同意或拒絕接入請求。創(chuàng)建監(jiān)聽線程 wait， wait 線程執(zhí)行的是 waitconn()方法， 啟動監(jiān)聽線程 。 表 51 文本聊天窗體主要控件屬性表 控件 屬性 值 GroupBox Name groupbox1 Text 信息顯示 RichTextBox Name richTxtInfos Readonly TRUE RichTextBox Name richTxtSent Readonly FALSE Active KeyDown Button Name send Text 發(fā)送消息 Button Name clearbox Text 清除屏幕 Button Name savelog Text 消息記錄 4) 具體實現(xiàn) 定義相關(guān)變量。主窗體界面如圖 54所示。文本輸入框設(shè)計了 Alt+S 和 Ctrl+Enter 熱鍵功能，方便用戶快速的發(fā)送消息。 圖 53 P2P文本聊天程序流程圖 3) 集成主窗體設(shè)計 主窗體是用來與用戶交互用的 ，所以加載時間不能太長，響應(yīng)速度應(yīng)足夠快，操作簡單，設(shè)計人性化。當有接入連接請求，同意或拒絕接入請求，若同意，則按照文本聊天服務(wù)器模塊工作流程執(zhí)行。簡言之，用這個程序可以在網(wǎng)絡(luò)中發(fā)送、接受消息，任何一臺計算機既可以作為服務(wù)器端，又可以作為客戶端。它是建立在 TcpListener 以及 TcpClient 這兩個類基礎(chǔ)上的。文本聊天客戶端工作流程圖如圖 52所示。若服務(wù)器端拒絕連接，則釋放 Socket 連接并關(guān)閉網(wǎng)絡(luò)流。 15 圖 51 文本聊天服務(wù)器程序流程圖 文本聊天客戶端工作原理 客戶端用來向服務(wù)器端發(fā)起一個連接，等待服務(wù)器的允許接入確認。若已建立連接，當斷開連接時，將向?qū)Ψ桨l(fā)送斷開信號，然后將釋放 Socket和網(wǎng)絡(luò)流，不影響到下一次連接的接入。若服務(wù)器端拒絕客戶端的連接，則關(guān)閉tcpconnect，并關(guān)閉網(wǎng)絡(luò)流，繼續(xù)執(zhí)行監(jiān)聽?？蛻舳耸盏椒?wù)器返回的同意信號后，也開啟接收信息線程，并置消息發(fā)送事件為 Enable。收到客戶發(fā)起的連接請求后，若服務(wù)器處于空閑狀態(tài)，彈出消息提示框， 對請求進行處理，服務(wù)器可以選擇接受或者拒絕客戶端的連接。所以，在文本聊天模塊中，采用 TCP 協(xié)議來傳輸文本信息。 TCP 協(xié)議是互聯(lián)網(wǎng)中最重的協(xié)議之一，主要特點是：保證數(shù)據(jù)包的準確到達；保證各數(shù)據(jù)包到達的順序和數(shù)據(jù)包發(fā)出的順序相同。通過文本聊天，局域網(wǎng)內(nèi)用戶能夠發(fā)送和接收文字信息，并在程序窗體上顯示出來，相互之間進行在線交流，并能根據(jù)用戶需要，對聊天記錄進行簡單的保存。 表 41 小組成員分工情況表 學(xué)號 成員姓名 負責模塊 xxxxx xxxx 服務(wù)器模塊、客戶端模塊、語音聊天模塊 ***** **** 文本聊天模塊、文件傳輸模塊、用戶管理模塊 客戶端 已注冊？ 登錄 登錄驗證 主窗體 對話框窗體 服務(wù)器端 服務(wù)器 （記錄所有注冊用戶和顯示所有當前在線用戶） 注冊 發(fā)消息 發(fā)消息 N Y Y 服務(wù)器 （