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:

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.
Rename the two image -files h4hrp_001.techview.nand.IMG and h4hrp_001.techview.nand.rofs.img as core.img and rofs1.img respectively.
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
Place H4HRP__NAND2ARMV5D.IMG in -a ZIP file and rename the ZIP file to sys$rom.zip.
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:

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
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
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.
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:

Select the Phone which -has dual drive feature supported on it.
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
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.
Install the sis package -on to the phone.

Install the sis file on to the -device using BT or USB.
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

+ + + + + + Base +F32_EKA2 Validation Test Suite Explanation of file server 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:

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.
Rename the two image +files h4hrp_001.techview.nand.IMG and h4hrp_001.techview.nand.rofs.img as core.img and rofs1.img respectively.
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
Place H4HRP__NAND2ARMV5D.IMG in +a ZIP file and rename the ZIP file to sys$rom.zip.
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:

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
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
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.
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:

Select the Phone which +has dual drive feature supported on it.
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
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.
Install the sis package +on to the phone.

Install the sis file on to the +device using BT or USB.
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

\ No newline at end of file