Bluetooth Test Technology

Bluetooth test technology area scope

Components under Test

The Bluetooth subsystem provides support for Bluetooth, a short-range radio communications technology, standardised by the Bluetooth SIG in the form of the v2.0 Bluetooth Specification. The Bluetooth test suites test the following components under the Bluetooth technology area:

• Bluetooth User: This component provides the application level APIs for configuring and managing Bluetooth connections. The following components of Bluetooth User are tested:

  • Bluetooth Library: This component provides setup and configuration details such as device type, Bluetooth sockets and link management options.

  • Bluetooth Sockets: Sockets provided by CBluetoothSocket instead of RSocket.

  • BluetoothAV: Provides the data structure for BluetoothAV operations for AVDTP, GAVDP, and A2DP, and so on.

• Bluetooth SDP: The Symbian platform Bluetooth Service Discovery Protocol (SDP) component provides the functionality of the SDP required for Bluetooth connectivity.

• Bluetooth GAVDP: The Symbian platform Bluetooth GAVDP component provides licensees the interfaces to implement Bluetooth GAVDP profile support on their platforms.

Scope of testing

This technology area provides a number of test suites to test APIs that Symbian identifies as PublishedAll and PublishedPartner, and are documented in the Symbian platform Library. These test suites can be used as a regression test suite, and also as part of a compatibility testing program. The test suite provides two types of tests, connected and unconnected tests.

Note: For more information about the individual classes, refer to Bluetooth Verification Suite.

Connected tests

The connected tests run Bluetooth commands from one device (called the Master), and send or receive data to/from another device (called the Slave). One device sends data over Bluetooth (this is the Active role) and the other device (the Passive role) will receive this data. Note that both the Master and Slave devices take turns at taking the Active and Passive roles.

Master tests

The Master tests control the Slave tests. These tests run on the Master device and use UCC commands to start a test run on the Slave device.

Slave tests

The Slave tests are controlled by the Master tests. A Slave test run is instigated by a UCC command on a Master test. The results of each Slave test is sent back to the Master and integrated into the results for the relevant Master test.

For example, a Master test calls a UCC command which tells the Slave device to start a Slave script. A Slave test on this script runs and the result is sent (using UCC) to the Master device.

Following is an example of a Bluetooth connected script using UCC:

1. The Master script is started on the Master device.

2. The Master script initialises UCC services on the Slave PC.

3. The Master script starts a Slave script running on the Slave device.

4. The Master starts a test.

5. The Master test creates Bluetooth objects.

6. The Script test starts, creates Bluetooth objects, and starts its Bluetooth dongle, which listens for incoming connections.

7. The Slave test waits until the Master requests it to proceed.

8. The Master test tells the Slave to continue and requests its Bluetooth dongle to connect to the Slave Bluetooth dongle.

9. The Slave test accepts this connection and sends the result to the Master.

10. The Master receives the result and integrates it into its result of this test.

11. The Master test is completed and the results are printed to a log file.

12. The Master script ends the UCC services running on the Slave PC.

13. The Master script is closed.

Unconnected tests

The unconnected tests run on a single device attached to a Bluetooth dongle. The tests are standalone, as they do not send or receive data to/from another device.

Test omissions

Not applicable.

Bluetooth test technology environment

Two devices, both attached with a Bluetooth dongle, are required to run these tests. Connected tests require a UCC setup to be configured. This involves having a Master side PC running the UCC and a Slave PC running the remote services for multi-device synchronised tests. UCC is a PC service. If the tests are run on H2 or H4 board, the board has to be connected to a PC running UCC.

Note: For more information about UCC setup, refer to Symbian Verification Suite » Use case controller (UCC).

All tests are controlled by the Master side connected device or emulator. Each device runs a script, where UCC is used to keep the tests in sync. The main device, which initiates the connection, is known as the Master device. The device, which accepts the connection, is called the Slave device. The Master device can either be a PC or a H2 or H4 board. However, the Slave device is always emulator because all the Master and Slave scripts are reversed and Slave scripts are executed on the Master device as well. For this reason, only the test coverage on the Master device is taken into consideration. There are separate Master and Slave scripts for each device.

Device under Test Setup

The device under test (hardware platform, phone or emulator) should have an appropriate Symbian platform or licensee UI build. On a Symbian platform reference board this requires connecting a CASIRA pod (a Bluetooth dongle) to COM3 and on the Slave or Master emulator PC to COM0. For licensee UI variant devices, the built-in Bluetooth hardware is used. In this scenario, configure the Bluetooth COM port in the corresponding hctl.ini file.

PC Setup

The PC should have Symbian or equivalent licensee developer kit, PDT and relevant compilers (Code Warrior, RVCT or GCCE) installed to build and execute the test code. The host PCs also require a Use-Case Controller (UCC) environment to be configured for connected tests to be run.

Network Environment Setup

The PC and the device under test should be on the same network. To set up TCP/IP communication between the PC and the device under test Symbian, refer to Appendix A.

Test dependencies

Any mention to epoc32 is offset by %EPOCROOT% that is, full path where the epoc tree is installed.

Test Data

Test data for each test suite is in the following location:

• …\bluetoothapitest\bluetoothsvs\T_BTSdpAPI\testdata

• …\bluetoothapitest\bluetoothsvs\T_BTSockAddrAPI\testdata

• …\bluetoothapitest\bluetoothsvs\T_BTSockAPI\testdata

• …\bluetoothapitest\bluetoothsvs\T_BTUserAPI\testdata

• …\bluetoothapitest\bluetoothsvs\testdata

• …\bluetoothapitest\bluetoothsvs\T_BTGavdpAPI\testdata

There is also test data common to all Bluetooth suites, which consists of the CommDbWintap.xml and CommDbNtras.xml files. These files are used to change the CommsDAT for testing on emulator and hardware respectively.

Building and executing tests

Before building and execution SVS, a new btuinotifiers.dll which used for tests need to be built. This new btuinotifiers.dll pops up window asking user to input password while Bluetooth is establishing connection. Without doing this, most connective case need user’s interaction while cases are running. If password is not input in time, cases will fail because of time out.

This btuinotifiers.dll used for tests can be built from the following location:

os/ shortlinksrv/ bluetooth/ btexample/ testui/ btuiautonotifiers/ group

Execute the following commands to build it:

bldmake bldfiles

abld test build [winscw|armv5] [urel|udeb]

The following code block illustrates the Bluetooth test suite hierarchical structure after the build process. This structure can be viewed from the .. %EPOCROOT%\epoc32\testdriver\testproduct folder after building the test suite.

Note: For information about the TestDriver test suite structure, see Symbian Verification Suite » TestDriver » Using TestDriver » Results » Viewing the test results.

<Component> - Bluetooth
<Device type> - master
<Test type> - connected
<Sub-component-BT-SDP> - BT-SDP-PublicApi-Master-suite
<suite> - BTSDP-Agent-PublicApi-Active-Master-suite
<suite> - BTSDP-Agent-PublicApi-Passive-Master-suite
<suite> - BTSDP-Database-PublicApi-Active-Master-suite
<suite> - BTSDP-Database-PublicApi-Passive-Master-suite
<suite> - BTSDP-Lists-PublicApi-Active-Master-suite
<suite> - BTSDP-Lists-PublicApi-Passive-Master-suite
<suite> - BTSDP-Search-PublicApi-Active-Master-suite
<suite> - BTSDP-Search-PublicApi-Passive-Master-suite
<Sub-component-BT-USER-SOCK> - BT-USER-SOCK-PublicApi-Master-suite
<suite> - BT-USER-SOCK-PublicApi-Active-Master-suite
<suite> - BT-USER-SOCK-PublicApi-Passive-Master-suite
<Sub-component-BT-USER-SOCK> - BT-USER-PublicApi-Master-suite
<suite> - BT-USER-Access-Public-Act-Master-suite
<suite> - BT-USER-Adapter-Public-Act-Master-suite
<Sub-component-BT-GAVDP> - BT-GAVDP-PublishedPartner-Master-Suite
<suite> - BT-GAVDP-PublishedPartner-Active-Master-suite
<suite> - BT-GAVDP-PublishedPartner-Passive-Master-suite
<Test type> - unconnected
<Sub-component-BT-SDP> - BT-SDP-PublicApi-Master-suite
<suite> - BTSDP-Agent-PublicApi-Unconnected-suite
<suite> - BTSDP-Lists-PublicApi-Unconnected-suite
<suite> - BTSDP-SearchPattern-PublicApi-Unconnected-suite
<Sub-component-BT-USER-SOCK> - BT-USER-SOCK-PublicApi-suite
<suite> - BT-USER-SOCK-PublicApi-Unconnected-suite
<Sub-component-BT-SOCK-ADDR> - BT-Sock-Addr-API-PublicApi-suite
<suite> - BT-sock-addr-api-publicapi-suite
<Sub-component-BT-USER> - BT-USER-PublicApi-Master-suite
<suite> - BT-USER-BTAccReq-Pub-Unc-Suite
<suite> - BT-USER-BTPhyLinAda-Pub-Unc-Suite
<suite> - BT-USER-BTPhyLin-Pub-Unc-Suite
<suite> - BT-USER-BTSynBan-Pub-Unc-Suite
<suite> - BT-USER-BTSynLin-Pub-Unc-Suite
<suite> - BT-USER-BTSynPac-Pub-Unc-Suite
<suite> - BT-USER-L2CapSocAdd-Pub-Unc-Suite
<suite> - BT-USER-RfRemPortPara-Pub-Unc-Suite
<suite> - BT-USER-RfRPNTra-Pub-Unc-Suite
<suite> - BT-USER-AvdtpCntProtCapa-PubPart-Unc-Suite
<suite> - BT-USER-AvdtpHeaderCompCapa-PubPart-Unc-Suite
<suite> - BT-USER-AvdtpMediaTransCapa-PubPart-Unc-Suite
<suite> - BT-USER-AvdtpRecoveryCapa-PubPart-Unc-Suite
<suite> - BT-USER-AvdtpReportingCapa-PubPart-Unc-Suite
<suite> - BT-USER-AvdtpSEPInfo-PubPart-Unc-Suite
<suite> - BT-USER-AvdtpSrvCate-PubPart-Unc-Suite
<suite> - BT-USER-AvdtpSockAddr-PubPart-Unc-Suite
<suite> - BT-USER-CnvtToSymbianErr-PubPart-Unc-Suite
<suite> - BT-USER-NonSBCCodecCapa-PubPart-Unc-Suite
<suite> - BT-USER-SEID-PubPart-Unc-Suite
<Test type> - connected - auto
<Sub-component-BT-USER> - BT-USER-PublicApi-Master-Auto-suite
<suite> - BT-USER-Access-Pub-Act-Mas-Auto-suite
<suite> - BT-USER-Adapter-Pub-Act-Mas-Auto-suite
<suite> - BT-USER-PhyLinks-Pub-Act-Mas-Auto-suite
<suite> - BT-USER-SyncLink-Pub-Act-Mas-Auto-Suite

<Device type> - slave
<Sub-component-BT-SDP> - BT-SDP-PublicApi-Slave-suite
<suite> - BTSDP-Agent-PublicApi-Active-Slave-suite
<suite> - BTSDP-Agent-PublicApi-Passive-Slave-suite
<suite> - BTSDP-Database-PublicApi-Active-Slave-suite
<suite> - BTSDP-Database-PublicApi-Passive-Slave-suite
<suite> - BTSDP-Lists-PublicApi-Active-Slave-suite
<suite> - BTSDP-Lists-PublicApi-Passive-Slave-suite
<suite> - BTSDP-Search-PublicApi-Active-Slave-suite
<suite> - BTSDP-Search-PublicApi-Passive-Slave-suite
<Sub-component-BT-USER-SOCK> - BT-USER-SOCK-PublicApi-Slave-suite
<suite> - BT-USER-SOCK-PublicApi-Active-Slave-suite
<suite> - BT-USER-SOCK-PublicApi-Passive-Slave-s
<Sub-component-BT-USER-SOCK> - BT-USER-PublicApi-Slave-suite
<suite> - BT-USER-Access-Public-Pass-Slave-suite
<suite> - BT-USER-Access-Pub-Pass-Sla-Auto-suite
<suite> - BT-USER-Adapter-Public-Pass-Slave-suite
<suite> - BT-USER-Adapter-Pub-Pass-Sla-Auto-suite
<suite> - BT-USER-PhyLinks-Pub-Pass-Sla-Auto-suite
<suite> - BT-USER-SyncLink-Pub-Pass-Sla-Auto-Suite
<Sub-component-BT-GAVDP> - BT-GAVDP-PublishedPartner-Slave-suite
<suite> - BT-GAVDP-PublishedPartner-Active-Master-suite
<suite> - BT-GAVDP-PublishedPartner-Active-Slave-suite
<suite> - BT-GAVDP-PublishedPartner-Passive-Master-suite
<suite> - BT-GAVDP-PublishedPartner-Passive-Slave-suite

The hierarchical test suite structure facilitates easy build and execution of the complete test suite or part of it. For example, if the path specified is:

• <bluetooth>: The entire suite is built or executed.

• <bluetooth.master.unconnected>: All the five unconnected suites are built or executed.

• <bluetooth.master.unconnected.BT-SDP-PublicApi-Master-suite.BTSDP-Agent-PublicApi-Unconnected-suite>: Only BTSDP-Agent-PublicApi-Unconnected-suite is built or executed.

The following subsequent sections describe the sequence of commands to be executed on emulator and hardware.

Notes:

• Refer to the code block in this section for sub-component and test suite names.

• Ensure that you ignore the Steps to build and execute tests manually section for automated testing and the Steps to build and execute tests using TestDriver section for manual testing.

General environment setup

Perform the following steps for the WINSCW or ARMV5 platforms:

Note: For building additional components, refer to the specific sub-component test suite description document in Symbian Verification Suite » API regression test suite » API test suites for Bluetooth.

1. The entire Bluetooth Test component can be built from \bluetoothapitest\bluetoothsvs\group\…. Individual test components can be built from the respective group directory:

   • \bluetoothapitest\bluetoothsvs\T_BTSdpAPI\group

   • \bluetoothapitest\bluetoothsvs\T_BTSockAddrAPI\group

   • \bluetoothapitest\bluetoothsvs\T_BTSockAPI\group

   • \bluetoothapitest\bluetoothsvs\T_BTUserAPI\group

   • \bluetoothapitest\bluetoothsvs\T_BTGavdpAPI\group

2. Execute the following commands to build the Bluetooth Test component:

   bldmake bldfiles

   abld test build [winscw|armv5] [urel|udeb]

   abld test build [winscw|armv5] [urel|udeb]

   %EPOCROOT%\epoc32\release\winscw\<udeb/urel>ced z:\bluetooth\[CommDbNtras.xml |CommDbWintap.xml]

   Note: This command performs the following tasks:

   • Updates CommDB to use the appropriate transport mechanism (NT RAS by default). For more information about NT RAS, refer to Appendix A.

   • If any username or password creation or changes on NT RAS connection the above command must be executed to reflect the new NT RAS account details.

   • Suppresses any WinTap prompts.

Steps to build and execute tests using TestDriver

For WINSCW platform:

1. Communication between the PC and the device under test (Symbian platform device) is enabled using STAT. So, the device under test must have STAT installed.

   Note: Refer to Symbian Verification Suite » TestDriver » Using TestDriver » Communicating with the device » STAT plug-in for more information.

2. Configure the TestDriver using the automated scripts located at the following location:

   \bluetoothapitest\bluetoothsvs\group\…

   testdriversetup

   testdriversetup.bat calls testdriversetup.pl which applies an appropriate set of configuration parameters. This should be done in both Master and Slave devices.

3. Build the test code by running the following command:

   Testdriver build [–p [winscw|armv5]] [–b [udeb|urel]] –s bluetooth[.master|slave[.<test suite name >]]

   Testdriver commands can be executed from any location.

4. Execute the tests by running the following command:

   testdriver run

Note: All scripts and test data are automatically removed from the system drive of the device under test after the execution.

For ARMV5 platform:

1. Communication between the PC and the device under test (Symbian platform device) is enabled using STAT. So, the device under test must have STAT installed.

2. Communication between PC and hardware: Refer to Symbian Verification Suite » TestDriver » Using TestDriver » Communicating with the device » STAT plug-in for details on the various methods of communication between the PC and hardware. The ROM image is built on the PC and transferred to the hardware board using MMC card.

3. TestDriver can be configured using the automated scripts located at: \bluetoothapitest\bluetoothsvs\group\…

   testdriversetup

   testdriversetup.bat calls testdriversetup.pl which applies an appropriate set of configuration parameters. This should be done in both Master and Slave devices.

4. Build the test code by running the following command:

   Testdriver build [–p [winscw|armv5]] [–b [udeb|urel]] –s bluetooth[.master|slave[.<test suite name >]]

   Testdriver commands can be executed from any location.

5. Build the ROM image by running the following command:

   buildrom –D_STARTUPMODE2 –D_EABI=ARMV5 -DRVCT -DUSE_STRONG_CRYPTOGRAPHY -D_CUSTOM_COMMSDAT <h2/h4hrp> techview_statapi platsec

6. Execute the tests by running the following command:

   testdriver run –tcp – –ip <client IP address of the NT RAS connection>

Note: All scripts and test data are automatically removed from the system drive of the device under test after the execution.

Steps to build and execute tests manually (Tests built into ROM)

For WINSCW platform:

1. Setup Scripts: The setup_t_bluetooth.script file is used to execute the entire bluetooth test suite. Following setup scripts are used to execute class specific test suites:

   • setup-BT-SOCK-ADDR-PublicApi.script

   • setup-BT-USER-SOCK-PublicApi.script

2. Running Scripts:

   Change directory to …%EPOCROOT%\epoc32\release\winscw\<urel/udeb>

3. Execute the Test:

   testexecute z:\bluetooth\setup_<test suite name>.script

   testexecute c:\bluetooth\<test suite name>.script

   t_ bluetooth.script is used to execute the entire Bluetooth test suite.

For ARMV5 platform:

1. Build the ROM image by running the following command:

   buildrom –D_EABI=ARMV5 -DRVCT -DUSE_STRONG_CRYPTOGRAPHY -D_CUSTOM_COMMSDAT <h2/h4hrp> techview_statapi platsec t_bluetooth

2. Setup Scripts: The setup_t_bluetooth.script file is used to execute the entire bluetooth test suite. Following setup scripts are used to execute class specific test suites:

   • setup-BT-SOCK-ADDR-PublicApi.script

   • setup-BT-USER-SOCK-PublicApi.script

3. Running Scripts:

   Open eshell

4. Execute the Test:

   testexecute z:\bluetooth\setup_<test suite name>.script

   testexecute c:\bluetooth\<test suite name>.script

   t_ bluetooth.script is used to execute the entire Bluetooth test suite.

Buildrom Overflow Error

The default ROM size for a OMAP (H2, H4 boards) is currently up to 32 MB.

If the ROM is greater than 32MB and less than 64MB in size, then the h2.oby or h4hrp.oby file can be modified, depending on the device being used. The value of "ROMMEGS" must be set to the desired ROM size. Note: This value must be specified in hexadecimal format.

Images executing in RAM consume part of the 64MB of available system memory. Hence, it is critical to ensure that there is enough memory remaining to run the OS and the required application. This availability of memory can vary dynamically depending on usage, so making ROMs that are close to the limit is risky and can slow down the execution rate dramatically. Alternatively, a custom ROM can be built with only a subset of the tests included.

Note: The above options must also be available for other, non OMAP, platforms.

Steps to build and execute tests on phone directly using .pkg file

For ARMV5 platform:

1. EShell and TestExecute:

   The phone must have eshell and testexecute installed.

2. Certificate files:

   Ensure .cer and .key files are placed into /epoc32/pkg/ directory on the PC and rename aszeus.cer and SymbianACS.key correspondingly.

3. Create and install SIS-file:

   Execute makesisfiles.bat from /epoc32/pkg/ directory.

   makesisfiles.bat

   This creates t_btsockaddrapi.sis, t_btuserapi.sis, and t_BTSdpAPI.sis files. The files must be copied to an MMC card, transferred to the phone and executed.

   When the above files are executed, the Bluetooth test suite is installed on the device.

   Note: If there is no SIS installer available, you can use a different tool (for example; STAT desktop, which can be found in %EPOCROOT%\epoc32\tools\stat\statdesktop.exe) to install the .sis file.

4. Running Scripts:

   Run the test scripts. For more information refer to Steps to build and execute tests manually (Tests built into ROM).

Selective Execution of Test Cases using TCS File

Test cases can be executed selectively using a .tcs file. The .tcs file contains the IDs of test cases:

• to be excluded from a test run

• to be executed on their own. Therefore, excluding all other test cases in the test script from a test run.

The test case IDs can be specified as a range, a list, or a combination of both, where each range or individual test case ID is delimited by a new-line character.

For example, range of test case IDs to be excluded can be specified as:

BTSDP-Agent-PublicApi-Active-0301: BTSDP-Agent-PublicApi-Active-0305

Test cases from 301 to 305 (301 and 305 included) are either excluded or are the only ones to be executed during a test run.

A list of test cases IDs can be:

BTSDP-Agent-PublicApi-Active-0301

BTSDP-Agent-PublicApi-Active-0306

BTSDP-Agent-PublicApi-Active-0310

A combination of range and list can be:

BTSDP-Agent-PublicApi-Active-0301:BTSDP-Agent-PublicApi-Active-0305

BTSDP-PublicApi-AttrValBool-Active-Master-0001:BTSDP-PublicApi-AttrValBool-Active-Master-005

BTSDP-PublicApi-AttrValNil-Active-Master-0104

BTSDP-PublicApi-AttrIdMatchList-Active-Master-0201

There is a .tcs file corresponding to each test script, , which is located at the following location:

…\bluetoothapitest\bluetoothsvs\config

For more information on location of .tcs files, see TCS file source location in T_BTGavdpAPI Test Suite, and TCS file source location in BT-USER API Test Suite.

The .tcs file must be modified when using the test driver for test execution. When executing the tests manually, the following testexecute command illustrates the usage of the .tcs file:

testexecute %EPOCROOT%\epoc32\release\winscw\<urel/udeb>\<test suite name>.script –[tcx|tci] %EPOCROOT%\epoc32\release\winscw\<urel/udeb>\t_bluetooth.tcs

The -tcx switch is used to execute all the tests in the specified script excluding the test cases specified in the .tcs file. The –tci switch is used to execute only the tests specified in the .tcs file from the specified script.

Test Results

Test results log file location

After tests complete execution, result logs can be found on the system drive of the device in the \logs\testexecute\ directory. On the PC, if tests are executed using TestDriver, results can be in one of the following folders:

• %EPOCROOT%\epoc32\TestDriver\results\

• %EPOCROOT%\epoc32\winscw\c\logs\testexecute

If the tests are run manually. When using TestDriver, a new test result folder is created for each test run that is, results are not overwritten each time a test run is executed. A .html log file can be found for each script contained in the suite, in its own subfolder.

Each testcase in the script contains one test block, which performs some of the actions on an API. The log will display the percentage of testcases that have passed successfully. The script should ideally have a 100% pass rate.

How to interpret test results

Each test suite produces its own HTML log file containing the results of the test run. While examining the log file, the results at the bottom of the log must be checked first. This gives a summary of the number of tests in the suite that have passed, failed or caused panic. In the body of the log, passed tests are highlighted in green, failed tests in red and tests which caused panic are highlighted in blue.

If a failed or resulted in a panic, the reason for its failure or panic can be known by examining each step in the test case, listed between the “START_TESTCASE” and “END_TESTCASE” tags. The steps which pass will have the word “INFO” followed by some information regarding the step. A failed step will instead have the word “ERROR”, followed by an explanation of the error (usually with an error code). If a panic occurs, there may be no textual explanation for the problem except the panic code (within the blue highlighted text).

When this test suite is run on a real device, some of the tests may fail due to limitations of the device. This is because of the device not having the correct hardware (for example, no BT device exists for a test which needs one), or lack the right software plugins to run the test. This can be spotted if the log displays that a test has failed with the error code -5 (which means KErrNotSupported). This -5 error code means that the test has failed because the functionality is not supported by the device being used. Therefore, tests failing with the error code -5 are not due to defects in the test scripts, but due to the limitations of the device used.

Note: For more information about the TestDriver results, see the Symbian Verification Suite » TestDriver » Using TestDriver » Results » Viewing the test results section.

OS Focussed Components

The tables in this section illustrate the components and classes tested on each Symbian platform baseline.

The following table lists the classes tested of the T_BTSockAddrAPI component on each Symbian platform baseline:

Classes tested of the T_BTSockAddrAPI component

The following table lists the classes tested of the T_BTSockAPI component on each Symbian platform baseline:

Classes tested of the T_BTSockAPI component

The following table lists the classes tested of the T_BTSdpAPI component on each Symbian platform baseline:

Classes tested of the T_BTSdpAPI component

The following table lists the classes tested of the T_BTUserAPI component on each Symbian platform baseline:

Classes tested of the T_BTUserAPI component

Appendix A

NT Remote Access Service (RAS)

If the tests are to be executed on the emulator, the PC should have two COM ports which are connected using null-modem cable. The Symbian emulator talks to one of the COM ports and the NT RAS service talks to the other. If the tests are to be executed on hardware, then one of the serial (COM) ports on the PC has to be connected to the COM3 port on the hardware board.

Before setting up NT RAS, ensure that you read the following steps:

• While configuring NT RAS on a PC, and adding a user, specify the following details:

  • User name: RasUser.

  • Password: test_product1.

  Note: For more information about setting up NTRAS and configuring NTRAS, see Symbian Verification Suite » TestDriver » Using TestDriver » Communicating with the device » Transport modes » Using TCP/IP.

  Note: This information is case-sensitive. Networks differ and may enforce strong passwords. In this scenario, the password should be modified in commdb. This can be done by modifying the following lines in the CommDbNtras.xml file:

  <IfAuthName>RasUser</IfAuthName> 
  <IfAuthPass>test_product1</IfAuthPass>

• While configuring NT RAS on a PC, and setting up the Networking components, if TCP/IP is not setup perform the following steps:

  1. Clear Allow callers to access my area Networks.

  2. Select Specify TCP/IP addresses.

  3. Specify 192.68.0.1 in the From field and 192.68.0.2 in the To field.

• NT RAS is also supported on Windows XP.

  While installing the null modem on a PC on which Windows XP is installed, open the Phone and Modem Settings section, from Control Panel > Printers and other Hardware.

• While configuring NT RAS on a PC on which Windows XP is installed, perform the following steps to create a new connection and configure it.

  1. From Control Panel, select Network and Internet Connections > Network connections > Create a new connection.

  2. In the New connection wizard, click Next.

  3. Select the Set up an Advanced Connection and Accept incoming connections options.

  4. Perform the remaining steps under the Configuring NT RAS section.