軟件測試畢業(yè)設(shè)計說明

1、師學院本科畢業(yè)設(shè)計題目：班級管理系統(tǒng)的測試學 號：姓 名:年 級：系 別：專 業(yè)：完成日期: 指導老師:班級管理系統(tǒng)的測試學號:指導教師:摘要 在軟件生命周期的各個階段，都有可能會產(chǎn)生差錯。雖然在每個階段結(jié)束之前希有嚴格的復審，以期望 能盡早的發(fā)現(xiàn)錯誤，但是經(jīng)驗表明審查并不能發(fā)現(xiàn)所有差錯。如果在軟件投入生產(chǎn)性運行之前，沒有發(fā)現(xiàn)大部 分錯誤，則這些錯誤遲早會在運行過程中暴寃出來，甚至遙成嚴重的后果，等到那時去改這些錯誤的代價會很 高。測試的目的就是在軟件投入生產(chǎn)性運行之前，盡可能地發(fā)現(xiàn)軟件中的錯誤，測試是對軟件規(guī)格說明、設(shè)計 和編碼的最后復審，所以軟件測試貫穿在整個軟件開發(fā)期的全過程。要對軟件進

2、行測試首先要明白軟件要實現(xiàn) 的功能，否則無法對軟件進行測試。本文在分析軟件測試的方法、目的、流程圖等基本概念的基礎(chǔ)上，重點介 紹了對自己開發(fā)的班級管理系統(tǒng)的測試。關(guān)鍍詞：安裝測試、功能測試、性能測試、單元測試1. 軟件測試的概念1.1軟件測試的定義軟件測試(Software testing)是軟件生存期(Software life cycle)中的一個重要階段, 是軟件質(zhì)量保證的關(guān)鍵步驟。通俗地講，軟件測試就是在軟件投入運行前，對軟件需求分析、 設(shè)計規(guī)格說明和編碼進行最終復審的活動。1983年IEEE提出的軟件工程術(shù)語中給軟件測試下的 定義是：“使用人工或自動的手段來運行或測定某個軟件系統(tǒng)的過

3、程，其目的在于檢驗它是否 滿足規(guī)定的需求或弄清預期結(jié)果與實際結(jié)果之間的差別”。這個定義明確指出：軟件測試的目 的是為了檢驗軟件系統(tǒng)是否滿足需求。從用戶的角度來看，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，所以軟件測試 應該是“為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程”?；蛘哒f，軟件測試應該根據(jù)軟件開發(fā)各階段的規(guī) 格說明和程序的部結(jié)構(gòu)而精心設(shè)計一批測試用例(即輸入數(shù)據(jù)及其預期的輸出結(jié)果)，并利用這 些測試用例去運行程序，以發(fā)現(xiàn)程序錯誤或缺陷。1.2軟件測試的目的、原則、基本要求1.2.1測試的目的1. 檢驗開發(fā)出來的軟件是否符合用戶的需求。2. 盡可能多地發(fā)現(xiàn)程序中的錯誤和缺陷。1.2.2基本要求(測

4、試人員)1. 了解軟件的總體設(shè)計思路和詳細設(shè)計過程2. 對整套軟件的數(shù)據(jù)流程要十分清晰1.2.3測試用例由測試數(shù)據(jù)和相應的預期結(jié)果構(gòu)成。在測試之前，一定要設(shè)計好測試數(shù)據(jù)和相應的預期結(jié) 果，這是測試用例的基本原則和進行有效測試的最好途徑之一1.2.4測試原則1. 根據(jù)測試數(shù)據(jù)來確定預期的輸出結(jié)果。2. 徹底檢查每個測試結(jié)果（正確的、錯誤的），并對測試結(jié)果進行認真和仔細的分析。3. 對非法的和非預期的輸入數(shù)據(jù)也要像合法的和預期的輸入數(shù)據(jù)一樣編寫測試用例。4. 以挑剔的眼光來看待每個程序模塊不要設(shè)想程序中不會出現(xiàn)錯誤。程序做了它不該做 的事情，即使是正確的，我們也應該把它視為錯誤。5. 程序模塊經(jīng)測

5、試后，殘存的錯誤數(shù)目一般與已發(fā)現(xiàn)的錯誤數(shù)目成正比例。也就是說，一個 模塊中發(fā)現(xiàn)的錯誤越多，那么它可能殘存的錯誤數(shù)目也就越多，對這樣的程序模塊，一定要進行 嚴格和更徹底的測試。6. 要保存測試用例。2. 軟件測試的方法2. 1軟件測試的基本方法軟件測試的方法和技術(shù)是多種多樣的。對于軟件測試技術(shù)，可以從不同的角度加以分類： 從是否需要執(zhí)行被測軟件的角度，可分為靜態(tài)測試和動態(tài)測試。從測試是否針對系統(tǒng)的部結(jié)構(gòu) 和具體實現(xiàn)算法的角度來看，可分為白盒測試和黑盒測試。2. 1. 1黑盒測試黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試，它是在已知產(chǎn)品所應具有的功能，通過測試來檢 測每個功能是否都能正常使用，在測試時，把

6、程序看作一個不能打開的黑盒子，在完全不考慮 程序部結(jié)構(gòu)和部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求 規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息，并且保 持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊界值分析、因 果圖、錯誤推測等，主要用于軟件確認測試?！昂诤小狈ㄖ塾诔绦蛲獠拷Y(jié)構(gòu)、不考慮部 邏輯結(jié)構(gòu)、針對軟件界面和軟件功能進行測試。黑盒”法是窮舉輸入測試，只有把所有可能 的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮 多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但

7、是可能的輸入進行測試。2. 1.2白盒測試白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，它是知道產(chǎn)品部工作過程，可通過測試來檢測產(chǎn) 品部動作是否按照規(guī)格說明書的規(guī)定正常進行，按照程序部的結(jié)構(gòu)測試程序，檢驗程序中的每 條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅(qū)動、 基路測試等，主要用于軟件驗證。“白盒”法全面了解程序部邏輯結(jié)構(gòu)、對所有邏輯路徑進行測試?！鞍缀小狈ㄊ歉F舉路徑 測試。在使用這一方案時，測試者必須檢查程序的部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測試 數(shù)據(jù)。貫穿程序的獨立路徑數(shù)是天文數(shù)字。但即使每條路徑都測試了仍然可能有錯誤。第一， 窮舉路徑測試決不能查出程序違反了

8、設(shè)計規(guī)，即程序本身是個錯誤的程序。第二，窮舉路徑測 試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的 錯誤。2. 1. 3 ALAC(Act-1 ike-a-customer)測試圖ALAC測試哪些客戶最容易遇到的錯誤圖(1)ALAC測試是一種基于客戶使用產(chǎn)品的知識開發(fā)出來的測試方法。ALAC測試是基于復雜的軟 件產(chǎn)品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對哪些客戶最容易遇到 的錯誤。2.2單元測試的基本方法單元測試的對象是軟件設(shè)計的最小單位一一模塊。單元測試的依據(jù)是詳細設(shè)計描述，單元 測試應對模塊所有重要的控制路徑設(shè)計測試用例，以便發(fā)現(xiàn)模塊

9、部的錯誤。單元測試多采用白 盒測試技術(shù)，系統(tǒng)多個模塊可以并行地進行測試。2.2.1單元測試任務(wù)單元測試任務(wù)包括：1模塊接口測試；2模塊局部數(shù)據(jù)結(jié)構(gòu)測試；3模塊邊界條件測試；4 模塊中所有獨立執(zhí)行通路測試；5模塊的各條錯誤處理通路測試。模塊接口測試是單元測試的基礎(chǔ)。只有在數(shù)據(jù)能正確流入、流岀模塊的前提下，其他測試 才有意義。測試接口正確與否應該考慮下列因素：1. 輸入的實際參數(shù)與形式參數(shù)的個數(shù)是否相同和屬性是否匹配；2. 輸入的實際參數(shù)與形式參數(shù)的量綱是否一致；3. 調(diào)用其他模塊時所給實際參數(shù)的個數(shù)是否與被調(diào)模塊的形參個數(shù)相同；4. 調(diào)用其他模塊時所給實際參數(shù)的屬性是否與被調(diào)模塊的形參的屬性是否

10、匹配；5. 調(diào)用其他模塊時所給實際參數(shù)的量綱是否與被調(diào)模塊的形參量綱一致；6. 調(diào)用預定義函數(shù)時所用參數(shù)的個數(shù)、屬性和次序是否正確；7. 是否存在與當前入口點無關(guān)的參數(shù)引用；&是否修改了只讀型參數(shù)；9. 對全程變量的定義各模塊是否一致；10. 是否把某些約束作為參數(shù)傳遞。如果模塊包括外部輸入輸出，還應該考慮下列因素：1. 文件屬性是否正確；2. OPEN/CLOSE語句是否正確；3. 格式說明與輸入輸出語句是否匹配；4. 緩沖區(qū)大小與記錄長度是否匹配；5. 文件使用前是否已經(jīng)打開；6. 是否處理了文件尾；7. 是否處理了輸入/輸出錯誤；&輸出信息中是否有文字性錯誤；檢查局部數(shù)據(jù)結(jié)構(gòu)是為了保證臨

11、時存儲在模塊的數(shù)據(jù)在程序執(zhí)行過程中完整、正確。局部數(shù) 據(jù)結(jié)構(gòu)往往是錯誤的根源，應仔細設(shè)計測試用例，力求發(fā)現(xiàn)下面幾類錯誤：1. 不合適或不相容的類型說明；2. 變量無初值；3. 變量初始化或缺省值有錯；4. 不正確的變量名（拼錯或不正確地截斷）；5. 出現(xiàn)上溢、下溢和地址異常。除了局部數(shù)據(jù)結(jié)構(gòu)外，如果可能，單元測試時還應該查清全局數(shù)據(jù)對模塊的影響。在模塊中應對每一條獨立執(zhí)行路徑進行測試，單元測試的基本任務(wù)是保證模塊中每條語句至少 執(zhí)行一次。此時設(shè)計測試用例是為了發(fā)現(xiàn)因錯誤計算、不正確的比較和不適當?shù)目刂屏髟斐傻?錯誤。此時基本路徑測試和循環(huán)測試是最常用且最有效的測試技術(shù)。計算中常見的錯誤包括：1

12、誤解或用錯了算符優(yōu)先級；2. 混合類型運算；3. 變量初值錯；4. 精度不夠；5. 表達式符號錯。比較判斷與控制流常常緊密相關(guān)，測試用例還應致力于發(fā)現(xiàn)下列錯誤：1. 不同數(shù)據(jù)類型的對象之間進行比較；2. 錯誤地使用邏輯運算符或優(yōu)先級；3. 因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等；4. 比較運算或變量出錯；5. 循環(huán)終止條件或不可能出現(xiàn)；6. 迭代發(fā)散時不能退出；7. 錯誤地修改了循環(huán)變量。一個好的設(shè)計應能預見各種出錯條件，并預設(shè)各種出錯處理通路，出錯處理通路同樣需要認真 測試，測試應著重檢查下列問題：1. 輸出的出錯信息難以理解；2. 記錄的錯誤與實際遇到的錯誤不相符；

13、3. 在程序自定義的出錯處理段運行之前，系統(tǒng)已介入；4. 異常處理不當；5. 錯誤述中未能提供足夠的定位出錯信息。邊界條件測試是單元測試中最后，也是最重要的一項任務(wù)。眾所周知，軟件經(jīng)常在邊界上 失效，采用邊界值分析技術(shù)，針對邊界值及其左、右設(shè)計測試用例，很有可能發(fā)現(xiàn)新的錯誤。 2.2.2單元測試過程一般認為單元測試應緊接在編碼之后，當源程序編制完成并通過復審和編譯檢查，便可開 始單元測試。測試用例的設(shè)計應與復審工作相結(jié)合，根據(jù)設(shè)計信息選取測試數(shù)據(jù)，將增大發(fā)現(xiàn) 上述各類錯誤的可能性。在確定測試用例的同時，應給出期望結(jié)果。應為測試模塊開發(fā)一個驅(qū)動模塊（driver）和（或）若干個樁模塊（stub）

14、，下圖顯示了一 般單元測試的環(huán)境。驅(qū)動模塊在大多數(shù)場合稱為“主程序”，它接收測試數(shù)據(jù)并將這些數(shù)據(jù)傳 遞到被測試模塊，被測試模塊被調(diào)用后，主程序”打印進入-退出”消息。驅(qū)動模塊和樁模塊是測試使用的軟件，而不是軟件產(chǎn)品的組成部分，但它需要一定的開發(fā) 費用。若驅(qū)動和樁模塊比較簡單，實際開銷相對低些。遺憾的是，僅用簡單的驅(qū)動模塊和樁模 塊不能完成某些模塊的測試任務(wù)，這些模塊的單元測試只能采用下面討論的綜合測試方法。提高模塊的聚度可簡化單元測試，如果每個模塊只能完成一個，所需測試用例數(shù)目將顯著 減少，模塊中的錯誤也更容易發(fā)現(xiàn)。圖單元測試環(huán)境圖（2）2.3綜合測試的基本方法時常有這樣的情況發(fā)生，每個模塊都

15、能單獨工作，但這些模塊集成在一起之后卻不能正常 工作。主要原因是，模塊相互調(diào)用時接口會引入許多新問題。例如，數(shù)據(jù)經(jīng)過接口可能丟失； 一個模塊對另一模塊可能造成不應有的影響；幾個子功能組合起來不能實現(xiàn)主功能；誤差不斷 積累達到不可接受的程度；全局數(shù)據(jù)結(jié)構(gòu)出現(xiàn)錯誤，等等。綜合測試是組裝軟件的系統(tǒng)測試技 術(shù)，按設(shè)計要求把通過單元測試的各個模塊組裝在一起之后，進行綜合測試以便發(fā)現(xiàn)與接口有 關(guān)的各種錯誤。某設(shè)計人員習慣于把所有模塊按設(shè)計要求一次全部組裝起來，然后進行整體測試，這稱為 非増量式集成。這種方法容易出現(xiàn)混亂。因為測試時可能發(fā)現(xiàn)一大堆錯誤，為每個錯誤定位和 糾正非常困難，并且在改正一個錯誤的同時

16、又可能引入新的錯誤，新舊錯誤混雜，更難斷定出 錯的原因和位置。與之相反的是增量式集成方法，程序一段一段地擴展，測試的圍一步一步地 增大，錯誤易于定位和糾正，界面的測試亦可做到完全徹底。下面討論兩種增量式集成方法。2. 3. 1自頂向下集成自頂向下集成是構(gòu)造程序結(jié)構(gòu)的一種增量式方式，它從主控模塊開始，按照軟件的控制層 次結(jié)構(gòu)，以深度優(yōu)先或廣度優(yōu)先的策略，逐步把各個模塊集成在一起。深度優(yōu)先策略首先是把 主控制路徑上的模塊集成在一起，至于選擇哪一條路徑作為主控制路徑，這多少帶有隨意性， 一般根據(jù)問題的特性確定。以圖（3）為例，若選擇了最左一條路徑，首先將模塊Ml, M2, M5 和M8集成在一起，再

17、將M6集成起來，然后考慮中間和右邊的路徑。廣度優(yōu)先策略則不然，它沿 著控制層次結(jié)構(gòu)水平地向下移動。仍然以下圖為例，它首先把M2、M3和M4與主控模塊集成在一 起，再將M5和M6和其他模塊集成起來。自頂向下綜合測試的具體步驟為：1. 以主控模塊作為測試驅(qū)動模塊，把對主控模塊進行單元測試時引入的所有樁模塊用實際模塊替代;2. 依據(jù)所選的集成策略（深度優(yōu)先或廣度優(yōu)先），每次只替代一個樁模塊；3. 每集成一個模塊立即測試一遍；4. 只有每組測試完成后，才著手替換下一個樁模塊；5. 為避免引入新錯誤，須不斷地進行回歸測試（即全部或部分地重復已做過的測試）。圖（3）從第二步開始，循環(huán)執(zhí)行上述步驟，直至整個

18、程序結(jié)構(gòu)構(gòu)造完畢。上圖（3）中，實線表示 已部分完成的結(jié)構(gòu)，若采用深度優(yōu)先策略，下一步將用模塊M7替換樁模塊S7,當然M7本身可能 又帶有樁模塊，隨后將被對應的實際模塊一一替代。自頂向下集成的優(yōu)點在于能盡早地對程序的主要控制和決策機制進行檢驗，因此較早地發(fā) 現(xiàn)錯誤。缺點是在測試較高層次模塊時，低層處理采用樁模塊替代，不能反映真實情況，重要 數(shù)據(jù)不能及時回送到上層模塊，因此測試并不充分。解決這個問題有幾種辦法，第一種是把某 些測試推遲到用真實模塊替代樁模塊之后進行，第二種是開發(fā)能模擬真實模塊的樁模塊；第三 種是自底向上集成模塊。第一種方法又回退為非增量式的集成方法，使錯誤難于定位和糾正， 并且失

19、去了在組裝模塊時進行一些特定測試的可能性；第二種方法無疑要大大增加開銷；第三 種方法比較切實可行，下面專門討論。2. 3.2自底向上集成自底向上測試是從“原子”模塊（即軟件結(jié)構(gòu)最低層的模塊）開始組裝測試，因測試到較 高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊。自底向上綜合測試的步驟分為：1. 把低層模塊組織成實現(xiàn)某個子功能的模塊群（cluster）；2. 開發(fā)一個測試驅(qū)動模塊，控制測試數(shù)據(jù)的輸入和測試結(jié)果的輸出；3. 對每個模塊群進行測試；4. 刪除測試使用的驅(qū)動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。 從第一步開始循環(huán)執(zhí)行上述各步驟，直至整個程序構(gòu)造完畢。圖

20、(4)說明了上述過程。首先“原子”模塊被分為三個模塊群，每個模塊群引入一個驅(qū)動模 塊進行測試。因模塊群1、模塊群2中的模塊均隸屬于模塊辰，因此在驅(qū)動模塊DI、D2去掉后， 模塊群1與模塊群2直接與血接口，這時可對血、D3被去掉后，H3與模塊群3直接接口，可對Mb 進行集成測試，最后曲、Mb和Me全部集成在一起進行測試。自底向上集成方法不用樁模塊，測試用例的設(shè)計亦相對簡單，但缺點是程序最后一個模塊 加入時才具有整體形象。它與自頂向綜合測試方法優(yōu)缺點正好相反。因此，在測試軟件系統(tǒng)時, 應根據(jù)軟件的特點和工程的進度，選用適當?shù)臏y試策略，有時混和使用兩種策略更為有效，上 層模塊用自頂向下的方法，下層模

21、塊用自底向上的方法。此外，在綜合測試中尤其要注意關(guān)鍵模塊，所謂關(guān)鍵模塊一般都具有下述一或多個待征: 對應幾條需求；具有高層控制功能；復雜、易出錯；有待殊的性能要求。關(guān)鍵模塊應 盡早測試，并反復進行回歸測試。模塊群1圖(4)2.4確認測試的基本方法通過綜合測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的最后一 步一一確認測試即可開始。確認測試應檢查軟件能否按合同要求進行工作，即是否滿足軟件需 求說明書中的確認標準。2.4. 1確認測試標準實現(xiàn)軟件確認要通過一系列黑盒測試。確認測試同樣需要制訂測試計劃和過程，測試計劃 應規(guī)定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，目

22、的在說明軟件與需否 一致。無論計劃還是過程，都應該著重考慮軟件是否滿足合同規(guī)定的所有功能和性能，文檔資 料是否完整、準確人機界面和其他方面（例如，可移植性、兼容性、錯誤恢復能力和可維護性 等）是否令用戶滿意。確認測試的結(jié)果有兩種可能，一種是功能和性能指標滿足軟件需求說明的要求，用戶可以 接受；另一種是軟件不滿足軟件需求說明的要求，用戶無法接受。項目進行到這個階段才發(fā)現(xiàn) 嚴重錯誤和偏差一般很難在預定的工期改正，因此必須與用戶協(xié)商，尋求一個妥善解決問題的 方法。2. 4.2配置復審確認測試的另一個重要環(huán)節(jié)是配置復審。復審的目的在于保證軟件配置齊全、分類有序， 并且包括軟件維護所必須的細節(jié)。2. 4

23、.3 a、B 測試事實上，軟件開發(fā)人員不可能完全預見用戶實際使用程序的情況。例如，用戶可能錯誤的 理解命令，或提供一些奇怪的數(shù)據(jù)組合，亦可能對設(shè)計者自認明了的輸出信息迷惑不解，等等。 因此，軟件是否滿足用戶要求，應由用戶進行一系列驗收測試”。驗收測試既可以是非正式 的測試，也可以有計劃、有系統(tǒng)的測試。有時，驗收測試長達數(shù)周甚至數(shù)月，不斷暴露錯誤， 導致開發(fā)延期。一個軟件產(chǎn)品，可能擁有眾多用戶，不可能由每個用戶驗收，此時多采用稱為 a、 0測試的過程，以期望發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的問題。a測試是指軟件開發(fā)組織部人員模擬各類用戶行對即將面市軟件產(chǎn)品（稱為a版本）進行 測試，試圖發(fā)現(xiàn)錯誤并

24、修正。a測試的關(guān)鍵在于盡可能逼真地模擬實際運行環(huán)境和用戶對軟件 產(chǎn)品的操作并盡最大努力涵蓋所有可能的用戶操作方式。經(jīng)過a測試調(diào)整的軟件產(chǎn)品稱為B版 本。緊隨其后的B測試是指軟件開發(fā)組織各方面的典型用戶在日常工作中實際使用B版本，并 要求用戶報告異常情況、提出批評意見。然后軟件開發(fā)公司再對B版本進行改錯和完善。 2.5系統(tǒng)測試的基本方法計算機軟件是基于計算機系統(tǒng)的一個重要組成部分，軟件開發(fā)完畢后應與系統(tǒng)中其它成分 集成在一起，此時需要進行一系列系統(tǒng)集成和確認測試。對這些測試的詳細討論已超出軟件工 程的圍，這些測試也不可能僅由軟件開發(fā)人員完成。在系統(tǒng)測試之前，軟件工程師應完成下列 工作：(1) 為

25、測試軟件系統(tǒng)的輸入信息設(shè)計出錯處理通路；(2) 設(shè)計測試用例，模擬錯誤數(shù)據(jù)和軟件界面可能發(fā)生的錯誤，記錄測試結(jié)果，為系統(tǒng)測 試提供經(jīng)驗和幫助；(3) 參與系統(tǒng)測試的規(guī)劃和設(shè)計，保證軟件測試的合理性。系統(tǒng)測試應該由若干個不同測試組成，目的是充分運行系統(tǒng)，驗證系統(tǒng)各部件是否都能夠正常 工作并完成所賦予的任務(wù)。下面簡單討論幾類系統(tǒng)測試。2. 5. 1恢復測試恢復測試主要檢查系統(tǒng)的容錯能力。當系統(tǒng)出錯時，能否在指定時間間隔修正錯誤并重新 啟動系統(tǒng)?；謴蜏y試首先要采用各種辦法強迫系統(tǒng)失敗，然后驗證系統(tǒng)是否能盡快恢復。對于 自動恢復需驗證重新初始化(reinitialization)、檢查點(checkp

26、ointing mechanisms),數(shù) 據(jù)恢復(data recovery)和重新啟動(restart)等機制的正確性；對于人工干預的恢復系統(tǒng)，還 需估測平均修復時間，確定其是否在可接受的圍。2. 5.2安全測試安全測試檢查系統(tǒng)對非法侵入的防能力。安全測試期間，測試人員假扮非法入侵者，采用 各種辦法試圖突破防線。2. 5.3強度測試強度測試檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力。強度測試總是迫使系統(tǒng)在異常的資源配置下運 行。2. 5.4性能測試對于那些實時和嵌入式系統(tǒng)，軟件部分即使?jié)M足功能要求，也未必能夠滿足性能要求，雖 然從單元測試起，每一個測試步驟都包含性能測試，但只有當系統(tǒng)真正集成之后，在真實

27、環(huán)境 中才能全面、可靠地測試運行性能系統(tǒng)性能測試是為了完成這一任務(wù)。性能測試有時與強度測 試相結(jié)合，經(jīng)常需要其他軟硬件的配套支持。3. 軟件測試的誤區(qū)隨著軟件規(guī)模的不斷擴大，軟件設(shè)計的復雜程度不斷提高，軟件開發(fā)中出現(xiàn)錯誤或缺陷的 機會越來越多。同時，市場對軟件質(zhì)量重要性的認識逐漸增強。所以，軟件測試在軟件項目實 施過程中的重要性日益突出。但是現(xiàn)實情況是與軟件編程比較，軟件測試的地位和作用，還沒 有真正受到重視，對于很多人(甚至是軟件項目組的技術(shù)人員)還存在對軟件測試的認識誤區(qū)， 這進一步影響了軟件測試活動的開展和真正提高軟件測試質(zhì)量。3.1誤區(qū)之一：軟件開發(fā)完成后進行軟件測試人們一般認為，軟件

28、項目要經(jīng)過以下幾個階段：需求分析，概要設(shè)計，詳細設(shè)計，軟件編 碼，軟件測試，軟件發(fā)布。因此，認為軟件測試只是軟件編碼后的一個過程。這是不了解軟件 測試周期的錯誤認識。軟件測試是一個系列過程活動，包括軟件測試需求分析，測試計劃設(shè)計，測試用例設(shè)計， 執(zhí)行測試。因此，軟件測試貫穿于軟件項目的整個生命過程。在軟件項目的每一個階段都要進 行不同目的和容的測試活動，以保證各個階段的正確性。軟件測試的對象不僅僅是軟件代碼， 還包括軟件需求文檔和設(shè)計文檔。軟件開發(fā)與軟件測試應該是交互進行的，例如，單元編碼需 要單元測試，模塊組合階段需要集成測試。如果等到軟件編碼結(jié)束后才進行測試，那么測試的 時間將會很短，測試

29、的覆蓋面將很不全面，測試的效果也將大打折扣。更嚴重的是如果此時發(fā) 現(xiàn)了軟件需求階段或概要設(shè)計階段的錯誤，如果要修復該類錯誤，將會耗費大量的時間和人力。 3.2誤區(qū)之二：軟件發(fā)布后如果發(fā)現(xiàn)質(zhì)量問題，那是軟件測試人員的錯這種認識容易打擊軟件測試人員的積極性。軟件中的錯誤可能來自軟件項目中的各個過程, 軟件測試只能確認軟件存在錯誤，不能保證軟件沒有錯誤，因為從根本上講，軟件測試不可能 發(fā)現(xiàn)全部的錯誤。從軟件開發(fā)的角度看，軟件的高質(zhì)量不是軟件測試人員測出來的，是靠軟件 生命周期的各個過程中設(shè)計出來的。出現(xiàn)軟件錯誤，不能簡單地歸結(jié)為某一個人的責任，有些 錯誤的產(chǎn)生可能不是技術(shù)原因，可能來自于混亂的項目管

30、理。應該分析軟件項目的各個過程， 從過程改進方面尋找產(chǎn)生錯誤的原因和改進的措施。3.3誤區(qū)之三：軟件測試要求不高，隨便找個人都行很多人都認為軟件測試就是安裝和運行程序，點點鼠標，按按鍵盤的工作。這是由于不了 解軟件測試的具體技術(shù)和方法造成的。隨之軟件工程學的發(fā)展和軟件項目管理經(jīng)驗的提高，軟 件測試已經(jīng)形成了一個獨立的技術(shù)學科，演變成一個具有巨大市場需求的行業(yè)。軟件測試技術(shù) 不斷更新和完善，新工具，新流程，新測試設(shè)計方法都在不斷更新，需要掌握和學習很多測試 知識。所以，具有編程經(jīng)驗的程序員不一定是一名優(yōu)秀的測試工程師。軟件測試包括測試技術(shù) 和管理兩個方面，完全掌握這兩個方面的容，需要很多測試實踐

31、經(jīng)驗和不斷學習精神。3.4 誤區(qū)之四：軟件測試是測試人員的事情，與程序員無關(guān)開發(fā)和測試是相輔相成的過程，需要軟件測試人員、程序員和系統(tǒng)分析師等保持密切的聯(lián) 系，需要更多的交流和協(xié)調(diào)，以便提高測試效率。另外，對于單元測試主要應該由程序員完成, 必要時測試人員可以幫助設(shè)計測試用例。對于測試中發(fā)現(xiàn)的軟件錯誤，很多需要程序員通過修 改編碼才能修復。程序員可以通過有目的的分析軟件錯誤的類型、數(shù)量，找出產(chǎn)生錯誤的位置 和原因，以便在今后的編程中避免同樣的錯誤，積累編程經(jīng)驗，提高編程能力.3.5誤區(qū)之五：項目進度吃緊時少做些測試，時間富裕時多做測試這是不重視軟件測試的表現(xiàn)，也是軟件項目過程管理混亂的表現(xiàn)，必

32、然會降低軟件測試的 質(zhì)量。一個軟件項目的順利實現(xiàn)需要有合理的項目進度計劃，其中包括合理的測試計劃，對項 目實施過程中的任何問題，都要有風險分析和相應的對策，不要因為開發(fā)進度的延期而簡單的 縮短測試時間、人力和資源。因為縮短測試時間帶來的測試不完整，對項目質(zhì)量的下降引起的 潛在風險，往往造成更大的浪費?？朔@種現(xiàn)象的最好辦法是加強軟件過程的計劃和控制，包 括軟件測試計劃、測試設(shè)計、測試執(zhí)行、測試度量和測試控制4. 軟件測試的流程圖隨著軟件規(guī)模的不斷擴大，軟件設(shè)計的復雜程度也不斷提高，軟件開發(fā)過程中出現(xiàn)錯誤或 缺陷的機會越來越多。因此，軟件測試在軟件項目實施過程中的重要性日益突出，而軟件測試 是一

33、種繁瑣的工作僅僅借助于人工測試是遠遠不夠的，還必須依靠軟件流程圖，才能更好的軟 件測試活動的開展和真正提高軟件測試質(zhì)量。測試工作總體流程圖需求階段測試工作流程需求工作培訓編寫需求 業(yè)務(wù)，用戶，功能總體測試計劃一需求規(guī)格說明書 系統(tǒng)測試方案需求變更記錄進入下一階段設(shè)計&編碼階段測試工作流程5. 軟件測試的實施和軟件測試報告5.1單元測試1單元是軟件系統(tǒng)的組成部分，它具有以下特點：1. 它是由程序員負責完成工作。2. 有一份詳細的說明書，它包括：輸入定義，輸出定義，數(shù)據(jù)庫定義，接口說明。3. 它是一個可識別的和可見的程序組成部分，并容易結(jié)合程序。4. 能單獨編譯、匯編、測試。5. 它是程序的必要部

34、分。2私有單元與公開單元從概念上可將單元分為私有單元與公開單元兩類。私有單元是非正式的、變化的、模糊的、 不完整的、混亂的、獨立的、不協(xié)調(diào)的。公開單元是正式的、固定的、具體的、完整的、條理 的、聯(lián)系的、協(xié)調(diào)的。單元是私有的即未經(jīng)過嚴格測試，尚未交付的使用單元。單元是公開的 即已經(jīng)嚴格測試及確認，可以與別的單元結(jié)合或調(diào)用的單元。單元測試的目的和效果是將私有 單元轉(zhuǎn)化公有單元，且使用最少的費用和最有效的方法完成從私有到公有的轉(zhuǎn)化。3）單元測試的目標單元測試的目標是證明程序有錯誤，而不是證明程序沒有錯誤。測試可以由程序員自己進 行，也可以由進行獨立測試，即由非程序員進行測試。但獨立測試對單元級測試會

35、有一定困難, 還要制定具體的目標和方法。如在目標制定時，還可分為主要目標，次要目標和輔助目標以及 程序員和他們的保證部門共同實施對單元的測試。主要目標：是否實現(xiàn)說明書的要求，文檔是否完整而有意義，測試計劃的遵守是否嚴格，錯 誤是否完全改正了。次要目標：設(shè)計風格是否保持統(tǒng)一。輔助目標：如錯誤類型統(tǒng)計，方法有效性，它們會為管理員提供信息。4）單元測試組織單元測試是程序或軟件測試的基層工作，因為單元是整個程序的基礎(chǔ)組成，其質(zhì)量直接影響程 序的更大成份甚至全局。在單元測試時應首先提供下列文檔并按步進行：1. 提供正式說明書。2. 制定單元測試計劃和文件。3. 先測試可測試代碼。4. 程序員先測試私有單

36、元再進行正式單元測試。5. 驗收和條件驗收（進度和質(zhì)量間的沖突）。單元測試后可進行程序元素測試，即對由單元組成的各種程序進行測試。5) 單元測試環(huán)境單元測試是在一定環(huán)境下進行的，這些環(huán)境可以是真實的也可以是模擬的。1. 真實環(huán)境。真實環(huán)境是單元程序?qū)嶋H使用的，這只有在極少數(shù)的環(huán)境情況下能提供，如單元 程序?qū)儆谝活惽度胄阅K。2. 模擬環(huán)境。模擬環(huán)境是單元測試常用的，模擬環(huán)境可以在程序開發(fā)的早期進行，并利用工具 對單元程序進行測試和排錯，工具本身也是一種模擬環(huán)境。但全部采用模擬方法對單元進行測 試，存在的缺點是某些真實的難以實現(xiàn)，從而失去真實性，可采用的方法進行回歸測試，從而 發(fā)現(xiàn)單元測試模擬方

37、法可能出現(xiàn)的不準確，甚至錯誤之處。6) 單元測試的方法1. 靜態(tài)測試。采用人工閱讀、分析、檢驗程序源代碼的方式，來發(fā)現(xiàn)程序的錯誤，它依據(jù)提供 單元測試對象的文檔，從功能和結(jié)構(gòu)兩方面來對程序進行檢查，并且著重于程序結(jié)構(gòu)的檢查。 在靜態(tài)文檔是重要的依據(jù)，但在檢查程序的同時也是對文檔實行檢查的過程，在繼續(xù)對程序的 檢查中又會發(fā)現(xiàn)文檔中存在的問題和不確切，甚至錯誤之處。2. 動態(tài)測試采用機器運行實例方式來發(fā)現(xiàn)程序的錯誤。它依據(jù)提供單元測試對象的文檔，從 功能和結(jié)構(gòu)兩方面來對程序進行檢查，并著重于程序功能檢查。還可盡量利用輔助測試工具， 進行語法檢查、報表生成、數(shù)據(jù)結(jié)構(gòu)、算確性等的檢查。通常采用靜態(tài)測試

38、和動態(tài)測試相互結(jié) 合、互相補充對單元測試是必要的，特別不要輕視靜態(tài)測試，它有利于提高人們的程序設(shè)計水 平和嚴謹?shù)墓ぷ鞯膽B(tài)度。3. 復審。復審是保證測試質(zhì)量的重要手段，由程序員參加的復審小組對文檔、測試過程和結(jié)果 應進行按計劃的檢查并驗證其正確性，因此應事先制定復審計劃，規(guī)定審查容和方式。復審的 方式和級別亦可以根據(jù)情況和需要有所區(qū)別5.2集成測試集成測試又稱整體測試或結(jié)合測試，是軟件測試的中的一個重要環(huán)節(jié)。1. 集成測試的任務(wù)集成測試是已完成程序元素級測試的條件下證實程序元素間的一致性。集成是指取出一組程序 元素，把它們集成為一個更大的自身無矛盾的元素。而整體測試就是要檢驗結(jié)合的過程中的錯 誤

39、，證實程序元素的一致性。整體測試不同于對一般元素的測試，是對正在結(jié)合元素測試，即 對結(jié)合過程的測試。2. 集成測試的條件集成測試前提是：(1) 全部被結(jié)合的子元素已經(jīng)過測試，子元素自身一致的和正確的。(2) 研究子元素間直接或間接的一致性。（3）測試和排錯交替進行，獲得一個互相一致的子元素結(jié)合。（4）對新元素進行測試。（5）重復上述過程，直到完成整個系統(tǒng)的測試和結(jié)合。3. 集成測試技巧集成測試將對結(jié)合元素間的調(diào)用關(guān)系、數(shù)據(jù)依賴和元素接口進行測試，它可以應用下述技術(shù)：（1）調(diào)用圖/樹的準備。包括每個元素和每個更低元素所做的各次調(diào)用，并且用圖型表示出 來，以便于了解元素間的調(diào)用關(guān)系。（2）數(shù)據(jù)依賴

40、圖的準備。全部數(shù)據(jù)分析是整體測試的一部分，它利用數(shù)據(jù)字典，確定數(shù)據(jù) 依賴關(guān)系。為了測試全程數(shù)據(jù)，可利用所謂數(shù)據(jù)依賴圖，它描繪出程序元素所引用各 種數(shù)據(jù)，并擴大到該元素的下層元素的影響數(shù)據(jù)，以說明程序元素與數(shù)據(jù)元素之間的 依從關(guān)系。（3）加工依賴圖。研究加工對數(shù)據(jù)對象的改變，加工依賴圖包括了各種加工對所有元素的 操作關(guān)系。（4）接口和接口標準。接口控制文檔記錄了元素之間的接口信息，它應遵守嚴格的接口標 準。接口標準規(guī)定：數(shù)據(jù)項的傳送方式、數(shù)據(jù)對象按類型的調(diào)用順序規(guī)定、元素格式 規(guī)定以及其它規(guī)定。4. 集成測試的容（1）程序元素中的數(shù)據(jù)項的相容性，它包括了數(shù)據(jù)項的表示圍的相容性、類型的相容性、 表

41、示方式的一致性、重要數(shù)據(jù)量的圍或個數(shù)的相容性、數(shù)據(jù)對象順序的正確性、傳遞 方法的正確性、參數(shù)使用合理性等。（2）對調(diào)用圖的使用中，應準確記錄相關(guān)信息，以檢驗對調(diào)用圖的路徑覆蓋情況。（3）在盡量避免設(shè)計多入口和多出口的程序元素的同時，應對此類元素進行認真測試，檢 查多入口元素的每個入口點，并驗證選取入口的正確和路徑覆蓋。多出口有時是有必 要的，但是也應在整體測試中對其進行測試。5. 集成測試策落集成測試可以采用如下：（1）自頂向下。自頂向下集成測試是從程序頂部開始，把頂部元素作為單元進行測試，它 所調(diào)用的子程序可設(shè)成虛元素，即一種簡單的替代元素，當測試完成后，再以真實元 素加入，并重新進行對加入

42、后的整個元素的測試；重復上述過程，直到全部測試完成 加入元素及其整體為止。（2）自底向上。自底向上的集成測試是從程序結(jié)構(gòu)的底層開始，把被集成的元素逐層進行 合并測試，直到頂層元素。（3）隨機測試。隨機測試是對系統(tǒng)進行整體測試的一種方法，但不是唯一的辦法，它是在 事先未做周密分析和計劃的條件下，運行和執(zhí)行某一類程序，或利用現(xiàn)成的隨手可得 的程序加載到系統(tǒng)并執(zhí)行，從而進行隨機測試，以求發(fā)現(xiàn)程序的某些錯誤，這種測試 是正式測試前的先導性測試，當發(fā)現(xiàn)某些錯誤并排除后再進行正式的測試。隨機測試 有利于確定整體程序的框架，如測試程序是否能完成輸入、存儲、控制和輸出的基本 功能。5.3系統(tǒng)測試系統(tǒng)測試是軟件

43、測試中的最后的、最完整的測試，它是在元素級測試和整體的基礎(chǔ)上進行 的，它是從全局來考慮軟件系統(tǒng)的功能和性能要求。（1）系統(tǒng)測試的任務(wù)。（2）完成系統(tǒng)的功能驗證。它由軟件人員和質(zhì)量保證人員共同研究進行。（3）完成系統(tǒng)的驗收測試。它由用戶或用戶代表在正式制定驗收測試計劃的情況下進行。（4）系統(tǒng)測試計劃。測試計劃的制定是執(zhí)行功能測試和驗收測試的基本保證，它們必須有正 式的測試文檔，沒有正式的文檔就不會有正式的測試。測試文檔應該是有規(guī)的且容豐富 的資料，一般包含三大部分：A部分：綜述部分，包括：詞匯集，各種說明書，測試設(shè)計標準和約定，測試運行次序、 方法、圖表等。B部分：測試數(shù)據(jù)庫和代碼部分，包括測試

44、數(shù)據(jù)庫文檔和交叉引用索引，測試數(shù)據(jù)庫生成 程序，驅(qū)動程序和裝配生成程序，測試配置說明書，測試硬件和軟件工具，驗證硬、軟件，支 持性工具等。測試計劃應自頂向下設(shè)計，并且文檔化。C部分：實際測試說明書，包括：測試結(jié)構(gòu)與圍組成，典型測試集組成，預測試的設(shè)計和記 錄，測試計劃和生產(chǎn)率。系統(tǒng)測試實施系統(tǒng)測試的實施一般按下述步驟進行：（1）功能測試。通過大量的精心的測試實例對系統(tǒng)的功能做全面系統(tǒng)的測試。（2）性能測試。用特定的測試實例驗證系統(tǒng)的性能要求。（3）背景測試。用實際負載代替無負我的情況的測試，即真實運行環(huán)境的測試。（4）配置測試。提供全部邏輯式物理設(shè)備，在指令的設(shè)備組合情況下，實現(xiàn)全部功能的測試

45、。（5）繁忙測試。系統(tǒng)全部資源處于高度繁忙情況下的一種“破壞”性測試，以驗證系統(tǒng)的可 靠性。（6）恢復測試。測試系統(tǒng)對故障恢復能力，測試故障后整體和控制的可恢復性。（7）安全性測試。測試系統(tǒng)對錯誤的操作或非法的用戶的惡意破壞的安全保證的可靠程度。 其中功能測試、性能測試和繁忙測試對于所有系統(tǒng)都是必要的，其它的測試同樣也是需要的， 但根據(jù)系統(tǒng)的不同要求，可能會更有側(cè)重。系統(tǒng)測試包括功能測試和驗收測試兩種測試，其中功能測試是一種按測試計劃和測試文檔嚴格 進行的過程，而驗收測試則是一種具有合同執(zhí)行和法律意義的活動。為順利進行系統(tǒng)測試通常 需要在測試文檔的指導下，先進行必要的測試，并在測試前組織測試人

46、和見證人班子，測試的 指揮人和見證人是測試的關(guān)鍵人員。軟件測試是軟件開發(fā)的重要組成環(huán)節(jié)，沒有測試就沒有合格和高質(zhì)量的軟件，而軟件測試 的投入，包括人員和資金投入是巨大的，而且具有很高的組織管理和技術(shù)難度，如何組織測試 人員隊伍和如何設(shè)計和積累測試實例等，但又是必須進行和完成的重要工作。5.4測試報告測試報告是測試階段工作的總結(jié)，測試報告的容主要包括：引言。介紹測試的目的、圍、測試角度和標準、測試結(jié)果概要。測試計劃和配置。包括系統(tǒng)配置、運行配置、測試標準和評價等。接口測試。描述對系統(tǒng)接口的測試和結(jié)果。功能測試。描述對系統(tǒng)各種功能的測試和結(jié)果。開發(fā)測試。包括正常數(shù)據(jù)和過載數(shù)據(jù)的測試，以及在錯誤數(shù)據(jù)

47、下的測試和結(jié)果。交付使用的準備。包括交付使用的軟件目錄，留待解決的問題，質(zhì)量的檢驗結(jié)果，對測試結(jié) 果進行歸納，給出系統(tǒng)可接受的程度。附錄。包括參考文獻、異常狀況小結(jié)、測試數(shù)據(jù)等。6. 班級管理系統(tǒng)的測試我們對軟件進行測試首先明白軟件要實現(xiàn)的功能，按照軟件測試文檔進行否則無法對軟件 進行測試。班級管理系統(tǒng)實現(xiàn)功能：1）學生信息管理，包括： 學生信息的錄入、修改、刪除。 學生信息的查詢：學號、。2）學生成績管理，包括： 學生成績的查詢、添加、修改、刪除。 計算班級每門課的最低分、最高分、平均分、每個學生的總分。 計算班級每門課的優(yōu)秀率和優(yōu)秀人數(shù)090）.良好率和良好人數(shù)075）.不及格率和不及格人

48、 數(shù)。3）課程管理，包括: 課程表的查詢 課程的添加、刪除、修改現(xiàn)以班級管理系統(tǒng)的成績評定為例進行測試。6.1應用程序測試界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設(shè)計良 好的界面能夠引導用戶自己完成相應的操作，起到向?qū)缘淖饔谩Ｍ瑫r界面如同人的面孔，具有 吸引用戶的直摟優(yōu)勢。設(shè)計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界 面設(shè)計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與諸東流。班級管理系 統(tǒng)的登錄界面和主界面就是很友好的界面，如下所示：迭擇身ifr介輔導員 廠學生登錄用戶名：|teacher登錄 |密碼：取消 |gf 級甘建

49、系統(tǒng) 2001-4-6 1654二L2J 兇趣用 Six 幫肋兇植宰編$5襠實2訶碗08超呂詢諜歪賣誼應箔評定建出系紡玄第班級管理依息系.紡 開發(fā)人員:晁戰(zhàn)中楊光明.蘇捷 炬權(quán)所有:5竹工住室曲導師:朱斕 2001-4-66.1.1易用性測試按鈕名稱易懂，用詞準確，放棄模楞兩可的字眼，要與同一界面上的其它按鈕易于區(qū)分，能成績is詢諜帀査閔退出系紙成績欄控制欄等級e心理學 r計篤機化基礎(chǔ)優(yōu)秀聶格r大學英語r c逶言程序設(shè)計良好廠人數(shù)廠平均分r高李數(shù)學r大學春文r眾高分不強格./?戲級件醉糸線 7001-4-6 16:47:14二LfiJ 兇鬆國用系綁9裙肋砂4N2001-4-6昱戍中、楊光明.勞

50、提 席稅所有:517工作室汨導裁師:宏卿望文知意。理想的情況是用戶不用查閱幫助就能知道該界面的功能并進行相關(guān)的正確操作。如班 級管理系統(tǒng)的模塊成績評定是一個非常易用如上所示：用戶輸入學號單擊統(tǒng)計”可以查詢自己 的各科成績和總分，當選種單選框科目”的一門課和在“等級”單選框可以計算優(yōu)秀人數(shù)和優(yōu) 秀率、平均分、最低分、最高分等。6. 1. 2規(guī)性測試通常界面設(shè)計都按Windows界面的規(guī)來設(shè)計，即包含菜單條、工具欄、工具箱、狀態(tài)欄、滾 動條、右鍵快捷菜單”的標準格式，可以說：界面遵循規(guī)化的程度越高，則易用性相應的就越好。 小型軟件一般不提供工具箱。班級管理系統(tǒng)主界面如上所示，僅提供菜單、命令工具箱

51、。6.1.3合理性測試屏幕對角線相交的位置是用戶直視的地方，正上方四分之一處為易吸引用戶注意力的位置， 在放置窗體時要注意利用這兩個位置。1）父窗體或主窗體的中心位置應該在對角線焦點附近，即采取屏幕居中。2）子窗體位置應該在主窗體的左上角或正中。3）多個子窗體彈出時應該依次向右下方偏移，以顯示出窗體標題為宜。4）重要的命令按鈕與使用較頻繁的按鈕放在界面上較注目的位置。5）與正在進行的操作無關(guān)的按鈕應加以屏蔽。6）對可能造成數(shù)據(jù)無法恢復的操作提供了確認信息，給用戶放棄選擇的機會。并且將按鈕的缺省 焦點置在取消”按鈕上。7）非法的輸入或操作有足夠的提示說明，例如，當用戶輸入學號在數(shù)據(jù)庫不存在時，則

52、系統(tǒng)有提 示。例如，當用戶查詢自己的各科成績時系統(tǒng)通過查詢數(shù)據(jù)庫有如下提示，同時用戶單擊確定請 輸入學號文本框清空：級骨孚糸線 ？0(M46 19:13:34二1兇養(yǎng)翻鎬成燼評定逞出采紜成績欄貶債祥徹信息話飆入學號，|454545控制欄高等如C語肓閏予設(shè)計計算機文化基礎(chǔ):欄優(yōu)莠及格艮好不及格e心理學 r計算機文化基砒大學奐語c悟肓程序設(shè)計廠人談廠平均分1廠杲低分2001-1-6參茫班切管理信息系紡開1人員:吳成中桶光明、濮版枚所有:5171作空8）對運行過程中出現(xiàn)問題而引起錯誤的地方要有提示，讓用戶明白錯誤出處，避免形成無限期的 等待。9）提示、警告、或錯誤說明清楚、明了、恰當。10）對于文本

53、框（TextBox） 般需要根據(jù)其對應的數(shù)據(jù)庫字段的類型以及長度來限制用戶允許輸 入的字符和長度，測試時注意了輸入框中的數(shù)值的最大數(shù)和最小數(shù)，以及默認值、空白值或空格 時的情況。M）對于單選組有且只有一個單選鈕可選；如果單選組無單選鈕可選，這種情況是否允許存在。12）復選框組允許多個復選框（包括全部可選）可選；如果復選框組無復選框可選，這種情況允 許存在；文本框及某些控件拒絕輸入和選擇時顯示區(qū)域變灰或按既定規(guī)約處理。13）系統(tǒng)的提示框樣式應統(tǒng)一，即使用標準的Windows提示框，其中包括標題、圖標、提示語和功 能按鈕。圖標使用要規(guī)，要根據(jù)提示信息的性質(zhì)選擇不同的圖標，而且除非嚴重的錯誤，一般不

54、 使用X”圖標，以免使用戶產(chǎn)生畏懼心理。14）窗體顯示后，缺省的焦點設(shè)在最合理的控件上，方便用戶操作。15）輸入型控件一般不允許只輸入空格或可存入輸入值兩端的空格。6. 1.4美觀與協(xié)調(diào)性 界面大小應該適合美學觀點，感覺協(xié)調(diào)舒適，能在有效的圍吸引用戶的注意力。1）長寬接近黃金點比例（寬高比為4:3）,切忌長寬比例失調(diào)。2）布局合理，不宜過于密集，也不能過于空曠，合理的利用空間。3）按鈕大小基本相近，忌用太長的名稱，免得占用過多的界面位置，與界面的大小和空間要協(xié)調(diào)。4）避免空曠的界面上放置很大的按鈕。5）放置完控件后界面沒有很大的空缺位置。6）字體的大小與界面的大小比例協(xié)調(diào)，通常使用的字體中宋體

55、9-12較為美觀，很少使用超過12號 的字體。建議使用宋體9號字。7）前景與背景色搭配合理協(xié)調(diào)，反差不太大，少用深色，如大紅、大綠等。常用色使用Windows 界面色調(diào)。8）如果使用其他顔色，主色要柔和，具有親和力與磁力，堅決杜絕刺目的顏色。班級管理系統(tǒng)的 載入界面.顏色采用了這一原則使用戶感覺樸素大方具有磁性。如下所示：6.2功能測試在測試前，首先要根據(jù)需求分析報告全面了解用戶需求并透徹理解。測試時要注意以 下幾點：A、測試時要分清主次，即先測試主要功能，后測試次要功能。要選找出系統(tǒng)的功能主干，讓數(shù) 據(jù)依次流經(jīng)功能主干，測試功能實現(xiàn)的是否正確。B、功能主干用正常正確后，我們還要考慮測試其異常處理功能。C、功能主干測試正確后，再進行分支功能的測試。E、要對程序的功能進行方便性測試，將不夠滿意的地方，都應當成系統(tǒng)缺陷向項目負責人或系 統(tǒng)開發(fā)者指出。F、檢查系統(tǒng)需求和設(shè)計說明書中要求的功能是否在系統(tǒng)中都被實現(xiàn)、性能是否達到指標。G、數(shù)據(jù)之間的邏輯關(guān)系是否正確。班級管理系統(tǒng)的功能測試是本系統(tǒng)的重點測試，對于班級管理系統(tǒng)的成績評定”可以完成計 算班級每門課的最低分、最高分、平均分、每個學生的總分。計算班級每門課的優(yōu)秀率和優(yōu)秀 人數(shù)090）.良好率和良好人數(shù)075）,不及格率和不