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