您好,登錄后才能下訂單哦!
Android原生底層驅動應用面極廣,但一直沒有很好的辦法進行質量追蹤。本文借助星云精準測試的高可靠性的測試技術手段,針對Android原生底層驅動進行分析、插樁、編譯、采集數據、數據分析等,逐步講解精準測試是如何實現android原生底層驅動的對接。
在本文中,我們可以清晰地查看到如何進行技術對接的每一步,比如如何使用星云精準測試進行代碼插樁、實現測試用例與采集底層驅動運行代碼的數據追溯、對最終采集的數據進行一系列分析等。
經分析android源碼的編譯主要依靠Android.bp為紐帶連接起來;在編譯時,只需要在想要編譯的模塊目錄下執行mm命令即可自動的根據當前目錄下的Android.bp文件對其所包含的模塊進行編譯。
主要流程大致為:先將ZOA通信庫源碼復制進去并加入某一層次的Android.bp中,再通過對包含所有Android.bp編譯信息的ninja文件的解析可以得到Shell認可的插樁json文件,Shell通過json文件對對應目錄的代碼進行插樁,插樁完成后,把對ZOA通信庫的引用加入該模塊的Android.bp中再放入ZoaInstru.h頭文件后就可以正常編譯出插樁程序了。
1.安卓原生8.1.0系統源碼,放于/data/source2/目錄下
2.shell.tar.gz插樁工具包放于/data/目錄下
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/目錄下執行命令
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后,聚類結果為:
切換為圖形模式為:
使用折線圖清晰的展現每天該版本覆蓋率的變化情況
左下角雷達圖展示了預期的各項覆蓋率與實際各項覆蓋看的差距
右下角對比了當前版本與最新版本各項覆蓋率的差異
在一個程序中,往往有成百上千的函數,這些函數有的是關聯整個程序核心、有的則是開發人員棄而不用,但一直保留遲遲不肯刪除的,針對這些大量的函數,“精準測試”采用通過靜態、動態指標的綜合分析,在大量的程序函數中,通過計算直接篩選潛在的高危的測試漏洞,通過報表給予展示。
當一個函數復雜度很高但覆蓋率卻很低的時候其出現風險的概率就可能比較高
當函數扇入扇出越大時,意味著其關聯函數越多,結合其覆蓋率信息也可能是風險較高。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。