Android原生底層驅動應用面極廣,但一直沒有很好的辦法進行質量追蹤。本文藉助星雲精準測試的高可靠性的測試技術手段,針對Android原生底層驅動進行分析、插樁、編譯、採集數據、數據分析等,逐步講解精準測試是如何實現android原生底層驅動的對接。linux
在本文中,咱們能夠清晰地查看到如何進行技術對接的每一步,好比如何使用星雲精準測試進行代碼插樁、實現測試用例與採集底層驅動運行代碼的數據追溯、對最終採集的數據進行一系列分析等。android
經分析android源碼的編譯主要依靠Android.bp爲紐帶鏈接起來;在編譯時,只須要在想要編譯的模塊目錄下執行mm命令便可自動的根據當前目錄下的Android.bp文件對其所包含的模塊進行編譯。算法
主要流程大體爲:先將ZOA通訊庫源碼複製進去並加入某一層次的Android.bp中,再經過對包含全部Android.bp編譯信息的ninja文件的解析能夠獲得Shell承認的插樁json文件,Shell經過json文件對對應目錄的代碼進行插樁,插樁完成後,把對ZOA通訊庫的引用加入該模塊的Android.bp中再放入ZoaInstru.h頭文件後就能夠正常編譯出插樁程序了。shell
1.安卓原生8.1.0系統源碼,放於/data/source2/目錄下json
2.shell.tar.gz插樁工具包放於/data/目錄下ide
3.ZOAMQLib通訊庫源碼放於/data/source2/ frameworks/av/目錄下函數
4.官方裝有原生8.1.0系統手機一部工具
本例是對/data/source2/ frameworks/av/camera模塊進行插樁編譯,首先source build/envsetup.sh配置環境變量,再lunch後輸入2選擇aosp_arm64-eng,再mm編譯模塊測試
在存放精準測試插樁工具包的/data/目錄下執行命令ui
tar -zxvf shell.tar.gz
將精準測試插樁工具包解壓
cd /data/shell/bin
進入shell包bin目錄下打開並修改Server.cfg的[SERVER]字段的ip爲星雲精準測試服務端ip,對[LOCAL]字段的ip,客戶端若與服務端在同一主機則保持127.0.0.1,若在不一樣主機則寫明客戶端ip。
本次選擇av模塊進行精準測試的插樁編譯驗證模塊,在對av模塊進行深刻了解後,解析出其Android,bp的鏈接其結構大體如此,每個最終節點就表明會生成一個動態庫或者靜態庫。
av大體結構與ZOA通訊庫加入安卓體系示意圖:
注:因爲第二層mediadrm模塊庫目錄過多不便展開,但原理又是相同,因此僅對該模塊展現骨架信息;綠色部分表明會產生一個庫文件,mediadrm只是骨架結構因此未標識。
本次是將寫好對應的Android.bp文件的ZOA通訊庫源代碼目錄整個複製到av目錄下,並在av目錄下的Android.bp文件中加入ZOA通訊庫的目錄。
cd /data/source2/frameworks/av/
進入av模塊
vi Android.bp
打開av模塊的Android.bp文件,並將ZOAMQLib目錄加入其中
ZOA通訊庫加入av模塊的Android.bp圖示:
而後在ZOAMQLib目錄下直接執行mm命令,編譯出安卓體系下的ZOA通訊庫。
android源碼在進行編譯時他會將全部的Android.bp中的信息提取出來並添加一些編譯信息來生成一個build.ninja文件。該文件中含有編譯的模塊、源代碼和編譯參數等信息。
經過android自帶的ninja工具能夠將該build.ninja文件轉化爲包含源代碼路徑、源代碼名字和編譯參數信息的json文件;再經過工具能夠將要插樁模塊的部分提取出來生成該模塊的插樁json文件
生成json文件的命令:
/data/source2/prebuilts/build-tools/linux-x86/bin/ninja -t compdb g.cc.cc > compile_commands.json
其中/data/source2/爲安卓源代碼路徑
shell編譯器能夠經過該json文件對該模塊進行插樁或還原操做。
插樁代碼命令 shell的路徑/shell -p json文件的路徑/ compile_commands.json
還原代碼命令 shell的路徑/shell -r json文件的路徑/ compile_commands.json
本次插樁與還原命令:
/data/shell/bin/shell -p /data/source2/compile_commands.json /data/shell/bin/shell -r /data/source2/compile_commands.json
插樁成功後在客戶端從新加載版本數據:
cd /data/source2/frameworks/av/camera
進入camera目錄下
vi Android.bp
打開camera模塊的Android.bp文件並在shared_libs中加入ZOA通訊庫的名字
camera的Android.bp加入ZOA通訊庫連接圖示:
cp /data/shell/include/ZoaInstru.h /data/source2/frameworks/av/camera/include/
將ZOA的頭文件加入被插樁的camera的頭文件夾中
而後就能夠按照正常的編譯流程來進行編譯,執行mm編譯該模塊。
本例是將安卓原生8.1.0代碼進行插樁後,放入官方8.1.0系統並得到root權限的手機中進行測試
本次插樁的是av模塊的camera部分,因此咱們將
camera模塊庫:
/data/source2/out/soong/.intermediates/frameworks/av/camera/libcamera_client/android_arm64_armv8-a_shared_core/libcamera_client.so
ZOA通訊庫:
/data/source2/out/soong/.intermediates/frameworks/av/ZOAMQLib/libZOAMQLib/android_arm64_armv8-a_shared_core /libZOAMQLib.so
這兩個庫放進手機的/system/lib64/目錄中開機進行相機測試。
測試概念圖:
將被測手機開機後用usb線鏈接到電腦上,採用adb端口映射的方法將程序運行時產生的動態數據傳輸到星雲精準測試工具上,再經過示波器進行波形展現。
數據傳輸圖:
在星雲精準測試工具客戶端打開示波器界面,創建測試用例並選擇測試用例後點擊 開始 並對手機進行相機功能的操做就能夠在接收到動態數據並示波器看到波形了。
示波器接收數據圖:
在對測試用例錄製完成後就能夠在主界面看到覆蓋率等相關信息。
在函數列表中隨便點開一個函數就能夠查看該函數的各項覆蓋率。
1.SCO覆蓋率
SCO覆蓋率即爲語句塊覆蓋率,在函數內順序執行碰見if、for、while等就算爲一個語句塊。
SC0覆蓋率圖示:
2.MCDC覆蓋率
MCDC 修訂條件斷定覆蓋,精準測試中對mcdc作了量化展現,分別統計單一條件個數,針對每個條件判斷是否知足mcdc覆蓋若是知足如上圖綠色表示條件知足mcdc覆蓋,藍色表示不知足。並對MCDC作了詳細信息的展現(選擇MCDC覆蓋,點擊斷定,顯示MCDC的詳細信息)
MCDC覆蓋率圖示:
注:
1.覆蓋率信息一共有七種,分別爲SCO語句塊覆率、True、Flase、Both等條件覆蓋率、Branch條件分支覆蓋率、CDC條件斷定覆蓋率、MCDC修正條件斷定。
2.精準測試默認是不關聯源碼的,如須要關聯源代碼使用,請將源碼複製到客戶端本地,在版本上右鍵選擇修改源碼路徑,而後添加源碼路徑來關聯源碼。
函數調用圖,只有函數調用的關係,可以比較清楚地看清函數調用的層次關係。當點擊其中的某個函數時,能顯示以該函數爲中心,調用該函數的上三層和下三層調用(可點擊設置層級進行層級的調整)。
當接收過動態數據後還能將各項數據顯示在圖像界面中。
控制流程圖基礎功能是展現函數的控制流程,即控制流程圖,用於表示函數的控制流程、顯示測試覆蓋率結果、實現半自動高效率測試用例設計,進行邏輯流程查錯,以及源碼、測試用例和相關文檔之間的雙向自動追溯等。
簡易控制流程圖功能,以語句塊的形式清晰的展現函數內部的控制邏輯,界面上能夠直觀的看出控制流各節點的測試覆蓋狀況,在展現中,簡易控制流程圖還能夠經過顏色對每一個程序塊進行覆蓋率標識,在縮略圖中整個模塊的覆蓋率很是直觀。(背景色爲綠色表示有測試用例覆蓋到該塊)關聯源碼後點擊語句塊可定位到代碼具體行。
因爲精準測試的測試用例與執行過的函數綁定,能夠在測試臺經過選擇不一樣的測試用例來正向追溯找到它執行過的函數;或者經過選擇不一樣的函數或代碼來反向追溯找到執行過它的測試用例。
正向追溯圖示:
該正向追溯是經過在左上側選擇測試用例來在下方展現該測試用例運行過的函數
反向追溯圖示:
反向追溯既能夠經過左下角的函數來追溯運行過該函數的測試用例,還能夠經過選擇代碼塊來追溯運行過該塊的測試用例。
在第一個版本測試完成後對第二個版本進行插樁後就在星雲精準測試工具生成了第二個工程版本。此時咱們要作的不是立馬對新版本進行測試,而是使用咱們星雲精準測試的迴歸功能對新插樁的版本進行迴歸,它會根據版本之間代碼的變化的來分析出與該函數相關的測試用例,而後根據測試用例內函數改變的多少進行迴歸優先級的排序,智能的推薦出須要從新跑的測試用例,以及顯示出不須要跑的測試用例。
智能迴歸示例:
cd /data/source2/frameworks/av/camera進入到camera目錄下
vi ICamera.cpp打開該源碼進行修改
在getParameters函數中加入if(1==1);條件
而後對camera模塊進行插樁,再在客戶端使用選取回歸測試用例功能進行迴歸
因爲getParameters函數內新增條件發生變化,因此運行過該函數的測試用例的迴歸計數就加一,而後該測試用例就被推薦出來須要從新去跑一遍。
迴歸圖示:
對精準測試而言,其是採用在測試階段,將測試用例和它所執行過的函數綁定的方法。在版本迭代時會將上一個版本的測試用例繼承下來,經過迴歸跟上個版本進行比較,哪一個函數有了變化,那麼與其相關的測試用例的功能均可能會發生變化,因此在迴歸時會推薦出要從新測試的測試用例;而當一個測試用例裏面關聯的全部函數都沒發生變化時他的功能也不會發生變化,那麼此時再去測試一遍該用例是沒有意義的事情。因此,在新版本插樁完畢後和之前的進行迴歸後就能夠看出哪些用例須要從新跑哪些徹底不用再跑。
該部分是執行插樁程序進行動態數據接收時保存的最後五十個語句塊執行的時序關係圖
它能夠點擊每一步次序查看執行塊的代碼
聚類算法中個數的設置是須要手動設置的,通常看顆粒度的粗細進行設置。聚類算法是經過測試用例的代碼類似程度得出結果的,因此能夠幫助咱們劃分出來有哪些測試用例的代碼類似程度比較高,
本次共設計7個測試用例,兩次拍照、兩次錄視頻、一次隨便側、一次打開相機、一次打開相機後閒置。
選擇分類個數爲5後,聚類結果爲:
切換爲圖形模式爲:
使用折線圖清晰的展示天天該版本覆蓋率的變化狀況
左下角雷達圖展現了預期的各項覆蓋率與實際各項覆蓋看的差距
右下角對比了當前版本與最新版本各項覆蓋率的差別
在一個程序中,每每有成百上千的函數,這些函數有的是關聯整個程序核心、有的則是開發人員棄而不用,但一直保留遲遲不願刪除的,針對這些大量的函數,「精準測試」採用經過靜態、動態指標的綜合分析,在大量的程序函數中,經過計算直接篩選潛在的高危的測試漏洞,經過報表給予展現。
當一個函數複雜度很高但覆蓋率卻很低的時候其出現風險的機率就可能比較高
當函數扇入扇出越大時,意味着其關聯函數越多,結合其覆蓋率信息也多是風險較高。