Comms-infras +Test Technology

Scope

Components +under test

The Comms-Infras (Communications Architecture Infrastructure) +subsystem provides a framework for the operation of all communication protocols +on a Symbian device.

The Comms-Infras test suites test the esock sub-component.

Test Scope

Published +API testing

This technology area provides a number of test suites +to test APIs that Symbian identify as PublishedAll 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.

For more +details, refer to the individual classes in Comms-Infras +API.

Test +Omissions

The behaviour of the Comms-Infras APIs is dependent +on the protocol being used. The protocols available are dependent on the device +used and so cannot be exhaustively tested. Consequently the test suites are +only tested using the most common protocols (that is, TCP and UDP).

For +more details about omissions in the individual classes, refer to Comms-Infras +API.

Environment

Device +under Test Setup

The device under test (hardware platform/phone/emulator) +must have an appropriate Symbian platform or licensee-UI build.

PC Setup

The PC must have a Symbian or licensee developer +kit, PDT and the relevant compilers (Code Warrior, RVCT, GCCE) installed to +build and execute the test code.

Network +Environment Setup

The PC and the device under test must be on +the same network.

The Comms-Infras test suites use sockets to send +and receive data. To ensure that the full networking stack is tested correctly, +the sockets on the PC and the device under test must be able send and receive +data between each other. Two PC ports, port 10007 for TCP data and port 10008 +for UDP data, listen for and receive TCP and UDP data respectively sent by +the device under test.

Follow the instructions in Appendix A - Echo Server and Appendix +B - NT RAS to set up TCP/IP communications between the PC and device +under test.

However, it is also possible to use other TCP/IP connections +such as Ethernet and Wi-fi instead of NT RAS. To do this the appropriate table +needs to be referenced from the Comms database (COMMSDAT). You must change +the section [iap_settings] in t_comms-infras.env with +the table used to establish the connection.

+[iap_settings] +NetworkTable=1 <Network table entry number in CommDbCommsInfras.xml> +IAPTable=1 <The IAP entry number in CommDbCommsInfras.xml> +

The default preference for commdb in CommDbCommsInfras.xml is +given below:

+<ConnectionPreferencesTable> + <ConnectionPreferences operation="add"> + <Name>DefaultRecordName-1</Name> + <Ranking>1</Ranking> + <Direction>OUTGOING</Direction> + <BearerSet>CSD</BearerSet> + <DialogPref>DONOTPROMPT</DialogPref> + <IAPRef><my NTAS/ppp connection IAP></IAPRef> + </ConnectionPreferences> +</ConnectionPreferencesTable> +

You need your own CommDbCommsInfras.xml to +do this.

Note: When executing the Comms-Infras test suites +on the emulator or the hardware reference board(H4), the preferred connection +channel should be the NT RAS. The preferred connection cannot be NT RAS when +you execute the Comms-Infras test suites on the real phone WIFI-enabled.

The CommDbCommsInfras.xml file +is in the following location:

...\commsinfrastructureapitest\commsinfrastructuresvs\suite\group

For +command details refer Building +and Execution section.

When execute the Comms-Infras test suites +on the emulator or the hardware reference board(H4), you must first configure +the NT RAS using the instructions in Appendix +B - NT RAS, and a serial port cable to connect the COM port. After +configuring NT RAS, you must build +and execute the tests.

For information about how to execute +the Comms-Infras test suites on the real phone with WIFI enable, see the Appendix +C - Testing on real phone through WIFI connection.

Test dependencies

Note: Any mention of “epoc32” is +offset by %EPOCROOT% that is, the full path where the epoc tree is installed.

Test data

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

…\commsinfrastructureapitest\commsinfrastructuresvs\suite\esock\t_rconnection\testdata
…\commsinfrastructureapitest\commsinfrastructuresvs\suite\esock\t_rsocket\testdata
…\commsinfrastructureapitest\commsinfrastructuresvs\suite\esock\t_rsocketserv\testdata
…\commsinfrastructureapitest\commsinfrastructuresvs\suite\esock\t_rsubconnection\testdata

For more details, refer to Comms-Infras +API.

Building and Execution

The +Comms-infras Test Suite Hierarchical Structure shown below illustrates the +Test Suite structure after building the test suite. General information about +the testdriver test suite structure may be found here » Symbian Verification +Suite » TestDriver V2 » TestDriver Output » Storing tests and results.

Note: This +structure can be seen in the following location after building the test suite + %EPOCROOT%\epoc32\testdriver\testproduct

The Comms-infras +Test Suite Hierarchical Structure is as shown below:

<Component> - Comms-Infras + <Sub-component>-Esock + csd (Circuit Switched Data) + <Class>-RConnection + <suite>-COMINF-ESOCK-RConnection-PublicAPI-Other-Suite + <suite>-COMINF-ESOCK-RConnection-PublicAPI-TCP-Suite + <suite>-COMINF-ESOCK-RConnection-PublicAPI-UDP-Suite + <Class>-RSocket + <suite>-COMINF-ESOCK-RSocket-PublicAPI-Other-Suite + <suite>-COMINF-ESOCK-RSocket-PublicAPI-TCP-Suite + <suite>-COMINF-ESOCK-RSocket-PublicAPI-UDP-Suite + <Class>-RSocketServ + <suite>-COMINF-ESOCK-RSocketServ-PublicAPI-Other-Suite + <suite>-COMINF-ESOCK-RSocketServ-PublicAPI-TCP-Suite + <suite>-COMINF-ESOCK-RSocketServ-PublicAPI-UDP-Suite + psd (Packet Switched Data) + <Class>-RSubConnection + <suite>-COMINF-ESOCK-RSubConnection-PublicAPI-Other-Suite + <suite>-COMINF-ESOCK-RSubConnection-PublicAPI-TCP-Suite + <suite>-COMINF-ESOCK-RSubConnection-PublicAPI-UDP-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:

+
<comms-infras> - +The entire suite is built or executed

+
<comms-infras.esock.csd> - +All the suites below csd that is, RConnection, RSocket, RSocketServ are built/executed.

+
<comms-infras.esock.csd.RConnection> - +All the three RConnection suites are built/executed.

+
<comms-infras.esock.csd.RConnection.RConnection-PublicAPI-Other-Suite> - RConnection-PublicAPI-Other-Suite is built or executed.

+

The commands to be executed on emulator and hardware.

Note +: Refer to Comms-infras Test Suite hierarchical structure for sub-component +and test suite names.

General environment setup

+
IAPSettings in the t_comms-infras.ini file:

+
For WINSCW platform:

Ensure +that under the [IAPSettings] section, IAPTable = 2 to use WinTap.

+
For ARMV5 platform:

Ensure +that under the [IAPSettings] section, IAPTable = 1 to use NT RAS.

+

+
The t_comms-infras.ini file +is generated by executing the InsertIPAddress batch file, which uses the t_comms-infras.env as +a template, in the following location:

…\commsinfrastructureapitest\commsinfrastructuresvs\suite\esock\testdata

See Appendix +A - Echo Server for more details on environment settings

+
The entire Comms-Infras +Test component can be built from …\commsinfrastructureapitest\commsinfrastructuresvs\suite\group\…

Individual +test components can be built from the respective group directory. For example, …\commsinfrastructureapitest\commsinfrastructuresvs\suite\esock\t_<sub-component>\group

Execute the following commands:

InsertIpAddr

bldmake +bldfiles

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

%EPOCROOT%\epoc32\release\winscw\<udeb/urel>ced +z:\comms-infras\CommDbCommsInfras.xml

Note: This +command accomplishes the following:

+
Updates CommDB to use +the appropriate transport mechanism (NT RAS by default). See Appendix B - NT RAS for more details.

+
Suppresses any WinTap +prompts.

+
Updates CommDb to use +the right IAP table.

+

startechoserver

+

Steps to build and execute +automatic tests using Test Driver

For WINSCW platform:

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

+
Test Driver can be configured +using the automated scripts located at:

…\commsinfrastructureapitest\commsinfrastructuresvs\suite\group\…

testdriversetup

testdriversetup.bat calls testdriversetup.pl which +applies an appropriate set of configuration parameters.

Note: +If you execute the tests on the real phone using Test Driver, the eshell and +testexecute must be installed on the phone. See details in Appendix C – Testing on real phone through WIFI connection.

+
Build the test code:

testdriver +build [–p [winscw|armv5]] [–b [udeb|urel]] –s comms-infras[.esock[.<csd|psd>[.<class +name>[.<test suite name >]]]]

Testdriver commands can +be executed from any location.

Note: For tree structure, refer +to Comms-infras Test Suite Hierarchical Structure in Building and Execution section.

+
Execute the Tests:

testdriver +run

+

For ARMV5 platform:

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

+
Communication between +PC and hardware:

The hardware reference board (for example, H4) +must be connected to the PC through USB or serial cable. The ROM image is +built on the PC and transferred to the hardware board through MMC card.

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

+
Test Driver can be configured +using the automated scripts located at:

…\commsinfrastructureapitest\commsinfrastructuresvs\suite\group\…

testdriversetup

testdriversetup.bat calls testdriversetup.pl which +applies an appropriate set of configuration parameters.

+
Build the test code:

testdriver +build [–p [winscw|armv5]] [–b [udeb|urel]] –s comms-infras[.esock[.<csd|psd>[.<class +name>[.<test suite name >]]]]

Testdriver commands can +be executed from any location.

Note: For tree structure, refer +to Comms-infras Test Suite Hierarchical Structure in Building and Execution section.

+
To build the ROM +image:

buildrom -D_STARTUPMODE2 -D_EABI=ARMV5 -DRVCT +-DUSE_STRONG_CRYPTOGRAPHY -D_CUSTOM_COMMSDAT <h2/h4hrp> techview_statapi +td_comms-infras

+
Execute the Tests:

testdriver +run -t <transport service used>

Transport service +used may be “serial<COM port number that is connected to the board>”, “bt<COM +port number for BT dongle>” or “usb<mapped port number>”

+

Note:

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

+
The RSubconnection tests +and COMINF-ESOCK-RSocket-PublicAPI-0024 test case are excluded +from execution. For more information, see Exclusion +of Packet Switched Data (PSD) Tests.

+

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

For WINSCW platform:

+
Setup Scripts:

setup_t_comms-infras.script is +used to execute the entire comms-infras test suite.

setup_COMINF-ESOCK-<class +name>-PublicAPI.script is used to execute class specific test suites.

+
Running Scripts:

Change +directory to

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

+
Execute the Tests:

testexecute +z:\comms-infras\esock\setup_<test suite name>.script

setup_t_comms-infras.script is +used to copy the test data files on to c:\drive.

testexecute +c:\comms-infras\esock\<test suite name>.script

t_comms-infras.script is +used to execute the entire comms-infras test suite.

+

For ARMV5 platform:

+
Build ROM image:

buildrom +-D_EABI=ARMV5 –DRVCT -DUSE_STRONG_CRYPTOGRAPHY -D_CUSTOM_COMMSDAT <h2/h4hrp> +techview td_comms-infras

+
Setup Scripts:

setup_t_comms-infras.script is +used to execute the entire comms-infras test suite.

setup_COMINF-ESOCK-<class +name>-PublicAPI.script is used to execute class specific test suites.

+
Running Scripts:

Open +eshell

+
Execute the Tests:

testexecute +z:\comms-infras\esock\setup_<test suite name>.script

setup_t_comms-infras.script is +used to copy the test data files on to c:\drive.

testexecute +c:\comms-infras\esock\<test suite name>.script

t_comms-infras.script is +used to execute the entire comms-infras test suite.

+

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

For ARMV5 platform:

+
EShell and TestExecute:

The +phone must have eshell and testexecute installed.

+
Certificate files:

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

+
Create and install +SIS-file:

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

makesisfiles.bat

This creates t_rconnection.sis, t_rsocket.sis, t_rsocketserv.sis, and t_rsubconnection.sis files. The files must be copied to an MMC +card, transferred to the phone and executed.

When the above files +are executed, the comms-infras test suite is installed on the device.

+
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 excluded +from a test run by using a .tcs file. The .tcs file +contains the IDs of test cases to be excluded.

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:

COMINF-ESOCK-RSubConnection-PublicAPI-0001: + COMINF-ESOCK-RSubConnection-PublicAPI-0039

A +list of test cases IDs to be excluded can be:

COMINF-ESOCK-RSubConnection-PublicAPI-0001

COMINF-ESOCK-RSubConnection-PublicAPI-0005

COMINF-ESOCK-RSubConnection-PublicAPI-0007

A +combination of range and list can be:

COMINF-ESOCK-RSubConnection-PublicAPI-0005: + COMINF-ESOCK-RSubConnection-PublicAPI-0010

COMINF-ESOCK-RSubConnection-PublicAPI-0015: + COMINF-ESOCK-RSubConnection-PublicAPI-0020

COMINF-ESOCK-RSubConnection-PublicAPI-0030

There +is only one .tcs file, which is located at the following +location:

…\commsinfrastructureapitest\commsinfrastructuresvs\suite\config\t_comms-infras.tcs

For +more information on location of .tcs files , see TCS +File Source Location in Comms-Infras ESOCK Test Suite.

Only .tcs file +is modified during test execution using the test driver.

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_comms-infras.tcs

This executes the specified script +excluding the test cases specified in the .tcs file.

Test Results

Test +Results log file location

After the tests complete execution, +result logs can be found on the system drive of the device in the \logs\testexecute\ +directory. On the PC the location of the results depends on whether the tests +were run using TestDriver or Testexecute. TestDriver places the results in,\epoc32\TestDriver\results\ and +creates a new folder for each test run. Testexecute places the results in + \epoc32\winscw\c\logs\testexecute. A .html log +file can be found for each script contained in the suite, in its own subfolder

Each +test case in the script contains one test block, which performs a number of +actions on an API. The log will display the percentage of test cases 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 . When examining +the log file, the results at the bottom of the log should be checked first. +This gives a summary of the number of tests in the suite that have passed, +failed or panicked. In the body of the log tests which pass are highlighted +in green, tests which fail in red and tests which cause a panic in blue.

If +a failing/panicking test has been identified, its reason for failing/panicking +can be seen by examining each step in the test, 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 failing 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 of the problem, +but a panic code will be given (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 will be because of the device not having the +correct hardware (for example, no modem exists for a test which needs one), +or lacking the right software plugins to run the test. This can be spotted +if the log displays that a test has failed with a -5 error (which means KErrNotSupported). +This -5 error basically means that the test has failed because the functionality +in this test is not supported on the device used. Therefore, any tests failing +with -5 are not due to defects, but to the limitations of the device used.

Refer +to Symbian Verification Suite » TestDriver » Using TestDriver » Results +» Viewing the test results for more information on test driver results.

+
OS Focussed Components
Table 1 illustrates the +sub-components and classes available on each Symbian platform

Table +1 – Component ESOCK class tested on each Symbian platform baseline
+ + + + Symbian platform Baseline +9.1 +9.2 +9.3 +9.4 +9.5 + + +Class1 - RConnection + + +Class2 – RSocketX + + +Class3 – RSocketServ + + +Class4 - RSubConnection + + + + +
X
+
X
+
X
+
X
+
X
+ + +
X
+
X
+
X
+
X
+
X
+ + +
X
+
X
+
X
+
X
+
X
+ + +
X
+
X
+
X
+
X
+
X
+ + + +

+
Appendix A +- Echo Server
To ensure that the full networking stack is correctly +tested, an external IP Echo Server is used to receive data on the PC from +the device under test and echo it back to a port on the device under test.

In +order to send data to the EchoServer, the tests need its IP address (that +is, the real IP address of the PC running the server). This is set in the +global Comms-Infras environment file, t_comms-infras.env, found in the following +location

…\commsinfrastructureapitest\commsinfrastructuresvs\suite\testdata\

t_comms-infras.env +file has the following lines:
[Network] +LocalIpAddress = <insert_local_ip_address_here> +TcpPort =10007 +UdpPort =10008 +LocalPort =2024 +BindPort =10001 +
The <insert_local_ip_address_here> tag needs to be replaced +with IP address of the PC running the EchoServer. For example:
[Network] +LocalIpAddress = 10.10.10.10 +
The bind port is the port on the device under test that sends +TCP and UDP data to the PC. The local port is the port on the device that +receives the data echoed by the echo server on the PC. These ports may be +configured in the t_comms-infras.env file

To generate the t_comms-infras.ini referred +to by the test data files and replace the IP address tag with the IP address +of the PC, execute the following batch file:

…\commsinfrastructureapitest\commsinfrastructuresvs\suite\group\InsertIpAddr.bat

The batch file executes the command, ipconfig, to retrieve the required +IP address.

Note: By default InsertIpAddr gets the IP address +from the ipconfig section ending “Local Area Connection”. If your IP address +is in a different section, you must edit InsertIpAddr.bat, changing “Local +Area Connection” to your section name.

Run Echo Server on the test +PC using the following batch file:

…\commsinfrastructureapitest\commsinfrastructuresvs\suite\group\StartEchoServer.bat

This will launch two command prompt windows. One each for the TCP +and UDP connections made to the server. After running all of the tests the +EchoServer can be stopped by closing the two Echo Server windows.

+
Appendix B +- NT RAS
If the tests are to be executed on the emulator, the PC +must have two COM ports which are connected through a 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 one of the +serial (COM) ports on the PC has to be connected to the COM3 port on the hardware +board.

Here are the full instructions for setting up NT RAS:

B.1 +Install a Null modem

+
Open the Control Panel

+
Open Phone and Modem +Settings (In Windows XP the option can be found in printers and other Hardware)

+
Goto the Modems tab

+
Select Add...

+
Check the "Do not detect +my modem; I will select it from a list." check box

+
Click Next

+
Select the (Standard +Modem Types) - Communications cable between two computers

+
Select the appropriate +com port

+
Click Finish

+
Open the Properties +of the Modem you have just installed

+
Set the maximum port +speed to be 115200 (on the General tab)

+
Goto the Advanced tab

+
Click Change Default +Preferences...

+
Make sure the Port speed +is 115200 and the Flow control is None (on the General tab)

+
Goto the Advanced tab

+
Make sure the Data bits += 8, Parity = None and Stop bits = 1

+
Keep clicking OK to +close all the open dialogs

+

B.2 Configuring NT RAS (Incoming Networking Connections)

+
Open the Control Panel

+
Open Networking and +Dial-up Connections (*)

+
Open Make New Connection

+
Click Next

+
Select the Accept incoming +connections and click Next

+
Check the modem you +have just installed and click Next

+
Select Do no allow virtual +private connections and click Next

+
Add a new user

+
Click Add

+
Enter the following +details (noting the case):

+
User name: RasUser

+
Password: pass

+

Note: Networks differ and may enforce strong passwords. In +such a scenario, the password must be modified in the commdb. This can be +done by modifying the following lines in the CommDbCommsInfras.xml file

+
<IfAuthName>RasUser</IfAuthName>

+
<IfAuthPass>Pass</IfAuthPass>

+

+
Click OK

+
Make sure the new user +is checked

+
Click Next

+

+
Setup the Networking +Components

+
If TCP/IP is not set +up, uncheck "Allow callers to access my area Networks".

+
Check "Specify TCP/IP +addresess" and add "192.68.0.1" to "From:"-mask and "192.68.0.2" to "To:" +mask.

Note: This step may be machine or network dependent.

+
Click Next

+

+
Enter whatever name +you like for the connection name.

+
Click Finish

+
Open the Properties +of the connection you have just created

+
Go to the Users tab

+
Make sure the "Always +allow directly......... a password" check box is unchecked

+
Click OK

+

* Steps 1-6 on XP

+
1. Select Network and +Internet Connections

+
2. Select network connections

+
3. Click on “create +a new connection -> new connection wizard

+
4. Click next

+
5. Select radio button +“set up an advanced connection

+
6. Accept incoming connections

+

Continue as instructed from step 6 onwards.

+
Appendix C +- Testing on real phone through WIFI connection
If the tests are +to be executed on the real phone through WIFI connection, a wireless router +must be connected to the PC to provide a wireless connection channel between +the PC and the real phone.

Before you start testing, configure the +WIFI-enabled phone’s IP address within the wireless IP domain. The phone can +be configured using two types of IP addresses, static IP address and DHCP +IP address.

Due to the convenience consideration of automated running +the test suites, the phone’s WIFI card IP address are configured as the static +IP address . The following are the instructions to set the static IP address:

+
Connect the wireless +router to the PC

+
Switch on the phone’s +WIFI card and search for the WIFI hot spot.

+
Find a router to be +connected to the WIFI hotspot.

+
Open the web browser +from the PC and logon to the administration web page, and move to the static +IP address configuration web page.

The web page of static IP address +configuration shows the MAC address of WIFI card of phone.

+
Click the Add new +record button to bind new static IP address to the MAC address of the +phone’s WIFI card. Once it is done, the wireless router assigns an IP address +to this phone’s WIFI card. Each time when the phone connected, the router +assigns this specified IP address to the phone.

+

When the phone’s WIFI card IP is specified, you also must let the +PC run within the same network domain. This enables you to run InsertIpAddr.bat +during the wireless connection between the PC and router. You can also allocate +a static IP address to the PC through the configuration web page of the wireless +router.

The following are the steps to execute the test on the real +phone through the WIFI connection:

+
Turn on the WIFI on +the real phone and connect it to the PC-connected wireless router.

+
Keep the router connecting +to the PC, and execute the InsertIpAddr.bat to generate +the correct IP allocated with in the wireless router’s domain in the t_comms-infras.ini.

+
The entire Comms-Infras +test component can be built from …\commsinfrastructureapitest\commsinfrastructuresvs\suite\group\...

Individual +test components can be built from the respective group directory. For example,…\commsinfrastructureapitest\commsinfrastructuresvs\suite\esock\t_<sub-component>\group.

Run the following commands :

bldmake bldfiles

abld +test build armv5 urel

Note: To connect to the +licensee server , change back the network cable connection to the original +network from PC side might is needed. When it finished , change back the connection +to the wireless router.

+
Run the following command:

startechoserver

If +you want to build and execute the tests using the testdriver, make sure the statapi application +exists in the phone and it must be run on the real phone before you proceed +for further steps.

+
Configure the TestDriver +using the automated scripts located at …\commsinfrastructureapitest\commsinfrastructuresvs\suite\group\…

Execute +the following commands:

testdriversetup

testdriversetup.bat calls testdriversetup.pl + which applies an appropriate set of configuration +parameters.

testdriver config --testexec OFF

This +command notifies the testdriver that it must not transfer the TEF component +sis file to the real phone if the real phone has already built-in TEF module.

testdriver +config --cert phone_applied_cert_file

testdriver +config --key phone_applied_key_file

+
Connect the PC and the +real phone with USB or some other cable, and execute the following commands:

testdriver +build -p armv5 -b urel -s comms-infras.esock.csd.RConnection

testdriver +run -p armv5 -b urel -s comms-infras.esock.csd.RConnection –t usb1

+

Notes:

+
During the execution, +if the phone’s CommsDB has not cancel the dialog prompt in the ConnectionPreferences +table, you must manually select the WIFI hot spot (IAP) to be connected to +the Echoserver.

+
Ensure that the wireless +connection of the phone remains unaffected because phone has different wireless +signal strength under different situations. For example, wireless strength +may vary with distance.

+
While testing under +the wireless environment, the phone package can be blocked by the PC’s firewall. +To avoid this problem, modify the firewall configuration to turn off this +blocking or close the firewall.

+

+