1、軟件測試畢業設計【精選文檔】阜陽師范學院本科畢業設計題目：班級管理系統的測試 學 號：姓 名:年 級：系 別： 專 業：完成日期： 指導老師： 班級管理系統的測試姓名： 學號： 指導教師： 摘要 在軟件生命周期的各個階段,都有可能會產生差錯。雖然在每個階段結束之前都有嚴格的復審,以期望能盡早的發現錯誤,但是經驗表明審查并不能發現所有差錯。如果在軟件投入生產性運行之前，沒有發現大部分錯誤，則這些錯誤遲早會在運行過程中暴露出來，甚至造成嚴重的后果,等到那時去改這些錯誤的代價會很高。測試的目的就是在軟件投入生產性運行之前,盡可能地發現軟件中的錯誤，測試是對軟件規格說明、設計和編碼的最后復審，所以軟件

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

3、自動的手段來運行或測定某個軟件系統的過程，其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別”。這個定義明確指出:軟件測試的目的是為了檢驗軟件系統是否滿足需求。從用戶的角度來看，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，所以軟件測試應該是“為了發現錯誤而執行程序的過程”。或者說，軟件測試應該根據軟件開發各階段的規格說明和程序的內部結構而精心設計一批測試用例（即輸入數據及其預期的輸出結果），并利用這些測試用例去運行程序，以發現程序錯誤或缺陷.1。2 軟件測試的目的、原則、基本要求1.2。1 測試的目的1。檢驗開發出來的軟件是否符合用戶的需求.2.盡可能多地發現程序中的錯誤

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

5、它視為錯誤.5。 程序模塊經測試后,殘存的錯誤數目一般與已發現的錯誤數目成正比例。也就是說,一個模塊中發現的錯誤越多，那么它可能殘存的錯誤數目也就越多，對這樣的程序模塊，一定要進行嚴格和更徹底的測試。6。 要保存測試用例.2. 軟件測試的方法 21 軟件測試的基本方法軟件測試的方法和技術是多種多樣的。對于軟件測試技術,可以從不同的角度加以分類:從是否需要執行被測軟件的角度，可分為靜態測試和動態測試。從測試是否針對系統的內部結構和具體實現算法的角度來看，可分為白盒測試和黑盒測試。2.1。1 黑盒測試 黑盒測試也稱功能測試或數據驅動測試,它是在已知產品所應具有的功能,通過測試來檢測每個功能是否都能

6、正常使用,在測試時，把程序看作一個不能打開的黑盒子,在完全不考慮程序內部結構和內部特性的情況下,測試者在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用,程序是否能適當地接收輸入數據而產生正確的輸出信息，并且保持外部信息（如數據庫或文件)的完整性.黑盒測試方法主要有等價類劃分、邊界值分析、因-果圖、錯誤推測等，主要用于軟件確認測試。 “黑盒” 法著眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試。“黑盒” 法是窮舉輸入測試,只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入

7、，而且還要對那些不合法但是可能的輸入進行測試。2.1.2 白盒測試白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用于軟件驗證。“白盒”法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。“白盒”法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手,得出測試數據。貫穿程序的獨立路徑數是天文數字.但即使每條路徑都測試了仍然可能有錯誤.第一，窮舉路徑測

8、試決不能查出程序違反了設計規范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了一些與數據相關的錯誤.2。1。3 ALAC(Actlikea-customer)測試軟件有好多錯誤圖ALAC測試客戶通常會遇到錯誤只占很小比例改進測試的有效性，使測試針對哪些客戶最容易遇到的錯誤圖（1）ALAC測試是一種基于客戶使用產品的知識開發出來的測試方法。ALAC測試是基于復雜的軟件產品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對哪些客戶最容易遇到的錯誤。 2.2 單元測試的基本方法單元測試的對象是軟件設計的最小單位-模塊。單元測試的依

9、據是詳細設計描述，單元測試應對模塊內所有重要的控制路徑設計測試用例,以便發現模塊內部的錯誤。單元測試多采用白盒測試技術，系統內多個模塊可以并行地進行測試。 2。2.1 單元測試任務單元測試任務包括：1 模塊接口測試；2 模塊局部數據結構測試;3 模塊邊界條件測試;4 模塊中所有獨立執行通路測試；5 模塊的各條錯誤處理通路測試。模塊接口測試是單元測試的基礎.只有在數據能正確流入、流出模塊的前提下，其他測試才有意義。測試接口正確與否應該考慮下列因素：1. 輸入的實際參數與形式參數的個數是否相同和屬性是否匹配；2。 輸入的實際參數與形式參數的量綱是否一致;3. 調用其他模塊時所給實際參數的個數是否與

10、被調模塊的形參個數相同；4。 調用其他模塊時所給實際參數的屬性是否與被調模塊的形參的屬性是否匹配；5. 調用其他模塊時所給實際參數的量綱是否與被調模塊的形參量綱一致；6。 調用預定義函數時所用參數的個數、屬性和次序是否正確；7. 是否存在與當前入口點無關的參數引用;8. 是否修改了只讀型參數；9。 對全程變量的定義各模塊是否一致;10.是否把某些約束作為參數傳遞。如果模塊內包括外部輸入輸出，還應該考慮下列因素：1. 文件屬性是否正確；2。 OPEN/CLOSE語句是否正確；3. 格式說明與輸入輸出語句是否匹配;4。 緩沖區大小與記錄長度是否匹配；5。 文件使用前是否已經打開；6. 是否處理了文

11、件尾；7。 是否處理了輸入/輸出錯誤；8. 輸出信息中是否有文字性錯誤； 檢查局部數據結構是為了保證臨時存儲在模塊內的數據在程序執行過程中完整、正確。局部數據結構往往是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：1。 不合適或不相容的類型說明；2。 變量無初值；3。 變量初始化或缺省值有錯；4. 不正確的變量名（拼錯或不正確地截斷）； 5. 出現上溢、下溢和地址異常。除了局部數據結構外,如果可能，單元測試時還應該查清全局數據對模塊的影響.在模塊中應對每一條獨立執行路徑進行測試,單元測試的基本任務是保證模塊中每條語句至少執行一次。此時設計測試用例是為了發現因錯誤計算、不正確的比較和不適

12、當的控制流造成的錯誤。此時基本路徑測試和循環測試是最常用且最有效的測試技術。計算中常見的錯誤包括：1. 誤解或用錯了算符優先級；2。 混合類型運算;3. 變量初值錯;4. 精度不夠；5。 表達式符號錯.比較判斷與控制流常常緊密相關，測試用例還應致力于發現下列錯誤: 1。 不同數據類型的對象之間進行比較；2. 錯誤地使用邏輯運算符或優先級;3. 因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等；4. 比較運算或變量出錯；5. 循環終止條件或不可能出現；6. 迭代發散時不能退出；7. 錯誤地修改了循環變量。 一個好的設計應能預見各種出錯條件，并預設各種出錯處理通路，出錯處理通路同樣需

13、要認真測試，測試應著重檢查下列問題:1。 輸出的出錯信息難以理解；2. 記錄的錯誤與實際遇到的錯誤不相符；3。 在程序自定義的出錯處理段運行之前，系統已介入；4。 異常處理不當；5. 錯誤陳述中未能提供足夠的定位出錯信息.邊界條件測試是單元測試中最后，也是最重要的一項任務。眾所周知，軟件經常在邊界上失效，采用邊界值分析技術,針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤.2.2。2 單元測試過程一般認為單元測試應緊接在編碼之后，當源程序編制完成并通過復審和編譯檢查,便可開始單元測試。測試用例的設計應與復審工作相結合,根據設計信息選取測試數據,將增大發現上述各類錯誤的可能性。在確定測試用

14、例的同時，應給出期望結果。應為測試模塊開發一個驅動模塊（driver）和（或）若干個樁模塊（stub）,下圖顯示了一般單元測試的環境.驅動模塊在大多數場合稱為“主程序"，它接收測試數據并將這些數據傳遞到被測試模塊，被測試模塊被調用后，“主程序”打印“進入-退出”消息。驅動模塊和樁模塊是測試使用的軟件，而不是軟件產品的組成部分，但它需要一定的開發費用。若驅動和樁模塊比較簡單，實際開銷相對低些。遺憾的是，僅用簡單的驅動模塊和樁模塊不能完成某些模塊的測試任務，這些模塊的單元測試只能采用下面討論的綜合測試方法。提高模塊的內聚度可簡化單元測試，如果每個模塊只能完成一個,所需測試用例數目將顯著減

15、少，模塊中的錯誤也更容易發現。圖（2）2.3 綜合測試的基本方法時常有這樣的情況發生，每個模塊都能單獨工作，但這些模塊集成在一起之后卻不能正常工作。主要原因是，模塊相互調用時接口會引入許多新問題。例如,數據經過接口可能丟失；一個模塊對另一模塊可能造成不應有的影響;幾個子功能組合起來不能實現主功能；誤差不斷積累達到不可接受的程度；全局數據結構出現錯誤,等等。綜合測試是組裝軟件的系統測試技術,按設計要求把通過單元測試的各個模塊組裝在一起之后,進行綜合測試以便發現與接口有關的各種錯誤.某設計人員習慣于把所有模塊按設計要求一次全部組裝起來，然后進行整體測試,這稱為非增量式集成。這種方法容易出現混亂。因

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

17、選擇了最左一條路徑，首先將模塊M1,M2,M5和M8集成在一起，再將M6集成起來，然后考慮中間和右邊的路徑。廣度優先策略則不然，它沿著控制層次結構水平地向下移動.仍然以下圖為例,它首先把M2、M3和M4與主控模塊集成在一起，再將M5和M6 和其他模塊集成起來。自頂向下綜合測試的具體步驟為：1。 以主控模塊作為測試驅動模塊，把對主控模塊進行單元測試時引入的所有樁模塊用實際 模塊替代；2. 依據所選的集成策略(深度優先或廣度優先），每次只替代一個樁模塊； 3。 每集成一個模塊立即測試一遍;4。 只有每組測試完成后，才著手替換下一個樁模塊；5. 為避免引入新錯誤，須不斷地進行回歸測試（即全部或部分地

18、重復已做過的測試）。 圖（3）從第二步開始,循環執行上述步驟，直至整個程序結構構造完畢。上圖（3）中,實線表示已部分完成的結構，若采用深度優先策略，下一步將用模塊M7替換樁模塊S7，當然M7本身可能又帶有樁模塊，隨后將被對應的實際模塊一一替代。自頂向下集成的優點在于能盡早地對程序的主要控制和決策機制進行檢驗，因此較早地發現錯誤。缺點是在測試較高層次模塊時，低層處理采用樁模塊替代,不能反映真實情況，重要數據不能及時回送到上層模塊，因此測試并不充分。解決這個問題有幾種辦法，第一種是把某些測試推遲到用真實模塊替代樁模塊之后進行，第二種是開發能模擬真實模塊的樁模塊;第三種是自底向上集成模塊。第一種方法

19、又回退為非增量式的集成方法，使錯誤難于定位和糾正，并且失去了在組裝模塊時進行一些特定測試的可能性；第二種方法無疑要大大增加開銷；第三種方法比較切實可行，下面專門討論。2.3。2 自底向上集成自底向上測試是從“原子”模塊（即軟件結構最低層的模塊）開始組裝測試,因測試到較高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊。自底向上綜合測試的步驟分為： 1。 把低層模塊組織成實現某個子功能的模塊群（cluster）； 2。 開發一個測試驅動模塊，控制測試數據的輸入和測試結果的輸出； 3。 對每個模塊群進行測試;4. 刪除測試使用的驅動模塊，用較高層模塊把模塊群組織成為完成更大功能的新模塊群。

20、從第一步開始循環執行上述各步驟，直至整個程序構造完畢。圖（4)說明了上述過程.首先“原子”模塊被分為三個模塊群，每個模塊群引入一個驅動模塊進行測試。因模塊群1、模塊群2中的模塊均隸屬于模塊Ma，因此在驅動模塊D1、D2去掉后,模塊群1與模塊群2直接與Ma接口，這時可對Ma、D3被去掉后,M3與模塊群3直接接口，可對Mb進行集成測試,最后Ma、Mb和 Mc全部集成在一起進行測試。 自底向上集成方法不用樁模塊，測試用例的設計亦相對簡單，但缺點是程序最后一個模塊加入時才具有整體形象.它與自頂向綜合測試方法優缺點正好相反。因此，在測試軟件系統時,應根據軟件的特點和工程的進度，選用適當的測試策略，有時混

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

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

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

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

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

26、chanisms）、數據恢復（data recovery）和重新啟動 (restart)等機制的正確性；對于人工干預的恢復系統，還需估測平均修復時間，確定其是否在可接受的范圍內.2。5.2 安全測試安全測試檢查系統對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者,采用各種辦法試圖突破防線。2.5.3 強度測試強度測試檢查程序對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源配置下運行。 2。5。4 性能測試對于那些實時和嵌入式系統，軟件部分即使滿足功能要求,也未必能夠滿足性能要求,雖然從單元測試起,每一個測試步驟都包含性能測試，但只有當系統真正集成之后，在真實環境中才能全面、可靠

27、地測試運行性能系統性能測試是為了完成這一任務。性能測試有時與強度測試相結合，經常需要其他軟硬件的配套支持。3。 軟件測試的誤區 隨著軟件規模的不斷擴大，軟件設計的復雜程度不斷提高，軟件開發中出現錯誤或缺陷的機會越來越多。同時，市場對軟件質量重要性的認識逐漸增強.所以，軟件測試在軟件項目實施過程中的重要性日益突出。但是現實情況是與軟件編程比較,軟件測試的地位和作用,還沒有真正受到重視，對于很多人（甚至是軟件項目組的技術人員）還存在對軟件測試的認識誤區，這進一步影響了軟件測試活動的開展和真正提高軟件測試質量。3。1 誤區之一：軟件開發完成后進行軟件測試人們一般認為，軟件項目要經過以下幾個階段：需求

28、分析，概要設計,詳細設計，軟件編碼，軟件測試，軟件發布.因此，認為軟件測試只是軟件編碼后的一個過程。這是不了解軟件測試周期的錯誤認識。軟件測試是一個系列過程活動，包括軟件測試需求分析,測試計劃設計，測試用例設計,執行測試。因此,軟件測試貫穿于軟件項目的整個生命過程。在軟件項目的每一個階段都要進行不同目的和內容的測試活動，以保證各個階段的正確性。軟件測試的對象不僅僅是軟件代碼,還包括軟件需求文檔和設計文檔。軟件開發與軟件測試應該是交互進行的，例如,單元編碼需要單元測試,模塊組合階段需要集成測試.如果等到軟件編碼結束后才進行測試，那么測試的時間將會很短，測試的覆蓋面將很不全面，測試的效果也將大打折

29、扣。更嚴重的是如果此時發現了軟件需求階段或概要設計階段的錯誤,如果要修復該類錯誤，將會耗費大量的時間和人力。3。2 誤區之二：軟件發布后如果發現質量問題，那是軟件測試人員的錯這種認識容易打擊軟件測試人員的積極性。軟件中的錯誤可能來自軟件項目中的各個過程，軟件測試只能確認軟件存在錯誤，不能保證軟件沒有錯誤,因為從根本上講，軟件測試不可能發現全部的錯誤。從軟件開發的角度看，軟件的高質量不是軟件測試人員測出來的，是靠軟件生命周期的各個過程中設計出來的.出現軟件錯誤,不能簡單地歸結為某一個人的責任，有些錯誤的產生可能不是技術原因，可能來自于混亂的項目管理。應該分析軟件項目的各個過程，從過程改進方面尋找

30、產生錯誤的原因和改進的措施.3.3 誤區之三:軟件測試要求不高，隨便找個人都行很多人都認為軟件測試就是安裝和運行程序，點點鼠標，按按鍵盤的工作。這是由于不了解軟件測試的具體技術和方法造成的。隨之軟件工程學的發展和軟件項目管理經驗的提高，軟件測試已經形成了一個獨立的技術學科，演變成一個具有巨大市場需求的行業。軟件測試技術不斷更新和完善，新工具，新流程，新測試設計方法都在不斷更新，需要掌握和學習很多測試知識。所以，具有編程經驗的程序員不一定是一名優秀的測試工程師.軟件測試包括測試技術和管理兩個方面，完全掌握這兩個方面的內容，需要很多測試實踐經驗和不斷學習精神.3.4  誤區之四:軟件測試

31、是測試人員的事情，與程序員無關開發和測試是相輔相成的過程,需要軟件測試人員、程序員和系統分析師等保持密切的聯系，需要更多的交流和協調，以便提高測試效率。另外,對于單元測試主要應該由程序員完成，必要時測試人員可以幫助設計測試用例。對于測試中發現的軟件錯誤，很多需要程序員通過修改編碼才能修復。程序員可以通過有目的的分析軟件錯誤的類型、數量，找出產生錯誤的位置和原因，以便在今后的編程中避免同樣的錯誤，積累編程經驗，提高編程能力。3。5 誤區之五：項目進度吃緊時少做些測試，時間富裕時多做測試這是不重視軟件測試的表現，也是軟件項目過程管理混亂的表現，必然會降低軟件測試的質量。一個軟件項目的順利實現需要有

32、合理的項目進度計劃，其中包括合理的測試計劃，對項目實施過程中的任何問題,都要有風險分析和相應的對策，不要因為開發進度的延期而簡單的縮短測試時間、人力和資源。因為縮短測試時間帶來的測試不完整，對項目質量的下降引起的潛在風險，往往造成更大的浪費。克服這種現象的最好辦法是加強軟件過程的計劃和控制,包括軟件測試計劃、測試設計、測試執行、測試度量和測試控制.4. 軟件測試的流程圖 隨著軟件規模的不斷擴大,軟件設計的復雜程度也不斷提高，軟件開發過程中出現錯誤或缺陷的機會越來越多.因此，軟件測試在軟件項目實施過程中的重要性日益突出，而軟件測試是一種繁瑣的工作僅僅借助于人工測試是遠遠不夠的，還必須依靠軟件流程

33、圖，才能更好的軟件測試活動的開展和真正提高軟件測試質量。 設計&編碼階段測試工作流程上一階段需求相關文檔概要設計評 審詳細設計單元測試方案編 碼單元測試測試抽檢單元測試報告進入下一階段集成測試方案自動測試方案抽象出驗證標準以模塊為單位，不斷循環5. 軟件測試的實施和軟件測試報告 5。1單元測試1)單元是軟件系統的組成部分,它具有以下特點： 它是由程序員負責完成工作. 有一份詳細的說明書,它包括：輸入定義，輸出定義,數據庫定義，接口說明。 它是一個可識別的和可見的程序組成部分，并容易結合程序. 能單獨編譯、匯編、測試。 它是程序的必要部分.2)私有單元與公開單元從概念上可將單元分為私有單

34、元與公開單元兩類。私有單元是非正式的、變化的、模糊的、不完整的、混亂的、獨立的、不協調的.公開單元是正式的、固定的、具體的、完整的、條理的、聯系的、協調的。單元是私有的即未經過嚴格測試,尚未交付的使用單元。單元是公開的即已經嚴格測試及確認，可以與別的單元結合或調用的單元。單元測試的目的和效果是將私有單元轉化公有單元，且使用最少的費用和最有效的方法完成從私有到公有的轉化.3）單元測試的目標單元測試的目標是證明程序有錯誤，而不是證明程序沒有錯誤.測試可以由程序員自己進行，也可以由進行獨立測試，即由非程序員進行測試。但獨立測試對單元級測試會有一定困難，還要制定具體的目標和方法。如在目標制定時，還可分

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

36、程序元素測試，即對由單元組成的各種程序進行測試。5）單元測試環境單元測試是在一定環境下進行的,這些環境可以是真實的也可以是模擬的. 真實環境。真實環境是單元程序實際使用的，這只有在極少數的環境情況下能提供，如單元程序屬于一類嵌入性模塊。 模擬環境。模擬環境是單元測試常用的，模擬環境可以在程序開發的早期進行，并利用工具對單元程序進行測試和排錯，工具本身也是一種模擬環境。但全部采用模擬方法對單元進行測試，存在的缺點是某些真實的難以實現，從而失去真實性，可采用的方法進行回歸測試,從而發現單元測試模擬方法可能出現的不準確，甚至錯誤之處.6)單元測試的方法 靜態測試。采用人工閱讀、分析、檢驗程序源代碼的

37、方式，來發現程序的錯誤,它依據提供單元測試對象的文檔，從功能和結構兩方面來對程序進行檢查，并且著重于程序結構的檢查。在靜態文檔是重要的依據，但在檢查程序的同時也是對文檔實行檢查的過程，在繼續對程序的檢查中又會發現文檔中存在的問題和不確切，甚至錯誤之處。 動態測試 采用機器運行實例方式來發現程序的錯誤。它依據提供單元測試對象的文檔，從功能和結構兩方面來對程序進行檢查，并著重于程序功能檢查。還可盡量利用輔助測試工具，進行語法檢查、報表生成、數據結構、算法正確性等的檢查。通常采用靜態測試和動態測試相互結合、互相補充對單元測試是必要的，特別不要輕視靜態測試，它有利于提高人們的程序設計水平和嚴謹的工作的

38、態度. 復審。復審是保證測試質量的重要手段，由程序員參加的復審小組對文檔、測試過程和結果應進行按計劃的檢查并驗證其正確性，因此應事先制定復審計劃，規定審查內容和方式。復審的方式和級別亦可以根據情況和需要有所區別5。2 集成測試 集成測試又稱整體測試或結合測試，是軟件測試的中的一個重要環節。 集成測試的任務集成測試是已完成程序元素級測試的條件下證實程序元素間的一致性.集成是指取出一組程序元素，把它們集成為一個更大的自身無矛盾的元素。而整體測試就是要檢驗結合的過程中的錯誤,證實程序元素的一致性。整體測試不同于對一般元素的測試，是對正在結合元素測試，即對結合過程的測試。 集成測試的條件集成測試前提是

39、：(1) 全部被結合的子元素已經過測試，子元素自身一致的和正確的。 (2) 研究子元素間直接或間接的一致性。(3) 測試和排錯交替進行，獲得一個互相一致的子元素結合。(4) 對新元素進行測試。(5) 重復上述過程,直到完成整個系統的測試和結合。 集成測試技巧集成測試將對結合元素間的調用關系、數據依賴和元素接口進行測試，它可以應用下述技術：（1） 調用圖/樹的準備。包括每個元素和每個更低元素所做的各次調用，并且用圖型表示出來，以便于了解元素間的調用關系。（2） 數據依賴圖的準備.全部數據分析是整體測試的一部分，它利用數據字典,確定數據依賴關系。為了測試全程數據，可利用所謂數據依賴圖，它描繪出程序

40、元素所引用各種數據，并擴大到該元素的下層元素的影響數據，以說明程序元素與數據元素之間的依從關系。（3） 加工依賴圖。研究加工對數據對象的改變，加工依賴圖包括了各種加工對所有元素的操作關系。（4） 接口和接口標準。接口控制文檔記錄了元素之間的接口信息，它應遵守嚴格的接口標準。接口標準規定：數據項的傳送方式、數據對象按類型的調用順序規定、元素格式規定以及其它規定. 集成測試的內容（1） 程序元素中的數據項的相容性，它包括了數據項的表示范圍的相容性、類型的相容性、表示方式的一致性、重要數據量的范圍或個數的相容性、數據對象順序的正確性、傳遞方法的正確性、參數使用合理性等。（2） 對調用圖的使用中，應準

41、確記錄相關信息，以檢驗對調用圖的路徑覆蓋情況.（3） 在盡量避免設計多入口和多出口的程序元素的同時，應對此類元素進行認真測試，檢查多入口元素的每個入口點，并驗證選取入口的正確和路徑覆蓋.多出口有時是有必要的，但是也應在整體測試中對其進行測試。 集成測試策落集成測試可以采用如下：（1） 自頂向下。自頂向下集成測試是從程序頂部開始,把頂部元素作為單元進行測試,它所調用的子程序可設成虛元素，即一種簡單的替代元素,當測試完成后,再以真實元素加入，并重新進行對加入后的整個元素的測試；重復上述過程，直到全部測試完成加入元素及其整體為止。（2） 自底向上。自底向上的集成測試是從程序結構的底層開始，把被集成的

42、元素逐層進行合并測試,直到頂層元素.（3） 隨機測試。 隨機測試是對系統進行整體測試的一種方法，但不是唯一的辦法，它是在事先未做周密分析和計劃的條件下,運行和執行某一類程序,或利用現成的隨手可得的程序加載到系統并執行，從而進行隨機測試，以求發現程序的某些錯誤，這種測試是正式測試前的先導性測試，當發現某些錯誤并排除后再進行正式的測試。隨機測試有利于確定整體程序的框架,如測試程序是否能完成輸入、存儲、控制和輸出的基本功能。5。3 系統測試系統測試是軟件測試中的最后的、最完整的測試，它是在元素級測試和整體的基礎上進行的，它是從全局來考慮軟件系統的功能和性能要求。（1） 系統測試的任務。（2） 完成系

43、統的功能驗證。它由軟件人員和質量保證人員共同研究進行。（3） 完成系統的驗收測試。它由用戶或用戶代表在正式制定驗收測試計劃的情況下進行。（4） 系統測試計劃.測試計劃的制定是執行功能測試和驗收測試的基本保證，它們必須有正式的測試文檔,沒有正式的文檔就不會有正式的測試.測試文檔應該是有規范的且內容豐富的資料，一般包含三大部分：A 部分:綜述部分，包括：詞匯集,各種說明書，測試設計標準和約定，測試運行次序、方法、圖表等。B 部分：測試數據庫和代碼部分,包括測試數據庫文檔和交叉引用索引，測試數據庫生成程序，驅動程序和裝配生成程序,測試配置說明書,測試硬件和軟件工具，驗證硬、軟件，支持性工具等。測試計

44、劃應自頂向下設計，并且文檔化。 C 部分：實際測試說明書，包括:測試結構與范圍組成，典型測試集組成，預測試的設計和記錄，測試計劃和生產率。系統測試實施系統測試的實施一般按下述步驟進行：（1） 功能測試。通過大量的精心的測試實例對系統的功能做全面系統的測試。（2） 性能測試。用特定的測試實例驗證系統的性能要求.（3） 背景測試.用實際負載代替無負載的情況的測試,即真實運行環境的測試。（4） 配置測試。提供全部邏輯式物理設備，在指令的設備組合情況下,實現全部功能的測試。（5） 繁忙測試。系統全部資源處于高度繁忙情況下的一種“破壞”性測試，以驗證系統的可靠性。（6） 恢復測試。測試系統對故障恢復能力

45、，測試故障后整體和控制的可恢復性。（7） 安全性測試。測試系統對錯誤的操作或非法的用戶的惡意破壞的安全保證的可靠程度。其中功能測試、性能測試和繁忙測試對于所有系統都是必要的，其它的測試同樣也是需要的，但根據系統的不同要求，可能會更有側重。系統測試包括功能測試和驗收測試兩種測試，其中功能測試是一種按測試計劃和測試文檔嚴格進行的過程，而驗收測試則是一種具有合同執行和法律意義的活動.為順利進行系統測試通常需要在測試文檔的指導下,先進行必要的測試,并在測試前組織測試人和見證人班子，測試的指揮人和見證人是測試的關鍵人員。軟件測試是軟件開發的重要組成環節,沒有測試就沒有合格和高質量的軟件，而軟件測試的投入

46、,包括人員和資金投入是巨大的，而且具有很高的組織管理和技術難度,如何組織測試人員隊伍和如何設計和積累測試實例等，但又是必須進行和完成的重要工作。5。4 測試報告測試報告是測試階段工作的總結，測試報告的內容主要包括：·引言。 介紹測試的目的、范圍、測試角度和標準、測試結果概要.·測試計劃和配置。包括系統配置、運行配置、測試標準和評價等。·接口測試。描述對系統接口的測試和結果.·功能測試.描述對系統各種功能的測試和結果。·開發測試.包括正常數據和過載數據的測試，以及在錯誤數據下的測試和結果.·交付使用的準備。包括交付使用的軟件目錄,留待解

47、決的問題,質量的檢驗結果，對測試結果進行歸納,給出系統可接受的程度.·附錄.包括參考文獻、異常狀況小結、測試數據等。6。 班級管理系統的測試 我們對軟件進行測試首先明白軟件要實現的功能,按照軟件測試文檔進行否則無法對軟件進行測試。班級管理系統實現功能：1)學生信息管理，包括： 學生信息的錄入、修改、刪除. 學生信息的查詢：學號、姓名。2)學生成績管理，包括： 學生成績的查詢、添加、修改、刪除。 計算班級每門課的最低分、最高分、平均分、每個學生的總分。 計算班級每門課的優秀率和優秀人數（>90）、良好率和良好人數(75）、不及格率和不及格人數.3） 課程管理，包括： 課程表的查詢

48、 課程的添加、刪除、修改現以班級管理系統的成績評定為例進行測試。6。1 應用程序測試界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象.而且設計良好的界面能夠引導用戶自己完成相應的操作，起到向導性的作用。同時界面如同人的面孔,具有吸引用戶的直接優勢.設計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設計的失敗，讓用戶有挫敗感,再實用強大的功能都可能在用戶的畏懼與諸東流。班級管理系統的登錄界面和主界面就是很友好的界面，如下所示： 6.1.1 易用性測試按鈕名稱易懂，用詞準確，放棄模楞兩可的字眼,要與同一界面上的其它按鈕易于區分，能望文知意。理想的情況是用戶不用查

49、閱幫助就能知道該界面的功能并進行相關的正確操作.如班級管理系統的模塊成績評定是一個非常易用如上所示：用戶輸入學號單擊“統計”可以查詢自己的各科成績和總分，當選種單選框“科目”的一門課和在“等級”單選框可以計算優秀人數和優秀率、平均分、最低分、最高分等。6.1.2 規范性測試通常界面設計都按Windows界面的規范來設計，即包含“菜單條、工具欄、工具箱、狀態欄、滾動條、右鍵快捷菜單”的標準格式，可以說：界面遵循規范化的程度越高,則易用性相應的就越好。小型軟件一般不提供工具箱。班級管理系統主界面如上所示，僅提供菜單、命令工具箱。6.1。3 合理性測試屏幕對角線相交的位置是用戶直視的地方,正上方四分

50、之一處為易吸引用戶注意力的位置，在放置窗體時要注意利用這兩個位置.1)父窗體或主窗體的中心位置應該在對角線焦點附近,即采取屏幕居中.2）子窗體位置應該在主窗體的左上角或正中。3)多個子窗體彈出時應該依次向右下方偏移，以顯示出窗體標題為宜。4)重要的命令按鈕與使用較頻繁的按鈕放在界面上較注目的位置。5）與正在進行的操作無關的按鈕應加以屏蔽。6)對可能造成數據無法恢復的操作提供了確認信息,給用戶放棄選擇的機會。并且將按鈕的缺省焦點置在“取消”按鈕上。7)非法的輸入或操作有足夠的提示說明,例如,當用戶輸入學號在數據庫不存在時，則系統有提示。例如，當用戶查詢自己的各科成績時系統通過查詢數據庫有如下提示

51、,同時用戶單擊確定請輸入學號文本框清空：8）對運行過程中出現問題而引起錯誤的地方要有提示，讓用戶明白錯誤出處,避免形成無限期的等待。9）提示、警告、或錯誤說明清楚、明了、恰當。10）對于文本框（TextBox）一般需要根據其對應的數據庫字段的類型以及長度來限制用戶允許輸入的字符和長度，測試時注意了輸入框中的數值的最大數和最小數，以及默認值、空白值或空格時的情況。11)對于單選組內有且只有一個單選鈕可選；如果單選組內無單選鈕可選,這種情況是否允許存在.12）復選框組內允許多個復選框（包括全部可選)可選；如果復選框組內無復選框可選,這種情況允許存在；文本框及某些控件拒絕輸入和選擇時顯示區域變灰或按

52、既定規約處理.13）系統的提示框樣式應統一，即使用標準的Windows提示框,其中包括標題、圖標、提示語和功能按鈕。圖標使用要規范,要根據提示信息的性質選擇不同的圖標，而且除非嚴重的錯誤,一般不使用“X”圖標，以免使用戶產生畏懼心理.14)窗體顯示后,缺省的焦點設在最合理的控件上，方便用戶操作。15)輸入型控件一般不允許只輸入空格或可存入輸入值兩端的空格。6。1.4 美觀與協調性界面大小應該適合美學觀點，感覺協調舒適，能在有效的范圍內吸引用戶的注意力。1)長寬接近黃金點比例（寬高比為4:3），切忌長寬比例失調。2）布局合理,不宜過于密集，也不能過于空曠,合理的利用空間。3)按鈕大小基本相近，忌

53、用太長的名稱，免得占用過多的界面位置，與界面的大小和空間要協調.4）避免空曠的界面上放置很大的按鈕。5)放置完控件后界面沒有很大的空缺位置。6）字體的大小與界面的大小比例協調, 通常使用的字體中宋體9-12較為美觀,很少使用超過12號的字體.建議使用宋體9號字。7）前景與背景色搭配合理協調，反差不太大，少用深色，如大紅、大綠等。常用色使用Windows界面色調.8)如果使用其他顏色，主色要柔和，具有親和力與磁力，堅決杜絕刺目的顏色。班級管理系統的載入界面顏色采用了這一原則使用戶感覺樸素大方具有磁性。如下所示:6.2 功能測試在測試前,首先要根據需求分析報告全面了解用戶需求并透徹理解.測試時要注

54、意以下幾點：A、測試時要分清主次，即先測試主要功能，后測試次要功能。要選找出系統的功能主干，讓數據依次流經功能主干，測試功能實現的是否正確.B、功能主干用正常正確后，我們還要考慮測試其異常處理功能。C、功能主干測試正確后，再進行分支功能的測試。E、要對程序的功能進行方便性測試,將不夠滿意的地方，都應當成系統缺陷向項目負責人或系統開發者指出.F、檢查系統需求和設計說明書中要求的功能是否在系統中都被實現、性能是否達到指標。G、數據之間的邏輯關系是否正確。班級管理系統的功能測試是本系統的重點測試,對于班級管理系統的“成績評定"可以完成計算班級每門課的最低分、最高分、平均分、每個學生的總分。

55、計算班級每門課的優秀率和優秀人數（90)、良好率和良好人數(>75）、不及格率和不及格人數。當使用黑盒測試測試系統時，系統應完成上述功能,對于邊界值測試時系統也有一定的提示（測試用例學號為空）如下所示：當用戶選中科目和等級的單選框時，單擊確定查詢按扭能完成所要求的操作（測試用例學號為20024420、心理學這門課的良好率和良好人數和這門課的最高分、最低分）。當用戶選中該系統“科目”框架中的計算機文化基礎和“等級”框架中的、良好、人數、平均分時,單擊“查詢”時所完成的操作與實際期望一致。如下所示：同時完成對學生記錄的添加、修改、刪除；成績的修改、刪除等功能。現以班級管理系統學生的刪除為例進

56、行測試如下，當用戶單擊“是（Y）”則刪除當前記錄；單擊“否（N）”則取消刪除。6。3 環境測試配置測試環境是測試實施的一個重要階段，測試環境適合與否會嚴重影響測試結果的真實性和正確性.測試環境包括硬件環境和軟件環境.其中軟件環境指被測軟件運行時的操作系統、數據庫及其他應用軟件構成的環境。在實際測試中,軟件環境又可分為主測試環境和輔助測試環境。主測試環境是測試軟件功能、安全可靠性、性能、易用性等大多數指標的主要環境.一般來說，配置主測試環境可遵循下列原則：1.符合軟件運行的最低要求。測試環境首先要保證能支撐軟件正常運行。2。選用比較普及的操作系統和軟件平臺。本系統能在Win98、Win2000、2000Server、Windows XP系統下運行。3。營造相對簡單、獨立的測試環境.除了操作系統，測試機上只安裝軟件運行和測試必需的軟件，以避免不相關的軟件影響測試實施。4.無毒的環境。利用有效