前言：中文期刊網精心挑選了系統測試范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。
系統測試范文1
摘要:
介紹了一款針對航空器上電子設備進行監測的系統的設計與測試方法。該系統可以完成數據的采集與傳輸、錯誤曼徹斯特碼生成、消息監聽等功能，其采用可編程邏輯器件（FPGA），在詳細分析1553B總線協議的前提下，采用硬件編程語言VHDL，完成功能邏輯部分設計。最后通過現有的1553B總線通信網，搭建硬件測試平臺，完成總體的設計實現與功能測試。
關鍵詞：
1553B總線；信息監聽；可編程邏輯器件；系統測試
一、引言
隨著航空業的飛速發展，飛行器上出現了越來越多的功能各異的電子終端設備，這些終端設備絕大部分是由不同的設計者設計生產出來的，那么由不同設計者設計生產的終端是否可以在同一個航空總線系統中實現完美融合呢？擁有眾多終端的總線系統上所傳輸的消息是否可以完整記錄？當總線系統中出現錯誤的編碼類型時，對終端是影響如何？這是飛行器設計制造者需要妥善解決的問題，并且也是眾終端設計生產者迫切想要知道的問題[1]。本系統可以完成數據采集與傳輸，通過測試后，就解決了終端與總線的融合問題；此外，系統還可以生成若干錯誤類型的曼徹斯特編碼，可以對總線上終端面對錯誤編碼的反應進行測試；最后系統與計算機相結合可以完成總線網絡的全信息監聽，為飛行器設計與制造提供有效數據。
二、總體設計
根據對系統的功能設想，系統的組成大致分為如下幾部分，如圖1所示：時鐘管理部分為中心邏輯器件提供時鐘信號；配置口主要實現對中心邏輯器件的配置；USB接口主要實現系統與計算機的連接；RT地址和功能選擇部分主要作用是選擇系統的功能和設置系統的終端號；A/D采集部分完成數據的采集，將模擬信號轉為數字信號；電源管理為系統各部分提供合適的電源；收發器和變壓器連通總線和中心邏輯器件；最后中心邏輯器件選擇FPGA。系統的數據流向主要有三條：其一，總線上數據經變壓器和收發器進入中心邏輯器件，經處理后通過USB接口傳至計算機，實現對總線的消息監聽；其二，模擬信號經A/D處理后存入中心邏輯器件，收到發送命令后，經收發器和變壓器發送至總線上；其三，收到發送錯誤碼命令后，中心器件直接發出錯誤碼，經收發和變壓器發送至總線，用以測試總線網絡中其余終端的反應[2]。
三、中心邏輯器件功能模塊設計
本設計選擇FPGA做為中心邏輯器件，中心邏輯器件功能模塊的設計及完成是系統實現的重點和難點，也是我們系統設計及實現最耗費時間的部分。FPGA中功能模塊大致有如下幾個：編碼器，主要是實現數據的曼徹斯特碼化，然后發至收發器；譯碼器，主要是實現從總線上得到的數據進行譯碼，分析出有效數據或命令；數據整合和緩存，主要是完成對數據的加標處理及緩存轉入計算機；協議處理模塊，主要是完成對命令字的解讀；數據采集模塊是可調整部分，可根據用戶要求靈活設計；錯誤數據發生模塊，主要是生成不同類型的錯誤編碼。具體劃分如圖2所示[2]。
四、仿真測試
系統的仿真測試平臺主要由北京神州飛航科技有限責任公司生產并銷售的AEC1553-31RT/S2型通信板卡和總線耦合器、耦合電阻搭建而成，通信板卡和總線耦合器、耦合電阻、計算機形成了一個小型的航空總線網絡，我們可以利用這個網絡，測試系統的總線監聽功能，測試現場圖如圖3所示；另外中心邏輯器件FPGA中的各功能模塊的測試主要利用QuartusII軟件內嵌的在線信號分析工具SignalTapII，該模塊可以讓使用者實時、在線觀測到相關模塊的工作運行情況，例如圖4所示；緩存模塊FIFO的主要信號測試數據表明：觸發信號為rdreq,檢測時鐘為讀時鐘，wrusedw有效說明存儲容量半滿，其值為80H時，給出讀時鐘和讀使能，在以后每一個時鐘讀出16位并行數據。最后，對于系統的錯誤碼發生功能，可以通過示波器直接觀察，確認其錯誤類型。根據以上測試方法，測試后系統達到設計要求。
五、結論
該系統設計功能多樣，隨著航空業的發展，其應用面也會越發廣泛，并且系統中有一部分可以根據用戶要求進行靈活設計，適應度高。但是本設計仍然存在一定的不足：其一，功能選擇，終端地址配置靠硬件實現，更改不靈活，該部分在未來可以結合配套軟件做出設計修整；其二，數據采集設計，因為沒有參考具體的用戶要求，暫時應用邏輯器件片內存儲，導致容量小，可以結合具體要求增添片外存儲器，擴大容量；第三，錯誤編碼以字為主，未能拓展至消息類型，尚有較大發展空間。隨著更大的需求和更廣的應用，系統的設計將會越來越完善，功能也將越來越強大。
參考文獻：
[1]張義，張紅旗．1553B數據總線用電纜阻抗的測試方法[J].光纖與電纜及其應用技術，2014，（3）.
[2]牛茜．基于FPGA的1553B總線監測系統設計[D]．太原：中北大學，2011．
[3]王誠，吳繼華，等．AlteraFPGA/CPLD設計（基礎篇）[M]．北京:人民郵電出版社，2005．
[4]夏宇聞.Verilog數字系統設計教程[第二版][M].北京:北京航空航天大學出版社，2008.
系統測試范文2
（一）測試輸入要素自身分析
在銀行管理系統中，系統功能輸入主要包括文本框、下拉框、選取、日期等。測試輸入要素自身分析如下：首先根據具體功能輸入判斷其合法性；然后確定輸入要素規則中取值的有效等價類個數，每個要素規則的1個有效等價類為1個輸入要素測試點；最后匯總所有輸入要素的有效等價類ni=1∑ftpi，記為FTP。
（二）單一功能輸入要素分析
單一功能輸入要素分析是從需求文檔出發，通過對每個單一功能可能涉及的規則進行輸入要素測試點計數，求得該功能點的輸入要素測試點數。首先按照需求文檔功能框架對每個單一功能涉及的輸入要素進行枚舉。接著根據業務規則的要求，從輸入要素的值域出發，分析可能的取值，確定其等價類。然后計算等價類組合總數，如果等價類取值之間有判定或者依賴關系，則輸入要素之間等價類數相乘，否則相加。最后將單一功能輸入要素所有等價類組合計數的測試點相加，匯總得到單一功能輸入要素測試點nj=1∑sftpj，記為SFTP。
（三）組合功能輸入要素分析
在銀行管理系統中，組合功能是多個單一功能業務流、數據流的組合，包含多個組合實例。首先結合輸入要素自身分析，得到組合功能中單一組合實例中的單一功能的輸入要素個數，根據輸入要素個數和組織級定義，計算出該功能相應的復雜度C，則該功能的輸入要素測試點為1×C。然后匯總該組合實例中所有單一功能的輸入要素測試點，得到組合功能中單一實例的輸入要素測試點計數。最后枚舉管理系統中所有可能的功能組合實例，所有功能組合實例輸入要素計數點之和即為組合功能輸入要素計數點nk=1∑mftpk，記為MFTP。
（四）測試勞動生產率
軟件測試生產率包括測試設計生產率和測試執行生產率。影響測試設計生產率的因素有：測試用例的可重用性、測試用例的復雜度、人員熟練度等。影響測試執行生產率的因素有：測試用例的復雜度、測試用例的可執行性、人員熟練度、測試所需的軟硬件環境的穩定性和可用性、測試數據的可用性、測試工具的復雜度、業務復雜度等。結合企業級和項目級勞動生產率，可以確定項目采用的測試勞動生產率TLC。通過以上分析，可以估算出基于輸入要素分析的測試點總數，即測試工作規模TS=FTP+SFTP+MFTP。根據測試工作量=測試工作規模/測試勞動生產率，可以計算出技術活動工作量TAW。
（五）非測試技術活動工作量
非測試技術活動指測試過程中的測試計劃撰寫、測試環境準備、測試管理與溝通、測試總結等活動。在定性與定量結合估算的模型中，需要考慮非技術活動風險因素，包括測試人員經驗、項目需求清晰度與穩定性、關聯系統接口復雜度、測試條件完備性、測試資產要求、測試質量要求、測試全面性等。結合風險模型：RNTAW=NRNTAW×（1+beta）。其中，RNTAW為考慮風險因素非技術活動工作量，NRNTAW為不考慮風險因素非技術活動工作量為，beta=人員經驗+需求清晰度與穩定性+關聯系統接口復雜度+測試條件完備性+，根據項目經驗，beta的取值約為-0.5～0.5。
二、結論
系統測試范文3
關鍵詞：系統測試；軟件開發；在線即時通信
中圖分類號：TP311 文獻標識碼：A 文章編號：1674-7712 （2012） 18-0022-02
為了開發的軟件滿足用戶需求，軟件設計開發人員運用了大量分析、設計和調試方法，在分析設計的每個部分結束前，對相應的分析設計結果進行嚴格的審查和評定。由于人為能力有一定的局限性，審查很難發現所有的錯誤和缺陷，而且在編碼調試階段會引出大量的錯誤，在所設計的軟件投入運行之后，這些缺陷和錯誤最終會暴露出來。而這可以通過系統測試來解決，系統測試就是在軟件投入運行之前，對軟件的需求分析階段、概要設計階段、詳細設計階段和編碼部分的最終審查，是保證軟件質量的關鍵步驟[1]。
一、系統測試的含義
系統測試是指為了發現軟件的錯誤而執行程序的過程。系統測試的最基本任務是盡可能多的、徹底的檢查出程序運行中的錯誤，提高軟件系統的可靠性，從而能檢驗出系統是否存在問題。在軟件開發的整個過程中，通常使用大量保證軟件質量的方法分析、設計和實現軟件，但仍然難免會出現一定的錯誤，從而導致軟件產品中隱藏一些錯誤和缺陷。尤其是對于規模較大、復雜性較高的軟件更會如此。在這些錯誤和缺陷中，有些是致命的，如果不排除掉，就可能會導致重大損失。基于這種情況迫使設計者必須認真計劃、徹底地進行系統測試[2]。
二、系統測試的原則
系統測試的原則是必須最大限度地模擬出被測試軟件的實際運行環境，以保證測試的可靠性[3]。
在進行有效無誤的系統軟件測試之前，系統測試工程師必須了解軟件系統測試的基本原則：
（1）查找錯誤的源泉。系統測試的最終目標在于查找軟件錯誤，而最嚴重的錯誤（用戶角度）就是完成的用戶需求分析模型是錯誤的。
（2）系統測試計劃要在需求分析模型完成時形成，詳細的系統測試過程要在軟件的任意代碼產生之前就進行計劃和設計。
（3）Pareto原則。Pareto原則意喻在系統測試中發現的錯誤有80%可能來源于程序模塊中的20%。
（4）系統測試應按照有“小規?！钡健按笠幠！钡姆绞竭M行。最初的測試要把焦點定位在單個程序模塊上，然后在逐漸向集成的模塊簇轉變，最后在整個系統中尋找錯誤。
（5）窮舉測試是無法實現的。選擇盡可能充分覆蓋程序邏輯關系的數據。
（6）系統測試的實現要由第三方來獨立完成。創建系統的軟件設計工程師不是構造軟件測試的最佳人選。
系統測試工作人員通常站在用戶的角度（第三方）來把握系統，并且在軟件開發的整個階段中時刻與用戶進行不間斷的交流和溝通，理解系統業務需求、理順業務關系，測試系統的可靠性、可用性、正確性、完整性和可維護性等。依據軟件開發各階段的規格說明和程序的內部結構認真設計各種測試用例，用這些精心設計的測試用例去執行程序進行系統測試，以發現程序的錯誤。軟件測試所追求的是通過各種不同的系統測試方法，發現軟件中錯誤，完善豐富的錯誤診斷信息，以便于改正錯誤，達到預錯誤的發生，減少軟件相應開發費用的目標[1]。
如果系統測試對軟件的審查不夠嚴格，引起了大量的錯誤，待到那時，不僅要付出很高的代價來改正這些錯誤，還會造成無法彌補的損失。系統測試在軟件整個生命周期中主要經歷兩個階段：通常在編寫出每一個模塊之后就對它做必要的測試，這稱為單元測試。編碼與單元測試屬于軟件開發生命周期中的同一階段。在結束這個階段之后，對整個軟件系統還要進行各種不同的綜合測試，這是軟件生命周期的另一階段，即測試階段[2]。
三、系統測試的方法
黑盒測試和白盒測試是系統測試的基本方法。這兩種方法主要是依靠一組精心挑選的測試用例為輸入執行程序，對程序的行為進行逐個檢驗，確定其是否與軟件預期的結果相符。因此，對系統進行實時性測試時，要借助相應的測試工具對應用程序的算法復雜度和操作系統的任務調度進行分析測試。從測試是否針對具體實現算法的角度和系統的內部結構來看，軟件測試可以分成黑盒測試和白盒測試。
（1）黑盒測試又稱為功能測試，它是通過測試輸入和輸出來檢測每個功能模塊是否都能正常使用。在測試過程中，把每個功能模塊程序看作是一個不能打開的黑盒子，在完全不考慮其程序內部結構和內部特性的情況下，在程序的輸入和輸出接口處進行測試，它僅僅檢查程序的每個模塊功能是否按照需求規格說明書的規定正常運行，以及程序是否能準確地接收輸入數據而輸出正確的結果信息。黑盒測試主要是從程序的外部結構出發，不考慮程序本身的內部邏輯結構，主要針對的是軟件界面和軟件基本功能進行測試。黑盒測試是站在用戶的角度，從輸入數據與輸出數據的對應關系出發進行測試的。這種測試方法的缺點是如果程序外部特性本身有問題或規格說明的規定有誤，用墨盒測試方法是檢測不出來的。
（2）白盒測試又稱為邏輯驅動測試或結構測試，它主要按照程序內部的結構來進行測試的，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程序中的每條通路是否都是按照預定要求進行正確工作的。這種方法是把被測試對象看作一個打開的盒子，測試工程師依據程序內部的邏輯相關信息，設計或選擇對應測試用例，對程序所有可能的邏輯路徑進行測試，通過在不同的測試點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致[4]。
四、系統測試舉例
這里以用戶自行開發的一款在線即時通信系統為測試用例進行系統測試，本系統實現的通信功能極其復雜，運用多個線程進行前臺和后臺的消息發送和接收。使用ServerSocket創建要連接的端口，線程連接socket打通前后臺的消息通道。在線即時通信系統登錄界面如圖1所示。
根據這一邏輯，在線用戶登陸成功后就將登陸ID保存在線程中，打開在線好友通信窗口時，也會將接收者的ID進行保存，這樣就能正確保證消息的發送者和接收者。消息的傳遞會通過前臺發送給連接后臺的線程，經后臺線程處理后，找到接收者，再將信息進行轉發，這樣就完成了好友間的在線即時通信。同時，在用戶登錄時，也會進行上線提示，將自己在線情況通知給所有在線用戶，又將所有在線用戶的狀態進行顯示。這樣就能正確的顯示在線用戶列表，也能準確的實現在線用戶間消息傳遞。
在線即時通信模塊功能測試過程和要求如下：
1.登錄模塊
（1）測試描述。用戶需正確輸入用戶名和密碼，才能正確登錄并跳轉到好友列表界面。系統默認用戶名為1-50之內的任意數字，密碼為123456。
（2）測試步驟。首先打開在線即時通信登錄界面，輸入用戶名和密碼；然后點擊登錄按鈕；最后確認是否能夠正常登錄。
（3）合格標準。輸入正確的用戶名和密碼后，能夠成功登錄，并跳轉到我的好友列表；或者用戶名和密碼不正確時會彈出相應的錯誤提示。
2.好友列表界面
（1）測試描述。登錄成功的用戶在好友列表會以彩色頭像顯示，后登錄的用戶會通知所有在線用戶更新好友列表。雙擊在線好友能正確打開通信對話框。
（2）測試步驟。首先由登錄用戶跳轉到好友列表，確認好友列表可以將自己的頭像設置成彩色在線狀態；然后再登錄一個用戶，確認能正確通知所有在線用戶進行好友在線更新，鼠標滑過在線用戶時，確認是否有不同顏色提示；最后雙擊在線好友頭像，能實時打開通信對話框。
（3）合格標準。登錄成功在好友列表顯示自己的頭像為彩色在線狀態，并獲取所有在線好友；后登錄的用戶會通知所有在線用戶更新自己的在線好友列表；鼠標滑到在線用戶名上時，用戶名由黑色變為紅色；鼠標滑過時，又會從紅色變為黑色；雙擊在線好友，能成功打開通信對話框，發送者和接收者均正確。
3.通信界面
（1）測試描述。在線好友間的消息能夠準確發送和接收，并正確顯示在通信界面上。
（2）測試步驟。首先互相打開在線好友的通信界面；然后在文本框中輸入通信內容，可以是任意字符，點擊發送按鈕；最后確認發送的消息是否能準確顯示在接收者的通信界面上。
（3）合格標準。輸入任意通信內容，點擊發送后，接收者的通信界面上即時顯示好友發送的消息，同時好友也能接收返回的信息，并正確顯示。
五、總結
將系統測試的基本方法用于軟件開發過程中，可以增加軟件的可靠性，使軟件在投入運行之后基本不出錯誤，或者錯誤很少。對實際開發的軟件系統按照測試步驟進行測試，滿足測試通過原則的軟件系統安裝到用戶現場能夠順利實施和運行，得到用戶認可。
參考文獻：
[1]馬瑞芳，王會燃.計算機軟件測試方法的研究[J].小型微型計算機系統，2009，12.
[2]張新華，何永前.軟件測試方法概述[J].科技視界，2012，2.
[3]郭遠東，黃榮瑛.基于模塊化設計的嵌入式軟件測試方法[J].單片機與嵌入式系統應用，2005，1.
系統測試范文4
介紹了鐵路區間信號系統測試評估平臺的研制背景，給出平臺的硬件分布式系統和軟件系統結構。簡要介紹了平臺軟件系統各個子系統的功能。闡述了平臺專用數據庫的設計過程。
【關鍵詞】
區間信號；數據庫設計
鐵路區間信號系統是安全性苛求系統。在區間安全性控制和防護設備的研制、生產、使用過程中，運用現代技術手段對設備的可靠性和安全性進行科學、高效、全面、按標準的檢測，以取代目前國內主要依靠專家經驗進行的手工測試和實際線路試運行的非完善的方法，是十分迫切和必需的。
1.區間信號系統測試平臺的結構
鐵路區間信號系統測試評估平臺（以下簡稱平臺）硬件采用分布式結構，如圖1所示。平臺由主控機、數據庫機和仿真機組成。被測系統通過網絡與平臺互聯。網絡通信采用TCP/IP協議。
平臺軟件系統結構框圖如圖2所示。其中：主控及測試案例自動生成子系統一方面向仿真子系統發送區間狀態的仿真設置命令，另一方面動態監控現場信號狀態等，實現測試案例的動態擴展和連續加載、測試結果的動態判定，并將測試結果存入數據。
傳輸信道仿真及區間現場仿真子系統為被測系統提供了一個模擬的傳輸仿真及現場環境。數據采集與處理子系統在被測系統與仿真信道之間進行數據處理及轉換。測試用基礎數據生成子系統通過讀取區間拓撲數據文件，生成區間測試用基礎數據。專用數據庫子系統負責存儲各種測試用基礎數據和測試結果。
2.平臺專用數據庫設計
平臺的數據庫不僅是一般意義上的數據庫應用，它還負責協調各個子系統之間的數據聯系。平臺數據的類型與結構在一定程度上反映了整個平臺的測試水平。基于對平臺數據以及平臺分布式結構的考慮，經過深入的比較，選擇SQL Server 作為平臺的數據庫開發工具。數據庫設計一般分為四步：需求分析、概念設計、邏輯設計和物理設計。應用數據庫設計理論，平臺專用數據庫設計的具體步驟如圖3所示。
2.1需求分析
平臺的數據按其對時效性的不同要求可以分為動態數據和靜態數據兩大類。動態數據是指具有嚴格時效性的數據，并且隨著時間推移而動態刷新；靜態數據則指相對穩定，不隨時間變化的數據。
2.1.1動態數據及其傳輸
測試結果信息。平臺的測試結果記錄是一種比較特殊的動態數據，包括經信道傳輸前后的實時電信號（數據）。它們是評價被測系統的重要依據，必須完整、正確地記錄。
動態數據傳輸首先必須滿足實時性要求，當不能及時傳送時，根據數據特性的不同，或丟棄，或重發。例如被測系統發送的數據如不能及時傳送，或數據有誤，則該數據必須丟棄。主控機發給仿真子系統的故障及干擾仿真命令、列車運行仿真命令，在網絡傳輸出現差錯的情況下，為了確保命令被正確執行，必須重發。
2.1.2靜態數據及其復制
生成和校驗正確后的靜態數據，在平臺對被測系統進行測試的過程中不再變化，具有相對的穩定性。同樣需要對靜態數據進行存儲、查詢、校驗和修改等操作。
區間現場拓撲數據。包括閉塞分區、發送端、接收端的位置和相互關系。這種描述有兩方面用途，一方面用于現場仿真的動態顯示，另一方面是作為測試用基礎數據生成的原始依據。靜態數據的復制是通過開放式數據庫互連（ODBC）機制實現的。
2.2概念設計
在數據庫設計中，筆者使用實體-聯系（ER）模型作為概念設計的工具，得到概念設計的E-R圖。E-R圖由實體、聯系和屬性3個基本成分組成。測試用基礎數據所處理的基本實體是城市軌道交通區間的信號設備：接收端、發送端、閉塞分區；設備之間的關系也就是最直接的實體間聯系。通過E-R圖，可以十分清楚地描述測試用基礎數據的結構。圖4為列車運行線路數據的E-R圖。
2.3物理設計
物理設計要根據具體的數據庫管理系統（DBMS）和相應的操作系統、計算機硬件所能支持的存儲結構、存取方法以及資源來進行設計。SQL Server 提供索引或表鍵機制來幫助SQL Server 優化對查詢的響應。在測試平臺上，對結果數據的查詢，是將記錄計數號與測試項目的組合作為索引。這是因為大多數的查詢都要直接或間接地將該兩項作為SQL語句中WHERE子句后的首列。
3.結語
建立在SQL Server上的平臺專用數據庫要兼顧通用數據庫的設計要求和區間測試平臺的特殊性。只有綜合考慮這兩方面的因素，才能使專用數據庫既高效又安全。當然，隨著平臺水平的不斷提高，專用數據庫的功能必將隨之擴展，日趨完善。
參考文獻：
[1]
吳芳美.鐵路安全軟件測試評估[M].北京：中國鐵道出版社，2001，23
[2]荊劍.基于計算機聯鎖安全軟件測試評估平臺的CL IEN T/ SERV ER 數據庫[學位論文][D].上海：上海鐵道大學電信系，1999：23
系統測試范文5
關鍵詞：多核嵌入式操作系統；時間性能；測試方法
中圖分類號：TP316.2 文獻標識碼：A 文章編號：1007-9416（2017）02-0184-04
在單核操作系統中，內核負責任務管理、資源管理、中斷管理、事件處理及通信管理等工作。在多核操作系統中，這些功能同樣具有，除此之外，還包括核間通信與同步、核間任務調度管理、資源共享及設備管理等部分。性能方面主要考慮任務切換時間、中斷響應時間、運算性能、信量延遲時間、內存讀寫性能等常規的嵌入式實時操作系統性能以外，針對多核還需要檢測核間同步時間，針對圖形的操作系統檢測圖形的運行性能，針對文件系統進行文件讀寫性能。以下是針對某國產多核嵌入式實時操作系統的測試方法。
1 功能測試
針對多核嵌入式實時操作系統以下幾方面的功能進行測試：
多核管理功能：操作系統能在系統初始化階段，完成引導可用的所有處理器核。支持處理器集合操作，對處理器核能夠進行啟停狀態查詢的功能進行測試，通過對已加載被測系統的目標機上電，在上電完成后監測所有處理器核的啟停狀態，驗證多核管理功能的正確性。
多核同步功能：提供自旋鎖、原子操作、內存屏障等機制實現多個處理器核間數據可重入的功能進行測試，通過運行測試程序，構建多個任務，對比使用和不使用自旋鎖的方式訪問共享的臨界資源，監測這些任務對臨界資源訪問的正確性（符合數據的可重入），驗證多核同步功能的正確性；通過在使用內存屏障的情況下，多任務并發訪問同一全局變量，通過對比編譯之后的匯編代碼及運行結果，驗證多核環境下內存屏障能夠保證數據運算順序的正確性；通過運行測試程序，對啟用原子操作和不啟用原子操作時程序運行結果進行對比，驗證多核環境下啟用原子操作能夠保證運行結果的正確性。
多核調度功能：支持多核并行運行，支持核心可搶占、提供基于優先級搶占調度、時間片輪轉調度，保證任務不會有餓死的情況；采用統一的任務隊列管理，基于高效的核間中斷機制實現多核任務統一調度，賦予多核環境中各CPU調度本地就緒隊列的能力；支持處理器親和性，提供任務和中斷綁定到指定處理器核的編程接口，用戶可以根據應用的需要把任務綁定到指定的處理器核上運行的功能進行測試。通過運行測試程序，測試多種優先級任務組合情況下，同時運行的環境下監測任務調度情況，查看系統中各個CPU的負載情況，驗證多核調度功能的正確性。設置了如下幾種優先級任務組合情況，查看是否依據任務優先級進行調度，假設任務優先級由0～255個級別。
運行4個任務，優先級相同（250），不指定運行在哪個cpu上，觀察4個任務在cpu上的分布情況，之后運行4個新任務，優先級逐一提高（251、252、253、254），觀察任務搶占調度。是否高優先級任務搶占低優先級任務。四個核上運行任務為（251、252、253、254），待這4個任務完成之后再運行優先級為250的4個任務。
運行4個任務，優先級各不相同（250、251、252、253），不指定運行在哪個cpu上，觀察4個任務在cpu上的分布，之后運行4個新任務，優先級逐一提高（251、252、253、254），觀察任務搶占調度。是否高優先級任務搶占低優先級任務。251的搶250、252的搶251、253的搶251、254的搶252，此時四個核上運行的任務應該為254、253、253、252，待任務運行完之后再按順序調度252、251、251、250的任務。
運行4個任務，優先級相同（250），不指定運行在哪個cpu上，觀察4個任務在cpu上的分布，之后運行4個新任務，優先級逐一提高（251、252、253、254），觀察任務搶占調度；之后動態調整優先級252任務的優先級到249，觀察任務搶占調度。是否高優先級任務搶占低優先級任務。動態調整優先級252任務的優先級到249后，252任務運行的核被優先級為250的任務搶占。
運行4個任務，優先級各不相同（250、251、252、253），指定cpu（對應順序0、1、2、3），觀察4個任務在cpu上的分布。是否每個任務運行在指定的核上。
運行4個任務，優先級各不相同（250、251、252、253），指定cpu（對應順序0、1、2、3），觀察4個任務在cpu上的分布；之后運行4個新任務，不指定CPU，優先級254，觀察任務搶占調度。是否高優先級任務搶占低優先級任務。四個核上運行的任務應該均為254，待任務運行完之后再按指定的CPU調度253、252、251、250的任務。
運行4個任務，優先級各不相同（250、251、252、253），指定cpu（對應順序0、1、2、3），觀察4個任務在cpu上的分布；之后運行1個新任務，優先級252，指定CPU0（對應優先級250的任務），觀察任務搶占調度。是否高優先級任務搶占低優先級任務。優先級為252的任務搶占優先級250的任務運行在CPU0上，待任務運行完之后CPU0再運行優先級250的任務。
運行4個任務，優先級各不相同（245、246、247、248），不指定cpu，觀察4個任務在cpu上的分布，之后運行4個新任務，優先級為250、251、252、253，指定CPU（對應順序0、1、2、3），觀察任務搶占調度。是否高優先級任務搶占低優先級任務。優先級為250、251、252、253的任務運行在指定的核上，待運行完畢后再運行優先級245、246、247、248的任務。
運行4個任務，優先級各不相同（245、246、247、248），指定CPU（對應順序0、1、2、3），觀察4個任務在CPU上的分布，之后運行4個新任務，優先級為250、251、252、253，指定CPU（對應順序3、2、1、0），觀察任務搶占調度。是否按照指定的核進行任務搶占，250搶248運行在CPU3上，251搶247運行在CPU2上，252搶246運行在CPU1上，253搶245運行在CPU0上，待新任務運行完畢后，優先級245、246、247、248的任務再運行在指定的核上。
運行2個任務，優先級各不相同（250、251），指定CPU0和1，觀察2個任務在CPU上的分布；之后運行1個新任務，優先級252，指定CPU0（對應優先級250的任務），觀察任務搶占調度。高優先級任務搶占低優先級任務。優先級252的任務搶占CPU0，待運行完畢后CPU0再運行優先級250的任務。
運行2個任務，優先級各不相同（250、251），指定CPU0和1，觀察2個任務在CPU上的分布；之后運行1個新任務，優先級252，指定CPU0（對應優先級250的任務），觀察任務搶占調度；之后取消優先級250任務的CPU綁定，觀察任務搶占調度。高優先級任務搶占低優先級任務。優先級252的任務搶占CPU0，取消優先級250任務的CPU綁定后，優先級250的任務選擇空閑CPU繼續運行。
2 性能測試
2.1 任務切換時間
任務切換時間，即CPU 的控制權由運行任務主動轉移到另外一個就緒任務時所花費的時間。任務切換時間包括保存當前運行任務上下文的時間、選擇下一個任務的調度時間以及將要運行任務的上下文恢復時間。
為了測試任務切換時間，需要制造任務之間的切換事件。在非搶占情況下，制造的測試場景是讓當前正在執行的任務激活另一個任務，然后自身掛起，那么，被激活的任務將處于就緒狀態，從而引起調度。切換過程包含了一系列的操作，如當前任務上下文的保存、新任務上下文的恢復等，這一過程所需要的時間開銷就是任務切換時間。
設當前正在運行的任務為TASK[i]，將要運行的新任務為TASK[i+I]。用T1表示新任務TASK[i+I]的激活時刻，T2表示新任務TASK[i+I]表示新任務開始運行的時刻，可以用T2.T1來近似地表示兩個任務之間的切換時間。
測試用例設計，構建my_test_performance工程，通過在任務一中調用pthread_suspend（此處任務調度函數為Posic通用接口）掛起任務二，之后調用pthread_resume恢復任務二的執行，插樁獲取從調用pthread_resume到任務二開始執行之間的時間，測試多核環境下的任務切換時間。
2.2 任務搶占時間
任務搶占時間，即系統將控制權從低優先級任務轉移到高優先級任務所花費的時間，它包括識別引起高優先級任務就緒的事件，比較兩個任務的優先級，最后進行任務的切換。
構建my_test_performance工程，通過在任務一中調用pthread_suspend掛起任務二，之后調用pthread_resume恢復任務二的執行，插樁獲取從調用pthread_resume到任務二開始執行之間的時間，測試多核環境下的任務響應時間。
2.3 中斷響應時間
中斷響應時間，即從中斷產生到開始執行中斷處理程序的第一條指令之間的時間間隔。主要由系統鎖中斷時間和中斷執行準備時間組成。
系統中斷是一種重要的異步事件，使用中斷的目的在于提高系統的效率。避免CPU對某些事件的輪詢，占用資源。在中斷驅動的系統中，CPU運行正常執行程序，當輸入輸出設備需要服務時，輸入輸出設備會通過中斷的方式通知CPU，CPU通過中斷服務程序對其作出快速的反應。
測試時制造場景IntrResp_test工程。安裝用戶自定義異常處理程序，之后觸發中斷，通過sys_timestamp獲取從中斷觸發時刻到進入異常處理程序所需時間，得到多核環境下的中斷響應時間。多次測試取最大值。
2.4 運算性能
多核設定不同的參與計算的CPU核數進行各種典型計算，比對消耗的運算時間，測試多核環境下CPU計算性能。PI運算、n皇后算法、Fibonacci數列算法。
此處同時還移植Linux平臺測試工具CPU2006，在操作系統上運行。獲取bzip、specrand、libqua、hmmer等運算處理時間。
2.5 信號量延遲時間
信號量延遲時間，即一個任務釋放信號量到另一個任務等待信號量的任務獲得信號量的時間間隔。當無任務等待信號量時，信號量延遲即為其釋放操作和獲取操作所需時間。當信號量的等待隊列上有阻塞等待的任務時，信號量延遲時間包含從等待隊列中解除阻塞任務，到該任務被調度執行的時間間隔。
2.6 核間同步時間
通過構建cpc_call_test工程，測試多核環境下的核間同步時間。
運行my_test_performance工程。通過啟動兩個優先級相同任務，任務1調用spin_lock關任務搶占再spin_unlock開搶占，任務2也調用spin_lock關任務搶占，使用Testbed RtInsight工具插樁獲取從任務1調用spin_unlock開搶占到任務2spin_lock關任務搶占之間的時間，測試多核環境下的核間同步時間。多次測試取最大值。
2.7 內存讀寫速度
程序代碼按預先分配好的地址空間存放在ROM中，不可能重新分配地址，程序的最終加載地址必須生成程序時重新分配，由于數據存儲在RAM中，系統要分別對代碼和數據定位，同時，為了節省昂貴的RAM，需要確定ROM中的只讀數據和可變數據，大量的只讀數據不用傳到RAM中。嵌入式系統存儲管理不僅僅包括RAM（片內RAM，SRAM）管理， 還包括ROM（MASK-ROM、FLASH）管理及虛擬內存管理（僅對含有MMU的MCU/CPU）。本文不論虛擬內存管理。嵌入式系統的內存管理可以細分為：
全局內存管理：任務共享數據管理及設備驅動的內存管理。
虛擬內存管理：主要用于需要大內存并且FLASH大的情況，虛擬內存管理是頁式管理。
局部內存管理：使用全局內存管理時要內存管理狀態為malloc_mem_null時調用全局內存管理并設為臨界態。
系統內存管理：只能由系統使用的內存。
使用mbw測試程序進行用戶內存讀寫速度進行測試，包含MEMCPY、DUMB、MCBLOCK（固定塊大小的MEMCPY測試，默認塊大小262144）。導入mbw工程，分別以參數50調用mbw運行測試，獲取運行結果。
2.8 文件讀寫速率
簡單的嵌入式系統沒有文件系統的支持，也能運行的很好，但對于現代嵌入式系統，需要管理和傳輸固態硬盤或U盤上的文件數據，文件系統必不可少。文件系統應具有大容量持久性存儲數據管理支持功能和文件可攜帶。文件系統可以放在閃存Flash中，當系統啟動時引導程序將文件系統拷貝到RAM中執行。一個嵌入式多任務文件系統主要具有如下功能：
實現文件命名、存取、更新及保護數據的基本功能。
提供嵌入式系統與其他系統之間的數據傳輸功能，處理多個用戶文件I/O存取，具有文件共享功能。
具有邏輯組織數據的能力，采用隨機存取數據方法，使系統能快速查找信息。
支持設備無關性，使應用程序文件操作獨立于存儲介質，文件操作在其所支持的每個設備上產生同樣的結果。
兼容多個文件系統（FAT16，FAT32），標準的I/O接口（ANSI C、POSIX或WIN32）。
支持多種存儲介質（如固態硬盤和U盤）的可靠存儲。
文件系統的實現需要解決文件和目錄的存儲、存儲介質空間的管理工作。嵌入式文件系統測試的重點在性能測試，使用iozone工具進行測試。
U盤讀寫速率：
使用performance_test工程，調用iozone（"-i 0 r 32k s 32m"）和iozone（"-i 1 r 32k s 32m"）分別測試文件讀寫速率。
（-i #n 指定的測試項，n的值為0到12，其中0=write/rewrite， 1=read/re-read。-r 為指定的文件塊大小，以KB為單位。-s 為指定的文件大小，其單位為MB。）
performance_test，在C中運行iozone：
mount（"dosfs"，"/dev/umass0p1"，"/c"）
sp iozone，"-i 0 -i 1 -r 32k -s 32m"
2.9 圖形性能測試
對于GUI圖形系統的測試修改通用的性能工具DMA進行。
重點測試對于系統繪制矩形、直線、填充矩形的時間進行測試：
加載gtk_demo_new工程，通過調用canvas.c文件中的 do_canvas_test1函數，在畫布上使用surface->DrawRectangle函數，得到畫矩形的時間。
加載gtk_demo_new工程，通過調用canvas.c文件中的 do_canvas_test1函數，在畫布上使用surface->DrawLine 和surface->DrawArc函數，得到畫線的時間。
加載gtk_demo_new工程，通過調用canvas.c文件中的 do_canvas_test1函數，在畫布上使用surface->FillRectangle函數填充矩形的時間。
另外對于GUI圖形系統的內存使用情況進行測試。對比加速和非加速情況下內存使用情況：
加載gtk_demo_new工程，設置canvas.c文件的 do_canvas2函數， 窗口大小為400*300，編譯下載到目標機，通過調用 do_canvas_test2和mi函數記錄打開窗口后的內存使用情況，關閉400*300的窗口，通過調用mi函數記錄打開窗口后的內存使用情況，比較內存差值。
加載gtk_demo_new工程，設置canvas.c文件的 do_canvas2函數， 窗口大小為800*600，編譯下載到目標機，通過調用 do_canvas_test2和mi函數記錄打開窗口后的內存使用情況，關閉800*600的窗口，通過調用mi函數記錄打開窗口后的內存使用情況，比較內存差值。
加載gtk_demo_new工程，設置canvas.c文件的 do_canvas2函數， 窗口大小為1024*768，編譯下載到目標機，通過調用 do_canvas_test2和mi函數記錄打開窗口后的內存使用情況，關閉1024*768的窗口，通過調用mi函數記錄打開窗口后的內存使用情況，比較內存差值。記錄打開關閉1024*768的窗口所使用的內存差值。
加載GTK_DMA工程，確認配置文件中勾選圖形系統配置和顯示驅動，設置df_dok_2.c中PRIMARY為0（開啟DMA加速，屏下）執行df_dok_demo2（0，0）命令獲得測試結果，設置PRIMARY為1（關閉DMA加速，屏上）獲得測試結果。得到開啟和關閉硬加速的情況下對比數據。
3 安全性測試
操作系統安全評測的基礎是需求說明，即把一個操作系統稱為“安全”的真實含義是什么。一般來說，安全系統規定安全特性、控制對信息的存取，使得只有授權的用戶才有讀、寫、建立或刪除信息的存取權等。主要對以下幾方面進行測試：
測試嵌入式操作系統的死鎖檢測機制。系統可以檢測到死鎖并打破死鎖。
測試可能發生優先級反轉的各種情況下，系y防止優先級反轉的措施。系統防止優先級反轉。
測試引用無效內存地址的情況下，系統能否進行出錯處理。系統進行出錯處理。
測試系統出現異常狀況（例如：虛擬存儲區缺頁、算術溢出、非法操作碼等）時，操作系統能否檢測到異常錯誤并進行處理。操作系統能檢測到異常錯誤，并由異常處理程序進行處理。
測試應用程序資源使用超出范圍時，操作系統的處理能力。系統進行出錯處理。
測試系統的內核運行狀態監視機制。系統提供內核運行狀態監視機制。
測試系統的內核故障檢測能力。系統能成功檢測到故障，并進行出錯處理。
測試系統的應用故障檢測能力。系統檢測到故障并終止故障運行。
測試安全關鍵數據的冗余備份機制。提供安全關鍵數據的冗余備份。
在具有內存管理單元（MMU）的硬件平臺上；設計并運行應用進程試圖對內核數據進行訪問的測試用例，測試系統能否給出出錯提示。系統給出出錯提示。
在配置網絡通信模塊時，設計并運行系統在一個時間段內的并發會話數量超過最大值的測試用例，測試系統能否給出出錯提示。系統給出出錯提示。
在配置網絡通信模塊時，測試操作系統能否提供端口訪問控制。提供端口訪問控制。
在配置網絡通信模塊時，y試系統對非法攻擊的檢測、預警和防范機制。系統提供檢測、預警和防范機制。
具體方法包括：
測試方法：采用人工模擬故障的方法，驗證嵌入式實時操作系統在出現異常時是否會采取保護措施不影響其他任務的執行；在操作系統使用過程中輸入錯誤數據，驗證操作系統是否具有提示或報警功能，系統資源監控功能在系統監控測試項中進行。判斷準則：嵌入式實時操作系統在出現異常時能夠采取保護措施不影響其他任務的執行，應對用戶的錯誤輸入具有提示或報警功能。
測試方法：操作系統與用戶應用地址空間進行隔離，用戶空間和內核空間將映射到不同的地址空間。用戶應用地址空間進一步基于MMU機制對應用構件進行地址空間隔離，不同的應用構件將占用不同的地址。一個應用構件訪問其它應用構件的地址空間時將發生異常。同時對構件中的任務?？臻g作了棧溢出保護，當構件中的任務出現棧溢出時將會觸發異常。對構件中的文本段也作只讀保護，當試圖改寫時，將發生異常。判斷準則：嵌入式實時操作系統在出現異常時能夠采取保護措施不影響其他任務的執行，應對用戶的錯誤輸入具有提示或報警功能。
測試方法：系統在發生TLB無效異常、保留指令異常、協處理器不可用異常以及浮點異常時，若系統未掉電將能通過日志服務記錄故障發生時的CPU異常信息、源文件名、行號、時間、寄存器信息、?；厮?、錯誤地址以及附加信息等內容。判斷準則：嵌入式實時操作系統在出現異常時能夠采取保護措施不影響其他任務的執行，應對用戶的錯誤輸入具有提示或報警功能。
系統測試范文6
【關鍵詞】 智能化變電站 二次系統 檢測調試 比對試驗
1 引言
非常規互感器的數字化輸出特性和高速以太網組成變電站數據采集傳輸系統，以及基于IEC61850標準實現變電站內設備連接的高速化、網絡化，通過站控層、間隔層、過程層真正實現數據、資源共享和智能化應用，是數字化變電站最鮮明的特點[1]。
與常規變電站相比較，智能化變電站二次系統的測試設備、方法及手段均發生深遠變化，如非常規互感器（NCIT）、合并單元（MU）等，由于是在物理層面上隔離、聯系一次設備和二次設備的全新裝置，傳統的檢測方法和手段均不適用，這方面相關的研究和工程化應用都較缺乏。國內外科研機構、測試設備生產廠家提供的測試設備往往不具備測試這些裝置的功能，只是將傳統的模擬量輸出轉換為數字量輸出，有的只能進行單項目調試、有的沒有考慮到智能化變電站的工程化應用[2-4]。所以，對智能化變電站二次系統的測試設備、測試方法及測試手段進行深入研究，是非常有必要的。
2 智能化變電站測試的要求和必要性
要實現智能變電站二次系統的測試，主要完成智能設備制造商家出廠單裝置調試、第三方試驗驗證中心進行系統級聯合檢測調試、安裝運行單位現場安裝調試及現場性能調試。
其主要內容為設備制造廠家出廠調試、第三方試驗驗證中心進行系統級聯調、安裝運行單位現場安裝調試及現場性能調試等相關內容。
設備制造廠家出廠調試主要是對智能站設備和裝置從硬件檢查、功能測試、性能測試、穩定性測試進行試驗。
第三方試驗驗證中心進行系統級聯調主要對智能變電站的保護控制裝置作為一個整體系統，進行協議測試、網絡測試等，檢驗智能站全站實現的一致性，滿足IEC61850系列標準和工程實施規范。
安裝運行單位現場安裝調試及現場性能調試包括二次系統性能測試和系統投運調試。該調試在現場所有二次設備安裝完成后進行，對二次系統、裝置進行功能及性能測試，以達到符合運行條件的目的。
啟動調試是在智能變電站采用非常規互感器后，無法通過傳統的通流、加壓及極性試驗對二次交流系統在實際帶電運行時能否正常工作進行驗證，應通過相關試驗儀器對全站二次交流設備進行試驗驗證，使之符合運行要求[5]。
3 現場測試的主要內容分析及方案的提出
智能變電站現場二次系統的試驗涉及范圍較廣，這里主要對一些和常規變電站不同的試驗項目進行分析，對試驗的相關內容及試驗手段進行探討，對試驗指標和要求進行進一步說明。
3.1 網絡性能測試
對于智能變電站，按照對網絡系統的功能的實現和性能的要求，重點應對網絡數據吞吐量、數據轉發時延及數據丟包率等進行測試。吞吐量測量交換設備的數據包轉發能力，通常指在不丟包條件下每秒轉發包的極限。一般可用二分法和步進法查找該極限點。丟包率測試交換設備在不同負荷情況下丟棄數據包與應轉發數據包的比例。不同負荷通常指線路上傳輸包的最高速率，以最高速率的10%遞增進行測試[6]。
3.2 時鐘準確度及同步測試
對智能變電站系統實施時間同步測試，確保時間同步對時系統的輸出時間準確度滿足設備對時精度要求，是智能變電站運行必要條件之一。
（1）電流采樣同步性測試。與常規變電站不同，由于每個非常規電流互感器存在數據處理時間的差異、采樣網絡存在傳輸延時的差異等，使得智能變電站的各個模擬量之間存在采樣非同步問題，所以必須對不同電流互感器采樣同步性進行測試、調整。這項試驗，可以在一次通流試驗時同時進行，通過對同時使用多個電流互感器的站端保護，如母線差動保護、主變差動保護等，在多個非常規電流互感器一次側并聯后通入大小相同方向一致的電流，可以根據保護裝置中這兩個電流量的采樣角度差判斷采樣的同步性，也可以通過數字式示波器來判斷采樣的同步性。（2）電壓采樣同步性測試。在具備同期合閘的測控裝置及電壓并列裝置中，需要對不同非常規電壓互感器的電壓采樣進行同步。這項試驗，可以在一次加壓試驗時同時進行，將不同非常規電壓互感器一次側并接升壓，可以在測控裝置及電壓并列裝置上檢查不同電壓采樣的角度差，以判斷電壓的同步情況，也可以通過數字式示波器來判斷采樣的同步性[7]。
3.3 交流回路正確性檢查
智能站中非常規光電式互感器的使用，使其傳統的二次回路的試驗手段，如極性測試、通流試驗將不能完成保證互感器變比、極性和二次回路的正確性。目前，對智能站非常規光電式互感器進行一次通流、加壓是檢驗回路完整性正確性的較佳選擇。一次通流加壓就是讓電流流過站內非常規光電式互感器，從而來驗證互感器變比、極性和二次繞組的接入方式，以保證互感器二次回路的完整性和正確性。為經濟、安全、可靠的完成一次通流、加壓，要先建立好變電站相關數學模型，設計通流加壓方案，主要要保證各側互感器全部能夠驗證，其次要保證通流時短路阻抗較小，一般應分別在高壓等級側通流、高壓側對中壓側通流和中壓側對低壓側通流。
4 結語
本文對智能變電站二次系統的測試方法及測試手段進行分析研究，對試驗流程、試驗的相關內容進行探討，對試驗指標和要求進行進一步說明。尤其對與常規變電站不同的部分進行了深入研究，提出了基于現場實際的最佳方案，使其測試方案更具備可操作性和實用性
對智能變電站二次系統試驗驗證技術的研究探討，也將隨著智能變電站技術的發展而不斷進步，如何更好的完成智能變電站二次系統的測試，仍有待進一步研究與實踐。
參考文獻：
[1]高翔.數字化變電站應用技術[M].北京：中國電力出版社，2008.
