Manuel d'utilisation / d'entretien du produit 1.2 du fabricant Sun Microsystems
Aller à la page of 130
Java ™ ME TCK F rame work De v elopers Guide V ersion 1.2 July 2007 Sun Microsystems, Inc. www .sun.com.
Please Recycle Copyright 2007 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved. Test suite developer’s guide for the Java ME TCK Framework. THIS PRODUCT CONT AINS CONFIDENTIAL INFORMA TION AND TRADE SECRETS OF SUN MICROSYSTEMS, INC.
iii Contents Preface xv 1. Introduction 1 Getting Started 1 Development Environment 3 Use of the Framework 3 T arget Environment 3 Connectivity Requirements 4 Resource Limitations 5 Framework Bundle 6.
iv Java ME TCK Framework Developer’s Guide • July 2007 Writing an Automated Test 15 ▼ T o Create a Simple Automated T est 16 Building an Updated Simple Test Suite 19 ▼ T o Build an Updated T est Suite 19 Testing an Updated Simple Test Suite 20 ▼ T o T est an Updated T est Suite 20 3.
Contents v remote Attribute 44 remoteSource Attribute 45 executeArgs Attribute 45 Distributed T est Execution 46 Testing User Interfaces With Interactive Tests 48 Client T est Component 49 Remote T es.
vi Java ME TCK Framework Developer’s Guide • July 2007 Marking T rusted T ests 62 Using an Attribute to Mark Double-Duty T ests 63 Granting or Denying Security Permissions 64 Granting Security Per.
Contents vii CommServers 85 Messaging 85 T est Export Support Libraries 85 CDC Agents 85 src Directory 86 Framework Server Classes and Interfaces 86 Agent Classes 87 Digital Signer 87 Preverif ication.
viii Java ME TCK Framework Developer’s Guide • July 2007.
ix Figur es FIGURE 1-1 Framework Configuration for Standard Automated Tests 10 FIGURE 1-2 Framework Configuration for Distributed Tests 11 FIGURE 1-3 Framework Configuration for Interactive Tests 13 F.
x Java ME TCK Framework Developer’s Guide • July 2007.
xi T ables T ABLE 1-1 Configurations and Supported Test Types 8 T ABLE C-1 Framework Test Description Fields 92 T ABLE C-2 Framework Keywords 94.
xii Java ME TCK Framework Developer’s Guide • July 2007.
xiii Code Examples CODE EXAMPLE 3-1 Simple Test Suite testsuite.jtt File 24 CODE EXAMPLE 3-2 Simple Test Class 26 CODE EXAMPLE 4-1 Required Distributed Test Keyword 44 CODE EXAMPLE 4-2 remote Attribut.
xiv Java ME TCK Framework Developer’s Guide • July 2007 CODE EXAMPLE 4-19 Test Description That Grants Permissions for a Security Test 65 CODE EXAMPLE 4-20 deny Attribute in the Test Description 6.
xv Pr eface This guide describes how to use resour ces from the Java™ Platform, Micro Edition T echnology Configuration Kit Framework (Framework) to develop and configur e test suites and tests for Java Platform, Micro Edition (Java ME platform) technologies.
xvi Java ME TCK Framework Developer’s Guide • July 2007 ■ JavaT est Harness User ’ s Guide: Graphical User Interface This guide provides a description of using the harness Graphical-User Interface (GUI). This guide is available from the Java ME T echnology APIs and Docs web site at http://java.
Preface xvii Platform Commands This document does not contain information about basic platform commands and procedur es such as shutting down the system, booting the system, and configuring devices.
xviii Java ME TCK Framework Developer’s Guide • July 2007 T ypographic Conventions This guide uses the following typographic conventions: Related Documentation When installed, the Framework includes a doc directory that contains both Framework and harness documentation in PDF and HTML format.
Preface xix Accessing Sun Documentation Online The Java Developer Connection™ program web site enables you to access Java platform technical documentation at http://java.sun.com/ . Sun W elcomes Y our Comments W e are interested in improving our documentation and welcome your comments and suggestions.
xx Java ME TCK Framework Developer’s Guide • July 2007.
1 CHAPTER 1 Intr oduction This chapter introduces using the Framework resour ces to develop test suites for the Java ME platform, including descriptions of the kinds of tests that a test suite can include.
2 Java ME TCK Framework Developer’s Guide • July 2007 Note – The TCK Project Planning Guide and the Java T echnology T est Suite Development Guide documents were originally developed as part of a product used by the Java Community Process (JCP) Specif ication Leads.
Chapter 1 Introduction 3 Development Envir onment The following tools and resources ar e the minimum software r equirements for the Framework development environment: ■ JDK, version 5.
4 Java ME TCK Framework Developer’s Guide • July 2007 Configuration (CDC) and a prof ile such as Mobile Information Device Profile (MIDP), Foundation Prof ile (FP), Personal Basis Profile (PBP), or Personal Prof ile (PP).
Chapter 1 Introduction 5 Resource Limitations Hardwar e resources on test devices ar e often limited. Resource constrained devices can quit operation when excess native resources ar e requested. The Framework can run tests on r esource constrained target devices with limited available memory and persistent storage.
6 Java ME TCK Framework Developer’s Guide • July 2007 Framework Bundle The Framework resour ces are packaged and provided to users as a zip bundle.
Chapter 1 Introduction 7 Framework Components on the Harness Side The following components are used for running CLDC, MIDP , and CDC tests in the Distributed, OT A, and Automated test configurations with the harness: ■ Execution server - Used in CLDC and MIDP Distributed and Automated test configurations.
8 Java ME TCK Framework Developer’s Guide • July 2007 An agent is a separate program that works in conjunction with the harness to run tests on the device.
Chapter 1 Introduction 9 Automated T ests Automated tests for CLDC, MIDP , and CDC configurations execute on the test device without requiring user interaction. Automated tests can be queued up and run by the test harness and their results r ecorded without the user being pr esent.
10 Java ME TCK Framework Developer’s Guide • July 2007 FIGURE 1-1 Framework Conf iguration for Standard Automated T ests Diagram of a standard automated test configuration. Distributed T ests Distributed tests are a special type of automated tests.
Chapter 1 Introduction 11 Distributed tests are typically slower (due to extra communication between remote components) and more complex than simple automated tests and should be used only when it’s not possible to write simple automated tests. FIGURE 1-2 illustrates the Framework configuration for running CLDC and MIDP distributed tests.
12 Java ME TCK Framework Developer’s Guide • July 2007 Interactive T ests Interactive tests are the tests that requir e some form of user interaction and cannot be executed without such interaction. From a design point of view , interactive tests are a subtype of distributed test.
Chapter 1 Introduction 13 FIGURE 1-3 Framework Conf iguration for Interactive T ests Diagram of the interactive test configuration. OT A T ests OT A tests are MIDP-specif ic tests that verify the over-the-air (OT A) application provisioning implementation.
14 Java ME TCK Framework Developer’s Guide • July 2007 OT A tests validate API functionality while the device is connected to a remote host (the PC or workstation where the harness runs).
15 CHAPTER 2 W riting a Simple Automated T est Automated test execution is the most common and simple of the test configurations that are run on the test device. User interaction is not r equired to run automated tests. The following instructions describe how to create a simple automated test and add it to an existing Framework supplied test suite.
16 Java ME TCK Framework Developer’s Guide • July 2007 ■ Each test case method must take no arguments, and must return a Status object that repr esents the outcome of the test case. The Status can be either Status.passed(String) or Status.failed(String) .
Chapter 2 Writing a Simple Automated T est 17 2. Save this f ile in the Simple T est Suite source as SimpleTestSuite/tests/pkg3/Test3.java . The pkg3 folder does not exist in SimpleTestSuite/tests and can be created by the test developer when saving Test3.
18 Java ME TCK Framework Developer’s Guide • July 2007 Note – The contents of this test description file corr espond to the Test3.java test class. 4. Save this f ile in the Simple T est Suite source as SimpleTestSuite/tests/pkg3/index.html . The index.
Chapter 2 Writing a Simple Automated T est 19 Building an Updated Simple T est Suite The following steps demonstrate how to build an updated test suite after adding a test.
20 Java ME TCK Framework Developer’s Guide • July 2007 3. Enter the ant command to invoke the ant build script. The build creates a SimpleTestSuite-build dir ectory containing the test suite.
Chapter 2 Writing a Simple Automated T est 21 3. Use the Conf iguration Editor to provide conf iguration information required to run the updated test suite. 4. After you complete the interview , choose Run T est > Start on the T est Manager main menu to start the test suite.
22 Java ME TCK Framework Developer’s Guide • July 2007.
23 CHAPTER 3 T est Suite Constr uction This chapter describes the organization and construction of a Java ME technology test suite that uses Framework resour ces. Additional information about constructing test suites for use with the JavaT est harness can be located in Chapters 4 and 8 of the JavaT est Architect’ s Guide .
24 Java ME TCK Framework Developer’s Guide • July 2007 ■ lib directory ■ tests directory ■ classes directory ■ doc directory testsuite.jtt File The testsuite.jtt file is located in the r oot directory of the test suite. It provides a registry of information about the test suite and def ines test suite properties.
Chapter 3 T est Suite Construction 25 The testsuite.jtt file is located under the r oot directory of the Simple T est Suite. Y ou can also find it under the build/ directory of the Simple T est Suite source. lib Dir ectory The lib directory usually contains the javatest.
26 Java ME TCK Framework Developer’s Guide • July 2007 Organize the tests hierar chically the way you want them displayed in the test tree. The T est Manager in the harness displays the test hierarchy , enabling users to select and run specific gr oups of tests from the GUI.
Chapter 3 T est Suite Construction 27 Additional examples (T est1.java and T est2.java)can be found in the following Simple T est Suite directories: ■ SimpleTestSuite/tests/sample/pkg1/ ■ SimpleTe.
28 Java ME TCK Framework Developer’s Guide • July 2007 The classes directory generally contains following sub-dir ectories: ■ classes/preverified - Contains the preverif ied test classes. ■ classes/shared/testClasses.lst - The test class dependency file ( testClasses.
Chapter 3 T est Suite Construction 29 In the test description file, $testHost and $testPort ar e test environment variables and are r eplaced by actual values obtained from the test environment.
30 Java ME TCK Framework Developer’s Guide • July 2007 1. Def ine the environment variable required by the test. In the example ( Test2.java ), the test case SampleStringValue() checks if the sampleValue that is passed in equals Hello . The harness requir es the sampleValue environment variable to run the test.
Chapter 3 T est Suite Construction 31 a. Create a class ( SampleInterview ) that is a subtype of the Interview class. The following code creates the SampleInterview class. b. Identify the new interview ( SampleInterview ) as a sub-interview of the parent interview .
32 Java ME TCK Framework Developer’s Guide • July 2007 d. Use the setFirstQuestion method in the constructor to specify the f irst question in the sub-interview . The following setFirstQuestion code in the SampleInterview example specifies the f irst question.
Chapter 3 T est Suite Construction 33 f. Implement exporting the conf iguration value to the test environment. One of the goals of the interview is to export the configuration value to the test environment. Each question has an export() method that is used for this purpose.
34 Java ME TCK Framework Developer’s Guide • July 2007 h. Use the getNext() method to determine the next question in the sub- interview . Every question except the Final question must provide a getNext() method that determines the next (successor) question or null.
Chapter 3 T est Suite Construction 35 j. Use the FinalQuestion marker to identify the last question in the sub- interview . At the end of the sub-interview , have the last question return an instance of FinalQuestion . FinalQuestion is only a marker and does not have question text, More Info, or a getNext method.
36 Java ME TCK Framework Developer’s Guide • July 2007 4. Update the interview .properties (resource) f ile. All question text is located in the interview .properties file associated with the interview class files and is identified by a unique question key .
Chapter 3 T est Suite Construction 37 a. Create a help directory under the directory where the interview classes are located. For this example, use the following location: SimpleTestSuite/src/sample/suite/help b. Create a helpset f ile ( sampleInterview.
38 Java ME TCK Framework Developer’s Guide • July 2007 d. Create a map f ile ( sampleInterview.jhm )i nt h e default directory . The JavaHelp system uses IDs from a map f ile to identify both the location and the HTML files that it loads for the More Info system.
Chapter 3 T est Suite Construction 39 e. Create the More Info topic f iles. The More Info topic f iles are provided in HTML format and displayed in the Configuration Editor ’s More Info pane. Refer to the JavaT est Architect’ s Guide for the procedur e for creating More Info topic f iles.
40 Java ME TCK Framework Developer’s Guide • July 2007 Building a T est Suite Refer to Chapter 2 , “Building an Updated Simple T est Suite” on page 19 for the procedur e to build a Java ME technology test suite by using Framework resour ces.
41 CHAPTER 4 W riting T ests This chapter describes how to write different types of Java ME technology tests that use Framework resour ces and to set special properties requir ed by the tests. General information about the process of creating tests can be located in Chapters 5 and 6 of the Java T echnology T est Suite Development Guide .
42 Java ME TCK Framework Developer’s Guide • July 2007 Automated T est Execution FIGURE 4-1 and the associated text are for CLDC and MIDP execution mode. In the diagram, arrows indicate the direction of dataf low between the device and the workstation.
Chapter 4 Writing T ests 43 While the tests from the application bundle ar e loaded onto the device by the AMS, the execution server establishes the sequence in which the tests in the bundle are run. 5. sendTestResult - The agent returns the test r esults to the execution server .
44 Java ME TCK Framework Developer’s Guide • July 2007 The client test component must use the send and handleMessage methods in the J2MEDistributedTest class to send and receive messages to or from the other named components of the distributed test.
Chapter 4 Writing T ests 45 The following is an example of the remote attribute entry that must be added to the test description file. In the example, the remote attribute execution command is composed of the following values: ■ sample.pkg.SampleDistributedTest is the fully qualified name of the remote test class.
46 Java ME TCK Framework Developer’s Guide • July 2007 The following is an example of the executeArgs attribute entry in which the $testMsgSwitch and $timeOut environment variables are specif ied. Distributed T est Execution FIGURE 4-2 and the associated text are for MIDP execution mode.
Chapter 4 Writing T ests 47 FIGURE 4-2 Distributed T est Execution 1. getNextApp - The AMS issues a getNextApp command to the execution server on the workstation. The AMS implementation is device specific and must be provided by the licensee. 2. Application Bundle - The execution server sends an application bundle to the AMS.
48 Java ME TCK Framework Developer’s Guide • July 2007 5. Check or Send Message - The test sends either a message or a check message request to the Framework messaging service on the harness. 6. Get Message - The Framework messaging service on the harness sends the test a get message command.
Chapter 4 Writing T ests 49 Client T est Component The client test component of the interactive test must extend the MidDistribInteractiveTest class. This is the base class for distributed interactive tests and extends the com.sun.tck.j2me.services.messagingService.
50 Java ME TCK Framework Developer’s Guide • July 2007 The test description might also include the remoteSource and executeArgs attributes. See “ remoteSource Attribute” on page 45 and “ executeArgs Attribute” on page 45 for a description and example of these attribute entries.
Chapter 4 Writing T ests 51 FIGURE 4-3 Interactive T est Execution 1. getNextApp - The AMS issues a getNextApp command to the execution server on the workstation. The AMS implementation is device specific and must be provided by the licensee. 2. Application Bundle - The execution server sends an application bundle to the AMS.
52 Java ME TCK Framework Developer’s Guide • July 2007 4. T est Name - The execution server returns the name of the next test in the application bundle that the AMS should run.
Chapter 4 Writing T ests 53 T esting Application Pr ovisioning W ith OT A T ests Over-the-air (OT A) tests ar e MIDP-specific tests that verify an OT A application provisioning implementation. This includes obtaining, installing, and removing applications (MIDlet suites), and enforcing security requir ements.
54 Java ME TCK Framework Developer’s Guide • July 2007 done at the build time. If the test writer creates a JAR file or a JAD f ile with special information about the MIDlet suite as part of the bundle, the test writer must also create a manifest f ile ( .
Chapter 4 Writing T ests 55 remote Attribute The remote attribute specifies the execution command for the server test component. The following is an example of the remote attribute entry that must be added to the test description file. In the remote attribute, sample.
56 Java ME TCK Framework Developer’s Guide • July 2007 The following is an example of a test description for a trusted OT A test. See “ remote Attribute” on page 55 for a description of the values that must be set in the remote attribute for a trusted OT A test.
Chapter 4 Writing T ests 57 OT A T est Execution In FIGURE 4-4 , arrows indicate the dir ection of dataflow between the device and the workstation. The numbered items indicate the sequence and the content of the dataflow .
58 Java ME TCK Framework Developer’s Guide • July 2007 FIGURE 4-4 OT A T est Execution 1. Request an Action - The server-side test r equests an action from the test operator .
Chapter 4 Writing T ests 59 Example of OT A T est The following is an example of an OT A server component. In the example, the source of the MIDlet suite is named Test_MIDlet.java and the JAD file is Test_MIDlet.jad . The JAD file contains the manifest f ile and the Test_MIDlet.
60 Java ME TCK Framework Developer’s Guide • July 2007 T esting Security-Constrained Functionality W ith Security T ests This section addresses writing dif ferent types of security tests, using ke.
Chapter 4 Writing T ests 61 T rusted T ests T rusted tests verify API implementation behavior for signed MIDlet suites. In most cases, these tests verify that specification assertions related to signed MIDlet suites are pr operly implemented.
62 Java ME TCK Framework Developer’s Guide • July 2007 If other keywords (such as positive ) are used, they would be included in the same line as the untrusted keyword. The following is an example of a test description file that uses runtime , positive , and untrusted keywor ds.
Chapter 4 Writing T ests 63 The following is an example of adding a trusted keyword entry to a test description file. When other keywords (such as positive ) ar e used, they are included in the same line as the trusted keyword and separated by white space.
64 Java ME TCK Framework Developer’s Guide • July 2007 Granting or Denying Security Permissions A security test might requir e that certain permissions be granted (or denied) for the test to pass. The test is run or not run accor ding to the permissions that a test writer grants or denies.
Chapter 4 Writing T ests 65 The following is an example of a grant attribute and permissions added to a test description file. The value of the grant attribute is a list of space-separated permissions (in the example, javax.microedition.io.Connector.file.
66 Java ME TCK Framework Developer’s Guide • July 2007 Denying Security Permissions When writing security tests, a test writer can specify the permissions that the security policy must not grant in the protection domain for this test application to execute and pass.
Chapter 4 Writing T ests 67 Adding Resour ce Files in T ests T est writers must sometimes develop tests that require extra r esource f iles (such as image, data, or class files) for the test execution.
68 Java ME TCK Framework Developer’s Guide • July 2007 For example, the following test requir es a Duke.png to create the Image object for successful execution. For this test example, the following is a resources entry that might be added to the test description file.
Chapter 4 Writing T ests 69 The following is an example of a test description file containing a resources entry , directory , and f ile name. CODE EXAMPLE 4-24 T est Description That Includes Resource.
70 Java ME TCK Framework Developer’s Guide • July 2007 Enabling T est Selection T est selection in a test run is of value to a user when a test suite includes tests for optional features that wer e not implemented.
Chapter 4 Writing T ests 71 ■ selectIf expression in test description - This mechanism provides a flexible way for developers to make individual tests selectable ( com.sun.tck.j2me.javatest.ExprFilter ) by including a selectIf expression in test description.
72 Java ME TCK Framework Developer’s Guide • July 2007 1. Add a selectIf entry to the test description f ile for a test class that users might be required to f ilter out of a test run. The following is an example of a selectIF entry added to a test description f ile.
Chapter 4 Writing T ests 73 <TR> <TD SCOPE="row"> <B>selectIf</B> </TD> <TD> isFeatureSupported </TD> </TR> </TABLE> </BODY> </.
74 Java ME TCK Framework Developer’s Guide • July 2007 2. W rite an interview question that obtains the value of the environment variable from the user . T o obtain the value of environment variables from users, test developers must write an interview class and create the requir ed interview questions.
Chapter 4 Writing T ests 75 3. Add interview question .smry and .text entries to the .properties f ile. For each added interview question, the developer must cr eate corresponding .smry and .text entries in the resour ce file ( .properties ). The following is an example of the .
76 Java ME TCK Framework Developer’s Guide • July 2007 Question keys are cr eated in the following form: interview-class-name . question-name ■ The .smry entry specifies the question title (in the example, Feature Support ) that the Configuration Editor displays to the user .
77 APPENDIX A T est API The following is the Java ME technology-specific API that every test developer must know: ■ Test ■ Status ■ MultiTest ■ J2MEDistributedTest ■ J2SEDistributedTest ■ DistribInteractiveTest ■ OTATest Test Interface name: com.
78 Java ME TCK Framework Developer’s Guide • July 2007 A test must also define main as follows: Defining main in this manner enables the test to also be run standalone, independent of the harness. Status Class name: com.sun.tck.cldc.lib.Status This is a Java ME technology version of the standard harness Status class.
Appendix A T est API 79 J2MEDistributedTest Class name: com.sun.tck.j2me.services.messagingService.J2MEDistributedTest This is the base class for distributed tests for the Java ME technology component of the test. Each distributed test has a unique name used for identification during message exchange.
80 Java ME TCK Framework Developer’s Guide • July 2007 OTATest Class name: com.sun.tck.midp.lib.OTATest This is the base class for the Java SE technology component of an OT A test. It provides various convenience methods which trigger installation, execution, or removal of an application.
81 APPENDIX B Framework Bundle This appendix describes the contents of the redistributables directory pr ovided by the Framework bundle. The contents of the redistributables directory are or ganized i.
82 Java ME TCK Framework Developer’s Guide • July 2007 ■ tckbuild.jar - Utility classes used by TCK build. ■ j2me-tck-framework_12.txt - Framework version marker (this file has no content). ■ midptck.ks - Standard keystor e containing default certificates used for MIDP application signing.
Appendix B Fr amework Bundle 83 Cor e The following are cor e Framework files provided in the lib dir ectory: ■ j2mefw_jt.jar - Harness plug-in code. Most of the Java SE platform code to support ME TCKs is in this file. ■ interviewlib.jar - Helper library for interview creation.
84 Java ME TCK Framework Developer’s Guide • July 2007 ■ cldc_agent.jar - Standard harness agent for CLDC. Application model: Main Communication channel: pluggable. Plug-ins The following are the plug-in .jar files pr ovided in the lib directory: ■ cldc_httpsrvr.
Appendix B Fr amework Bundle 85 ■ cldc_commClient.jar - Implementation of the Client interface for the CLDC device. This client uses HTTP for communication. ■ datagram_commClient.jar - Distributed test communication client interface implementation that uses datagrams for communication.
86 Java ME TCK Framework Developer’s Guide • July 2007 Application model: Xlet Pluggable communication channel ■ applet_agent.jar - JavaT est agent for Personal Prof ile.
Appendix B Fr amework Bundle 87 Agent Classes The following are the agent classes and interfaces provided in the src directory: ■ com/sun/cldc/communication/Client - Communication interface ■ com/.
88 Java ME TCK Framework Developer’s Guide • July 2007 ■ com/sun/tck/midp/interview/VmAdvancedInterview ■ com/sun/tck/midp/interview/VmInterview ■ com/sun/tck/midp/interview/MidpTckInterview.
Appendix B Fr amework Bundle 89 This class provides an implementation of the harness distribution mechanism on top of HTTP . ■ com/sun/tck/midp/javatest/MidBundler - MIDP-specific extension that builds on top of the generic CLDC mechanism. ■ com/sun/tck/midp/javatest/MessageSwitch - Support for distributed tests on MIDP .
90 Java ME TCK Framework Developer’s Guide • July 2007.
91 APPENDIX C T est Description Fields and Keywor ds This appendix describes the Framework supported fields and keywords for test description files. The JavaT est harness requir es that each test is accompanied by machine readable descriptive data in the form of test suite-specific name-value pairs contained in a test description file.
92 Java ME TCK Framework Developer’s Guide • July 2007 T ABLE C-1 lists the test description fields supported by the Framework and describes how their values are used by the harness when the tests are run. T ABLE C-1 Framework T est Description Fields Field Description title A descriptive string that identifies what the test does.
Appendix C T est Description Fields and K eywords 93 executeArgs An array of strings that are passed to the test classes being executed. The arguments might be f ixed but often involve symbolic values that are substituted from the test environment (variables def ined elsewhere in the test environment).
94 Java ME TCK Framework Developer’s Guide • July 2007 Keywor ds Keywords ar e tokens associated with specific tests. Keywords have the following functions: ■ Convey information to the harness a.
Appendix C T est Description Fields and K eywords 95 runtime Identifies tests used with runtime pr oducts. trusted Identifies tests which must be run in a trusted (operator , manufacturer , and trusted third party) security domain. untrusted Identifies tests which must be run in an untr usted (unidentified third party) security domain.
96 Java ME TCK Framework Developer’s Guide • July 2007.
97 Glossary The definitions in this glossary ar e intended for Java Compatibility T est T ools (Java CTT) and Java T echnology Compatibility Kits (TCK).
98 Java ME TCK Framework Developer’s Guide • July 2007 appeals process A process for challenging the fairness, validity , accuracy , or relevance of one or more TCK tests. T ests that are successfully challenged are either corr ected or added to the TCK’s exclude list .
Glossary 99 boundary value analysis A test case development technique that entails developing additional test cases based on the boundaries defined by pr eviously categorized equivalence classes. class The prototype for an object in an object-oriented language.
100 Java ME TCK Framework Developer’s Guide • July 2007 distributed tests T ests consisting of multiple components that are r unning on both the device and the JavaT est harness host.
Glossary 101 Java Platform, Standard Edition (Java SE platform) A set of specifications that def ines the desktop runtime environment r equired for the deployment of Java technology applications. Java SE platform implementations are available for a variety of platforms, but most notably the Solaris and W indows operating systems.
102 Java ME TCK Framework Developer’s Guide • July 2007 JavaT est harness A test harness developed by Sun to manage test execution and result reporting for a T echnology Compatibility Kit (TCK) . The harness conf igures, sequences, and runs test suites.
Glossary 103 included according to the r eferencing rules set out in that platform edition specification. Other r eferenced specif ications must be referenced in their entirety . Program Management Off ice (PMO) The administrative structur e that implements the Java Community Process (JCP) program .
104 Java ME TCK Framework Developer’s Guide • July 2007 structure-based testing A set of test development methodologies that are based on the internal structure or logic of the system under test, not the description, behavior , or requir ements of that system.
Glossary 105 test command template A generalized specification of a test command in a test envir onment . The test command is specified in the test envir onment using variables so that it can execute any test in the test suite regar dless of its arguments.
106 Java ME TCK Framework Developer’s Guide • July 2007 work directory A directory associated with a specif ic test suite and used by the JavaT est harness to store f iles containing information about the test suite and its tests.
107 Index Symbols .jtx files, 100 A active agent, 97 active applet instance, 97 agent, 97 agent monitor, 97 AID, 98 all values, 97 AMS, 98 APDU, 98 API, 98 API member, 97 API member test, 97 appeals .
108 Ja va ME TCK F ramework Dev eloper’ s Guide • July 2007 I instantiation, 100 interactive tests, 10 0 ISO 7816-4, 9 8 J JAM, 101 JAR, 101 Java Application Manager, 10 1 Java Archive, 101 Java C.
Index 109 work directory, 106.
110 Ja va ME TCK F ramework Dev eloper’ s Guide • July 2007.
Un point important après l'achat de l'appareil (ou même avant l'achat) est de lire le manuel d'utilisation. Nous devons le faire pour quelques raisons simples:
Si vous n'avez pas encore acheté Sun Microsystems 1.2 c'est un bon moment pour vous familiariser avec les données de base sur le produit. Consulter d'abord les pages initiales du manuel d'utilisation, que vous trouverez ci-dessus. Vous devriez y trouver les données techniques les plus importants du Sun Microsystems 1.2 - de cette manière, vous pouvez vérifier si l'équipement répond à vos besoins. Explorant les pages suivantes du manuel d'utilisation Sun Microsystems 1.2, vous apprendrez toutes les caractéristiques du produit et des informations sur son fonctionnement. Les informations sur le Sun Microsystems 1.2 va certainement vous aider à prendre une décision concernant l'achat.
Dans une situation où vous avez déjà le Sun Microsystems 1.2, mais vous avez pas encore lu le manuel d'utilisation, vous devez le faire pour les raisons décrites ci-dessus,. Vous saurez alors si vous avez correctement utilisé les fonctions disponibles, et si vous avez commis des erreurs qui peuvent réduire la durée de vie du Sun Microsystems 1.2.
Cependant, l'un des rôles les plus importants pour l'utilisateur joués par les manuels d'utilisateur est d'aider à résoudre les problèmes concernant le Sun Microsystems 1.2. Presque toujours, vous y trouverez Troubleshooting, soit les pannes et les défaillances les plus fréquentes de l'apparei Sun Microsystems 1.2 ainsi que les instructions sur la façon de les résoudre. Même si vous ne parvenez pas à résoudre le problème, le manuel d‘utilisation va vous montrer le chemin d'une nouvelle procédure – le contact avec le centre de service à la clientèle ou le service le plus proche.
