!215 更新日志打印以及Readme文档

Merge pull request !215 from liguangjie/master
This commit is contained in:
openharmony_ci 2023-03-27 14:04:27 +00:00 committed by Gitee
commit 8672038cc1
No known key found for this signature in database
GPG Key ID: 173E9B9CA92EEF8F
3 changed files with 486 additions and 160 deletions

View File

@ -1,28 +1,28 @@
# xdevice组件<a name="ZH-CN_TOPIC_0000001083129731"></a> # xdevice
- [xdevice](#xdevice组件)
- [简介](#section15701932113019) - [简介](#简介)
- [目录](#section1791423143211) - [目录](#目录)
- [约束](#section118067583303) - [约束](#约束)
- [使用](#section2036431583) - [使用](#使用)
- [相关仓](#section260848241) - [相关资料](#相关资料)
- [相关仓](#相关仓)
## 简介<a name="section15701932113019"></a>
## 简介
xdevice是OpenHarmony中为测试框架的核心组件提供用例执行所依赖的相关服务。 xdevice是OpenHarmony中为测试框架的核心组件提供用例执行所依赖的相关服务。
xdevice主要包括以下几个主要模块 xdevice主要包括以下几个主要模块
- command用户与测试平台命令行交互模块提供用户输入命令解析命令处理。 - command用户与测试平台命令行交互模块提供用户输入命令解析命令处理。
- config测试框架配置模块提供测试平台串口连接方式和USB连接方式的不同配置选项。 - config测试框架配置模块提供测试平台串口连接方式和USB连接方式的不同配置选项。
- driver测试用例执行器提供测试用例分发执行结果收集等主要测试步骤定义。 - driver测试用例执行器提供测试用例分发执行结果收集等主要测试步骤定义。
- report测试报告模块提供测试结果解析和测试报告生成。 - report测试报告模块提供测试结果解析和测试报告生成。
- scheduler测试框架调度模块提供不同类型的测试执行器调度的调度功能。 - scheduler测试框架调度模块提供不同类型的测试执行器调度的调度功能。
- environment测试框架的环境配置模块提供设备发现设备管理的功能。 - environment测试框架的环境配置模块提供设备发现设备管理的功能。
- testkit测试框架工具模块提供json解析网络文件挂载等操作。 - testkit测试框架工具模块提供json解析网络文件挂载等操作。
- resource测试框架资源模块提供设备连接配置文件和报告模板定义。 - resource测试框架资源模块提供设备连接配置文件和报告模板定义。
## 目录<a name="section1791423143211"></a>
## 目录
``` ```
xdevice xdevice
├── config # xdevice组件配置 ├── config # xdevice组件配置
@ -33,192 +33,301 @@ xdevice
| |—— ohos # openharmony测试驱动插件 | |—— ohos # openharmony测试驱动插件
│ ├── src # 扩展模块源码 │ ├── src # 扩展模块源码
│ └── setup.py # ohos扩展模块安装脚本 │ └── setup.py # ohos扩展模块安装脚本
| |--devicetest # devicetest测试驱动插件
| └── setup.py # deviectest扩展模块安装脚本
``` ```
## 约束<a name="section118067583303"></a>
## 约束
运行环境要求: 运行环境要求:
- python版本\>=3.7.5 - python版本>=3.7.5
- pyserial\>=3.3 - pyserial>=3.3
- paramiko\>=2.7.1 - paramiko>=2.7.1
- rsa\>=4.0 - rsa>=4.0
## 使用<a name="section2036431583"></a> ## 使用
- **安装xdevice**
- **安装xdevice** 1. 打开xdevice安装目录。
1. 打开xdevice安装目录。
2. 打开控制台,执行如下命令:
``` 2. 打开控制台,执行如下命令:
python setup.py install ```
``` python setup.py install
```
- **安装ohos扩展模块**
- **安装extension** 1. 打开plugins\ohos安装目录。
1. 打开extension安装目录。
2. 打开控制台,执行如下命令:
``` 2. 打开控制台,执行如下命令:
python setup.py install ```
``` python setup.py install
```
- **修改user\_config.xml**
- **修改user\_config.xml**
user\_config.xml是框架提供的用户配置文件用户可以根据自身环境信息配置相关内容具体介绍如下 user\_config.xml是框架提供的用户配置文件用户可以根据自身环境信息配置相关内容具体介绍如下
**1、environment环境相关配置** 1. **environment环境相关配置**
- 设备类型一 以下列出三种device配置。
>![](figures/icon-note.gif) **说明:**
>ip/port: 表示远程设备地址默认情况为空表示使用本地设备ip地址为127.0.0.1port为本机hdc启动端口号
>sn: 过滤执行测试设备若设置为SN1则表示只有设备SN1能够支持后续run命令执行其他设备分配状态设置为Ignored不参与命令执行可通过list devices命令中Allocation字段来查看sn设置可配置多个sn中间以;隔开;
- 设备类型二
>![](figures/icon-note.gif) **说明:**
>type: 设备连接方式com表示连接方式是串口
>label: 表示设备种类如wifiiot
>serial: 表示一个串口定义
>serial/com 表示本地连接的串口如COM20 serial/type 表示串口类型cmd是命令串口deploy是刷机串口社区版本cmd和deploy使用同一个串口com值相同
>serial/baud\_rate、data\_bits、stop\_bits、timeout: 为串口波特率等串口参数 ,一般采用默认值即可。
**2、测试用例目录设置**
dir: 指定测试用例目录。 ```xml
<environment>
<!-- 标准系统设备配置>
<device type="usb-hdc"> <!-- type: 设备连接方式,usb-hdc表示使用hdc命令控制设备(默认) -->
<ip></ip> <!-- ip: 远端设备地址,ip和port为空时使用本地设备,非空时使用远端设备 -->
<port></port> <!-- port: 远端设备端口号 -->
<sn></sn> <!-- sn: 设备串口号列表,串口号之间用分号;分隔,sn为空时使用所有本地设备,非空时使用指定的sn设备 -->
</device>
<!-- 轻量系统设备配置(轻量系统设备进行测试时需要刷入已经集成好测试用例的系统所以需要配置两个串口进行通信如设备支持可以将两个serial标签的com口设置为一致),可配置多个 -->
<device type="com" label="wifiiot"> <!-- type: 设备连接方式com表示连接方式为串口label设备种类如wifiiot -->
<serial> <!-- serial表示一个串口定义 -->
<com></com> <!-- serial表示本地连接的串口如COM4 -->
<type>cmd</type> <!-- type表示串口类型cmd为命令串口 -->
<baud_rate>115200</baud_rate> <!-- baud_rate、data_bits、stop_bits、timeout为串口波特率等串口参数一般采用默认值即可 -->
<data_bits>8</data_bits>
<stop_bits>1</stop_bits>
<timeout>20</timeout>
</serial>
<serial>
<com></com>
<type>deploy</type> <!-- type表示串口类型cmd为刷机串口 -->
<baud_rate>115200</baud_rate>
</serial>
</device>
<!-- 小型系统设备配置,可配置多个 -->
<device type="com" label="ipcamera">
<serial>
<com></com>
<type>cmd</type>
<baud_rate>115200</baud_rate>
<data_bits>8</data_bits>
<stop_bits>1</stop_bits>
<timeout>1</timeout>
</serial>
</device>
<device type="com" label="ipcamera">
<ip></ip>
<port></port>
</device>
</environment>
```
2. **测试用例目录设置**
**3、nfs挂载** 以下为testcase标签内容及作用。
>![](figures/icon-note.gif) **说明:** ```xml
>server: nfs挂载配置label取值为NfsServer。 <testcases>
>server/ip: 挂载环境IP地址。 <!-- dir标签和server标签同时配置时只有一个会起作用 -->
>server/port: 挂载环境端口。 <!-- 指定测试用例目录为空则默认设置为当前项目下的testcase文件夹 -->
>server/username: 登录用户名。 <dir></dir>
>server/password: 登录用户密码。 <!-- nfs挂载配置label取值为NfsServer -->
>server/dir: 对应挂载的外部路径。 <server label="NfsServer">
>server/remote: nfs服务器与xDevice执行机不在同一台机器时remote配置为true否则为false。 <ip></ip> <!-- 挂载环境IP地址 -->
<port></port> <!-- 挂载环境端口 -->
<dir></dir> <!-- 对应挂载的外部路径 -->
<username></username> <!-- 登录用户名(remote为false时可不填或删除) -->
<password></password> <!-- 登录密码(remote为false时可不填或删除) -->
<remote></remote> <!-- nfs服务器与xDevice执行机不在同一机器时remote配置为true否则为false -->
</server>
</testcases>
```
3. **资源目录设置**
以下为resource标签内容及作用。
```xml
<resource>
<!-- 指定资源目录为空则默认设置为当前项目下的resource文件夹 -->
<dir></dir>
</resource>
```
4. **日志打印等级设置**
以下为loglevel标签内容及作用。
```xml
<!-- 默认为INFO如需更详细信息可设置为DEBUG -->
<loglevel>INFO</loglevel>
```
- **选定任务类型** - **选定任务类型**
- **启动框架**
- **执行指令** 设备执行的测试支撑套件是由测试配置文件所指定。
框架指令可以分为三组help、list、run。在指令序列中以run为最常用的执行指令。 每类XTS测试套都有一个json格式的测试配置文件主要配置了需要使用的kits(测试支撑套件)等信息,执行预制和清理操作
**1、help** 以下为某个测试支撑套件的json配置文件样例。
输入help指令可以查询框架指令帮助信息。
```json
{
//测试支撑套件描述
"description":"Configuration for acecshi Tests",
//指定执行当前测试支撑套件的设备
//environment设置为可选,如不设置,将从框架中注册的设备中选择一个符合的空闲设备执行用例
"environment":{
"type":"device",
"label":"wifiiot"
},
//指定设备执行的驱动
"driver":{
"type":"OHJSUnitTest",
"test-timeout":"700000",
"bundle-name":"com.open.harmony.acetestfive",
"package-name":"com.open.harmony.acetestfive",
"shell-timeout":"700000",
},
//kit的作用是为了支撑测试执行活动
"kits":[
{
"type":"ShellKit",
"run-command":[
"remount",
"mkdir /data/data/resource"
],
"teardown-command":[
"remount",
"rm -rf /data/data/resource"
]
}
]
}
``` ```
help:
- **启动框架**
可以通过以下几种方式启动框架
- Linux系统可以运行根目录下的run.sh文件
- Windows系统可以运行根目录下的run.bat文件
- Linux和Windows系统皆可运行项目目录下的src\xdevice\\\_\__main___.py文件
- **执行指令**
框架指令可以分为三组help、list、run。在指令序列中以run为最常用的执行指令。
1. **help**
输入help指令可以查询框架指令帮助信息。
```bash
help:
use help to get information. use help to get information.
usage: usage:
run: Display a list of supported run command. run: Display a list of supported run command.
list: Display a list of supported device and task record. list: Display a list of supported device and task record.
Examples: Examples:
help run help run
help list help list
``` ```
>![](figures/icon-note.gif) **说明:** 说明: help run展示run指令相关说明 help list展示 list指令相关说明。
>help run展示run指令相关说明
>help list展示 list指令相关说明
**2、list** 2. **list**
list指令用来展示设备和相关的任务信息 list指令用来展示设备和相关的任务信息
``` ```bash
list: list:
This command is used to display device list and task record. This command is used to display device list and task record.
usage: usage:
list list
list history list history
list <id> list <id>
Introduction: Introduction:
list: display device list list: display device list
list history: display history record of a serial of tasks list history: display history record of a serial of tasks
list <id>: display history record about task what contains specific id list <id>: display history record about task what contains specific id
Examples: Examples:
list list
list history list history
list 6e****90 list 6e****90
``` ```
>![](figures/icon-note.gif) **说明:** 说明: list: 展示设备信息 list history: 展示任务历史信息 list <id>: 展示特定id的任务其历史信息。
>list: 展示设备信息
>list history: 展示任务历史信息
>list <id\>: 展示特定id的任务其历史信息
**3、run** 3. **run**
run指令主要用于执行测试任务 run指令主要用于执行测试任务
``` ```bash
run: run:
This command is used to execute the selected testcases. This command is used to execute the selected testcases.
It includes a series of processes such as use case compilation, execution, and result collection. It includes a series of processes such as use case compilation, execution, and result collection.
usage: run [-l TESTLIST [TESTLIST ...] | -tf TESTFILE usage: run [-l TESTLIST [TESTLIST ...] | -tf TESTFILE
[TESTFILE ...]] [-tc TESTCASE] [-c CONFIG] [-sn DEVICE_SN] [TESTFILE ...]] [-tc TESTCASE] [-c CONFIG] [-sn DEVICE_SN]
[-rp REPORT_PATH [REPORT_PATH ...]] [-rp REPORT_PATH [REPORT_PATH ...]]
[-respath RESOURCE_PATH [RESOURCE_PATH ...]] [-respath RESOURCE_PATH [RESOURCE_PATH ...]]
[-tcpath TESTCASES_PATH [TESTCASES_PATH ...]] [-tcpath TESTCASES_PATH [TESTCASES_PATH ...]]
[-ta TESTARGS [TESTARGS ...]] [-pt] [-ta TESTARGS [TESTARGS ...]] [-pt]
[-env TEST_ENVIRONMENT [TEST_ENVIRONMENT ...]] [-env TEST_ENVIRONMENT [TEST_ENVIRONMENT ...]]
[-e EXECTYPE] [-t [TESTTYPE [TESTTYPE ...]]] [-e EXECTYPE] [-t [TESTTYPE [TESTTYPE ...]]]
[-td TESTDRIVER] [-tl TESTLEVEL] [-bv BUILD_VARIANT] [-td TESTDRIVER] [-tl TESTLEVEL] [-bv BUILD_VARIANT]
[-cov COVERAGE] [--retry RETRY] [--session SESSION] [-cov COVERAGE] [--retry RETRY] [--session SESSION]
[--dryrun] [--reboot-per-module] [--check-device] [--dryrun] [--reboot-per-module] [--check-device]
[--repeat REPEAT] [--repeat REPEAT]
action task action task
Specify tests to run. Specify tests to run.
positional arguments: positional arguments:
action Specify action action Specify action
task Specify task name,such as "ssts", "acts", "hits" task Specify task name,such as "ssts", "acts", "hits"
``` ```
>![](figures/icon-note.gif) **说明:** run常用指令基本使用方式如下。
>一个基本的run指令结构如下
>```
>run [task name] -l module1;moudle2
>```
>task name任务类型。一般为ssts、acts、hits。非必选项
>-l :指定执行测试用例,多个测试用例,中间用;隔开
>module被测试的模块。一般在testcases目录下存在对应的\\.json文件
>此外,其他参数可以作为约束条件,附加到这个基本指令之上使用。常用的如:
>-sn: 过滤执行测试设备若设置为SN1则表示只有设备SN1执行用例
>-c: 重新指定user\_config.xml。
>-rp: 报告生成路径。默认为xxx/xdevice/reports目录。指定目录后优先级:指定目录\>xxx/xdevice/reports目录。
>-tcpath环境目录默认为xxx/xdevice/testcases目录。指定目录后优先级:指定目录\>xxx/xdevice/testcases目录
>-respath测试套目录默认为xxx/xdevice/resource目录。指定目录后优先级:指定目录\>xxx/xdevice/resource目录
>--reboot-per-module: 执行前先重启设备
- **查看执行结果** | xDevice命令 | 功能 | 示例 |
| :---------------------- | :----------------------------------------------------------- | :----------------------------------------------------------- |
框架执行run指令控制台会输出对应的log打印还会生成对应的执行结果报告。如果使用了-rp参数指定报告路径那么报告就会生成在指定的路径下。否则报告会存放在默认目录。 | run xts | 运行所有指定类型的xts模块如actshitsssts等 | run acts |
| run -l XXX | 运行指定测试套。如有多个测试套,测试套之间以分号分隔 | run -l ActsWifiServiceTest;ActsLwipTesttestcase目录下的测试套名称 |
``` | run -sn | 指定运行设备sn号多个sn号之间以分号分隔 | run acts -sn 10.11.133.22:12345 <br/> run acts -sn 2222122;22321321 |
当前报告目录(默认目录/指定目录) | run -rp | 指定报告生成路径默认报告生成在项目根目录下的reports文件夹以时间戳或任务id建立子目录 | run acts -rp /XXXX/XXX |
├── result模块执行结果存放目录 | run -respath | 指定测试资源路径默认为项目根目录下的resource文件夹 | run -respath /XXX/XXX/XXX |
│ ├── <模块名>.xml | run -tcpath | 指定测试用例路径,默认为项目根目录下的testcases文件夹 | run -tcpath /XXX/XXX/XXX |
│ ├── ... ... | run - ta | 指定模块运行参数可以指定运行测试套中的某个用例多个用例之间以逗号分隔目前只支持hits | run hits -ta size:large <br/> run hits -l XXXTest -ta class:XXXX(类名)#XXXXX(方法名) |
| run --retry | 重新运行上次失败的测试用例 | run --retry --session 2022-12-13-12-21-11(report任务报告目录) |
├── log (设备和任务运行log存放目录) | run --reboot-per-module | 执行前先重启设备 | run --reboot-per-module -l XXXX |
│ ├── <设备1>.log
│ ├── ... ...
│ ├── <任务>.log
├── summary_report.html测试任务可视化报告
├── summary_report.html测试任务数据化报告
└── ... ...
```
## 相关仓<a name="section260848241"></a> - **查看执行结果**
[测试子系统](https://gitee.com/openharmony/docs/blob/master/zh-cn/readme/%E6%B5%8B%E8%AF%95%E5%AD%90%E7%B3%BB%E7%BB%9F.md) 框架执行run指令控制台会输出对应的log打印还会生成对应的执行结果报告。如果使用了-rp参数指定报告路径那么报告就会生成在指定的路径下。否则报告会存放在默认目录。
**test\_xdevice** ```
当前报告目录(默认目录/指定目录)
├── result模块执行结果存放目录
│ ├── <模块名>.xml
│ ├── ... ...
├── log (设备和任务运行log存放目录)
│ ├── <设备1>.log
│ ├── ... ...
│ ├── <任务>.log
├── summary_report.html测试任务可视化报告
├── summary_report.html测试任务数据化报告
├── detail_report.html详细执行用例结果可视化报告
├── failures_report.html失败用例可视化报告无失败用例时不生成
├── summary.ini记录测试类型使用的设备开始时间和结束时间等信息
├── task_info.record记录执行命令失败用例等清单信息
├── XXX.zip对上述文件进行压缩得到的文件
├── summary_report.hash对压缩文件进行SHA256加密得到的文件
└── ... ...
```
[test\_developertest](https://gitee.com/openharmony/test_developertest/blob/master/README_zh.md) ## 相关仓
[测试子系统](https://gitee.com/openharmony/docs/blob/master/zh-cn/readme/%E6%B5%8B%E8%AF%95%E5%AD%90%E7%B3%BB%E7%BB%9F.md)
**test\_xdevice**
[test\_developertest](https://gitee.com/openharmony/test_developertest/blob/master/README_zh.md)

216
docs/Command_Run.md Normal file
View File

@ -0,0 +1,216 @@
# run命令
**run命令比较复杂包含多种选项。框架在解析run命令的组合后根据命令运行测试套。run命令涉及的选项可分为执行类选项和约束类选项。**
## 1.执行类选项
> 执行选项是与下文约束选项相对的概念。执行选项可以和run命令进行组合形成一条有效的运行命令从而将测试套运行起来。约束选项则用于约束测试套运行时的行为光有约束选项执行框架是无法正确运行的。
- run
运行所有执行类型的xts测试套如actshitsssts等
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| run xts测试套名 | 运行所有执行类型的测试套 | run acts |
- run -l
运行指定的测试套。长选项为"run --testlist"。后面的之为测试套配置文件列表。命令执行后框架会在testcases目录下找到对应的"测试套名.json",然后解析执行。
如下所示,用户输入 ACtsWifiTest 和 ActLwipTest两个模块要求框架执行。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| run -l 测试套1;测试套2 | 测试套之间以分号分隔 | run -l ActsWifiTest;ActsLwipTest |
- run -tf
指定测试套文件。长选项表示为"run --testfile"。
如下所示用户指定了test/resoucre/test.txt文件作为模块选项的来源文件框架将读取这个文件中的内容解析后执行。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| run -tf 测试套文本路径 | 用户可以指定一个测试套文件让框架来执行 | run -tf test/resoucre/test.txt |
- run -tc
指定测试用例。长选项表示为"run --testcase"。只支持devicetest类型的python用例
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| run -tc 测试用例文件名(无后缀) | 只支持devicetest类型的python用例 | run -tc XXX |
- run --retry
重新运行上一次的任务或者指定session的失败用例重新生成测试报告。
如下所示实例输入了一个session id那么框架将在报告路径下找到这个包含这个session id的目录从smmary_report.html中解析出失败用例重新运行。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| run --retry [--session session路径] | 如不指定session则重新运行上次失败的用例。否则执行session中的失败用例 | run --retry <br> run --retry --session 2022-10-12-12-12-12 |
## 2.约束选项
> 约束选项可以用于修饰执行选项也可以修饰约束选项。单独的约束选项和run命令的组合是无法被框架理解和执行的。
- -sn
通过设置参数的值来指定运行的设备
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| -sn 设备唯一标识号 | 参数后的值为sn号或idport的字符格式。多个设备之间以分号分隔。 | run acts -sn 10.117.22.3:123 <br> run acts -sn 12321412;123213123 |
- -rp
指定报告生成路径。长选项表示为"--reportpath"。默认会在项目的reports文件夹下用时间戳或任务id建立子目录。
如下所示,示例将报告生成路径进行了更改。本次执行任务的报告将生成在指定目录下。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| -rp 指定路径 | 使用指定的路径将体态默认的报告生成路径 | run acts -rp /suites/hits/resport/XXXX |
- -respath
指定测试所需要的资源路径。长选项表示为"--resourcepath"。如果设置了此参数,框架在加载资源时,会在指定目录下查找。
如下所示,示例设置了对应的资源路径。那么任务后续将在此目录下读取对应的资源进行操作。
| 格式 | 使用说明 | 实例 |
| :---------------------- | :----------------------------------------------------------- | :------------------------------------------ |
| -respath 指定的资源路径 | 资源目录默认为项目下的resoucre。如果用户设置了此参数则将资源目录设为指定文件夹 | run acts -respath /suites/hits/res/resuorce |
- -ta
指定测试套运行参数,约束测试套在运行时的行为。长选项表示为"--targets"。-ta后的参数最终会被框架获取、解析、拼接成命令。
如下所示,-ta后的值将被框架读到并指定模块后续行为。
以下可用参数只对OHJS驱动有效
| 可用参数 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| class | 可以指定运行测试套中的指定用例,多个用例间以逗号分隔。 | run -l SoundTriggerTest -ta class:android.harware.SoundTriggerTest#testKey解释只运行SoundTriggerTest测试套下的testKey用例SoundTriggerTest中其他用例均不执行 |
| notClass | 指定不允许测试套中的哪些用例 | run -l SoundTriggerTest -ta notClass:android.harware.SoundTriggerTest#testKey解释除了SoundTriggerTest测试套下的testKey用例SoundTriggerTest中其他用例均执行 |
| stress | 指定测试套的运行次数 | run -l SoundTriggerTest -ta stress:100解释将测试套SoundTriggerTest运行100次 |
| level | 用例级别,可选参数:"0","1","2","3" | run -l SoundTriggerTest -ta level:1解释指定测试套SoundTriggerTest的用例级别为1 |
| size | 用例粒度,可选参数:"small","medium","large" | run -l SoundTriggerTest -ta size:small解释指定测试套SoundTriggerTest的用例粒度为small |
| testType | 用例测试类型,可选参数:"function","performance","reliability","security" | run -l SoundTriggerTest -ta testType:function解释指定测试套SoundTriggerTest的测试用例类型为function |
- -pt
指定-ta选项后的值的解析方式。长选项表示为"--passthrough"。需要配合-ta使用。-ta选项后的值框架默认他是以组合方式存在的多个组合之间以分号进行分隔。组合中如果存在多个元素则元素之间以逗号进行分隔。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| -pt true/false | 如果指定为true则-ta参数的值会被框架整体作为一个字符串来解析。如果为false则会按照默认的方式解析 | run hits -ta size:large -pt false |
- -env
指定配置文件内容。长选项表示为"-- environment"。用户设置了配置文件内容后框架将不再读取config/user_config.xml而是解析指定的xml字符串内容。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| -env xml字符串 | Xml字符串必须符合user_config.xml规范。并且各个层级之间不允许存在换行符 | run -l XXXTest -env xxx |
- -c
指定当前任务的user_config.xml所在路径。长选项表示为"--config"。参数为一段有效路径。同-env命令有些相似不过-env命令是将整个xml内容输入。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| -c 包含user_config.xml的路径 | 框架将优先从指定路径中去读取user_config.xml | run -l XXXTest -c xxx |
- -t
指定当前任务的测试类型。长选项表示为"--testtype"。其值主要使用在可视化报告中默认为Test。可选类型有UTMSTSTPERFSECRELIDSTAll。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| -t 类型名 | 如不填写summary_report.html中默认为Test | run -l XXXTest -t ALL |
- -td
指定当前任务使用的驱动id。长选项表示为"--testdriver"。可填写的内容详见[测试支撑套件配置中的driver类型]()。
如下所示ANSModuleTest模块使用CppTest作为驱动id。框架会使用CppTest的对应驱动执行任务。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| -td 驱动id | 驱动id必须是框架提供的类型字符串 | run -l ANSModuleTest -td CppTest |
- -tcpath
指定用例测试用例路径。长选项表示为"--testcasespath"。框架默认使用项目下的testcase文件夹作为用例路径如果指定了用例路径则在指定路径下查找测试用例。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| -tcpath 用例路径 | | run -l XXXTest -tcpath D:/xxxx/xxxx |
- --session
指定运行session id下的内容。约束选项需配合--retry使用。
如下所示示例中指定了session id。框架在执行retry操作时会在报告路径下寻找对应的文件进行解析获取到失败的测试用例列表然后重新执行。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| --session sessionID | 重新执行指定sessionid中的失败用例 | run --retry --session 2022-12-11-12-11-22 |
- --dryrun
列举上次失败的测试用例选项。约束参数,需配合--retry使用。结果集打印分成几大部分。
> Session id框架记录的上次任务的Session编号
> Command上次任务使用的命令
> ReportPath上次任务报告路径
> CasesInfo上次任务的用例选项包括模块Module、测试套TestSuit、测试用例TestCase
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| run --retry --dryrun | 固定用法。用于获取上次的失败用例的详细信息。结果分列显示在控制台上 | run --retry --dryrun |
- --reboot-per-module
指定执行本次任务的模块前是否重启设备。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| --reboot-per-module | 直接在命令后输入执行项名即可 | run -l ANSTest --reboot-per-module |
- --check-device
验证设备。
如果设备不一致,则会出现错误"does not meet the requirement"。
| 格式 | 使用说明 | 实例 |
| :--- | :--- | :--- |
| --check-device | 验证ssts.json里properties的spt与实际运行的设备是否一致 | run ssts -l XXXTest --check-device |
- --repeat
重复执行次数
| 格式 | 使用说明 | 实例 |
| :------- | :--------------------------------------- | :-------------------------------------------------- |
| --repeat | 在--repeat后空格输入需要重复执行的次数 | run ssts -l XXX --repeat 3,表示重发运行XXX测试套3次 |
- -tl
长选项表示为"--testlevel",此参数为保留选项,目前框架没有使用到
- -cov
长选项表示为"--coverage",此参数为保留选项,目前框架没有使用到
- -bv
长选项表示为"--build_variant",此参数为保留选项,目前框架没有使用到

View File

@ -175,21 +175,22 @@ class LogListener(IListener):
from _core.utils import convert_serial from _core.utils import convert_serial
del kwargs del kwargs
if lifecycle == LifeCycle.TestSuite: if lifecycle == LifeCycle.TestSuite:
self.log_queue.debug(log_data="End test suite [{}] and cost {}ms." self.log_queue.debug(log_data="End test suite cost {}ms."
.format(test_result.suite_name, test_result.run_time)) .format(test_result.run_time), clear=True)
self.log_queue.clear() self.log_queue.info(log_data="End test suite [{}]."
.format(test_result.suite_name), clear=True)
elif lifecycle == LifeCycle.TestCase: elif lifecycle == LifeCycle.TestCase:
self.log_queue.debug(log_data="TestEnded({}#{})" self.log_queue.debug(log_data="TestEnded({}#{})"
.format(test_result.test_class, test_result.test_name)) .format(test_result.test_class, test_result.test_name))
ret = ResultCode(test_result.code).name ret = ResultCode(test_result.code).name
if self.test_num: if self.test_num:
self.log_queue.debug(log_data="[{}/{} {}] {}#{} {}". self.log_queue.info(log_data="[{}/{} {}] {}#{} {}".
format(test_result.current, self.test_num, convert_serial(self.device_sn), format(test_result.current, self.test_num, convert_serial(self.device_sn),
test_result.test_class, test_result.test_name, ret)) test_result.test_class, test_result.test_name, ret))
else: else:
self.log_queue.debug(log_data="[{}/- {}] {}#{} {}". self.log_queue.info(log_data="[{}/- {}] {}#{} {}".
format(test_result.current, convert_serial(self.device_sn), format(test_result.current, convert_serial(self.device_sn),
test_result.test_class, test_result.test_name, ret)) test_result.test_class, test_result.test_name, ret))
@staticmethod @staticmethod
def __skipped__(lifecycle, test_result, **kwargs): def __skipped__(lifecycle, test_result, **kwargs):