VII. Using Scripts to Generate Airtest Reports¶

1.Preface¶

In the AirtestIDE user manual, we have introduced how to use AirtestIDE and command line to generate Airtest reports. In this article, we will take a look at how to use scripts to generate test reports directly.

2.Using the `simple_report()` API¶

First, let's talk about the simple_report API, which is actually a simplified API for generating reports, easy to understand and handy to use:

filepath: Specify the path of the script
logpath: Specify the path of the log content
logfile: Specify the path of the log.txt file
output: Specify the path of the HTML reports, which must end in .html

If you do not specify any parameters, the API will generate a report in HTML format using the default parameters. The output='log.html' means that an airtest report named log.html will be generated in the current script path:

from airtest.report.report import simple_report
simple_report(__file__)

If the output parameter is specified, a report will be generated in the specified path:

from airtest.core.api import *
from airtest.report.report import simple_report

auto_setup(__file__,logdir=True)
simple_report(__file__,logpath=True,output=r"D:\test\report02\log.html")

logdir and logpath

The generation of Airtest reports relies on the log saved during the script runtime. If you want to generate a report, you need to save the log of the script runtime. The logdir parameter of auto_setup API can set the log saving path. When you use simple_report to generate a report, you can set the logpath to find the corresponding log content under the log saving path specified by logdir.

1) Specify the name of the report file using the output parameter¶

Some of you may notice that the output parameter can specify the complete path for generating Airtest reports, including the naming of the report file, such as xxx.html. By utilizing this feature, you can customize the name of the report file:

simple_report(__file__,logpath=True,output=r"D:\test\cloud_music.html")

(2) The new report generated by running the same script do not overwrite the previous ones.¶

To expand on this, if we do not specify the output parameter, the default parameter will be used for each report generation, which will result in the old report being overwritten by each new report; then if we want to not overwrite the old report, we can use this parameter by passing it a non-repeat naming rule, e.g:

# -*- encoding=utf8 -*-
__author__ = "AirtestProject"

from airtest.core.api import *
from airtest.report.report import simple_report,LogToHtml

auto_setup(__file__,logdir=True)

a = 1
while a < 4:
    print("Pretending to execute some scripts here")

    # Generate the report
    from airtest.report.report import simple_report
    simple_report(__file__,logpath=True,output="log"+str(a)+".html")
    a = a + 1

3.Using the `LogToHtml()` Class¶

Another way to generate Airtest reports using scripts is to use the LogToHtml() class: The parameters of this class are much more complex than simple_report() and include:

script_root, specifying the script path
log_root, specifying the path of the log file
static_root, specifying the path of the server where static resources are deployed
export_dir, specifying the path where the exported reports are stored
script_name, specifying the script name
logfile, specifying the path of the log file log.txt
lang, specifying the language of the report (Chinese: zh; English: en)
plugins, specifying the reporting plugin, used when Poco or Airtest-selenium are used

1) Examples of using LogToHtml() class to generate reports¶

Here is an example where we export the runtime report of the D:\test\report01.air script in the specified path D:\test\report02, with the report language in English:

from airtest.report.report import LogToHtml

h1 = LogToHtml(script_root=r'D:\test\report01.air', log_root=r"D:\test\report01.air\log", export_dir=r"D:\test\report02" ,logfile=r'D:\test\report01.air\log\log.txt', lang='en', plugins=None)
h1.report()

From the example we can see that to use the LogToHtml class to generate reports, we need to first instantiate a LogToHtml class, and then call the class method report() to generate an Airtest report.

1) `Logdir` and log_root¶

As we have mentioned above, the generation of Airtest reports depends on the log content of the script run. Before generating the report, we need to save the log content of the script run and then specify parameters to find the corresponding log content when generating the report.

In the above example, we specify logdir=True in auto_setup to save the log content in the path of the current script. When generating the report, we can use the log_root parameter of LogToHtml to specify the path to find the log.

!!! Warning "logdir and log_root" In fact, if we change the log_root=r "D:\test\report01.air\log" into log_root=True in the above example, it will still have the same effect. In other words, the logdir specifying the log saving path and the log_root specifying the log finding path must be the same.

2）Export_dir parameter for exporting reports¶

Using the export_dir parameter in LogToHtml can export the Airtest report and send it to others or deploy it to a file server for viewing. Without this parameter, local Airtest reports are generated by default which can only be viewed locally.

3) Static_root parameter for specifying the server address where static resources are deployed¶

Airtest's HTML report contains some static resource files such as css and js, which will be exported as a file alongside the report.

To avoid exporting the same static resource files whenever exporting reports, we can deploy this fixed static resource file to a file server, and then pass the server address where the static resource file is deployed to the static_root parameter. This way, our report will access the static resource file of the report on the given server address, without copying the static resource file again into the report folder. This can greatly reduce the size of the report.

4) Plugins parameter for specifying the report plugins¶

When our automation script contains Poco statements or Airtest-selenium statements, we need to pass in the corresponding plugin to change some styles of the Airtest report when generating the report:

plugins=["poco.utils.airtest.report", "airtest_selenium.report"]

5) The output_file parameter of the class method report¶

About the report method, we need to focus on its output_file parameter: Please note that the output_file and export_dir parameters are different. The former specifies the path to generate the local report while the latter specifies the path to generate the exported report.

#example
r = LogToHtml(script_root=r'D:\test\song.air',log_root=r'D:\test\song.air\log')

r.report(output_file=r'D:\test\cloud_music01.html')

The above example is a script for the generation of a local Airtest report, specifying the report generation path and the name of the report file. If we use both the export_dir and the output_file parameters, only export_dir will take effect and output_file will not.

4.Notes on Generating Reports¶

1) Use the report generation script at the beginning¶

Beginners tend to make the mistake of placing the code that generates the report at the beginning of the script, followed by a series of operations:

# -*- encoding=utf8 -*-
__author__ = "AirtestProject"

from airtest.core.api import *
from airtest.report.report import simple_report,LogToHtml

auto_setup(__file__,logdir=True)

simple_report(__file__,log_path=True)

touch(Template(r"tpl1637219700366.png", record_pos=(-0.103, 0.27), resolution=(1920, 1080)))
sleep(1.0)
snapshot(msg="Please fill in the test points...")
# Multiple scripts are omitted here.

This will lead to an empty report even if we run the whole script successfully because the test report has been generated at the beginning of the script before the log records the execution of any scripts. In other words, the operation scripts are run after the script that generates the report), resulting in an empty test report.

2) Generate a test report regardless of whether the script runs successfully¶

Generally, the report-generating statements should be placed after all use case scripts to ensure that the script-generating statements are executed only after the use case has been executed. However, there is a tendency that once the execution of the use case scripts fail, the whole script will be terminated, i.e., the script has stopped running before the statement that generates the report is executed. In this case, the report cannot be generated properly. To cope with this situation, we can use the try-finally statement to generate a report regardless of whether the script runs successfully or not, so that the tester can easily check the corresponding problem:

try:
    poco("com.netease.newsreader.activity:id/bjd").wait_for_appearance()
    poco("com.netease.newsreader.activity:id/awo").click()
    ...
finally:
    simple_report(__file__,logpath=True,output="../netease_music/login.html")
    print("-----execution completed-----")