時間：2022-05-10 14:40:57
序論：在您撰寫系統測試時，參考他人的優秀作品可以開闊視野，小編為您整理的7篇范文，希望這些建議能夠激發您的創作熱情，引導您走向新的創作高度。
關鍵詞：軟件測試；系統測試；線索；壓力測試；性能測試
中圖分類號：TP39文獻標識碼：A文章編號：1007-9599 (2012) 05-0000-02
一、引言
軟件測試作為軟件質量保證的關鍵技術之一，其目的就是能夠有效地發現軟件中的錯誤或缺陷。系統測試是對完整集成后的系統進行測試的階段，用來評價系統對具體需求規格說明的符合性，系統測試是在單元、組件和集成測試階段之后進行的。主要針對軟件系統和其他系統元素（及硬件、數據庫和人機交互信息）組合構成完整的計算機應用系統中所有的元素配合是否合適以及整個系統的功能、性能、執行強度、安全性等是否達到規定標準而進行的測試。
二、系統測試概述
（一）系統測試概念
所謂系統測試是將通過集成測試的軟件系統，作為計算機系統的一個重要組成部分，與計算機硬件、外設、某些支撐軟件的系統等其他系統元素組合在一起所進行的測試，目的在于通過與系統的需求定義作比較，發現軟件與系統定義不符合或矛盾的地方。
（二）系統測試前的準備工作
系統測試前的準備工作主要包括：對系統各種功能的描述；系統要求的數據處理及傳輸的速率；對系統性能的要求；對備份及修復的要求；對兼容性的描述；對配置的描述；對安全方面的要求等。
（三）系統測試的測試數據
系統測試所用的數據必須盡可能地像真實數據一樣精確和有代表性?？梢允褂谜鎸崝祿蛘呤褂谜鎸崝祿囊粋€復制，復制數據的質量、精度和數據量必須盡可能地代表真實的數據。
（四）系統測試與確認測試區別
確認測試始于集成測試的結束，那時已測試完單個構件，軟件已組裝成完整的軟件包，且接口錯誤已被發現和改正。在確認測試時，傳統軟件與面向對象軟件的差別已經消失，測試便集中于用戶可見的動作和用戶可識別的系統輸出。
1.確認測試準則
軟件確認是通過一系列表明已符合軟件需求的測試而獲得的。測試計劃和規程都是用于確保滿足所有的功能需求，具有所有的行為特征，達到所有的性能需求，文檔是正確的、可用的。執行每個確認測試用例之后，存在下面兩種可能條件之一：（1）功能或性能特征符合需求規約，因而被接受；（2）發現了與規約的偏差，創建缺陷列表。
2.配置評審
評審的目的是保證所有的軟件配置元素已正確開發、編目，且具有支持軟件生命周期的支持階段的必要細節。
3.α測試與β測試
α測試是由最終用戶在開發者的場所進行。軟件在自然的環境下使用，開發者站在典型用戶的后面觀看，并記錄錯誤和使用問題。α測試在受控的環境下進行。
β測試是最終用戶場所執行。開發者通常不在場，因此，β測試是在不為開發者控制的環境下軟件的現場應用。最終用戶記錄測試過程中遇見的所有問題(現實存在或想象的)，并將其定期地報告給開發者。接到β測試的問題報告之后，軟件工程師進行修改，然后準備向最終用戶軟件產品。
二、系統級功能測試技術
（一）線索的概念
線索（thread）的概念很難定義。事實上，一些已經公開的定義都是矛盾、容易產生誤導或錯誤的?？梢园丫€索看作是一種不需要形式化定義的原始概念。以下是對線索的多種看法：一般使用的場景；系統級測試用例；激勵/響應對；由系統級輸入序列產生的行為；端口輸入和輸出事件的交替序列；系統狀態機描述中的轉換序列；對象消息和方法執行的交替序列；機器指令序列；源指令序列；MM-路徑序列；原子系統功能序列。
（二）需求規約的基本構造元素
根據一組基本需求規約構造元素，即數據、行動、設備、事件和線索，來討論系統測試。每個系統都可以使用這五種元素表示。
1.數據
主要包括：變量、數據結構、字段、記錄、數據存儲和文件、實體關系模型高層數據描述。
2.行動
以行動為中心建模仍然是需求規約的一種常見形式，這是因為有命令式程序設計語言以行動為中心性質的歷史原因。行動有輸入和輸出，這些輸入和輸出既可以是數據，也可以是端口事件。行動還可以分解為低層活動，例如數據流圖。
3.設備
每個系統都有端口設備，這些端口設備是系統級輸入和輸出（端口事件）的源和目的地。在技術上，端口是I/O設備接入系統的點。
4.事件
事件既有數據方面的一些特征，又有行動方面的一些特征。事件是發生在端口設備上的系統級輸入（或輸出）?？梢允请x散的，也可以是連續的（例如溫度、高度或壓力）。端口輸入事件是物理到邏輯的轉換，同樣，端口輸出事件是邏輯到物理的轉換。
5.線索
因為要測試線索，因此測試人員通常不能在數據、事件和行動之間的交互中找出線索。線索本身出現在需求規約中的惟一地方，是使用快速原型法并結合場景記錄器。
（三）線索測試的結構策略及功能策略
結構策略實際上是基于有限狀態機的行為建模中的結構來尋找測試線索的。首先自底向上組織各層次的狀態機，然后尋找線索覆蓋每個狀態機的節點和邊，同時還要找出節點與邊覆蓋指標。
線索測試的功能策略
1.基于事件的線索測試
（1）端口輸入事件覆蓋指標
五個覆蓋指標為覆蓋端口輸入事件提供了一組線索：
(1)PI1：每個端口輸入事件發生。
(2)PI2：端口輸入事件的常見序列發生。
(3)PI3：每個端口輸入事件在所有“相關”數據語境中發生。
(4)PI4：對于給定語境，所有“不合適”的輸入事件發生。
(5)Pl5：對于給定語境，所有可能的輸入事件發生。
（2）端口輸出事件覆蓋指標
根據端口輸出事件定義兩種覆蓋指標：
(1)PO1：每個端口輸出事件發生。
(2)PO2：每個端口輸出事件在每種原因下發生
2.基于端口的線索測試
基于端口的測試是基于事件測試的有用補充。
對于每個端口都要詢問端口上會出現什么事件。然后根據每個端口的事件列表尋找使用輸入端口和輸出端口的線索。有些需求規約技術要求提供這種端口的事件列表。
設備和事件之間的多對多測試應該在兩個方向上進行：基于事件的測試覆蓋從事件到端口的一對多關系，反之，基于端口的測試覆蓋從端口到事件的一對多關系。SATM系統不能使用這種測試，因為SATM不發生在多個端口上。
三、系統測試的主要內容
系統測試一般要完成以下幾種測試：功能測試、性能測試、可靠性、穩定性測試、兼容性測試、恢復性測試、安全性測試、強度測試、面向用戶支持方面的測試、其他限制條件的測試。下面就對常用的系統測試做一個介紹：
（一）壓力測試
壓力測試是指模擬巨大的工作負荷以查看或評估應用程序在峰值或超越最大負載使用情況下如何執行操作。壓力測試有如下特點：可以測試系統的穩定性；一般需要對用戶的使用情況進行模擬。壓力測試的方法包括：并發測試法、增加量級法、重復測試法。
（二）性能測試
性能測試一般需進行：對軟件計算的精度有要求時，設計測試用例；對軟件有時間要求時，設計測試用例；測試為完成功能所處理的數據量；測試程序運行所占用的空間；測試對系統的負載潛力；測試配置項各部分的協調性；測試軟件性能和硬件性能的集成；測試系統對并發事務和并發用戶訪問的處理能力。
（三）恢復性測試
多數基于計算機的系統必須從錯誤中恢復并在一定的時間內重新運行?；謴托詼y試是通過各種方式強制地讓系統發生故障并驗證其能適當恢復的一種系統測試。若恢復是自動的(由系統自身完成)，則對重新初始化、檢查點機制、數據恢復和重新啟動都要進行正確性評估。若恢復需要人工干預，則估算平均恢復時間(mean-time-to-repair，MTTR)以確定其是否在可接受的范圍之內。
（四）安全性測試
安全性測試驗證建立在系統內的保護機制是否能夠實際保護系統不受非法入侵。系統的安全必須經受住正面的攻擊，但是也必須能夠經受住側面和背后的攻擊。在安全性測試過程中，測試者扮演試圖攻擊系統的角色。測試者可以試圖通過外部手段獲取密碼；可以通過瓦解任何防守的定制軟件來攻擊系統；可以“制服”系統使其無法對別人提供服務；可以有目的地引發系統錯誤以期在其恢復過程中入侵系統；可以通過瀏覽非保密數據，從中找到進入系統的鑰匙等等。
四、結語
系統測試有助于在其部署中客戶發現缺陷之前，盡可能多滴發現缺陷，在系統測試期間要驗證完整產品的行為，包括設計多個模塊、程序和功能的測試，測試完整產品的行為是很關鍵的，因為很多人錯誤地認為經過單獨測試的組件放到一起后仍能正常運行。
參考文獻：
[1]薛沖沖,陳堅.軟件測試研究[J].計算機系統應用,2011,2
[2]陶幸輝,宋志剛.軟件系統測試類型及測試用例設計[J].科技經濟市場,2011,6
[3]朱家云.淺析軟件測試[J].信息系統工程,2011,4
[4王麗達.論軟件系統的測試[J].經濟研究導刊,2011,14
三年以上工作經驗|男|29歲（1987年3月11日）
居住地：曲阜
電 話：158******（手機）
E-mail：
最近工作[1年7個月]
公 司：XX有限公司
行 業：通信/電信/網絡設備
職 位：系統測試
最高學歷
學 歷：本科
?！I：通信工程
學 校：曲阜師范大學
自我評價
本人畢業于軟件工程專業，在學校經過多年的努力，有著扎實的計算機基礎。目前一直從事于IT 行業，熱愛軟件測試，有多年的測試經驗，熟悉軟件的開發的流程和測試流程，熟悉b/s 框架系統和C/框架的區別，有豐富的測試經驗，了解 QTP 和 loadrunner 的工作原理。XX年測試經理，XX年的測試主管，積累了豐富的管理經驗。希望從事測試經理以上職位（最好是高級測試經理和測試總監）的測試管理工作。
求職意向
到崗時間：一個月之內
工作性質：全職
希望行業：通信/電信/網絡設備
目標地點：曲阜
期望月薪：面議/月
目標職能：系統測試
工作經驗
2013/11 — 2015/6：XX有限公司[1年7個月]
所屬行業：通信/電信/網絡設備
測試部系統測試
1.熟悉手機功能機，智能機（MTK，展訊，高通，瑞芯微/INTEL 6321/SOFIA平臺）方案，手機軟件研發流程。熟悉安卓系統，將針對產品制定出全面測試案例，專項測試案例，壓力測試案例。
2.測試報告的提出，回復，驗證及BUG問題詳細記錄，做到可以追溯。
3.版本號規則命名，軟件存儲路徑規范，軟件測試流程的商討等
4.協助和推動項目組將產品軟件改善達到穩定狀態。
2011/9 — 2013/8：XX有限公司[1年11個月]
所屬行業：通信/電信/網絡設備
測試部 系統測試
1.及時了解項目進度,及時了解軟件狀態，減少軟件問題延誤進度
2.未處理的嚴重問題,及時反饋,跟催.已改善的嚴重問題,反復測試驗證,重點關注
3.硬件/軟件問題及時與工程師溝通,反饋到所有相關人員.該重視問題會重點強調.
4.建立BUG數據匯總,讓相關人員了解每周BUG處理情況
教育經歷
2006/9— 2011/6 曲阜師范大學 通信工程本科
證書
2007/12 大學英語四級
本文從功能、性能、可用性、客戶端兼容性、安全性等方面討論了基于web的系統測試方法。/kF?RZNAX4^''''8gnv[本資料來源于貴州學習網計算機網絡技術]/kF?RZNAX4^''''8gnv
隨著internet和intranet/extranet的快速增長，web已經對商業、工業、銀行、財政、教育、政府和娛樂及我們的工作和生活產生了深遠的影響。許多傳統的信息和數據庫系統正在被移植到互聯網上，電子商務迅速增長，早已超過了國界。范圍廣泛的、復雜的分布式應用正在web環境中出現。web的流行和無所不在，是因為它能提供支持所有類型內容連接的信息，容易為最終用戶存取。
yogeshdeshpande和stevehansen在1998年就提出了web工程的概念。web工程作為一門新興的學科，提倡使用一個過程和系統的方法來開發高質量的基于web的系統。它"使用合理的、科學的工程和管理原則，用嚴密的和系統的方法來開發、和維護基于web的系統"。目前，對于web工程的研究主要是在國外開展的，國內還剛剛起步。
在基于web的系統開發中，如果缺乏嚴格的過程，我們在開發、、實施和維護web的過程中，可能就會碰到一些嚴重的問題，失敗的可能性很大。而且，隨著基于web的系統變得越來越復雜，一個項目的失敗將可能導致很多問題。當這種情況發生時，我們對web和internet的信心可能會無法挽救地動搖，從而引起web危機。并且，web危機可能會比軟件開發人員所面對的軟件危機更加嚴重、更加廣泛。
在web工程過程中，基于web系統的測試、確認和驗收是一項重要而富有挑戰性的工作。基于web的系統測試與傳統的軟件測試不同，它不但需要檢查和驗證是否按照設計的要求運行，而且還要測試系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，internet和web媒體的不可預見性使測試基于web的系統變得困難。因此，我們必須為測試和評估復雜的基于web的系統研究新的方法和技術。
一般軟件的周期以月或以年計算，而web應用的周期以天計算甚至以小時計算。web測試人員必須處理更短的周期，測試人員和測試管理人員面臨著從測試傳統的c/s結構和框架環境到測試快速改變的web應用系統的轉變。
一、功能測試
1、鏈接測試
鏈接是web應用系統的一個主要特征，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面。首先，測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面；其次，測試所鏈接的頁面是否存在；最后，保證web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的url地址才能訪問。
鏈接測試可以自動進行，現在已經有許多工具可以采用。鏈接測試必須在集成測試階段完成，也就是說，在整個web應用系統的所有頁面開發完成之后進行鏈接測試。
2、表單測試
當用戶給web應用系統管理員提交信息時，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統是否會報錯。
3、cookies測試
cookies通常用來存儲用戶信息和用戶在某應用系統的操作，當一個用戶使用cookies訪問了某一個應用系統時，web服務器將發送關于用戶的信息，把該信息以cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登陸等信息。
如果web應用系統使用了cookies，就必須檢查cookies是否能正常工作。測試的內容可包括cookies是否起作用，是否按預定的時間進行保存，刷新對cookies有什么影響等。
4、設計語言測試
web設計語言版本的差異可以引起客戶端或服務器端嚴重的問題，例如使用哪種版本的html等。當在分布式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了html的版本問題外，不同的腳本語言，例如Java、JavaScript、activex、vbscript或perl等也要進行驗證。
5、數據庫測試
在web應用技術中，數據庫起著重要的作用，數據庫為web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在web應用中，最常用的數據庫類型是關系型數據庫，可以使用sql對信息進行處理。
在使用了數據庫的web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由于用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由于網絡速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。,l/u,H*wjY-gM8- [此文轉貼于我的學習網計算機網絡技術
二、性能測試
1、連接速度測試
用戶連接到web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。
2、負載測試
負載測試是為了測量web系統在某一負載級別上的性能，以保證web系統在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問web系統的用戶數量，也可以是在線數據處理的數量。例如：web應用系統能允許多少個用戶同時在線？如果超過了這個數量，會出現什么現象？web應用系統能否處理大量用戶對同一個頁面的請求？
3、壓力測試
【關鍵詞】LVDS；測試
1.引言
隨著現代電子科學技術的不斷進步，雷達技術和體制的也在不斷發展，DBF體制的相控陣雷達，機載預警雷達以及合成孔徑（SAR）雷達等一些新體制的雷達不斷出現在現代高科技戰場。隨著雷達體制的發展，其對信號帶寬和大容量高速率的信號傳輸提出了越來越高的要求。LVDS這種接口標準為解決這一瓶頸問題提供了可能。目前LVDS技術在工業各領域已經得到了廣泛應用，本文結合某雷達產品調試現狀，提出了一套LVDS的全新測試方法，該方法簡單易行，大大縮減了產品調試周期。
2.LVDS的基本原理
LVDS（LOW VOLTAGE DIFFERENTIAL SIGNALING）是一種低壓差分信號傳輸技術，其基本原理如圖1所示。其驅動器為一個恒流源驅動一對差分信號線組成，在接收端有一個高的直流輸入阻抗，阻抗基本上不會消耗電流，所以幾乎全部驅動電流都流經100W的終端電阻在接收器端產生。約350mV的電壓，當驅動狀態反轉時，流經電阻的電流方向發生改變，于是在接收端產生邏輯狀態的改變。
LVDS傳輸具有以下特點：
（1）高速率，LVDS的恒流源模式低擺幅輸出決定了其高速的驅動能力，它允許單個通道的數據傳輸速率達到數百兆每秒。
（2）超低功耗，LVDS器件采用CMOS工藝，提供了低的靜態功耗，負載（100W的終端電阻）功耗僅為1.2mW.
（3）低噪聲和低電磁干擾，LVDS傳輸采用差分方式，接收端只關心兩信號的差，噪聲被抵消，同時由于差分傳輸，兩條信號線周圍的磁場也相互抵消，降低了電磁干擾。
3.提出方案
某型號雷達采用相控陣列天線，天線為N維陣列，從天線陣列下來的N路射頻信號經過接收系統變換成數字中頻信號，接收系統采用LVDS編碼芯片將中頻信號編碼，一塊LVDS芯片傳輸5路中頻信號，接收系統通過專用的LVDS電纜將信號傳輸到信號處理系統，共N/5路數據組送到信號處理系統，其LVDS芯片將傳送來的5路串行數據還原成5路并行數據。這N/5組并行傳送的信號的直接送到波束形成插件內的FPGA內，完成數字波束形成、同時完成接收通道數據校正和發射通道數據校正等功能。
針對該型號雷達的波束形成插件調試記錄及其插件的返修率進行統計分析發現，LVDS解碼芯片本身質量引發的故障率為21%；表貼工藝引發的故障率為15%；印制線短、斷路，阻值超標，故障率為18%。LVDS解碼芯片自身為細間距芯片，在用探頭點測時容易短路，一旦短路，容易致使芯片由于人為因素失效。
目前信號處理系統調試方法是在波束形成插件的程序中做掃頻數據庫，同時形成波束，這樣在信號處理分系統調試過程中實際上并沒有覆蓋LVDS解碼芯片，也不經過FPGA中的輸入管腳，無法判斷其狀態好壞，只有在雷達整機上系統聯調時才能測試其狀態好壞，需要雷達系統人員配合，而且必須保障信號處理前端的狀態正常才能測試。一旦發現問題，返工的周期也會影響雷達系統聯調的總體時間進度，這樣導致工作量增加，而且調試效果也不佳，售后服務返修件多數情況也無法處理。
針對以上情況，本文提出了一套簡單易行的解決方案，通過搭建波束形成調試、測試工裝，建立一個專門的波束形成插件調試、測試系統，可以在分系統測試時就完成LVDS解碼芯片的功能測試、表貼工藝測試，以及LVDS解碼芯片將信號送進FPGA器件的正交IQ信號M位數字信號的測試，測試是否存在表貼虛焊現象，是否存在印制線短路、斷路現象，是否存在印制線阻值超標現象，測試結果簡單明了，很容易判斷故障的所在。
3.1 系統組成
整個測試系統由接收系統、信號處理系統組成，測試儀器與儀表主要有計算機和示波器各一臺，整個測試系統連接框圖如圖2所示。其中時鐘信號由接收系統產生提供，并通過
LVDS電纜傳給信號處理系統。接收系統測試軟件固化在其配置芯片中，信號處理系統端的測試軟件通過計算機在線編程下載到FPGA芯片中。
3.2 軟件設計
接收系統軟件產生鋸齒波信號，通過測試電纜送信號系統；實現方法：利用一個計數器產生所需鋸齒波信號。具體如圖3所示。
信號系統編寫控制軟件，根據接收系統送過來的信號所接通道，控制選擇相應的LVDS解碼芯片將解得的鋸齒波測試信號送入FPGA器件，并能將接收系統送來的多位信號進行截位控制。重新設計FPGA控制電路，將收到的鋸齒波測試信號采樣、處理、還原成模擬信號、輸出給示波器觀測，這樣測試結果快捷、直觀。當所選通道經過的LVDS解碼芯片和送入FPGA器件的IQ信號均正常，可以在示波器上看到如4所示的波形。
當波形產生插件故障時（比如LVDS解碼芯片故障、送入FPGA器件的IQ信號虛焊、印制線制造故障），示波器上輸出波形將不再是標準的鋸齒波，不同的故障信號位可以根據故障波形基本定位。示意圖如圖5所示。
當輸入的IQ信號較低位出現虛焊時，軟件控制端口的截位控制選項值可以較低，上圖中為05截位；當輸入的IQ信號較高位出現虛焊時，控制軟件控制端口的截位選項值需要較高，這樣才能檢測出故障，圖6所示截位選擇為0E。
3.3 改進后測試流程
在后續的調試過程中，采用了上述測試方法，基本解決了波束形成插件調試困難的問題，提高了調試效率。具體操作流程如圖7所示。
3.4 改進效果比較分析
下面以一塊波束形成插件的調試來比對改進前后的測試效果：
改進前：
配合人員：至少雷達系統和信號處理系統各1人，共2人；
測試平臺：一套完整的雷達；
需要時間：5小時；
同時在測試過程中要受到整機性能的影響，雷達整機工作必須正常，特別是接收校正功能。在沒有整機的情況下是無法進行測試工作，對于分系統的調試以及今后的售后服務插件的維修來說相當不便。
改進后：
配合人員：信號處理系統1人。
測試平臺：信號系統和接收系統調試設備。
需要時間：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.
摘要:
介紹了一款針對航空器上電子設備進行監測的系統的設計與測試方法。該系統可以完成數據的采集與傳輸、錯誤曼徹斯特碼生成、消息監聽等功能，其采用可編程邏輯器件（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.
1區域醫療領域大數據應用系統測試實現
1.1應用系統架構如圖4所示，最底層是HBase集群，用于診療文檔數據倉庫，HMaster是HBase集群的管理節點。應用服務器層由若干臺調閱應用服務器組成，分別注冊到上層的若干臺Nginx服務器中。Nginx層包含多臺Nginx服務器，每臺Nginx服務器下面掛接了若干臺AppServer。負載均衡層由兩臺配置了LVS和Keepalive服務的負載均衡服務器組成，其中一臺為主服務器，另外一臺為備用服務器。
1.2測試環境基于區域醫療大數據應用系統的特點以及要求，搭建了如圖5所示的測試環境。
1.3測試業務(1)基于云計算的健康信息調閱主要面向聯網醫院的醫生，實現對其接診患者健康檔案信息的調閱。(2)基于云計算的智能提示服務基于居民健康信息為醫生提供的提示、警示，如藥物過敏、重點人群等各類警示信息以及重復檢驗/檢查提示等。(3)網上預約服務通過網上預約及醫院醫生病人預約的方式實現病人就診，確保在醫療資源分布不均的情況下，讓病人得到更方便快捷的醫療服務。
1.4測試場景(1)場景一測試所用診療文檔庫的數據量：380萬，腳本取樣：1萬；1萬個工作站在1min之內共完成2000個交易；每次調閱操作的最長響應延時不超過1.5s；高峰時段可支撐500~800個并發用戶請求。(2)場景二測試所用特征數據庫中的數據量：380萬，腳本取樣：1萬；1萬個并發用戶1min之內共完成10000個交易；每次交易最長的響應延時不應超過500ns。
1.5測試方法測試人員根據系統的特點，采用黑盒測試方法，通過自動化和手工結合的方式完成功能測試；使用LoadRunner完成性能壓力測試[6]。功能測試通過手動和自動化工具Selenium相結合的方式進行，按照等價類、邊界值、因果圖、判定表等方法，主要驗證待測試系統各個功能模塊邏輯是否正確[7]。易用性測試通過手動方式檢查區域醫療大數據軟件系統使用的合理性和方便性等。在測試時，測試人員要多從用戶體驗的角度出發，檢驗是否符合大多數而不是個別用戶的操作使用習慣。兼容性測試主要是通過手動的方式驗證區域醫療大數據軟件系統能否在特定的硬件平臺上、不同的應用軟件之間、不同的操作系統平臺上、不同的網絡環境中很好地運行。擴展性測試美國國家標準與技術研究院(NIST)給出的云計算權威定義：按需的自我服務，廣泛的網絡訪問資源池，快速的彈性能力，可度量的服務。云存儲是云計算的一個方面，因此彈性擴展能力對于云計算時代的區域醫療大數據系統尤為重要。擴展性測試，主要包括測試系統的彈性擴展能力(擴展與回縮)，以及擴展系統帶來的性能影響，驗證是否具有線性擴展能力。這部分測試也是以手動方式進行。安全性測試考慮到為保護區域醫療大數據應用系統關鍵核心業務的安全，需要從以下方面實施：保護信息系統安全，加強防止未授權的訪問、使用、泄露、中斷、修改或破壞；保護網絡安全，需要防入侵檢測、防病毒、密碼、物理隔離等；保護數據安全，需要加強數據庫的機密、完整、可備份和可恢復。因此，使用Appscan測試用具進行相關安全性漏洞掃描。壓力測試主要是通過逐步增加系統負載，測試系統性能的變化，并最終確定什么負載條件下系統性能處于失效狀態，并以此獲得系統能提供的最大服務級別的測試，并驗證大數據系統的性能指標要求。使用LoadRunner測試工具進行，LoadRunner是一種預測系統行為和性能的工業標準級負載測試工具。通過模擬上千萬用戶實施開發負載及實時性能監測的方式來確認和查找問題，LoadRunner能夠對整個JavaEE系統的架構進行測試。通過使用LoadRunner，能最大限度地縮短測試時間、優化性能和加速應用系統周期。在不同的測試類型中，采用不同的測試方法。功能測試：采用手工和自動化相結合，針對不同的功能點，合理的使用邊界值法、錯誤推測法、因果圖法、判定表法等，回歸測試80%的功能點由自動化測試工具來完成。性能測試：根據需求調研、制定合理的性能測試指標，使用性能測試工具進行測試，分析測試結果查找系統瓶頸，最終使產品的性能滿足客戶的需求。安全性測試、環境測試以及標準符合性測試都在不同程度進行功能和性能測試[8]。
2結語
