接口測試精品(七篇)

序論：寫作是一種深度的自我表達。它要求我們深入探索自己的思想和情感，挖掘那些隱藏在內心深處的真相，好投稿為您帶來了七篇接口測試范文，愿它們成為您寫作過程中的靈感催化劑，助力您的創作。

篇(1)

關鍵詞： 模型檢驗；接口變異；切片技術；功能依賴圖

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2015）02-0211-04

Abstract：Motivated by compressing the model of component through slicing technique， this paper employs the interactive relationship of the components. Then it proposes a method of constructing a function dependence graph for component system， which is made of a test driver node and some extended component nodes. Finally， by an example， it demonstrates that this method could not only decrease the size of the state space and increase the efficiency for testing generation， but also guarantee the comprehension and the validity of the interface testing for JavaBean components while applying the method of interface mutation testing based on model checking.

Key words： model checking； interface mutation； slicing technique； function dependence graph

模型檢驗技術作為一種形式化驗證方法，以其自動化程度高的特點已經廣泛應用于計算機硬件、通信協議的分析與驗證等許多領域，它通過窮盡地搜索有限狀態系統的狀態空間，從而判定系統（模型）的每一個狀態是否滿足給定的性質，并且總會以“是”或“否”為結果而終止[1]。目前，利用模型檢驗技術進行測試用例生成的研究也十分活躍，并且也取得了一定的研究成果[2]。同時，隨著程序模型檢驗工具的誕生，一些將變異測試方法與程序模型檢驗工具相結合并生成測試用例的研究工作也得到了一定進展[3]。

盡管模型檢驗技術在自動化方面具有許多優點，但它是采用窮盡搜索系統空間的方法對所給定的性質進行驗證，因此，對并發系統而言，其狀態數往往隨并發分量的增加呈指數增長，這樣就產生了“狀態空間爆炸”（state-explosion）問題[1]。對于基于模型檢驗的變異測試來說，當對非等價變異體采用“搜索所有的反例路徑”的策略進行驗證，以及對等價變異體進行驗證時，都必須通過搜索整個系統的狀態空間才能夠進行判定，所以這樣就影響了模型檢驗的驗證效率。

因此，為了壓縮系統狀態空間的數量，本文將通過建立構件系統的功能依賴圖，然后運用切片技術[4]對其進行切片。最后，本文將以Java PathFinder作為模型檢驗工具，采用基于模型檢驗技術的接口變異測試方法[5]對JavaBean構件進行接口變異測試，并對所切片效果進行驗證。圖1給出了該方法的測試用例生成框架。

1 構件系統的功能依賴圖

S.Horwitz等人通過引入系統依賴圖（System Dependence Graph，SDG）的概念表示了具有多個過程的程序依賴圖[6]，但是使用該方法就必須知道每一個過程內部的具體細節信息，因此這種方法并不適用于在源碼未知情況下的構件化軟件切片；雖然文獻[7]提出了一種能夠對由構件所組成的系統進行切片的方法，但是這種方法卻只考慮了構件之間接口的交互關系而忽略了構件在系統中的狀態。因此，本文以文獻[8]所提出的構件之間接口的交互關系為基礎，在細化了構件之間的接互圖后，使其能夠在清晰描述源碼未知情況下被測試構件的狀態和接口函數之間的關系的同時，也能夠使切片技術適用于對被測試構件系統的接口調用關系模型的狀態空間的壓縮。

1.1 功能依賴圖的組成

本文以該被測試構件的接口規約說明為依據，通過測試驅動程序對被測試構件，或者是將該被測試構件和與之相關的構件關聯后進行建模，從而建立被測試構件的接口調用關系模型。通過這個構件系統的接口調用關系模型，被測試構件所具備的相關功能會在利用模型檢驗技術進行驗證的過程中表現出來。因此，將細化后的構件之間的接互關系稱之為構件系統的功能依賴圖（Function Dependence Graph，FDG），并且該圖是由測試驅動節點（Test Driver Node）和構件節點（Component Node）兩種類型的節點所組成。

測試驅動節點是由被測試構件的測試驅動程序所虛擬出來的一個節點，它是整個構件系統的主體框架。從切片技術的觀點來分析，該節點實際上就是它所代表的測試驅動程序的過程依賴圖[3]（Process Dependence Graph）。

構件節點實際上在代表被測試構件的同時，也可以代表與被測試構件相關聯的構件。為了能夠應用切片技術對其進行切片，需要通過添加一些輔助接點對構件節點及輔助邊對其進行細化。這里通過定義一個五元組C = 來描述一個構件節點，具體如圖2所示。

1） 構造函數輔助節點（Construction Assistant Node）的集合Con

對于JavaBean構件來說，為了體現面向對象的特征，在構件節點中應該添加與之相關的所有構造函數的構造函數輔助節點（Conk表示構件中第k個構造函數）。輔助節點實際上就是該構件的入口節點。

2） 狀態輔助節點（State Assistant Node）的集合S

由于在代碼未知情況下的構件接口測試是一種黑盒測試，因此，還必須在構件節點中添加表示構件狀態的狀態輔助節點（Si表示構件中第i個狀態）。

3） 接口函數輔助節點（Interface Function Assistant Node）的集合I

在構件節點中添加表示該構件所包含的所有接口函數的接口函數輔助節點（Im表示構件中第m個接口函數）。

4） 輸入參數輔助節點（Input Parameter Assistant Node）的集合p

對于每一個包含輸入參數的接口函數應該在其所對應的接口函數輔助節點中添加表示該接口函數中所有參數的輸入參數輔助節點（pn表示該接口函數中的第n個參數）。

5） 輔助節點之間輔助邊（Assistant Edge）的集合E

為了能夠體現出上述輔助節點之間的內在關系并使切片技術能夠適用于構件節點，還必須根據構件的規約說明在輔助接點之間添加相應的邊。首先，由于通過構造函數在實例化一個構件的時候，與該構件相關的狀態和接口調用函數也會被創建，因此，就必須在構造函數輔助節點和狀態輔助節點以及構造函數輔助節點和接口函數輔助節點之間添加一條控制依賴邊；其次，根據構件的接口規約說明，應該在具有控制依賴關系的接口函數之間添加能夠代表它們之間控制依賴關系的控制依賴邊；最后，由于構件相關的狀態信息是通過與之相關的構件接口函數進行改變的，所以需要在接口函數輔助節點和狀態輔助節點之間添加一條控制依賴邊，同時，構件的狀態信息也需要通過接口函數向外界進行表現，因此，還應該在狀態輔助節點和與之相關接口函數輔助節點之間添加一條數據依賴邊。綜上所述，構件節點之間輔助邊的集合E是控制依賴邊Ec和數據依賴邊Ed的并集，即：E = Ec U Ed。

1.2 功能依賴圖的建立及其切片

在明確了構件系統的功能依賴圖的組成后，就應該根據測試驅動程序將測試驅動節點和構件節點進行關聯，從而建立整個構件系統的功能依賴圖，它主要包括建立測試驅動程序的過程依賴圖和確立該過程依賴圖與構件節點之間關聯關系兩個主要步驟。

文獻[9]給出了建立測試驅動程序過程依賴圖的具體方法和步驟，故本文在此不作熬述。

本文的研究重點在于對構件的接口進行測試，因此，對被測試構件系統的功能依賴圖的建立主要就體現在確立測試驅動程序的過程依賴圖和構件節點之間的關系之上，這些關系主要包括了如下四個方面：

1） 測試驅動程序對構件的實例化

在測試驅動程序中需要通過構造函數對JavaBean構件進行實例化。這樣，就必須添加一條描述測試驅動程序對構件進行實例化的控制依賴邊。

2） 測試驅動程序對構件中接口函數的調用

對構件中接口函數的每一次調用，需要添加一條描述測試驅動程序對接口函數進行調用的接口函數調用邊。

3） 測試驅動程序對構件中接口函數的參數輸入

對于擁有輸入參數的接口函數來說，測試驅動程序在對其進行調用時，對于每一個輸入參數都需要添加一條描述測試驅動程序在對其進行調用時的參數輸入邊。

4） 構件中接口函數對測試驅動程序的響應

對接口函數的調用實際上相當于對構件中相關功能進行了一次使用，因此，構件就必須向外界產生這個調用的一個響應，這樣，就必須添加一條描述構件中接口函數響應的邊。

本文以三角形問題的JavaBean構件為例進行研究，表1給出了三角形問題構件中的接口函數及接口函數所對應的狀態。

在依據三角形問題構件的接口規約說明建立測試驅動程序后，圖3給出了其構件系統的功能依賴圖。圖中右側部分是測試驅動程序節點，它是由被測試構件的測試驅動程序所建立的過程依賴圖組成的[5]；圖中左側部分是三角形問題構件的構件節點，該節點中的S1、S2和S3分別代表了構件中的三個狀態：bTriangle、 bRight和tType。由于三個接口函數的輸入參數都是三個整形變量，因此，為了便于觀察，在具體作圖的過程中將輸入參數a、b、c三個節點視為一個節點。

建立構件系統的功能依賴圖后，就可以運用切片技術對其進行切片。在基于模型檢驗技術的變異測試方法的測試用例的生成過程中，是通過引入斷言違背機制將原有模型和變異模型結合并對構件的狀態進行判定從而誘發錯誤生成并得到反例路徑。因此，為了能夠找到導致這個斷言違背所產生錯誤的原因，就必須找到在這個斷言違背之前，系統模型中哪些語句或者是哪個謂詞表達式影響了所關注的這個斷言違背，并且它們是如何傳播到這個地方。這樣在對功能依賴圖進行切片時，就可以采用文獻[6]中所提出的后向切片準則和兩步圖的可達性算法對構件系統的功能依賴圖進行切片。

2 實驗結果和分析

2.1 實驗對象說明及實驗結果

本節以三角形問題構件中反應三角形類型的狀態“tType”作為興趣點，對其構件系統的功能依賴圖進行切片試驗。圖4所得到的即為切片后的三角形問題構件系統的功能依賴圖。

在利用基于模型檢驗的接口變異測試方法對構件系統進行驗證并生成測試用例時，為了能夠體現出構件系統模型中存在的“狀態空間爆炸”問題以及通過切片技術對系統的狀態空間進行壓縮后的效果，首先選擇三角形問題構件的接口函數TriType（int a， int b， int c）的等價變異體TriType（int c， int b， int a）作為研究對象，并將三邊的輸入域劃分為5組進行對比分析。

表2給出了在上述實驗條件下，JPF對切片前后的構件系統在模型驗證后所得到的狀態數，它是由JPF統計信息中“state”里面的“new”與“visited”相加所得到的。

對表2進行分析可知：

首先，除去最后一行對壓縮率的分析外，表格中的每一行都反應出隨著三角形三邊輸入域的增加，整個模型檢驗過程所耗費的時間以及在驗證過程中所產生的狀態數都在以指數形式增加，這就體現了在本章最開始所提到的“狀態空間爆炸”問題。

其次，表格中的每一列說明了在對構件接口調用關系模型運用切片技術后，模型檢驗工具在驗證過程中所耗費的時間有了一定的減少，而且在整個驗證過程中系統模型所產生的狀態空間的數量也得到了壓縮，模型檢驗的驗證效率得到了提高。

再次，由于上述五組實驗只改變了三角形問題構件的輸入域，對于構件系統模型本身并沒有進行改變，因此，在使用相同的切片準則并運用切片技術對構件系統的功能依賴圖進行切片后，所得到的系統模型的狀態空間壓縮率在效果上基本是相同的。

最后。上述五組實驗的驗證結果都沒有檢驗出任何反例路徑，因此，切片技術的運用并不會影響“基于模型檢驗技術的接口變異測試方法”對等價變異體的正確判定。

2.2 統計分析

在上一小節中，通過利用JPF對同一個等價變異體TriType（int c， int b， int a）的五組不同輸入域的檢驗，說明了運用切片技術對構件系統中單個接口函數的等價變異體進行壓縮后，依然能夠通過“基于模型檢驗技術的接口變異測試方法”對等價變異體進行有效地判定。但是，當同一個構件中所有不同的接口函數在分別運用切片技術對構件系統模型進行壓縮后，上述實驗結果并不能夠說明切片技術對整個構件系統的驗證以及對接口測試用例生成所產生的影響。因此，本小節將就這一問題作進一步的討論。

這里，分別以三角形問題構件中的三個狀態屬性作為興趣點對構件系統進行切片，然后三個接口函數的非等價變異體對切片后的構件系統模型進行變異并驗證。表4給出了三個接口函數在切片前后進行變異并生成測試用例的相關驗證信息，為了能夠達到對系統模型狀態空間進行窮盡搜索以及對非等價變異體生成所有測試用例的目的，這里將JPF中的搜索配置策略設置為“搜索顯示多條反例路徑”。同樣地，表3所產生的狀態數也是由統計信息“states”中“new”與“visited”相加得到的。

通過對表3可以發現：

首先，對于每一個需要驗證的系統模型來說，在運用切片技術對系統模型進行切片之后，都能夠達到壓縮系統模型狀態空間數量，并提高驗證效率的目的。

其次，表中的數據以及實際的實驗結果說明，切片后的系統模型在驗證后所產生的反例路徑與切片之前所產生的反例路徑是相同的，因此，切片前后所產生的測試用例也是一樣的。

最后，盡管切片技術是對構件系統的功能依賴圖進行切片，但其實質上是對構件系統的狀態空間進行縮減。由于三角形構件系統中僅由一個三角形構件組成，因此其狀態空間是由三邊的輸入域所確定，這樣，表中三組實驗所對應的切片前的構件系統模型在驗證后所產生的狀態空間總數是一樣的；同時，對于每一個切片后的構件系統模型來說，其狀態空間是由三角形構件中的一個狀態所決定的，而該狀態又是由相同的輸入域確定，因此在切片后，構件系統模型的狀態空間總數也是一樣的。綜上所述，三組實驗的狀態空間壓縮率也是相同的。

3 結束語

目前，基于模型檢驗的測試用例生成技術作為一種新興的軟件測試方法已經得到了測試人員的廣泛關注，但是由于模型檢驗技術中所存在的“狀態空間爆炸”問題會使得驗證的效率較為低下，因此，本文主要講解了運用切片技術對系統模型進行切片從而達到壓縮系統模型狀態空間，并提高驗證效率的目的。

本文以構件之間接口的交互關系為基礎，通過擴展構件之間接互圖后，提出了一種建立構件系統的功能依賴圖的具體方法，然后運用切片算法實現了對其進行切片的目標。最后，本文通過基于模型檢驗的接口變異測試方法對三角形問題的JavaBean構件的實驗說明：在運用切片技術對系統模型進行切片以后，達到了有效壓縮系統狀態空間數量并提高驗證效率的目的，同時，不但可以對等價變異體模型進行正確地判定，而且對于非等價變異體模型來說還可以正確地生成測試用例。

參考文獻：

[1] 林惠民， 張文輝. 模型檢測：理論，言方法與應用[J]. 電子學報， 2002， 30（12A）： 1907-1912.

[2] 梁陳良， 聶長海， 徐寶文， 陳振宇. 一種基于模型檢驗的類測試用例生成方法[J]. 東南大學學報（自然科學版）， 2007， 37（5）： 776-781.

[3] W. Visser， C. Pasareanu， S. Khurshid. Test Input Generation with Java PathFinder[C]. Proceedings of ISSTA 2004， New York： ACM Press， July 2004， 97-107.

[4] 李必信. 程序切片技術及其應用[M]. 北京： 科學出版社， 2006： 3.

[5] 張K， 王[， 韓柯， 歐陽志強. 面向構件接口變異的模型檢驗技術研究[J]. 電腦知識與技術， 2010（6）： 1954-1956.

[6] Horwitz S B， et al. Interprocedural slicing using dependence graphs[J]. ACM Transactions on Programming Languages and Systems， 1990， 12（1）：26-60.

篇(2)

關鍵詞：CBI聯鎖，OCS950系統，一致性測試

中圖分類號：U231+.3 文獻標識碼：A

天津地鐵2、3號線信號系統由通號集團總包，龐巴迪作為主要技術分包商，實現了一套完整的CITYFLO650基于無線通信技術的移動閉塞系統。其中，聯鎖系統作為最核心最基礎的系統，使用龐巴迪EBILock 950 CBI聯鎖與OCS950目標控制器系統[1]。由于地鐵2、3號線工期緊湊，給予信號系統安裝調試期短，聯鎖調試顯得尤為緊湊和重要。

1 聯鎖調試前的準備工作

（1）線纜絕緣測試

線纜絕緣測試主要包括：電源屏所有輸出供電配線、組合柜到分線柜配線、分線柜至各控制單元配線、以及目標控制器（OBC機柜）到組合柜的配線等。測試要求依次完成各單元每一根線纜的線纜電阻、線間絕緣及線纜對地絕緣的測試。

（2）上電測試

天津地鐵2、3號線采用綜合UPS供電技術。對于OCS950系統OBC機柜，各模塊供電后需要用安裝有WinOC test 軟件（龐巴迪系統專用）的測試筆記本（設置IP地址為 172.21.0.3）通過網線連接至OBC機柜CCME通信板，以觀察各OC板的工作狀態是否正常，確認所有供電單元上電正常[2]。

2 聯鎖測試流程及方法

聯鎖系統測試包括點對點的測試、軌旁信號設備單體調試、聯鎖室內外一致性測試三大部分。

2.1 點對點測試

點對點測試是為了確定目標控制器與組合繼電器的一一對應關系是否正確，驗證目標控制器驅動與采集是否正確。

點對點測試時連接測試筆記本（安裝有WinOC test 軟件）到目標控制柜，通過軟件下發驅動信號，同時確認能夠通過軟件觀察到采集狀態的變化。使用DC24V電源端子線，根據各個組合采集電路圖及配線圖依次將需要測試的繼電器驅起和驅落，觀察測試筆記本軟件內采集狀態的變化是否正常。

2.2 軌旁單體測試

（1）信號機測試

信號機單體調試是使用點對點測試軟件完成目標控制器對信號機單體設備點對點控制的調試，其中包括信號顯示控制調試；信號機單體輸入輸出電壓、電流測試；

① 連接測試筆記本到目標控制柜，通過點對點測試軟件完成對信號機紅（R）、綠（G）、黃（Y）、紅黃（RY）、M紅（MR）顯示的驅動，并測量其對應信號顯示的一次側電壓電流、二次側電壓、及二次側設定電壓值，保證其測量值在系統設計確定的范圍內并盡可能趨于范圍的中間值。

② 各信號顯示電流測量范圍如下(參考龐巴迪系統)：

當紅黃同時點亮時,紅燈和黃燈顯示信號電流也要保持在上述范圍內。

③ 2、3號線信號機的燈絲報警采用兩級報警機制。燈絲報警儀檢測作為一級報警，OCS內部板卡檢測作為二級報警（降級報警）。對信號機進行降級測試，確定綠燈顯示能降級為紅燈，黃燈顯示能降級為紅燈，紅黃顯示能降級為紅燈，M紅燈降級為紅燈，紅燈降級后為滅燈狀態。其一級報警設置原則為：M紅燈LED燈短2束報警，其他顏色燈位LED燈斷4束報警；二級報警設置原則為：黃燈降級報警電流下限為98mA，紅燈降級報警電流下限為98mA，綠燈降級報警電流下限為100mA，M紅燈降級報警電流下限為110 mA。

（2）轉轍機測試

轉轍機測試的目的是通過點對點測試軟件完成目標控制器對轉轍機單體設備點對點控制的測試，其中包括轉轍機的定操、反操、定表、反表、失表示、轉轍機動作電流、動作電壓、動作時間、摩擦電流、摩擦電壓及四開狀態下的動作時間、4mm轉轍機不鎖閉失表示、2mm轉轍機鎖閉有表示等參數。

① 連接測試筆記本到目標控制柜，給轉轍機設備上電，通過點對點測試軟件對轉轍機執行定操和反操命令確定轉轍機動作方向是否正確，動作到位后定位和反位表示是否正確。

② 測量轉轍機所有需要測量的參數如下：

道岔正常動作時：

動作電壓380V±10%；

動作電流

道岔處于四開狀態時：

動作電壓380V±10%；

動作電流

動作時間

轉轍機斷表示測試；轉轍機斷遮斷器測試；

道岔岔尖2mm鎖閉、4mm不鎖閉測試。

（3）PSD（屏蔽門）接口測試

PSD接口測試的目的是為了完成信號系統與屏蔽門系統的硬件接口的測試（如果測試過程中PSD不具備聯機條件，本測試可使用封線假條件），為聯調聯試做準備[3]。

①將屏蔽門全部關閉，確認門控柜門關繼電器吸起。在屏蔽門PSL盒激活互鎖解除，確認門控柜門旁路繼電器吸起，互鎖解除恢復時確認門旁路繼電器落下。在屏蔽門PSL盒激活本地控制，確認PLC采集到本地控制信號，本地控制恢復時確認PLC采集到的信號消失。

② 在門控柜激活開門信號和關門信號，確認屏蔽門相應的開起和關閉。

③ PSD測試中如果測試的是非集中站，同時需要集中站測試人員確認所測試的非集中站在集中站對應的復視繼電器狀態與非集中站是否一致。

（4）PEP（緊急停車按鈕）接口測試

PEP接口測試是為了完成信號系統緊急停車控制功能的測試。測試中將站臺和車控室所有緊急停車按鈕恢復，由集中站測試人員確認對應的緊急停車繼電器吸起，當按鈕被按下時繼電器落下，依次激活和恢復每一個緊急停車按鈕，確認集中站繼電器狀態正確。

2.3 聯鎖室內外一致性測試

聯鎖室內外一致性測試是通過ATS軟件完成ATS工作站站場表示及操作與室外軌旁設備的一致性測試[4]。

① 通過ATS工作站排列進路，開放每一架信號機的每個燈位顯示，室內外人員一起校驗實際與顯示一致性，并通過聯鎖維護終端查看對應的參數是否正確。由室外人員設置信號機斷束報警和斷絲報警，然后通過燈絲報警儀設置各個信號機報警電流的上門限值和下門限值，同時確定ATS會有對應的報警顯示。

② 通過ATS軟件對轉轍機進行定操和反操操作，室內外人員一起校驗實際與顯示一致性，并通過聯鎖維護終端查看對應的參數是否正確。然后由室外人員對轉轍機斷表示、斷遮斷器，確定ATS和聯鎖維護終端會有相應的報警顯示，并且斷遮斷器時轉轍機不能動作成功。

③ 軌旁人員對PSD進行開關門、互鎖解除操作，確定屏蔽門狀態和ATS、維護終端顯示一致。

④ 軌旁人員對站臺所有PEP按鈕及車控制PEP按鈕進行激活，取消激活操作，確定PEP激活狀態和ATS、維護終端顯示一致。

3 結束語

聯鎖系統調試是地鐵信號系統建設開通的重要環節，聯鎖控制是關乎地鐵安全運營的核心重點。本文介紹了整個聯鎖系統硬件控制部分的調試流程及方法，筆者根據實際經驗概述了天津地鐵2、3號線聯鎖系統調試的實現過程。

參考文獻

[1] 天津地鐵2號線 工程信號系統詳細設計文件.第二冊2010.10.

[2] 天津地鐵 2&3 號線EBI Lock 950 系統接口.2012.2.

[3] 天津地鐵 2&3 號線軌旁ATC系統．2012.1.

篇(3)

關鍵詞：DSP；匯編語言；測試

中圖分類號：TP313文獻標識碼：A文章編號：1009-3044(2008)23-963-02

DSP Assembly Language Software Testing Method

HU Qing-xia, LIU Qing-feng

(91413 Units, Qinhuangdao 066001,China)

Abstract: The in-depth analysis of the DSP assembly language software testing difficult, given the DSP assembly language software testing strategy, the DSP assembly language software is an important test of significance.

Key words: DSP; assembly language; test

1 引言

目前，DSP硬件系統已具有了很高的可靠性，但其軟件系統，特別是用匯編語言設計編寫的較為復雜的軟件系統，可靠性總是難以得到保證，更是缺少完整的質量保證和評估體系，這已經成為DSP應用方面亟待解決的一個問題。對DSP匯編語言軟件的測試與一般的軟件測試不同，其自身的特點決定了測試面臨的困難。本文首先對其測試難點進行分析，然后給出了DSP匯編語言軟件的測試方法。

2 DSP匯編語言軟件環境的復雜性分析

2.1 與硬件結合緊密，測試環境難以搭建和選擇

匯編語言的程序是燒制到DSP芯片中運行的，DSP芯片種類繁多。這些芯片的外部管腳、內部存儲器分配都各不相同 。在搭建宿主機測試環境時必須選擇各種不同的相對應的芯片，然后配合仿真器與宿主機連接。這些硬件的配置本身就增加了測試難度，然而這些仿真環境總是和目標環境之間有著不小的差異,比如目標環境的中斷難于模擬等?；谀繕说臏y試消耗較多的經費和時間，而基于宿主的測試代價較小，但畢竟是在模擬環境中進行的。目前的趨勢是把更多的測試轉移到宿主環境中進行，但是，目標環境的復雜性和獨特性不可能完全模擬。

2.2 I/O通道少，測試數據獲取比較困難

在DSP匯編語言軟件的測試中給主機上載測試數據是很困難的。目前主要是基于以下3 種方式：1）實際的物理通道；2）開發工具IDE的虛擬IO功能；3）直接讀取內存區數據。第一種方式就是目標機和主機之間具備物理的通信方式，比如以太網、串口、并口、USB等。這種方式要求系統必須具備這種通信方式和通信軟件，一般只適用于系統級的測試。第二種方式是借助開發工具，比如TI CCS，這種方式調試較為復雜也容易出錯。第三種方式則是需要占用較多的內存資源。

2.3 實時性要求較強

DSP軟件一般都用作控制系統的內核，所以有很高的實時性要求，而實時性的測試是一般的測試方法和測試工具都難以實現的。

2.4缺少相應測試工具

匯編語言結構和語法都比較繁瑣和冗長，這首先使測試人員理解程序變得困難，又因為DSP芯片的多樣性，使得開發針對DSP匯編語言軟件的通用測試工具幾乎是不可能的。因此，在測試時，只能夠使用一些測試工具（比如覆蓋率分析工具等），而把測試的重點放在人工的代碼審查上面，這就要求測試人員要很熟悉相應芯片的用法并且還要與開發人員充分的溝通。

3 DSP匯編語言軟件的測試策略

DSP匯編語言軟件是最難測試的軟件之一，必須制定有效的測試策略。在搭建測試環境時，要尋求宿主機與目標機之間的平衡，即要對目標環境和宿主環境的測試內容有所選擇，在宿主環境中，可以進行邏輯或界面的測試、以及與硬件無關的測試。在模擬或宿主環境中的測試消耗時間通常相對較少，用調試工具可以更快地完成調試和測試任務。而中斷測試、硬件接口測試、系統集成測試等必須要在目標環境中進行。而在測試環境搭建完成之后，考慮到重要性以及測試執行先后順序，把整個測試依次分為以下幾個不同階段。

1）代碼審查階段。對于DSP匯編語言軟件，代碼審查是整個測試的重點，要占到整個測試周期的60%。同時，代碼審查又是功能測試編寫測試用例之前的必要步驟。代碼審查最好是在開發環境中通過硬件仿真進行。

2）功能測試階段。在功能測試階段，采用功能分解法、等價類劃分和猜錯法等方法，根據軟件需求規格說明中所規定的軟件正式合格項設計并執行測試用例，以驗證其功能是否滿足需求規格說明的要求，并對其功能的適合性和準確性進行驗證。對于DSP匯編語言軟件系統，功能測試必須首先進行模塊化處理，分離出每個模塊的輸入輸出。

在設計功能測試用例時，也包括對邊界值的測試，即對輸入域(或輸出域)的臨界狀態、數據結構、狀態轉換、功能界限等的邊界或端點情況下的運行狀態的測試。此外，設計功能測試用例時運用覆蓋測試工具輔助測試用例的設計，以達到功能測試的充分性。

3）性能測試階段。在DSP軟件系統中，程序的性能是非常重要的，要嚴格根據需求中對負載、定時、性能的要求，判斷軟件是否滿足這些需求規范。在使用環境中，軟件的失效過程要平穩（電機運動慣性問題），所以，不僅要檢查軟件工作過程，也要檢查軟件失效過程。

可以使用測試工具CODETEST主要對DSP下行的伺服驅動器控制軟件中有時間要求和數據處理精度要求的軟件合格性項進行測試，并把重點放在測試其實際時間特性與實際數據處理精度上。時間特性主要包括以下幾個：中斷延遲時間、任務上下文切換時間、任務響應時間、任務創建/刪除時間、交替信號量時間、取得/釋放信號量時間、交替消息隊列傳輸時間。

4）接口測試階段。為了保證正確地測試，還須要檢驗軟硬件之間的接口。對接口的測試主要利用各種不同類型接口的監視工具。比如對TMS320LF2407板匯編軟件串口測試，可以使用串口監控器EtherPeek.NX，人工設置各軟件從RS232串口接收的輸入/輸出，驗證各軟件對輸入/輸出的反應，并監控其輸入/輸出內容的格式與數據位是否與接口規范一致，驗證各接口的正確性和一致性。

5）結構覆蓋測試階段。使用測試工具LDRA TestBed對被測軟件程序進行插裝。插裝可以是在測試環境中嵌入硬件，也可以是在可執行代碼中加入軟件，也可以是二者相結合?；跍y試用例，執行插裝后的程序，提取語句/跳轉覆蓋信息，將程序的執行表現與編碼意圖進行比較，衡量軟件測試工作的充分性。代碼覆蓋分析工具可能侵入代碼的執行，影響實時代碼的運行過程?；谟布拇a覆蓋分析工具的侵入程度要小一些，但是價格一般比較昂貴，而且限制被測代碼的數量。

6）強度測試階段。在模擬環境下，打開被測軟件全部數據采集與數據通信通道，運行全部模擬外設，長時間運行功能測試和接口測試等相關測試用例，檢測交流伺服驅動器控制軟件在設計能力下的運行情況。

7 ）安全性測試階段。采用人工測試的方法對被測軟件進行安全性測試。檢測用戶是否能對被測軟件進行災難性操作，被測軟件是否具有關鍵操作的安全性保護等功能。對于電機控制系統的DSP軟件，主要檢查過壓、過流、低壓、低流、斷電、異常復位等災難性操作。

8）可恢復性測試階段。采用人工測試的方法對被測軟件進行可恢復性測試。用人工干預的手段模擬硬件故障、鏈路故障、電源故障等，故意造成系統出現異常，并由此檢查被測軟件是否具有錯誤探測功能，在故障發生時能否保護正在運行的作業和系統狀態。并檢測被測軟件在重啟之后能否正常地繼續進行工作，并不對系統造成損害。

9）回歸測試階段。對于在測試過程中發現的問題，開發方應及時對其進行修正。修正后由測試方通過回歸測試進行確認?；貧w測試必須將所有功能測試、接口測試等測試用例重新執行一遍，以驗證所有問題已經全部解決，并且沒有引入新的問題。

4 結論

此方法研究在一定程度上減輕了DSP匯編語言軟件的測試難點，對以后的測試實踐有重要的參考意義。此策略的充分性和自動化程度是今后工作和研究的方向。

參考文獻：

[1] 鄭人杰.計算機軟件測試技術[M].北京:清華大學出版社,1992.

篇(4)

關鍵詞：物聯網云計算平臺；測評體系

中圖分類號：F426.6

以云計算、物聯網、下一代互聯網為代表的新一輪信息技術革命，正在成為各國社會和經濟發展共同關注的重點，當然，質量是其核心的競爭力。因此物聯網云計算平臺的測試策略的研究具有極其重要的意義。

1 物聯網云計算平臺的發展現狀

物聯網云計算平臺是一種IT資源的集中管理與動態分配模式，即將各種IT基礎設施集中到一個資源池中，并以按需服務的方式提供給終端用戶，用戶只需要一個簡單PC或接入客戶端（如Web），來獲取云計算體系分配的資源或應用服務―――可能是一個虛擬的PC（遠程桌面）或某個Web應用（Mail）。物聯網通過物體與網絡的統一，實現物體網絡化。物聯網云計算平臺根據用戶需求給用戶分配資源，用戶使用完成后，云管理又可以將其收回，重新放入到資源池中。

2 基于物聯網云計算平臺的軟件測試注意事項

2.1 員工的專業知識應扎實

物聯網云計算系統是新一代信息發展的重要體現，員工尤其應該與時俱進，深入了解物聯網云計算平臺的運作機理與自身的業務流程，熟練地掌控物聯網云計算平臺在運作中與自己業務的對應關系。使得這樣的高科技平臺能夠嫻熟地受到人為的操作。只有這樣才能讓平臺進行高效的測試和執行。

2.2 降低測試對生產環境帶來的風險

物聯網云計算平臺不同于傳統的測試，只能通過現實的生產環境來進行測試。這樣的特性，加大了測試的風險。因此，作為專業的測試人員應該要好好利用其它手段來有意識的規避這方面的問題。

2.3 對物聯網云計算平臺的性能測試重點關注

測試的目的是來驗證物聯網云計算平臺在承擔各種負載的情況時表現出來的服務性能。我們通過使用不同的測試用例、場景以及模擬邊界、壓力測試來測試相關性能。隨著不斷的使用，整個過程會消耗平臺的運行能效。系統重新部署運作時，虛擬機的性能和效率也會打折扣。所有的這些結果導致測試人員必須采取合理的場景與腳本進行有效的測試。

2.4 對安全性、可靠性的測試加以關注

關于物聯網云計算平臺安全可靠性測試目前主要采用評估的方式，其過程是通過物聯網云計算平臺模型得到相關的安全可靠模型，通過模型分析對建立的安全可靠性進行直接評估。測試人員通過測試評估過程中產生的數據以及其他的測試評估結果進行全面統一的分析比較計算，構成關于物聯網云計算平臺的安全可靠性評價。對于測試的關注度還應考慮到物聯網云計算平臺的兼容性、容錯性和可恢復性。

3 面向物聯網云計算平臺的質量測評體系的建立

質量測評體系對于一個組織系統或是一個產業的可持續發展具有很重大的作用。隨著網絡技術的發展，互聯網技術的浪潮，以及各種新科技的發展，物聯網云計算平臺正在繼續走向成熟，以物聯網云計算平臺為中心的時代即將到來。這就更需要質量測評體系的重度把關。質量，就是某種產品對需求的滿足程度和特征的總和。面向物聯網云計算平臺的質量測評體系，決定了物聯網的發展前途。

3.1 質量測評體系的認識

通過從基礎的網絡設備的建設，逐步推進，不斷提高信息技術含量，從而帶動國家的各方面發展，強化產業優勢和國家競爭力；通過在人民大眾的生活區域內建立職能網絡，讓大眾隨時的感受科技智慧的服務。根據物聯網云計算平臺管理運行機制的本質特點和目標，面向物聯網云計算平臺的質量測量體系指標應該當從整體質量評價的效果上來進行，從整體的角度實現物聯網質量的提高，而不能只是看重某一個環節對現有的情況的影響。

隨著物聯網技術的發展，為了更加合理地顯示出質量問題，就應該要考慮建立和其相對應的質量測評體系，并根據所建立的這個質量測評體系，對物聯網進行評定。這個體系的指標有其自身的特點，其內容相比其他評價指標體系更為寬廣。

為了建立有效的質量測評體系，應該參照以下幾個原則。第一，要顯出重點，對關鍵的影響因素要進行著重研究。第二，要采用能反映物聯網運行流程的指標體系。第三，采用的指標體系不僅僅是反映物聯網的某個點的情況，而是要考慮到全局。第四，要做到實時分析，實時評價，并作出相對應的方案條例。

3.2 面向物聯網的質量測評體系的建立

質量測評體系的建立應該從以下三個方面入手：第一，確定測評原則，制定評定計劃；第二，建立測評體系，開始測評工作；第三，質量綜合評價，開展質量跟蹤，提高質量。必須對物聯網的質量進行測評，這樣才能發現其不足，以完善其缺點來提高其服務質量。但是在研究具體的方法之前我們需要了解測評體系該如何建立，測評體系的特點。

確立測評體系的構建思路首先有利于我們可以迅速抓住體系構建的重點，并能順清思路，根據物聯網服務的特征，我們應該在面向物聯網的質量測評體系的構建中遵循以下思想。

第一，重視信息共享，物聯網的運行和市場都靠信息的共享，大量真實的信息，是這一個體系的核心。第二，選取關鍵性指標。物聯網涉及的領域廣，信息量大，如果從一個個普通的指標入手，不僅成本太大，而且不能發現影響其質量的關鍵性因素。第三，層次化。這樣各個不同的指標就有可比性，能夠產生有效的決策支撐，是一種重要的分析方法。第四，區分不同領域。物聯網的領域廣，不同的領域有不同的運轉方式，因此要采用不同的測評指標。

4 物聯網云計算平臺的測試策略

4.1 熟悉物聯網云計算平臺的測試技術及測試需求

物聯網云計算平臺測試是一個復雜新型技術，這就需要相應的測試工程師對物聯網云計算平臺有著深刻的理解。比如像海量數據的管理、物聯網云計算平臺自身的管理以及資源調度、分布式的編程模式、虛擬化技術、存儲模式等。工程師如果能對這些相關技術有著熟練的駕馭能力，那么才能精確地對物聯網云計算平臺測試的缺陷、漏洞和風險產生判斷。

4.2 物聯網云計算平臺真實環境下的部署與測試

應用軟件的測試必須是在真實環境下進行的測試。一般為了公司業務的正常運行，會部署出兩套應用服務器便于測試和正式上線。并且讓所有的軟件在物聯網云計算平臺的基礎上同步運行，這樣才能保證測試環境的真實有效。

4.3 物聯網云計算平臺的其他物理接口測試

門戶之類的其他系統運行在另外的物理服務器上，與管理系統運行在不同的兩個系統中，這樣使得接口測試非常重要。接口測試通常會選擇標準Web服務測試。通過XML、SOAP、WSDL等一系列專業的服務測試，來測試它是不是合格。當完成接口測試的時候，同時也完成了物聯網云計算平臺的標準符合性測試。

4.4 對平臺的安全性測試

不管是什么軟件，關于軟件的安全性考慮都是重點，像物聯網云計算平臺這么龐大的軟件系統更是如此。如果系統本身安全性較低的話，單靠外部防護也無濟于事。

4.5 對平臺的兼容性測試

可以直接用不同的Windows操作系統來達到預想的目的，從而輕松完成系統的訪問，并十分便捷地實現兼容性測試問題。

4.6 對平臺的容錯性能與可恢復性能的測試

檢驗一個系統的容錯能力主要是看容錯和可恢復性測試。根據測試結果便可對系統的容錯性能有一定了解。主要針對物聯網云計算平臺故障和恢復測試、客服端的故障以及虛擬機的遷移等。

5 結束語

如今，物聯網云計算平臺作為新一代信息時代的代表早已到來。面向新一代信息技術應用的測評體系與測試策略的建立，一方面幫助中小企業交付高質量、高可靠的產品和系統；另一方面，推動中國高技術產業的發展，同時也對自己企業模式的轉型和創新以及高效運營提供了先機。

參考文獻：

[1]章澤昂，鄔家煒.基于云計算的教育信息化平臺的研究[J].中國遠程教育，2010（06）.

[2]錢文靜，鄧仲華.云計算與信息資源共享管理[J].圖書與情報，2009（04）.

[3]曹麗，姜毅，甘春梅，張一弛，陳桂強.云計算軟件測試平臺的構建[J].現代圖書情報技術，2012（11）.

作者簡介：劉雪（1981-），女，西安人，西安科技產業發展中心工程師，碩士，研究方向：質量管理及產業研究；王文斌（1972-），男，西安人，西安科技產業發展中心，高級工程師，博士，研究方向：產業研究。

篇(5)

1、引言

隨著科學技術的進步及數字通信技術的不斷發展，用戶通信中越來越關注數據通信的安全性保密性。電話作為人們日常生活中的通信工具，除語音通話外，被廣泛用來傳真、上網及電話會議等，其數據傳輸的安全性和保密性越來越受到重視。偶爾的一點消息的外漏，都會引發公司巨大的經濟損失。

普通電話線路接口為模擬接口，線路測試儀與交換機問的用戶線路上傳輸的是話音模擬信號，頻率較低（頻率范圍大致為300-3400Hz）。然而有些電話線路接口卻為數字接口，此類接口雖然也使用普通的電話線，但用戶線路上是將高速數字信號通過基帶或幅頻調制進行傳輸，頻率較高（頻率范圍大致為16K-250KHz，如某軍工用XXX話機）。目前，相關的線路測試設備不斷涌現和換代，普通的電話線路測試儀僅適用于對普通電話業務的線路質量進行全程或區域測量，而對于上述數字類的接口線路，目前的普通線路測試儀就不能滿足要求。專用的數字接口測試儀體積較大，不適于用戶現場使用，而且測試程序繁瑣價格昂貴。因此，本文提出了一種既適應模擬用戶接口又適應數字用戶接口的電話線路測試儀方法。

2、測試儀硬件結構

測試儀由單片機、FPGAI、LCD、時鐘芯片、存儲器芯片、Modem芯片1、Modem芯片2、保持電路等組成。測試儀采用單片機與FPGA作為其核心控制電路；存儲芯片提供實時保存測試數據的功能；時鐘芯片為測試儀提供測試時間；液晶顯示用于顯示測試的信息等；鍵盤來選擇測試項目和查看測試信息等從而實現人機互動；串口芯片可與電腦通過串口線連接，從而把測試數據傳送給上位機軟件；配置ROM用來配置FPGA～E作；當電話線路接通后保持電路能夠保持測試儀連接到電話線路上電話線路保持通路狀態。系統的硬件結構如圖1所示。

3、測試儀的測試功能

本測試儀能夠實現模擬接口和數字接口的電話線路測試。其基本實現原理為Modem芯片1為低速調制解調芯片，主要實現模擬接口的電話線路測試；Modem芯片2為高速調制解調芯片，實現數字接口的電話線路測試。通過鍵盤選擇相應的測試速率，單片機響應鍵盤操作并發送相應指令到FPGA，FPGA解析接收到的單片機指令通過控制Modem芯片1的工作來測試低速模擬接口線路或控制Modem芯片2來測試高速數字接口線路。

測試儀需要實現的測試功能有幅頻衰耗測試、誤碼測試、相位抖動測試、串擾測試、信令測試和自檢。

4、測試儀系統工作簡介

測試儀是整個測試系統的核心，測試時測試系統由測試儀主機和測試儀從機兩部測試儀配合使用。其測試連接圖如圖2所示。此種連接方式能夠測試的功能有幅頻衰減測試、誤碼測試、相位抖動測試、串擾測試及信令測試。

測試的基本方法為：預先撥號將電話接通，掛斷電話（測試儀通過內置保持電路使被測試線路保持通暢），選擇需要測試的功能，如幅頻衰耗測試、誤碼測試等并設置其測試參數。此時，測試儀主機發送測試命令，測試儀從機接收測試數據并分析測試結果。每隔1秒，測試儀從機將測試結果發送至測試儀主機，測試完成，測試儀從機發送測試完成命令至測試儀主機。測試結果可以直接通過RS323串口傳送到上位機，也可以保存測試結果待測試完成后利用上位機讀取測試結果。停止測試，電話線路恢復通話功能。

自檢測試為測試電話線路的各個組成部分是否連接正確，是測試儀工作是否正常的自我檢測，不需要連接任何設備，工作原理如圖3所示。

選擇自檢測試，并按0K鍵，單片機發送自檢測試命令至FPGA，Flea分別發送命令至Modem芯片1和Modem芯片2，Modem芯片將FPGA發送的命令直接反饋到FPGA，FPGA再將接收到的命令發送至單片機，單片機將自檢結果在液晶顯示器顯示。

為了測試儀使用靈活方便，本測試儀內部集成主、從兩套系統，即其既可以當主機使用也可以當從機使用。其主、從模式轉換原理圖如圖

4、所示

如圖4所示測試儀初始默認狀態為從機，只進行數據的接收與處理，當選擇要測試項目并按OK鍵后，測試儀從默認的從機狀態轉換為主機狀態，測試測試儀開始發送相應的測試數據。T秒后進行的測試項目完成，測試儀自動由主機狀態回復到默認的從機狀態。

5、測試儀系統測試結果

篇(6)

【關鍵詞】軟件測試；單元測試；用例；等價類

1.軟件測試

軟件測試是指利用相關測試工具，按照一定的測試方案和流程對軟件系統的功能和性能進行測試，對可能出現的問題進行分析、評估，發現開發錯誤并跟蹤，以確保所開發的軟件滿足用戶需求。軟件測試是保證軟件質量的主要手段，是根據軟件開發各階段的規則說明和程序內部結構而精心設計的一批測試用例，并利用這些測試用例運行程序以發現軟件是否存在錯誤的過程，軟件測試的范圍應當包括更廣泛些，除了考慮正確性外，還應關心程序的效率、健壯性等因素。

軟件測試過程包含單元測試、集成測試、確認測試和系統測試四個步驟：

（1）單元測試：對每一個程序單元進行獨立測試，檢查各程序模塊是否正確地實現了預定的功能。

（2）集成測試：把已通過測試的模塊組裝起來，對軟件體系構造的正確性進行測試。

（3）確認測試：檢查已完成的軟件系統是否已滿足了需求規格說明中的各項需求，軟件配置是否完全、正確。

（4）系統測試：將經過確認的軟件系統置入實際的運行環境中，與其它系統成份結合在一起進行測試。

2.單元測試

單元測試又稱模塊測試，是以軟件系統設計的最小單位——程序模塊為對象，進行正確性檢驗的測試工作。單元測試常被看作編碼的附屬品，在代碼被開發、編譯調試、審查后，單元測試用例設計便開始了。進行充分的單元測試，是提高軟件質量，降低研發成本的必由之路。幾乎所有的開發人員都會對每一段代碼做一定程度的單元測試。如果一個模塊要完成多項功能，可以將該模塊看成由幾個小程序組成，對每個小程序分別進行單元測試。如果是關鍵模塊，往往還要做性能測試。

單元測試以詳細設計說明書和源程序清單為依據，常采用白盒測試的用例，輔之以黑盒測試的用例，以尋找模塊內部可能存在的錯誤為目的，主要完成模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試等任務。

（1） 模塊接口測試

單元測試開始時，要對通過被測模塊的數據流進行測試。包括調用該模塊的輸入參數的正確性、調用其子模塊時提供參數的正確性、全局變量的定義在各模塊中是否一致等。

（2） 局部數據結構測試

包括數據類型的一致性、變量名、變量賦值、全局數據對模塊影響的正確性等檢驗。

（3） 路徑測試

對基本執行路徑和循環進行測試，查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。

（4） 錯誤處理測試

檢測對錯誤條件的響應是否正確，錯誤描述是否與實際的錯誤是否相符、是否能夠對錯誤定位、是否易于理解等。

（5） 邊界測試

通過設定邊界值檢測數據流、控制流中等于、大于或小于比較值時出錯的可能性。

在面向過程編程時代，單元測試所說的單元一般是指函數，而在面向對象編程時代，單元測試所說的單元一般是指類。以類作為測試單位，測試的復雜度相對較高，所以目前通常采用的辦法是為軟件開發建立對應的測試工程，為每個類建立對應的測試類，為每個函數建立測試函數測試結構化的局部代碼。

3.單元測試用例的設計

測試用例是指對某特定的軟件系統進行測試任務的描述，它體現了測試的方案、方法和技術，包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。

測試用例的設計也就是測試需求細化的過程，測試需求分析和測試用例設計是密不可分的，前者是后者的依據，后者是前者的體現。測試用例的設計應與復審相結合，根據相關設計信息設計測試數據，以增大發現錯誤的可能性。

單元測試用例可以選取正確輸入、邊緣數據和錯誤輸入作為測試數據。以系統用戶注冊模塊中出生年、月、日的設置為例，通過等價類劃分法設計測試用例。

在劃分等價類時，我們將其劃分為兩類：1、有效等價類：是指輸入完全滿足程序輸入的規范說明、合理的、有意義的輸入數據所構成的集合。利用有效等價類可以檢驗程序是否滿足規格說明書所規定的功能和性能。2、無效等價類：是指完全不滿足程序輸入的規格說明、不合理的、無意義的輸入數據所構成的集合。使用無效等價類可以檢驗程序的容錯性能。

篇(7)

1．1通信設備簡介

本通信設備由信息處理模塊、信號處理模塊、收發信道模塊及電源模塊組成。每個模塊具有獨立結構件，插入到整機機箱，模塊之間以高速接插件及射頻接口互聯，主要完成綜合信息處理，調制解調信號處理，收發變頻等功能。

1．2可測試性設計指導思想［4］

可測試性設計的主要內容是機內測試（BIT）設計和自動測試設備（ATE）設計。BIT是指系統或設備內部提供的檢測和隔離故障的自動測試能力，ATE則是指自動進行功能或性能參數測試、評價性能下降程度或隔離故障的設備［5］。BIT的主要功能是把設備故障隔離到外場可更換單元（LRU）或外場可更換模塊（LRM），ATE則進一步把LRU或LRM故障隔離到內場可更換單元（SRU）。產品的BIT設計和ATE設計應該從方案設計階段就予以考慮，并且與產品同步研制。圖1給出了測試性設計與設備方案設計的基本流程。

1．3BIT設計

作為一個整機設備，不僅要具備監控其內部各模板工作狀態的能力，同時也要具備監控整機整體功能、性能的能力，這些在BIT設計時都要考慮到。本通信設備信息處理模塊主要完成業務信息處理、數據組幀解幀、整機狀態監控等功能，信號處理模塊主要實現基帶信號調制解調、A／D及D／A轉換等功能，收發變頻模塊主要完成模擬信號上下變頻、自動增益控制、提供參考時鐘等功能，電源模塊給各個模塊提供直流穩壓電源。根據圖2所示的設備測試工作流程圖，將BIT設計分為加電BIT、周期BIT、維護BIT?，F在復雜數字系統的設計，有些數字芯片自身就具有狀態監控的能力，只需控制電路上報這些狀態即可。對于可編程邏輯器件（FPGA、CPLD等）和嵌入式微處理器（PowerPC、DSP等），可在程序設計時考慮加入多種監控手段，盡量把設備問題隔離到模塊級。

1）加電BIT：加電BIT是設備剛上電時對自身健康狀態進行檢測，設備還沒有進入正常工作狀態。對于本設備，各模塊分別將BIT信息上報信息處理模塊，信息處理模塊綜合后上報顯控終端。主要檢測的信號有：串行通信總線功能是否正常、電源模塊輸出是否正常、頻綜是否鎖定，系統時鐘是否正常，內部ROM、RAM是否正常，微處理器PowerPC、可編程邏輯器件FPGA、數字信號處理器DSP等主要數字器件狀態是否正常，微處理器中斷響應是否正常等。如果時間允許的話，3）中維護BIT的（1）～（3）也可在加電BIT時實現，通過判斷3種環路下接收機的鎖定狀態，實現對設備基本功能的快速檢測。2）周期BIT：周期BIT指的是設備周期檢查自身工作狀態，并不影響正常工作。主要有性能檢測和故障檢測。周期BIT不僅包括啟動BIT中與正常工作狀態不沖突的狀態檢測部分，還有對設備工作時的性能狀態監測，包括模塊工作溫度指示、發射狀態、接收機鎖定狀態、接收端BUFFER狀態、接收信號電平、接收信號信噪比（Eb／N0）、接收誤碼率及接收信號頻偏等。3）維護BIT：加電BIT和周期BIT只能檢測最基本的故障，當設備出現問題時往往需要維護BIT來進行故障檢測和隔離，這個是本設備BIT設計的重點內容。維護BIT時設備工作在測試模式，不正常工作。本設備維護BIT主要通過圖3所示的3條環路來實現，每個環路各有側重點，主要內容如下：

（1）數據接口自環：如圖3中的環路1所示，數據接口自環指的是顯控終端控制信息處理模塊將發送數據幀經過FIFO后的數據直接送到模塊接收端，此方法主要測試發送數據組幀是否正確，發送FIFO以及接收BUFFER的工作狀態是否正常，微處理器中斷響應是否正常等，用于驗證信息處理模塊的數字接口功能是否正常。

（2）中頻自環：圖3環路2所示，中頻自環指的是信號處理模塊輸出的中頻調制信號直接送到接收端進行解調，通過觀察接收鎖定情況，可判斷信號處理模塊工作是否正常。此外，運用此方法可測試信號處理的調制、解調性能指標。顯控終端控制信息處理模塊使用偽隨機碼（PN碼）填充數據幀，信號處理模塊調制產生中頻信號，接收端解調后將數據幀送回信息處理模塊進行比對，可用于測試信號處理模塊解調誤碼率，想辦法從發射端疊加噪聲，可同時測量解調門限及對應誤碼率，這個方法中頻自環由模擬域開關切換，無需改變外部電纜連接。

（3）射頻自環：如圖3環路3所示，射頻自環指的是收發信道的射頻輸出端直接送到射頻輸入端，通過觀察接收鎖定狀態，驗證收發信道模塊是否工作正常。具體過程為發射端信號處理模塊輸出的中頻信號經過收發信道模塊后上變頻到射頻，射頻信號在收發信道模塊內部送到接收端下變頻到中頻后送回信號處理模塊，同時驗證收發變頻模塊和信號處理模塊。此時仍可使用（2）中所介紹的誤碼率及解調門限測試方法，驗證經過信道后信號處理模塊的性能。一般在設計時，由于發射信號比較大，接收信號相對比較小，可通過將收發信道的發射端信號耦合出一路環回到接收端的方式，同樣采用模擬開關切換，無需改變外部電纜連接。

（4）單載波測試模式：此模式控制信號處理調制端發射未經調制的單載波，主要用于測試載波的相位噪聲，以及其他相關指標，如發射載波頻率準確度、雜波抑制，諧波抑制等。此外，該模式可用于測量接收端載噪比（C／N0），因為單載波調制功率和調制信號的通道功率相當，通過標定接收端載噪比可算出接收端的解調信噪比Eb／N0，對整個通信系統的鏈路狀況作出判斷。

（5）發射端1，0調制模式：該模式控制調制器輸出一個經過交替1，0，1，0序列調制后的載波，序列的符號速率為當前通信符號速率，這樣將會在距離載波頻率正負1／2符號速率的位置產生兩個離散頻譜，用于檢測調制器的載波抑制。如果調制方式是OQPSK，將會出現一個頻譜，適用于測量單邊帶載波抑制，對于確定調制器的幅度和相位準確度也非常有用。4）BIT信息管理：對于機載通信系統尤其是無人機系統，應該在設計時考慮將重要BIT信息下傳至地面處理中心便于綜合分析。一般應在系統中設置數據記錄裝置，記錄全機各設備在飛行過程中上報的各類BIT信息，作為事后分析的依據。本設備的BIT信息上傳給顯控終端后存儲在機載計算機的硬盤中。

1．4ATE設計

由于BIT設計受10％軟硬件增量限制［6］，不可能將故障完全隔離，也很難達到較高的故障隔離率要求，因此必須借助ATE來共同完成故障診斷和隔離。ATE的出發點是在BIT將故障定位在LRU后，進一步將故障定位到SRU以及LRM。隨著數字電子技術的不斷進步，ATE向著通用化、小型化、標準化方向發展［7］。對于實際應用，ATE的這種設計要求是矛盾的，既要通用化又要小型化，最終只能折中考慮。本設備沒有設計專用的整機ATE設備，而是設計了一個整機接口測試板和各個模塊的離線測試夾具，相當于ATE的作用，分別用于原位測試和離線測試。1）原位測試：對于實際應用中，在某些情況下需要在問題出現時在線對故障進行定位，特別是對本電子通信設備，要完成相對復雜的綜合信息處理、協議處理、調制解調信號處理，各個模塊間存在較多交互，這樣給離線檢測帶來較大困難。針對這種情況，本設備在設計時在機箱外面預留一個測試口，這個測試口為一個多芯接插件，將設備內部FPGA及DSP的JTAG下載調試口、PowerPC的網口及調試串口、模塊內部的主要監控信號引出來，在出現問題時可原位在線測試，適用于設備的調試測試、綜合故障分析以及程序升級。這個測試口引出后連接到接口測試板，測試板上集成上述各種測試口及主要監控信號，方便在不開設備機箱的情況下在線對設備故障進行檢測和隔離。2）離線測試：問題隔離到一個單獨模塊后，為了進一步分析隔離故障，需要做一個針對單板測試的ATE。本設備各模塊均做了一個專用測試模塊，這個測試模塊根據待測模塊的內部軟硬件架構、結構進行測試性設計，簡稱測試夾具。夾具實際也是一個PCB板卡，通過接插件和待測模塊相連，完成待測模塊的單板加電、單板測試驗收及故障定位。這個測試夾具可模擬互聯的其他模塊的測試激勵信號和響應信號，實現脫離儀器的單板全功能、性能測試。ATE作為對模塊的測試分析與性能評估，其自身的狀態必須保證，應在實驗室用專業儀器對其狀態進行全方位測試與驗證，使其具有很高的可靠性，并應定期標校。

2測試結果

根據以上BIT和ATE設計對本通信設備進行了測試，部分測試結果如表1所示。

3結論