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

篇(1)

關(guān)鍵詞： 模型檢驗；接口變異；切片技術(shù)；功能依賴圖

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：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

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

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

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

1 構(gòu)件系統(tǒng)的功能依賴圖

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

1.1 功能依賴圖的組成

本文以該被測試構(gòu)件的接口規(guī)約說明為依據(jù)，通過測試驅(qū)動程序?qū)Ρ粶y試構(gòu)件，或者是將該被測試構(gòu)件和與之相關(guān)的構(gòu)件關(guān)聯(lián)后進(jìn)行建模，從而建立被測試構(gòu)件的接口調(diào)用關(guān)系模型。通過這個構(gòu)件系統(tǒng)的接口調(diào)用關(guān)系模型，被測試構(gòu)件所具備的相關(guān)功能會在利用模型檢驗技術(shù)進(jìn)行驗證的過程中表現(xiàn)出來。因此，將細(xì)化后的構(gòu)件之間的接互關(guān)系稱之為構(gòu)件系統(tǒng)的功能依賴圖（Function Dependence Graph，F(xiàn)DG），并且該圖是由測試驅(qū)動節(jié)點（Test Driver Node）和構(gòu)件節(jié)點（Component Node）兩種類型的節(jié)點所組成。

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

構(gòu)件節(jié)點實際上在代表被測試構(gòu)件的同時，也可以代表與被測試構(gòu)件相關(guān)聯(lián)的構(gòu)件。為了能夠應(yīng)用切片技術(shù)對其進(jìn)行切片，需要通過添加一些輔助接點對構(gòu)件節(jié)點及輔助邊對其進(jìn)行細(xì)化。這里通過定義一個五元組C = 來描述一個構(gòu)件節(jié)點，具體如圖2所示。

1） 構(gòu)造函數(shù)輔助節(jié)點（Construction Assistant Node）的集合Con

對于JavaBean構(gòu)件來說，為了體現(xiàn)面向?qū)ο蟮奶卣鳎跇?gòu)件節(jié)點中應(yīng)該添加與之相關(guān)的所有構(gòu)造函數(shù)的構(gòu)造函數(shù)輔助節(jié)點（Conk表示構(gòu)件中第k個構(gòu)造函數(shù)）。輔助節(jié)點實際上就是該構(gòu)件的入口節(jié)點。

2） 狀態(tài)輔助節(jié)點（State Assistant Node）的集合S

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

3） 接口函數(shù)輔助節(jié)點（Interface Function Assistant Node）的集合I

在構(gòu)件節(jié)點中添加表示該構(gòu)件所包含的所有接口函數(shù)的接口函數(shù)輔助節(jié)點（Im表示構(gòu)件中第m個接口函數(shù)）。

4） 輸入?yún)?shù)輔助節(jié)點（Input Parameter Assistant Node）的集合p

對于每一個包含輸入?yún)?shù)的接口函數(shù)應(yīng)該在其所對應(yīng)的接口函數(shù)輔助節(jié)點中添加表示該接口函數(shù)中所有參數(shù)的輸入?yún)?shù)輔助節(jié)點（pn表示該接口函數(shù)中的第n個參數(shù)）。

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

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

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

在明確了構(gòu)件系統(tǒng)的功能依賴圖的組成后，就應(yīng)該根據(jù)測試驅(qū)動程序?qū)y試驅(qū)動節(jié)點和構(gòu)件節(jié)點進(jìn)行關(guān)聯(lián)，從而建立整個構(gòu)件系統(tǒng)的功能依賴圖，它主要包括建立測試驅(qū)動程序的過程依賴圖和確立該過程依賴圖與構(gòu)件節(jié)點之間關(guān)聯(lián)關(guān)系兩個主要步驟。

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

本文的研究重點在于對構(gòu)件的接口進(jìn)行測試，因此，對被測試構(gòu)件系統(tǒng)的功能依賴圖的建立主要就體現(xiàn)在確立測試驅(qū)動程序的過程依賴圖和構(gòu)件節(jié)點之間的關(guān)系之上，這些關(guān)系主要包括了如下四個方面：

1） 測試驅(qū)動程序?qū)?gòu)件的實例化

在測試驅(qū)動程序中需要通過構(gòu)造函數(shù)對JavaBean構(gòu)件進(jìn)行實例化。這樣，就必須添加一條描述測試驅(qū)動程序?qū)?gòu)件進(jìn)行實例化的控制依賴邊。

2） 測試驅(qū)動程序?qū)?gòu)件中接口函數(shù)的調(diào)用

對構(gòu)件中接口函數(shù)的每一次調(diào)用，需要添加一條描述測試驅(qū)動程序?qū)涌诤瘮?shù)進(jìn)行調(diào)用的接口函數(shù)調(diào)用邊。

3） 測試驅(qū)動程序?qū)?gòu)件中接口函數(shù)的參數(shù)輸入

對于擁有輸入?yún)?shù)的接口函數(shù)來說，測試驅(qū)動程序在對其進(jìn)行調(diào)用時，對于每一個輸入?yún)?shù)都需要添加一條描述測試驅(qū)動程序在對其進(jìn)行調(diào)用時的參數(shù)輸入邊。

4） 構(gòu)件中接口函數(shù)對測試驅(qū)動程序的響應(yīng)

對接口函數(shù)的調(diào)用實際上相當(dāng)于對構(gòu)件中相關(guān)功能進(jìn)行了一次使用，因此，構(gòu)件就必須向外界產(chǎn)生這個調(diào)用的一個響應(yīng)，這樣，就必須添加一條描述構(gòu)件中接口函數(shù)響應(yīng)的邊。

本文以三角形問題的JavaBean構(gòu)件為例進(jìn)行研究，表1給出了三角形問題構(gòu)件中的接口函數(shù)及接口函數(shù)所對應(yīng)的狀態(tài)。

在依據(jù)三角形問題構(gòu)件的接口規(guī)約說明建立測試驅(qū)動程序后，圖3給出了其構(gòu)件系統(tǒng)的功能依賴圖。圖中右側(cè)部分是測試驅(qū)動程序節(jié)點，它是由被測試構(gòu)件的測試驅(qū)動程序所建立的過程依賴圖組成的[5]；圖中左側(cè)部分是三角形問題構(gòu)件的構(gòu)件節(jié)點，該節(jié)點中的S1、S2和S3分別代表了構(gòu)件中的三個狀態(tài)：bTriangle、 bRight和tType。由于三個接口函數(shù)的輸入?yún)?shù)都是三個整形變量，因此，為了便于觀察，在具體作圖的過程中將輸入?yún)?shù)a、b、c三個節(jié)點視為一個節(jié)點。

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

2 實驗結(jié)果和分析

2.1 實驗對象說明及實驗結(jié)果

本節(jié)以三角形問題構(gòu)件中反應(yīng)三角形類型的狀態(tài)“tType”作為興趣點，對其構(gòu)件系統(tǒng)的功能依賴圖進(jìn)行切片試驗。圖4所得到的即為切片后的三角形問題構(gòu)件系統(tǒng)的功能依賴圖。

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

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

對表2進(jìn)行分析可知：

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

其次，表格中的每一列說明了在對構(gòu)件接口調(diào)用關(guān)系模型運(yùn)用切片技術(shù)后，模型檢驗工具在驗證過程中所耗費(fèi)的時間有了一定的減少，而且在整個驗證過程中系統(tǒng)模型所產(chǎn)生的狀態(tài)空間的數(shù)量也得到了壓縮，模型檢驗的驗證效率得到了提高。

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

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

2.2 統(tǒng)計分析

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

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

通過對表3可以發(fā)現(xiàn)：

首先，對于每一個需要驗證的系統(tǒng)模型來說，在運(yùn)用切片技術(shù)對系統(tǒng)模型進(jìn)行切片之后，都能夠達(dá)到壓縮系統(tǒng)模型狀態(tài)空間數(shù)量，并提高驗證效率的目的。

其次，表中的數(shù)據(jù)以及實際的實驗結(jié)果說明，切片后的系統(tǒng)模型在驗證后所產(chǎn)生的反例路徑與切片之前所產(chǎn)生的反例路徑是相同的，因此，切片前后所產(chǎn)生的測試用例也是一樣的。

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

3 結(jié)束語

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

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

參考文獻(xiàn)：

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

[2] 梁陳良， 聶長海， 徐寶文， 陳振宇. 一種基于模型檢驗的類測試用例生成方法[J]. 東南大學(xué)學(xué)報（自然科學(xué)版）， 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] 李必信. 程序切片技術(shù)及其應(yīng)用[M]. 北京： 科學(xué)出版社， 2006： 3.

[5] 張K， 王[， 韓柯， 歐陽志強(qiáng). 面向構(gòu)件接口變異的模型檢驗技術(shù)研究[J]. 電腦知識與技術(shù)， 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)

關(guān)鍵詞：CBI聯(lián)鎖，OCS950系統(tǒng)，一致性測試

中圖分類號：U231+.3 文獻(xiàn)標(biāo)識碼：A

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

1 聯(lián)鎖調(diào)試前的準(zhǔn)備工作

（1）線纜絕緣測試

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

（2）上電測試

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

2 聯(lián)鎖測試流程及方法

聯(lián)鎖系統(tǒng)測試包括點對點的測試、軌旁信號設(shè)備單體調(diào)試、聯(lián)鎖室內(nèi)外一致性測試三大部分。

2.1 點對點測試

點對點測試是為了確定目標(biāo)控制器與組合繼電器的一一對應(yīng)關(guān)系是否正確，驗證目標(biāo)控制器驅(qū)動與采集是否正確。

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

2.2 軌旁單體測試

（1）信號機(jī)測試

信號機(jī)單體調(diào)試是使用點對點測試軟件完成目標(biāo)控制器對信號機(jī)單體設(shè)備點對點控制的調(diào)試，其中包括信號顯示控制調(diào)試；信號機(jī)單體輸入輸出電壓、電流測試；

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

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

當(dāng)紅黃同時點亮?xí)r,紅燈和黃燈顯示信號電流也要保持在上述范圍內(nèi)。

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

（2）轉(zhuǎn)轍機(jī)測試

轉(zhuǎn)轍機(jī)測試的目的是通過點對點測試軟件完成目標(biāo)控制器對轉(zhuǎn)轍機(jī)單體設(shè)備點對點控制的測試，其中包括轉(zhuǎn)轍機(jī)的定操、反操、定表、反表、失表示、轉(zhuǎn)轍機(jī)動作電流、動作電壓、動作時間、摩擦電流、摩擦電壓及四開狀態(tài)下的動作時間、4mm轉(zhuǎn)轍機(jī)不鎖閉失表示、2mm轉(zhuǎn)轍機(jī)鎖閉有表示等參數(shù)。

① 連接測試筆記本到目標(biāo)控制柜，給轉(zhuǎn)轍機(jī)設(shè)備上電，通過點對點測試軟件對轉(zhuǎn)轍機(jī)執(zhí)行定操和反操命令確定轉(zhuǎn)轍機(jī)動作方向是否正確，動作到位后定位和反位表示是否正確。

② 測量轉(zhuǎn)轍機(jī)所有需要測量的參數(shù)如下：

道岔正常動作時：

動作電壓380V±10%；

動作電流

道岔處于四開狀態(tài)時：

動作電壓380V±10%；

動作電流

動作時間

轉(zhuǎn)轍機(jī)斷表示測試；轉(zhuǎn)轍機(jī)斷遮斷器測試；

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

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

PSD接口測試的目的是為了完成信號系統(tǒng)與屏蔽門系統(tǒng)的硬件接口的測試（如果測試過程中PSD不具備聯(lián)機(jī)條件，本測試可使用封線假條件），為聯(lián)調(diào)聯(lián)試做準(zhǔn)備[3]。

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

② 在門控柜激活開門信號和關(guān)門信號，確認(rèn)屏蔽門相應(yīng)的開起和關(guān)閉。

③ PSD測試中如果測試的是非集中站，同時需要集中站測試人員確認(rèn)所測試的非集中站在集中站對應(yīng)的復(fù)視繼電器狀態(tài)與非集中站是否一致。

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

PEP接口測試是為了完成信號系統(tǒng)緊急停車控制功能的測試。測試中將站臺和車控室所有緊急停車按鈕恢復(fù)，由集中站測試人員確認(rèn)對應(yīng)的緊急停車?yán)^電器吸起，當(dāng)按鈕被按下時繼電器落下，依次激活和恢復(fù)每一個緊急停車按鈕，確認(rèn)集中站繼電器狀態(tài)正確。

2.3 聯(lián)鎖室內(nèi)外一致性測試

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

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

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

③ 軌旁人員對PSD進(jìn)行開關(guān)門、互鎖解除操作，確定屏蔽門狀態(tài)和ATS、維護(hù)終端顯示一致。

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

3 結(jié)束語

聯(lián)鎖系統(tǒng)調(diào)試是地鐵信號系統(tǒng)建設(shè)開通的重要環(huán)節(jié)，聯(lián)鎖控制是關(guān)乎地鐵安全運(yùn)營的核心重點。本文介紹了整個聯(lián)鎖系統(tǒng)硬件控制部分的調(diào)試流程及方法，筆者根據(jù)實際經(jīng)驗概述了天津地鐵2、3號線聯(lián)鎖系統(tǒng)調(diào)試的實現(xiàn)過程。

參考文獻(xiàn)

[1] 天津地鐵2號線 工程信號系統(tǒng)詳細(xì)設(shè)計文件.第二冊2010.10.

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

[3] 天津地鐵 2&3 號線軌旁ATC系統(tǒng)．2012.1.

篇(3)

關(guān)鍵詞：DSP；匯編語言；測試

中圖分類號：TP313文獻(xiàn)標(biāo)識碼：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硬件系統(tǒng)已具有了很高的可靠性，但其軟件系統(tǒng)，特別是用匯編語言設(shè)計編寫的較為復(fù)雜的軟件系統(tǒng)，可靠性總是難以得到保證，更是缺少完整的質(zhì)量保證和評估體系，這已經(jīng)成為DSP應(yīng)用方面亟待解決的一個問題。對DSP匯編語言軟件的測試與一般的軟件測試不同，其自身的特點決定了測試面臨的困難。本文首先對其測試難點進(jìn)行分析，然后給出了DSP匯編語言軟件的測試方法。

2 DSP匯編語言軟件環(huán)境的復(fù)雜性分析

2.1 與硬件結(jié)合緊密，測試環(huán)境難以搭建和選擇

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

2.2 I/O通道少，測試數(shù)據(jù)獲取比較困難

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

2.3 實時性要求較強(qiáng)

DSP軟件一般都用作控制系統(tǒng)的內(nèi)核，所以有很高的實時性要求，而實時性的測試是一般的測試方法和測試工具都難以實現(xiàn)的。

2.4缺少相應(yīng)測試工具

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

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

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

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

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

在設(shè)計功能測試用例時，也包括對邊界值的測試，即對輸入域(或輸出域)的臨界狀態(tài)、數(shù)據(jù)結(jié)構(gòu)、狀態(tài)轉(zhuǎn)換、功能界限等的邊界或端點情況下的運(yùn)行狀態(tài)的測試。此外，設(shè)計功能測試用例時運(yùn)用覆蓋測試工具輔助測試用例的設(shè)計，以達(dá)到功能測試的充分性。

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

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

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

5）結(jié)構(gòu)覆蓋測試階段。使用測試工具LDRA TestBed對被測軟件程序進(jìn)行插裝。插裝可以是在測試環(huán)境中嵌入硬件，也可以是在可執(zhí)行代碼中加入軟件，也可以是二者相結(jié)合。基于測試用例，執(zhí)行插裝后的程序，提取語句/跳轉(zhuǎn)覆蓋信息，將程序的執(zhí)行表現(xiàn)與編碼意圖進(jìn)行比較，衡量軟件測試工作的充分性。代碼覆蓋分析工具可能侵入代碼的執(zhí)行，影響實時代碼的運(yùn)行過程。基于硬件的代碼覆蓋分析工具的侵入程度要小一些，但是價格一般比較昂貴，而且限制被測代碼的數(shù)量。

6）強(qiáng)度測試階段。在模擬環(huán)境下，打開被測軟件全部數(shù)據(jù)采集與數(shù)據(jù)通信通道，運(yùn)行全部模擬外設(shè)，長時間運(yùn)行功能測試和接口測試等相關(guān)測試用例，檢測交流伺服驅(qū)動器控制軟件在設(shè)計能力下的運(yùn)行情況。

7 ）安全性測試階段。采用人工測試的方法對被測軟件進(jìn)行安全性測試。檢測用戶是否能對被測軟件進(jìn)行災(zāi)難性操作，被測軟件是否具有關(guān)鍵操作的安全性保護(hù)等功能。對于電機(jī)控制系統(tǒng)的DSP軟件，主要檢查過壓、過流、低壓、低流、斷電、異常復(fù)位等災(zāi)難性操作。

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

9）回歸測試階段。對于在測試過程中發(fā)現(xiàn)的問題，開發(fā)方應(yīng)及時對其進(jìn)行修正。修正后由測試方通過回歸測試進(jìn)行確認(rèn)。回歸測試必須將所有功能測試、接口測試等測試用例重新執(zhí)行一遍，以驗證所有問題已經(jīng)全部解決，并且沒有引入新的問題。

4 結(jié)論

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

參考文獻(xiàn)：

[1] 鄭人杰.計算機(jī)軟件測試技術(shù)[M].北京:清華大學(xué)出版社,1992.

篇(4)

關(guān)鍵詞：物聯(lián)網(wǎng)云計算平臺；測評體系

中圖分類號：F426.6

以云計算、物聯(lián)網(wǎng)、下一代互聯(lián)網(wǎng)為代表的新一輪信息技術(shù)革命，正在成為各國社會和經(jīng)濟(jì)發(fā)展共同關(guān)注的重點，當(dāng)然，質(zhì)量是其核心的競爭力。因此物聯(lián)網(wǎng)云計算平臺的測試策略的研究具有極其重要的意義。

1 物聯(lián)網(wǎng)云計算平臺的發(fā)展現(xiàn)狀

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

2 基于物聯(lián)網(wǎng)云計算平臺的軟件測試注意事項

2.1 員工的專業(yè)知識應(yīng)扎實

物聯(lián)網(wǎng)云計算系統(tǒng)是新一代信息發(fā)展的重要體現(xiàn)，員工尤其應(yīng)該與時俱進(jìn)，深入了解物聯(lián)網(wǎng)云計算平臺的運(yùn)作機(jī)理與自身的業(yè)務(wù)流程，熟練地掌控物聯(lián)網(wǎng)云計算平臺在運(yùn)作中與自己業(yè)務(wù)的對應(yīng)關(guān)系。使得這樣的高科技平臺能夠嫻熟地受到人為的操作。只有這樣才能讓平臺進(jìn)行高效的測試和執(zhí)行。

2.2 降低測試對生產(chǎn)環(huán)境帶來的風(fēng)險

物聯(lián)網(wǎng)云計算平臺不同于傳統(tǒng)的測試，只能通過現(xiàn)實的生產(chǎn)環(huán)境來進(jìn)行測試。這樣的特性，加大了測試的風(fēng)險。因此，作為專業(yè)的測試人員應(yīng)該要好好利用其它手段來有意識的規(guī)避這方面的問題。

2.3 對物聯(lián)網(wǎng)云計算平臺的性能測試重點關(guān)注

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

2.4 對安全性、可靠性的測試加以關(guān)注

關(guān)于物聯(lián)網(wǎng)云計算平臺安全可靠性測試目前主要采用評估的方式，其過程是通過物聯(lián)網(wǎng)云計算平臺模型得到相關(guān)的安全可靠模型，通過模型分析對建立的安全可靠性進(jìn)行直接評估。測試人員通過測試評估過程中產(chǎn)生的數(shù)據(jù)以及其他的測試評估結(jié)果進(jìn)行全面統(tǒng)一的分析比較計算，構(gòu)成關(guān)于物聯(lián)網(wǎng)云計算平臺的安全可靠性評價。對于測試的關(guān)注度還應(yīng)考慮到物聯(lián)網(wǎng)云計算平臺的兼容性、容錯性和可恢復(fù)性。

3 面向物聯(lián)網(wǎng)云計算平臺的質(zhì)量測評體系的建立

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

3.1 質(zhì)量測評體系的認(rèn)識

通過從基礎(chǔ)的網(wǎng)絡(luò)設(shè)備的建設(shè)，逐步推進(jìn)，不斷提高信息技術(shù)含量，從而帶動國家的各方面發(fā)展，強(qiáng)化產(chǎn)業(yè)優(yōu)勢和國家競爭力；通過在人民大眾的生活區(qū)域內(nèi)建立職能網(wǎng)絡(luò)，讓大眾隨時的感受科技智慧的服務(wù)。根據(jù)物聯(lián)網(wǎng)云計算平臺管理運(yùn)行機(jī)制的本質(zhì)特點和目標(biāo)，面向物聯(lián)網(wǎng)云計算平臺的質(zhì)量測量體系指標(biāo)應(yīng)該當(dāng)從整體質(zhì)量評價的效果上來進(jìn)行，從整體的角度實現(xiàn)物聯(lián)網(wǎng)質(zhì)量的提高，而不能只是看重某一個環(huán)節(jié)對現(xiàn)有的情況的影響。

隨著物聯(lián)網(wǎng)技術(shù)的發(fā)展，為了更加合理地顯示出質(zhì)量問題，就應(yīng)該要考慮建立和其相對應(yīng)的質(zhì)量測評體系，并根據(jù)所建立的這個質(zhì)量測評體系，對物聯(lián)網(wǎng)進(jìn)行評定。這個體系的指標(biāo)有其自身的特點，其內(nèi)容相比其他評價指標(biāo)體系更為寬廣。

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

3.2 面向物聯(lián)網(wǎng)的質(zhì)量測評體系的建立

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

確立測評體系的構(gòu)建思路首先有利于我們可以迅速抓住體系構(gòu)建的重點，并能順清思路，根據(jù)物聯(lián)網(wǎng)服務(wù)的特征，我們應(yīng)該在面向物聯(lián)網(wǎng)的質(zhì)量測評體系的構(gòu)建中遵循以下思想。

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

4 物聯(lián)網(wǎng)云計算平臺的測試策略

4.1 熟悉物聯(lián)網(wǎng)云計算平臺的測試技術(shù)及測試需求

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

4.2 物聯(lián)網(wǎng)云計算平臺真實環(huán)境下的部署與測試

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

4.3 物聯(lián)網(wǎng)云計算平臺的其他物理接口測試

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

4.4 對平臺的安全性測試

不管是什么軟件，關(guān)于軟件的安全性考慮都是重點，像物聯(lián)網(wǎng)云計算平臺這么龐大的軟件系統(tǒng)更是如此。如果系統(tǒng)本身安全性較低的話，單靠外部防護(hù)也無濟(jì)于事。

4.5 對平臺的兼容性測試

可以直接用不同的Windows操作系統(tǒng)來達(dá)到預(yù)想的目的，從而輕松完成系統(tǒng)的訪問，并十分便捷地實現(xiàn)兼容性測試問題。

4.6 對平臺的容錯性能與可恢復(fù)性能的測試

檢驗一個系統(tǒng)的容錯能力主要是看容錯和可恢復(fù)性測試。根據(jù)測試結(jié)果便可對系統(tǒng)的容錯性能有一定了解。主要針對物聯(lián)網(wǎng)云計算平臺故障和恢復(fù)測試、客服端的故障以及虛擬機(jī)的遷移等。

5 結(jié)束語

如今，物聯(lián)網(wǎng)云計算平臺作為新一代信息時代的代表早已到來。面向新一代信息技術(shù)應(yīng)用的測評體系與測試策略的建立，一方面幫助中小企業(yè)交付高質(zhì)量、高可靠的產(chǎn)品和系統(tǒng)；另一方面，推動中國高技術(shù)產(chǎn)業(yè)的發(fā)展，同時也對自己企業(yè)模式的轉(zhuǎn)型和創(chuàng)新以及高效運(yùn)營提供了先機(jī)。

參考文獻(xiàn)：

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

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

[3]曹麗，姜毅，甘春梅，張一弛，陳桂強(qiáng).云計算軟件測試平臺的構(gòu)建[J].現(xiàn)代圖書情報技術(shù)，2012（11）.

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

篇(5)

1、引言

隨著科學(xué)技術(shù)的進(jìn)步及數(shù)字通信技術(shù)的不斷發(fā)展，用戶通信中越來越關(guān)注數(shù)據(jù)通信的安全性保密性。電話作為人們?nèi)粘Ｉ钪械耐ㄐ殴ぞ撸Z音通話外，被廣泛用來傳真、上網(wǎng)及電話會議等，其數(shù)據(jù)傳輸?shù)陌踩院捅Ｃ苄栽絹碓绞艿街匾暋Ｅ紶柕囊稽c消息的外漏，都會引發(fā)公司巨大的經(jīng)濟(jì)損失。

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

2、測試儀硬件結(jié)構(gòu)

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

3、測試儀的測試功能

本測試儀能夠?qū)崿F(xiàn)模擬接口和數(shù)字接口的電話線路測試。其基本實現(xiàn)原理為Modem芯片1為低速調(diào)制解調(diào)芯片，主要實現(xiàn)模擬接口的電話線路測試；Modem芯片2為高速調(diào)制解調(diào)芯片，實現(xiàn)數(shù)字接口的電話線路測試。通過鍵盤選擇相應(yīng)的測試速率，單片機(jī)響應(yīng)鍵盤操作并發(fā)送相應(yīng)指令到FPGA，F(xiàn)PGA解析接收到的單片機(jī)指令通過控制Modem芯片1的工作來測試低速模擬接口線路或控制Modem芯片2來測試高速數(shù)字接口線路。

測試儀需要實現(xiàn)的測試功能有幅頻衰耗測試、誤碼測試、相位抖動測試、串?dāng)_測試、信令測試和自檢。

4、測試儀系統(tǒng)工作簡介

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

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

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

選擇自檢測試，并按0K鍵，單片機(jī)發(fā)送自檢測試命令至FPGA，F(xiàn)lea分別發(fā)送命令至Modem芯片1和Modem芯片2，Modem芯片將FPGA發(fā)送的命令直接反饋到FPGA，F(xiàn)PGA再將接收到的命令發(fā)送至單片機(jī)，單片機(jī)將自檢結(jié)果在液晶顯示器顯示。

為了測試儀使用靈活方便，本測試儀內(nèi)部集成主、從兩套系統(tǒng)，即其既可以當(dāng)主機(jī)使用也可以當(dāng)從機(jī)使用。其主、從模式轉(zhuǎn)換原理圖如圖

4、所示

如圖4所示測試儀初始默認(rèn)狀態(tài)為從機(jī)，只進(jìn)行數(shù)據(jù)的接收與處理，當(dāng)選擇要測試項目并按OK鍵后，測試儀從默認(rèn)的從機(jī)狀態(tài)轉(zhuǎn)換為主機(jī)狀態(tài)，測試測試儀開始發(fā)送相應(yīng)的測試數(shù)據(jù)。T秒后進(jìn)行的測試項目完成，測試儀自動由主機(jī)狀態(tài)回復(fù)到默認(rèn)的從機(jī)狀態(tài)。

5、測試儀系統(tǒng)測試結(jié)果

篇(6)

【關(guān)鍵詞】軟件測試；單元測試；用例；等價類

1.軟件測試

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

軟件測試過程包含單元測試、集成測試、確認(rèn)測試和系統(tǒng)測試四個步驟：

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

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

（3）確認(rèn)測試：檢查已完成的軟件系統(tǒng)是否已滿足了需求規(guī)格說明中的各項需求，軟件配置是否完全、正確。

（4）系統(tǒng)測試：將經(jīng)過確認(rèn)的軟件系統(tǒng)置入實際的運(yùn)行環(huán)境中，與其它系統(tǒng)成份結(jié)合在一起進(jìn)行測試。

2.單元測試

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

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

（1） 模塊接口測試

單元測試開始時，要對通過被測模塊的數(shù)據(jù)流進(jìn)行測試。包括調(diào)用該模塊的輸入?yún)?shù)的正確性、調(diào)用其子模塊時提供參數(shù)的正確性、全局變量的定義在各模塊中是否一致等。

（2） 局部數(shù)據(jù)結(jié)構(gòu)測試

包括數(shù)據(jù)類型的一致性、變量名、變量賦值、全局?jǐn)?shù)據(jù)對模塊影響的正確性等檢驗。

（3） 路徑測試

對基本執(zhí)行路徑和循環(huán)進(jìn)行測試，查找由于錯誤的計算、不正確的比較或不正常的控制流而導(dǎo)致的錯誤。

（4） 錯誤處理測試

檢測對錯誤條件的響應(yīng)是否正確，錯誤描述是否與實際的錯誤是否相符、是否能夠?qū)﹀e誤定位、是否易于理解等。

（5） 邊界測試

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

在面向過程編程時代，單元測試所說的單元一般是指函數(shù)，而在面向?qū)ο缶幊虝r代，單元測試所說的單元一般是指類。以類作為測試單位，測試的復(fù)雜度相對較高，所以目前通常采用的辦法是為軟件開發(fā)建立對應(yīng)的測試工程，為每個類建立對應(yīng)的測試類，為每個函數(shù)建立測試函數(shù)測試結(jié)構(gòu)化的局部代碼。

3.單元測試用例的設(shè)計

測試用例是指對某特定的軟件系統(tǒng)進(jìn)行測試任務(wù)的描述，它體現(xiàn)了測試的方案、方法和技術(shù)，包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等，并形成文檔。

測試用例的設(shè)計也就是測試需求細(xì)化的過程，測試需求分析和測試用例設(shè)計是密不可分的，前者是后者的依據(jù)，后者是前者的體現(xiàn)。測試用例的設(shè)計應(yīng)與復(fù)審相結(jié)合，根據(jù)相關(guān)設(shè)計信息設(shè)計測試數(shù)據(jù)，以增大發(fā)現(xiàn)錯誤的可能性。

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

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

篇(7)

1．1通信設(shè)備簡介

本通信設(shè)備由信息處理模塊、信號處理模塊、收發(fā)信道模塊及電源模塊組成。每個模塊具有獨立結(jié)構(gòu)件，插入到整機(jī)機(jī)箱，模塊之間以高速接插件及射頻接口互聯(lián)，主要完成綜合信息處理，調(diào)制解調(diào)信號處理，收發(fā)變頻等功能。

1．2可測試性設(shè)計指導(dǎo)思想［4］

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

1．3BIT設(shè)計

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

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

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

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

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

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

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

1．4ATE設(shè)計

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

2測試結(jié)果

根據(jù)以上BIT和ATE設(shè)計對本通信設(shè)備進(jìn)行了測試，部分測試結(jié)果如表1所示。

3結(jié)論