JP2009104490A - Program testing equipment - Google Patents

Abstract

Conventionally, since it is a method of developing or correcting a hardware drive program, it is required to have a high technical difficulty in constructing a test environment and to be familiar with computer resource experts and the inside of an OS kernel. The requirements for the test environment could not be easily met.
When verifying the operation of a program under test, an apparatus for verifying the validity of various response processes for access to a computer hardware resource (real I / O device 62) by the program under test is provided. A pseudo driver 23 that generates various pseudo responses by a function of replacing a normal return value from an interface that services access to a hardware resource with an arbitrary response value based on a predetermined parameter. The operation verification for an arbitrary response process is performed.
[Selection] Figure 1

Description

  The present invention relates to a test apparatus for a program for verifying the validity of various response processes for access to a computer hardware resource by a program under test when performing operation verification of a program under test operating on a computer.

  In particular, the present invention includes a pseudo driver configured with a pseudo response (including fault) generation program, which is used when verifying operations related to various response processes including an abnormal access response to a computer hardware resource. The present invention relates to a program test apparatus for performing a program test using a computer.

(1): Conventional example 1
Hereinafter, a conventional test method will be described as Conventional Example 1.

  In Conventional Example 1, the following test method was performed. In other words, when various responses including abnormal responses occur when accessing the computer hardware resources of the program under test, the validity of processing is crafted so that abnormalities occur in the actual hardware using physical methods. Develop or modify a hardware driver program called from an interface that services a computer hardware resource access using a tested I / O device, and incorporate various responses including pseudo failure responses And various responses including abnormal responses were generated.

(2): Conventional example 2
Hereinafter, Patent Document 1 will be described as Conventional Example 2. Conventional Example 2 describes the following contents.

(a): “Provide computer system and device input / output simulator capable of performing application software input / output processing evaluation tests.” See the summary section.
(b): “The input / output request from the AP is checked by the system call layer for input / output parameters, and if there is no abnormality, it is sent to the device driver layer 3. The device driver layer 3 is based on the received data. First, in step S1, it is determined whether or not to perform simulated input / output.If simulated input / output is not performed, the process proceeds to step S2 to send data to the actual device for processing.

On the other hand, when the simulated input / output process is performed, the process proceeds to step S3, where the simulated input / output is performed to change to the device input / output. In step S4, it is determined whether or not the input / output request sent from the AP requires a trace process for recording the history information of the process. If necessary, the process proceeds to step S5 to perform the trace. Refer to the summary column.
(3): Conventional example 3
Hereinafter, Patent Document 2 will be described as Conventional Example 3. Conventional Example 3 describes the following contents.

(a): “Provide input / output simulation technology that enables easy and quick verification of complex cooperative operation between CPU and input / output device.” See the summary section.
(b): “In an I / O simulation of software such as a microcomputer, the results of I / O commands and interrupt operations are shown in time series, so that the operator etc. can grasp the simulation results quickly and accurately. This makes it possible to easily verify a complicated cooperative operation between the CPU and the input / output device. "... Refer to paragraph [0031].
(4): Conventional example 4
Hereinafter, Patent Document 3 will be described as Conventional Example 4. Conventional Example 4 describes the following contents.

(a): “The program under test such as an I / O handler and the input / output device are simulated by simulating the operation of the input / output device part and synchronizing the simulated operation with the suspended / restarting operation of the program under test. "... (see the second page, upper left column, line 8 to page 2, upper left column, line 12)"
JP-A-10-133914 JP-A-5-224994 JP-A-1-76236

  (1): In the test of Conventional Example 1, a tester with a high level of skill is working on hardware, developing a driver program, or putting a hand in the driver program. There was a problem with reliability.

  (2): In general, in the test of a program as in Conventional Example 1, the accuracy (test coverage) that can detect a problem in the program under test depends on the contents of the test environment, and the cause of the problem when it occurs It greatly affects ease. For this reason, when building a test environment that focuses on problem detection accuracy and test coverage, or a test environment that focuses on identifying the cause of the problem, the following items are required as the test environment and test method.

  (a): The test environment must be reproducible under the same conditions.

  (b): The state of the test environment can be stabilized for a long time.

  (c): The test environment should not depend on the skill of the person in charge, and anyone can build a uniform environment.

  (d): A comprehensive test can be performed according to the type of response processing of the program under test.

  (e): The test should be able to test the I / O response timing entanglement equivalent to the actual one.

  (f): In the test environment, the same test as actual data such as huge data (over several hundred MB) and actual I / O control data can be performed.

  However, since the test method of the conventional example 1 is a method of developing or correcting a hardware drive program called from an application interface that crafts actual hardware or services access to computer hardware resources, The technical difficulty of constructing the test environment is high, and it is required to be a computer resource expert and to be familiar with the inside of the OS kernel, so that the requirements required for the test environment cannot be easily satisfied.

  (3): Conventional example 2 describes an evaluation method using a computer system and a device input / output simulator capable of evaluating input / output processing of a program under test. However, Conventional Example 2 is a technique for replacing real I / O with simulated I / O by a simulator, and relates to a method for effectively performing a test in an environment that does not use real I / O. The only function that has been realized is not a unique technology that leaves the area of the conventional simulator, but a technology that solves a problem that is different from the problem that has been a problem in Conventional Example 1, Content.

  (4): Conventional Example 3 provides an input / output simulation technique capable of easily and quickly verifying a complicated cooperative operation between a CPU and an input / output device, and is a content of reference level of the present invention. It is.

  (5): Conventional example 4 simulates the operation of the input / output device part, and synchronizes the simulated operation with the suspended / resumed operation of the program under test, thereby allowing the program under test such as an I / O handler. And the input / output device are easily realized, and the content of the present invention is a reference level.

  The present invention has been made to solve the conventional problems, and can perform operation verification for any response process via a pseudo driver configured by a computer hardware resource access program having various pseudo response generation functions. The purpose is to be.

  In order to achieve the above object, the present invention is configured as follows.

  That is, a test apparatus for a program for verifying the validity of various response processes for access to a computer hardware resource by a program under test when performing operation verification of a program under test operating on a computer, A pseudo driver that generates various pseudo responses by a function of replacing a normal return value from an interface that services access to a resource with an arbitrary response value based on a predetermined parameter is provided via the pseudo driver. It has a function to perform operation verification for arbitrary response processing.

(Function)
FIG. 1 is a diagram illustrating the principle of the present invention. The operation of the present invention based on the above configuration will be described below with reference to FIG.

  The pseudo driver 23 is located between the OS kernel 21 and the real I / O driver 60 in the driver layer, and is registered as a hook function of the OS kernel 21 so that the process is passed to the real I / O driver 60 immediately before the process is passed. Processing is passed to the pseudo driver 23 (registered as such).

  With this hook function, an I / O processing request from the application layer (program under test) is passed to the pseudo driver 23 immediately before passing to the real I / O driver 60 (instead of the dotted lines R1 and R2 in FIG. Therefore, the subsequent processing follows the processing of the pseudo driver 23.

  That is, the routes indicated by dotted lines R1 and R2 in FIG. 1 are processing routes when the pseudo driver 23 is not hooked, and the routes indicated by solid lines R3 and R4 are processing routes when the pseudo driver 23 is hooked. become. Here, the pseudo driver 23 converts the response from the driver layer into various responses including an abnormal response and responds to the application layer. The program under test performs processing based on various responses including an abnormal response from the pseudo driver 23.

  Note that the response of the pseudo driver 23 can be set by a parameter. Further, since the pseudo driver 23 looks like a normal driver layer when viewed from the application layer, it is not necessary to make any changes to the program under test, so that a test with a normal product version is possible.

  Here, I / O processing basically uses real I / O, and only response values or data are replaced by parameters, so that it is not necessary to develop special I / O drivers or simulator programs. Yes.

  Accordingly, various functions can be used to replace a normal return value from an interface that services access to computer hardware resources (real I / O device 62 in the hardware layer) with an arbitrary response value based on a predetermined parameter. The pseudo driver 23 for generating the pseudo response is provided, and an operation verification (test) for an arbitrary response process is performed via the pseudo driver 23. In this way, operation verification for an arbitrary response process can be performed via the pseudo driver 23 configured by a computer hardware resource access program having various pseudo response generation functions.

  The present invention has the following effects in claims 1 to 5.

  (1): The test environment has reproducibility under the same conditions. In other words, since the pseudo driver operates based on the response table parameters set by the operator, it is easy to reproduce the same test by executing the test using the same response table as the program under test in the same environment. .

  (2): The test environment can be stabilized for a long time. In other words, there is no operator intervention after the start of the test, and the test proceeds with only the program under test and the response table. Therefore, the test can be repeatedly executed by setting repeats and the like, so that the same state can be stably maintained.

  (3): Test implementation does not depend on the skill of the person in charge, and anyone can build a uniform environment. In other words, the implementation of the pseudo driver does not require a high level of expertise or skill like OS kernel or I / O driver development, but is a technology that can develop normal applications that perform condition determination and conversion processing. realizable. In addition, since the test can be performed almost automatically using a response table, anyone can easily test the same content. The test contents are only response table parameter settings, and there is no skill dependence.

  (4): Extensive testing can be performed according to the type of response processing of the program under test. That is, the completeness of the test depends on the combination of the response table parameters. As combinations of response table parameter settings, it is possible to comprehensively extract parameters based on combinations of processing routes of the program under test.

  In addition, since the flow of processing is recorded in the access table, and there is a record of replacement execution in the response table, it is easy for the tester to analyze the records and find out how far the route was actually covered I can grasp. Based on this result, by adding uncovered portions to the response table, it is possible to finally create a response table that achieves the expected coverage.

  (5): In the test, the I / O response timing entanglement test equivalent to the actual one can be performed. In other words, the I / O operation is characterized by using the real I / O and replacing only the response value, and the test at the I / O response timing similar to the environment in which the program under test actually operates and operates. Can be implemented. This is the most different and superior to the method using a simulator.

  (6): In the test environment, the same tests as actual data such as huge data (over several hundred MB) and actual I / O control data can be performed. In other words, I / O operation uses real I / O, and only response values are replaced. Input / output data and control data use actual I / O results, so the program under test actually Tests can be performed with data similar to the operating and operating environment. This is the most different and superior to the method using a simulator.

  (7): Tests with extended timing dependence can be performed. In other words, the “delay time range” function of the response table can delay a normal I / O request (or a response indicating completion of I / O processing) by an arbitrary time. With this function, for example, in multitasking, it is possible to delay I / O control of each task and intentionally change the task execution order. This means that if there is a dependency relationship between the task execution order and the I / O processing order, for example, in task A and task B, task I I / O processing is completed after task A I / O processing is completed. In general, it is necessary to set semaphores between tasks and control them clearly. However, if the semaphores are set incorrectly when creating a program, the task execution order will not be compensated. For example, inconsistencies are detected during testing, but it is timing dependent and the order between tasks may be as expected, and in that case it may not be found in the test. With respect to such a program error, it is possible to test the order (timing dependence) by intentionally shifting the processing timing of the I / O processing.

§1: Outline Description FIG. 1 is a diagram illustrating the principle of the present invention. In FIG. 1, 21 is an OS kernel, 23 is a pseudo driver, 60 is a driver layer (real I / O driver), 61 is an I / O port, and 62 is a hardware layer (real I / O device). R1 and R2 indicate access and response routes when the pseudo driver 23 is not hooked by the hook function of the OS kernel 21 (normal processing), and R3 and R4 indicate the pseudo driver 23 by the hook function of the OS kernel 21. Indicates the access and response routes when is hooked.

  (1): When verifying the operation of a program under test running on a computer, the validity of various response processes for accessing the computer hardware resource (hard layer real I / O device 62) by the program under test is checked. A test apparatus for a program to be verified, and various pseudo-responses by a function of replacing a normal return value from an interface that services access to computer hardware resources with an arbitrary response value based on a predetermined parameter. And a function of performing operation verification for an arbitrary response process via the pseudo driver 23.

  (2): In the program test apparatus according to (1), the pseudo driver 23 sets a normal response value from an interface that services access to computer hardware resources to an arbitrary time based on a predetermined schedule. After that, it has a function of replacing an arbitrary response value, and has a function of performing an operation verification for an arbitrary pseudo response process via the pseudo driver 23.

  (3): In the test apparatus for the program of (1), the pseudo driver 23 receives a normal response value from an interface that services access to the computer hardware resource, and is given a predetermined access condition or response value. It has a function to generate various pseudo responses by scheduling an arbitrary combination and returning an arbitrary response value based on the schedule. Through the pseudo driver 23, operation verification for an arbitrary pseudo response process is performed. I do.

  (4): In the program test apparatus according to (1), the pseudo driver 23 uses a normal return value from an interface that services access to computer hardware resources as a pre-given access condition or response value. A test function for a program under test that returns an arbitrary response value based on the schedule is prepared, and the returned response value is recorded by the function of the pseudo driver, from the recorded response value. The scope of the test was able to be grasped.

  (5): In the program test apparatus of (1), the pseudo driver 23 performs a process test on the same data as the real environment by causing the real I / O to execute the operation, and the response value is set in advance. Operation verification is performed by having a function of returning a given pseudo-response value scheduled for a combination of access conditions and response values.

§2: Description of the configuration of a computer constituting the program test apparatus FIG. 2 is an overall configuration diagram of the apparatus. The configuration of a computer constituting the program test apparatus will be described below with reference to FIG.

  The program test apparatus (see, for example, FIG. 1) is realized by the computer shown in FIG. The computer is composed of an arbitrary computer such as a personal computer or a workstation (hereinafter, the computer constituting the program test apparatus is also simply referred to as “computer”).

  As shown in FIG. 2, the computer (or computer system) constituting the program test apparatus includes a computer main body 1, an input device 2 connected to the computer main body 1, a display device 3, and other I / Os. An O device (for example, a file device) 62 is configured. The computer main body 1 is provided with a CPU 11 (processor), a memory device 15, a memory control unit 12, an I / O control unit 13, a communication control unit 14, and the like.

  Further, the memory device 15 includes an OS kernel 21, a program under test 22, a pseudo driver 23, an access table 51 and a response table 52 used by the pseudo driver 23 (see FIG. 3 for these tables 51 and 52). A pseudo driver setting utility 53 used by the pseudo driver 23 and a real I / O driver 60 (hereinafter simply referred to as “I / O driver 60”) for driving various I / O devices such as the I / O device 62. ) Etc. are provided. The detailed description of each part is as follows.

  The input device 2 inputs information to the computer (or computer system). The input device 2 is used for a conversation with a computer or an application program when operated by an operator. The display device 3 displays various information (or data) in the computer (or computer system).

  The hard layer I / O device 62 (including various I / O devices) includes a file device (for example, a hard disk device), a communication control device, and the like. The CPU 11 is a processor constituting the computer. The memory control unit 12 controls a memory such as the memory device 15. The I / O control unit 13 controls the I / O device 62 that is an external input / output device. The communication control unit 14 controls the communication device.

  The memory device 15 stores various data (including programs). The OS kernel 21 is an OS kernel that controls the computer stored in the memory device 15. The program under test 22 is a program under test stored in the memory device 15. The pseudo driver 23 is a pseudo driver stored in the memory device 15.

  The real I / O driver 60 is various real I / O drivers stored in the memory device 15. The access table 51 and the response table 52 are an access table that is referred to or updated by the pseudo driver 23 stored in the memory device 15 and a response table in which operation parameters are written (see FIG. 3). The pseudo driver setting utility 53 is a utility that performs various settings for the pseudo driver 23 in a conversation format with an operator.

§3: Detailed configuration of pseudo driver FIG. 3 is an explanatory diagram of a pseudo driver. Hereinafter, the configuration of the pseudo driver will be described in detail with reference to FIG.

  The pseudo driver 23 includes a pseudo driver control unit 31, an access analysis unit 32, a scheduler 33, a response generation unit 34, a response analysis unit 35, and the like, and a memory common area 50 (the memory device 15 of FIG. 2). Some areas) have an access table 51 and a response table 52.

  The scheduler 33 is connected with a setting analysis unit 36, an abnormal response unit 37, a normal response unit 38, a not ready unit 39, a timeout unit 40, a sense data generation unit 41, and an abnormal data generation unit 42. is doing. The function of each part is as follows.

  The pseudo driver control unit 31 controls the entire pseudo driver. The access analysis unit 32 analyzes access contents (I / O request) from the application layer. The scheduler 33 performs a schedule for converting a response from the driver layer according to the setting of the tester.

  The response generation unit 34 converts the result of the driver layer according to the setting from the scheduler 33 and returns a response to the application layer. The response analysis unit 35 analyzes the response from the driver layer and notifies the scheduler of the result. The setting analysis unit 36 analyzes the setting contents of the tester and notifies the scheduler.

  The abnormal response unit 37 generates an abnormal response according to the setting of the tester. The normal response unit 38 generates a normal response according to the setting of the tester. The knot ready unit 39 generates knot ready according to the setting of the tester. The timeout unit 40 generates a timeout according to the setting of the tester.

  The sense data generation unit 41 generates sense data according to the setting of the tester. The abnormal data generation unit 42 generates an abnormality in the read data in accordance with the setting of the tester. The access table 51 is a table that stores the result of analyzing the access content (I / O request) from the application layer, and is created by the access analysis unit 32.

  The response table 52 is a table storing access contents (I / O requests) from the application layer and information associated with the response contents according to the setting of the tester, and is created by the scheduler. It is assumed that the access table 51 and the response table 52 are placed in the memory common area 50 so that they can be referred to from the pseudo driver 23 and the pseudo driver setting utility 53 (see FIG. 2).

§4: Description of concept of test method FIG. 4 is a conceptual diagram of the test method. The concept of the test method will be described below based on FIG.

  In the example test method described below, the pseudo driver 23 converts and returns a pseudo response to a normal response from a computer hardware resource accessed by the program under test in the running environment of the program under test. In the response processing route of the program under test, various responses including abnormal responses are verified and tested.

  As shown in FIG. 4, the program under test in the application layer has an interface (service for accessing computer hardware resources) when accessing computer hardware resources (real I / O device 62) such as files and networks. The actual I / O driver 60 of the driver layer is used via the API), but here, between the real I / O driver 60 of the driver layer and the application layer (configured by a program), The pseudo driver 23 (configured by a program) is arranged as a so-called middle layer.

  Normally, I / O processing from the application layer (program under test) is requested to the OS kernel 21 as a system call or the like by an application interface (hereinafter referred to as “API”), and the OS kernel 21 receives the real I / O driver 60. It is realized by passing processing to.

  The pseudo driver 23 is located between the OS kernel 21 and the real I / O driver 60 and is registered as a hook function of the OS kernel 21, so that the pseudo driver 23 immediately passes processing to the real I / O driver 60. Processing will be passed (register as such).

  With this hook function, an I / O processing request from the application layer (program under test) is passed to the pseudo driver 23 immediately before passing to the real I / O driver 60 (instead of the dotted lines R1 and R2 in FIG. Therefore, the subsequent processing follows the processing of the pseudo driver 23.

  That is, the routes indicated by dotted lines R1 and R2 in FIG. 4 are processing routes when the pseudo driver 23 is not hooked, and the routes indicated by solid lines R3 and R4 are processing routes when the pseudo driver 23 is hooked. become. Here, the pseudo driver 23 converts the response from the driver layer into various responses including an abnormal response and responds to the application layer. The program under test performs processing based on various responses including an abnormal response from the pseudo driver 23.

  Note that the response of the pseudo driver 23 can be set by a parameter. Further, since the pseudo driver 23 looks like a normal driver layer when viewed from the application layer, it is not necessary to make any changes to the program under test, so that a test with a normal product version is possible.

  Here, I / O processing basically uses real I / O, and only response values or data are replaced by parameters, so that it is not necessary to develop special I / O drivers or simulator programs. Yes.

§5: Description of Access Table Example and Response Table Example FIG. 5 shows an access table example and a response table example. Hereinafter, an example of an access table and an example of a response table will be described with reference to FIG.

(1): Access table example In the access table example shown in FIG. 5A, each item of access contents (I / O request), data amount (bytes), and replacement execution item number (record) is provided. Data is stored for each item.

  The item of access content (I / O request) is a record of the access content (I / O request) requested to the driver by the program under test. The item of data amount (Byte) is a record of the amount of data requested by the program under test from the driver. The item of the replacement execution item number (record) is a record of the item number on the response table when the access condition of the program under test matches the condition of the response table and the response value is replaced. If there is no replacement, “−” is assumed.

(2): Response table example In the response table example shown in FIG. 5B, each item of item number, condition, replacement response value, replacement execution record, one shot, and delay time range (ms) Is provided, and data is stored for each item. In this case, the condition item is divided into conditions for each item of access contents (I / O request), data amount, and original response value.

  The item of access content (I / O request) is access to the driver, and the tester sets the type of access to be replaced. In the condition item, a condition for replacing the driver response is set by the tester. In the item of the replacement response value, the tester sets a replacement value when the conditions for replacing the response value match.

  The item of replacement execution record is recorded when response value replacement occurs. In the one-shot, when a response value is replaced, the tester sets whether to replace only the first time or to replace it repeatedly thereafter. In the item of the delay time range (ms), the tester sets the response delay time when the response value from the driver is notified to the program under test. Note that “0” is set when returning immediately, and “−” is set when not returning at all.

§6: Detailed description of processing (or operation), etc. Pseudo driver processing (or operation)
Hereinafter, the process (or operation) of the pseudo driver will be described with reference to FIG.

  First, the pseudo driver control unit 31 performs only the function of starting and stopping each module constituting the pseudo driver 23, initializing the work area and the control table, returning at the end of the test, and the conversation function with the tester. So it continues to work during the test. When hardware access is performed from the application layer, the access analysis unit 32 analyzes the access content (I / O request), creates an access table 51, and notifies the scheduler 33.

  The scheduler 33 links the access content (I / O request) from the application layer with the content according to the setting of the tester, and creates the response table 52. When there is a response from the driver layer, a response value from the response analysis unit 35 is obtained, converted into a response value according to the response table 52, and notified to the response generation unit 34.

  Further, according to the response table 52, the abnormal response unit 37, normal response unit 38, not ready unit 39, timeout unit 40, sense data generation unit 41, and abnormal data generation unit 42 are activated to generate response values. Take control.

  The response generation unit 34 responds the generated result to the application layer according to the setting of the response value from the scheduler 33. The response analysis unit 35 analyzes the response from the driver layer and notifies the scheduler 33 of the result. The setting analysis unit 36 analyzes the setting content related to the response value from the tester and notifies the scheduler 33 of the setting content.

2. Explanation of operation until a response value according to the tester's setting is obtained for the access from the application layer. Hereinafter, according to the tester's setting for the access from the application layer, referring to FIG. The operation until a response value is obtained will be described.

  (a): The tester performs an operation of creating the response table 52 at the start of the test. In response to a response (I / O request) from the application layer, a response value to be returned after the access is completed is determined and tabulated.

  (b): Next, start the application and start the test.

  (c): When the application is started, a request for accessing the hardware is issued from the application layer via the driver (real I / O driver 60). The access analysis unit 32 of the pseudo driver 23 analyzes the access contents. The information is stored in the access table 51 and notified to the scheduler 33 at the same time.

  (d): The scheduler 33 indexes the access table 51 and the response table 52 created previously, and prepares the specified response value.

  (e): When the hardware operation is completed and the response value from the driver layer is returned to the response analysis unit 35, the scheduler 33 is notified.

  (f): If there is no problem in the response value from the response analysis unit 35, the scheduler 33 replaces the response value prepared in advance and notifies the response generation unit 34.

  (g): The response generation unit 34 returns the response value instructed from the scheduler 33 to the application layer. With the above operations (a) to (g), a response value according to the setting of the tester is obtained for access from the application layer.

  Here, a tester can prepare a response value that can be generated only at the time of failure as a response value necessary for verifying the operation of the program under test by a tester in advance.

3. Description of Delay Time Range During Processing (or Operation) FIG. 6 is a time chart of a delay processing example. In FIG. 6, A is an I / O request and timeout monitoring of the program under test, B is a pseudo driver delay time process, C is an I / O driver, and D is an I / O time chart. Hereinafter, the delay time range during operation will be described with reference to FIG. In the following description, (1) to (9) are the same as the numbers in FIG.

  The functions described below are for the purpose of testing the effect on the program under test due to the timing of completion of processing of the I / O device, and are mainly abnormal when the I / O response is close to the expected completion time. In this case, it is confirmed whether or not the device functions without any problem in a case assuming a long time (eg, several hours).

  Generally, the program is abnormally terminated by the timeout monitoring process of the program under test. However, in a multitask control type application, the next I / O processing request starts running, which causes a serious problem such that the order of processing results cannot be maintained. There are cases (this test is effective).

  (1): The program under test 22 (application layer) issues an I / O request by a system call and enters time-out monitoring for completion of I / O processing.

  (2): The pseudo driver 23 hooks the I / O request from the program under test 22 and passes the I / O request to the real I / O driver 60 according to the response table 52.

  (3): The real I / O driver 60 starts monitoring the processing of the I / O device 62 after starting the I / O device 62 in accordance with the I / O request from the pseudo driver 23.

  (4): The I / O device 62 notifies the real I / O driver 60 of completion when the requested processing is completed.

  (5): The real I / O driver 60 notifies the pseudo driver 23 that the I / O processing has been completed.

  (6): The pseudo driver 23 notifies the program under test 22 that the processing of the I / O device 62 has been completed, but at this time, notifies it after a time delay according to the “delay time range” of the response table 52.

  (7): The program under test 22 receives a notification of completion of I / O processing from the pseudo driver 23 with a delay corresponding to the “delay time range” of the response table 52.

  (8): The program under test 22 proceeds to the next processing if the processing completion of the I / O device 62 is within the set timeout monitoring time due to delay.

  (9): If the I / O device 62 completes processing due to a delay but the set timeout monitoring time has elapsed, the program under test 22 proceeds to timeout processing.

  When “−1” is set in the “delay time range”, a pseudo response is created without waiting for a response from the I / O device 62, and the response is immediately returned. In this example, the function of the delay time is the completion of the I / O device 62. However, as another diameter, it is also possible to function as a delay of the I / O request from the OS kernel 21. Furthermore, it can also be implemented so that they can be switched.

  As described above, the processing route provided in the program under test 22 can be tested by artificially delaying the completion of the processing of the I / O device 62 by setting the pseudo driver 23 and the response table 52. . Similarly, in the case where the program under test 22 controls a plurality of I / O devices 62 at the same time, a test can be performed by arbitrarily combining the timings of notification of completion of each I / O processing. 22 I / O processing order errors can be tested.

  Further, in the replacement execution item number (record) in the access table 51 shown in FIG. 3, the item number of the response table 52 in the case of access that satisfies the conditions of the response table 52 is recorded. This means that the actual response value has been replaced by the pseudo driver 23, and this is a record of the test (test trace).

  When the test is completed, the access table 51 records all access records (traces) of the program under test 22 and response replacement by the pseudo driver 23. (Test coverage) can be grasped.

§7: Explanation of processing (or operation) by flowchart FIG. 7 is a test processing flowchart (part 1), and FIG. 8 is a test processing flowchart (part 2). Hereinafter, the processing (or operation) will be described with reference to FIGS. 7 and 8, S1 to S18 indicate processing steps.

  First, the operator activates the pseudo driver setting utility, and the operator sets the response table 52 reflecting the test contents (S1). Next, the operator activates the pseudo driver 23 (S2). Then, the pseudo driver 23 hooks an I / O request to the OS kernel 21 (S3). Next, the operator activates the program under test 22 (S4). Then, the program under test 22 issues an I / O request (S5).

  Next, the OS kernel 21 confirms the I / O request with the pseudo driver 23 at the hook destination (S6). As a result, if there is a hook, the OS kernel 21 passes I / O processing to the pseudo driver 23 (S7). Then, it is determined whether or not the access table 51 / response table 52 is set (S8). As a result, if the access table 51 / response table 52 is set, the pseudo driver 23 follows the setting of the response table 52 (S9).

  Next, the pseudo driver 23 traces the contents of the I / O request (S10). Then, the pseudo driver 23 passes the processing to the real I / O driver 60 (S11). Next, the pseudo driver 23 activates the real I / O device 62 in the hardware layer and starts processing (S12). When the processing is completed, the real I / O device 62 responds to the real I / O driver 60 (S13). The real I / O driver 60 monitors the response from the real I / O device 62 in the hardware layer and waits for a response (S14). The response is passed to the pseudo driver 23 (S15).

  Next, the pseudo driver 23 compares the response contents with the contents of the response table 52 and processes the set values in the response table 52 (S16). Then, the operator monitors the completion of the program under test 22 (S17). If the operation is continued, the operation proceeds to S16. If the operation is completed, the operator stops the pseudo driver 23 (S18).

  Further, when there is no hook in the process of S6 and when the access table 51 / response table 52 is not set in the process of S8, the process proceeds to S18. In this way, the process is finished.

§8: Description of main route processing (operation) FIG. 9 is a main route processing flowchart (part 1), and FIG. 10 is a main route processing flowchart (part 2). The main route processing (operation) will be described below with reference to FIGS. The processing of the main route described below is a detailed description of the processing of S16 shown in FIG. 9 and 10, S21 to S35 indicate each processing step.

  In S16 of FIG. 8, the pseudo driver 23 compares the response contents with the contents of the response table 52 and processes the set values in the response table 52. The detailed process is as follows. In this process, the pseudo driver 23 first determines whether or not there is an I / O request from the program under test 22 (S21), and if there is no I / O request from the program under test 22, waits for the request. If there is an I / O request from the program under test 22, the I / O request for the program under test 22 is recorded in the access table 51 by an access analysis process (S 22). Next, the I / O request is passed to the real I / O driver 60 (S23), and it is determined whether or not there is a response from the real I / O driver 60 (S24).

  As a result, if there is no response from the real I / O driver 60, it waits for a response, and if there is a response from the real I / O driver 60, the I / O request content and the real I / O driver 60 It is determined whether or not the response combination condition is in the response table 52 (S25). As a result, if the combination condition of the response from the I / O request and the real I / O driver 60 exists in the response table 52, the corresponding replacement response value is obtained from the response table 52 (S26).

  Next, the corresponding response delay time is obtained from the response table 52 (S27). Then, “execution” is recorded in the corresponding replacement response recording column of the response table 52 (S28). Further, the corresponding “item number” is obtained (S29). Next, the pseudo driver 23 records “item number” in the corresponding replacement item number of the access table 51 (S30). And the response value and data according to the conditions of the response table 52 are produced | generated (S31).

  Next, the scheduler 33 returns a replacement response value to the program under test 22 after the response delay time (S32). Then, the pointer of the access table 51 is updated (S33). Next, it is determined whether or not there is a stop instruction by the operator (S34), and if there is, the access table 51 and the response table 52 are stored in a predetermined storage area (S35).

  If there is no stop instruction from the operator in the process of S34, the process proceeds to S21. If it is determined in the process of S25 that the combination condition of the I / O request content and the response from the real I / O driver 60 is not in the response table 52, the process proceeds to S33. In this way, when the process of S35 ends, this process ends.

§9: Other description The program test method using the program test apparatus (computer) includes the following test methods.

  (1): Tests the validity of various types of response processing (including anomalies) for access to computer hardware resources by the program under test, regarding the operation verification (test method) of the program itself (program under test) running on the computer In this method, operation verification for an arbitrary response process is performed through a computer hardware resource access program (pseudo driver) having various pseudo response generation functions.

  (2): Regarding the operation verification (test method) of the program itself (program under test) that runs on the computer, test the validity of various (including abnormal) response processes for access to computer hardware resources by the program under test In this method, a response timing test equivalent to that in the actual environment is performed by causing the actual I / O to execute the operation, and the response value is given in advance, and any combination of the access condition and the response value is scheduled. Returns the response value of.

§10: Explanation of additional notes The following configuration is added to the above description.

(Appendix 1)
A test apparatus for a program for verifying the validity of various types of response processing to access to computer hardware resources by a program under test when performing operation verification of a program under test operating on a computer,
A pseudo driver that generates various pseudo responses by a function of replacing a normal return value from an interface that services access to computer hardware resources with an arbitrary response value based on a predetermined parameter;
A program test apparatus having a function of performing operation verification for an arbitrary response process via the pseudo driver.

(Appendix 2)
The pseudo driver has a function of replacing a normal response value from an interface that services access to the computer hardware resource with an arbitrary response value after an arbitrary time based on a predetermined schedule,
The program test apparatus according to appendix 1, which has a function of performing operation verification for an arbitrary pseudo response process via the pseudo driver.

(Appendix 3)
The pseudo driver schedules a normal response value from an interface that services access to the computer hardware resource for a combination of access conditions and response values given in advance, and based on the schedule. It has a function to generate various pseudo responses by returning an arbitrary response value,
The program test apparatus according to appendix 1, which performs operation verification for an arbitrary pseudo response process via the pseudo driver.

(Appendix 4)
The pseudo driver schedules a normal return value from an interface that services access to the computer hardware resource for a combination of access conditions and response values given in advance, and based on the schedule. It has a test program test function that returns an arbitrary response value.
The program test apparatus according to appendix 1, wherein the returned response value is recorded by the function of the pseudo driver, and the execution range of the test can be grasped from the recorded response value.

(Appendix 5)
The pseudo driver performs a process test on the same data as the real environment by causing the real I / O to execute an operation, and a response value is given in advance, and a combination of access conditions and response values is scheduled. The program test apparatus according to appendix 1, wherein the operation verification is performed by having a function of returning an arbitrary pseudo response value.

(Appendix 6)
A test method for a test apparatus for a program for verifying the validity of various response processes for accessing a computer hardware resource by a program under test when performing operation verification of a program under test operating on a computer,
Any response via a pseudo driver that generates various pseudo responses by the function of replacing the normal return value from the interface that services access to computer hardware resources with an arbitrary response value based on a predetermined parameter. A test method of a test apparatus for a program for performing operation verification on processing.

(Appendix 7)
An arbitrary pseudo-driver is provided via a pseudo driver having a function of replacing a normal response value from an interface that services access to the computer hardware resource with an arbitrary response value after an arbitrary time based on a predetermined schedule. The test method of a test apparatus for a program according to appendix 6, wherein operation verification for response processing is performed.

(Appendix 8)
A normal response value from an interface that services access to the computer hardware resource is scheduled against a combination of access conditions and response values given in advance, and an arbitrary response value based on the schedule is set. The program test apparatus test method according to appendix 6, wherein operation verification is performed for an arbitrary pseudo-response process via a pseudo driver that generates various pseudo-responses by returning the program.

(Appendix 9)
A normal return value from the interface that services access to the computer hardware resource is scheduled for a combination of access conditions and response values given in advance, and an arbitrary response value is set based on the schedule. The program test apparatus test method according to appendix 6, wherein the returned response value is recorded by a pseudo driver having a test function of the program to be returned, and the execution range of the test can be grasped from the recorded response value.

(Appendix 10)
By causing the real I / O to execute the operation, a test of the processing for the same data as the real environment is performed, and the response value is given in advance, and any pseudo-response value scheduled for a combination of access conditions and response values The test method of a test apparatus for a program according to appendix 6, wherein the operation verification is performed by a pseudo driver having a function of returning.

It is a principle explanatory view of the present invention. 1 is an overall configuration diagram of an apparatus according to an embodiment. It is explanatory drawing of the pseudo driver in embodiment. It is a conceptual explanatory view of a test method in an embodiment. FIG. 4A is an example of an access table and an example of a response table in the embodiment, FIG. It is a time chart of the example of delay processing in an embodiment. It is a test processing flowchart (the 1) in an embodiment. It is a test processing flowchart (the 2) in an embodiment. It is a processing flowchart (the 1) of the main route in an embodiment. It is a processing flowchart (the 2) of the main route in an embodiment.

Explanation of symbols

1 Computer Main Body 2 Input Device 3 Display Device 11 CPU
DESCRIPTION OF SYMBOLS 12 Memory control part 13 I / O control part 14 Communication control part 15 Memory device 21 OS kernel 22 Test program 23 Pseudo driver 31 Pseudo driver control part 32 Access analysis part 33 Scheduler 34 Response generation part 35 Response analysis part 36 Setting analysis part 37 abnormal response unit 38 normal response unit 39 not ready unit 40 timeout unit 41 sense data generation unit 42 abnormal data generation unit 50 memory common area 51 access table 52 response table 53 pseudo driver setting utility 60 driver layer (real I / O driver)
61 I / O port 62 Hardware layer (real I / O device)

Claims (5)

A test apparatus for a program for verifying the validity of various types of response processing to access to computer hardware resources by a program under test when performing operation verification of a program under test operating on a computer,
A pseudo driver that generates various pseudo responses by a function of replacing a normal return value from an interface that services access to computer hardware resources with an arbitrary response value based on a predetermined parameter;
A program test apparatus having a function of performing operation verification for an arbitrary response process via the pseudo driver. The pseudo driver has a function of replacing a normal response value from an interface that services access to the computer hardware resource with an arbitrary response value after an arbitrary time based on a predetermined schedule,
2. The program test apparatus according to claim 1, further comprising a function of performing operation verification for an arbitrary pseudo response process via the pseudo driver. The pseudo driver schedules a normal response value from an interface that services access to the computer hardware resource for a combination of access conditions and response values given in advance, and based on the schedule. It has a function to generate various pseudo responses by returning an arbitrary response value,
The program test apparatus according to claim 1, wherein operation verification for an arbitrary pseudo response process is performed via the pseudo driver. The pseudo driver schedules a normal return value from an interface that services access to the computer hardware resource for a combination of access conditions and response values given in advance, and based on the schedule. It has a test program test function that returns an arbitrary response value.
The program test apparatus according to claim 1, wherein the returned response value is recorded by the function of the pseudo driver, and the test execution range can be grasped from the recorded response value.   The pseudo driver performs a process test on the same data as the real environment by causing the real I / O to execute an operation, and a response value is given in advance, and a combination of access conditions and response values is scheduled. The program test apparatus according to claim 1, wherein the operation verification is performed by having a function of returning an arbitrary pseudo response value.

Images