中文 EN

4.5.2. AutoTest Usage Guide

AutoTest provides a flexible automated testing solution, supporting custom stress test duration and number of test runs through the configuration file config.ini, and allows users to extend test cases according to their needs to meet various testing requirements. This tool is developed based on driver unit testing, implements automated testing functionality, operates independently from functional unit tests, and fully reuses existing code resources.

4.5.2.1. AutoTest Directory Structure

AutoTest uses the startup.sh script to read the config/config.ini configuration file to start testing. Users can customize test content by modifying the config/config.ini file. When conducting stability or stress tests for multiple functions, this approach significantly reduces the workload of repeatedly configuring test environments. Currently, AutoTest has reused the following test items from the driver functional unit tests.

#:/app/platform_samples/chip_base_test$ tree
.
├── 01_cpu_bpu_ddr
│   └── scripts
│       └── stress_test.sh         # CPU-BPU-DDR stress test
├── 02_emmc
│   └── emmc_stability_test.sh     # eMMC stability test
├── 03_nand_flash
│   └── nand_test.sh               # QSPI NAND Flash stress test
├── 04_uart_test
│   └── uartstress.sh              # UART stress test
├── 05_spi_test
│   └── spistress.sh               # SPI stress test
├── config
│   └── config.ini                 # Configuration file for automated testing
└── startup.sh                     # Script for configuring auto-start

4.5.2.2. config.ini Configuration File Description

The config.ini file is used to configure and manage AutoTest test items. By adjusting parameters in this file, users can quickly select tests to run and specify test parameters. Below is the file structure and configuration instructions:

Configuration File Structure

Each test item starts with [Test Item Name] and includes the following fields:

  • Status: Activation status, can be set to enabled (enabled) or disabled (disabled).

  • Description: A brief description of the test item, explaining the test content.

  • ExecStart: Path and execution parameters of the test script, defining how the specific test is executed.

Configuration File Example

[CpuBoost]
Status=disabled
Description=Set the CPU to enter boost mode

[CpuAndBpu]
Status=enabled
Description=CPU, BPU, and DDR stress test
ExecStart=/app/platform_samples/chip_base_test/01_cpu_bpu_ddr/scripts/stress_test.sh -t 24h

[EmmcStablity]
Status=enabled
Description=eMMC stability test
ExecStart=/app/platform_samples/chip_base_test/02_emmc/emmc_stability_test.sh -t 24h

[NandFlash]
Status=disabled
Description=NAND flash stress test
ExecStart=/app/platform_samples/chip_base_test/03_nand_flash/nand_test.sh -t 24h

[UART]
Status=enabled
Description=UART stress test
ExecStart=/app/platform_samples/chip_base_test/04_uart_test/uartstress.sh -b 115200 -d /dev/ttyS2 -c 1000000

[SPI]
Status=enabled
Description=SPI stress test
ExecStart=/app/platform_samples/chip_base_test/05_spi_test/spistress.sh -d /dev/spidev2.0 -c 1000000

Usage Instructions

  1. Edit the configuration file: Open and edit the config/config.ini file, adjust the Status value of each test item as needed:

    • Set to enabled: Enable the test item.

    • Set to disabled: Disable the test item.

  2. Modify test parameters: Adjust commands and parameters in ExecStart according to actual requirements. For example:

    • Modify test duration (e.g., -t 24h means the test lasts for 24 hours).

    • Adjust device paths (e.g., /dev/ttyS2 or /dev/spidev2.0).

    • Adjust other test options (e.g., loop count -c or baud rate -b).

    • All script programs for currently supported test items support the -h option; you can check command help information to adjust parameters.

  3. The CpuBoost item is an environment configuration used to set whether the CPU should be overclocked.

4.5.2.3. Starting Tests with startup.sh

After completing the config.ini configuration, users can start AutoTest by running the startup.sh script. The script supports multiple startup methods to meet different usage needs:

  • Manually start or debug test items

    Suitable for scenarios using the official system image and requiring manual execution or debugging of test items. Run the following command to start the test:

    /app/platform_samples/chip_base_test/startup.sh
# or
cd /app/platform_samples/chip_base_test
./startup.sh

    This method is convenient for debugging individual test items or observing test execution.

  • Automatically run tests on board startup

    Applicable when test items have been configured and debugged successfully, and need to be automatically executed after the development board powers on. Users can create a symbolic link to achieve automatic execution:

    ln -s /app/platform_samples/chip_base_test/startup.sh /app/startup.sh

    After creating the symbolic link, every time the development board starts (power-on or reboot), it will automatically execute /app/startup.sh (called by the /etc/init.d/S99auto_startup service), initiating the configured test process.

With these two methods, users can choose the appropriate startup mode according to their needs, achieving flexible control over the testing workflow.

4.5.2.4. Viewing Test Logs

During test execution, the system generates relevant log files. Users can check the progress or results of the test through these logs. By default, log files are saved in the following path:

/app/platform_samples/chip_base_test/log

Modifying Log Storage Path

Users can change the log storage location in two ways:

  1. Move the directory: Logs are by default saved under the chip_base_test directory. Users only need to move the entire chip_base_test directory to a new location, for example:

    mv /app/platform_samples/chip_base_test /userdata/chip_base_test

    After moving, log files will automatically be saved to the new path, for example:

    /userdata/chip_base_test/log

  2. Customize log output path The driver unit test scripts support using the -o option to customize the log directory. Users can edit the config.ini configuration file and add the -o option to the ExecStart parameter of the corresponding test item. For example:

    ExecStart=/app/platform_samples/chip_base_test/01_cpu_bpu_ddr/scripts/stress_test.sh -t 24h -o /userdata/logs

    This configuration will save logs to the /userdata/logs directory.

By flexibly adjusting the log storage path, users can more conveniently manage and view test results, while meeting log storage requirements under different environments.

4.5.2.5. Adding New Test Items

AutoTest supports flexible extension of test items through configuring the config.ini file and scripts. Users can add new test functions as needed. Below are the steps for adding a new test item:

Write the Test Script

Before adding a new test item, you must first write or prepare the corresponding test script and ensure that the script can run independently. The test script should include the following elements:

  • Clear input parameters (such as test duration, device path, etc.).

  • Log output functionality; it is recommended to support the -o parameter for customizing the log path.

Save the test script to an appropriate location, for example:

/app/platform_samples/chip_base_test/new_test/new_test.sh

Configure the config.ini File

Add a new test item configuration section in config/config.ini, defining the following fields:

  • Status: Set to enabled to enable the test, or disabled to temporarily disable it.

  • Description: Describe the test function for easy identification of the test item.

  • ExecStart: Enter the test script path and its execution parameters.

Example configuration:

[NewTest]
Status=enabled
Description=New feature stability or stress test
ExecStart=/app/platform_samples/chip_base_test/new_test/new_test.sh -t 12h -o /userdata/new_test_logs

Field explanation:

  • The -t parameter specifies the test duration, e.g., 12h means 12 hours.

  • The -o parameter specifies the log storage path, e.g., /userdata/new_test_logs.

Start the Test

After completing the configuration, start the test using the startup.sh script:

/app/platform_samples/chip_base_test/startup.sh

The startup.sh script will automatically load and run the newly added test item based on the configuration in config.ini.

Verify the Test Item

After running the test, check the following to ensure the new test item works properly:

  • Whether log files are generated as expected, with complete content.

  • Whether test results meet functional expectations.

  • Whether parameters configured in config.ini take effect correctly.