T-CSAE 177-2021 電動汽車車載控制器軟件功能測試規(guī)范

ICS43.120團體標準T/CSAE177－2021Testspecificationforsoftwarefunction2021-04-15發(fā)布2021-04-15實施中國汽車工程學(xué)會發(fā)布I V 1 1 1 2 2 2 2 6 6 6 7 9 9 9 本文件按照GB/T1.1—2020《標準化工作導(dǎo)則第1部分：標準化文件的結(jié)構(gòu)和起草規(guī)則》的規(guī)定大學(xué)、南京越博動力系統(tǒng)股份有限公司、上汽海外出行科技有限公司、威馬汽車成都研究院。V電動汽車車載控制器軟件測試活動受控制器開發(fā)體系（自1電動汽車車載控制器軟件功能測試規(guī)范GB20263—2006導(dǎo)航電子地圖安全處理技術(shù)基本GB/T30290.3—2013衛(wèi)星定位車輛信息服務(wù)系統(tǒng)第3部分：信息安全GB/T34590.6道路車輛功能安全第6部分：產(chǎn)品開發(fā)：軟件GB/T38634.1—2020系統(tǒng)與軟件工程軟件測試第1部分：概念GB/T38634.3—2020系統(tǒng)與軟件工程軟件測試第3部分：測試文檔ISO/IEC27001—2013信息技術(shù)安全技術(shù)信息安全管technology—Securitytechniques—Informationsecuritymanagementsystems.ReCNAS-CL01-A019:2018檢測和校準實驗室能力認可準則在軟件檢測領(lǐng)域的應(yīng)用說明2所有定義的或計劃的測試用例的一個子集。它覆蓋組件/系統(tǒng)的主要功能，以查明程序的絕大部分再測試verificationt4測試過程要求4.1測試準備階段要求4.1.1主要活動4.1.2測試計劃4.1.2.1測試范圍確定3測試范圍按照項目不同階段來確定，不應(yīng)少于b)量產(chǎn)功能驗收，應(yīng)開展完整的功能測試，測試結(jié)果符合組織的測試出口準則；4.1.2.2測試時間周期確定4應(yīng)針對開發(fā)過程中的不同情況參照公式(1)預(yù)設(shè)測試周期的構(gòu)成方式，并在測試開始前對開發(fā)人員做出測試周期的開放式承諾。使用者可根據(jù)需要按照附錄A給出的測試周期構(gòu)成方式示例預(yù)設(shè)測試周期4.1.2.3測試依賴資源確定4.1.2.3.1概述4.1.2.3.2外在輸入要求4.1.2.3.2.1功能描述文檔2)統(tǒng)一性：文檔內(nèi)容之間以及與其成套的文檔間無相互矛盾；3)可驗證性：有明確的訪問或檢查接口指引，同時有明確的判定指標；4)可追溯性：與其他文檔有追溯關(guān)系，或有明確的文件信息表明其來源；b)功能描述文檔在內(nèi)容描述時需要遵循以下原則：2)每條語句僅使用主動語態(tài)及用1個過程動詞來明確表達需求，應(yīng)避免錯綜復(fù)雜的語句描“電機控制器”；），5注3：該文件在使用自然語言構(gòu)成的同時，4.1.2.3.2.2接口描述文檔接口描述文檔需要描述被測對象存在的物理狀態(tài)以其接口形描述，比如控制器硬線接口定義、通訊協(xié)議（CAN、CANFD、Flexray、Ethernet等）、診斷協(xié)議、標定例，如在對數(shù)字和模擬通道接口描述時，應(yīng)包含以下a)與數(shù)字和模擬通道相連的外圍電氣負載，可以原理圖的形式呈現(xiàn)；b)信號類型（模擬量、開關(guān)量、PWM等）、收發(fā)頻率、門限值、準確度設(shè)計要求；c)若該通道需要開展硬線信號故障注入，應(yīng)確定接口外接屬于執(zhí)行器還是傳感器；d)若有外接傳感器應(yīng)給出關(guān)聯(lián)傳感器電氣特性；通信協(xié)議用于仿真和接收被測目標文件總線通信信息，模擬與被測目標文件交互的虛擬節(jié)點。數(shù)據(jù)范圍、數(shù)據(jù)分辨率)提供通訊矩陣每個信號的意義解釋；對于狀態(tài)信號，應(yīng)在后續(xù)的功能描述文件中提供詳細的狀態(tài)轉(zhuǎn)換邏輯說明；如果協(xié)議文件中存在CRC校驗（或CheckSum），應(yīng)在后續(xù)的功能描述4.1.2.3.2.3測試目標信息補充6a)測試完成后期望達到的質(zhì)量/性能目標（這個目標如果被提出則應(yīng)是量化的）；c)測試功能覆蓋范圍與測試應(yīng)完成的時間節(jié)點。4.1.2.3.2.4被測對象應(yīng)確定在實施計劃以內(nèi)完成測試所需的人員及其能力是否匹配，包括其出勤情況等。4.1.3準入條件a)測試所依存的信息、文件缺失導(dǎo)致測試無法實施，嚴重影響測試啟動；b)測試文件數(shù)量龐大，來源復(fù)雜，需要額外關(guān)注；4.1.4入口質(zhì)量要求試時長、調(diào)試環(huán)境模擬情況以及調(diào)試發(fā)現(xiàn)的問題及其更改a)測試在不可抗拒力的情況下無法實施應(yīng)默認為出口準則，無需單獨列出；c)可作為計劃的時間節(jié)點應(yīng)滿足時的最低質(zhì)量要求給出；d)可作為因軟件問題導(dǎo)致測試無法實施的最長時間要求。74.1.6測試環(huán)境準備4.1.6.1概述b)測試環(huán)境的運行步長應(yīng)小于被測對象的程序運行最小步長；c)測試環(huán)境與被測對象交互部分的仿真程度應(yīng)符合測試目標的要求。4.1.6.2硬件在環(huán)測試設(shè)備的要求4.1.6.2.1環(huán)測試設(shè)備要素d)通訊板卡：用于仿真器與各種總線系統(tǒng)的連接通4.1.6.2.2設(shè)備儀器選型對于具備不同屬性的設(shè)備儀器選型應(yīng)參考以下a)對具有采樣率指標的設(shè)備儀器，一般設(shè)備采樣頻率大于被測量信號的周期頻率；b)對具有量程指標的設(shè)備儀器其被測信號正控制在±0.5%以內(nèi)；被測信號負向最小值不超過儀器量程負向最小值的80%，且精c)對具有功率等級的設(shè)備儀器所提供電壓、電流及功率均應(yīng)滿足被測對象要求，且具有不低于8a)從自動化擴展方面考慮，PC上位機搭載上設(shè)備所需軟件工具后，從其發(fā)送指令開始計時，到該信號被實時處理器處理完成并回傳截止的時間間隔為T1，應(yīng)至少為被測控制器中涉及時間— d)對于CANFD的通訊要求：獨立高速CANFD通道，波特率可配置40～1Mbit/s，最高傳輸速率8Mbit/s，兼容高速CAN以及J193e)對于以太網(wǎng)的通訊要求：獨立高速以太網(wǎng)通道，支持車載以太網(wǎng)物理接口，速率可配置由于車載控制器分類比較多，例如驅(qū)動電機控制器、整車控制器、電池管理系統(tǒng)、DC-DC控制器4.1.6.3測試工具軟件的要求4.1.6.3.1運行測試環(huán)境工具的要求9f)可擴展性，工具本身預(yù)留充足接口便于進行二次開發(fā)；4.1.6.3.2測試執(zhí)行工具的要求a)測試采用的軟件應(yīng)至少支持Windows,Mac,Linux等系統(tǒng)中的一種或b)支持使用可視化的圖形建模工具搭建環(huán)境模型；4.2測試實施階段要求4.2.1對測試需求的分析要求4.2.1.1條目化4.2.1.2測試接口4.2.1.3用例設(shè)計要求4.2.2基于需求的測試用例設(shè)計要求4.2.2.1一般性要求及分類測試用例具體測試內(nèi)容的格式上應(yīng)包含前置條件、輸入變量及預(yù)測試用例在編寫后應(yīng)進行評審，評審應(yīng)由對功能了解的開發(fā)人員以及編寫用例的測試人員共同參4.2.2.2閾值類測試用例的設(shè)計方法A＜X≤B4.2.2.3查表類測試用例的設(shè)計方法4.2.2.4觸發(fā)條件類測試用例的設(shè)計方法不同重要程度的測4.2.2.5延遲觸發(fā)類測試用例的設(shè)計方法滿足一些單條件或條件組合且持續(xù)時間≥T,實現(xiàn)此功能。當條件為多條件組合與不同重要程度的測T4.2.2.6故障類測試用例的設(shè)計方法4.2.2.7枚舉類測試用例的設(shè)計方法不同重要程度的測4.2.2.8多狀態(tài)跳轉(zhuǎn)類測試用例的設(shè)計方法不同重要程度的測4.2.2.9迭代控制類測試用例的設(shè)計方法不同重要程度的測4.2.2.10公式類測試用例推薦的設(shè)計方法不同重要程度的測1.選取公式的輸出變量的最大值、最小值，以及需要4.2.2.11配置類測試用例設(shè)計方法不同重要程度的4.2.3基于經(jīng)驗的測試設(shè)計要求一定的自由度，應(yīng)采取一定的基于經(jīng)驗的測試4.2.4基于安全的測試設(shè)計要求4.2.4.1概述能安全測試、網(wǎng)絡(luò)安全測試；按照安全層級可劃分為：4.2.4.2對功能安全測試安全性測試需求來自對控制器的失效模式分析、對車輛影響的DFMEA等環(huán)節(jié)。按照GB/T34590.6對用圖2所示的方法識別汽車的失效。汽車常見的失效場景見警試整車處于維修模式時無法上高壓或整車處于上高壓狀整車控制器檢測到繼電器端電壓超過閾值時，禁整車接收到維修模式指令后，容錯時間內(nèi)是否可發(fā)送出繼電器在接收到整車發(fā)送的維修模式指令后，容對控制器功能安全測試的要求，具體要求見N——常量，N=365；4.2.4.3對網(wǎng)絡(luò)安全測試√——√——√—— √√—√— √ —√——√— √—√√——√——√——√ √——√4.2.4.4車載控制器的安全漏洞劃分針對識別的安全漏洞，按照引發(fā)后果的嚴重性確定漏洞等級。漏洞等級依不同程度分為3段，分別業(yè)務(wù)系統(tǒng)較小損失，并且立即可以受到控制，較小或忽略不計的財務(wù)損失等影響針對車載控制器的安全漏洞問題及數(shù)量，劃分安全等級見表不安全系統(tǒng)（符合任何b)直接獲取核心系統(tǒng)權(quán)限的漏洞，包括但不限于任意代碼執(zhí)行，遠程命令），c)核心系統(tǒng)業(yè)務(wù)邏輯的漏洞，包括但不限于交易支付邏輯漏洞，獲取任務(wù)賬號管理權(quán)限漏洞，越權(quán)增刪或查改其他用戶資源信息，未授權(quán)訪問重要系統(tǒng)后臺，重要系統(tǒng)任意文件讀取和下載漏洞核心接口邏輯檢驗漏洞取大量用戶身份信息，訂單信息，資金交易信息的接口權(quán)限校驗漏洞一般安全系統(tǒng)（符合任3、需要用戶交互方可影響的漏洞，包括但不限于反射性XSS，非敏感操作安全系統(tǒng)（符合任何一3、只存在經(jīng)過專家嚴密審核的一定次數(shù)后無法復(fù)現(xiàn)，或者不能反映出漏洞且并未引入新的安全問題，以此達到安全系4.2.5測試執(zhí)行要求4.2.5.1測試記錄其中異常事件包括：測試時間計劃變更、測試用例變更、測試范圍變更、測試輸入變更、開發(fā)/測試約定內(nèi)容未達成、不可抗拒力（設(shè)備無征兆損壞、停電、上級領(lǐng)導(dǎo)介入導(dǎo)致1)測試問題報告標識符。為該測試問題報告規(guī)定唯一的標識2)摘要。概述問題，標識涉及發(fā)現(xiàn)問題的測試項，并指出其嚴重級別；4.2.5.2測試全過程數(shù)據(jù)信息監(jiān)測4.3測試結(jié)束階段要求4.3.1測試報告概述4.3.2測試報告要求c)測試結(jié)論：應(yīng)明確標明測試后該軟件的質(zhì)量狀態(tài)與測試目的差異。2)應(yīng)包含測試環(huán)境軟硬件配置信息，包括測試設(shè)備名稱、型號等標識信息。4.3.3測試總結(jié)概述測試總結(jié)指定測試活動的結(jié)果并根據(jù)這些結(jié)果進行評4.3.4測試總結(jié)要求a)測試總結(jié)報告標識符：為該測試總結(jié)報告規(guī)定唯一的標識符。1)總結(jié)對測試項的評價，標識已完成測試項，標注版本/修訂級別及執(zhí)行測試活動所處的環(huán)c)差異：實際測試實施項與預(yù)期測試實施項的全部差異，實際執(zhí)g)改進項：根據(jù)以上信息得出，在后續(xù)測試活動中需要改進的內(nèi)容，并確定改進期限與責(zé)任人。h)批準：記錄測試過程中涉及的所有人員的姓名和職務(wù)，并為審批人員簽名和日期留出位置。一個問題從提出到關(guān)閉，測試人員和開發(fā)人員需要跟蹤b)Fixed（已修復(fù)的）：當開發(fā)人員進行處理并認為已經(jīng)解決問題之后，將問題的狀態(tài)設(shè)置為“Fixed”并將其提交給開發(fā)組的負責(zé)人，由開發(fā)組的負責(zé)人將問題反饋給測試組；c)Verified（驗證通過的測發(fā)人員的討論之后認可問題無效，開發(fā)組負責(zé)人可將問題的狀態(tài)設(shè)置為“Reje)Closed（已關(guān)閉的測試人員經(jīng)過再次測試拒絕狀態(tài)，經(jīng)與開發(fā)人員達成一致意見后測試組的負責(zé)人將問題的狀態(tài)設(shè)置為“Closed”；將問題的狀態(tài)設(shè)置為“Rejected”。如果開發(fā)人5.3測試問題修改5.4測試問題關(guān)閉驗證a)測試人員對“Fixed”已修復(fù)狀態(tài)的問題進行再測試，測試步驟應(yīng)當按照記錄的步驟進行重現(xiàn)，b)對于狀態(tài)為“Rejected”2)回歸測試驗證不通過的問題，應(yīng)駁回給開發(fā)“Reopen”重新打開，評審為非問題則可以修改問題狀態(tài)為“Closed”關(guān)閉。5.5測試問題評審5.5.1問題評審總體要求5.5.2問題評審人員要求5.5.3問題評審流程要求a)評審由測試人員發(fā)起，與項目經(jīng)理協(xié)商后，確定評審時間和評審人員；b)確定評審時間后，提前將需評審的問題進行整理并發(fā)送給相關(guān)評審人員；c)評審會議上對問題清單進行一一評審，并在創(chuàng)建測試問題評審表；d)測試人員參照測試問題評審表對問題狀態(tài)進行修改。5.5.4問題評審結(jié)論要求a)評審人員需要對“Rejected”狀態(tài)的問題進行判斷。若確定為非問題需將問題狀態(tài)改為“Closed”，并標注說明確認為非問題的原因。若確認為問題，將問題狀態(tài)改為“Reop給相應(yīng)的開發(fā)人員或者將問題狀態(tài)更改為“Deferred”；b)評審人員判定為“Deferred”的問題，需標注說明延期處理原因；5.6測試問題跟蹤避免因為該類問題處理不當對軟件功能造成不良影響。若問題延期，處理辦法如下：5.7測試問題總結(jié)5.8測試問題分析c)功能問題嚴重級別分布：可根據(jù)問題的嚴重級別以堆積圖的形式表示出各模塊的問題分布情6.1汽車業(yè)軟件測試知識基礎(chǔ)框架體以獨立完成汽車控制器軟件測試為目標，本文件將汽車軟件測X1-汽車軟件測試助理級別主要包含作為測試助理員所應(yīng)具備的基礎(chǔ)，包括IT基本概念和基礎(chǔ)知識）；）；X2-汽車軟件基礎(chǔ)級測試員屬于開展基礎(chǔ)測試工作的入門級模塊，此模塊系統(tǒng)涵蓋了軟件測試的基本概念、理論和方法，包括測試管理和工具支持等知識。主要內(nèi)c)軟件全生命周期的測試：針對不同的軟件開發(fā)模型，測試的不同級別和測試的不同類型；g)測試工具的支持：測試工具的類型，如何有效選擇和使用工具。b)AutomotiveSPICE軟件測試相關(guān)要點，ISO26262控制器軟件測試相關(guān)要點，AUTOSAR架構(gòu)與c)在虛擬環(huán)境中的測試：虛擬汽車測試環(huán)境，閉環(huán)系統(tǒng)與開環(huán)系統(tǒng)，模型在環(huán)系統(tǒng)（MiL），軟d)汽車專業(yè)測試（靜態(tài)）：MISRA20）：X3模塊是以X2為基礎(chǔ)的，應(yīng)在學(xué)習(xí)和掌握了X2模塊后再學(xué)習(xí)X3模塊。注：本部分的具體內(nèi)容可參看ISTQB/CS第三方測試機構(gòu)為中國汽車行業(yè)具有廣泛影響力的綜合性技術(shù)服務(wù)機構(gòu)，具有“獨立、公正、第三a)具有針對測試需求的專業(yè)的軟件功能測試團隊，團隊人數(shù)不的人員，應(yīng)有專門對軟件測試輸入和測試結(jié)果進行核查的人f)應(yīng)有涵蓋崗位工作的考核體系，并有方法衡量人員能力是否達標；h)測試人員能力需符合本文件第6章規(guī)定的相關(guān)要求；b)具有獨立的軟件功能測試實驗室，實驗室面積不小于40平米；c)實驗室配置專業(yè)的功能測試設(shè)備，能夠覆蓋電動汽車車載控制器測試需求；d)具有規(guī)范化測試環(huán)境搭建流程，并有與之對應(yīng)的測試環(huán)境搭建說明手冊；e)針對每一類可測試控制器應(yīng)有明確的測試環(huán)境搭建所需數(shù)據(jù)參數(shù)的需求清單；f)具備測試管理平臺，能夠?qū)崿F(xiàn)測試資源管理，測項不良程序交叉感染測試環(huán)境，如防病毒軟件a)在測試開始之前應(yīng)將測試需求條目化，同時識別各自的風(fēng)險等級；c)具有專業(yè)的測試用例設(shè)計方法進行測試用例開發(fā)，測試用例設(shè)計方法參考本文件4.2.2、d)對需求文檔的覆蓋應(yīng)有用例設(shè)計規(guī)格說明書，該說明書中規(guī)定了針對不同情況的測試覆蓋方e)條目化的需求與測試用例間需形成對應(yīng)關(guān)系，并可隨時查閱；f)所有用例都應(yīng)設(shè)置風(fēng)險等級，用例執(zhí)行順序應(yīng)遵從風(fēng)險等級從高到低；g)具有測試評審環(huán)節(jié)，包括設(shè)計輸入信息的評審以及測試用例的評審；h)應(yīng)有測試執(zhí)行過程中的應(yīng)急預(yù)案，預(yù)案中應(yīng)有可行的預(yù)備方案；j)需有測試日志，在記錄預(yù)定內(nèi)容完成情況的同時也應(yīng)記錄其他異常事件；k)具有完善的風(fēng)險管機制，能夠應(yīng)對測試實施過程中的異常事件；l)具有完善的測試出口準則，規(guī)范化定義所開展的測試任務(wù)的結(jié)束條件。商內(nèi)部建立一套完善的樣件管理體系，版本管理主要b)軟硬件版本的管理。供應(yīng)商在釋放每一版軟件，推薦采用如下方式提交版本信息。供應(yīng)商委托第三方測試需提供完整的測試輸入物，輸入物主要包括如下b)控制器接口描述文檔：主要針對控制器硬線接口定義、接口參數(shù)特性進行詳細描述；c)總線通信矩陣及數(shù)據(jù)庫：主要針對控制器進行總線數(shù)據(jù)監(jiān)測及網(wǎng)絡(luò)仿真；d)診斷協(xié)議及診斷數(shù)據(jù)庫：主要針對控制器診斷通信進行控制；e)控制器標定數(shù)據(jù)庫及標定工具：主要針對控制器進行標定控制；f)故障定義及故障識別、處理策略：主要針對控制器的故障邏輯策略進行詳細描述；g)兩套待測控制器：需提供滿足測試系統(tǒng)閉環(huán)調(diào)試的樣件；進行前期測試環(huán)境搭建以及測試用例開發(fā)相關(guān)c)供應(yīng)商確保測試持續(xù)到車型上市，上市后保存測試環(huán)境3個月。a)供應(yīng)商在每一個階段測試完成后，針對第三方測試機構(gòu)的提交的問題清單進行評估，要求3c)供應(yīng)商在問題整改完成后按計劃釋放對應(yīng)的回歸測試軟件，由第三方測試機