OpenHarmony移植:XTS子系統之應用相容性測試套件
摘要:本文通過例項分析下ACTS應用相容性測試套件移植案例,以及移植過程中特定的操作的原理。
本文分享自華為雲社群《移植案例與原理 - XTS子系統之應用相容性測試套件》,作者:zhushy。
XTS(X Test Suite)子系統是OpenHarmony生態認證測試套件的集合,當前包括:
- acts(application compatibility test suite)應用相容性測試套件,看護北向HAP相容、OpenHarmony開發API相容。
- hats(Hardware Abstraction Test Suite )硬體抽象測試套,看護HDI層介面。
- dcts(Distributed Compatibility Test Suite )分散式相容性測試套,看護分散式相容(待上線)
本文主要通過例項分析下ACTS應用相容性測試套件移植案例,以及移植過程中特定的操作的原理。主要講述的是輕量系統相容性測試。輕量系統因系統能力限制,相容性測試在系統初始化階段進行;並且各裝置燒錄工具存在差異,導致自動化工具(xDevice工具)無法實現真正的自動適配,因此認證執行方式不對合作夥伴進行限制。流程如下:
- 步驟1 編譯適配:XTS子系統加入到編譯元件中,隨版本一起編譯;
- 步驟2 本地執行:完成相容性測試;
1、編譯適配XTS子系統
1.1 產品解決方案適配
需要在產品解決方案配置檔案中增加增加xts_acts與xts_tools元件定義。下面看幾個示例,檔案vendor\bestechnic\xts_demo\config.json中的配置片段:
{ "subsystem": "xts", "components": [ { "component": "xts_acts", "features": [ "config_ohos_xts_acts_utils_lite_kv_store_data_path = \"/data\"", "enable_ohos_test_xts_acts_use_thirdparty_lwip = true" ] }, { "component": "xts_tools", "features":[] } ] }
檔案vendor\goodix\gr5515_sk_xts_demo\config.json中的配置片段:
{ "subsystem": "xts", "components": [ { "component": "xts_acts", "features": [ "config_ohos_xts_acts_utils_lite_kv_store_data_path = \"/data\"" ] }, { "component": "xts_tools", "features":[] } ] },
1.2 編譯連結
需要通過連結選項指定需要連結的ACTS的部件編譯庫檔案,會使用到 --whole-archive 和 --no-whole-archive這2個ld連結選項。–whole-archive 可以把 在其後面出現的靜態庫包含的函式和變數輸出到動態庫,–no-whole-archive 則關掉這個特性。在檔案vendor\goodix\gr5515_sk_xts_demo\BUILD.gn中,對ACTS的編譯檔案進行連結。其中⑴到⑵處的連結選項為編譯出的屬於ACTS的元件測試庫檔案。
executable("${fw_img_name}.elf") { deps = [ "tests:drivers", "tests:fs_test", "tests:ohosdemo", "tests:shell_test", "//build/lite:ohos", ] ldflags = [ "-Wl,--whole-archive", # "-lfs_test", # "-ldrivers_test", # "-lapp_hello", "-lshell_test", ⑴ "-lhctest", "-lmodule_ActsBootstrapTest", "-lmodule_ActsWifiIotTest", "-lmodule_ActsUtilsFileTest", "-lmodule_ActsKvStoreTest", "-lmodule_ActsParameterTest", "-lmodule_ActsSamgrTest", "-lhuks_test_common", "-lmodule_ActsHuksHalFunctionTest", "-lmodule_ActsDfxFuncTest", "-lmodule_ActsUpdaterFuncTest", ⑵ "-lmodule_ActsHieventLiteTest", "-Wl,--no-whole-archive", ] }
在檔案vendor\bestechnic\xts_demo\config.json中,需要連結的ACTS部件測試庫檔案寫在了bin_list裡的force_link_libs裡。
"bin_list": [ { "elf_name": "wifiiot", "bsp_target_name": "best2600w_liteos", "signature": "false", "burn_name": "rtos_main", "enable": "true", "force_link_libs": [ "bootstrap", "abilityms", "bundlems", "broadcast", "hctest", ⑴ "module_ActsParameterTest", "module_ActsBootstrapTest", "module_ActsDfxFuncTest", "module_ActsHieventLiteTest", "module_ActsSamgrTest", ⑵ "module_ActsKvStoreTest" ] }, ....... ],
然後在檔案device\soc\bestechnic\bes2600\BUILD.gn裡組裝編譯連結選項,相關程式碼片段如下:
# config bin from vendor/bestechnic/<product_name>/config.json foreach(bin_file, bin_list) { ...... if (build_enable == "true") { ...... # force link invisible function ,which ar to lib ldflags += [ "-Wl,--whole-archive" ] foreach(force_link_lib, bin_file.force_link_libs) { ldflags += [ "-l${force_link_lib}" ] } ldflags += [ "-lbsp${bsp_target_name}" ] ldflags += [ "-Wl,--no-whole-archive" ] ...... } }
在檔案vendor_asrmicro\xts_demo\config.json中,存在這樣的配置片段。
"xts_list": [ { "enable": "true", "xts_modules": [ "ActsKvStoreTest", "ActsDfxFuncTest", "ActsHieventLiteTest", "ActsSamgrTest", "ActsParameterTest", "ActsWifiServiceTest", "ActsWifiIotTest", "ActsBootstrapTest" ] } ]
然後,在檔案device_soc_asrmicro\asr582x\liteos_m\sdk\BUILD.gn檔案中組裝編譯連結選項。
foreach(xts_item, xts_list) { xts_enable = xts_item.enable if(xts_enable == "true") { defines = [ "CFG_HARMONY_SUPPORT" ] ldflags += [ "-Llibs", "-Wl,--whole-archive", "-lhctest", "-lbootstrap", "-lbroadcast", ] foreach(xts_module, xts_item.xts_modules) { ldflags += [ "-lmodule_${xts_module}" ] } ldflags += [ "-Wl,--no-whole-archive" ] } }
在產品解決方案配置檔案中增加的bin_list、xts_list這些配置選項都不是config.json中的預設的標準選項。各個方案實現的風格差異比較大,建議使用第一種,寫在檔案vendor\goodix\gr5515_sk_xts_demo\BUILD.gn中會比較好。另外,需要使用hb命令觸發debug版本(非debug版本不會觸發測試編譯)。
2、XTS子系統編譯流程
2.1 hb編譯構建工具讀取config.json
編譯構建工具hb會讀取產品解決方案配置文,獲取參與編譯的子系統以及部件資訊。XTS測試支援對各個子系統、部件的介面進行測試,產品解決方案配置了哪些子系統才會對這些配置的子系統進行測試。後文會繼續解釋。
2.2 XTS編譯配置檔案
在檔案中test\xts\acts\build_lite\BUILD.gn中,定義了ACTS的測試套件。⑴處的ohos_xts_test_args表示,如果指定了具體的xts的測試套件,則只編譯xts測試編譯選項中指定的測試套件,後文會分析怎麼在編譯構建時指定測試套件。如果沒有在編譯構建時指定測試套件,則預設編譯全部的測試套件。對於不同的核心型別,測試套件是有差異的,如⑵所示。對於輕量系統,支援的測試套件主要包含communication_lite、startup_lite、iot_hardware_lite、security_lite、hiviewdfx_lite、distributed_schedule_lite、update_lite、utils_lite等子系統及其部件。
all_features = [] features = [] ⑴ if (ohos_xts_test_args != "") { args = [ "--method_name", "get_target_modules", "--arguments", "all_features=${ohos_xts_test_args}", ] all_features += exec_script(rebase_path("//test/xts/tools/lite/build/utils.py"), args, "list lines") } else { ⑵ if (ohos_kernel_type == "liteos_m") { all_features += [ "//test/xts/acts/communication_lite/lwip_hal:ActsLwipTest", "//test/xts/acts/communication_lite/wifiservice_hal:ActsWifiServiceTest", "//test/xts/acts/utils_lite/file_hal:ActsUtilsFileTest", "//test/xts/acts/startup_lite/syspara_hal:ActsParameterTest", "//test/xts/acts/iot_hardware_lite/iot_controller_hal:ActsWifiIotTest", "//test/xts/acts/utils_lite/kv_store_hal:ActsKvStoreTest", "//test/xts/acts/security_lite/huks/liteos_m_adapter:ActsHuksHalFunctionTest", "//test/xts/acts/hiviewdfx_lite/hilog_hal:ActsDfxFuncTest", "//test/xts/acts/hiviewdfx_lite/hievent_hal:ActsHieventLiteTest", "//test/xts/acts/distributed_schedule_lite/system_ability_manager_hal:ActsSamgrTest", "//test/xts/acts/update_lite/dupdate_hal:ActsUpdaterFuncTest", "//test/xts/acts/startup_lite/bootstrap_hal:ActsBootstrapTest", ] } else if (ohos_kernel_type == "liteos_a") { all_features += [ ...... ] } else if (ohos_kernel_type == "linux") { all_features += [ ...... ] } }
在該檔案中,還有如下程式碼片段。可以看出,只要構建型別為debug並且沒有指定notest測試編譯選項時才會編譯ACTS測試套。測試編譯選項的指定如下所示:hb build -t notest。
if (ohos_build_type == "debug" && ohos_test_args != "notest") { _all_features = "" _product_json = rebase_path("${product_path}/config.json") foreach(one_feature, all_features) { _all_features = _all_features + one_feature + "," } _args = [ "--method_name", "filter_by_subsystem", "--arguments", "testsuites=${_all_features}#product_json=${_product_json}", ] features += exec_script(rebase_path("//test/xts/tools/lite/build/utils.py"), _args, "list lines") }
接下來看下,如何在編譯時指定特定的XTS測試套件進行編譯。上文提到的ohos_xts_test_args在檔案build\lite\hb_internal\build\build_process.py中,程式碼如下。可以看出測試套件相關的編譯選項有xts和notest兩種。⑵處當指定xts測試編譯選項時,緊接著指定的測試套件會儲存進變數ohos_xts_test_args。支援指定的測試套件,應該需要來自上文中的全部的測試套件。具體的使用示例為:hb build -t xts //test/xts/acts/communication_lite/lwip_hal:ActsLwipTest。不過這樣的用法應該比較罕見,使用全量編譯測試套件的就好。
@test.setter def test(self, test_args): ⑴ cmd_list = ['xts', 'notest'] if test_args[0] in cmd_list: if test_args[0] == 'notest': self.register_args('ohos_test_args', 'notest') else: ⑵ self._test = test_args[1] if len(test_args) > 1: self.register_args('ohos_xts_test_args', self._test) else: raise OHOSException('Error: wrong input of test')
2.3 生成的測試套的庫檔案
成功編譯後,在編譯構建輸出目錄,如out/v200zr/xts_demo/libs,生成測試套和測試框架的庫檔案,XTS子系統測試套.a歸檔格式為:libmodule_{測試套件模組名稱}.a,測試框架歸檔格式:libhctest.a。這些生成的檔案和上文中的連結選項可以對應起來。
-rw-r--r-- 1 zhushangyuan zhushangyuan 28842 Feb 10 16:49 libhctest.a -rw-r--r-- 1 zhushangyuan zhushangyuan 53024 Feb 10 16:49 libhuks_test_common.a -rw-r--r-- 1 zhushangyuan zhushangyuan 22562 Feb 10 16:49 libmodule_ActsBootstrapTest.a -rw-r--r-- 1 zhushangyuan zhushangyuan 7560 Feb 10 16:49 libmodule_ActsDfxFuncTest.a -rw-r--r-- 1 zhushangyuan zhushangyuan 6096 Feb 10 16:49 libmodule_ActsHieventLiteTest.a -rw-r--r-- 1 zhushangyuan zhushangyuan 96278 Feb 10 16:49 libmodule_ActsHuksHalFunctionTest.a -rw-r--r-- 1 zhushangyuan zhushangyuan 31346 Feb 10 16:49 libmodule_ActsKvStoreTest.a -rw-r--r-- 1 zhushangyuan zhushangyuan 69010 Feb 10 16:49 libmodule_ActsParameterTest.a -rw-r--r-- 1 zhushangyuan zhushangyuan 197120 Feb 10 16:49 libmodule_ActsSamgrTest.a -rw-r--r-- 1 zhushangyuan zhushangyuan 8256 Feb 10 16:49 libmodule_ActsUpdaterFuncTest.a -rw-r--r-- 1 zhushangyuan zhushangyuan 20968 Feb 10 16:49 libmodule_ActsWifiServiceTest.a
3、 移植適配XTS定製選項
在移植案例時,產品配置檔案中適配XTS子系統時,有時候指定了定製選項如config_ohos_xts_acts_utils_lite_kv_store_data_path、enable_ohos_test_xts_acts_use_thirdparty_lwip等等。本小節專門看下這些定製選項。
3.1 ohos_xts_test_args
該選項宣告在檔案test\xts\tools\lite\build\suite_lite.gni中。前文已經瞭解到,編譯構建命令列可以指定要編譯的xts測試套件。理論上,也可以在產品解決方案配置檔案中指定。注意不能同時在編譯構建命令列引數中指定,會覆蓋。無用的知識點又增加了。
declare_args() { ohos_xts_test_args = "" }
3.2 enable_ohos_test_xts_acts_use_thirdparty_lwip
該選項enable_ohos_test_xts_acts_use_thirdparty_lwip宣告在檔案test\xts\acts\communication_lite\lwip_hal\BUILD.gn,預設為true。在移植適配時,繼續指定該選項為true,可以說是不必要的。
declare_args() { enable_ohos_test_xts_acts_use_thirdparty_lwip = true }
該選項的作用是什麼呢?在檔案test\xts\acts\communication_lite\lwip_hal\BUILD.gn中,⑴處表明,會依賴Liteos_m核心編譯。從選項的名字和實際的作用,讓人摸不著頭腦。
hctest_suite("ActsLwipTest") { suite_name = "acts" sources = [ "src/lwip_func_test.c" ] if (enable_ohos_test_xts_acts_use_thirdparty_lwip) { ⑴ deps = [ "//kernel/liteos_m:kernel" ] } cflags = [ "-Wno-error" ] }
3.3 config_ohos_xts_acts_utils_lite_kv_store_data_path
該選項config_ohos_xts_acts_utils_lite_kv_store_data_path宣告在檔案test\xts\acts\utils_lite\kv_store_hal\BUILD.gn,如下⑴處所示。注意下⑵處把這個配置define為了DATA_PATH。
declare_args() { ⑴ config_ohos_xts_acts_utils_lite_kv_store_data_path = "" } hctest_suite("ActsKvStoreTest") { suite_name = "acts" sources = [ "src/kvstore_func_test.c" ] include_dirs = [ "src", "//utils/native/lite/include", "//base/iot_hardware/peripheral/interfaces/kits", ] cflags = [ "-Wno-error" ] defines = ⑵ [ "DATA_PATH=\"${config_ohos_xts_acts_utils_lite_kv_store_data_path}\"" ] }
在檔案test\xts\acts\utils_lite\kv_store_hal\src\kvstore_func_test.c中,有如下程式碼。在移植適配XTS子系統時,還必須要加上這一行 “config_ohos_xts_acts_utils_lite_kv_store_data_path = “/data””。如果不加的話,config_ohos_xts_acts_utils_lite_kv_store_data_path等於空字串“”,DATA_PATH被定義了空字串“”,沒有起到提供預設值的作用。
#ifndef DATA_PATH #define DATA_PATH "/data" #endif
參考站點
參考了下述站點,或者推薦讀者閱讀下述站點了解更多資訊。