【正文】 ，方便添加老師信息后可以及時的設(shè)置任課信息，如下圖： 課程設(shè)置注：其他模塊功能類似，此處也再不贅述。 本章小結(jié)在概要設(shè)計的基礎(chǔ)上，對系統(tǒng)的模塊結(jié)構(gòu)進(jìn)行分析設(shè)計，對系統(tǒng)模塊的界面和實(shí)現(xiàn)源代碼進(jìn)行了設(shè)計與實(shí)現(xiàn)5 班級管理系統(tǒng)系統(tǒng)測試 概述 隨著web應(yīng)用的增多，新的模式解決方案中以web為核心的應(yīng)用也越來越多，很多公司各種應(yīng)用的架構(gòu)都以B/S及web應(yīng)用為主，但是有關(guān)WEB測試方面的內(nèi)容并沒有相應(yīng)的總結(jié)，因此，在開發(fā)空警管理系統(tǒng)時，對web應(yīng)用程序的測試方法和采用的測試技術(shù)進(jìn)行總結(jié)。測試方法盡量涵蓋web程序的各個方面，測試技術(shù)方面在繼承傳統(tǒng)測試技術(shù)的技術(shù)上結(jié)合web應(yīng)用的特點(diǎn)。 測試方法 [11] 界面測試 很多人認(rèn)為這是測試中最不重要的部分，但是恰恰相反界面測試是相當(dāng)重要的確。主要包括以下幾個方面的內(nèi)容：各個空間位置是否合理，是否可以實(shí)現(xiàn)對應(yīng)功能、內(nèi)容布局布局是否合理，是否正確、背景/色調(diào)是否正確、美觀，是否符合用戶需求； 窗口中的控件顯示是否正確、美觀（在調(diào)整窗口大小時，是否有明顯的閃爍影響）表格樣式大小，格式，是否對提交數(shù)據(jù)進(jìn)行有效驗(yàn)證，功能是否易于理解等。 測試技術(shù)結(jié)合兼容性測試對不用分辨率下頁面顯示效果，如果有影響則提出解決方案。可以結(jié)合數(shù)據(jù)定義文檔查看表單項(xiàng)的內(nèi)容，長度等信息。界面測試要素: 符合標(biāo)準(zhǔn)和規(guī)范,靈活性,正確性,直觀性,舒適性,實(shí)用性,一致性 功能測試 對功能測試是測試中的重點(diǎn)，主要包括以下內(nèi)容： 表格數(shù)據(jù)提交應(yīng)當(dāng)模擬用戶提交，具有驗(yàn)證格式等信息是否正確的功能，要測試這些程序，需要驗(yàn)證服務(wù)器能正確保存這些數(shù)據(jù)，而且后臺運(yùn)行的程序能正確解釋和使用這些信息。還有數(shù)據(jù)正確性驗(yàn)證，異常處理等，最好結(jié)合易用性要求等。C/S結(jié)構(gòu)實(shí)現(xiàn)的功能可能主要的就在這里，提交數(shù)據(jù)，處理數(shù)據(jù)等如果有固定的操作流程可以考慮自動化測試工具的錄制功能，編寫可重復(fù)使用的腳本代碼，可以在測試、回歸測試時運(yùn)行以便減輕測試人員工作量。白盒測試技術(shù)(White Box Testing) 深入到代碼一級的測試，使用這種技術(shù)發(fā)現(xiàn)問題最早，效果也是最好的。該技術(shù)主要的特征是測試對象進(jìn)入了代碼內(nèi)部,根據(jù)開發(fā)人員對代碼和對程序的熟悉程度,對有需要的部分進(jìn)行在軟件編碼階段，開發(fā)人員根據(jù)自己對代碼的理解和接觸所進(jìn)行的軟件測試叫做白盒測試。黑盒測試技術(shù)（Black Box Testing）黑盒測試的內(nèi)容主要有以下幾個方面，但是主要還是功能部分。主要是覆蓋全部的功能，可以結(jié)合兼容，性能測試等方面進(jìn)行，根據(jù)軟件需求，設(shè)計文檔，模擬客戶場景隨系統(tǒng)進(jìn)行實(shí)際的測試，這種測試技術(shù)是使用最多的測試技術(shù)涵蓋了測試的方方面面，可以考慮以下方面： 正確性 (Correctness)、可用性 (Usability)、邊界條件 (Boundary Condition)、性能 (Performance) 壓力測試 (Stress) 多用戶情況可以考慮使用壓力測試工具,查看服務(wù)器CPU使用率,內(nèi)存占用情況,如果有必要可以模擬大量數(shù)據(jù)輸入,(軟硬件都可以).這里的壓力測試針對的是某幾項(xiàng)功能. 錯誤恢復(fù) (Error Recovery) 錯誤處理，頁面數(shù)據(jù)驗(yàn)證,包括突然間斷電,輸入臟數(shù)據(jù)等. 安全性測試(Security)這個領(lǐng)域正在研究中,不過防火墻,不過可以考慮破壞性測試時任意. 兼容性 (Compatibility) 不同瀏覽器，不同應(yīng)用程序版本在實(shí)現(xiàn)功能時的表現(xiàn),不同的上網(wǎng)方式,如果你測試的是一個公共網(wǎng)站的話. 功能測試邊界測試\越界測試技術(shù)詳述 邊界條件 邊界條件是指軟件計劃的操作界限所在的邊緣條件. 如果軟件測試問題包含確定的邊界,那么數(shù)據(jù)類型可能是: 數(shù)值速度字符地址位置尺寸數(shù)量 同時,考慮這些類型的下述特征: 第一個/最后一個最小值/最大值 開始/完成超過/在內(nèi) 空/滿最短/最長 最慢/最快最早/最遲 最大/最小最高/最低 相鄰/最遠(yuǎn) 越界測試 通常是簡單加1或者很小的數(shù)(對于最大值)和減少1或者很小的數(shù)(對于最小值),例如: 第一個減1/最后一個加1 開始減1/完成加1 空了再減/滿了再加 慢上加慢/快上加快 最大數(shù)加1/最小數(shù)減1 最小值減1/最大值加1 剛好超過/剛好在內(nèi) 短了再短/長了再長 早了更早/晚了更晚 最高加1/最低減1 另一些該注意的輸入:默認(rèn),空白,空值,零值和無。非法,錯誤,不正確和垃圾數(shù)據(jù). 狀態(tài)測試技術(shù) 軟件可能進(jìn)入的每一種獨(dú)立狀態(tài)。 從一種狀態(tài)轉(zhuǎn)入另一種狀態(tài)所需的輸入和條件。 進(jìn)入或退出某種狀態(tài)時的設(shè)置條件及輸入結(jié)果.具體測試方法可以參考如下: 每種狀態(tài)至少訪問一次。 測試看起來最常見最普遍的狀態(tài)轉(zhuǎn)換。 測試狀態(tài)之間最不常用的分支 測試所有錯誤狀態(tài)及其返回值 測試隨機(jī)狀態(tài)轉(zhuǎn)換 競爭條件測試技術(shù) 競爭條件典型情形參考如下: 兩個不同的程序同時保存或打開同一個文檔 共享同一臺打印機(jī),通信端口或者其他外圍設(shè)備 當(dāng)軟件處于讀取或者修改狀態(tài)時按鍵或者單擊鼠標(biāo) 同時關(guān)閉或者啟動軟件的多個實(shí)例 同時使用不同的程序訪問一個共同數(shù)據(jù)庫 負(fù)載\壓力測試(StressTest) 在這里的負(fù)載\壓力和功能測試中的不同,他是系統(tǒng)測試的內(nèi)容,亦可以在系統(tǒng)測試階段進(jìn)行.使用負(fù)載測試工具進(jìn)行,虛擬一定數(shù)量的用戶看一看系統(tǒng)的表現(xiàn),是否滿足定義中的指標(biāo). 負(fù)載測試一般使用工具完成，loadrunner，webload，was，ewl，etest等，主要的內(nèi)容都是編寫出測試腳本，腳本中一般包括用戶一般常用的功能，然后運(yùn)行，得出報告。所以負(fù)載測試包括的主要內(nèi)容就不介紹了。無論什么工具基本的技術(shù)都是利用線程技術(shù)模仿和虛擬用戶，在這里主要的難點(diǎn)在與測試腳本的編寫，每種工具使用的腳本都不一樣，但是大多數(shù)工具都提供錄制功能就算是不會編碼的測試人員同樣可以測試。 對負(fù)載工具的延伸使用可以進(jìn)行系統(tǒng)穩(wěn)定性測試，系統(tǒng)極限測試，如使用100的Load Size連續(xù)使用24小時，微軟定義的通過準(zhǔn)則是通過72小時測試的程序一般不會出現(xiàn)穩(wěn)定性的問題。 不同的測試技術(shù)區(qū)分 覆蓋測試技術(shù) 說明:測試覆蓋率可以看出測試的完成度,在測試分析報告中可以作為量化指標(biāo)的依據(jù)，測試覆蓋率越高效果越好。覆蓋測試可以是程序代碼的執(zhí)行路徑覆蓋，亦可以是功能實(shí)現(xiàn)的步驟覆蓋（可以理解成流程圖的路徑覆蓋）。該技術(shù)可以用在任何測試階段，包括單元測壞死、集成測試、系統(tǒng)測試。使用該技術(shù)時可以使用以上的任何測試方法和測試技術(shù)。 白盒測試和黑盒測試技術(shù) 白盒測試技術(shù) (White Box Testing)該技術(shù)主要的特征是測試對象進(jìn)入了代碼內(nèi)部,根據(jù)開發(fā)人員對代碼和對程序的熟悉程度,對有需要的部分進(jìn)行在軟件編碼階段，開發(fā)人員根據(jù)自己對代碼的理解和接觸所進(jìn)行的軟件測試叫做白盒測試。這一階段測試以軟件開發(fā)人員為主，使用Xunit系列工具進(jìn)行測試，可以包括很多方面如功能性能等。黑盒測試 (Black Box Testing)測試的主體部分黑盒測試的內(nèi)容主要有以下幾個方面，但是主要還是功能部分。主要是覆蓋全部的功能，可以結(jié)合兼容，性能測試等方面進(jìn)行,包括的不同測試類型請參考以上內(nèi)容。 手工測試和自動化測試 手工測試（Manual Testing）：即依靠人力來查找Bug。方法可以參考上邊的測試，也可以根據(jù)對實(shí)現(xiàn)技術(shù)及經(jīng)驗(yàn)等進(jìn)行不同的測試。 自動測試（Automation Testing）使用有針對工具實(shí)行?？梢宰鞒鲎詣踊瘻y試的計劃,對可以進(jìn)行自動化測試的部分編寫或者錄制相應(yīng)的腳本,可以加入功能,容錯,表單提交等,可以參考MI,Rational或者其他類測試工具說明.根據(jù)權(quán)威的軟件測試經(jīng)驗(yàn)，手工測試還是主要的測試方法，自動測試不夠靈活，在這里不再詳述。微軟的測試過程80％還是手工完成。自動測試永遠(yuǎn)也代替不了手工測試，但是手工測試的工作量很大是不爭的事實(shí)。 由于測試環(huán)境操作系統(tǒng)，網(wǎng)絡(luò)環(huán)境，帶寬等情況可能產(chǎn)生的測試結(jié)果可能不同這是就需要經(jīng)驗(yàn)以及對測試環(huán)境的保護(hù)等方面下一些功夫。 軟件缺陷的原則 軟件缺陷區(qū)別于軟件bug,它是在測試過程中出現(xiàn)的對系統(tǒng)有影響的,但是在設(shè)計中沒有的或者對修改后的bug測試和開發(fā)人員有不同意見等軟件未達(dá)到產(chǎn)品說明書標(biāo)明的功能。 軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤。 軟件功能超出產(chǎn)品說明書指明范圍。 軟件未達(dá)到產(chǎn)品說明書雖未指出但應(yīng)達(dá)到的目標(biāo)。 軟件測試員認(rèn)為軟件難以理解、不易使用、運(yùn)行速度緩慢，或者最終用戶認(rèn)為不好。 6 開發(fā)技巧和難點(diǎn)本系統(tǒng)開發(fā)的技術(shù)難點(diǎn)主要有兩個方面：一是否業(yè)務(wù)邏輯的理解；二是數(shù)據(jù)庫邏輯結(jié)構(gòu)的設(shè)計。業(yè)務(wù)邏輯是依據(jù)空警管理系統(tǒng)的行業(yè)特點(diǎn)及其特殊的應(yīng)用領(lǐng)域需要來進(jìn)行設(shè)計的。只有在準(zhǔn)確不理解一個系統(tǒng)的業(yè)務(wù)邏輯之后才可能開發(fā)出適應(yīng)其應(yīng)用的應(yīng)用系統(tǒng)來,并且在系統(tǒng)之間模塊的科學(xué)劃分與結(jié)構(gòu)組織都是在正確不理解實(shí)際應(yīng)用的業(yè)務(wù)邏輯需求的前提下完成的。數(shù)據(jù)庫設(shè)計是應(yīng)用系統(tǒng)開發(fā)的另一個難點(diǎn),只有科學(xué)的數(shù)據(jù)庫設(shè)計才能使系統(tǒng)具有良好的結(jié)構(gòu)及良好的可編程性,在開發(fā)相關(guān)數(shù)據(jù)庫方面的管理系統(tǒng)時,都需要充分考慮到科學(xué)性、結(jié)構(gòu)性、規(guī)范性、安全性、可擴(kuò)展等相關(guān)問題。系統(tǒng)編譯標(biāo)準(zhǔn)(建議)要求 Microsoft Windows XP Professional(SP3) .net Framework Microsoft SQL Server 2000企業(yè)版(SP3) Microsoft Visual 2008企業(yè)架構(gòu)版 已啟動生成: 項(xiàng)目: CMS, 配置: Debug Any CPU CMS C:\Documents and Settings\Administrator\桌面\CMS\CMS\bin\Debug 已啟動生成: 項(xiàng)目: ButtonEx, 配置: Debug Any CPU ButtonEx C:\Documents and Settings\Administrator\桌面\CMS\ButtonEx\bin\Debug========== 生成: 成功或最新2 個，失敗0 個，跳過0 個==========7 結(jié)束語經(jīng)過二個多月的設(shè)計和開發(fā)，系統(tǒng)基本開發(fā)完畢。其功能基本符合用戶需求，能夠完成學(xué)生學(xué)籍的存儲和成績的查詢、刪除等功能。但是由于畢業(yè)設(shè)計時間較短，所以該系統(tǒng)還有許多不盡如人意的地方，比如用戶界面不夠美觀，功能不太完善，系統(tǒng)健壯性不強(qiáng)等多方面問題。這些都有待進(jìn)一步改善。 8 致謝： 在論文完成之際，首先我要向我的導(dǎo)師康萬新老師致以衷心的感謝。本論文在編寫的過程中得到了康萬新老師的幫助和指導(dǎo),并提供了大量有價值的資料；在撰寫論文的過程中，康萬新老師多次審閱我們的論文，指出了缺點(diǎn)和不足，提出了許多寶貴意見，使得我能夠順利完成論文的撰寫任務(wù)?？等f新老師老師用淵博的專業(yè)知識、嚴(yán)謹(jǐn)?shù)闹螌W(xué)精神、高尚的職業(yè)道德指引我在學(xué)習(xí)中不斷探索，相信會讓我在今后的人生道路上受益匪淺。在此我向康萬新老師表示深深的感謝！同時我還感謝母校的老師,沒有他們就不會現(xiàn)在的系統(tǒng).最后，誠摯地感謝為評閱本論文而付出辛勤勞動的各位專家和學(xué)者！參考文獻(xiàn)[1] 張海藩：《軟件工程導(dǎo)論》（第五版），清華大學(xué)出版社，P259P288[2] 楊樹林、胡潔萍：《C程序設(shè)計與案例教程》，清華大學(xué)出版社，P1P6[3] (美) 麥斯科 顏炯 譯:《C設(shè)計模式》，中國電力出版社，P130P144[4] 張蒲生、何升：《SQL Server數(shù)據(jù)庫應(yīng)用技術(shù)》，清華大學(xué)出版社，P20P35[5] 徐孝凱、賀桂英：《數(shù)據(jù)庫基礎(chǔ)與SQL Server應(yīng)用開發(fā)》，清華大學(xué)出版社， P1P6[6] 張海藩：《軟件工程導(dǎo)論》（第五版），清華大學(xué)出版社，P216P228[7] 王小科、呂雙、梁冰：《C完全自學(xué)手冊》，人民郵電出版社，P132P221[8] （美）羅賓遜、（美）內(nèi)格爾 著 李敏波 譯:《C高級編程（第3版）》 | Simon Robinson Christian Nagel，清華大學(xué)出版社，P301P345[9] 啟明工作室：《MIS系統(tǒng)開發(fā)與應(yīng)用(C+SQL Server版)》，人民郵電出版社，P211P310[10] Stanley B. Lippman著 侯捷、陳碩 譯：《C Primer中英文版》(C Primer A Practical Approach)，華中科技大學(xué)出版社，P154P203[11] （美）托馬斯 等著，陳偉樁 陶文 譯《單元測試之道C版——使用Nunit》| Pragmatic Unit Testing in C with NUnit Andrew Hunt,David Thomas，電子工業(yè)出版社 ，P38P49