Java Device Test Suite Tester’s Guide

For runtime and benchmark tests, there are several ways to connect the test device to the harness so that tests can flow to the device and test results can flow to the harness. This chapter describes the options and the details of test device-harness communication in the following sections:

• Test Device Requirements
• Test Device Connection Options
• Specifying the Transmission of Bundles and Results

The material in this chapter does not apply to over-the-air provisioning (OTA) tests. Those tests are structured very differently and have no options for communication. In particular, the means of bundle transfer and result disposition described in this chapter has no effect on the execution of OTA tests. See OTA Provisioning Test Architecture for information.

---

Test Device Requirements

Test devices must meet these requirements:

• Heap space. At least 128KB of heap space is required. Some tests require more space.
• MIDlet suite size: A test device must be able to download and install MIDlet suites (test bundles) of at least 80Kbytes in size. Most tests are larger but can fit in 128Kbyte bundles. A few tests are as large as 1,300Kbytes.

---

Test Device Connection Options

In addition to the device requirements, a test device must support at least one of the connection options described in this section. The connection options support the transfer of tests and results:

• Tests must be transferred from the Relay to a test device so they can run on the device.
• Test results must be transferred from the test device to the Relay so they can be incorporated in reports and displayed in the harness. If the device cannot transfer results, they can be displayed on the device.

Test Bundle Transfer

When you direct the harness to run tests, the harness packs groups of tests into MIDP MIDlet suites, which are called test bundles. To run the tests in a bundle, the bundle must be transferred to the test device, installed, and launched. The bundles can be transferred by HTTP or over a local link, such as a serial cable. You specify your choice in the Tests and Bundles section of a template or configuration. The operations for installing and launching a bundle are device dependent.

HTTP Bundle Transfer

When test bundles are transferred by HTTP, the harness repeatedly creates test bundles and sends them to the Relay. You then download a bundle from the Relay, install it and launch it, which causes the tests to run.

The Relay can transfer test bundles over a TCP/IP connection that supports HTTP version 1.0 or 1.1. The device itself does not need to support HTTP over TCP/IP if bridge hardware or software between the test device and the Relay can act as an HTTP client on behalf of the device. A WAP gateway is one example of such a bridge. FIGURE 4-1 illustrates HTTP test bundle downloading with and without a bridge.

FIGURE 4-1 Test Bundle Transfer Options - HTTP

Local Link Bundle Transfer

The alternative to HTTP bundle transfer is to use a local link, such as serial, infrared, or Bluetooth. This option requires cooperating software on the harness host or another host. In the Configuration Editor, specify a directory into which the harness stores the test bundles. Direct the software to download the test bundles from the directory to the test device. FIGURE 4-2 illustrates test bundle transfer by a local link.

FIGURE 4-2 Test Bundle Transfer - Local Link

Test Result Disposition

For test results to be transferred from a test device to a harness, the test device’s Java software or a gateway interposed between the device and the Relay, must support HTTP version 1.0 or 1.1 over TCP/IP. If the test device or gateway does not support HTTP, test results are not sent to the harness. Instead, test results can be displayed on the device. FIGURE 4-3 illustrates the possible test result disposition options:

FIGURE 4-3 Test Result Disposition Options

---

Specifying the Transmission of Bundles and Results

In the Configuration Editor, specify how tests are downloaded to the test device and how test results are handled. You can choose from the following test bundle transfer and result disposition options:

• Option A. Manually download each test bundle over an HTTP connection. Return the test results to the harness using HTTP.

You can select this value if both of the following conditions are true:

• Bundle Download. You can direct the test device to download, install, and launch a MIDlet suite (a test bundle) from a web server, possibly with assistance from an intermediating bridge, such as a WAP gateway.
• Result Disposition. The test device has working Java methods for HTTP communication that the agent can use to send results to the harness. The results can also pass through a bridge.

• Option B. Manually download each test bundle over an HTTP connection. Hold and display the test results on the test device.

This option is for test devices whose Java methods for HTTP communication are absent or do not work correctly. The device must still be able to download MIDlets using HTTP, which is possible if the device’s native HTTP implementation is working.

• Option C. Manually download each test bundle from a directory on the harness, using a local link such as a serial line. Return the test results to the harness using HTTP.

Select this value if both of the following conditions are true:

• Bundle Download. You can direct the test device, or associated software, to download, install, and launch a MIDlet suite from a harness directory. The MIDlet file transfer can be conducted over a serial line, a Bluetooth connection, an infrared connection, or similar.
• Result Disposition. The test device has working Java methods for HTTP communication that the agent can use to send results to the harness.

• Option D. Manually download each test bundle from a directory on the harness, using a local link such as a serial line. Hold and display the test results on the test device.

This option is for devices whose Java methods for HTTP communication are absent or do not work correctly.

• Option E. Have the test device implement the harness’s autotest protocol, in which the test device repeatedly and automatically downloads, installs, launches, and removes test bundles until all tests have been run. Test results are returned to the harness using HTTP. This option is only available if the device supports the autotest protocol.

If your test device supports more than one of the options consider these factors when making your choice:

• If the test device’s HTTP connection is over the air, options C and D might transfer bundles faster. However, the reverse might be true if the HTTP connection is over a local network, such as Ethernet or Wi-Fi.

When bundles are transferred using a local link and the last test run completes, you must press the Stop button so the harness is no longer waiting for more bundles to be transferred to the test device and is no longer in a run test mode.

• One option might be easier to use, and possibly faster, because it requires fewer test device interactions (such as key presses) to download, install, and launch a test bundle. For example, the local link download software might require fewer keystrokes than downloading over the air.
• If option D is used, you must manually stop the test run when test execution completes or if a problem occurs during test execution. Press the Stop button to stop the test run.
• The autotest protocol is easy to use because the device obtains, installs, launches, and removes test bundles. However, it is usually available only on emulators or specially manufactured versions of test devices.
• The options where results are held on the device are the most inconvenient to use. Select one only if none of the “Send” options work with the test device. The options where results are held on the device do not return results to the harness, require you to manually display interactive test instructions, and only support a subset of tests.