1 前 言
自動變速控制系統(tǒng)軟件存儲于TCU（Transmission Control Unit，變速器控制單元）的ROM 中，主要由數(shù)據(jù)采集與處理、數(shù)據(jù)通信、決策調(diào)度、控制協(xié)調(diào)、驅(qū)動控制等模塊和換檔規(guī)律及相關(guān)經(jīng)驗數(shù)據(jù)等部分組成?，F(xiàn)代控制理論、電子技術(shù)、計算機技術(shù)、車輛自動變速理論及人工智能技術(shù)的發(fā)展與應(yīng)用，為車輛動力傳動系統(tǒng)自動操縱的實現(xiàn)提供了理論支持和技術(shù)保障。共同完成駕駛員意圖及環(huán)境參數(shù)識別、檔位決策、故障診斷、起步控制、換檔控制、制動控制、倒車控制及與外部通信等功能，實現(xiàn)發(fā)動機與傳動系共同工作的最佳匹配[1 ,2 ]。作為質(zhì)量保證的重要手段，軟件測試技術(shù)的研究與應(yīng)用，對提高AMT 控制系統(tǒng)軟件質(zhì)量并推動其產(chǎn)品化進程有著重要的意義。
2 自動變速控制系統(tǒng)軟件測試基本概念
2.1 測試目的及對象
自動變速控制系統(tǒng)軟件測試的目的是發(fā)現(xiàn)控制軟件的錯誤，而不是去證明其正確性。在測試活動中，應(yīng)始終把目標對準未被發(fā)現(xiàn)的隱藏錯誤。找出軟件錯誤不只是找出程序中的錯誤，所有與軟件開發(fā)有關(guān)的文檔資料也應(yīng)是軟件測試的對象。據(jù)我們在開發(fā)過程中的統(tǒng)計表明，在查找出的軟件錯誤中，屬需求分析和軟件設(shè)計的錯誤約占64%，而代碼編寫的錯誤僅占36%。所以自動變速控制系統(tǒng)軟件測試的對象應(yīng)包括軟件需求分析、設(shè)計規(guī)格說明及程序代碼等方面的內(nèi)容。
2.2 測試原則
自動變速控制系統(tǒng)軟件測試遵循如下原則：
（1）測試用例（Test Case）應(yīng)由測試輸入數(shù)據(jù)及對應(yīng)的預(yù)期輸出結(jié)果兩部分組成，其設(shè)計必須兼顧有效與無效輸入、正確與錯誤輸入[3 ]。
（2）編程人員避免測試本人的程序，為此在自動變速控制軟件開發(fā)小組中設(shè)置專業(yè)測試人員。
（3）檢查一個模塊是否完成了所有的功能，只是完成了測試工作的一半。另一半是要檢查該模塊是否還有預(yù)料之外的行為。
（4）充分注意測試中的群集現(xiàn)象。經(jīng)驗表明，測試后模塊中殘存的錯誤數(shù)與該模塊中已發(fā)現(xiàn)的錯誤數(shù)或檢錯率成正比[4 ]。
（5）應(yīng)在系統(tǒng)有錯的假定下進行測試。
2.3 錯誤類型
就錯誤發(fā)生的環(huán)境而言，自動變速控制系統(tǒng)軟件錯誤類型可分類如下：
（1）功能錯誤：文檔不完整、有歧義、一致性差，從而導(dǎo)致對系統(tǒng)功能的誤解。
（2）系統(tǒng)錯誤：包括與外部通信協(xié)議錯誤、參數(shù)引用及子程序調(diào)用出錯、I/O 操作及I/O 地址錯誤、
中斷處理錯誤、控制序列錯誤、資源分配出錯等。
（3）過程錯誤：運算、初始化及邏輯錯誤等。
（4）數(shù)據(jù)錯誤：信息、參數(shù)與控制數(shù)據(jù)混淆、數(shù)據(jù)結(jié)構(gòu)與屬性錯誤等。
（5）編碼錯誤：語法、變量名錯；局部與全局變量混淆等。
2.4 測試信息流
自動變速控制系統(tǒng)軟件測試過程中的信息流如圖1 所示。
圖1 自動變速控制系統(tǒng)軟件測試信息流
測試過程需要三類輸入信息：①軟件配置，包括軟件需求規(guī)格說明書、軟件設(shè)計規(guī)格說明書、源程序等；②測試配置，包括測試計劃、測試用例、測試驅(qū)動程序等，在軟件生存期過程中，它實際上只是軟件配置的一個子集；③測試工具，指測試過程中為便于測試而使用的軟件工具。
把測試結(jié)果和預(yù)期結(jié)果進行比較后可以得出是否有錯的信息，如果有錯需進行糾錯處理，經(jīng)改正后的軟件（包括文檔）需重新測試，直到錯誤消除為止。另一方面，可根據(jù)出錯情況建立軟件可靠性模型，用于可靠性預(yù)測。
3 自動變速控制系統(tǒng)軟件測試分析方法
3.1 靜態(tài)分析方法
靜態(tài)分析的主要特點是無需運行軟件系統(tǒng)本身，而是以一些人工的技術(shù)對自動變速控制系統(tǒng)軟件開發(fā)各階段所形成的軟件配置進行測試，主要是對需求分析、設(shè)計和編碼階段的成果進行測試，以保證軟件質(zhì)量。經(jīng)驗表明，靜態(tài)分析方法能夠有效地發(fā)現(xiàn)30%~70%的需求分析、邏輯設(shè)計和編碼錯誤，是一種行之有效的軟件測試分析方法。
（1）軟件需求規(guī)格說明書的靜態(tài)分析
在自動變速控制系統(tǒng)軟件需求規(guī)格說明書里，通常要給出軟件系統(tǒng)的功能、性能及輸入/輸出。對這些進行靜態(tài)分析，首先列出檢查表（Check List），然后利用它逐項地做人工檢查。在檢查表中列出的各種可能出現(xiàn)問題的條目，這些條目反映以下特性：相容性、必要性、充分性、可行性及可測性。
（2）軟件設(shè)計規(guī)格說明書的靜態(tài)分析
在自動變速控制系統(tǒng)軟件設(shè)計規(guī)格說明書包含有數(shù)學(xué)方程、算法、模塊功能描述、模塊的接口、數(shù)據(jù)流程圖、程序流程圖、存儲數(shù)據(jù)結(jié)構(gòu)等設(shè)計環(huán)節(jié)。同樣也要列出檢查表對這些設(shè)計環(huán)節(jié)進行分析。檢查表條目體現(xiàn)相容性、必要性、充分性及正確性。
（3）源代碼的靜態(tài)分析
對源代碼進行靜態(tài)分析有兩種方法：一是程序特性信息分析，即在獲取程序特性信息之后用人工方法來查找錯誤。這些特性信息包括模塊 (或子程序 )的調(diào)用關(guān)系、變量或其它符號名的交叉引用情況、模塊的循環(huán)特性及模塊的參數(shù)特性等；另外就是進行程序正確性分析，查找程序中特定類型錯誤或發(fā)現(xiàn)程序結(jié)構(gòu)上異常現(xiàn)象。包括對模塊邏輯結(jié)構(gòu)錯誤、循環(huán)控制變量未被賦初值、數(shù)組使用越界、零做除數(shù)等情況的檢查。
為提高靜態(tài)分析的效率，人工測試的形式也很重要，在自動變速控制系統(tǒng)軟件開發(fā)過程中常采用以下幾種形式：
（1）桌前檢查（Desk Checking）
在進行單元測試之間，由編程人員檢查自己編寫的程序（或模塊），對源代碼進行分析、檢查，并補充相關(guān)的文檔，目的是發(fā)現(xiàn)程序中的錯誤。檢查項目包括：變量或符號的交叉引用表、模塊 (或子程序 )的調(diào)用關(guān)系、標準、風(fēng)格、控制流、選擇/激活路徑、與規(guī)格說明是否一致等。實施此方法時要求編程人員注意避免主觀片面性。
（2）評審會（Inspection）
由有經(jīng)驗的編程人員主持（非軟件的設(shè)計者或程序的編寫者本人），吸收程序的作者或參加過設(shè)計的人員參加，也邀請有關(guān)專家和技術(shù)人員參加。
與會者在評審會前應(yīng)研究過被評審軟件的有關(guān)資料。會上由程序作者介紹任務(wù)來源和程序的編寫與調(diào)試情況。參加者提出問題，作者回答，使用錯誤檢查表（常見錯誤清單），逐步進行檢查，其中涉及到數(shù)據(jù)引用、數(shù)據(jù)說明、計算、比較、控制流程、接口、輸入和輸出等方面。會議時間不太長，以保持審查的效率。評審會的目的只是為了發(fā)現(xiàn)問題。
（3）走查會（Walkthroughs）
會前工作與評審會相同，會上不是簡單地讀程序和對照錯誤清單進行檢查，而是讓與會者集體“充當”計算機。即會前由測試人員準備好有代表性的測試用例，提交給走查小組。會上由集體扮演計算機，讓測試用例沿程序的邏輯“運行”一遍，隨時記錄程序蹤跡，供分析和討論之用。
3.2 動態(tài)分析方法
對自動變速控制系統(tǒng)軟件進行動態(tài)分析是在運行（或仿真）程序（或模塊）的條件下，取得程序（或模塊）的動態(tài)特性信息，通過這些信息來發(fā)現(xiàn)軟件配置中存在的錯誤。自動變速控制系統(tǒng)軟件動態(tài)分析包括以下幾個步驟：
（1）對軟件需求規(guī)格說明書進行動態(tài)分析
典型的方法是黑盒測試（又稱功能測試），即根據(jù)功能需求來設(shè)計測試用例，并通過測試結(jié)果來檢驗功能是否實現(xiàn)。
（2）對軟件設(shè)計規(guī)格說明書進行動態(tài)分析
根據(jù)設(shè)計過程中所涉及到的計算公式、算法、模塊功能及接口等設(shè)計環(huán)節(jié)設(shè)計測試用例，進行動態(tài)測試。從各個不同的設(shè)計方面設(shè)計不同的測試用例，使各個設(shè)計環(huán)節(jié)均能得到相應(yīng)的驗證。
（3）對程序（或模塊）進行動態(tài)測試
一般采用白盒測試（又稱結(jié)構(gòu)測試或邏輯驅(qū)動測試）方法，即根據(jù)程序（或模塊）的內(nèi)部邏輯結(jié)構(gòu)及有關(guān)信息（包括語句、分支、路徑等）設(shè)計測試用例，對程序（或模塊）的所有邏輯路徑進行測試，通過不同點檢查程序（或模塊）的狀態(tài)，確定實際的狀態(tài)是否與預(yù)期的狀態(tài)一致。白盒測試包括語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋、路徑覆蓋等測試方法，從語句覆蓋到路徑覆蓋測試強度呈遞增的趨勢。實際上，對于自動變速控制系統(tǒng)軟件這種控制邏輯比較復(fù)雜的程序，其執(zhí)行路徑比較龐大，采用完全路徑覆蓋方法進行測試是不現(xiàn)實的且沒有必要，通常的做法是在程序控制流圖的基礎(chǔ)上，通過分析控制構(gòu)造的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，用于設(shè)計測試用例。
4 自動變速控制系統(tǒng)軟件測試過程
自動變速控制系統(tǒng)軟件測試過程分三步進行：單元測試、集成測試和確認測試。
4.1 單元測試（Unit Test）
又稱模塊測試，是針對自動變速控制系統(tǒng)軟件實現(xiàn)的最小單位――程序模塊進行檢查，以發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種錯誤。單元測試在模塊編碼階段進行，各模塊的測試可平行、單獨地進行。一般使用白盒測試法。
單元測試的內(nèi)容主要包括五個方面：模塊接口、局部數(shù)據(jù)結(jié)構(gòu)、重要執(zhí)行路徑、錯誤處理及邊界測試。由于自動變速控制系統(tǒng)軟件的模塊本身并非獨立的執(zhí)行單位，為完成單元測試，往往需要編寫一個驅(qū)動模塊（Driver）和若干樁模塊（Stub），前者相當于被測模塊的主程序，后者則用來代替被測模塊所調(diào)用的模塊。模塊的內(nèi)聚性決定了單元測試的工作量。
4.2 集成測試（Integrated Test）
又稱組裝測試或整體測試。在單元測試的基礎(chǔ)上，將各模塊聯(lián)接起來進行測試，發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)的問題。這些問題可能是：穿越模塊接口數(shù)據(jù)丟失、一個模塊功能對另一模塊功能產(chǎn)生負面影響、各子功能組合后不能完成預(yù)期的父功能、全局數(shù)據(jù)結(jié)構(gòu)的使用存在問題等。
選擇什么方式將模塊組裝成一個系統(tǒng)，直接影響到模塊測試用例設(shè)計、模塊編號及測試順序、生成測試用例的費用及調(diào)試費用等。常用的組裝方式有兩種：一次性組裝和漸增式組裝。
一次性組裝首先對每個模塊分別進行單元測試，然后再把所有模塊組裝在一起進行測試。這種方法試圖在分別完成單元測試的基礎(chǔ)上將所有模塊連接起來進行測試，但實際上由于不可避免地涉及模塊間接口和全局數(shù)據(jù)結(jié)構(gòu)的問題，一次運行成功的可能性并不大，結(jié)果往往是發(fā)現(xiàn)有錯誤時查錯和糾錯都很困難。
對自動變速控制系統(tǒng)軟件的組裝方式應(yīng)采用漸增式組裝。即先對一個個模塊獨立進行測試，然后將這些模塊逐步組裝成較大的系統(tǒng)，在組裝過程中邊連接邊測試，以發(fā)現(xiàn)模塊連接過程中出現(xiàn)的問題，在規(guī)模漸增的過程中完成自動變速控制系統(tǒng)軟件的組裝。我們在實際中采用先自底向上（ Bottom-up）將關(guān)鍵模塊組裝成功能比較完整且相對獨立的子系統(tǒng)、然后再由主模塊開始進行自頂向下（Top-down）組裝的混合漸增式組裝測試方式，其優(yōu)點是在減少樁模塊的同時，能及時發(fā)現(xiàn)主要控制方面的問題。
4.3 確認測試（Validation Test）
自動變速控制系統(tǒng)軟件確認測試的任務(wù)是測試軟件的功能、性能及其它特性是否達到用戶要求，是對軟件綜合特性的全面測試。在這一階段要完成有效性測試、軟件配置復(fù)查、a 測試、b 測試及驗收測試。
5 結(jié)束語
本文結(jié)合自動變速控制系統(tǒng)軟件開發(fā)實踐，對自動變速控制系統(tǒng)軟件測試技術(shù)基本概念、測試方法和測試過程進行了較為全面的介紹。軟件測試技術(shù)的研究與應(yīng)用，有效地保證了自動變速控制系統(tǒng)軟件質(zhì)量，對其它汽車電控系統(tǒng)軟件開發(fā)也有一定的借鑒意義。
（轉(zhuǎn)載）
