CANNAscend人工智能任務調(diào)度【免費下載鏈接】runtime本項目提供CANN運行時組件和維測功能組件。項目地址https://gitcode.com/cann/runtime點擊查看免費下載導讀本文完整解讀 CANN Runtime 開源倉庫中runtime-llt-generator技能Skill所使用的 LLTLow Level Test覆蓋率驗收政策。該政策規(guī)定了在生成或修改 Runtime 單元測試時如何圈定覆蓋率統(tǒng)計范圍、如何解析覆蓋率門檻、如何采集與判定覆蓋率以及判定達標所必須滿足的質(zhì)量條件。讀完本文你將掌握一套可復用的覆蓋率達到標判定方法既能準確設定coverage_threshold入?yún)?、理解默認 80% 的語義與生效優(yōu)先級也能在 LCOV/LLVM coverage 報告基礎上完成可核對的分子分母計算并避免把行覆蓋率達標誤當作測試行為正確的常見陷阱。一、政策定位與適用范圍本文檔對應的政策文件位于倉庫 coverage-policy.md它是runtime-llt-generatorSkill 在新增或修改 LLT時的完成判定依據(jù)不替代倉庫自身的 UT 規(guī)范。與之配套的兩份規(guī)范由 runtime-ut-guidelines.md 引用包括UT代碼規(guī)范硬性規(guī)范斷言、mock 與全局狀態(tài)清理、測試隔離、可維護性。UT用例開發(fā)指導 與 Runtime DT用例開發(fā)總綱用例設計方法論與校驗方式。覆蓋率政策與這些規(guī)范的分工是UT 規(guī)范管用例怎么寫覆蓋率政策管覆蓋率怎么驗收。覆蓋率只回答代碼被執(zhí)行了沒有而斷言是否有效、行為是否正確由 UT 代碼規(guī)范和用例設計規(guī)范共同負責。1.1 適用范圍的關鍵約束政策第一條即聲明其使用邊界開始前記錄工作區(qū)已有修改作為本次任務的基線。覆蓋率的統(tǒng)計只針對用戶指定范圍或本次 LLT 涉及的生產(chǎn)代碼改動不包含基線中的無關修改。僅修改測試時默認統(tǒng)計目標函數(shù)的全部可執(zhí)行行只有用戶或缺陷已明確范圍時才按分支或代碼區(qū)間統(tǒng)計。聲明、注釋、空行、當前產(chǎn)品未編譯的代碼不計入分母——這與倉庫 CMake 構建中的ENABLE_UT/ENABLE_COV開關語義一致見第五節(jié)。排除代碼時需逐行說明原因且可由配置啟用的代碼不得排除——防止通過剔除未編譯路徑來虛增覆蓋率。二、門檻入?yún)⑴c解析規(guī)則2.1coverage_threshold入?yún)⒌膶懛ㄕ叨x了可選入?yún)overage_threshold用于表示目標范圍的行覆蓋率門檻。接受以下寫法寫法含義是否合法8080 個百分點合法80%80 個百分點合法87.5%87.5 個百分點小數(shù)合法自然語言覆蓋率達到 90%90 個百分點視為同一入?yún)?5/120/abc越界或不可解析非法規(guī)則要點數(shù)值單位始終是百分點必須是0到100之間的有限值。參數(shù)缺失時直接采用默認值參數(shù)越界、無法解析或同一請求給出互相沖突的值時只詢問會影響門檻判定的歧義不做無謂提問。用戶值與倉庫強制值沖突時不得靜默降級必須取較高者見 2.3。2.2 默認門檻80%用戶未指定coverage_threshold時請求門檻默認為80%。需要特別強調(diào)的是政策原文明確注明80% 是本 Runtime Skill 的默認值不是通用行業(yè)標準。也就是說這個 80% 是runtime-llt-generator這一 Skill 在與倉庫 workflow 配合時采用的本地默認不能據(jù)此推論全行業(yè) UT 覆蓋率都應為 80%或CANN 倉庫統(tǒng)一要求 80%。2.3 強制門檻優(yōu)先級取較高者需求、目標倉庫 workflow 或其他強制規(guī)則若規(guī)定了最低覆蓋率實際生效門檻按以下公式確定實際生效門檻 max(請求門檻, 強制最低值)示例用戶指定coverage_threshold75%但倉庫 workflow 規(guī)定最低 80%則本次實際生效門檻為 80%若用戶指定 90%則取 90%。政策要求開始生成前記錄請求門檻及其來源用戶輸入或默認值、倉庫強制最低值和實際生效門檻交付時同時報告這些值。這保證了覆蓋率驗收過程可審計、可復核。三、完成門檻行覆蓋達標只是必要條件政策明確完成門檻包含兩層二者缺一不可行覆蓋率達標按適用范圍統(tǒng)計的行覆蓋率必須達到實際生效門檻。行為驗證充分所有可達的新建或修改判斷結果、錯誤返回、邊界和資源清理路徑必須有直接用例不能用行覆蓋率門檻替代分支與行為驗證。第 2 條直接呼應了 UT代碼規(guī)范 的規(guī)則 2斷言必須覆蓋關鍵可觀察結果——失敗場景必須校驗錯誤碼、錯誤狀態(tài)或關鍵保護行為而不是只斷言執(zhí)行結束。政策同時給出一個重要警示覆蓋率只說明代碼被執(zhí)行不能證明斷言有效或行為正確。這是全篇的核心心智模型覆蓋率是執(zhí)行證據(jù)不是正確性證據(jù)。四、采集與判定從報告明細讀數(shù)4.1 采集流程六步政策規(guī)定了覆蓋率采集的固定流程先檢查當前環(huán)境查看當前 workflow、tests/build_ut.sh --help、準確的 CMake target 和覆蓋工具不復用可能已過期的命令。同一快照構建運行使用與被測源碼、測試源碼同一工作區(qū)快照構建并運行目標用例篩選結果必須實際執(zhí)行大于 0 個用例。從明細數(shù)據(jù)讀取目標行從 LCOV、LLVM coverage 或倉庫等價工具的明細數(shù)據(jù)讀取目標行不得從控制臺總體PASS推斷覆蓋率達標。記錄完整元信息commit/工作樹狀態(tài)、覆蓋口徑生產(chǎn) diff 或 test-only 目標范圍、構建 target、測試 binary、篩選條件、報告路徑、可執(zhí)行總行、命中行、未命中行、未知行和百分比。平臺分別采集同一目標具有平臺實現(xiàn)時分別采集受影響平臺的結果一個平臺的覆蓋率不能外推到另一個平臺。unknown 行處理可執(zhí)行代碼未插樁、未構建、未進入報告、無法映射到當前二進制或統(tǒng)計范圍不能解釋時必須記為unknown并阻止達到實際生效門檻的結論。報告缺失或源碼與二進制快照不一致時結論只能是覆蓋率未驗證。4.2 計算口徑公式政策給出的唯一合法計算公式為scope_line_coverage 已命中的目標范圍可執(zhí)行生產(chǎn)代碼行 / 目標范圍可執(zhí)行生產(chǎn)代碼總行配套判定規(guī)則分子、分母、未覆蓋行和unknown行必須能從報告明細中核對。unknown不為 0 時不能判定達標。分母為 0 時記為N/A不算達標。沒有判斷分支的函數(shù)分支覆蓋率記為N/A但仍需測試調(diào)用方可觸發(fā)的邊界情況。也就是說一個目標函數(shù)沒有可執(zhí)行行或報告無法映射的場景永遠不能宣稱覆蓋率達標只能如實報告N/A或覆蓋率未驗證。4.3 倉庫中的覆蓋率工具鏈在 CANN Runtime 倉庫中覆蓋率采集依賴 tests/build_ut.sh 的-c/--cov參數(shù)其關鍵實現(xiàn)邏輯與政策第 1、3、4 條完全對應-c, --cov同時打開ENABLE_UTon與ENABLE_COVon見 tests/build_ut.sh構建階段通過 CMake 傳入-DENABLE_COV${ENABLE_COV}見 tests/build_ut.sh運行時先用 gtest 生成 XML 報告--gtest_outputxml:${report_dir}/${filename}.xml再調(diào)用lcov -c -d ${ut_dir}采集、lcov -r剔除/usr/*、output/*、tests/*、第三方庫與build/*等目錄最后genhtml生成 HTML 報告見 tests/build_ut.sh。從 CMake 側(cè)看910B 平臺 CMakeLists 在ENABLE_GCOV開關開啟時追加-fprofile-arcs -ftest-coverage插樁并在鏈接期追加-lgcov同時 UT target 接口統(tǒng)一鏈接了-lgcov見 910B CMakeLists。這解釋了政策第 6 條可執(zhí)行代碼未插樁……必須記為 unknown的落地方式只有以-c/--cov構建的二進制才攜帶覆蓋率插樁信息未插樁的二進制天然無法進入報告明細。需要特別留意的是腳本中的一處歷史路徑build_rts的 CMake 參數(shù)里使用的是-DENABLE_COV見 tests/build_ut.sh而 UT 編譯選項里生效的是ENABLE_GCOV見 910B CMakeLists。政策第 1 條要求先檢查當前 workflow、tests/build_ut.sh --help、準確 CMake target正是為了在構建前核對這類開關的實際接線避免憑記憶拼接命令。4.4 平臺分支必須分別采集政策第 5 條的背景是 Runtime 倉的多平臺 UT 工程布局。從 tests/ut/runtime/runtime/test 目錄可以看到測試用例按平臺拆分到platform/910B/、platform/950/、platform/arch5162/、platform/arch9201/、platform/cloud/、platform/dc/等多個獨立目錄每個平臺擁有各自的CMakeLists.txt、main.cc、stub/hal_stub.cc與平臺專屬 fixture。例如 910B 平臺構建出runtime_utest_task_910B、runtime_utest_api_910B、runtime_utest_xpu_910B等多個 gtest 可執(zhí)行文件見 910B CMakeLists。因此當被測代碼存在平臺實現(xiàn)差異時必須為每個受影響平臺分別構建、運行并采集覆蓋率一個平臺如 910B的通過結果不能外推為 950 或 David 等其他平臺已覆蓋。五、質(zhì)量檢查覆蓋率之外的硬性要求即使行覆蓋率達標政策仍要求對用例本身做質(zhì)量審計有效斷言對返回碼、出參、對象狀態(tài)、副作用、回調(diào)、資源和依賴交互使用有效斷言。場景覆蓋檢查成功、非法輸入、邊界、依賴失敗、重復調(diào)用、失敗清理和適用的平臺分支。未覆蓋代碼審計檢查未覆蓋代碼是否暴露遺漏場景、不可達代碼、錯誤掛載或錯誤 target。用例獨立性使用獨立、可重復、順序無關的用例恢復 mock、全局狀態(tài)、環(huán)境變量和臨時資源。這四點與倉庫 UT代碼規(guī)范 的規(guī)則一一對應規(guī)則 1每個測試用例必須有有效斷言對應第 1 條規(guī)則 2斷言必須覆蓋關鍵可觀察結果對應第 1、2 條規(guī)則 3mock 對象必須在測試退出時 verify 或 reset、規(guī)則 4修改全局狀態(tài)后必須恢復對應第 4 條規(guī)則 5測試用例之間不得互相依賴、規(guī)則 6臨時文件和目錄必須清理對應第 4 條。在 UT用例開發(fā)指導 中也可以找到配套的實踐模式例如在TearDown中調(diào)用Mock::VerifyAndClear或GlobalMockObject::verify()來收口 mock 狀態(tài)。六、與 LLT 生成工作流的銜接覆蓋率政策是 runtime-llt-generator SKILL.md 工作流程第 5 步構建、運行和覆蓋率的執(zhí)行依據(jù)。結合該 SKILL 的完整工作流建立被測范圍 → 設計行為矩陣 → 選擇放置位置和構建掛載 → 編寫 LLT → 構建/運行/覆蓋率覆蓋率驗收的完整閉環(huán)如下生成前記錄工作區(qū)基線確定請求門檻用戶輸入或默認 80%、倉庫強制最低值、實際生效門檻并記錄三者來源。生成中只修改目標測試及其必要構建資產(chǎn)新增測試文件必須加入準確的CMakeLists.txt源文件列表若新增模塊需要tests/build_ut.sh -u name獨立執(zhí)行才修改腳本的ut_path_map/target 映射。驗證時以-c構建準確 target → 直接運行包含新用例的 gtest binary → 證明篩選后實際執(zhí)行大于 0 個用例且無失敗/超時 → 按本政策采集覆蓋率并與實際生效門檻核對。交付時同時報告請求門檻及來源、實際生效門檻、覆蓋范圍、實際結果、未覆蓋/未知行以及未執(zhí)行的全量驗證、平臺路徑和剩余風險。政策與 SKILL 共同強調(diào)的已知陷阱包括不假設tests/build_ut.sh會把--后的gtest_filter透傳給二進制不用全倉覆蓋率掩蓋目標改動未覆蓋不把行覆蓋率當作斷言有效性的替代品不把單個平臺 fixture 的通過結果外推為所有平臺已覆蓋。七、常見問題速查問題答案未指定門檻時默認是多少80%且這是 Runtime Skill 的本地默認不是行業(yè)通用標準用戶指定門檻與倉庫強制值沖突怎么辦取較高者為實際生效門檻不得靜默降級覆蓋率統(tǒng)計的分母包含什么僅目標范圍內(nèi)的可執(zhí)行生產(chǎn)代碼行聲明、注釋、空行、未編譯代碼不計入能否從控制臺PASS判斷覆蓋率達標不能必須從 LCOV/LLVM coverage 明細數(shù)據(jù)讀取目標行報告中有unknown行怎么辦unknown不為 0 時不能判定達標目標范圍沒有可執(zhí)行行怎么辦記為N/A不算達標一個平臺覆蓋達標能代表其他平臺嗎不能受影響平臺必須分別采集行覆蓋率達標是否意味著測試合格不是分支、錯誤返回、邊界和資源清理路徑仍需直接用例斷言有效性另行審計排除代碼需要滿足什么條件逐行說明原因且可由配置啟用的代碼不得排除八、結語覆蓋率驗收的本質(zhì)是證據(jù)鏈而非單一百分比從圈定統(tǒng)計范圍、解析門檻優(yōu)先級到按同一快照構建運行、從報告明細核對分子分母再到對unknown/N/A的誠實上報每一步都有明確的判定規(guī)則。在 CANN Runtime 倉庫中這套政策與 tests/build_ut.sh 的-c/--cov工具鏈、各平臺 CMakeLists.txt 的ENABLE_GCOV插樁以及 UT代碼規(guī)范 的斷言與狀態(tài)清理要求共同構成完整閉環(huán)。掌握了這套方法你就能在生成 Runtime LLT 時給出可審計、可復核、不可被看起來通過了糊弄的覆蓋率結論。贊分享CANNAscend人工智能任務調(diào)度【免費下載鏈接】runtime本項目提供CANN運行時組件和維測功能組件。項目地址https://gitcode.com/cann/runtime點擊查看免費下載相關推薦CANN Runtime LLT 用例生成實戰(zhàn)指南從行為設計到覆蓋率驗收的完整方法論CANN Runtime LLT 用例生成實戰(zhàn)指南從行為設計到覆蓋率驗收的完整方法論 CANN Runtime 開源倉庫 cann/runtime 為運行CANNAscend人工智能任務調(diào)度CANN Runtime LLT 精準驗收指南變更驅(qū)動的用例篩選與定向運行CANN Runtime LLT 精準驗收指南變更驅(qū)動的用例篩選與定向運行 CANN Runtime 代碼倉cann/runtime維護著一套龐大的 RuCANNAscend人工智能任務調(diào)度CANN Runtime Example API 覆蓋率分析從零構建可量化、可追蹤的接口覆蓋報告CANN Runtime Example API 覆蓋率分析從零構建可量化、可追蹤的接口覆蓋報告 導讀 本文面向需要在 CANN Runtime 倉庫中評估CANNAscend人工智能任務調(diào)度上一篇高性能實時面部關鍵點檢測技術深度解析MediaPipe Face Mesh的實現(xiàn)原理與優(yōu)化策略下一篇開源項目 PoC 使用教程創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考