持續(xù)測試（CT）實戰(zhàn)經(jīng)驗分享

傳統(tǒng)汽車正在向互聯(lián)網(wǎng)發(fā)展

在汽車行業(yè)向“新四化”趨勢的推動下，傳統(tǒng)分布式的EE架構(gòu)向域集中式架構(gòu)發(fā)展，伴隨著域控制器概念的提出，軟件也將根據(jù)相應功能域分類集成，域控制器的代碼量也與日俱增。SOA的開發(fā)模式實現(xiàn)各軟件功能模塊間解耦，幫助軟件團隊縮短開發(fā)周期，快速迭代軟件版本。OTA升級技術(shù)將軟件快速部署到各個域控制器，為軟件產(chǎn)品的快速迭代提供保障。隨著開發(fā)模式的變革，迭代測試變得周期短而頻繁，持續(xù)測試將為軟件產(chǎn)品提供快速的質(zhì)量保證。

POLELINK

什么是持續(xù)測試？

A

持續(xù)測試來源于DevOps（Development和Operations）中提倡的CI（持續(xù)集成）- CO(持續(xù)部署) - CT（持續(xù)測試）- CD（持續(xù)交付），通過流程和持續(xù)集成/持續(xù)測試工具平臺，自動化“軟件交付”，使得構(gòu)建、測試、發(fā)布軟件能夠更加快捷、頻繁和可靠。

POLELINK

汽車行業(yè)為什么需要持續(xù)測試？

傳統(tǒng)汽車軟件開發(fā)模型中，測試方法包括手動測試和手動編寫測試腳本后的自動化/半自動化測試。其特點是以“人”為中心，需要測試工程師重復性的手動測試、不斷更新測試腳本或配置、記錄測試問題和測試狀態(tài)跟蹤。測試的周期和質(zhì)量，依賴于測試工程師的數(shù)量、經(jīng)驗能力和工具數(shù)量。

圖1 傳統(tǒng)測試流程持續(xù)測試的方法以人、測試流程、測試工具的結(jié)合，通過一系列測試工具鏈的組合與自動化測試工程結(jié)合，提交新版軟件時即為測試流程的開始，快速找到軟件缺陷，解決測試和開發(fā)在時間上的矛盾，幫助軟件開發(fā)團隊實現(xiàn)軟件產(chǎn)品速度與質(zhì)量的目標。本文將從持續(xù)測試角度，分享基于Jenkins和Vector軟硬件實現(xiàn)的實戰(zhàn)經(jīng)驗。

測試方案簡介

系統(tǒng)框架

圖2 系統(tǒng)框圖

主要功能

測試流程管理

?測試項目管理模塊、測試需求管理模塊、測試用例管理模塊、測試任務管理模塊、測試缺陷管理模塊、測試報告管理模塊、遠程設備管理模塊等

持續(xù)驗證調(diào)度管理

?測試對象、測試設備調(diào)度管理、代碼版本庫調(diào)用管理、測試流程搭建及執(zhí)行

IDL腳本轉(zhuǎn)換工具集成

?通過測試數(shù)據(jù)文件生成測試腳本

測試腳本/測試數(shù)據(jù)版本控制管理

?基于GitLab/SVN或自建數(shù)據(jù)庫管理測試腳本/測試數(shù)據(jù)，構(gòu)建有效的知識庫

數(shù)據(jù)流引擎驅(qū)動測試數(shù)據(jù)分析

?基于測試數(shù)據(jù)進行分析，獲得測試結(jié)果

測試報告引擎自動測試報告

?基于測試數(shù)據(jù)分析結(jié)果生成定制測試報告

案例介紹

基于Jenkins和Vector工具實現(xiàn)CAN/CAN FD/LIN/FlexRay/ETH網(wǎng)絡和診斷測試。

圖3 CT流程持續(xù)測試的核心在于把自動化測試的各個環(huán)節(jié)和流程自動地、智能地組織起來，并提供狀態(tài)查詢、通知等服務，實現(xiàn)步驟如下：

? 測試計劃：根據(jù)開發(fā)人員提交的軟件版本建立對應測試計劃

? 測試環(huán)境搭建：測試工具鏈與測試對象連接，滿足測試環(huán)境要求

? 更新測試用例：建立對應軟件版本的測試用例庫，并進行版本管理，方便回歸測試

? 測試觸發(fā)：監(jiān)控開發(fā)人員提交狀態(tài)，提交結(jié)束即為測試開始，采用Jenkins管理測試執(zhí)行的流程

? 測試樣件/設備管理：自動從測試樣件/設備庫中選擇可執(zhí)行測試的環(huán)境，提高測試資源的利用率

? 自動化測試用例腳本：根據(jù)標準化的測試用例和數(shù)據(jù)庫，自動生成可測試工程

? 數(shù)據(jù)采集和分析：用自動化測試工程代替測試工程師手動執(zhí)行測試，既縮短測試周期，又避免了人工測試產(chǎn)生的誤測漏測等問題；分析測試數(shù)據(jù)，自動生成測試報告與測試問題，避免測試工程師手動錄入測試問題的重復性勞動

? 測試報告版本管理：測試用例、測試工程、測試報告、測試數(shù)據(jù)與軟件版本相對應，方便測試問題追溯與定位

以下將從測試準備、測試觸發(fā)、測試執(zhí)行與測試問題記錄三個方面詳細介紹搭建測試環(huán)境的步驟。

測試準備

測試準備過程將測試執(zhí)行中需要使用到的各種工具進行配置，包含如下過程：

? 測試計劃建立：使用北匯自研PAVELINK或者JIRA等測試管理軟件建立測試計劃，包含測試軟件版本信息，測試用例庫，測試責任人等

?更新測試用例：根據(jù)新發(fā)布的軟件版本建立測試用例庫，使用GitLab/SVN進行版本管理

? 測試樣件/設備管理：管理測試樣件/設備狀態(tài)及測試進度

? 測試環(huán)境搭建：測試設備與測試樣件進行測試環(huán)境調(diào)試，以支持自動化測試。測試工具使用Vector總線接口設備和CANoe軟件

? Jenkins測試流程管理：配置Jenkins Job，管理測試執(zhí)行的流程

圖4 傳統(tǒng)總線網(wǎng)絡和以太網(wǎng)測試系統(tǒng)

測試觸發(fā)

自動化測試流程通過Jenkins Job進行配置管理。Jenkins Job可通過手動、定時、監(jiān)控GitLab/SVN版本或通過Jenkins API觸發(fā)調(diào)用等方式觸發(fā)。本次方案通過監(jiān)控測試樣件軟件版本，讀取到軟件升級到指定版本后，使用Jenkins API調(diào)度方式觸發(fā)測試流程的開始。

圖5 Jenkins API

測試執(zhí)行與測試問題記錄

Jenkins Job定義一個測試流程，包含自動化測試腳本的生成、測試執(zhí)行、測試問題記錄。自動化測試腳本生成：通過解析數(shù)據(jù)庫文件生成測試腳本。

圖6 測試腳本自動生成
測試執(zhí)行：通過CANoe軟件COM接口調(diào)用的方式實現(xiàn)測試用例工程的選擇、測試執(zhí)行、測試數(shù)據(jù)和測試結(jié)果的回讀。

圖7 CANoe COM接口說明
測試問題記錄：回讀到的測試結(jié)果自動上傳到測試問題管理系統(tǒng)，使用北匯自研的PAVELINK平臺更新測試用例的測試結(jié)果，上傳測試數(shù)據(jù)和新建測試問題。

圖8 PAVELINK問題管理平臺Jenkins具有郵件發(fā)送功能，在測試執(zhí)行結(jié)束時，可將測試結(jié)果等信息通過郵件發(fā)送給相關責任人。

寫在最后

1

持續(xù)測試不等同于自動化測試，持續(xù)測試一系列流程，包含自動化測試，自動化測試是持續(xù)測試的一個關鍵步驟。通過和軟件開發(fā)迭代在流程上結(jié)合，快速發(fā)現(xiàn)軟件缺陷。

2

采用持續(xù)測試的測試方式可以很好地將解決手動測試周期長的問題，提升了測試效率，提高測試人員的生產(chǎn)力。同時對測試輸出物與軟件開發(fā)版本進行控制，符合正向開發(fā)和測試管理的要求。

3

持續(xù)測試作為可提升測試效率的工具，的確給測試工程師帶來“一鍵式”托管執(zhí)行測試的工作體驗。但作為工具而言，持續(xù)測試并不能滿足所有的測試場景。首先，持續(xù)測試要求可執(zhí)行的測試用例是可自動化執(zhí)行的，測試過程中如果需要手動進行參數(shù)輸入或測試環(huán)境的變更，很難達到提升測試效率的效果。其次，需要測試腳本可自動生成或測試腳本不需要修改，面對每次迭代的軟件產(chǎn)品，手動編寫或者修改測試工程也會給測試人員帶來繁重的工作量。

4

持續(xù)測試使用的工具鏈多且復雜，測試系統(tǒng)整體的穩(wěn)定性需要重點關注。所以是否進行持續(xù)測試需要先對測試場景進行分析，也不能為了追求持續(xù)性而去舍棄測試的精確性。

北匯信息緊跟市場風向，在持續(xù)測試方面也積累了很多的經(jīng)驗，除了基于Jenkins的持續(xù)測試方案，北匯信息也自研了基于CANoe軟件的測試管理工具，期待與行業(yè)中的同仁進行交流。參考文獻:【1】中國汽車基礎軟件發(fā)展白皮書2.0【2】Jenkins權(quán)威指南