Base F32_EKA2 Validation Test Suite

Test Suite Overview

This Suite provides regression tests for the following APIs:

• RFs

• CDir

• CDirScan

• CFileBase

• CFileMan

• MFileManObserver

• RDir

• RFile

• RFormat

• RRawDisk

• TDriveUnit

• TEntry

• TEntryArray

• TFindFile

• TFileText

• TOpenFileScan

• TParse

• TParseBase

• TParsePtr

• TparsePtrC

• TVolumeInfo

• FileNamesIdentical()

All PublishedAll APIs are tested.

Test Approach

Automated tests

All tests of the test suite are fully automated except those described in Manual Tests.

Manual tests

Tests in the script PBASE-F32-RFS-Drives-PublicApi-REM-manual.script rely on the removal and insertion of removable storage, which requires manual intervention, so cannot be automated. Any test case that requires the card door to be opened or closed displays a message on the console to instruct the user. The functions that must be tested manually are:

• RFs::LockDrive()

• RFs::UnlockDrive()

• RFs::ClearPassword()

• RFs::ErasePassword()

MMC Card Tests

When executing on hardware, all the tests that use an MMC card need a real MMC card.

On the emulator an MMC card is simulated. You must press and release the F5 button when requested to simulate a door open or door close event.

Some MMC locking related tests can be considered as dangerous because they remove all data from the MMC card. These test cases are run together with all other test cases to ensure that no critical data is saved on the MMC card.

Dual Drive Tests

The Dual Drive tests are run on the device which has two drives enabled from the same interface. For example, two MMC drives, two NAND flash etc.

These tests can be run directly by modifying the environment file with the relevant drive information.

Categorization by drive type

Many test cases are dependant on the type of disk drive they can be run on. The test suite consists of some of the test scripts each containing a certain drive specific tests.

The following are the specific drive types:

• ROM-drive (test scripts have –ROM postfix in file name)

• Paged NAND memory (test scripts have –NAND postfix in file name)

• System-drive (test scripts have –OS postfix in file name)

• RAM-drive (test scripts have –RAM postfix in file name)

• Removable drive (like MMC, test scripts have –REM postfix in file name)

All the remaining tests are not specific to any type of drive (test scripts have –ANY postfix in file name). The separation makes possible to test the APIs against a certain drive type.

Coverage Omissions

Function RFs::FinaliseDrives() is omitted in the test suite, because it is impossible to automate it's tests with TEF. During execution TEF keeps files open and finalising drives would break TEF execution.

The following functions are omitted as they purely debug mode functions:

• RFs::SetErrorCondition(TInt anError,TInt aCount=0);

• RFs::SetDebugRegister(TInt aVal);

• RFs::SetAllocFailure(TInt aAllocNum);

• RFs::DebugNotify(TInt aDrive,TUint aNotifyType,TRequestStatus& aStat);

• RFs::ControlIo(TInt aDrive,TInt aCommand);

• RFs::ControlIo(TInt aDrive,TInt aCommand,TDes8& aParam1);

• RFs::ControlIo(TInt aDrive,TInt aCommand,TDes8& aParam1,TDes8& aParam2);

• RFs::ControlIo(TInt aDrive,TInt aCommand,TAny* aParam1,TAny* aParam2);

Some functions of RFs must be used by ESTART program during Symbian platform start up. Such functions are as follows:

• RFs::SetStartupConfiguration(TInt aCommand, TAny *aParam1, TAny *aParam2);

• RFs::SetLocalDriveMapping(const TDesC8 &aMapping);

• RFs::StartupInitComplete(TRequestStatus &aStat);

• RFs::AddCompositeMount(const TDesC &aFileSystemName, TInt aLocalDriveToMount, TInt aCompositeDrive, TBool aSync);

The test suite provides only possible negative tests for the functions above.

The following list of functions is also omitted because they must be tested as part of a separate test suite:

• RFile::AdoptFromClient(const RMessage2 &aMsg, TInt aFsHandleIndex, TInt aFileHandleIndex);

• RFile::AdoptFromCreator(TInt aFsIndex, TInt aFileHandleIndex);

• RFile::AdoptFromServer(TInt aFsHandle, TInt aFileHandle);

• RFile::TransferToClient(const RMessage2 &aMsg, TInt aFileHandleIndex);

• RFile::TransferToProcess(RProcess &aProcess, TInt aFsHandleIndex, TInt aFileHandleIndex);

• RFile::TransferToServer(TIpcArgs &aIpcArgs, TInt aFsHandleIndex, TInt aFileHandleIndex);

Test Suite Details

Test Script Source Tree Location

Descriptions of the test scripts can be found at the following location:

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Dir-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-DirScan-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-DriveUnit-PublicApi-ANY.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Entry-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-EntryArray-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-File-PublicApi-NAND.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-File-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-FileMan-PublicApi-OS.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-FileMan-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-FileNamesIdentical-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-FileText-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-FindFile-PublicApi-OS.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-FindFile-PublicApi-REM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Format-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Format-PublicApi-REM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Format-PublicApi-ROM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-OpenFileScan-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Parse-Inherited-PublicApi-ANY.scrip t

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Parse-PublicApi-ANY.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-ParseBaseTemplate-Inherited-PublicApi-ANY.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-ParsePtr-Inherited-PublicApi-ANY.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-ParsePtr-PublicApi-ANY.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RawDisk-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RawDisk-PublicApi-REM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RDir-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RFS-Drives-PublicApi-ANY.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RFS-Drives-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RFS-Drives-PublicApi-REM-manual.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RFS-Drives-PublicApi-REM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RFS-Files-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RFS-Misc-PublicApi-ANY.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RFS-Misc-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RFS-Mounts-PublicApi-ANY.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RFS-Mounts-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RFS-PublicApi-OS.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-RFS-PublicApi-ROM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Sfsrv-PublicApi-ANY.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Sfsrv-PublicApi-NAND.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Sfsrv-PublicApi-OS.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Sfsrv-PublicApi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Sfsrv-PublicApi-REM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-Sfsrv-PublicApi-ROM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-SfSrv-PublicApi.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-VolumeInfo-PublicApi-ANY.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\PBASE-F32-DUAL-DRIVE-Publicapi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\Setup-PBASE-F32-DUAL-DRIVE-Publicapi-RAM.script

• ...\baseapitest\basesvs\validation\f32\sfsrv\scripts\setup-PBASE-F32-SfSrv-PublicApi.script

Test Script EPOC tree Location

When the tests are built for emulator or hardware (winscw or armv5), the scripts are exported into the following location in the epoc tree:

%EPOCROOT%\epoc32\data\Z\base\

Test Script Build Location

When the tests are built, the scripts are built into the following location:

%EPOCROOT%\epoc32\release\<winscw|armv5>\<udeb|urel>\Z\base\

Note: When the tests are built to be run on hardware, the files are built in the z: drive of the ROM.

Test data source tree location

The test suite contains following test data files:

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\1mb

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\1mb

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\any.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\big_line.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\empty_file.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\filetext_eof.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\filetext_read.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\multiline.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\new_file.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\oneliner.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-Dir-PublicApi.ini

• %EPOCROOT%\epoc32\data\Z\base\PBASE-F32-DirScan-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-DriveUnit-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-Entry-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-EntryArray-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-File-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-FileMan-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-FileNamesIdentical-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-FileText-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-FindFile-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-Format-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-OpenFileScan-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-Parse-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-ParseBase-Inherited-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-ParsePtr-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-ParsePtrC-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RawDisk-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RDir-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RFS-Drives-PublicApi-ANY.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RFS-Drives-PublicApi-RAM.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RFS-Drives-PublicApi-REM-manual.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RFS-Drives-PublicApi-REM.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RFS-Files-PublicApi-ANY.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RFS-Files-PublicApi-RAM.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RFS-Misc-PublicApi-ANY.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RFS-Misc-PublicApi-RAM.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RFS-Mounts-PublicApi-ANY.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RFS-Mounts-PublicApi-RAM.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RFS-PublicApi-OS.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-RFS-PublicApi-ROM.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-VolumeInfo-PublicApi.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\PBASE-F32-DUAL-DRIVE-Publicapi-RAM.ini

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\test.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\Test1.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\Test2.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\Test3.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\test_rom.txt

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\USBLOAD.ZIP

• ...\baseapitest\basesvs\validation\f32\sfsrv\testdata\Big.txt

The global environment file is located at the following location:

• ...\baseapitest\basesvs\validation\f32\testdata\<platform>\base_f32_env.ini

Test Data Files EPOC Tree Location

When the tests are built for emulator or hardware (winscw/armv5), the data files are exported into the following location in the epoc tree.

%EPOCROOT%\epoc32\data\Z\base\t_sfsrv\

The global environment file is located at: %EPOCROOT%\epoc32\data\Z\base\base_f32_env.ini

Test Data Files Emulator Location

When the tests are built, the test data files are built into the following location :

%EPOCROOT%\epoc32\release\winscw\<udeb/urel>\Z\base\t_sfsrv\

The global environment file is placed into the following location:

%EPOCROOT%\epoc32\release\winscw\<udeb/urel>\Z\base\

Note: When the tests are built to be run on hardware, the files are built into the z: drive of the ROM

Test .driver File

The base.driver file found in ...\baseapitest\basesvs\testsuites\base\ is used by the test driver to construct the test suite tree structure and export all the appropriate files to the correct location in the epoc32 tree and on the device.

When the tests are built, the .driver file can be found in the following location: %EPOCROOT%\epoc32\testdriver\testproduct\

TCS File Source Location

The .tcs file is located at the following location:

...\baseapitest\basesvs\config\t_base.tcs

TCS File Build Location

When the tests are built, the .tcs file is built into the following location:

%EPOCROOT%\epoc32\release\<winscw|armv5>\<udeb|urel>\Z\base\

Note: When the tests are built to be run on hardware, the files are built into the z: drive of the ROM.

Global tests configuration

The base_f32_env.ini file is the test suite global environment file, which contains the configurable parameters. The file contains following definitions of different drives used by the test suite and other settings:

• a system drive (which is normally C-drive);

• a test drive with RAM (which is X-drive by default on WINSCW and E: on H2/H4 standard ROMs);

• an MMC drive (a drive to where a MMC card is present);

• a drive for testing substitution;

• a drive that has no a file system;

• file system plug-ins used as the test data

Test Environment and Execution

File system plug-ins

This test suite is dependant upon the test file system and test file system extension plug-ins found in ...\baseapitest\basesvs\FileSystemPlugins\group\.

If the test suite is build from ...\baseapitest\basesvs\group\ then there is no need to build the plug-ins separately.

When the plug-ins are built, two files, T_TESTFSY1.fsy and T_TestFXT.fxt, are added to the system of the device under test. The plug-ins are used in some test cases that test the drive mounting and dismounting related functions of RFs.

Console application

The manual test suite is dependant upon the console input-output application found in the location ...\baseapitest\basesvs\Prompt\.

If the test suite is build from ...\baseapitest\basesvs\group\ then there is no need to build the console application separately.

When the console input-output executable is built, an executable file, t_prompt.exe, will be added to the system of the device under test. This executable file prints the following instruction:

“After hitting a key to continue, eject and insert the MMC card (press F5 and release on the emulator). And press any key to continue...”

Steps to run NAND tests

A few test cases (test IDs PBASE-F32-File-PublicApi-6001 and PBASE-F32-File-PublicApi-6002) require a flash memory stick with paged NAND ROM. The system is started from the NAND flash and uses the flash memory stick as the ROM-drive. Ensure that your NAND ROM memory is paged. If any other type of ROM is used then the test cases will fail with KErrNotSupported.

The NAND memory can be paged by building a ROM with pagedrom_functional.oby present in the ...\epoc32\rom\include\ directory as described:

1. Navigate to ...\epoc32\rom and run one of the following commands:

   For automated testing using TestDriver:

   buildrom -D_STARTUPMODE5 -D_NAND2 -D_EABI=<ARMV5/Gcce> -DRVCT <h4hrp/h2> pagedrom_functional.oby techview_statapi platsec td_base

   For manual testing:

   buildrom -D_STARTUPMODE5 -D_NAND2 -D_EABI=<ARMV5/gcce> -DRVCT <h4hrp/h2> pagedrom_functional.oby techview platsec t_base

   This command creates two image files: h4hrp_001.techview.nand.IMG and h4hrp_001.techview.nand.rofs.img.

2. Rename the two image files h4hrp_001.techview.nand.IMG and h4hrp_001.techview.nand.rofs.img as core.img and rofs1.img respectively.

3. To generate the nandloader, navigate to the sf/os/kernelhwsrv/kernel/eka/rombuild directory and run the following command:

   rom -v=h4hrp -b=urel -I=armv5 -t=nandloader -m=_NAND2

   Successful execution of this command generates the image file H4HRP__NAND2ARMV5D.IMG

4. Place H4HRP__NAND2ARMV5D.IMG in a ZIP file and rename the ZIP file to sys$rom.zip.

5. Transfer all three files (core.img, rofs1.img and sys$rom.zip) to the hardware board using an MMC card or a USB cable.

   The STAT application should launch automatically into the waiting for data state when the board is restarted with the NAND configuration.

   If this does not occur, check that the NAND configuration ROM is built correctly and that you have configured STAT correctly.

Steps to run Dual Drive tests

The test cases in PBASE-F32-DUAL-DRIVE-Publicapi-RAM.script are used to test the dual drive feature on the device. F32 APIs has been used to validate the Dual Drive feature on Hardware.

To run Dual Drive tests on H4, perform the following steps:

1. Update dual_drive_env.ini with the proper drive information.

   Example : DriveChar1 = E //On H4 MMC1 is represented as E:/ drive

   DriveChar2 = F //On H4 MMC2 is represented as F:/ Drive

   Build the test code from location ...\baseapitest\basesvs\group\

   >>bldmake bldfiles

   >>abld test build

2. Build the rom image with STAT

   >>buildrom -DMMC_DUAL_SLOT -DUSE_SDIO_SD_MMC -DWITH_FAT32 -D_STARTUPMODE2 -D_EABI=ARMV5 -DRVCT h4hrp techview_statapi platsec

   Executing the above command generates an image file by name, h4hrp_001.techview.IMG. The file h4hrp_001.techview.IMG needs to be zipped in Sys$rom.zip

3. Boot the H4 board with the above image from MMC1 slot. On techview ROM the mmc drive used to boot the board is represented as E:/ Drive.

   Once the image is booted, “STAT waiting for data” appears on the screen. Now insert the other MMC card on to the MMC2. This drive is mapped to F drive.

   Note: MMC2 slot must be free while booting the image and insert it later before running the tests.

4. Run the tests

   Now use testdriver to build and run the tests.

   >>testdriver build –p armv5 –b urel –s base.validation.f32.f32-dualdrive

   >>testdriver run –t <transport>

   where <transport> is serial or usb

To run Dual Drive tests on Phone, perform the following steps:

1. Select the Phone which has dual drive feature supported on it.

2. Update global environment file before building the testcode.

   Update dual_drive_env.ini with the proper drive information.

   Example :

   DriveChar1 = E //one of the dual drive on the phone

   DriveChar2 = F //One of the dual drive on the phone

   Build the test code from location ...\baseapitest\basesvs\group\

   >>bldmake bldfiles

   >>abld test build

3. Create sis package using the package file <drive>:/epoc32/pkg/dualdrive.pkg

   >>makesis dualdrive.pkg dualdrive.sis

   >>signsis -s dualdrive.sis dualdrive.sis test.cer test.key

   where test.cer and test.key are certificate and key files.

4. Install the sis package on to the phone.

   Install the sis file on to the device using BT or USB.

5. Run the tests from eshell

   > testexecute z:\base\setup-PBASE-F32-DUAL-DRIVE-Publicapi-RAM.script

   > testexecute z:\base\PBASE-F32-DUAL-DRIVE-Publicapi-RAM.script