系統測試

前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了5篇系統測試范文，相信會為您的寫作帶來幫助，發現更多的寫作思路和靈感。

系統測試范文第1篇

關鍵詞 軟件測試；軟件質量；模擬器

中圖分類號TN911 文獻標識碼A 文章編號 1674-6708（2013）95-0224-02

隨著信息技術與信息產業的發展，計算機軟件廣泛地滲入到了我們的工作和生活中，各種產品和設備與計算機軟件的聯系也越來越緊密。計算機軟件的質量優劣也日益受到人們的重視。軟件測試是保證軟件質量的重要手段。在軟件工程中，軟件測試是軟件生命周期中一項非常重要的工作，也是一項非常復雜的工作。

1 模擬器軟件的開發與測試

軟件是模擬器的重要組成部分，軟件的質量直接影響著模擬器的質量。軟件如果存在缺陷或故障，將會導致模擬器在使用過程中發生錯誤，對用戶產生各種影響。模擬器軟件的開發過程一般包括制定計劃、需求分析、軟件設計、軟件編碼、軟件測試、運行維護等6個階段。軟件測試是模擬器軟件開發過程中的一個階段，是保證模擬器軟件質量的重要方法和手段。軟件測試技術可分為靜態測試與動態測試。靜態測試是一種不通過執行程序而進行測試的技術，關鍵是檢查軟件的表示和描述是否一致，有無沖突或歧義。動態測試通過人工或使用工具運行程序進行檢查，分析程序的執行狀態和程序運行的表象。動態測試一般分為白盒法測試和黑盒法測試。白盒法測試對象是源程序，依據程序內部的邏輯結構來發現編程錯誤、結構錯誤和數據錯誤。黑盒法是把測試對象看成一個黑盒子，依據軟件的功能或軟件行為描述，發現軟件的接口、功能和結構錯誤。

模擬器的軟件測試是軟件開發過程中的一個階段，但不是一個完全獨立的階段，而是貫穿于軟件開發整個過程中的一個重要環節。模擬器軟件測試過程由單元測試、集成測試、系統測試和驗收測試等階段組成，整個測試過程與如圖1所示。其中，系統測試是整個軟件測試過程中非常重要的測試階段，是軟件的全部功能在實際運行環境中進行驗證和確認的測試，也是用戶進行驗收前的測試。

2模擬器軟件系統測試的目的和內容

模擬器軟件測試是一項非常復雜的工作，首先要按照詳細設計的要求對所有模塊的功能、性能、接口等進行單元測試，發現每個程序模塊內部可能存在的差錯，確保每個模塊單元工作正常。在單元測試的基礎上，將所有已通過單元測試的模塊按照概要設計的要求組裝成系統進行集成測試，發現與接口有關的各種錯誤，確保各單元模塊集成系統后能夠按設計要求協作運行，并確保增量行為的正確性。

模擬器軟件的系統測試，就是將已經過集成測試的模擬器軟件和其它支持軟件安裝在模擬器的專用計算機上，并與模擬器的硬件設備、人員等所有系統元素結合在一起，在實際的運行環境下，對模擬器軟件進行全面測試。通過對模擬器軟件的需求定義進行比較，找出軟件與需求定義不相符之處，通過對模擬器進行一系列嚴格測試來發現軟件中潛在的錯誤和缺陷，以確保模擬器交付給用戶后能夠正常使用。

模擬器軟件系統測試包含功能性測試和非功能性測試兩類測試內容。功能性測試的目的是測試軟件的主要功能與用戶的需求是否一致，主要進行訓練環境設置功能測試、訓練功能測試、訓練評估功能測試。非功能性測試主要測試軟件的性能、可靠性、健壯性是否滿足設計要求，主要進行性能測試、可靠性測試、易用性測試。模擬器軟件的系統測試主要采用黑盒測試技術中的因果圖、決策表、錯誤推測等測試方法。

3 模擬器軟件的功能性測試

功能測試不考慮模擬器軟件的內部結構和處理過程，通常在程序的界面處進行測試，測試軟件是否能夠按照需求的規定正常運行，是否能夠實現與需求一致的所有功能，發現軟件與需求定義不相符之處和潛在的錯誤與缺陷。模擬器軟件的功能性測試主要進行訓練環境設置功能測試、訓練功能測試和訓練評估程序功能測試。

3.1 訓練環境設置功能測試

在訓練開始前模擬器要進行訓練環境設置，訓練環境包括地理地形、氣象條件、各種設置、各類模型數據等。訓練環境設置的功能測試用例應當按照軟件需求進行設計，要考慮到不同訓練環境的各種組合情況，測試目的就是核實在不同的環境設置時數據載入是否正確、是否完整，是否完全符合設計要求。

3.2 訓練功能測試

模擬器的訓練功能就是在各種操作方式（正確或錯誤）條件下仿真裝備的真實反應（狀態和過程）。不同的操作方式就是按照不同的操作順序將模擬器不同設備面板的各種操作器件置于不同的位置狀態，所有操作器件不同順序的不同位置狀態可以產生數量很大的各種條件的輸入組合。仿真裝備的真實反應就是模擬器軟件的輸出，就是啟動不同的仿真過程、或改變仿真進程、或使模擬器顯示器件顯示不同內容與狀態、或導致三維場景的不同改變。對于模擬器軟件這種多條件組合輸入、產生多動作輸出的復雜功能測試使用因果圖（邏輯模型）方法設計測試用例比較合適。

采用因果圖方法設計模擬器軟件功能測試用例的步驟：首先確定模擬器軟件功能中的原因和結果，確定原因和結果之間的邏輯關系，根據這些關系畫出因果圖。確定因果圖中的各個約束。然后把因果圖轉換為決策表。根據決策表設計測試用例。

由于模擬器軟件的功能測試比較復雜，應當采用錯誤推測法作為輔助測試方法，依靠測試人員的經驗和直覺推測軟件功能可能存在的各種錯誤從而有針對性地設計測試用例。

根據測試用例進行訓練功能測試，檢查在各種操作方式條件下軟件的訓練仿真過程以及模擬器表象及狀態是否與設計要求完全一致、是否存在錯誤和潛在的缺陷。

3.3 訓練評估程序的功能測試

對訓練過程進行評估是模擬器的一個重要功能。訓練環境的設置數據和訓練過程中對模擬器的所有操作過程都按照時間先后以規定的數據格式完整地記錄在操作過程的文件中。訓練評估程序的功能就是將記錄的操作過程文件作為輸入數據，經過邏輯分析和數據計算，輸出此次訓練的成績和訓練過程的評語。由于訓練評估程序的輸入是整個訓練過程的全部操作，所有操作器件產生的操作順序組合將達到非常大的數目，實際中可能無法完成，在設計測試用例時采用等價類技術對操作過程的各種順序組合進行劃分，從劃分的每個區域內選取有代表性的操作過程作為測試用例。測試的目的就是檢查對不同的操作過程輸出的成績和評語是否正確，是否與專家評定結果一致。

4 模擬器軟件的非功能性測試

模擬器軟件的非功能性測試主要內容包括性能測試、可靠性測試、易用性測試。

4.1 性能測試

性能測試主要檢驗模擬器軟件是否達到需求規定的各類性能指標，并滿足一些性能相關的約束和限制條件。軟件運行的實時性是非常重要的性能指標。模擬器軟件的實時性測試主要包括操作響應時間的測試以及三維場景顯示的流暢與連續性測試。操作的響應時間應當與裝備的響應時間一致。場景的流暢要符合人們的視覺感受，如果三維場景繪制復雜、數據量大時會導致顯示幀頻下降，人眼就會感到畫面間斷、停頓，顯示幀頻是衡量流暢性的指標。三維場景的流暢性與場景中三維實體的數量、復雜程度、分辨率，以及三維場景特效（如煙霧）等有直接關系，應當以場景實體和特效達到或接近最苛刻的過程進行場景顯示的實時性測試。

4.2 可靠性測試

軟件的可靠性也叫做穩定性，是指在負載多變的情況下或長時間運行的情況下模擬器軟件運行的穩定程度。模擬器軟件的可靠性測試可以使用重復測試、并發測試、隨機變化以及長時間不間斷運行等方法。重復測試就是對某一器件進行重復操作，測試模擬器能否持續不斷地仿真設備的真實運行效果；并發測試就是同時對多個器件進行操作，測試模擬器能否產生與設備同樣的狀態；隨機變化就是不按照正常的操作順序，而是設計非常規的隨機操作順序或對重復和并發測試手段進行隨機組合，以獲得最佳的測試效果。按照設計要求讓模擬器軟件長時間不間斷地運行，測試軟件是否運行正常、功能是否出錯。

4.3 易用性測試

模擬器軟件的易用性主要是指訓練環境設置、成績評估等環節的界面易懂、選擇準確、操作方便。界面的設計要盡量符合人們的習慣和思維方式，按鈕名稱用詞準確、沒有歧義，同一界面的按鈕要易于區分，用戶能夠進行正確理解界面的功能并能夠進行正確操作。用戶能夠終止進程，重新返回、重新選擇。通過對界面的操作來測試模擬器軟件的易用性。

5 結論

系統測試是軟件交給用戶進行驗收測試的最后一道關口，對保證軟件的質量起著非常重要的作用。系統測試也是測試人員需要花大量的時間和精力才能完成的工作，雖然有些測試工作可以使用軟件測試工具來完成，但由于每一種測試工具都有其特定領域的應用，都有其自身的很多局限性，軟件測試工具本身不具備創造力，不能設計測試用例，不能處理意外事件，使用測試工具發現的缺陷也沒有手工測試發現的多。系統測試中的很多工作主要還是靠人完成的，測試人員的能力和素質最終決定了測試結果的好壞。根據系統測試結果和系統測試分析報告，在驗收測試前完善軟件功能、糾正軟件錯誤、消除軟件潛在的缺陷，提高軟件質量。

參考文獻

[1]趙斌.軟件測試技術經典教程 [M].2版.北京：科學出版社，2011.

[2]李海生，郭銳.軟件測試技術案例教程[M].北京：清華大學出版社，2012.

系統測試范文第2篇

【關鍵詞】系統測試；信息系統；監理；要點

中圖分類號：P208 文獻標識碼：A 文章編號：

前言

隨著我國信息化工程的加速推進，在項目的信息化過程中引入了第三方監理。其主要職能是對軟件信息系統進行監理工作。主要負責測試系統，達到項目驗收的目的，在監理測試信息系統的過程中，系統測試工作的規范化，標準化，科學化，有利于信息系統測試結果的準確性的提高。本文針對信息系統測試中監理的要點進行分析，指出了監理工作的重點及重要性。

二、信息系統測試的流程和關注點

1.信息系統項目測試的流程

從信息系統監理的角度，信息系統項目中測試的流程基本分兩步進行，第一步，承建單位進行的測試;第二步，項目小組(建設單位、監理單位、承建單位)進行的測試。

圖1 信息系統項目測試的流程

2.系統測試的關注點

(一) 信息系統的類型

信息系統，從項目建設的角度可以分為純開發系統和二次開發配置系統。純開發系統是指根據用戶需求，采用某種編程語言(如Java、JSP)和某種開發工具(如eclipse)，從零基礎開始編寫代碼實現的系統。二次開發配置系統是指在成品軟件(如Oracle DIM、Oracle BIEE、Oracle CRM、Oracle EBS、Oracle iLearning等)的基礎上，根據用戶需求，進行配置開發實現的系統。

(二)純開發系統

純開發系統的質量與開發人員的技術水平、開發風格、對系統需求目標的理解等因素有很密切的關系，導致純開發系統的測試工作任務繁重，其關注點也很多、很細。從監理的角度，假定系統基本包含用戶需求的所有功能點，純開發系統測試時的關注點，可以概括為：(1)系統界面布局的合理性、美觀性;(2)系統每個組件、控件的有效性、合理性;(3)系統流程邏輯的合理性;(4)具體功能的實現方式的最優性;(5)開發代碼的可閱讀性等。

(三)二次開發配置系統

二次開發配置系統的質量部分取決于所基于的軟件產品的質量。進行二次開發配置系統測試時的關注點，可以概括為：(1)系統組件、控件的有效性;(2)系統流程邏輯的合理性等。

與純開發系統的區別，主要體現在(1)系統界面的整體布局基于成品軟件產品，細節部分可以二次干預;(2)系統組件、控件的合理性也基于成品軟件產品，不建議二次干預(系統升級后，一切恢復為成品軟件原始狀態);(3)編寫開發代碼的工作量比純開發系統的工作量少。

系統測試中監理要點分析

1.信息系統測試中監理的工作

(一)審核承建單位的單元測試報告、集成測試報告、自測報告(總集成測試報告)及回歸測試報告；

(二)審核承建單位提交的系統測試計劃、系統測試方案(包含測試用例)；

(三)根據測試計劃和測試方案，制定系統測試記錄表，包括功能測試記錄表、性能測試記錄表、回歸測試記錄表，三方討論確認后執行；

(四)協助業主方、確定性能測試指標，三方簽字確認后執行；

(五)根據測試記錄表，出具測試結果分析報告(功能測試結果分析報告、性能測試結果分析報告、回歸測試結果分析報告)，其中，功能測試結果分析報告和性能測試結果分析報告作為回歸測試的依據；

(六)匯總測試結果分析報告，出具初驗系統測試報告。

2.平臺的系統測試

平臺經過需求調研分析、概要設計、詳細設計、二次開發配置、差異化分析及修正、自測等階段之后進入項目初驗階段，承建方提交初驗申請，批準后，業主方、監理方、承建方組成平臺初驗的系統測試小組對平臺進行系統測試，包括功能測試、性能測試及回歸測試。

(一) 功能測試階段

平臺的系統測試的功能測試部分的流程，可以概括為：

(1)監理方根據承建方提交的測試方案，制定《功能測試記錄表》包含需求分析說明書中的所有功能點和項目合同文件中的所有功能模塊；

(2)按照測試方案(含測試用例)，采用手動測試的方式，一邊測試一邊記錄測試情況；

(3)監理方對功能測試記錄表進行分析，形成《功能測試結果分析報告》，包含通過測試的功能點及模塊、未通過測試的功能點及模塊、計劃完成功能點及模塊數與實際完成功能點及模塊數的比較、存在的問題及建議；

(4)承建方根據功能測試結果分析報告，制定《回歸測試記錄》確定初驗階段回歸測試的內容及終驗時需跟進的內容，三方討論通過后執行。

(二)性能測試階段

平臺的系統測試的性能測試部分分別采用人工方式和工具測試兩種方式進行。該階段的流程，可以概括為：

(1)測試小組討論確定《性能測試指標》，包括對CPU利用率(＜=80％)、在CPU利用率允許范圍內的最大并發用戶數、吞吐量、疲勞強度(12小時)、響應時間、內存頁交換率等指標的要求規定；

(2)監理方根據承建方提交的測試方案，制定《性能測試記錄表》包含功能性、可靠性、易用性、效率、可維護性、可移植性六個方面；

(3)在功能測試完成時采用人工方式，進行以上六個方面的性能測試，填寫性能測試記錄表；

(4)監理方匯總性能測試記錄表，形成《性能測試結果報告》；

(5)根據性能測試指標，采用工具測試的方式，對平臺進行負載壓力測試，生成測試報表；

(6)承建方對測試報表進行分析，形成《性能測試分析報告》，提交監理方審核，審核通過后性能測試結束。

(三)回歸測試階段

平臺的系統測試的回歸測試主要是指對功能測試的回歸測試，該階段的流程，可以概括為：

(1)按照測試方案和《回歸測試記錄》中確定的內容對平臺進行回歸測試，并將結果記錄在回歸測試記錄中；

(2)監理方對回歸測試記錄結果進行分析，形成《回歸測試結果分析報告》，包括本次通過測試的內容、還需改進在終驗時跟進的內容、在用戶培訓時需重點跟蹤的內容、平臺上線后需進行深化的內容；

(3)將回歸測試結果分析報告和回歸測試記錄中約定的需在后期跟進的內容匯總整理形成《工程備忘錄》，作為對項目初驗的補充。

(四)系統測試報告

平臺的系統測試u引經歷功能測試、性能測試及回歸測試之后基本結束，監理方匯總整個測試過程中產生的文檔，形成《系統測試報告》及附件，附件包括《功能測試結果分析報告》、《性能測試指標》、《性能測試結果報告》、《性能測試分析報告》及測試報表、《回歸測試結果分析報告》、《工程備忘錄》。

四.系統試運行中監理的工作要點

系統試運行是為了檢查系統的穩定性、適用性等。一般情況下監理方在這個階段的主要工作有：

1.審核竣工文檔資料的完整性、可讀性及一致性；

2.審核軟件環境配置與設計方案的符合性；

3.檢測驗證系統功能性能與合同的符合性；

4.檢查人員培訓計劃落實情況；

5.出具階段性驗收報告；

6.幫助用戶制定系統運行管理規章制度；

7.在保修期內定期或不定期對項目進行質量檢查、督促承建方按合同要求進行維護。

本階段，軟件開發的工作告一段落，重點在于解決試運行工作中暴露出來的各種問題，和系統交付用戶前的各項準備工作。一般情況下， 目前業內第三方軟件功能、性能測試均在本階段進行。

五、結束語

信息系統監測監理工作是一份技術含量高，智力高等優質素質的工作，他是多種科學領域綜合交叉的產業，軟件工程監理是一門技術含量高，智力、知識密集型的產業，信息系統監測是多種科學技術領域的綜合交叉的產業，涉及到國民經濟的各個領域，因此，本文著重分析系統監測監理的工作要點，有助于監理們更清晰的把握工作職責，讓系統檢測工作得到有的放矢的開展。

參考文獻：

系統測試范文第3篇

關鍵詞：web測試；測試技術

在一個軟件項目開發中，系統測試是保證整體項目質量的重要一環，基于Web的系統測試與傳統的軟件測試既有相似之處，又有不同的地方，對軟件測試提出了新的挑戰。本文就筆者開發的工資查詢系統的測試技術及使用的相應的自動測試工具做一個簡要的介紹。

1網站功能測試

1.1．測試環境配置

本次測試使用了多臺計算機，已裝好Windows系統。選擇其中一臺作為服務器，將系統運行所需的軟件安裝完畢。

1.2．表單測試

用戶提交信息時需要使用表單操作，在此測試中利用兩臺計算機檢查各個模塊之間功能的實現，一臺為已安裝好子系統的服務器，另一臺為客戶機。首先測試教師用戶模塊，在客戶機上訪問服務器系統首頁執行用戶注冊、個人資料填寫，接著退出系統，然后用此注冊名、密碼登錄，登錄成功看到相應的工資明細及各項津貼。同樣用錯誤的注冊名、密碼登錄，系統顯示“用戶名或密碼錯誤”則返回到首頁，重新輸入用戶名和密碼進入。同樣對財務管理人員模塊測試，測試結果正常。

2系統聯合測試

  將系統集成為完整的網上工資查詢管理系統，通過聯合測試來檢驗系統的耦合性，以及功能上和性能上是否滿足設計目標。設計測試范例如下：

2.1．測試范例A

查看頁面鏈接是否有不可達現象。測試工具選擇Xenu Link Sleuth，這是個功能強大的檢查網站死鏈接的軟件，可以分別列出網站的活鏈接以及死鏈接，連轉向鏈接都分析得一清二楚；支持多線程，可以把檢查結果存儲成文本文件或網頁文件。啟動軟件在其File菜單下打開Check URL選項，在What address do you want to check?下拉菜單中填入測試URL：localhost:8080/myweb/index.jsp執行測試。測試結果如圖2-1所示。

 

圖2.1頁面鏈接測試

圖中Address表示鏈接地址，Status顯示鏈接狀態，如發現死鏈接將會以紅色字體顯示出來。在測試中發現了死鏈接，這是由于在編寫頁面時鏈接地址寫錯造成的，修改后頁面鏈接測試顯示正常。測試表明網上工資查詢系統不存在死鏈接問題，運行正常。

2.2．測試范例B

進行服務器的壓力并發測試，找出服務器能夠支持的最大客戶端數。測試內容為系統壓力負載測試，測試估算的依據是：假設在實際環境中，用戶只啟用一個服務器進行所有的業務處理。方法是：按照正常業務壓力估算值的1~10倍進行測試，考察服務器的運行情況。本次測試使用的工具是JMeter。JMeter是Apache組織的開放源代碼項目，用于模擬在服務器、網絡或者其他對象上附加高負載以測試他們提供服務的受壓能力、或者分析他們提供的服務在不同負載條件下的總性能情況，使用方法很簡單，啟動服務器，將JMeter下載解壓到目錄，運行bin中的jmeter.bat就可以使用。本次使用jakarta-jmeter-2.2版本。具體測試步驟如下：

（1）建立一個測試計劃（Test Plan），添加測試線程組：線程數為10；同時并發請求為3；循環次數為5。

（2）添加HTTP Request Defaults，設置參數Name：HTTP Request；server name or ip：127.0.0.1; port number：8080。

（3）添加HTTP Request，設置參數Name：HTTP Request；path：/myweb/index.jsp。

（4）添加Graph Results執行后結果如圖2.2：

圖2.2負載并發測試

說明：本測試使用線程數為10；同時并發請求為3；循環次數為5。平均響應時間（Average）為24ms；中位數（Median）即50%用戶的響應時間為16ms；吞吐量（Throughtput）默認為每秒完成的請求數502.52/minute。數據顯示本查詢系統符合測試要求。

3系統測試中遇到的問題及解決方法討論

3.1頁面亂碼問題

在JSP開發過程中，當數據從數據庫讀出返回到WEB瀏覽器中時，中文字符變成了亂碼，經過查找和分析，發現其原因是由于數據庫、Java和JSP文件之間的字符編碼差異造成的。當數據存取到數據庫時采用統一的ISO-8859-1字符集，而Java程序在處理字符時默認采用的也是ISO-8859-1字符集，所以在數據添加的時候Java和數據庫都是以ISO-8859-1方式處理的，這樣是不會有亂碼問題的。但是當從數據庫讀取數據時就會出現亂碼問題，因為讀出的數據是以ISO-8859-1字符集編碼的，而JSP文件頭中會加入這條語句，這說明頁面采用的是GB2312字符集顯示，這樣就和讀出的數據不一樣了。頁面顯示的就是從數據庫中讀出的字符亂碼，解決的方法就是轉碼，從ISO-8859-1轉成GB2312，就可以正常顯示了。這個問題可以通過編寫一個轉碼類來解決，代碼如下：

try{

系統測試范文第4篇

關鍵詞：構件化；軟件開發；過程；開發實例；系統測試技術；構件測試方法；問題

中圖分類號：TP311文獻標識碼：A文章編號：1007-9599 (2012) 03-0000-02

Component-based Software Development and System Testing TechnologyExploration

Ye Wei

(Ningbo Dahongying University,Ningbo315175,China)

Abstract:Along with the social demand for software continues to increase,as well as the difficulty and cost of software development increase,the technology of component-based software development and system testing is more extensive,component-based software development process to explore,while the use a development instance,the last component-based software system testing and component testing methods,

and come to the problems in the testing techniques.

Keywords:Component-based;Software development;Process;Development instance;System testing technology;Component test methods;Problem

近年來由于軟件系統困難度及復雜性不斷加大，以及不斷增加的軟件開發規模，同時軟件開發機構不僅對開發軟件的成本有了日益增高的要求，還對開發周期提出更多要求。當軟件開發面向對象分析以及設計方法以后，構件化的軟件開發形式已變為新發展趨勢。把外部開發的構件集成至實際具體應用中，進而面向固定應用的軟件系統得以合理構建，對軟件集成以及重用產生相當重要的影響，其已變為目前軟件研究領域的熱點以及主流技術。另外在構件應用前進行相關測試，也被實踐證明了其正確性。

一、構件化軟件開發過程分析

對于基于構件的開發，其指開發軟件系統的時候，把這個過程視為基于體系結構指導，合理運用構件組裝形式，進行軟件系統開發的一種軟件開發方法。下述的四個階段構成了構件化軟件開發過程。

第一個階段就是進行問題域分析與建模的階段。針對具體的問題情形，合理實施分析以及建模，與此同時，能夠利用合適的UML模型進行表示說明。

第二個階段就是求解域模型設計階段。針對問題域，合理實施分析建模，隨后得到求解域模型，就是系統需要的構件以及系統的體系結構。針對那些可以進行復用的構件，對其接口進行合理分析，然后確認是否應該進行擴展，要是增加一些新的構件，進行恰當的分析設計，進而保證構件可以達到求解域的需求。還要盡可能地保證構件有著可復用性。

第三個階段就是構件的開發及組裝階段。在構件庫內，進行可以達到需求構件的選用，并對其接口進行擴展，使之于目前工程相適應；針對新研發出來的軟件構件，可以把它儲存到構件庫內，保證日后的方便復制使用，還應把它運用到目前的工程里[1]。組裝完成后，完整的系統便得出，進行測試合格之后，就能夠運行。

最后階段就是應用系統的演化階段。針對構件的應用系統的演化，換句話說就是構件的替換、升級以及擴充的過程，按照具體的運行效果，同時根據用戶的實際要求，合理調整軟件，以保證期對新的環境的適應性。

二、開發實例分析

當進行某個系統開發的時候，積極采用構件復用技術，進而確保權限配置管理功能的實現。通過合理的分析，對于系統的權限管理，“用戶-角色-功能”方式得以確定，其為基于角色的訪問控制模式，對已有構件的復用可以確保此功能的合理實現。

角色管理以及用戶管理構件、角色節點配置構件、節點管理構件及用戶角色配置構件，這五個構件都存在于構件庫中，其中角色管理構件對系統制定的角色進行維護，與此同時就角色的名稱以及描述等信息進行合理管理；用戶管理構件則是對一個系統用戶信息進行管理的，主要由登陸名、登陸密碼構成的；對于角色節點配置構件，其重點應用在進行節點與角色之間對應關系的配置，保證一個角色能夠顯示幾個功能節點的制定，進而間接的對某個角色具有的功能進行合理限定；節點管理構件主要作用在管理系統功能樹上的節點中；用戶角色配置構件則用于用戶和角色對應關系的配置。以上五個構件不是單獨運行的，而是相互合作的，正是由于它們的互相合作才使系統中權限管理的相關功能得以實現。

三、構件化軟件系統測試技術研究

由于構件自身具有的特點，實施測試人員主要由構件的開發方以及構件的使用方來組成的，由于他們在測試中占據不同的立場，在實施測試的內容方面多少會存在一定的差異性：一是測試目的是不相同的，構件的開發方對構件的所有功能進行測試，構件使用方則更多的關心與其有關部分的功能。二是使用的環境存在差異性；三是具有的資源存在差異性，對于構件開發方，其對構件源代碼有著一定擁有權，但是對于構件的使用方，只具有構件的可執行代碼；于是，當對構件軟件進行實施測試時，要分別站在構件的開發方以及構件使用方等兩個角度上展開[2]。基于構件的使用方角度，測試方法是通過測試構件類型進而得出，具有兩種主要類型的構件：首先源代碼不確定，只給予使用方測試的信息當作所提供服務的COTS構件；另外一種是源代碼具有可訪問性的構件。當構件類型不同時，對測試方法的選用也是不同的。

（一）對構件測試方法的分析

目前，對構件的測試主要是通過以下幾個方法：

1.基于構件使用規范說明的測試。以下方法都與構件開發方有著一定聯系，本方法按照構件運用方就應用環境與規范給予的數據當作測試用例，只局限于黑盒測試中來使用。

2.內置測試。對于構件開發方，他們把有著可執行性的測試用例內置于構件內，同時當作構件的常用功能，在構件集成于實際應用環境的情況下，對其中測試用例進行運行，進而進行集成測試；

3.元數據。針對在集成測試的時候，構件信息缺乏等一些問題，構件開發方將關于構件的基本信息通過元數據這一合理形式，給予構件測試或者使用方，確保測試順利地實施，提升構件的可測試性是它的核心內容；

4.可測試體系結構。由構件開發方會提供與構件相配套的可測試體系，這樣構件使用方在實施測試的情況下，能對測試用例進行直接執行，和上述各個方法相比，不同的是，該測試信息通過規范的形式附加于構件之上，當運行的時候，沒有占用內存[3]。

5.證明策略。一般情況下，由于構件證明不同的承擔方，構件證明主要包括以下幾類：首先是構件使用方構件證明，其次是第三方構件證明，最后為構件開發方構件證明。

（二）構件測試技術中存在的一些主要問題

對于構件集成測試，很難對其實施，主要有兩方面的原因：異構性的存在以及相關信息的缺少。針對異構性，其表現為：同一個構件處于相同規范下，具有不相同的實現方法；不相同的構件能使用不同平臺的不同程序語言進行實現；由于構件使用方與開發方兩方很少進行交換信息，便導致了信息缺乏，構件開發方主要對開發構件的應用環境沒有足夠了解，所以，它進行的構件測試只可以面對假設的應用環境，但是實際環境和假設的環境之間一定具有差別，在實際的應用中，各個構件在動態交互過程中可能會出現數據交換不能有效兼容等問題。從另一方面，構件的源代碼因為相對構件運用方法有著某些未知性，于是，對其實施靜態分析是很難進行的。更別說對相關數據依賴以及控制依賴關系的獲得，進行有關測試用例的構造，進行測試，確認出進行測試需要的充分性準則是很難的。所以，在構件測試技術中，應該考慮以下幾個問題：

1.怎樣利用系統方法對測試驅動程序與插針進行構建。對于構件測試驅動程序，其一定是基于腳本的程序，同時僅僅對其黑盒功能進行執行。主要有基于場景以及規范的測試驅動程序；各個測試探針進行構件行為或者黑盒功能的合理模擬，在當前，還是主要通過基于操作腳本以及基于模型的方法。

2.怎樣合理構造出可重用的構件。就是開發系統方法以及工具安裝可重用的測試程序，進而進行各種測試資源的存儲及管理，主要有測試腳本、測試用例以及數據[4]。在當今，兩個方向較為突出，一個為于構件內部中進行構件測試的創建，內置測試就是實例；另外方向是使用可直接插拔技術進行一套測試程序的創建，不僅牽涉了測試訪問接口以及標準化測試信息格式，還牽涉到測試數據庫模式與定義以及開發新的可插拔技術支持構件單元測試。

3.怎樣正確進行可重用及通用的構件測試平臺的構建。在一般情況下，測試檢索以及執行、測試結果檢查以及報告組成了測試執行環境。此測試平臺可以根據不同語言及不同技術開發實現的構件是它的主要問題。

4.怎樣合理進行可測試構件的構建。其牽涉到三個問題，就是定義及設計可測構件的測試接口與公共結構、開發系統方法進行可測構件的構建、最小化系統資源及開銷。

四、總結

由于社會對軟件的需求一直增加，軟件復雜度及規模一直加大，因此，人們就不斷探索創新軟件開發技術，進而滿足軟件發展的需要。對于構件技術，其要經過創建及復用構件，還要通過組裝構件保證軟件系統開發的完成，能使系統的開發效率提高，系統的開發成本還減少，進而達到軟件復用的要求。于是，構件化的軟件開發方法能夠作為一種有效途徑，使軟件危機得以解決。與此同時，更要引起構件測試技術中的一些主要問題。

參考文獻：

[1]梅宏,楊芙清.構件化軟件設計與實現[M].北京:清華大學出版社,2008

[2]許幀．基于構件的軟件開發方法及實現[J].軟件導刊,2009,11:17-19

系統測試范文第5篇

關鍵詞：嵌入式測試；課程分析；教學方法

中圖分類號：TP3-4

信息技術和網絡技術的飛躍發展，我們已經進入后PC時代。而嵌入式系統可謂是后PC時代的代表，嵌入式技術以其靈活、高效和性價比高等諸多優勢，被廣泛應用于各項領域，從家庭的洗衣機、電冰箱、空調、小汽車，到辦公室里的遠程會議系統等，這些都屬于可以使用嵌入式技術進行開發和改造的產品。因為嵌入式系統經常應用于對可靠性和穩定性要求很高的領域，所以對于嵌入式系統的測試顯得尤為重要，因此嵌入式系統測試技術也是當前計算領域研究的熱點。

1 開設《嵌入式系統測試》課程的背景與意義

嵌入式系統作為現代科技高速發展的產物，滲透到我們生活的各方各面，發揮著重要作用。隨著我國嵌入式產品的快速發展，人們對于產品的性能要求越來越多，穩定性也要求越來越高。為滿足這些需求，越來越多的人意識到嵌入式系統測試的重要性，這也促使國內對于嵌入式系統測試人才的需求也越來越多，嵌入式系統測試也將成為我國現在乃至未來最炙手可熱的職業之一。同嵌入式系統測試的飛速發展相比較，我國高校在這方面的培養則相對落后，一方面部分計算機專業的學生畢業后找不到工作；而另一方面很多嵌入式企業或公司急需大量嵌入式系統測試人員來完成項目測試工作。歸根究底，導致這種現象的原因主要是高校的傳統教育無法滿足市場需求的快速變化。目前市場的發展趨勢是：越來越多的嵌入式設備的系統趨于復雜化，而系統測試將發揮起決定性的作用，所以當前業界非常缺乏的就是嵌入式方向的測試人才。

由此可見，我國各大高校爭相開設《嵌入式系統測試》這一門課程，主要目的就是要適應市場發展變化，教授當前最實用的測試技術，培養有實力和高競爭力的嵌入式測試人才，為學生今后的就業打下堅實的基礎，也為我國的嵌入式事業貢獻自己的一份力量。

2 課程特點分析

嵌入式系統測試對測試人員的要求較高，要求他們能夠熟練掌握軟硬件兩方面的知識，不僅要懂底層的硬件知識，而且對軟件知識也有較高的要求，包含了大量的專業性很強的理論和實踐技術，市場上需要的嵌入式測試人才必須具備高級語言編程經驗、嵌入式系統開發經驗等。綜合以上原因，筆者歸納了《嵌入式系統測試》課程的特點：

2.1 該課程涉及專業課程較多

《嵌入式系統測試》是一門綜合嵌入式軟件與硬件的課程。測試人員，僅有軟件方面的知識，而缺少對硬件方面的了解，則無法達到理想的測試效果。在很多時候即使發現了錯誤，也很難立即分清到底是軟件的錯誤還是硬件本身的錯誤；因此，各個高校在開設《嵌入式系統測試》課程前，都有一些相應的前驅課程來奠定一個良好的基礎，通常所需的前驅課程有：高級語言程序設計，嵌入式系統，單片機等。而該課程本身所涉及的內容包括：前半部分主要介紹嵌入式系統基礎知識、系統測試基礎原理、和硬件測試環境；后半部分課程主要介紹嵌入式系統測試流程；主流測試工具使用等。《嵌入式系統測試》是一門將多種軟、硬件方面的知識融合在一起的課程。

2.2 理論知識較為枯燥

課程大部分學習時間，要求學生掌握相當多的軟硬件理論知識和測試方法，例如：測試生命周期各階段的工作內容、工作方法學習和單元測試的實施等。這些都要求學生記大量枯燥且抽象的理論內容，因此學生學習積極性不高，認為測試課程內容理解困難，而且相當一部分學生學習后，只記得一些基本概念，期末考試前也只是背概念，去應付考試。即使學生在應聘時，招聘公司一問及測試的知識，學生只會說不知道或者不記得了。導致這些情況的產生，主要還是所學內容太過理論抽象，學生無法真正的將理論與實際相結合。

2.3 實驗條件要求較高

嵌入式測試學習過程中需要有較強的動手實踐能力。對于嵌入式系統而言，嵌入式軟件測試與硬件測試并沒有明顯的分界。嵌入式系統工作環境不同于一般軟件，嵌入式軟件的開發和測試通常處于跨平臺的交叉工作環境。在進行嵌入式軟件測試的時候，我們需要將軟件運行在目標機上。然后將目標機的輸入輸出重定位為主機的輸入輸出設備，即可借助主機的資源完成對目標機的操作，一旦具備這樣的條件，就可以將傳統的軟件測試方法應用于嵌入式軟件測試中。毫無疑問，要能夠順利完成該課程的測試實驗，對于實驗器材的要求都較高。

3 教學方法探討

在對課程特點分析的基礎上，結合筆者親身的教學經歷對該門課程的教學方法提出了一些自己的想法，將多種教學方法結合起來應用。

3.1 激發學生的學習主動性

我校開設《嵌入式系統測試》這門課程，是針對計算機科學與技術專業大四的學生。這些學生在面臨就業和畢業設計的雙重壓力下，對于大四的課程學習，往往顯得“力不從心”，無法集中精力好好學習。在教學初期應將學生感興趣的測試行業就業形勢介紹清楚，嵌入式測試領域的要求雖然相對較高，但付出與收獲是成正比的。在后期教學過程中，應堅持將所教授的理論知識，結合在實際企業中的應用，進行拓展介紹。這樣一來，學生不僅學到了知識本身，還了解到企業的運作流程，讓學生意識到所學內容不再遙遠。注意培養學生對嵌入式測試的興趣，激發學習積極性與主動性，堅定學好這門課程的信念。

3.2 使用對比教學法

嵌入式測試領域的很多知識并不是孤立存在的，而是與我們以前學過的很多知識有著密切關系，特別是和一般通用軟件的測試。在學習此類知識的時候，要介紹嵌入式系統測試和通用軟件測試的相同點，例如：測試流程等，加強這方面的學習；與此同時，將嵌入式測試中有別與通用軟件測試的知識點提煉出來并作重點介紹。學生在這樣的學習過程中，不但鞏固了之前所學的知識，而且還學習了嵌入式系統測試中所特有的新技術。通過這樣的對比學習，學生更容易接受新的知識，并加深了記憶。

3.3 使用項目教學法

該課程是一門實踐性很強的課程，只有理論聯系實踐，才能收到較好的學習效果。在實踐教學中，將一些和課程相關的小項目與教學過程緊密結合起來，達到理論與實踐的完美結合。如“嵌入式系統測試流程”部分，按照軟件測試流程進行組織，將全班同學分成若干組，每組5-6人，每個小組都有具體的工作任務布置和學習指導。在實現過程中，大家還可以通過角色扮演，清楚地知道自己應該要完成的工作。例如：扮演“測試經理”的學生，要給其余扮演“測試工程師”的學生，分配測試任務，并告知其何時測等等。通過這樣的角色扮演，不僅提高了學生實踐的興趣，更讓他們體會到測試的各種過程，最終完成。采用這種方法，使得學生在動手動腦的過程中，也學習到了測試方面的知識，并獲得了滿足感與成就感，也就進一步激發了其學習嵌入式測試課程的興趣和信心。

4 結論

嵌入式系統是現代科技高速發展的產物，在我們生活中發揮重要作用，對嵌入式系統進行測試是保證其質量的一種重要手段。筆者從闡述開設《嵌入式系統測試》課程的背景與意義出發，對本門課程的特點進行分析，并對該課程的教學方法進行了一定探討，以適應新時期的發展需要。

參考文獻：

[1]潘鳳.《嵌入式系統開發》課程研究及教學方法探討[J].辦公自動化.2009（22）.

[2]呂金和.嵌入式軟件測試[J].軟件導刊.2010（9）.

[3]張蘇，牛麗梁，穎紅.項目教學法在《軟件測試》課程中的實施[J].天津職業大學學報.2011（20）.

[4]蔡建平.嵌入式軟件測試實用技術[M].北京：清華大學出版社，2010.