WO2001071502A1 - Procede et systeme destines a tester un logiciel dans des ordinateurs - Google Patents

Procede et systeme destines a tester un logiciel dans des ordinateurs Download PDF

Info

Publication number
WO2001071502A1
WO2001071502A1 PCT/IB2000/000338 IB0000338W WO0171502A1 WO 2001071502 A1 WO2001071502 A1 WO 2001071502A1 IB 0000338 W IB0000338 W IB 0000338W WO 0171502 A1 WO0171502 A1 WO 0171502A1
Authority
WO
WIPO (PCT)
Prior art keywords
local agent
test
instructions
computer
agent
Prior art date
Application number
PCT/IB2000/000338
Other languages
English (en)
Inventor
Stephen Kruger
Original Assignee
Sun Microsystems, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems, Inc. filed Critical Sun Microsystems, Inc.
Priority to PCT/IB2000/000338 priority Critical patent/WO2001071502A1/fr
Priority to AU2000231862A priority patent/AU2000231862A1/en
Publication of WO2001071502A1 publication Critical patent/WO2001071502A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites

Definitions

  • This invention relates to computer technology. More particularly, it deals with testing the compatibility of software with various computer architectures .
  • a new release of a software may comprise a particular version for each computer architecture ("target") to be supported. Each such version has to be tested for full operability within the corresponding target architecture.
  • targets computer architecture
  • the testing process complexity is still further increased when the software to be tested is installed in a computer network comprising computer targets with different architectures, and has networking functions, since the operation between each possible combination of targets also has to be tested.
  • This invention aims at improving the situation.
  • the invention may be firstly defined as a method of testing software in a computer, comprising the steps of : a) providing a primary computer with a software to be tested, b) providing the primary computer with a local agent, the local agent being capable of having commands to be run in the local agent's primary computer, and having a communication interface, c) providing a master computer, arranged for selective communication with the communication interface of the local agent, with a representation of test operations being stored in the master computer, and d) dynamically and selectively sending commands derived from at least certain of the test operations, from said master computer to the local agent.
  • the representation of test operations comprises data stored in correspondence with a designation of the local agent, and a sequence of instructions, at least some of which have the designation of the local agent as a parameter
  • step d) comprises: dl) scanning the sequence of instructions, d2) for at least some of the instructions, building a test command from that instruction and the data corresponding to the local agent parameter of that instruction, and d3) sending the test command to the local agent.
  • the invention may also be defined as a system for testing software in computers, the system comprising : - a primary computer, provided with a software to be tested, and with a local agent, the local agent being capable of having commands to be run in the local agent's primary computer, and the local agent having a communication interface, a master computer, having an interface adapted for selective communication with the local agent interface, and having a memory comprising:
  • test sequence module comprising a representation of a sequence of test operations
  • test control module adapted for sending commands derived from at least certain of the test operations, from said master computer to a selected local agent.
  • test sequence module comprises:
  • test control module comprises:
  • the designation of a local agent may comprise a name given to the local agent, and/or a port number assigned to the local agent.
  • the instructions are selected from a predefined set of instructions forming a test programming language, with the predefined set of instructions comprising an instruction requesting a local agent to start execution of a command.
  • Other instructions may be:
  • the master computer and the target (s) are equipped with a common environment, preferably defining at least one Java virtual machine in each computer, and the local agent (s) is (are) written for this common environment.
  • the invention also extends to the software code of a test program in a master test computer, and to the software code of a local agent.
  • FIG. 1 is a general diagram of a computer network in which the invention is applicable;
  • figure 2 diagrammatically shows the organization of a primary computer or target 2 of figure 1;
  • figure 3 diagrammatically shows the memory organization of the master computer 1 of figure 1 ;
  • FIG. 4 is a flow-chart of a local agent in a target 2;
  • FIG. 5 shows the test supporting files required for creating a specific test environment in a master computer
  • FIG. 6 shows how the successive instructions of a script in the master computer are executed
  • - figure 7 is a flow-chart of the execution of a single instruction in the master computer; and - figure 8 is a flow-chart including the interaction of the master computer with the test personnel.
  • the quote sign " may be used as character string delimiter when deemed necessary for clarity (e.g. "/usr/bin/java” ) ,
  • brackets may be used to frame the optional portion of an entity or name (e.g. "[,VALUE]").
  • the expression "software and hardware architecture” refers mainly to the operating system (OS) and to the motherboard, respectively.
  • the example in the foregoing description considers only one harness computer; however, several harnesses might be used simultaneously as well. Similarly, several targets are considered in the example, although only one target might be used as well. Furthermore, at least in certain situations, the harness (es) and target (s) may be hosted in the same physical machine.
  • this networking feature is not absolutely necessary, since e.g. the harness and the agents may be run on the same physical machine.
  • both the harness (es) and the target(s) may be locally resident or they may be distributed (e.g. as with the server and client relationship) where communication between the two takes place over some sort of network connection e.g. LAN, Internet, etc.
  • release version hereinafter means a new release of a software, in a version adapted to a particular computer architecture (and programming language, if appropriate), or more generally any version modified for some reason.
  • harness 1 has a central processing unit or CPU 11, a RAM 13 (or any other working memory, for example DRAM, SDRAM or flash memory), and a hard disk 14 (or any other mass memory, for example floppy disks, removable drives, or flash memory emulating a disk). It may also have input/output devices like a display 15, a keyboard 19, and a pointer e.g. a mouse 18. A graphic user interface (GUI) may also be included if desired.
  • the interconnections within harness 1 are diagrammatically shown as a single bus 10, although a more complex bus structure is generally used.
  • harness 1 is mainly defined by its CPU 11 and its operating system (OS), stored e.g. in hard disk 14.
  • OS may be, for example, Solaris (a registered trademark of SUN MICROSYSTEMS) or Windows NT (a registered trademark of MICROSOFT) .
  • Other communication interfaces may be used in lieu of TCP sockets.
  • Each target 2-i (Fig. 2) comprises a CPU 21, a RAM 23 (or any other working memory, for example DRAM, SDRAM or flash memory), a hard disk 24 (or any other mass memory, for example floppy disks, removable drives, or flash memory emulating a disk) and optional peripherals (not shown), which may include dedicated equipment, such as network adapters, removable storage media, or pluggable hardware components.
  • a target OS is stored e.g. in hard disk 24.
  • a local file system (LFS) may be organized in hard disk 24 ("local" here means visible to the target, but possibly residing elsewhere, as e.g. in a Network File System or NFS scenario). This is exemplary only, and the invention may apply to other hardware target structures.
  • the targets may also comprise communication equipment enabling them to be interconnected in a network via a medium 9, which may be comprised by e.g. Ethernet or token-ring running e.g. on fiber optics or twisted pair cabling or radio transmission or infra-red transmission. Harness 1 may also be connected to the network.
  • a medium 9 may be comprised by e.g. Ethernet or token-ring running e.g. on fiber optics or twisted pair cabling or radio transmission or infra-red transmission. Harness 1 may also be connected to the network.
  • the targets may have various architectures in terms of hardware and/or software.
  • the target architecture may be a SOLARIS-INTEL, a SOLARIS-SPARC, a WINDOWS NT- INTEL, a WINDOWS NT-ALPHA or a WINDOWS 95-INTEL one.
  • SOLARIS, SPARC are registered trademarks of SUN MICROSYSTEMS
  • INTEL is a registered trademark of INTEL Corp.
  • WINDOWS 95 and WINDOWS NT are registered trademarks of MICROSOFT
  • ALPHA is a registered trademark of DIGITAL EQUIPMENT.
  • the targets may range e.g. from notebooks to desktop stations.
  • the target 2 has in RAM a Java virtual machine or JVM 230, which in turn hosts a local agent 231.
  • the local agent 231 has a TCP server socket 25 to accept connection from the harness, as necessary. These connections are created as requested by the harness, e.g. as illustrated in 25A-17A to 25C-17C.
  • the operating systems of both the harness 1 and the targets 2-i be equipped with a common environment, which the local agents are written for.
  • the Java environment is discussed.
  • the invention is not so limited.
  • the hard disk 14 of harness 1 contains OS files 140, Java supporting files 141, and files 8 supporting the software tests.
  • the Java files 141 are used to implement a Java virtual machine 130 which is executed in the RAM 13 of machine 1, and hosts a "logical" harness 131, which is in fact a program running the test for the target(s) remotely, from the harness, using test supporting files 8, and sockets 17-i.
  • the local agent 231 acts as a kind of "mini- server", capable of communicating with harness 1 on request from this harness, and of running commands in its hosting target 2.
  • the local agent is a program written in a language adapted to the target architecture, and stored in its memory 23.
  • the language may be Java when the target implements a Java virtual Machine. Alternatively, other languages may be used, according to the target architecture and environment.
  • This local agent program 231 (more briefly "local agent”) is arranged for managing the local target TCP socket 25. This enables communication between the target local agent 231 and the harness 1, independently of other target local agents. So, each local agent is attached to one TCP socket 25 of its hosting target computer 2. As illustrated in Fig. 2, if three local agents are implemented in the same target computer, that target computer will have three TCP sockets 25A through 25C, each of which may be implemented through a server socket. Although each local agent is preferably hosted in its own JVM, this is not shown in the simplified representation of Fig. 2.
  • step 40 a local agent waits for receipt of a request from the harness, on its dedicated TCP socket.
  • step 42 may optionally check e.g. the syntax and/or arguments of the request and its arguments, at least partially. If the request is found not consistent (at 44), then an error is returned to the harness at step 45, and control is given to step 40. Otherwise (normally), step 47 launches execution of the request in the local target ; a report, together with results if appropriate, is returned to the harness at step 49, and control is returned to step 40 of waiting for another request from the harness.
  • the program for such a harness and local agent interaction may be written e.g. in Java, or in any other desired language, including Interface Definition Language (IDL) of the Object Management Group (OMG), and converted into an executable version in the target.
  • IDL Interface Definition Language
  • OMG Object Management Group
  • a number of functionalities may have to be implemented in the local agent, depending upon the set of harness commands to be executed in the target, as described hereinafter. Programming each of these functionalities is considered accessible to men skilled in the art.
  • each target 2-i is provided with a copy, or a portion of a copy, of the software to be tested, in a release version matching its own architecture (as above defined), and also matching its supported programming languages, if appropriate.
  • the release version may be previously installed in the mass memory 24 of the target, or selectively sent from the harness 1 to the target 2-i e.g. through the network, just before running a test.
  • the release version may be an application, which may involve information obtained through communication with other computers, or from local files stored in the mass memory or hard disk 24.
  • Harness 1 is used for selectively distributing specific test sequences to the targets 2-i, in which respective release versions have to be tested.
  • the specific sequences are basically intended for selecting the release versions to correctly operate within the target architec- tures.
  • harness 1 has test supporting files 8 stored in its hard disk 14.
  • the test supporting files 8 firstly comprise agent definitions 81, which comprise agent variables (or agent properties, for e.g. as given in Example A.l in Exhibit A).
  • agent variables or agent properties, for e.g. as given in Example A.l in Exhibit A.
  • agent properties include at least a portion of the information needed at the harness level for sending that local agent a request being executable in the target.
  • the test supporting files 8 further comprise a generic test section 84, having, in the example: - target OS specific test code, e.g. Solaris specific test code 841S and NT specific test code 841N;
  • - target OS specific test code e.g. Solaris specific test code 841S and NT specific test code 841N;
  • versions of the software to be tested for various target architectures e.g. a Solaris version 842S and an NT version 842N; and - generic test code 850, examples of which will be given hereinafter.
  • test supporting files 8 may further comprise optional default settings 82, corresponding e.g. to standard system directories as used with Solaris or NT.
  • each local agent is preferably identified by a unique couple or doublet of parameters, comprising a name which identifies the local agent (and, hence, its host target), and a port number which identifies its TCP socket. While this is an Internet Protocol (IP) type identification, other non IP identifications might be used as well.
  • IP Internet Protocol
  • This couple may be the only information known by the harness about the local agent, i.e. all the other information about the local agent will be determined at the time of executing the test, by querying each target for more detailed information through appropriate usage of the test script code, as illustrated in an example on Figure 6.
  • a local agent 231 will execute commands sent from harness 1. Such a command may result in an action in the target computer hosting the local agent; the action may be internal, or comprise sending file data required by harness 1, or sending file data required (on command) by another local agent, to be transmitted to harness 1; data representing the test result in the target computer 2 hosting the local agent may also be returned to harness 1.
  • harness 1 will selectively send commands derived from at least certain of the test operations, to a local agent.
  • the selection of commands may be based on available information about the target agent. At least part of the available information may be dynamically acquired.
  • the sequence of test operations has to be configured in accordance with the specific environment of the target 2-i hosting that given local agent, including its operating system (OS) and hardware architecture.
  • OS operating system
  • the sequences of test operations are loaded in RAM 13, e.g. from one or more files.
  • This forms a script 60 which is read by a harness test parser 64 also loaded in RAM 13, taking into account the current designated local agent (agent name and agent port number i.e. the agent doublet of parameters).
  • Fig. 6 also shows auxiliary data files 62, for use in implementing the script, and stored in hard disk 14.
  • the parser 64 accesses the instructions in the script 60 one by one.
  • the result of the parsing, at 66 is a sequence of one or more commands, which are now in an executable form. The number of commands in the sequence depends upon the design of the basic script file 60, and upon the interaction of the user with parser 64. The commands are then executed at 70.
  • the execution 70 starts with a first command as the current command, which is executed at 71. If appropriate (depending upon whether the command is at least partially executable on the target), the command is sent as a request to the local agent being involved. If the command is not successfully executed (72), an error processing is made at 73. Otherwise (normally), if step 74 indicates further commands, step 75 goes to the next command, and control is given to step 71. Step 79 is the end of the processing of the sequence of commands.
  • test sequence module comprising a representation of a sequence of test operations, is formed on the basis of the test supporting files 8, used as desired by the script 60.
  • the parser 64, its products 66 (a working area in RAM), and the execution module 70 together act as a test control module, based on the script 60.
  • the instructions in the test sequences refer to parameters (or variables), which are defined later. Some of these variables may be file names, thus enabling to select a file depending upon the target architecture.
  • This is made preferably by using a "master language” (a language adapted to control the test from the harness) to write these instructions ("master instructions").
  • the instructions in the master language are e.g. interpreted at the time of their execution, i.e. at step 70 latest.
  • GETFILE(AGENT_ID,SRC_PATH,DEST_PATH) is a request instruction for retrieving an arbitrary file from a local agent designated by AGENT_ID, in its path SRC_PATH, and sending it to path DEST_PATH, relative to the harness 1.
  • SENDFILE(AGENT_ID,SRC_PATH,DEST_PATH) is a request instruction for sending an arbitrary file to a local agent AGENT_ID, from a path SRC_PATH, relative to the harness 1, to a path DEST_PATH relative to the target having the local agent designated by AGENT_ID.
  • SETAGENT(AGENT_ID,AGENT_NAME,AGENT_PORT,WORK_DIR) is a master instruction which sets up a local agent for use during the lifetime of a current master instruction file.
  • WORK_DIR designates a directory to place any files sent to the designated local agent via a 2IPSEND command (defined hereafter) .
  • ZIPSEND(AGENT_ID,ZIP_ID,ZIP_FILENAME) is a master instruction, which may be defined with three arguments:
  • AGENT_ID designates the local agent to send the zip file to (the local agent has been created by a previous call to SETAGENT) ;
  • ZIP_ID (return argument only) designates the handle to the zip file who will be created. So, it must be undefined at this point and will be used thereafter when a call is made to a ZIPDEL command (delete a previously sent ZIPFILE); * ZIP_FILENAME designates the full path to the zip file to be sent, relative to the harness 1.
  • ZIPSEND will send the zip file ZIP_FILENAME from the harness to a local agent designated in AGENT_ID and request that agent to unzip the file.
  • the unzipped file is placed in the directory designated by WORK_DIR in the SETAGENT instruction for that AGENT_ID.
  • SETPROP(AGENT_ID,KEY[,VALUE ] ) is a master instruction which sets a property value on a specified AGENT_ID, which will be visible to any subsequent CMDSTART commands (defined hereafter) called on this AGENT_ID.
  • VALUE (optional third argument) designates the value of the property. If this argument is omitted, it will be retrieved from the specific chosen syntax environment, and if it is not defined here either, it will be assigned to the same value as KEY.
  • INCLUDE is a master instruction used to include another master instruction file OTHER_FILE into the current file.
  • CMDSTART (AGENT_ID,CMD_ID,CMD_STRING) is a request instruction which spawns an execute process on a local agent, using an environment built from any previous calls to SETPROP, and then executing the command specified in CMD_STRING (defined hereafter). It accepts at least three arguments:
  • CMD_ID which designates a handle to be used for further communication of the started process
  • CMD_STRING which designates the command to be executed on the designated local agent. It must match the OS and hardware architecture of the target hosting the local agent.
  • REPORTSTATUS STATUS_CODE
  • STATUS_CODE is a request instruction used to ask for a report of the final value of a test to the harness 1. It serves to decide whether a test passed or failed. For example, a value of 0 will indicate a test passed, any other value indicating an error (e.g. failed, not run, or unresolved). Accordingly, in case of multiple test processes on multiple agents, each partial result can be combined by a syntax file and then a test result can be decided upon. It accepts a single return-only argument:
  • the master instructions may include other self explanatory instructions, like DELFILE, or CHECKFILE, and so on.
  • the syntax files for the master language and the system local files are preferably stored in hard disk 14 of harness 1.
  • a result is decided on, and may be sent back to the harness 1 for processing and, if desired, for storage in hard disk 14 (Fig. 3).
  • the master instructions are used by the test parser for building up dynamically the desired environment (or test instruction execution configuration) adapted to data communication between the harness 1 and each designated target local agent.
  • This dynamic test creation is made and managed by test control module 6.
  • the file transfer facility (SENDFILE) allows the release version which is to be tested, to be sent to the local agent machine 2-i as well, before executing the test.
  • Example I A non limiting example of a set of master instructions is shown as Example I in Exhibit A. It will send a file "passtest.zip” to a local agent, unzip it, run the Java class contained in this zip file “PassTest”, and report the result to the test harness. Lines beginning with "#” are not executable. It is assumed that a local agent "AGENT1” has been defined from an agent definition file 81. The agent definition includes a variable AGENT1_0SNAME, containing the name of the OS in the corresponding target. The value of AGENT1_0SNAME may be "Windows NT" or "Solaris".
  • Section A.l defines default hard-coded settings: the path to the Java home directory in the target; the path and name of the Java Interpretor in the target; a keyword representing the target OS class; the path to a temporary directory in the target; and a name TEST_NAME given to the current test sequence.
  • the variable "FILE_SEPARATOR” is referred to the agent machine, seen from the harness.
  • Java supplies another variable noted " file. separator” , for the local machine (whether harness or target).
  • the default settings might be imported from one of the files 82, for example by using the instruction INCLUDE (OTHER_FILE ) in lieu of section A.l.
  • Section A.2. sets up an agent to run the test on.
  • AgentID is returned after execution of the instruction.
  • Section A.3 fetches a zip file "passtest.zip” containing the test, in a subdirectory of the harness, and sends it to the local agent in the target.
  • "Passtest.zip” is one of the files labelled 62 in Fig. 6.
  • Section A.4 executes the test, using a timeout of 30 seconds. More precisely, it launches the Java virtual machine to execute the Java class "PassTest” unzipped from “passtest.zip” in the target temporary directory named "TMP DIR” .
  • Section A.5 gets the status returned by the execute command.
  • Section A.6 gets the standard output and standard error traces.
  • Section A.7 cleans the standard output and standard error traces.
  • Section A.8 cleans the zip file on the agent side.
  • Section A.9 clears any leftover agent files.
  • section A.10 reports the status to the harness user interface, e.g. a GUI.
  • the generic test code 850 of Fig. 5 is comprised of sets of instructions which are target independent, like the sets of instructions in Examples III and IV in Exhibit C. These examples are given only to illustrate what target independent code may be, and are not intended to constitue a part of an actual test code.
  • test parser is responsible for parsing the script 60, and for adapting the same according to the designated agent name and agent port number (the agent doublet of parameters).
  • agent name and agent port number the agent doublet of parameters.
  • the general structure of a test specification may include the following steps:
  • each local agent is queried for its operating system (OS) and hardware architecture.
  • OS operating system
  • the harness builds up the test commands which will be sent to each of the local agents involved in the test specification, for the test to be run.
  • Each sent command has its own "CommandID”.
  • the results are stored in 89 (Fig. 5).
  • script of master instructions may generally comprise any of the following, in any desired order (compatible with parsing requirements):
  • the script is conveniently handled using a parser and editor based on a Graphic User Interface or GUI. It is also possible to run a test sequence without any GUI interface, if one makes use of a parser command-line interface, for example while specifying :
  • hard disk 14 stores a collection of test specifications 841, corresponding to different levels, including: - OS level, e.g. Solaris or NT,
  • Actions may be taken within the tree, or when reaching a leaf of the tree. Actions may comprise a CMDSTART using an adequate one of the command files 841.
  • test script (and of its master language) is to elucidate, based on the initial information known about each target agent (host and port number), enough information to send to the agent all information and/or data required to properly exercise the software being tested. This information is sequentially built up by dynamically querying the agent at the time of executing the test, and/or building on previously queried information and/or supplied default values (default properties) for each of the tested architecture/OS combinations.
  • test parser When parsing such a script, the test parser considers the local agent being set therein, and progressively builds up a test configuration adapted to that local agent. If several local agents are set, they are processed selectively the same way, with each agent finally receiving test commands adapted to its own architecture.
  • the logical harness 131 forms, in RAM 14, a set of agent specific commands, which are ready for being directly sent as requests to the local agent of a target 2-i, via sockets 17-i and 25- i.
  • test specifications 841 may be managed as a database, where each test specification is associated to its corresponding OS, supporting language, and hardware requirements. It may also include an identification of the corresponding specific software release version to be tested.
  • test operations themselves may be written in an agent-independent manner, with a syntax matching the harness test parser.
  • the "SETAGENT" portion of the script, and the corresponding analysis of "levels” may be considered as establishing a correspondence between active local agents and records in the above mentioned database. This correspondence may be materialized by a correspondence table between local agents (whose identifiers are defined) and corresponding test specifications (sequences of test operations) to be run with a release version in targets 2-i.
  • the harness 1 may also comprise a configuration file for each local agent registered in the correspondence table (or, at least, a configuration file for each local agent involved in the currently processed test sequences).
  • the test sequences in the harness include master instructions, the execution mode of which is stored in mass memory 4.
  • the master instructions may have one or more arguments (or parameters).
  • most of the master instructions are request instructions, i.e. will result into a request being sent by the harness to one of the local agents; again, in most cases, one argument (or more) in the request instruction is a command to be executed in the target, or includes such a command.
  • the harness .1 may allow the user to effect permutations of the local agents, and since the local agents can be queried, it is possible to detect, just prior to running, what the destination set-up (Java virtual machine, O.S., hardware architecture) needs to be, and to send the corresponding commands (and requests) comprising the test sequence to the local agent(s).
  • the destination set-up Java virtual machine, O.S., hardware architecture
  • the harness 1 may allow users to define their own shell script parser for use with the other testing tools.
  • parser in the given implementation of the technology is implemented as a Java class interface to allow abstraction of the actual parser details from the GUI, and to facilitate the implementation of other types of parser by simply implementing the provided interface "ParserInterface" , shown in Exhibit D. Men skilled in the art will be able to implement their own master language syntax using this standard Java abstraction mechanism.
  • harness may run on Windows NT or Solaris or any other hardware/software configuration (or several of them) depends on how portably the test sequences are written, as far as the master computer architecture is concerned ("portably” refers here e.g. to the master instructions references to the auxiliary data files 62, and other platform specific properties required to test the software, such as absolute file paths, drive letters, interrupts, etc).
  • the approach of this invention greatly facilitates the distribution of tests, by centralising them in a single master computer (harness) and dynamically selcting and distributing these tests, when needed, to simple target local agents, which act as "mini-servers" waiting for commands to be run on the "target” primary computer provided with the software to be tested.
  • test database associated with a number of different target computer architectures, is stored in the harness computer. Accordingly, a test operator will simply have to designate, in the database, one (or more) local agent(s) intended to run a selected test; after that, a specific test environment is dynamically created between the harness computer(s) and the designated local agent (s) in their respective hosting target computers.
  • This database may be modified or completed with new test sequences every time a new computer architecture appears .
  • test system may be built as follows:
  • Each primary computer 2-i having respective specific architecture (in terms of software and hardware).
  • Each primary computer 2-i is provided with a software (or application) to be tested and at least one local agent.
  • This software and the local agent(s) are adapted to their host primary computer architecture, and each local agent is capable of communicating data and running the software, on command.
  • a master computer or harness 1 which may store a correspondence between local agents and sequences of test operations to be run with a software to be tested in a primary computer 2-i.
  • the or each master computer 1 may also communicate with the primary computer local agent( s ) .
  • step 101 designate at least one primary computer local agent, e.g. in a table (step 101). This may be implemented with a GUI.
  • the designation consists preferably of a couplet of parameters (or variables) such as a name identifying the local agent primary computer and a port number identifying the TCP socket 5 attached to the local agent.
  • the master computer builds up dynamically a specific test environment (or configuration) adapted to data communication between the master computer(s) 1 and each designated primary computer local agent. This may be done with a parser.
  • step 107 data representative of the selected sequence of test operations are communicated from the master computer 1 to the selected primary computer local agent(s), in the specific test environment, for running the desired test operations with the software to be tested, in the primary computer (s) 2-i.
  • the harness gathers the results, i.e. reports sent back from the primary computer.
  • multiple local agents may reside in the same target, or may be spread across several targets, as long as all the doublets designating the local agents are unique. This may be of use for example when the release version to be tested is an application requiring results or information provided by several targets.
  • the invention is not limited to local agents and/or harnesses written for implementation in a Java virtual machine.
  • This invention also covers the proposed software code itself, especially when made available on any appropriate computer- readable medium.
  • computer-readable medium includes a storage medium such as magnetic or optic, as well as a transmission medium such as a digital or analog signal.
  • the software code basically includes the code for use in the harness, and the code for use in the targets. It may also include the accompanying files, and further include at least some of the group of software components to be installed.
  • the software code of a test program in the master test computer comprises :
  • test sequence module comprising a representation of a sequence of test operations
  • test control module adapted for sending commands derived from at least certain of the test operations, from said master computer to a selected local agent.
  • the software code of a local agent comprises code capable of having commands to be run in an hosting computer, and capable of communication for receiving such commands.
  • JAVAHOME_NT "c: ⁇ jdkl .2.2”
  • JAVAHOME_SOLARIS "/usr/javal .2"
  • JAVA_INTERPRETOR JAVAHOME_SOLARIS + FILE_SEPARATOR+ “bin” + FILE_SEPARATOR+ “Java”
  • KEYWORDS "Solaris”
  • TMP_DIR "/tmp” END
  • CMDSTRING JAVAJNTERPRETOR+ " -classpath " +TMP_DIR+ " PassTest”; CMDSTART(AgentID, CommandID, CMDSTRING, "30");
  • A.4 is preceded by A.3, to send the file corresponding
  • ODD_NUMBER_SUM + I END PRINT "Sum of odd numbers between 1 and 10 is " + ODD_NUMBER_SUM
  • setTestPath public void setTestPath(java.lang. String testFile) This method sets the path to file file containing the syntax which will be parsed.
  • This method sets the PrintStream to use for reporting errors and other types of output from the script.
  • This method sets any default properties which will be required for parsing this file.
  • This method returns all the properties obtained by parsing this test file.
  • the parser does not actually make contact with the agents but merely simulates the agent responses to allow standalone parsing.
  • ProtocolConstants ProtocolConstants.
  • FAILED ProtocolConstants FAILED ProtocolConstants.NOTRUN ProtocolConstants. UNRESOLVED
  • interrupt public void interruptO This method is responsible for killing any processes already started on the agents, and immediately halt parsing any files. getProperty public java. lang. String getProperty (Java. lang. String key)
  • This method retrieves the specified property from the results of parsing this file.
  • This method should return a test name which will be used to display the test in the test tree.
  • This method should return all keywords associated with this test. These will be used in using the keywords to select/deselect tests in the harness.
  • This method should list all available output files produced by this test when run on the agent, but relative to the harness.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention concerne des ordinateurs principaux (2-i) comprenant chacun une version d'un logiciel à tester, un agent local (231) pouvant être pourvu de commandes à exécuter dans l'ordinateur principal de l'agent local, ainsi qu'une interface (25A-25C), en vue d'une communication avec un ordinateur maître (1). Une représentation d'opérations de test est stockée dans l'ordinateur maître (1). Les commandes dérivées des opérations de test sont envoyées dynamiquement et sélectivement à partir de l'ordinateur maître (1) vers le ou les agents locaux (231), selon un nom et un numéro de port. Des dispositifs virtuels Java (230) peuvent être utilisés dans les ordinateurs principaux.
PCT/IB2000/000338 2000-03-23 2000-03-23 Procede et systeme destines a tester un logiciel dans des ordinateurs WO2001071502A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/IB2000/000338 WO2001071502A1 (fr) 2000-03-23 2000-03-23 Procede et systeme destines a tester un logiciel dans des ordinateurs
AU2000231862A AU2000231862A1 (en) 2000-03-23 2000-03-23 Method of and system for testing software in computers

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2000/000338 WO2001071502A1 (fr) 2000-03-23 2000-03-23 Procede et systeme destines a tester un logiciel dans des ordinateurs

Publications (1)

Publication Number Publication Date
WO2001071502A1 true WO2001071502A1 (fr) 2001-09-27

Family

ID=11003896

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2000/000338 WO2001071502A1 (fr) 2000-03-23 2000-03-23 Procede et systeme destines a tester un logiciel dans des ordinateurs

Country Status (2)

Country Link
AU (1) AU2000231862A1 (fr)
WO (1) WO2001071502A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005096153A2 (fr) * 2004-03-12 2005-10-13 United Parcel Service Of America, Inc. Systeme de test automatise servant a tester une application executee dans un environnement windows et procedes associes
EP1728159A1 (fr) * 2004-02-25 2006-12-06 Samsung Electronics Co., Ltd. Methode d'essai de plate-forme ouverte de services d'initiative de passerelle de services, et instrument d'essai faisant appel a cette methode
GB2456813A (en) * 2008-01-24 2009-07-29 Advanced Risc Mach Ltd Diagnostic control circuits for data processors which trigger a diagnostic operation in response to a memory address, a state and a context identifier
CN111488285A (zh) * 2020-04-15 2020-08-04 北京字节跳动网络技术有限公司 接口测试方法、装置、电子设备及计算机可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5022028A (en) * 1988-03-30 1991-06-04 Elverex Limited Software verification apparatus
US5669000A (en) * 1991-11-20 1997-09-16 Apple Computer, Inc. Interpreter for performing remote testing of computer systems
US5999179A (en) * 1997-11-17 1999-12-07 Fujitsu Limited Platform independent computer network management client
EP0964334A2 (fr) * 1998-06-03 1999-12-15 International Business Machines Corporation Système, méthode et produit de programme d'ordinateur pour découvrir des ressources dans un environnement d'ordinateur distribué

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5022028A (en) * 1988-03-30 1991-06-04 Elverex Limited Software verification apparatus
US5669000A (en) * 1991-11-20 1997-09-16 Apple Computer, Inc. Interpreter for performing remote testing of computer systems
US5999179A (en) * 1997-11-17 1999-12-07 Fujitsu Limited Platform independent computer network management client
EP0964334A2 (fr) * 1998-06-03 1999-12-15 International Business Machines Corporation Système, méthode et produit de programme d'ordinateur pour découvrir des ressources dans un environnement d'ordinateur distribué

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1728159A1 (fr) * 2004-02-25 2006-12-06 Samsung Electronics Co., Ltd. Methode d'essai de plate-forme ouverte de services d'initiative de passerelle de services, et instrument d'essai faisant appel a cette methode
EP1728159A4 (fr) * 2004-02-25 2010-12-08 Samsung Electronics Co Ltd Methode d'essai de plate-forme ouverte de services d'initiative de passerelle de services, et instrument d'essai faisant appel a cette methode
WO2005096153A2 (fr) * 2004-03-12 2005-10-13 United Parcel Service Of America, Inc. Systeme de test automatise servant a tester une application executee dans un environnement windows et procedes associes
WO2005096153A3 (fr) * 2004-03-12 2006-08-17 United Parcel Service Inc Systeme de test automatise servant a tester une application executee dans un environnement windows et procedes associes
US7398469B2 (en) 2004-03-12 2008-07-08 United Parcel Of America, Inc. Automated test system for testing an application running in a windows-based environment and related methods
GB2456813A (en) * 2008-01-24 2009-07-29 Advanced Risc Mach Ltd Diagnostic control circuits for data processors which trigger a diagnostic operation in response to a memory address, a state and a context identifier
GB2456813B (en) * 2008-01-24 2012-03-07 Advanced Risc Mach Ltd Diagnostic context construction and comparison
US8250411B2 (en) 2008-01-24 2012-08-21 Arm Limited Diagnostic context construction and comparison
CN111488285A (zh) * 2020-04-15 2020-08-04 北京字节跳动网络技术有限公司 接口测试方法、装置、电子设备及计算机可读存储介质
CN111488285B (zh) * 2020-04-15 2023-05-12 抖音视界有限公司 接口测试方法、装置、电子设备及计算机可读存储介质

Also Published As

Publication number Publication date
AU2000231862A1 (en) 2001-10-03

Similar Documents

Publication Publication Date Title
US5950011A (en) System using designer editor and knowledge base for configuring preconfigured software in an open system in a distributed environment
US6810364B2 (en) Automated testing of computer system components
US6367073B2 (en) Centralized, automated installation of software products
JP4603106B2 (ja) オブジェクトの遠隔的ブラウズ方法及びシステム
US7171659B2 (en) System and method for configurable software provisioning
US5692180A (en) Object-oriented cell directory database for a distributed computing environment
US7020699B2 (en) Test result analyzer in a distributed processing framework system and methods for implementing the same
US5920868A (en) Cataloging apparatus for facilitating the re-use of distributed objects in a distributed object system
KR100285223B1 (ko) 프로그램에입각하여분산오브젝트프로그램을생성하는방법
US6061721A (en) Bean-based management system
US7130881B2 (en) Remote execution model for distributed application launch and control
US20030217308A1 (en) Distributed test harness model
US20050240931A1 (en) System and method for dynamic cooperative distributed execution of computer tasks without a centralized controller
JPH0827726B2 (ja) 共通エージェント・コンピュータ管理システムと方法
US8214809B2 (en) Grid-enabled ANT compatible with both stand-alone and grid-based computing systems
JPH11224196A (ja) リモート・オブジェクト・アクセス
US7266817B1 (en) Method and system for creating packages for multiple platforms
EP1444597A1 (fr) Essai de services web comme composants
JPH0334018A (ja) コンピュータプログラムのカプセル化方法及びその装置
US20030120776A1 (en) System controller for use in a distributed processing framework system and methods for implementing the same
US20030055862A1 (en) Methods, systems, and articles of manufacture for managing systems using operation objects
Lakner et al. IBM system Blue Gene solution: Blue Gene/Q system administration
JP3013983B2 (ja) グラフィックインタフェースコマンド生成および実行ツール
US20060122958A1 (en) Matching client interfaces with service interfaces
US7765284B2 (en) Dynamically modified, multiple-platform computer programs, and methods and apparatus utilizing same

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP