JP5526572B2 - Test apparatus and test method - Google Patents

Description

  The present invention relates to a test apparatus and a test method.

  2. Description of the Related Art Conventionally, a technique for performing an input / output processing evaluation test of an application (application software) is known. For example, an input / output request from the application software is sent to the device driver layer if the input / output parameters are checked by the system call layer and there is no abnormality. The device driver layer first determines whether or not to perform simulated input / output based on the received data. If simulated input / output is not performed, data is sent to the actual device for processing. On the other hand, when performing simulated input / output processing, simulated input / output can be performed to switch to device input / output (see, for example, Patent Document 1).

JP-A-10-133914

  However, in the conventional technique, simulated input / output processing is performed by returning information stored in advance in the device driver layer in response to a request from application software. Therefore, there is a problem that it is impossible to perform a test by simulating various responses returned from a legitimate device in response to various requests of application software.

  This test apparatus and test method is an apparatus and method for evaluating input / output processing of data exchanged between a test target application in an application layer and a hardware layer via a driver layer. The application layer includes a pseudo data creation unit. The pseudo data creation unit creates pseudo data of data passed from the hardware layer to the driver layer and outputs the pseudo data to the driver layer. The driver layer includes a pseudo data response unit. The pseudo data response unit returns the pseudo data passed from the application layer to the test target application as data passed from the hardware layer.

  According to this test apparatus and test method, it is possible to perform a test by simulating various responses returned from a legitimate device in response to various requests of an application.

It is a block diagram in Embodiment 1 of the present invention. It is a sequence diagram in Embodiment 1 of the present invention. It is a figure which shows the hardware constitutions in Embodiment 2 of this invention. It is a block diagram in Embodiment 2 of the present invention. It is a figure which shows the format of the normal transmission data in Embodiment 2 of this invention. It is a figure which shows the format of the normal reception data in Embodiment 2 of this invention. It is a figure which shows the format of the pseudo data in Embodiment 2 of this invention. It is a figure which shows the format of the pseudo data in Embodiment 2 of this invention. It is a flowchart in Embodiment 2 of this invention. It is a sequence diagram in Embodiment 2 of the present invention. It is a sequence diagram in Embodiment 2 of the present invention. It is a sequence diagram in Embodiment 2 of the present invention. It is a sequence diagram in Embodiment 2 of the present invention. It is a sequence diagram in Embodiment 2 of the present invention. It is a sequence diagram in Embodiment 2 of the present invention. It is a sequence diagram in Embodiment 2 of the present invention.

  Exemplary embodiments of a test apparatus and a test method will be described below in detail with reference to the accompanying drawings.

(Embodiment 1)
Configuration of test apparatus FIG. 1 is a block diagram according to Embodiment 1 of the present invention. As shown in FIG. 1, the test apparatus 1 includes an application layer 2 and a driver layer 3. The application layer 2 includes a test target application 4 and a pseudo data creation unit 5. The driver layer 3 includes a pseudo data response unit 6. The test apparatus 1 is an apparatus that evaluates input / output processing of data exchanged between the test target application 4 and the hardware layer 7 via the driver layer 3.

  The test target application 4 is an application for which the test apparatus 1 evaluates data input / output processing with the hardware layer 7. The pseudo data creation unit 5 creates pseudo data and outputs it to the driver layer 3. The pseudo data is data simulating data passed from the hardware layer 7 to the driver layer 3. The pseudo data is data that replaces the original data passed from the hardware layer 7 to the driver layer 3.

  The driver layer 3 is a device driver that operates the device of the hardware layer 7. In the driver layer 3, the pseudo data response unit 6 returns the pseudo data passed from the application layer 2 to the test target application 4 as data passed from the hardware layer 7. The hardware layer 7 may be connected to the test apparatus 1 or may not be connected. Further, as the hardware layer 7, a device other than a regular device may be connected to the test apparatus 1.

Test Device Operation FIG. 2 is a sequence diagram in the first embodiment of the present invention. As shown in FIG. 2, in the application layer 2, the pseudo data creation unit 5 creates pseudo data of data passed from the hardware layer 7 to the driver layer 3 (step S1). Then, the pseudo data creation unit 5 transmits the pseudo data to the driver layer 3 (step S2). The driver layer 3 receives the pseudo data from the application layer 2 and returns the pseudo data to the test target application 4 as data passed from the hardware layer 7 (step S3).

  According to the first embodiment, the pseudo data created by the pseudo data creation unit 5 is returned from the driver layer 3 to the test target application 4 as a response from the hardware layer 7 to the request of the test target application 4. No response from the device is required. Therefore, even if the hardware layer 7 is a device other than a regular device, it is possible to perform a test by simulating various responses returned from the regular device in response to various requests of the test target application 4. Further, when there is no device in the hardware layer 7, that is, even when the hardware layer 7 is a virtual device, similarly, various tests returned from the legitimate device can be simulated.

  Further, the pseudo data generation unit 5 may transmit the pseudo data to the driver layer 3 at an arbitrary timing, or the pseudo data response unit 6 may return the pseudo data to the test target application 4 at an arbitrary timing. Also good. By doing so, not only a response to a request from the test target application 4 but also a test such as a case where data is spontaneously transmitted from the hardware layer 7 can be performed. In addition, since the test target application 4 can be tested without a regular device, the application and the device of the hardware layer 7 can be developed in parallel.

(Embodiment 2)
Hardware configuration of test apparatus FIG. 3 is a diagram illustrating a hardware configuration according to the second embodiment of the present invention. As shown in FIG. 3, the test apparatus includes, for example, a computer main body 11, an input device 12, and an output device 13. The test apparatus can be connected to a network 14 such as a local area network (LAN), a wide area network (WAN), and the Internet via a router or a modem (not shown).

  The computer main body 11 includes, for example, a central processing unit (CPU, central processing unit), a memory, and an interface. The CPU governs overall control of the test apparatus. The memory includes, for example, a read only memory (ROM), a random access memory (RAM), a hard disk (HD, hard disk), and an optical disk 15. The memory is used as a work area for the CPU. Various programs are stored in the memory. Various programs are loaded according to instructions from the CPU. The interface controls, for example, input from the input device 12, output to the output device 13, and transmission / reception with respect to the network 14. The input device 12 includes, for example, a keyboard 16, a mouse 17, a scanner 18, and the like. The output device 13 includes a display 19, a speaker 20, a printer 21, and the like, for example.

FIG. 4 is a block diagram according to the second embodiment of the present invention. As shown in FIG. 4, the test apparatus 31 includes an application layer 32 and a driver layer 33. The application layer 32 includes a test target application 34 and a pseudo data creation application 35. The pseudo data creation application 35 corresponds to a pseudo data creation unit. The driver layer 33 includes a determination unit 36, a reception unit 37, a user data processing unit 38, a control data processing unit 39, a reception buffer 40, and a pruning processing unit 41.

  The determination unit 36 determines the device type of the hardware layer 46. As a result of determining the type of the device, the determination unit 36 notifies the test target application 34 as a regular device even when the hardware layer 46 is a device other than a regular device or a virtual device. The determination unit 36 operates during the process of initializing the device driver of the driver layer 33.

  The reception unit 37 receives data transmission processing from the test target application 34 and data transmission processing from the pseudo data creation application 35. The reception unit 37 includes a data interpretation unit 42. The data interpretation unit 42 determines the type of data received by the reception unit 37. If the data interpretation unit 42 determines that the data type is normal transmission data to the hardware layer 46, the data interpretation unit 42 transmits the transmission data addressed to the hardware layer 46 to the hardware layer 46. When the data type is pseudo data, the data interpretation unit 42 transmits the pseudo data to the user data processing unit 38 or the control data processing unit 39 according to the type of the pseudo data.

  The user data processing unit 38 is an interface that receives user data such as streaming. The user data processing unit 38 transmits the data sent from the data interpretation unit 42 to the test target application 34 as user data sent from the hardware layer 46.

  The control data processing unit 39 is an interface that receives control data. The control data processing unit 39 transmits the data sent from the data interpretation unit 42 to the reception buffer 40 as control system data sent from the hardware layer 46.

  The reception buffer 40 stores control system data sent from the control data processing unit 39. The mowing processing unit 41 is an interface between the application layer 32 and the reception buffer 40. The test target application 34 reads data stored in the reception buffer 40 via the mowing processing unit 41. The user data processing unit 38, the control data processing unit 39, the reception buffer 40, the pruning processing unit 41, and the data interpretation unit 42 operate as a pseudo data response unit.

  The hardware layer 46 may be a device other than a regular device, or may be a virtual device that does not actually exist. A device assumed as the hardware layer 46 is, for example, an interface device that controls wired or wireless communication. Examples of such an interface device include a device used in an environment in which a response is returned from the network side to a request from the application layer 32, such as a communication card such as a wireless LAN. As such a device, for example, a wireless LAN card conforming to the 802.11a or 802.11b standard of Institute of Electrical and Electronic Engineers (IEEE).

  The test target application program is, for example, a program that establishes or controls communication with the device of the hardware layer 46. The test target application program and the pseudo data creation application program are stored, for example, in the memory of the computer main body. The application layer 32 is realized by expanding the test target application program and the pseudo data creation application program loaded from the memory into the memory. The driver layer 33 is realized by developing a device driver program loaded from the memory in the memory.

Data format FIG. 5 is a diagram showing a format of normal transmission data in the second embodiment of the present invention. As shown in FIG. 5, normal transmission data 51 includes a transmission data type field 52 that stores, for example, transmission data type information (for example, “SEND — 1...”), And a transmission data field 53 that stores transmission data. ing. Normal transmission data is data transmitted from the test target application 34 to the hardware layer 46. The data interpretation unit 42 of the driver layer 33 recognizes that the transmission data is addressed to the hardware layer by referring to the transmission data type information.

  FIG. 6 is a diagram showing a format of normal reception data in the second embodiment of the present invention. As shown in FIG. 6, the normal reception data 54 includes a reception data type field 55 that stores, for example, reception data type information (for example, “RECV_1...”), And a reception data field 56 that stores reception data. ing. Normal reception data is data returned from the legitimate device to the application in the user's usage environment in the field. Therefore, normal reception data does not appear in the test environment in the second embodiment.

  FIG. 7 is a diagram showing a format of pseudo data in Embodiment 2 of the present invention. As shown in FIG. 7, the pseudo data 57 includes, for example, a pseudo data type field 58 for storing pseudo data type information (for example, “SEND_DUMMY”), and a pseudo received data field 59 for storing pseudo received data. The pseudo reception data is data that replaces normal reception data. The pseudo received data field 59 includes, for example, a received data type field 60 for storing received data type information (for example, “RECV_1...”) And a received data field 61 for storing received data, similarly to normal received data. I have. The data interpretation unit 42 recognizes the pseudo received data to be returned to the test target application 34 by referring to the pseudo data type information.

  FIG. 8 is a diagram showing a format of pseudo data in Embodiment 2 of the present invention. As shown in FIG. 8, the pseudo data 62 is obtained by adding a standby counter value field 63 for storing a standby counter value to the format of the pseudo data 57 shown in FIG. The standby counter value is data that controls the timing for returning the pseudo reception data to the test target application 34.

Driver Layer Operation FIG. 9 is a flowchart according to the second embodiment of the present invention. In the test, the driver layer 33 performs processing in the following procedure, for example. As shown in FIG. 9, the reception unit 37 receives data from the application layer 32 (step S11). Then, the data interpretation unit 42 refers to the data type field (transmission data type field 52 or pseudo data type field 58) of the received data, and determines whether the received data is normal transmission data addressed to the hardware layer. Is determined (step S12). As a result of the determination, when the received data is normal transmission data (step S12: No), the data interpretation unit 42 transmits the data stored in the transmission data field 53 of the received data to the hardware layer 46. (Step S19). Data transmitted to the hardware layer 46 is discarded in the hardware layer 46.

  On the other hand, when the data received from the application layer 32 is pseudo data (step S12: Yes), the data interpretation unit 42 refers to the reception data type field 60 of the pseudo reception data field 59 of the received data, and receives pseudo reception data. Is control data or user data (step S13). As a result of the determination, when the pseudo reception data is user data (step S13: No), the data interpretation unit 42 transmits the data stored in the reception data field 61 of the pseudo reception data field 59 to the user data processing unit 38. To do. The user data processing unit 38 receives the data sent from the data interpretation unit 42 (step S18), and transmits the data as user data to the test target application 34 of the application layer 32 (step S17).

  On the other hand, when the pseudo reception data is control system data (step S13: Yes), the data interpretation unit 42 transmits the data stored in the reception data field 61 of the pseudo reception data field 59 to the control data processing unit 39. To do. The control data processing unit 39 receives the data sent from the data interpretation unit 42 (step S14) and sends the data to the reception buffer 40. The reception buffer 40 stores the data sent from the control data processing unit 39 (step S15). The mowing processing unit 41 receives data mowing processing from the test target application 34 (step S16), and reads the data stored in the reception buffer 40. The mowing processing unit 41 transmits the data read from the reception buffer 40 to the test target application 34 as control system data (step S17). Through this series of procedures, even if the hardware layer 46 is not a legitimate device or a virtual device, correct data originally received from the hardware layer 46 is returned from the driver layer 33 to the test target application 34. .

・ Test equipment operation (operation to make non-regular devices appear as regular devices)
FIG. 10 is a sequence diagram in the second embodiment of the present invention. In FIG. 10, device A is a regular device and device B is a non-regular device. As shown in FIG. 10, when the hardware layer 46 is the device B, the operating system (OS, operating system, basic software) detects the device B when installing the device driver, and then the device driver for the device A Is registered in advance in a system definition file (INF file), for example. When the OS detects the device B during the test (step S21), the OS activates a device driver for the device A (step S22). The test target application 34 for hardware A searches for a device driver for device A at the time of activation (step S23). Since the device driver for device A is activated, the test target application 34 recognizes the device driver for device A and continues the test process (step S24).

・ Test device operation (operation to make a virtual device look like a regular device)
FIG. 11 is a sequence diagram in the second embodiment of the present invention. In FIG. 11, device A is a regular device, and virtual device A is a virtual device of device A. As shown in FIG. 11, when there is no device in the hardware layer 46, the virtual device technology is used. Therefore, the hardware layer 46 becomes the virtual device A. In this case, if the OS detects the device A when installing the device driver, the OS registers in advance, for example, in a system definition file so that the device driver for the device A is activated. When the OS detects the device A (virtual device A) during the test (step S31), the OS activates a device driver for the device A (step S32). The test target application 34 for hardware A searches for a device driver for device A at the time of activation (step S33), recognizes the device driver for device A, and continues the test process (step S34). Steps S24 and S34 will be described below with reference to FIGS.

・ Operation of test equipment (test when there is no response)
FIG. 12 is a sequence diagram in the second embodiment of the present invention. As illustrated in FIG. 12, the test target application 34 transmits normal transmission data addressed to the hardware layer to the driver layer 33 (step S41). The driver layer 33 transmits the data sent from the test target application 34 to the hardware layer 46 (step S42). Since the pseudo data creation application 35 does not transmit pseudo data to the driver layer 33, no data is stored in the reception buffer 40. Therefore, when the test target application 34 prunes data to the reception buffer 40, information indicating no data is returned to the test target application 34 (step S43). In this case, since the test target application 34 cannot obtain an expected response to the transmission data to the hardware layer 46, for example, a request for retransmission or error processing is performed. Normal transmission data sent to the hardware layer 46 is discarded.

・ Test equipment operation (test when response is normal)
FIG. 13 is a sequence diagram in the second embodiment of the present invention. As shown in FIG. 13, the test target application 34 transmits normal transmission data to the hardware layer 46 via the driver layer 33 (steps S51 and S52), similarly to step S41 and step S42. Next, the pseudo data creation application 35 recognizes that normal transmission data addressed to the hardware layer has been transmitted, and transmits pseudo data including a response value expected for the transmission data to the driver layer 33 ( Step S53). In the driver layer 33, the control data processing unit 39 stores the control system data extracted from the received pseudo data in the reception buffer 40 as a response value (step S54). Next, the test target application 34 performs data pruning on the reception buffer 40. As a result, the data stored in the reception buffer 40 is returned as a response value from the driver layer 33 to the test target application 34 (step S55). When user data is extracted from the pseudo data, the user data processing unit 38 transmits the user data to the test target application 34. The pseudo data creation application 35 may recognize that normal transmission data has been transmitted from the test target application 34 by, for example, setting a flag.

・ Operation of test equipment (test when response is delayed)
FIG. 14 is a sequence diagram in the second embodiment of the present invention. As shown in FIG. 14, the pseudo data creation application 35 does not transmit pseudo data immediately after the test target application 34 transmits normal transmission data (step S61, step S62). Therefore, even if the test target application 34 prunes data to the reception buffer 40, information indicating no data is returned to the test target application 34 (step S63). The pseudo data creation application 35 transmits pseudo data to the driver layer 33 after an arbitrary time has elapsed after the test target application 34 transmits normal transmission data (step S64). Thereby, after an arbitrary time has elapsed after transmission of the normal transmission data, the control system data extracted from the pseudo data is stored in the reception buffer 40 (step S65). Thereafter, the test target application 34 prunes data to the reception buffer 40, whereby a response value is returned to the test target application 34 (step S66). When the response value is user data, the user data processing unit 38 transmits user data to the test target application 34 after an arbitrary time has elapsed after transmission of normal transmission data. For example, a flag is set when an arbitrary time has elapsed after transmission of normal transmission data, so that the pseudo data creation application 35 recognizes that normal transmission data has been transmitted with a delay from the actual transmission timing. You may make it do.

・ Operation of test equipment (another example of test when response is delayed)
FIG. 15 is a sequence diagram in the second embodiment of the present invention. As shown in FIG. 15, the pseudo data creation application 35, after the test application 34 transmits normal transmission data (step S71, step S72), includes pseudo data including a standby counter value (= n, n is a natural number). Is transmitted to the driver layer 33 (step S73). Control system data and standby counter values are extracted from the pseudo data, and these data are stored in the reception buffer 40 (step S74). The test target application 34 performs data pruning on the reception buffer 40, but information indicating no data is returned to the test target application 34 until the number of pruning exceeds the standby counter value (= n) (step S75). . When the number of harvesting is n + 1, the harvesting processing unit 41 returns a response value to the test target application 34 (step S76). At that time, the mowing processing unit 41 does not return the standby counter value to the test target application 34. The mowing processing unit 41 may monitor the standby counter value and the number of times of trimming, and may not return a response value to the test target application 34 until the number of times of trimming exceeds the standby counter value. When the response value is user data, the user data processing unit 38 transmits the user data to the test target application 34 regardless of the standby counter value. Instead of setting the standby counter value by the number of cuttings, it may be set by time. That is, after the test target application 34 transmits normal transmission data, the mowing processing unit 41 may not return a response value to the test target application 34 until the time set in the standby counter value elapses. . When setting the standby counter value by time, the user data processing unit 38 may transmit user data to the test target application 34 after the time set for the standby counter value has elapsed.

・ Test equipment operation (test when data is sent spontaneously from the hardware layer)
FIG. 16 is a sequence diagram in the second embodiment of the present invention. As shown in FIG. 16, the pseudo data creation application 35 transmits pseudo data to the driver layer 33 at an arbitrary timing (step S81). In the driver layer 33, the control data processing unit 39 stores the control system data extracted from the pseudo data in the reception buffer 40 as a response value (step S82). Next, the test target application 34 performs data pruning on the reception buffer 40, and acquires data stored in the reception buffer 40 as a response value (step S83). When user data is extracted from the pseudo data, the user data processing unit 38 transmits the user data to the test target application 34. In the test of the procedure shown in FIG. 16, normal transmission data addressed to the hardware layer is not transmitted before the pseudo data is transmitted. Therefore, the response value returned to the test target application 34 by the pseudo data is not a response to the request of the test target application 34. That is, a test is performed when data is spontaneously sent from the hardware layer 46.

  According to the second embodiment, the same effect as in the first embodiment can be obtained. Further, the response value by the pseudo data returned from the driver layer 33 to the test target application 34 uses the original logic when the driver layer 33 returns the data received from the hardware layer 46 to the application layer 32. Returned to Accordingly, it is not necessary to perform a time-consuming test using a large-scale device such as an emulator, so that it is possible to reduce the man-hour and cost for developing an application.

  The following additional notes are disclosed with respect to the first and second embodiments described above.

(Supplementary Note 1) A test apparatus for evaluating input / output processing of data exchanged between a test target application of an application layer and a hardware layer via a driver layer, wherein the hardware includes the hardware A pseudo data creation unit that creates pseudo data of data passed from the layer to the driver layer and outputs the pseudo data to the driver layer, and is provided in the driver layer to the application under test as data passed from the hardware layer A test apparatus comprising: a pseudo data response unit that returns the pseudo data.

(Additional remark 2) The said pseudo data response part outputs the data output to the said hardware layer from the said test object application to the said hardware layer, The test apparatus of Additional remark 1 characterized by the above-mentioned.

(Additional remark 3) The said pseudo data preparation part is the data of the response value returned from the said hardware layer to the said test object application with respect to the data output to the said hardware layer from the said test object application as said pseudo data The test apparatus according to appendix 1 or 2, characterized in that:

(Additional remark 4) The said driver layer is provided with the determination part which determines the device of the said hardware layer, and shows an actual device with respect to the said test object application to the device corresponding to the said test object application, It is characterized by the above-mentioned. The test apparatus according to any one of appendices 1 to 3.

(Additional remark 5) The said driver layer is provided with the determination part which determines the device of the said hardware layer, and makes a device corresponding to the said test object application show a virtual device with respect to the said test object application. The test apparatus according to any one of 1 to 3.

(Additional remark 6) The said pseudo data preparation part is provided with the information which shows that it is the data returned to the said test object application as the data passed from the said hardware layer, and the data returned to the said test object application. The test apparatus according to any one of appendices 1 to 5, wherein the pseudo data is created.

(Additional remark 7) The said pseudo data preparation part produces the said pseudo data further provided with the information which controls the timing returned to the said test object application of the data returned to the said test object application, The additional data characterized by the above-mentioned. 6. The test apparatus according to 6.

(Supplementary Note 8) A test method for evaluating input / output processing of data exchanged between a test target application of an application layer and a hardware layer via a driver layer, which is passed from the hardware layer to the driver layer A pseudo data creating step of creating pseudo data of the data to be output to the driver layer, and a pseudo data response step of returning the pseudo data from the driver layer to the test target application as data passed from the hardware layer; The test method characterized by including these.

(Additional remark 9) It further includes the process of determining the device of the said hardware layer before the said pseudo data creation process, and making the device corresponding to the said test object application show an actual device with respect to the said test object application. The test method according to appendix 8, characterized in that:

(Additional remark 10) It further includes the process of determining the device of the said hardware layer, and making the device corresponding to the said test object application show the virtual device with respect to the said test object application before the said pseudo data creation process. The test method according to appendix 8, characterized by:

DESCRIPTION OF SYMBOLS 1,31 Test apparatus 2,32 Application layer 3,33 Driver layer 4,34 Test object application 5,35 Pseudo data creation part 6,38-42 Pseudo data response part 7,46 Hardware layer 57,62 Pseudo data

Claims (5)

A test apparatus for evaluating input / output processing of data exchanged via a driver layer between a test target application of an application layer and a hardware layer,
In the application layer, when an arbitrary time has elapsed since the test target application transmitted data addressed to the hardware layer, the data output from the test target application to the hardware layer Pseudo data including a response value returned from the hardware layer to the test target application and a standby counter value indicating the number of times of data pruning by the test target application as a condition for returning the response value to the test target application A pseudo data creation unit that creates and outputs to the driver layer,
In the driver layer, when the number of data pruning by the test target application exceeds the standby counter value included in the pseudo data, the pseudo test data is passed to the test target application as data passed from the hardware layer. A pseudo data response unit that returns the response value included in the data;
A test apparatus comprising:   The test apparatus according to claim 1, wherein the pseudo data response unit outputs data output from the test target application to the hardware layer to the hardware layer.   The determination unit for determining a device of the hardware layer in the driver layer and showing an actual device for the test target application to a device corresponding to the test target application. 2. The test apparatus according to 2.   3. The determination unit for determining a device of the hardware layer in the driver layer and displaying a virtual device for the test target application on a device corresponding to the test target application. The test apparatus described in 1. A test method for evaluating input / output processing of data transferred via a driver layer between a test target application of an application layer and a hardware layer,
When an arbitrary time has elapsed after the test target application transmits data addressed to the hardware layer, the test is performed from the hardware layer on the data output from the test target application to the hardware layer. The driver layer by creating pseudo data including a response value returned to the target application and a standby counter value indicating the number of times the data is trimmed by the test target application, which is a condition for returning the response value to the test target application Pseudo data creation process to output to
When the number of data pruning by the test target application exceeds the standby counter value included in the pseudo data , the response value included in the pseudo data is transmitted from the driver layer to the test target application from the hardware layer. A pseudo data response process to return as the passed data;
A test method comprising:

Images