WO2009150788A1 - 組み込み機器におけるａｐｉ評価システム - Google Patents

組み込み機器におけるａｐｉ評価システム Download PDF

Info

Publication number
WO2009150788A1
WO2009150788A1 PCT/JP2009/002239 JP2009002239W WO2009150788A1 WO 2009150788 A1 WO2009150788 A1 WO 2009150788A1 JP 2009002239 W JP2009002239 W JP 2009002239W WO 2009150788 A1 WO2009150788 A1 WO 2009150788A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
log
unit
execution
command
Prior art date
Application number
PCT/JP2009/002239
Other languages
English (en)
French (fr)
Inventor
永原功策
溝渕友樹
橋本麻希
後藤修
Original Assignee
パナソニック株式会社
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 パナソニック株式会社 filed Critical パナソニック株式会社
Priority to JP2010516734A priority Critical patent/JP5337155B2/ja
Publication of WO2009150788A1 publication Critical patent/WO2009150788A1/ja
Priority to US12/948,526 priority patent/US8443381B2/en

Links

Images

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

Definitions

  • the present invention relates to a technique for evaluating an apparatus, and more particularly to a technique for evaluating an apparatus incorporating a microcomputer.
  • This prior art verification system includes the following configuration in a host computer 2 and a user system 1 (hereinafter also referred to as a target system or target device). That is, the verification device on the host computer 2 includes a command control unit 121 and a communication control unit 124.
  • the command control unit 121 includes an evaluation result comparison unit 123 and a command execution unit 122.
  • On the user system 1, a communication control unit 102 (consisting of a data reception unit 103 and a data transmission unit 104), a command determination unit 105, a user memory 108, a synchronous command processing unit 106, and an asynchronous command processing unit 107.
  • the command control unit 121 of the verification device on the host computer 2 outputs a command for operating the function of the real-time OS on the user system 1 to control the user program and perform verification.
  • API refers to Application Program Interface, and instructions / functions that can be used when developing software that supports platforms such as OS and middleware, and program procedures for using these instructions / functions Indicates an interface consisting of a set of rules that define
  • the API verification system of the present invention is A target device capable of executing an API (Application Program Interface), and an API verification device connected to the target device so as to be capable of mutual communication;
  • the API verification device includes: A test procedure description part describing the test procedure of the API;
  • a virtual API unit that provides an API interface in the target device to the test procedure description unit, extracts the test procedure from the test procedure description unit, and issues a command for calling the API in the extracted test procedure;
  • a script execution unit that performs script interpretation of the command;
  • a command transmission unit that transmits the command interpreted by the script execution unit to the target device;
  • a log receiving unit that receives an execution result log of the API from the target device that executes the API based on the command;
  • the virtual API unit acquires a return value obtained by executing the API from the execution result log received by the log receiving unit,
  • the virtual API unit has the same type of interface as the API executed on the target device,
  • the virtual API part is An API executor for outputting a trigger for
  • the user program on the target device can be controlled in API units, and the test result can be determined from the log output on the target device.
  • the API verification system of the present invention is An event receiver that receives an asynchronous event that occurs at an arbitrary timing after execution of the API;
  • the log description rule management unit defines a log output method related to the asynchronous event,
  • the event receiving unit notifies the log output unit of reception of the asynchronous event,
  • the log output unit when verifying the asynchronous event, generates an execution result log including a log description rule related to the asynchronous event read from the log description rule management unit,
  • the virtual API unit is An asynchronous event standby setting device for detecting a timing at which the asynchronous event occurs in the target device;
  • the event information manager further manages the information of the asynchronous event;
  • the log filter extracts a log related to the asynchronous event from the execution result log based on the information of the asynchronous event managed by the event information manager. Is preferred.
  • the API verification system of the present invention is The test procedure description part A first test procedure description part in which the first test procedure is described; A second test procedure description part in which the second test procedure is described; With The virtual API unit is The first test description read from the first test procedure description unit and the second test description read from the second test procedure description unit are assigned identifiers for individually identifying these test procedures.
  • the API executor is A first API executor that implements the API execution procedure described in the first test procedure; A second API executor for executing the API execution procedure described in the second test procedure; Further comprising The API execution completion standby setting device notifies the API execution completion to the first API executor and the second API executor,
  • the command execution unit determines whether the first or second test procedure is being executed based on the identifier from the command, and then outputs the determination result to the log output unit,
  • the log output unit outputs the execution result log including a log indicating which of the first test procedure and the second test procedure is performed based on the determination result; Is preferred.
  • test procedure can be executed on a plurality of targets by the same configuration.
  • API verification apparatus of the present invention software installed on a user system can be controlled in API units from a test script. Thereby, after acquiring the state of the system at the time of the test execution by API call, it is possible to control related software according to the acquired state. Therefore, the same test conditions can always be created. As a result, lower layer software such as a device driver can be tested at the API interface.
  • FIG. 1 is a configuration diagram showing the entire verification system according to Embodiment 1 of the present invention.
  • FIG. 2 shows a data structure registered in the parameter memory in the first embodiment.
  • FIG. 3 shows event information in the first embodiment.
  • FIG. 4 is a diagram showing a command structure in the first embodiment.
  • FIG. 5 is a diagram illustrating command / API correspondence in the first embodiment.
  • FIG. 6 shows a log description rule in the first embodiment.
  • FIG. 7 is a configuration diagram illustrating the entire verification system according to the first embodiment.
  • FIG. 8 is a configuration diagram illustrating the entire verification system according to the first embodiment.
  • FIG. 9 shows execution log description rules in the first embodiment.
  • FIG. 10 is a configuration diagram showing the entire verification system according to the second embodiment of the present invention.
  • FIG. 11 is a configuration diagram illustrating the entire verification system according to the third embodiment of the present invention.
  • FIG. 12 is a block diagram showing the entire verification system in the conventional example.
  • FIG. 1 is a block diagram of an API verification apparatus according to Embodiment 1 of the present invention.
  • the verification system according to the present embodiment includes an API verification apparatus 1000A and a target apparatus 2000A that operate on the host PC.
  • the API verification apparatus 1000A includes a test procedure description unit 1100, a virtual API unit 1200, a script execution unit 1300, a command transmission unit 1400, and a log reception unit 1500.
  • the virtual API unit 1200 includes an API execution unit 1201, a parameter storage unit 1202, an API execution completion standby setting unit 1203, an event information management unit 1204, a log filter 1205, and a test result determination unit 1600.
  • the target device 2000A includes a command reception unit 2100, a command execution unit 2200, a command / API correspondence management unit 2300, a user program 2400, a log output unit 2500, a log description rule management unit 2600, and a log transmission unit 2700.
  • the verification operation includes a command transmission operation of the API verification device 1000A, a log transmission operation of the target device 2000A, and a log reception operation of the API verification device 1000A.
  • the test procedure description part 1100 describes a test execution procedure.
  • the test execution procedure describes an assignment procedure of argument values to be passed to the API and an API calling order.
  • a test execution procedure divided into API execution units is referred to as an API execution procedure.
  • the test procedure description unit 1100 outputs the test procedure to the API executor 1201.
  • the API executor 1201 registers information on variables for setting arguments and return values in the parameter storage unit 1202, and completes API execution registration for waiting until API execution is completed. This is performed for the standby setting device 1203. Thereafter, the API executor 1201 outputs an API execution procedure to the script execution unit 1300.
  • FIG. 2 is a diagram showing details of parameters registered / stored in the parameter storage 1202.
  • the parameter storage 1202 stores the API name, the argument passed to the API, and the return value in a state of being associated with each other as the detailed parameter contents. Therefore, referring to the detailed contents of the parameter, the argument and the return value can be specified from the registered API name. Only the value of the parameter input to the API when the API is called is set in the argument and the return value. In addition, output parameters are set for the argument and the return value after the API call is completed. Note that the output parameter is set by the log filter 1205.
  • the API execution completion standby setting unit 1203 registers an API completion event in the event information management unit 1204. Specifically, the API execution completion standby setting unit 1203 registers “WAITING information” in the event information manager 1204 as an API completion event. Based on the “WAITING information”, the event information manager 1204 performs “WAITING” until the registered information (API and its parameter details) is notified to the log filter 1205 as an event. “WAITING” here refers to, for example, an infinite loop or polling processing for periodically checking events, but it is needless to say that the present invention is not limited thereto.
  • the event information manager 1204 holds event information formed by associating an API completion event with an API.
  • FIG. 3 shows an example of event information held by the event information manager 1204.
  • the event name is represented by a character string
  • the virtual API unit 1200 returns from the API call based on whether or not the event information held by the event information manager 1204 is detected. It is determined whether or not.
  • the parameter storage unit 1202 holds detailed parameter information such as arguments and return values registered by the API execution unit 1201.
  • the script execution unit 1300 interprets the API execution procedure sent from the API executor 1201 and converts it into a command structure shown in FIG. 4 (hereinafter simply referred to as a command).
  • the script execution unit 1300 outputs a command (API execution procedure) to the command transmission unit 1400.
  • the command transmission unit 1400 transmits the command received from the script execution unit 1300 to the target device 2000A according to the transmission order.
  • the command transmitted by the command transmission unit 1400 will be described.
  • the command is represented by a character string, and an API represented by a leading character string “APINAME” and its argument are sequentially arranged.
  • the commands are transmitted from the command transmission unit 1400 to the target device 2000A along the arrangement order.
  • the command reception unit 2100 receives a command transmitted from the API verification apparatus 1000A and passes it to the command execution unit 2200.
  • the command execution unit 2200 reads the API corresponding to the received command from the user program 2400 and executes it by referring to the association between the command and API stored in the command / API correspondence management unit 2300. This will be described in more detail below.
  • the command / API correspondence management unit 2300 stores an API name and an address where the API is located on the memory of the user program 2400 (hereinafter simply referred to as “memory”) in association with each other. Yes.
  • the command execution unit 2200 refers to the API name in the command (a character string consisting of “APINAME # X” (X: serial number) in the example) in the command / API correspondence management unit 2300, and the API is arranged.
  • the start address on the memory (hereinafter referred to as API start address) is specified. Further, the command / API correspondence management unit 2300 executes the API existing at the specified API head address.
  • the command execution unit 2200 acquires the API execution result (argument / return value) from the user program 2400 and passes it to the log output unit 2500.
  • the log output unit 2500 creates a log (hereinafter referred to as an API execution result log) indicating an API execution result received based on management information (hereinafter referred to as a log description rule) provided in the log description rule management unit 2600.
  • the generated API execution result log is output to the log transmission unit 2700.
  • FIG. 6 shows an example of a log description rule when an API on the user program 2400 is called.
  • a character string “EVT_APIRET:” is provided at the beginning, followed by “RETVAL”, and then “ARGVAL1” and “ARGVAL2”.
  • RETVAL RETVAL
  • ARGVAL1 ARGVAL2
  • ARGVAL2 ARGVAL2
  • EVT_APIRET indicates a log description rule when calling an API.
  • a return value returned when calling the API is added to the “RETVAL” portion as a log.
  • a parameter log output as an API argument is added to the parts of “ARGVAL1” and “ARGVAL2”.
  • the log output unit 2500 outputs a log for determining the test result (hereinafter referred to as a log for determining the test result) to the log transmission unit 2700 together with the API execution result log described in the log description rule.
  • the log for determining the test result indicates, for example, the argument / return value information passed to the API or the log indicating the internal processing path of the API, and at the top is a log for determining the test result.
  • a header indicating that it is present is added. An example of this header is “ ⁇ EXLOG>” shown in FIG.
  • the API execution result log and the log for determining the test result are collectively referred to as an execution result log.
  • the log transmission unit 2700 transmits the execution result log to the log reception unit 1500 of the API verification apparatus 1000A.
  • the log receiving unit 1500 outputs the execution result log received from the target device 2000A to the log filter 1205.
  • the log filter 1205 acquires “WAITING information” from the event information manager 1204.
  • “WAITING information” is information regarding an API (event) for which the waiting API execution completion waiting setting unit 1203 is performing WAITING.
  • the log filter 1205 analyzes the execution result log based on “WAITING information” to determine whether or not the execution result log includes the execution result of the API that is WAITING. If it is determined that it is included, the log filter 1205 determines that the execution of the WAITING API has been completed and notifies the API execution completion waiting setting unit 1203 of the completion.
  • the API execution completion waiting setting unit 1203 cancels WAITING of the API that has been executed. Furthermore, the log filter 1205 extracts the API execution result log of the API for which processing has been completed from the execution result log. As described above, this log is information on arguments and return values. The log filter 1205 sets the value (argument / return value) by collating the extracted API execution result log with the variable information registered in the parameter storage unit 1202. The log filter 1205 outputs the set API execution result log value (argument / return value) to the API execution completion standby setting unit 1203 via the log filter 1205.
  • the log filter 1205 extracts a log for determining the test result from the execution result log, and outputs a log for determining the extracted test result to the test result determination unit 1600.
  • the test result determination unit 1600 analyzes the log for determining the test result, and determines whether or not the API that has been executed has been correctly executed.
  • the API execution completion waiting setting unit 1203 outputs the value (argument / return value) of the API execution result log to the test procedure description unit 1100 via the API execution unit 1201 at the timing when WAITING is released.
  • the test procedure description unit 1100 calls the next API based on the value (argument / return value) of the acquired API execution result log.
  • the virtual API unit 1200 transmits an API call command in synchronization with the target device 2000A, analyzes the execution result log output in a fixed format, After setting the return value, the set argument / return value is returned to the test procedure description part 1100.
  • the test procedure description unit 1100 it is possible to control the execution of the target-side API using the same interface as the user program provided by the virtual API unit 1200.
  • the test result determination unit 1600 can automatically determine the test result based on the execution result log output on the target device 2000A.
  • a log storage unit 2900 and a log filter 2800 may be provided in the target device 2000F.
  • a log for determining a test result is temporarily stored in the log storage unit 2900 of the target device 2000F, and then a log for determining a test result at a timing when the test procedure is completed is stored in the target device 2000F.
  • the API verification apparatus 1000F From the log transmission unit 2700 to the API verification apparatus 1000F.
  • the API verification apparatus 1000F outputs a log for determining the received test result to the test result determination unit 1600 via the log reception unit 1500 and the log filter 1215. According to this, it is possible to prevent the execution of the API from being delayed due to the transmission of the log for determining the test result.
  • the target device 2000G is further provided with a log filter 2800 and a second log transmission unit 2710
  • the API verification device 1000G is further provided with a second log reception unit 1510. May be.
  • the log filter 2800 of the target device 2000G extracts the log for determining the test result from the API execution result log
  • the log filter 2800 stores the log for determining the extracted test result.
  • the second log receiving unit 1510 receives the log for determining the test result, and then outputs the test result directly from the second log receiving unit 1510 to the test result determining unit 1600.
  • the execution of the API is prevented from being delayed due to the transmission of the log for determining the
  • the asynchronous event indicates an interrupt event generated from hardware or software on the target device triggered by API execution.
  • the data transfer start processing itself can be confirmed after calling the API, but whether or not the data transfer processing itself has been performed is actually determined by hardware and Furthermore, it cannot be confirmed until a response is received from a lower program.
  • “response” indicates, for example, a data transfer completion notification. Such a response from the hardware and the lower-level program is called an asynchronous event.
  • FIG. 10 is a block diagram of Embodiment 2 of the present invention. Similarly to FIG. 1, FIG. 10 also includes an API verification device 1000B and a target device 2000B that operate on the host PC.
  • the API verification apparatus 1000B includes a test procedure description unit 1100, a virtual API unit 1210, a script execution unit 1300, a command transmission unit 1400, and a log reception unit 1500.
  • the virtual API unit 1210 includes an API execution unit 1201, a parameter storage unit 1202, an API execution completion standby setting unit 1203, an event information management unit 1214, a log filter 1215, and an asynchronous event standby setting unit 1216.
  • the target device 2000B includes a command reception unit 2100, a command execution unit 2200, a command / API correspondence management unit 2300, a user program 2400, a log output unit 2500, a log description rule management unit 2610, a log transmission unit 2700, and an event reception unit 3000. Prepare.
  • the API verification device 1000B includes an asynchronous event standby setting device 1216;
  • the event information manager 1214 has an asynchronous event information management function;
  • the log filter 1215 has an asynchronous event extraction function;
  • the target device 2000B is provided with an event receiver 3000; It is.
  • the verification operation includes a preparation operation of the API verification device 1000B, a log transmission operation of the target device 2000B, and a log reception operation of the API verification device 1000B.
  • the test procedure description unit 1100 When performing an asynchronous event WAITING process, the test procedure description unit 1100 outputs information indicating a procedure for performing an asynchronous event WAITING process to the asynchronous event wait setting unit 1216.
  • the asynchronous event standby setting unit 1216 registers event information for performing WAITING processing in the event information manager 1214.
  • the procedure for performing the WAITING processing of the asynchronous event is a series of processing procedures from when the standby start is set by the asynchronous event standby setting device 1216 until the standby is completed (returned). Indicates.
  • log transmission operation of target device 2000B After the preparatory operation of the API verification apparatus 1000B is completed, when an asynchronous event occurs in the system on the target apparatus 2000B triggered by execution of an API from the test procedure description section 1100, the event reception section 3000 displays the user program 2400. From this, a parameter notified when an asynchronous event occurs is received and output to the log output unit 2500.
  • the log output unit 2500 refers to the asynchronous event log description rule from the log description rule management unit 2610 and creates an asynchronous event execution result log.
  • the log output unit 2500 outputs the created asynchronous event execution result log to the log transmission unit 2700.
  • the log transmission unit 2700 transmits the received asynchronous event execution result log to the log reception unit 1500 of the API verification apparatus 1000B.
  • the log reception unit 1500 outputs the asynchronous event execution result log received from the log transmission unit 2700 to the log filter 1215.
  • the log filter 1215 analyzes the received execution result log of the asynchronous event. In this analysis, when an asynchronous event registered in the event information manager 1214 is detected, the log filter 1215 sets a parameter included in the asynchronous event log in the parameter storage unit 1202 and further indicates that the asynchronous event has been detected.
  • the asynchronous event standby setting unit 1216 is notified.
  • the asynchronous event standby setting unit 1216 calls a variable returned by the asynchronous event from the parameter storage unit 1202, sets the value returned at the asynchronous event to the called variable, and describes the test procedure description. Return to part 1100.
  • the log filter 1215 refers to the event information manager 1214 to determine the asynchronous event, so that the target device 2000B The occurrence of an asynchronous event (asynchronous event execution log) is detected, and the asynchronous event standby setting unit 1216 is notified of the occurrence of the asynchronous event.
  • the information that the log filter 1215 refers to from the event information manager 1214 is event information for performing a WAITING process that is set in advance in the preparation operation of the API verification apparatus 1000B.
  • the verification system includes an API verification device 1000D, a first target device 2000Aa, and a second target device 2000Ab that operate on the host PC.
  • the first target device 2000Aa includes a first command reception unit 2100a, a first command execution unit 2200a, a first command / API correspondence management unit 2300a, a first user program 2400a, a first log output unit 2500a, A first log description rule management unit 2600a and a first log transmission unit 2700a are provided.
  • the second target device 2000Ab includes a second command reception unit 2100b, a second command execution unit 2200b, a second command / API correspondence management unit 2300b, a second user program 2400b, a second log output unit 2500b, A second log description rule management unit 2600b and a second log transmission unit 2700b are provided.
  • the first target device 2000Aa and the second target device 2000Ab have the same configuration as the target device 2000A.
  • the API verification apparatus 1000D includes a test procedure description unit 1100, a virtual API unit 1220, a script execution unit 1300, a command transmission unit 1400, and a log reception unit 1500, as in the first embodiment (FIG. 1). It is.
  • This embodiment differs from the first embodiment (FIG. 1) in that a virtual API unit 1220, a virtual API controller 1217, a first API executor 1221a, a second API executor 1221b, and an API And an execution completion standby setting unit 1223.
  • the first API executor 1221a and the second API executor 1221b have exactly the same function.
  • the verification operation includes a command transmission operation of the API verification device 1000D, a log transmission operation of the first and second target devices 2000Aa and 2000Ab, and a log reception operation of the API verification device 1000D.
  • test procedure is described in each of the first test procedure description unit 1100a and the second test procedure description unit 1100b.
  • the test procedure a procedure for assigning a value to an argument to be passed to the API and an order of calling the API are described.
  • the first test procedure description unit 1100a and the second test procedure description unit 1100b output the test procedure to the virtual API controller 1217.
  • identification information hereinafter referred to as script identification information
  • the virtual API controller 1217 outputs an API execution procedure to the first API executor 1221a or the second API executor 1221b.
  • the virtual API controller 1217 selects which of the first API execution unit 1221a and the second API execution unit 1221b to output the API execution procedure. The selection method will be described below.
  • the virtual API controller 1217 determines whether an API execution procedure can be output to one arbitrarily selected API executor (for example, the first API executor 1221a). This determination is performed by confirming whether or not another test procedure has already been performed in the selected API executor. When determining that output is possible, the virtual API controller 1217 outputs the API execution procedure to the API execution unit (for example, the first API execution unit 1221a) that is determined to be capable of output. When it is determined that the output is impossible, the virtual API controller 1217 outputs the API execution procedure to the other API executor (for example, the second API executor 1221b) different from the one determined not to be output.
  • an API execution unit that outputs an API execution procedure is denoted by reference numeral 1221x.
  • the virtual API controller 1217 when outputting the API execution procedure, the virtual API controller 1217 adds identification information (hereinafter referred to as target device identification information) for identifying the target device that transmits the API execution procedure to the API execution procedure.
  • the target device identification information indicates, for example, an IP address or a MAC address, but is not limited thereto.
  • the API executor 1221x that has received the API execution procedure outputs the API execution procedure to the script execution unit 1300.
  • the API executor 1221x creates and holds information for specifying the script being executed based on the script description information.
  • the script execution unit 1300 converts the received API execution procedure into a command (structure of API name and argument), and outputs the command to the command transmission unit 1400.
  • the script execution unit 1300 further gives target device identification information and script description information to the command to be created.
  • the target device identification information is added to the API execution procedure by the virtual API controller 1217 as described above.
  • the command transmission unit 1400 transmits a command (API execution procedure) to the target device 2000Ax based on the target device identification information added to the API execution procedure.
  • the target device 2000Ax is the first target device 2000Aa, the second target device 2000Ab, or both target devices 2000Aa and 2000Ab.
  • the first command receiving unit 2100a When the first command receiving unit 2100a receives the command, the first command receiving unit 2100a outputs the command to the first command executing unit 2220a.
  • the first command execution unit 2220a refers to the first command / API correspondence management unit 2300a to convert the received command into a command itself and an API argument.
  • the first command execution unit 2220a executes the API on the first user program 2400a based on the command obtained by the conversion and the API argument.
  • the first command execution unit 2220a executes the API on the first user program 2400a, thereby specifying information for specifying the script being executed (hereinafter referred to as script identification information) and specifying the target being executed.
  • Information hereinafter referred to as target identification information
  • a return value obtained as a result of executing the API are output to the first log output unit 2500a.
  • the first log output unit 2500a outputs a return value, script identification information, and target identification information obtained as a result of API execution to the first log transmission unit 2700a.
  • the return value, the script identification information, and the target identification information are a log (execution result log) as a result of executing the API in accordance with an instruction from the first log description rule management unit 2600a.
  • the first log transmission unit 2700a transmits the received execution result log from the first log output unit 2500a to the log reception unit 1500 of the API verification apparatus 1000D.
  • the log receiving unit 1500 outputs the received execution result log to the log filter 1205 of the virtual API unit 1220.
  • the log filter 1205 examines the received execution result log with reference to the event information manager 1204 to determine whether or not a log indicating an API execution completion waiting event exists in the reception log.
  • the log filter 1205 determines that a log indicating an API execution completion waiting event exists in the reception log, the log filter 1205 sets a return value parameter corresponding to the API execution completion waiting event in the parameter storage unit 1202, and then API execution completion.
  • the standby setting unit 1223 is notified of the script identification information and the target identification information.
  • the API execution completion standby setting unit 1223 outputs the received script identification information and target identification information to the first API executor 1221a and the second API executor 1221b. If the first API executor 1221a and the second API executor 1221b interpret the script identification information and determine that the script is currently being executed, the return value from the parameter storage unit 1202 will be described. The parameter is acquired, and the return value parameter is returned to the virtual API controller 1217. The virtual API controller 1217 that has received the return value parameter specifies one of the first test procedure description unit 1100a and the second test procedure description unit 1100b based on the script identification information. Return the return value to the specified test procedure description part. However, if the same script is being executed on another target, the execution of the API on the other target is awaited.
  • a plurality of test procedures can be executed.
  • the API verification apparatus has an effect that the software installed on the user system can be controlled in API units from the test script. It is useful as an API verification system in combination with a system.

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

　ＡＰＩの実行手順を記載するテスト手順記述部と、ターゲット装置のＡＰＩのインターフェースをテスト手順記述部に提供することでＡＰＩを呼び出すコマンドを発行して戻り値を取得する仮想ＡＰＩ部と、スクリプト解釈を行なうスクリプト実行部と、ターゲット装置にコマンドを送信するコマンド送信部と、ターゲット装置からＡＰＩ実行後の結果ログを受信するログ受信部とを備えて、ターゲット装置上に実装されたユーザプログラムをＡＰＩ単位で制御し検証する。

Description

組み込み機器におけるＡＰＩ評価システム
　本発明は、装置を評価する技術に関し、特にマイクロコンピュータが組み込まれた装置を評価する技術に関する。
　近年家電機器の商品サイクルの短期化から開発期間の短縮化が要求されるようになり、その結果、組み込みソフト開発の検証工数においても効率化が要求されている。検証工数の効率化のために、マイクロコンピュータのユーザプログラムを自動で評価する検証システムが研究されている。（例えば、特許文献１参照）。
　図１２を参照して従来技術について説明する。この従来技術の検証システムは、ホストコンピュータ２と、ユーザシステム１（以降、ターゲットシステムまたはターゲット装置とも呼ぶ）とに、以下の構成を備える。すなわち、ホストコンピュータ２上の検証装置はコマンド制御部１２１と通信制御部１２４とを備える。コマンド制御部１２１は評価結果比較部１２３とコマンド実行部１２２とを備える。ユーザシステム１上には、通信制御部１０２（データ受信部１０３とデータ送信部１０４とからなる）と、コマンド判定部１０５と、ユーザメモリ１０８と、同期コマンド処理部１０６と、非同期コマンド処理部１０７とを備える。
　上記従来の検証システムでは、ホストコンピュータ２上の検証装置のコマンド制御部１２１からユーザシステム１上のリアルタイムＯＳの機能を操作するコマンドを出力することによって、ユーザプログラムを制御して検証を行なう。
特開２００２－１８９６１７号公報
　しかしながら、従来の検証システムでは、リアルタイムＯＳ上の機能を使用してユーザプログラムを制御するため、ユーザプログラムをタスク単位でしか制御することができない。そのため、種々のテスト項目において、ＡＰＩ界面でテストすることができない。なお、ＡＰＩとは、Application Program Interfaceのことであって、ＯＳやミドルウェア等のプラットフォームに対応するソフトウェアを開発する際に使用可能な命令/関数やそれら命令/関数を利用するためのプログラム上の手続きを定めた規約の集合等からなるインターフェースを示す。
　本発明のＡＰＩ検証システムは、
　ＡＰＩ(Application Program Interface)を実行可能なターゲット装置と、前記ターゲット装置に相互通信可能に接続されたＡＰＩ検証装置とを備え、
　前記ＡＰＩ検証装置は、
　前記ＡＰＩのテスト手順が記述されたテスト手順記述部と、
　前記ターゲット装置におけるＡＰＩインターフェースを前記テスト手順記述部に提供したうえで当該テスト手順記述部から前記テスト手順を取り出し、取り出した当該テスト手順で前記ＡＰＩを呼び出すコマンドを発行する仮想ＡＰＩ部と、
　前記コマンドのスクリプト解釈を行なうスクリプト実行部と、
　前記スクリプト実行部でスクリプト解釈された前記コマンドを前記ターゲット装置に送信するコマンド送信部と、
　前記コマンドに基づいて前記ＡＰＩを実行する前記ターゲット装置から前記ＡＰＩの実行結果ログを受信するログ受信部と、
　を備え、
　前記仮想ＡＰＩ部は、前記ログ受信部が受信する前記実行結果ログから前記ＡＰＩを実行することで得られる戻り値を取得し、
　前記仮想ＡＰＩ部は、前記ターゲット装置上で実行される前記ＡＰＩと同種のインターフェースを有しており、
　かつ前記仮想ＡＰＩ部は、
　前記ターゲット装置で前記ＡＰＩを実行させるトリガを出力するＡＰＩ実行器と、
　前記ＡＰＩに渡すパラメータを記憶するパラメータ記憶器と、
　前記ターゲット装置が前記ＡＰＩの実行を完了するタイミングを検出するＡＰＩ実行完了待機設定器と、
　前記ターゲット装置で実行される前記ＡＰＩにおける実行完了イベントを管理するイベント情報管理器と、
　前記実行結果ログから、前記戻り値を示す情報と、ＡＰＩ実行完了を示す情報と、イベント情報に関するログとを抽出するログフィルタと、
　を備え、
　前記ターゲット装置は、
　前記ＡＰＩ検証装置が送信する前記コマンドを受信するコマンド受信部と、
　前記コマンドと前記ＡＰＩとを互いに対応させて記憶するコマンド・ＡＰＩ対応管理部と、
　前記コマンド受信部で受信する前記コマンドに対応付けられた前記ＡＰＩを前記コマンド・ＡＰＩ対応管理部において特定したうえで、特定した前記ＡＰＩを実行するコマンド実行部と、
　前記ＡＰＩが提供する機能が実装されたユーザプログラムと、
　前記コマンド実行部で前記ＡＰＩが実行されることで得られる戻り値と返却引数の値とを含む前記実行結果ログを作成するログ出力部と、
　前記実行結果ログの出力方法を定義するログ記述ルール管理部と、
　前記ログ記述ルール管理部で定義された前記出力方法に基づいて前記実行結果ログを前記ＡＰＩ検証装置に送信するログ送信部と、
　を備える。
　かかる構成により、ターゲット装置上のユーザプログラムをＡＰＩ単位で制御し、ターゲット装置上で出力したログからテスト結果を判定することを可能となる。
　本発明のＡＰＩ検証システムは、
　前記ＡＰＩの実行後に任意のタイミングで発生する、非同期イベントを受信するイベント受信部をさらに備え、
　前記ログ記述ルール管理部は、前記非同期イベントに関するログの出力方法を定義し、
　前記イベント受信部は、前記非同期イベントの受信を前記ログ出力部に通知し、
　前記ログ出力部は、前記非同期イベントを検証する際には、前記ログ記述ルール管理部から読み出した前記非同期イベントに関するログ記述ルールを含む実行結果ログを生成し、
　前記仮想ＡＰＩ部は、
　前記ターゲット装置で前記非同期イベントが発生するタイミングを検出する非同期イベント待機設定器をさらに備え、
　前記イベント情報管理器は、前記非同期イベントの情報をさらに管理し、
　前記ログフィルタは、前記イベント情報管理器で管理している前記非同期イベントの情報に基づいて、前記実行結果ログから前記非同期イベントに関するログを抽出する、
　のが好ましい。かかる構成により、前記発明に加え、ＡＰＩ検証システム上で非同期イベントに対応する制御も可能となる。
　本発明のＡＰＩ検証システムは、
　前記テスト手順記述部は、
　第一のテスト手順が記述された第一のテスト手順記述部と、
　第二のテスト手順が記述された第二のテスト手順記述部と、
　を備え、
　前記仮想ＡＰＩ部は、
　前記第一のテスト手順記述部から読出した前記第一のテスト記述と前記第二のテスト手順記述部から読出した前記第二のテスト記述とに、これらのテスト手順を個別に識別する識別子を付与したうえで、識別子付与後の両テスト手順を、前記ＡＰＩ実行器における両テスト手順の実施状態に応じて前記ＡＰＩ実行器に順次出力する仮想ＡＰＩ制御器を、
　さらに備え、
　前記ＡＰＩ実行器は、
　前記第一のテスト手順に記載されたＡＰＩ実行手順を実施する第一のＡＰＩ実行器と、
　前記第二のテスト手順に記載されたＡＰＩ実行手順を実施する第二のＡＰＩ実行器と、
　をさらに備え、
　前記ＡＰＩ実行完了待機設定器は、前記第一のＡＰＩ実行器と、前記第二のＡＰＩ実行器とにＡＰＩ実行完了通知を行ない、
　前記コマンド実行部は、前記コマンドから前記識別子に基づいて前記第一、第二のテスト手順のどちらが実行されているのかを判別したうえでその判別結果を前記ログ出力部に出力し、
　前記ログ出力部は、前記判別結果に基づいて前記第一のテスト手順と前記第二のテスト手順とのうちのどちらを実施しているかを示すログを含んだ前記実行結果ログを出力する、
　のが好ましい。
　かかる構成により、複数のテスト手順を同時に実行することが可能となる。なお、同構成により、テスト手順を複数のターゲット上で実行することも可能となる。
　本発明のＡＰＩ検証装置によれば、テストスクリプトからユーザシステム上に実装されたソフトウェアをＡＰＩ単位で制御することが可能となる。これにより、テスト実行時のシステムの状態をＡＰＩ呼び出しにより取得したうえで、取得した状態に応じて関連するソフトウェアを制御することができる。そのため、常に同じテスト条件を作り出すことができる。その結果、デバイスドライバなどの下位層のソフトウェアを、ＡＰＩの界面でテストすることが可能となる。
図１は本発明の実施の形態１における検証システム全体を示す構成図である。 図２は実施の形態１におけるパラメータ記憶器に登録するデータ構造である。 図３は、実施の形態１におけるイベント情報である。 図４は、実施の形態１におけるコマンド構造を示す図である。 図５は、実施の形態１におけるコマンド・ＡＰＩ対応を表す図である。 図６は、実施の形態１におけるログ記述ルールである。 図７は、実施の形態１における検証システム全体を示す構成図である。 図８は、実施の形態１における検証システム全体を示す構成図である。 図９は、実施の形態１における実行ログ記述ルールである。 図１０は、本発明の実施の形態２における検証システム全体を示す構成図である。 図１１は、本発明の実施の形態３における検証システム全体を示す構成図である。 図１２は、従来例における検証システム全体を示す構成図である。
　以下、本発明のＡＰＩ検証装置等の実施形態について図面を参照して説明する。なお、実施の形態において同じ符号を付した構成要素は同様の動を行うので、再度の説明を省略する場合がある。
　（実施の形態１）
　図１は、本発明の実施の態１におけるＡＰＩ検証装置のブロック図である。本実施形態にかかる検証システムは、ホストＰＣ上で動作するＡＰＩ検証装置１０００Ａとターゲット装置２０００Ａとを備える。ＡＰＩ検証装置１０００Ａは、テスト手順記述部１１００、仮想ＡＰＩ部１２００、スクリプト実行部１３００、コマンド送信部１４００、およびログ受信部１５００を備える。仮想ＡＰＩ部１２００は、ＡＰＩ実行器１２０１、パラメータ記憶器１２０２、ＡＰＩ実行完了待機設定器１２０３、イベント情報管理器１２０４、ログフィルタ１２０５、およびテスト結果判定部１６００を備える。ターゲット装置２０００Ａは、コマンド受信部２１００、コマンド実行部２２００、コマンド・ＡＰＩ対応管理部２３００、ユーザプログラム２４００、ログ出力部２５００、ログ記述ルール管理部２６００、およびログ送信部２７００を備える。
　以下、実際に検証を行なう際の流れを説明するとともに各部の動作を説明する。検証動作は、ＡＰＩ検証装置１０００Ａのコマンド送信動作と、ターゲット装置２０００Ａのログ送信動作と、ＡＰＩ検証装置１０００Ａのログ受信動作とを含む。
　（ＡＰＩ検証装置１０００Ａのコマンド送信動作）
　テスト手順記述部１１００にはテスト実行手順が記述されている。テスト実行手順は、ＡＰＩに渡す引数の値の代入手順やＡＰＩの呼び出し順序が記載されたものである。以降、テスト実行手順をＡＰＩの実行単位に区切ったものをＡＰＩの実行手順と呼ぶ。検証が開始されるとテスト手順記述部１１００は、テスト手順をＡＰＩ実行器１２０１に出力する。テスト手順を受け取ったＡＰＩ実行器１２０１は、引数や戻り値を設定する変数の情報をパラメータ記憶器１２０２に登録するとともに、ＡＰＩの実行が完了するまで待機する旨のＡＰＩの実行登録をＡＰＩ実行完了待機設定器１２０３に行なう。その後、ＡＰＩ実行器１２０１は、ＡＰＩ実行手順をスクリプト実行部１３００に出力する。
　ここでパラメータ記憶器１２０２に登録・記憶されるパラメータ詳細内容について説明する。パラメータ詳細内容とは、引数や戻り値を設定する変数の情報のことである。図２はパラメータ記憶器１２０２に登録・記憶されるパラメータ詳細内容を示す図である。パラメータ記憶器１２０２には、パラメータ詳細内容として、ＡＰＩ名と、そのＡＰＩに渡される引数および戻り値とが互いに関連付けられた状態で格納される。したがって、パラメータの詳細内容を参照すれば、登録されているＡＰＩ名から引数と戻り値とを特定できる。引数と戻り値とには、ＡＰＩを呼び出す際においてＡＰＩに入力されるパラメータの値のみが設定される。そのうえで、引数と戻り値とには、ＡＰＩの呼び出しが完了した後において出力パラメータが設定される。なお、出力パラメータの設定はログフィルタ１２０５より行なわれる。
　ＡＰＩ実行完了待機設定器１２０３は、ＡＰＩ完了イベントをイベント情報管理器１２０４に登録する。具体的にはＡＰＩ実行完了待機設定器１２０３は、ＡＰＩ完了イベントとして“WAITING情報”をイベント情報管理器１２０４に登録する。イベント情報管理器１２０４は、“WAITING情報”に基づいて、登録された情報（ＡＰＩやそのパラメータ詳細内容）がログフィルタ１２０５にイベントとして通知されるまで、”WAITING″(待ち)を行なう。ここで言う”WAITING”とは、例えば無限ループや定期的にイベントを確認するポーリング処理などを示すが、それらに限定されるものではないのはいうまでもない。
　イベント情報管理器１２０４は、ＡＰＩの完了イベントとＡＰＩとを関連付けてなるイベント情報を保持する。図３はイベント情報管理器１２０４が保持するイベント情報の例を示す。図３の例では、文字列でイベント名を表しており、仮想ＡＰＩ部１２００は、イベント情報管理器１２０４が保持するイベント情報を検出するか否かに基づいて、処理がＡＰＩの呼び出しから復帰してきたか否かを判断する。パラメータ記憶器１２０２は、ＡＰＩ実行器１２０１によって登録処理される引数や戻り値といったパラメータ詳細情報を保持する。
　スクリプト実行部１３００はＡＰＩ実行器１２０１から送られてきたＡＰＩ実行手順を解釈することでそれを図４に示すコマンドの構造（以下、単にコマンドと称す）に変換する。スクリプト実行部１３００は、コマンド（ＡＰＩ実行手順）をコマンド送信部１４００に出力する。コマンド送信部１４００は、スクリプト実行部１３００から受け取ったコマンドを送信順序に従ってターゲット装置２０００Ａに送信する。
　ここで、コマンド送信部１４００によって送信されるコマンドの説明を行なう。図４に示すようにコマンドは文字列によって表されており、先頭の「ＡＰＩＮＡＭＥ」という文字列によって表わされるＡＰＩとその引数とが順次配置されている。コマンドは、その配置順に沿ってコマンド送信部１４００からターゲット装置２０００Ａに送信される。
　（ターゲット装置２０００Ａのコマンド受信/ログ送信動作）
　コマンド受信部２１００は、ＡＰＩ検証装置１０００Ａから送信されるコマンドを受信し、コマンド実行部２２００に渡す。コマンド実行部２２００は、コマンド・ＡＰＩ対応管理部２３００に格納されているコマンドとＡＰＩとの対応付けを参照することで、受信したコマンドに対応するＡＰＩをユーザプログラム２４００から読み出して実行する。以下、さらに詳細に説明する。
　コマンド・ＡＰＩ対応管理部２３００は、図５に示すように、ＡＰＩ名と、そのＡＰＩがユーザプログラム２４００のメモリ（以下、単にメモリという）上に配置されているアドレスとを対応付けて保持している。コマンド実行部２２００は、コマンド内のＡＰＩ名（図例では「ＡＰＩＮＡＭＥ#Ｘ」（Ｘ：通し番号）からなる文字列）を、コマンド・ＡＰＩ対応管理部２３００に参照することで、そのＡＰＩが配置されているメモリ上の先頭アドレス（以下、ＡＰＩ先頭アドレスという）を特定する。さらにコマンド・ＡＰＩ対応管理部２３００は、特定したＡＰＩ先頭アドレスに存在するＡＰＩを実行する。更にコマンド実行部２２００は、ＡＰＩ実行した結果（引数・戻り値）をユーザプログラム２４００から取得して、ログ出力部２５００に渡す。ログ出力部２５００は、ログ記述ルール管理部２６００に設けられた管理情報（以下、ログ記述ルールという）を元に受け取ったＡＰＩ実行結果を示すログ（以下、ＡＰＩ実行結果ログと呼ぶ）を作成し、作成したＡＰＩ実行結果ログをログ送信部２７００に出力する。
　ログ記述ルール管理部２６００が管理するログ記述ルールの構造について図６を参照して説明する。図６は、ユーザプログラム２４００上のＡＰＩを呼び出した場合のログ記述ルールの例を示す。この例では、先頭に「ＥＶＴ＿ＡＰＩＲＥＴ：」という文字列が、その後に「ＲＥＴＶＡＬ」の部分が、さらにその後に「ＡＲＧＶＡＬ１」、「ＡＲＧＶＡＬ２」の部分が設けられている。なお、ここでいう前後とは、データ送信順序に沿った位置関係をいう。
　「ＥＶＴ＿ＡＰＩＲＥＴ：」は、ＡＰＩを呼び出す際のログ記述ルールであることを示す。「ＲＥＴＶＡＬ」の部分には、ＡＰＩを呼び出す際に返却された戻り値がログとして付加される。「ＡＲＧＶＡＬ１」、「ＡＲＧＶＡＬ２」の部分には、ＡＰＩの引数として出力されるパラメータのログが付加される。
　ログ出力部２５００による出力動作に戻って説明を行う。ログ出力部２５００は、テスト結果を判定するためのログ（以下、テスト結果を判定するためのログという）を、ログ記述ルールで記述されたＡＰＩ実行結果ログとともにログ送信部２７００に出力する。テスト結果を判定するためのログは、例えばＡＰＩに渡した引数・戻り値の情報やＡＰＩの内部の処理経路を表すログのことを示し、その先頭には、テスト結果を判定するためのログであることを表すヘッダが付加される。このヘッダの一例が図９に示す「＜ＥＸＬＯＧ＞」である。以降、ＡＰＩ実行結果ログとテスト結果を判定するためのログとを合わせて実行結果ログという。ログ送信部２７００は、実行結果ログをＡＰＩ検証装置１０００Ａのログ受信部１５００に送信する。
　（ＡＰＩ検証装置１０００Ａのログ受信動作）
　ログ受信部１５００は、ターゲット装置２０００Ａから受信した実行結果ログをログフィルタ１２０５に出力する。ログフィルタ１２０５は、実行結果ログを受け取ると、イベント情報管理器１２０４から“WAITING情報”を取得する。“WAITING情報”とは、前述した通り、待ちＡＰＩ実行完了待機設定器１２０３がWAITING（待ち）を行なっているＡＰＩ（イベント）に関する情報である。ログフィルタ１２０５は、実行結果ログを“WAITING情報”に基づいて解析することで、実行結果ログの中に、WAITING（待ち）を行なっているＡＰＩの実行結果が含まれるか否かを判断する。含まれると判断する場合、ログフィルタ１２０５は、WAITING（待ち）を行なっているＡＰＩの実行が完了したと判断してそのことをＡＰＩ実行完了待機設定器１２０３に通知する。ＡＰＩ実行完了待機設定器１２０３は、受け取った通知（ＡＰＩ完了通知）に基づいて、実行が完了したＡＰＩのWAITING（待ち）を解除する。さらにログフィルタ１２０５は、実行結果ログから、処理が完了したＡＰＩのＡＰＩ実行結果ログを抽出する。このログは前述したように引数や戻り値の情報である。ログフィルタ１２０５は、抽出したＡＰＩ実行結果ログをパラメータ記憶器１２０２に登録されている変数の情報に照合させることでその値（引数・戻り値）を設定する。ログフィルタ１２０５は、設定したＡＰＩ実行結果ログの値（引数・戻り値）をログフィルタ１２０５を介してＡＰＩ実行完了待機設定器１２０３に出力する。
　さらにログフィルタ１２０５は、実行結果ログから、テスト結果を判定するためのログを抽出し、抽出したテスト結果を判定するためのログをテスト結果判定部１６００に出力する。テスト結果判定部１６００はテスト結果を判定するためのログを解析することで、実行が完了したＡＰＩが正しく実行されたか否かを判定する。
　ＡＰＩ実行完了待機設定器１２０３は、WAITING（待ち）を解除したタイミングでＡＰＩ実行結果ログの値（引数・戻り値）をＡＰＩ実行器１２０１を介してテスト手順記述部１１００に出力する。テスト手順記述部１１００は、取得したＡＰＩ実行結果ログの値（引数・戻り値）に基づいて次のＡＰＩの呼び出しを実施する。
　以上説明したように、本実施の形態によれば仮想ＡＰＩ部１２００がターゲット装置２０００Ａと同期してＡＰＩの呼び出しコマンドの送信や、決まった形式で出力された実行結果ログを解析してその引数・戻り値を設定したうえで、設定した引数・戻り値をテスト手順記述部１１００に返却する。これにより、テスト手順記述部１１００上では、仮想ＡＰＩ部１２００が提供するユーザプログラムと同じインターフェースを用いて、ターゲット側ＡＰＩの実行を制御することが可能となる。これにより本実施の形態では、ターゲット装置２０００Ａ上で出力された実行結果ログに基づいてテスト結果判定部１６００がテスト結果を自動的に判定することが可能となる。
　なお、本実施の形態では、図７に示すように、ターゲット装置２０００Ｆにログ蓄積部２９００とログフィルタ２８００とを設けてもよい。この構成では、テスト結果を判定するためのログを一旦ターゲット装置２０００Ｆのログ蓄積部２９００で蓄積したうえで、テスト手順が一通り実施されたタイミングでテスト結果を判定するためのログをターゲット装置２０００Ｆのログ送信部２７００からＡＰＩ検証装置１０００Ｆに送信する。ＡＰＩ検証装置１０００Ｆでは、受信したテスト結果を判定するためのログをログ受信部１５００とログフィルタ１２１５とを介してテスト結果判定部１６００に出力する。これによれば、テスト結果を判定するためのログの伝送に起因してＡＰＩの実行が遅延することが防止される。
　さらに、本実施の形態では、図８に示すように、ターゲット装置２０００Ｇにログフィルタ２８００と第二のログ送信部２７１０とをさらに設け、ＡＰＩ検証装置１０００Ｇに第二のログ受信部１５１０をさらに設けてもよい。この構成では、ターゲット装置２０００Ｇのログフィルタ２８００が、ＡＰＩ実行結果ログからテスト結果を判定するためのログを抽出したうえで、抽出したテスト結果を判定するためのログを、ログフィルタ２８００が第二のログ送信部２７１０を介してＡＰＩ検証装置１０００Ｇに送信する。ＡＰＩ検証装置１０００Ｇでは、第二のログ受信部１５１０でテスト結果を判定するためのログを受信したうえで、第二のログ受信部１５１０から直接にテスト結果判定部１６００に出力することでテスト結果を判定するためのログの伝送に起因してＡＰＩの実行が遅延することが防止される。
　（実施の形態２）
　実施の形態２では、非同期イベントを検証するシステムについて説明する。まず、本実施の形態２における、非同期イベントの定義について明らかにする。非同期イベントとは、ＡＰＩ実行をトリガとしてターゲット装置上のハードウェア、ソフトウェアから発生する割り込みイベントのことを示す。例えば、メモリ間のデータ転送開始処理が実装されたＡＰＩの場合、ＡＰＩの呼び出し後、データの転送開始処理自体は確認できるが、データの転送処理自体が実施されたどうかは、実際にハードウェア及び更に下位にあたるプログラムからの応答を受けるまで確認することができない。ここで言う“応答”とは、例えばデータ転送完了通知等を示す。このようなハードウェア及び下位プログラムからの応答のことを非同期イベントと呼ぶ。
　図１０は本発明の実施の形態２の構成図である。図１０についても図１と同様に、ホストＰＣ上で動作するＡＰＩ検証装置１０００Ｂとターゲット装置２０００Ｂとを備える。ＡＰＩ検証装置１０００Ｂは、テスト手順記述部１１００、仮想ＡＰＩ部１２１０、スクリプト実行部１３００、コマンド送信部１４００、およびログ受信部１５００を備える。仮想ＡＰＩ部１２１０は、ＡＰＩ実行器１２０１、パラメータ記憶器１２０２、ＡＰＩ実行完了待機設定器１２０３、イベント情報管理器１２１４、ログフィルタ１２１５、および非同期イベント待機設定器１２１６を備える。
　ターゲット装置２０００Ｂは、コマンド受信部２１００、コマンド実行部２２００、コマンド・ＡＰＩ対応管理部２３００、ユーザプログラム２４００、ログ出力部２５００、ログ記述ルール管理部２６１０、ログ送信部２７００、およびイベント受信部３０００を備える。
　本実施の形態が実施の形態１と異なる点は、
・ＡＰＩ検証装置１０００Ｂが非同期イベント待機設定器１２１６を備えること、
・イベント情報管理器１２１４が非同期イベント情報管理機能を備えること、
・ログフィルタ１２１５が非同期イベント抽出機能を備えること、
・ターゲット装置２０００Ｂにイベント受信部３０００を備えること、
　である。
　以下、本実施の形態において、非同期イベントのWAITING(待ち）処理を実施する際における各部の動作を説明する。検証動作は、ＡＰＩ検証装置１０００Ｂの準備動作と、ターゲット装置２０００Ｂのログ送信動作と、ＡＰＩ検証装置１０００Ｂのログ受信動作とを含む。
　（ＡＰＩ検証装置１０００Ｂの準備動作）
　非同期イベントのWAITING(待ち)処理を行なう場合、テスト手順記述部１１００は、非同期イベント待機設定器１２１６に、非同期イベントのWAITING(待ち)処理を行なう際の手順を示す情報を出力する。非同期イベント待機設定器１２１６は、イベント情報管理器１２１４に、WAITING(待ち)処理を行なうイベント情報を登録する。なお、非同期イベントのWAITING(待ち)処理を行なう手順とは、非同期イベント待機設定器１２１６によって待機開始が設定されたうえで待機が終了する（返却される）までの間の一連の処理手順のことを示す。
　（ターゲット装置２０００Ｂのログ送信動作）
　ＡＰＩ検証装置１０００Ｂの準備動作が完了した後、テスト手順記述部１１００からのＡＰＩの実行などをトリガとして、ターゲット装置２０００Ｂの上のシステムで非同期イベントが発生すると、イベント受信部３０００は、ユーザプログラム２４００から、非同期イベントが発生した際に通知されるパラメータを受信し、ログ出力部２５００に出力する。ログ出力部２５００はログ記述ルール管理部２６１０から非同期イベントのログ記述ルールを参照して非同期イベントの実行結果ログを作成する。ログ出力部２５００は、作成した非同期イベントの実行結果ログをログ送信部２７００に出力する。ログ送信部２７００は、受け取った非同期イベントの実行結果ログをＡＰＩ検証装置１０００Ｂのログ受信部１５００に送信する。
　（ＡＰＩ検証装置１０００Ｂのログ受信動作）
　ログ受信部１５００は、ログ送信部２７００から受け取った非同期イベントの実行結果ログをログフィルタ１２１５に出力する。ログフィルタ１２１５は、受け取った非同期イベントの実行結果ログを解析する。この解析において、イベント情報管理器１２１４に登録されている非同期イベントを検出すると、ログフィルタ１２１５は、非同期イベントログに含まれるパラメータをパラメータ記憶器１２０２に設定し、さらに、非同期イベントを検出したことを非同期イベント待機設定器１２１６に通知する。
　非同期イベント待機設定器１２１６は、非同期イベント検出通知を受け取ると、パラメータ記憶器１２０２から非同期イベントにより返却される変数を呼び出し、呼び出した変数に非同期イベント時に返却された値を設定して、テスト手順記述部１１００に返却する。
　以上のように、本実施の形態では、非同期イベントのWAITING（待ち）処理を行なう際に、ログフィルタ１２１５が、イベント情報管理器１２１４を参照して非同期イベントを判断することで、ターゲット装置２０００Ｂにおける非同期イベントの発生（非同期イベントの実行ログ）を検知し、非同期イベント待機設定器１２１６に非同期イベントの発生を通知する。なお、ログフィルタ１２１５が、イベント情報管理器１２１４から参照する情報は、ＡＰＩ検証装置１０００Ｂの準備動作にて予め設定しておいた、WAITING（待ち）処理を行うイベント情報である。
　これにより、ＡＰＩを実行し戻り値を取得した後、実際の内部処理が行われ、その動作が完了した時点で発生する非同期イベントの受信をもってＡＰＩの目的が達成される、いわゆる非同期イベントの検証を実施することが可能となる。
　（実施の形態３）
　本発明の実施形態３にかかる検証システムは、図１１に示すように、ホストＰＣ上で動作するＡＰＩ検証装置１０００Ｄと第一のターゲット装置２０００Ａａと第二のターゲット装置２０００Ａｂとを備える。第一のターゲット装置２０００Ａａは、第一のコマンド受信部２１００ａ、第一のコマンド実行部２２００ａ、第一のコマンド・ＡＰＩ対応管理部２３００ａ、第一のユーザプログラム２４００ａ、第一のログ出力部２５００ａ、第一のログ記述ルール管理部２６００ａ、および第一のログ送信部２７００ａを備える。第二のターゲット装置２０００Ａｂは、第二のコマンド受信部２１００ｂ、第二のコマンド実行部２２００ｂ、第二のコマンド・ＡＰＩ対応管理部２３００ｂ、第二のユーザプログラム２４００ｂ、第二のログ出力部２５００ｂ、第二のログ記述ルール管理部２６００ｂ、および第二のログ送信部２７００ｂを備える。
　このように第一のターゲット装置２０００Ａａと第二のターゲット装置２０００Ａｂとは、ターゲット装置２０００Ａと同様の構成を備える。さらには、ＡＰＩ検証装置１０００Ｄが、テスト手順記述部１１００、仮想ＡＰＩ部１２２０、スクリプト実行部１３００、コマンド送信部１４００、およびログ受信部１５００を備える点は、実施の形態１（図１）と同様である。
　本実施の形態が実施の形態１（図１）と異なるのは、仮想ＡＰＩ部１２２０に、仮想ＡＰＩ制御器１２１７と、第一のＡＰＩ実行器１２２１ａと、第二のＡＰＩ実行器１２２１ｂと、ＡＰＩ実行完了待機設定部１２２３とを備えることである。但し、第一のＡＰＩ実行器１２２１ａと第二のＡＰＩ実行器１２２１ｂとは全く同じ機能を有する。
　以上のように構成された本実施の形態の検証システムについて、以下に各部の動作を説明する。検証動作は、ＡＰＩ検証装置１０００Ｄのコマンド送信動作と、第一、第二のターゲット装置２０００Ａａ、２０００Ａｂのログ送信動作と、ＡＰＩ検証装置１０００Ｄのログ受信動作とを含む。
　（ＡＰＩ検証装置１０００Ｄのコマンド送信動作）
　第一のテスト手順記述部１１００ａと第二のテスト手順記述部１１００ｂとにはそれぞれテスト手順が記述されている。テスト手順には、ＡＰＩに渡す引数に値を代入する手順やＡＰＩを呼び出す順序が記載されている。検証が開始されると第一のテスト手順記述部１１００ａと第二のテスト手順記述部１１００ｂとは、テスト手順を、仮想ＡＰＩ制御器１２１７に出力する。第一のテスト手順記述部１１００ａと第二のテスト手順記述部１１００ｂとに記述されているテスト手順には、各々のテストを識別するための識別情報（以下、スクリプト識別情報という）が記述されている。
　仮想ＡＰＩ制御器１２１７は、第一のＡＰＩ実行器１２２１ａあるいは第二のＡＰＩ実行器１２２１ｂにＡＰＩ実行手順を出力する。仮想ＡＰＩ制御器１２１７は、ＡＰＩ実行手順の出力に際して、第一のＡＰＩ実行器１２２１ａと第二のＡＰＩ実行器１２２１ｂとのうちのどちらにＡＰＩ実行手順を出力するかを選択する。以下、その選択方法について説明する。
　まず仮想ＡＰＩ制御器１２１７は、任意に選択した一つのＡＰＩ実行器（例えば第一のＡＰＩ実行器１２２１ａ）にＡＰＩ実行手順を出力可能であるかどうかを判断する。この判断は、選択したＡＰＩ実行器において既に他のテスト手順が実施されている状態であるか否かを確認することで実施される。出力可能であると判断する場合、仮想ＡＰＩ制御器１２１７は、出力可能と判断した方のＡＰＩ実行器（例えば第一のＡＰＩ実行器１２２１ａ）にＡＰＩ実行手順を出力する。出力不可能であると判断する場合、仮想ＡＰＩ制御器１２１７は、出力不可能と判断した方とは異なる他方のＡＰＩ実行器（例えば第二のＡＰＩ実行器１２２１ｂ）にＡＰＩ実行手順を出力する。以下、ＡＰＩ実行手順が出力されるＡＰＩ実行器に、便宜的に符号１２２１ｘを付す。
　なお、仮想ＡＰＩ制御器１２１７は、ＡＰＩ実行手順を出力する際には、ＡＰＩ実行手順を送信するターゲット装置を識別する識別情報（以下、ターゲット装置識別情報という）をＡＰＩ実行手順に付加する。ターゲット装置の識別情報とは、例えばＩＰアドレスやＭＡＣアドレスを示すが、それらに限定されるものではないのはいうまでもない。
　ＡＰＩ実行手順を受け取ったＡＰＩ実行器１２２１ｘは、スクリプト実行部１３００にＡＰＩ実行手順を出力する。この時、ＡＰＩ実行器１２２１ｘはスクリプト記述情報に基づいて、実行しているスクリプトを特定する情報を作成して保持しておく。スクリプト実行部１３００は、受け取ったＡＰＩ実行手順を解釈することでコマンド（ＡＰＩ名と引数との構造）に変換してコマンド送信部１４００に出力する。スクリプト実行部１３００は、作成するコマンドに、ターゲット装置識別情報やスクリプトの記述情報を更に付与する。ターゲット装置識別情報は、前述したように仮想ＡＰＩ制御器１２１７によってＡＰＩ実行手順に付加されている。
　コマンド送信部１４００は、ＡＰＩ実行手順に付加されたターゲット装置識別情報に基づいて、コマンド（ＡＰＩ実行手順）をターゲット装置２０００Ａｘに送信する。ここで、ターゲット装置２０００Ａｘは、第一のターゲット装置２０００Ａａ、または第二のターゲット装置２０００Ａｂ、または両ターゲット装置２０００Ａａ、２０００Ａｂとなる。
　（第一、第二のターゲット装置２０００Ａａ、２０００Ａｂのコマンド受信/ログ送信動作）
　第一のターゲット装置２０００Ａａと第二のターゲット装置２０００Ａｂとは全く同機能を有し、同じ動作をするため、第一のターゲット装置２０００Ａａを代表してその動作の説明を行なう。
　第一のコマンド受信部２１００ａは、コマンドを受信するとそのコマンドを第一のコマンド実行部２２２０ａに出力する。第一のコマンド実行部２２２０ａは、第一のコマンド・ＡＰＩ対応管理部２３００ａを参照することで、受信したコマンドをコマンドそのものとＡＰＩ引き数とに変換する。第一のコマンド実行部２２２０ａは、変換により得られるコマンドとＡＰＩ引き数とに基づいて第一のユーザプログラム２４００ａ上のＡＰＩを実行する。
　第一のコマンド実行部２２２０ａは、第一のユーザプログラム２４００ａ上のＡＰＩを実行することで、実行しているスクリプトを特定する情報（以下、スクリプト識別情報という）と、実行しているターゲットを特定する情報（以下、ターゲット識別情報という）と、ＡＰＩを実行した結果得られる戻り値とを取得し、それらを第一のログ出力部２５００ａに出力する。
　第一のログ出力部２５００ａは、ＡＰＩ実行の結果得られる戻り値とスクリプト識別情報とターゲット識別情報とを第一のログ送信部２７００ａに出力する。戻り値とスクリプト識別情報とターゲット識別情報とは、第一のログ記述ルール管理部２６００ａの指示に従ってＡＰＩを実行した結果のログ（実行結果ログ）である。第一のログ送信部２７００ａは、受け取った実行結果ログを、第一のログ出力部２５００ａからＡＰＩ検証装置１０００Ｄのログ受信部１５００に送信する。
　（ＡＰＩ検証装置１０００Ｄのログ受信動作）
　ログ受信部１５００は、受信した実行結果ログを仮想ＡＰＩ部１２２０のログフィルタ１２０５に出力する。ログフィルタ１２０５は、受信した実行結果ログを、イベント情報管理器１２０４を参照して調べることで、ＡＰＩ実行完了待機状態のイベントを示すログが受信ログ内にあるか否かを判断する。ＡＰＩ実行完了待機状態のイベントを示すログが受信ログ内にあると判断するとログフィルタ１２０５は、ＡＰＩ実行完了待機状態のイベントに対応する戻り値パラメータをパラメータ記憶器１２０２に設定した後、ＡＰＩ実行完了待機設定器１２２３にスクリプト識別情報とターゲット識別情報とを通知する。ＡＰＩ実行完了待機設定器１２２３は、通知を受けたスクリプト識別情報とターゲット識別情報とを第一のＡＰＩ実行器１２２１ａと第二のＡＰＩ実行器１２２１ｂとに出力する。第一のＡＰＩ実行器１２２１ａと第二のＡＰＩ実行器１２２１ｂとは、スクリプト識別情報を解釈して、そのスクリプトが現在実行しているスクリプトであると判断すれば、パラメータ記憶器１２０２から上記戻り値パラメータを取得して、その戻り値パラメータを仮想ＡＰＩ制御器１２１７に返却する。戻り値パラメータの返却を受けた仮想ＡＰＩ制御器１２１７は、スクリプト識別情報に基づいて第一のテスト手順記述部１１００ａと第二のテスト手順記述部１１００ｂとのうちの一つを特定したうえで、特定したテスト手順記述部に戻り値を返却する。但し、同じスクリプトを別のターゲット上でも実行している場合はもう一方のターゲット上でのＡＰＩの実行完了を待つ。
　以上説明したように、本実施の形態によれば複数のテスト手順を実行することが可能となる。なお、本実施の形態によれば一つ以上のテスト手順を実行する場合に、仮想ＡＰＩ制御器１２１７からコマンド送信先を指定することで複数のターゲット装置を同時にＡＰＩ単位で制御することが可能となる。
　以上のように、本発明にかかるＡＰＩ検証装置は、テストスクリプトからユーザシステム上に実装されたソフトウェアをＡＰＩ単位で制御することが可能となる、という効果を有し、ＡＰＩ検証装置やターゲット側のシステムと組み合わせた、ＡＰＩ検証システムとして有用である。
１０００Ａ　ＡＰＩ検証装置
２０００Ａ　ターゲット装置
２０００Ａａ　第一のターゲット装置
２０００Ａｂ　第二のターゲット装置
１１００　　テスト手順記述部
１１００ａ　第一のテスト手順記述部
１１００ｂ　第二のテスト手順記述部
１２００　　仮想ＡＰＩ部
１２０１　　ＡＰＩ実行器
１２０１ａ　第一のＡＰＩ実行器
１２０１ｂ　第二のＡＰＩ実行器
１２０２　　パラメータ記憶器
１２０３　　ＡＰＩ実行完了待機設定器
１２０４　　イベント情報管理器
１２０５　　ログフィルタ
１２１７　　仮想ＡＰＩ制御器
１２２１ａ　　第一のＡＰＩ実行器
１２２１ｂ　　第二のＡＰＩ実行器
１３００　　スクリプト実行部
１４００　　コマンド送信部
１５００　　ログ受信部
１５１０　　第二のログ受信部
１８００　　テスト結果判定部
２１００　　コマンド受信部
２１００ａ　第一のコマンド受信部
２１００ｂ　第二のコマンド受信部
２２００　　コマンド実行部
２２００ａ　第一のコマンド実行部
２２００ｂ　第二のコマンド実行部
２３００　　コマンド・ＡＰＩ対応管理部
２３００ａ　第一のコマンド・ＡＰＩ対応管理部
２３００ｂ　第二のコマンド・ＡＰＩ対応管理部
２４００　　ユーザプログラム
２４００ａ　第一のユーザプログラム
２４００ｂ　第二のユーザプログラム
２５００　　ログ出力部
２５００ａ　第一のログ出力部
２５００ｂ　第二のログ出力部
２６００　　ログ記述ルール管理部
２６００ａ　第一のログ記述ルール管理部
２６００ｂ　第二のログ記述ルール管理部
２６１０　　ログ記述ルール管理部
２７００　　ログ送信部
２７００ａ　第一のログ送信部
２７００ｂ　第二のログ送信部
２７１０　　第二のログ送信部
２８００　　ログフィルタ
２９００　　ログ蓄積部

Claims (9)

  1. 　ＡＰＩ(Application Program Interface)を実行可能なターゲット装置に相互通信可能に接続されたＡＰＩ検証装置であって、
    　前記ＡＰＩのテスト手順が記述されたテスト手順記述部と、
    　前記ターゲット装置におけるＡＰＩインターフェースを前記テスト手順記述部に提供したうえで当該テスト手順記述部から前記テスト手順を取り出し、取り出した当該テスト手順で前記ＡＰＩを呼び出すコマンドを発行する仮想ＡＰＩ部と、
    　前記コマンドのスクリプト解釈を行なうスクリプト実行部と、
    　前記スクリプト実行部でスクリプト解釈された前記コマンドを前記ターゲット装置に送信するコマンド送信部と、
    　前記コマンドに基づいて前記ＡＰＩを実行する前記ターゲット装置から前記ＡＰＩの実行結果ログを受信するログ受信部と、
    　を備え、
    　前記仮想ＡＰＩ部は、前記ログ受信部が受信する前記実行結果ログから前記ＡＰＩを実行することで得られる戻り値を取得する、
    　ＡＰＩ検証装置。
  2. 　前記仮想ＡＰＩ部は、前記ターゲット装置上で実行される前記ＡＰＩと同種のインターフェースを有しており、
    　かつ前記仮想ＡＰＩ部は、
    　前記ターゲット装置で前記ＡＰＩを実行させるトリガを出力するＡＰＩ実行器と、
    　前記ＡＰＩに渡すパラメータを記憶するパラメータ記憶器と、
    　前記ターゲット装置が前記ＡＰＩの実行を完了するタイミングを検出するＡＰＩ実行完了待機設定器と、
    　前記ターゲット装置で実行される前記ＡＰＩにおける実行完了イベントを管理するイベント情報管理器と、
    　前記実行結果ログから、前記戻り値を示す情報と、ＡＰＩ実行完了を示す情報と、イベント情報に関するログとを抽出するログフィルタと、
    　を備える、
    　請求項１のＡＰＩ検証装置。
  3. 　請求項２のＡＰＩ検証装置と、前記ターゲット装置とを備え、
    　前記ターゲット装置は、
    　前記ＡＰＩ検証装置が送信する前記コマンドを受信するコマンド受信部と、
    　前記コマンドと前記ＡＰＩとを互いに対応させて記憶するコマンド・ＡＰＩ対応管理部と、
    　前記コマンド受信部で受信する前記コマンドに対応付けられた前記ＡＰＩを前記コマンド・ＡＰＩ対応管理部において特定したうえで、特定した前記ＡＰＩを実行するコマンド実行部と、
    　前記ＡＰＩが提供する機能が実装されたユーザプログラムと、
    　前記コマンド実行部で前記ＡＰＩが実行されることで得られる戻り値と返却引数の値とを含む前記実行結果ログを作成するログ出力部と、
    　前記実行結果ログの出力方法を定義するログ記述ルール管理部と、
    　前記ログ記述ルール管理部で定義された前記出力方法に基づいて前記実行結果ログを前記ＡＰＩ検証装置に送信するログ送信部と、
    　を備える、
    　検証システム。
  4. 　前記ターゲット装置は、
    　前記ＡＰＩの実行後に任意のタイミングで発生する、非同期イベントを受信するイベント受信部をさらに備え、
    　前記ログ記述ルール管理部は、前記非同期イベントに関するログの出力方法を定義し、
    　前記イベント受信部は、前記非同期イベントの受信を前記ログ出力部に通知し、
    　前記ログ出力部は、前記非同期イベントを検証する際には、前記ログ記述ルール管理部から読み出した前記非同期イベントに関するログ記述ルールを含む実行結果ログを生成し、
    　前記仮想ＡＰＩ部は、
    　前記ターゲット装置で前記非同期イベントが発生するタイミングを検出する非同期イベント待機設定器をさらに備え、
    　前記イベント情報管理器は、前記非同期イベントの情報をさらに管理し、
    　前記ログフィルタは、前記イベント情報管理器で管理している前記非同期イベントの情報に基づいて、前記実行結果ログから前記非同期イベントに関するログを抽出する、
    　請求項３の検証システム。
  5. 　前記テスト手順記述部は、
    　第一のテスト手順が記述された第一のテスト手順記述部と、
    　第二のテスト手順が記述された第二のテスト手順記述部と、
    　を備え、
    　前記仮想ＡＰＩ部は、
    　前記第一のテスト手順記述部から読出した前記第一のテスト手順と前記第二のテスト手順記述部から読出した前記第二のテスト手順とに、これらのテスト手順を個別に識別する識別子を付与したうえで、識別子付与後の両テスト手順を、前記ＡＰＩ実行器における両テスト手順の実施状態に応じて前記ＡＰＩ実行器に順次出力する仮想ＡＰＩ制御器を、
    　さらに備え、
    　前記ＡＰＩ実行器は、
    　前記第一のテスト手順に記載されたＡＰＩ実行手順を実施する第一のＡＰＩ実行器と、
    　前記第二のテスト手順に記載されたＡＰＩ実行手順を実施する第二のＡＰＩ実行器と、
    　をさらに備え、
    　前記ＡＰＩ実行完了待機設定器は、前記第一のＡＰＩ実行器と、前記第二のＡＰＩ実行器とにＡＰＩ実行完了通知を行ない、
    　前記コマンド実行部は、前記コマンドから前記識別子に基づいて前記第一、第二のテスト手順のどちらが実行されているのかを判別したうえでその判別結果を前記ログ出力部に出力し、
    　前記ログ出力部は、前記判別結果に基づいて前記第一のテスト手順と前記第二のテスト手順とのうちのどちらを実施しているかを示すログを含んだ前記実行結果ログを出力する、
    　請求項３のＡＰＩ検証システム。
  6. 　前記ターゲット装置は、
    　第一のターゲット装置と、
    　第二のターゲット装置と、
    　を備え、
    　前記テスト手順記述部に記述された前記テスト手順には、当該テスト手順を実行するターゲット装置を指定する情報がさらに記述されており、
    　前記ＡＰＩ実行器は、
    　第一のＡＰＩ実行器と、
    　第二のＡＰＩ実行器と、
    　を備え、
    　前記仮想ＡＰＩ部は、
    　前記テスト手順で指定されたターゲット装置の識別情報と前記ＡＰＩ実行器とを関連付けたコマンドを前記ＡＰＩ実行器に出力する仮想ＡＰＩ制御器を、
    　さらに備え、
    　前記ＡＰＩ実行完了待機設定器は、前記ログフィルタが抽出する前記実行結果ログを、前記第一のＡＰＩ実行器と前記第二のＡＰＩ実行器とに通知する、
    　請求項３の検証システム。
  7. 　前記ログフィルタは、前記実行結果ログから前記ＡＰＩのテスト結果を判定するためのログをさらに抽出し、
    　前記ＡＰＩ検証装置は、
    　前記テスト結果を判定するためのログに基づいて前記ＡＰＩが正しく実行されたか否かを判定するテスト結果判定部を、
    　さらに備える、
    　請求項３の検証システム。
  8. 　前記ターゲット装置は、
    　前記テスト結果を判定するためのログの記述ルールが記述されたログ記述ルール管理部と、
    　前記テスト結果を判定するためのログと前記実行結果ログとを振り分けるログフィルタと、
    　前記ログフィルタによって振り分けられた前記テスト結果を判定するためのログを蓄積するログ蓄積部と、
    　をさらに備え、
    　前記ログ送信部は、ＡＰＩの実行完了後、前記テスト結果の判定を行なうためのログを前記ログ蓄積部から読み出して、前記ＡＰＩ検証装置に送信する、
    　請求項７の検証システム。
  9. 　前記ターゲット装置は、
    　前記テスト結果を判定するためのログと前記実行結果ログとを振り分けるログフィルタと、
    　前記ログフィルタで振り分けられた前記テスト結果を判定するためのログを前記ＡＰＩ検証装置に送信する第二のログ送信部と、
    　を備え、
    　前記ＡＰＩ検証装置は、
    　前記第二のログ送信部から送信された前記テスト結果の判定するためのログを受信して前記テスト結果判定部に直接出力する第二のログ受信部を、
    　さらに備える、
    　請求項７の検証システム。
PCT/JP2009/002239 2008-06-10 2009-05-21 組み込み機器におけるａｐｉ評価システム WO2009150788A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2010516734A JP5337155B2 (ja) 2008-06-10 2009-05-21 組み込み機器におけるａｐｉ評価システム
US12/948,526 US8443381B2 (en) 2008-06-10 2010-11-17 API evaluation system in embedded device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008-151457 2008-06-10
JP2008151457 2008-06-10

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/948,526 Continuation US8443381B2 (en) 2008-06-10 2010-11-17 API evaluation system in embedded device

Publications (1)

Publication Number Publication Date
WO2009150788A1 true WO2009150788A1 (ja) 2009-12-17

Family

ID=41416502

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/002239 WO2009150788A1 (ja) 2008-06-10 2009-05-21 組み込み機器におけるａｐｉ評価システム

Country Status (3)

Country Link
US (1) US8443381B2 (ja)
JP (1) JP5337155B2 (ja)
WO (1) WO2009150788A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2485204A (en) * 2010-11-05 2012-05-09 Jk Technosoft Uk Ltd Automating testing of an application using a hook mechanism
JP2016177659A (ja) * 2015-03-20 2016-10-06 ヤフー株式会社 検証プログラム、検証装置及び検証方法

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10776233B2 (en) * 2011-10-28 2020-09-15 Teradyne, Inc. Programmable test instrument
US9759772B2 (en) 2011-10-28 2017-09-12 Teradyne, Inc. Programmable test instrument
US9470759B2 (en) 2011-10-28 2016-10-18 Teradyne, Inc. Test instrument having a configurable interface
US9747193B1 (en) * 2013-03-13 2017-08-29 Ca, Inc. System and method for automatic root cause detection
US9940223B2 (en) * 2013-04-05 2018-04-10 FEV North America Inc. Human-machine interface test system
CN103559114B (zh) * 2013-11-12 2015-08-19 福建联迪商用设备有限公司 嵌入式模块驱动功能测试系统及方法
US10296362B2 (en) * 2014-02-26 2019-05-21 Red Hat Israel, Ltd. Execution of a script based on properties of a virtual device associated with a virtual machine
US9417992B2 (en) * 2014-09-24 2016-08-16 Oracle International Corporation Web portal API test report generation
US10810099B2 (en) * 2017-09-11 2020-10-20 Internatinal Business Machines Corporation Cognitive in-memory API logging
US10956244B1 (en) * 2020-08-26 2021-03-23 Coupang Corp. Systems and methods for automated application programming interface evaluation and migration
US11704187B1 (en) 2022-01-18 2023-07-18 Bank Of America Corporation Automated application programming interface (API) route testing system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09198279A (ja) * 1996-01-19 1997-07-31 Pentel Kk シミュレ−ションソフト内蔵携帯端末装置
JP2000215082A (ja) * 1999-01-26 2000-08-04 Hitachi Ltd 分散オブジェクト環境のプレイバックテスト方式
JP2007026306A (ja) * 2005-07-20 2007-02-01 Nec Corp プログラムテスト装置、方法、及び、プログラム
JP2007219893A (ja) * 2006-02-17 2007-08-30 Seiko Epson Corp ファームウェア評価システムおよびファームウェア評価方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6587969B1 (en) * 1998-06-22 2003-07-01 Mercury Interactive Corporation Software system and methods for testing the functionality of a transactional server
WO2001022228A1 (en) * 1999-09-17 2001-03-29 Nortel Networks Limited System and method for producing a verification system for verifying procedure interfaces
JP2002189617A (ja) 2000-12-22 2002-07-05 Nec Corp 評価システム、及び評価方法
NZ527660A (en) * 2001-01-26 2005-03-24 Bridicum Security Group As System for providing services and virtual programming interface
US7409602B2 (en) * 2003-11-12 2008-08-05 Lsi Corporation Methodology for debugging RTL simulations of processor based system on chip
US7287190B2 (en) * 2004-01-29 2007-10-23 Sun Microsystems, Inc. Simultaneous execution of test suites on different platforms
US7529977B2 (en) * 2006-05-31 2009-05-05 Microsoft Corporation Automated extensible user interface testing
KR20080068385A (ko) * 2007-01-19 2008-07-23 슈어소프트테크주식회사 소프트웨어 테스트 시스템, 방법 및 그 방법을 실행하기위한 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록매체
US8429619B2 (en) * 2007-07-03 2013-04-23 International Business Machines Corporation Executable high-level trace file generation system
US20090249216A1 (en) * 2008-03-28 2009-10-01 International Business Machines Corporation Interacting with multiple browsers simultaneously using linked browsers controlled from a primary browser interface

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09198279A (ja) * 1996-01-19 1997-07-31 Pentel Kk シミュレ−ションソフト内蔵携帯端末装置
JP2000215082A (ja) * 1999-01-26 2000-08-04 Hitachi Ltd 分散オブジェクト環境のプレイバックテスト方式
JP2007026306A (ja) * 2005-07-20 2007-02-01 Nec Corp プログラムテスト装置、方法、及び、プログラム
JP2007219893A (ja) * 2006-02-17 2007-08-30 Seiko Epson Corp ファームウェア評価システムおよびファームウェア評価方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2485204A (en) * 2010-11-05 2012-05-09 Jk Technosoft Uk Ltd Automating testing of an application using a hook mechanism
JP2016177659A (ja) * 2015-03-20 2016-10-06 ヤフー株式会社 検証プログラム、検証装置及び検証方法

Also Published As

Publication number Publication date
US8443381B2 (en) 2013-05-14
US20110067040A1 (en) 2011-03-17
JP5337155B2 (ja) 2013-11-06
JPWO2009150788A1 (ja) 2011-11-10

Similar Documents

Publication Publication Date Title
JP5337155B2 (ja) 組み込み機器におけるａｐｉ評価システム
Feng et al. {P2IM}: Scalable and hardware-independent firmware testing via automatic peripheral interface modeling
US8151277B2 (en) Method and system for dynamic remote injection of in-process agents into virtual machine based applications
KR101008977B1 (ko) ＯＳＧｉ 서비스 플랫폼 테스트 방법 및 이를 이용한테스트 툴
CN103634592A (zh) 智能电视自动化测试方法及系统
CN109426158B (zh) 用于生成在测试装置上可实施的模型的方法和测试装置
US20150100830A1 (en) Method and system for selecting and executing test scripts
US20040049362A1 (en) Same virtual machine mode for distributed test execution
WO2013099438A1 (ja) 協調シミュレーション用計算機システム、組込みシステムの検証方法及びプログラム
CN110119350A (zh) 软件开发工具包测试方法、装置和设备及计算机存储介质
CN111026627A (zh) 压力测试方法、装置及服务器
CN113672441A (zh) 对智能设备的测试方法及装置
US20120246636A1 (en) Method and arrangement for installing and configuring a computer system
KR20070052641A (ko) 로봇 제어를 위한 로봇 서버, 이를 포함하는 컨텐츠 제공시스템 및 그 방법
CN114217990A (zh) 一种基于udp协议分布式硬件远程通讯系统及其控制方法
US7873498B2 (en) Remote hardware inspection system and method
JP2008135008A (ja) プログラムモジュール検証方式
Feng et al. P $^ 2$ IM: Scalable and Hardware-independent Firmware Testing via Automatic Peripheral Interface Modeling (extended version)
CN111611065A (zh) 机器学习算法的调用方法、装置、存储介质及电子设备
US20140351643A1 (en) Smart terminal fuzzing apparatus and method using multi-node structure
US20190034259A1 (en) Systems and Methods for Implementing a Thread Trace Log
KR100918840B1 (ko) 센서 네트워크를 구성하기 위한 타겟 센서 노드를 시험하는장치 및 그 방법
KR102128004B1 (ko) 소프트웨어 검증 장치 및 방법
KR20220049334A (ko) 어플리케이션 테스트 방법 및 테스트 시스템
JP2006155047A (ja) 検証システム及び検証方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09762219

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010516734

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09762219

Country of ref document: EP

Kind code of ref document: A1