Shulou(Shulou.com)06/03 Report--

Android native underlying drivers have a wide range of applications, but there has been no good way to track quality. With the help of the high reliability testing technology of nebula precision testing, this paper analyzes, inserts, compiles, collects data and analyzes data for Android primary underlying drivers, and gradually explains how accurate testing realizes the docking of android native underlying drivers.

In this article, we can clearly see every step of how to carry out technical docking, such as how to use nebula accurate testing for code insertion, how to implement test cases and collect data traceability of the underlying driver running code, and how to conduct a series of analysis of the final collected data.

An overview of the accurate testing process of Android source code

After analysis, the compilation of android source code mainly depends on Android.bp as the link; at the time of compilation, you only need to execute the mm command under the directory of the module you want to compile, and you can automatically compile the modules contained in it according to the Android.bp file in the current directory.

The main process is as follows: first copy the source code of the ZOA communication library and add it to a certain level of Android.bp, then through the analysis of the ninja file containing all the Android.bp compilation information, you can get the stuffing json file approved by Shell, and Shell inserts the code of the corresponding directory through the json file, after the piling is completed. After adding the reference to the ZOA communication library to the Android.bp of the module and putting the ZoaInstru.h header file, the stuffing program can be compiled normally.

Preparation tools for accurate testing of Android source code

1. Android native 8.1.0 source code, placed in the / data/source2/ directory

The 2.shell.tar.gz piling tool kit is placed in the / data/ directory

The 3.ZOAMQLib communication library source code is placed in the / data/source2/ frameworks/av/ directory

4. Officially equipped with a mobile phone with native 8.1.0 system.

In this example, the / data/source2/ frameworks/av/camera module is piled and compiled. First, source build/envsetup.sh configures the environment variables, then lunch, enter 2 to select aosp_arm64-eng, and then mm compiles the module.

Third, accurate testing and deployment of pile insertion tools

Execute the command in the / data/ directory where the precision test stub kit is stored

Tar-zxvf shell.tar.gz

Decompress the precision test pile insertion kit

Cd / data/shell/bin

The ip that opens and modifies the "SERVER" field of Server.cfg in the bin directory of the shell package is the nebula precision test server ip. For the ip of the "LOCAL" field, 127.0.0.1 is maintained if the client is on the same host as the server, and the client ip is specified if it is on different hosts.

4. Add ZOA communication library to Android system

This time, we select the pile insertion compilation verification module of the av module for accurate testing. After an in-depth understanding of the av module, we find that the structure of its Android,bp connection is roughly like this, and each final node represents the generation of a dynamic library or static library.

Av general structure and ZOA communication library to join the Android system schematic diagram:

Note: because the second layer mediadrm module library directory is too many to expand, but the principle is the same, so only show the skeleton information for this module; the green part represents a library file, mediadrm is only the skeleton structure so it is not identified.

This time, the ZOA communication library source code directory of the corresponding Android.bp file is copied to the av directory, and the Android.bp file in the av directory is added to the ZOA communication library directory.

Cd / data/source2/frameworks/av/

Enter the av module

Vi Android.bp

Open the Android.bp file of the av module and add the ZOAMQLib directory to it

Android.bp diagram of ZOA communication library with av module added:

Then execute the mm command directly in the ZOAMQLib directory to compile the ZOA communication library under Android.

5. Pile insertion compilation process 1. Generate json file

When the android source code is compiled, it will extract all the information from the Android.bp and add some compilation information to generate a build.ninja file. The file contains information such as compiled modules, source code and compilation parameters.

Through the ninja tool provided with android, the build.ninja file can be transformed into a json file containing source code path, source code name and compilation parameter information, and then the part of the stub module can be extracted to generate the stub json file of the module.

Commands to generate json files:

/ data/source2/prebuilts/build-tools/linux-x86/bin/ninja-t compdb g.cc.cc > compile_commands.json

Where / data/source2/ is the Android source code path

two。 Pile insertion code

The shell compiler can insert piles or restore the module through the json file.

The path of the stake code command shell / shell-p json file / compile_commands.json

Restore the path of the code command shell / shell-r json file / compile_commands.json

This pile insertion and restore command:

/ data/shell/bin/shell-p / data/source2/compile_commands.json/data/shell/bin/shell-r / data/source2/compile_commands.json

Reload the version data on the client side after successful stake insertion:

3. Compile Link Link Communication Library

Cd / data/source2/frameworks/av/camera

Enter the camera directory

Vi Android.bp

Open the Android.bp file of the camera module and add the name of the ZOA communication library to shared_libs

Camera's Android.bp to join the ZOA communication library link:

Add header file

Cp / data/shell/include/ZoaInstru.h / data/source2/frameworks/av/camera/include/

Add the header file of ZOA to the header folder of the piled camera

You can then follow the normal compilation process to compile and execute mm to compile the module.

Insert pile compilation icon:

VI. Testing methods

This example is to insert the Android native 8.1.0 code and put it into the official 8.1.0 mobile phone with root permission for testing.

This time the stake is the camera part of the av module, so we will

Camera module library:

/ data/source2/out/soong/.intermediates/frameworks/av/camera/libcamera_client/android_arm64_armv8-a_shared_core/libcamera_client.so

ZOA communication library:

/ data/source2/out/soong/.intermediates/frameworks/av/ZOAMQLib/libZOAMQLib/android_arm64_armv8-a_shared_core / libZOAMQLib.so

These two libraries are put into the phone's / system/lib64/ directory to boot for camera testing.

Test the concept map:

After the phone under test is turned on, it is connected to the computer with USB line, and the dynamic data generated by the program is transmitted to the nebula precision testing tool by the method of adb port mapping, and then the waveform is displayed by the oscilloscope.

Data transmission diagram:

Open the oscilloscope interface in the nebula precision testing tool client, establish the test case and select the test case, click start and carry on the camera function operation to the mobile phone, you can receive the dynamic data and the oscilloscope can see the waveform.

The oscilloscope receives the data chart:

Seventh, accurate testing-basic functions 1. Coverage rate

After recording the test case, you can see relevant information such as coverage in the main interface.

You can view the coverage of a function by clicking on a function in the list.

1.SCO coverage

The SCO coverage is the statement block coverage. If you encounter if, for, while and so on in the function sequentially, it can be regarded as a statement block.

SC0 coverage icon:

2.MCDC coverage

The MCDC revision condition determines the coverage, and the mcdc is shown quantitatively in the accurate test, counting the number of single conditions respectively, and judging whether it satisfies the mcdc coverage according to each condition. If the green condition is satisfied with the mcdc coverage as shown above, the blue color indicates that it does not meet. And show the detailed information of MCDC (select MCDC overlay, click OK, display the details of MCDC)

MCDC coverage icon:

Note:

1. There are seven kinds of coverage information, which are SCO statement block coverage, True, Flase, Both conditional coverage, Branch conditional branch coverage, CDC conditional decision coverage, MCDC correction conditional coverage.

two。 Precision testing is not associated with source code by default. If you need to associate source code, copy the source code locally to the client, right-click on the version, select modify source code path, and then add source code path to associate source code.

two。 Function call diagram

Function call diagram, only the relationship of function calls, can clearly see the hierarchical relationship of function calls. When you click on one of the functions, you can display the function as the center, calling the upper and lower three layers of the function (you can click to set the level to adjust the level).

After receiving the dynamic data, the data can also be displayed in the image interface.

3. Program control flow chart

The basic function of the control flow chart is to show the control flow of the function, that is, the control flow chart, which is used to represent the control flow of the function, display the test coverage results, realize semi-automatic and efficient test case design, and check errors in the logic flow. and two-way automatic traceability between source code, test cases and related documents.

4. Simple control flow chart

The function of the simple control flow chart clearly shows the control logic inside the function in the form of sentence blocks, and the test coverage of each node of the control flow can be seen intuitively on the interface. In the display, the simple control flow chart can also identify the coverage of each program block through color, and the coverage of the whole module in the thumbnail is very intuitive. (the background color is green to indicate that a test case is covered to the block.) Click the statement block after associating the source code to locate the specific line of the code.

5. Two-way tracing

Because the test case of a precise test is bound to the executed function, the function it executed can be traced forward by selecting different test cases on the test bench, or the test case that executed it can be found backwards by selecting different functions or code.

Forward retro icon:

The forward traceability shows the functions that the test case has run below by selecting the test case on the upper left.

Reverse retro icon:

Reverse traceability can be used not only to trace the test case that ran the function through the function in the lower left corner, but also to trace the test case that ran that block by selecting a block of code.

Precision testing-Advanced Analysis function 1. Intelligent regression test case selection

After inserting the second version after the completion of the first version test, the second engineering version is generated in the Nebula Precision Test tool. What we need to do at this time is not to test the new version immediately, but to use the regression function of our nebula accurate test to regression the new version. It will analyze the test cases related to the function according to the changes in the code between versions, and then sort the regression priority according to the number of function changes in the test cases, and intelligently recommend the test cases that need to be rerun. And test cases that show no need to run.

Example of intelligent regression:

Cd / data/source2/frameworks/av/camera goes to the camera directory

Vi ICamera.cpp opens the source code for modification

Add if (1 conditions) to the getParameters function

Then insert piles into the camera module, and then use the function of selecting regression test cases on the client side for regression.

Due to the change in the new condition in the getParameters function, the regression count of the test case that ran the function is incremented by one, and then the test case is recommended to run again.

The regression diagram shows:

For precision testing, it uses the method of binding the test case to the function it has executed during the test phase. The previous version of the test case will be inherited during the iteration of the version, and compared with the previous version through regression, which function has changed, then the function of the related test case may change, so the test case to be retested will be recommended during regression. When all the functions associated with a test case remain unchanged, it is pointless to test the use case again. So, after the insertion of the new version and the regression of the previous version, you can see which use cases need to be rerun and which ones don't have to run at all.

two。 Last execution time sequence

This part is the timing diagram of the last fifty statement blocks saved when the pile insertion program is executed for dynamic data reception.

It can click on the order of each step to view the code of the execution block.

3. Cluster analysis.

The setting of the number in the clustering algorithm needs to be set manually, which is generally set according to the thickness of the granularity. The clustering algorithm obtains the result through the code similarity of the test cases, so it can help us to distinguish which test cases have a higher degree of code similarity.

A total of 7 test cases were designed, including two photos, two video recordings, one random side, one turning on the camera, and one idle after turning on the camera.

When the number of categories is 5, the clustering results are as follows:

Switch to graphics mode as follows:

10. Web report 1. Daily coverage growth curve

Use a line chart to clearly show the changes in the coverage of this version on a daily basis

The radar chart in the lower left corner shows the gap between the expected coverage and the actual coverage.

The lower right corner compares the differences in coverage between the current version and the latest version.

two。 Intelligent Analysis of Test vulnerabilities

In a program, there are often hundreds of functions, some of which are related to the core of the whole program, and some are abandoned by developers, but they have been retained for a long time. In view of these a large number of functions, "accurate testing" uses a comprehensive analysis of static and dynamic indicators, and in a large number of program functions, potential high-risk test vulnerabilities are screened directly through calculation and displayed through reports.

When the complexity of a function is high but the coverage is low, the probability of risk may be high.

When the function fan in and out is larger, it means that the more correlation functions, combined with its coverage information may also be a higher risk.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.