KR101271232B1 - Software testing device and method thereof - Google Patents

Abstract

The software test apparatus according to the present invention captures the input of the input means performed on the software under test to generate a first test script, and reproduces the generated first test script to perform a test on the software. A first test unit configured to perform a test on the software based on event information of a second test script including a plurality of event information written by a user, and generated by capturing and inputting the input means The hybrid test unit performing a test on the software based on a hybrid test script including a first test script and a second test script including event information, and the first test script according to a user's selection or a test setting value for the software. 1 test section, 2nd frame And a test controller configured to execute one of the test unit and the hybrid test unit to test the software.

Description

SOFTWARE TESTING DEVICE AND METHOD THEREOF}

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

Software is typically developed through requirements, design, implementation, and testing processes. Here, if an error of the corresponding software is found in the test, which is the final stage of the development, the cost of the software development is increased because all the processes of the process from the requirement to the implementation are changed.

If an error occurs in some functions of the software, errors may occur in another function due to the characteristics of the software having an internal structure that is complicatedly interlocked with each other. As a method for solving this, conventionally, a test scenario was created before the implementation of the software and a method of testing the software through a test scenario was used.

Such a software testing method determines that the software is not performing a normal operation when a value that is executed according to a test scenario differs from a predicted value, while the software is being developed. In this case, according to the test scenario, the test is continued while the software is continuously modified until a predicted value is obtained in advance.

However, it took a lot of time to develop a test plan, create test scenarios and test data, and when the user's needs changed during development, there was a problem that all of the test plan and the test data were changed.

Thus, there is a need to test the software more effectively.

In this regard, Korean Patent Laid-Open Publication No. 2005-0109305 (name of the invention: a system and method for monitoring the status of a process equipment) relates to a system and a method for monitoring the status of a process equipment. It provides a system and method for monitoring the status of process equipment that can be accurately detected.

In addition, Korean Patent Laid-Open Publication No. 2002-0063270 (name of the invention: a method for requesting trace data reports from an FDC semiconductor manufacturing process) discloses a method of dynamically generating trace data reports in a semiconductor manufacturing process by employing error detection control. do.

An embodiment of the present invention is an interface that makes it difficult for a user to manually write a test script or tests software operating based on a graphical user interface (GUI), or allows a specific module of the software and a plurality of modules to be integrated and operated. The present invention provides a software test apparatus and method for performing an effective test on a variable and a function definition of each program code.

As a technical means for achieving the above-described technical problem, the software test apparatus of the present invention, by capturing the input of the input means performed for the software to be tested to generate a first test script, the generated first A first test unit for reproducing a test script to test the software, and a second test for testing the software based on event information of a second test script including a plurality of event information written by a user A hybrid test unit and a user for performing a test on the software based on a hybrid test script including a first test script generated by capturing input of the input means and a second test script including event information; Or in the software According to the test set value by executing one of the first testing unit, a second test section and a hybrid test unit comprises a test control unit for performing a test on the software.

According to any one of the problem solving means of the present invention described above, it is difficult for a user to manually write a test script or test software operating based on a GUI (Graphic User Interface), or a specific module of the software, a plurality of modules You can quickly and precisely test the interface that allows them to work together, define variables and functions in each program code, and so on.

In addition, according to any one of the above-described problem solving means of the present invention, it is possible to improve the test efficiency for semiconductor process control software such as Fault Detection and Classification (FDC) and R2R (Run to Run) that requires customization.

1 is a block diagram of a software test apparatus according to an embodiment of the present invention.
2 is a block diagram of a first test unit according to an exemplary embodiment of the present invention.
3 is a block diagram of a second test unit according to an exemplary embodiment of the present invention.
4 is a diagram illustrating a software test method through a first test unit according to an embodiment of the present invention.
5 is a diagram illustrating a test result image before and after a software test according to an embodiment of the present invention.
6 is a diagram illustrating a software test method through a second test unit according to an embodiment of the present invention.
7 is a flowchart of a software test method according to an embodiment of the present invention.
8 is a flowchart illustrating a software test method through a first test unit according to an embodiment of the present invention.
9 is a flowchart illustrating a software test method through a second test unit according to an embodiment of the present invention.
10 is a block diagram of a software test apparatus according to another embodiment of the present invention.
11 is a block diagram of a hybrid test unit according to an embodiment of the present invention.
12 is a flowchart of a software test method through a hybrid test unit according to another exemplary embodiment of the present invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings, which will be readily apparent to those skilled in the art. The present invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. In the drawings, parts irrelevant to the description are omitted in order to clearly describe the present invention, and like reference numerals designate like parts throughout the specification.

Throughout the specification, when a part is referred to as being "connected" to another part, it includes not only "directly connected" but also "electrically connected" with another part in between . Also, when an element is referred to as "comprising ", it means that it can include other elements as well, without departing from the other elements unless specifically stated otherwise.

1 is a block diagram of a software test apparatus according to an embodiment of the present invention.

As shown in FIG. 1, the software test apparatus 100 of the present invention includes a first test unit 110, a second test unit 120, a test control unit 130, a test verification unit 140, and a test result generation. The unit 150 includes a script storage unit 160, a load unit 170, and a data storage unit 180.

The software according to an embodiment of the present invention may include one or more of fault detection and classification (FDC) and run to run (R2R) as semiconductor process control software. FDC process control software is used to control semiconductor equipment and individual processes in semiconductor processes. It analyzes wavelets and checks for defects to improve semiconductor production yield and productivity and reduce defect rates.

The R2R process control software is designed to stabilize the semiconductor process control process and minimize the impact of disturbances, and can be flexibly customized according to the engineer's requirements. In this case, the test efficiency of the semiconductor process control software requiring customization can be improved through the software test apparatus 100 of the present invention.

The software test apparatus 100 of the present invention is not limited to the above-described semiconductor process control software, and software for testing or implementing software operating in various industrial fields such as mobile phones, computers, imaging devices, home appliances, and personal portable devices. It can be used to test. Hereinafter, each component of the software test apparatus 100 will be described in detail.

The first test unit 110 captures (or records) input of the input means performed on the software to be tested to generate a first test script, and plays back or replays the generated first test script. Test the software. For example, the first test unit 110 may be used to test software that is difficult for a user to manually write a test script or operates based on a graphical user interface (GUI).

The input means described above may include one or more of a mouse, a touch pad, and a keyboard. In addition, an interface may be provided for the user to perform input through the input means to the software. A detailed configuration of the first test unit 110 will be described with reference to FIG. 2.

The second test unit 120 generates a second test script including a plurality of event information, and performs a test on software based on the generated event information of the second test script. Here, an interface may be provided so that a user may input or modify event information.

The second test unit 120 may be used when a fast and precise test is required for a specific module of software, an interface for allowing a plurality of modules to be integrated, and operation of variable and function definition of each program code. A more detailed description of the configuration of the second test unit 120 will be described with reference to FIG. 3.

The test control unit 130 executes any one of the first test unit 110 and the second test unit 120 according to the user's selection or the test setting value for the software and controls the test for the software. Here, the test controller 130 may execute any one of the first test unit 110 and the second test unit 120 according to the user's selection. In addition, the test controller 130 may execute any one of the first test unit 110 and the second test unit 120 according to the test set value.

In this case, the test controller 130 may sequentially execute the first test unit 110 and the second test unit 120 one by one according to the test set value. For example, after the test on the first test unit 110 is completed, the test controller 130 may execute the second test unit 120 according to the verification result.

More specifically, the test control unit 130 performs a test on the software through the first test unit 110 according to the test set value, the specific module of the software through the test verification unit 140 is abnormal If it is determined, the second test unit 120 may be executed to perform a more precise test on the corresponding module.

In this case, the test control unit 130 provides the user with event information necessary to perform a test on a specific module of the software in which an error occurs in the form of a check list, or automatically transfers it to the second test unit 120 to perform a second test. You can have a script generated.

In addition, the test controller 130 repeatedly executes one of the first test unit 110 and the second test unit 120 a predetermined number of times according to a predetermined test rate according to the test set value to perform a test on the software. This can increase the reliability of software tests. As such, by executing the first test unit 110 and the second test unit 120 having characteristics, respectively, according to a user's selection or test setting value, an automated test for more precise and reliable software can be performed. have.

The test verification unit 140 may determine whether the software is normal based on the test result data of the software on which the test is performed according to one of the first test unit 110 and the second test unit 120. Perform verification. Here, the test verifier 140 may include the image verifier 118 of FIG. 2 and the event verifier 126 of FIG. 3. In addition, the test verifier 140 may be implemented as the image verifier 118 and the event verifier 126, respectively, and included in the first test unit 110 and the second test unit 120.

The test result generator 150 evaluates the test result data of the software on which the test is performed according to the execution of any one of the first test unit 110 and the second test unit 120 and the verification result of the software based on the test result. Generate as a report. For example, the test result generator 150 may create an evaluation report in the form of extensible markup language (XML), HyperText Markup Language (HTML), or the like. Here, the information about the test date and time, the test time required, the object passing the test, the response time, the throughput, the processing speed, the utilization, etc. may be included in the evaluation report.

The script storage unit 160 stores one or more of the first test script and the second test script as a file. Here, the first test script and the second test script may be written in a markup language. For example, one or more of the first test script and the second test script may be written in an extensible markup language (XML) language among markup languages.

The load unit 170 loads the storage files of the first test script and the second test script under the control of the test control unit 130, so that a test of the software is performed. For example, when the first test unit 110 is executed, a previously written first test script may be loaded. At this time, it is possible to test the software by reusing the pre-written test script, thereby reducing the time cost of writing the test script.

The data storage unit 180 stores algorithms, setting values, and various other information for performing and verifying software tests. For example, information about a test set value, event information, test data, test speed, test repetition count, test result data, and verification result data may be stored.

2 is a block diagram of a first test unit according to an exemplary embodiment of the present invention.

As illustrated in FIG. 2, the first test unit 110 may include a first test script generator 112, a first test script execution unit 114, an image generator 116, and an image verifier 118. Include.

The first test script generation unit 112 captures the input of the input means performed on the software and generates the first test script. Here, input through a mouse, keyboard, touch pad, etc. may be captured and generated as a first test script. For example, if the user has made an input (click, drag, etc.) through a mouse or keyboard to a GUI component (or control) of the software, a capture of this is performed and the first based on the captured value. Test scripts can be generated.

At this time, the test data may be generated together according to the attribute value of the GUI component selected by the user. For example, when the GUI component is a module that adjusts the rotational speed and angle of the device in a semiconductor process control process, test data related to the rotational speed and angle control may be automatically generated to correspond to the module.

The first test script execution unit 114 performs a test on the software by playing back or replaying the first test script. At this time, the test may be repeatedly performed according to the set value.

The image generator 116 generates a first image based on a difference between a test result image of the software before capturing the input of the input means and a test result image of the software when capturing the input of the input means. . In addition, the image generator 116 generates a second image based on a difference between a test result image of the software before playing the first test script and a test result image of the software after playing the first test script. do.

Here, the image generator 116 may generate the first image and the second image through the screen captured by the user, or may automatically process the test result data for the corresponding software as an image file. For example, in the case of software for performing semiconductor process control for outputting test result data in a graph form, a graph image may be generated as test result data.

The image verifier 118 compares the difference between the first image and the second image and performs verification to determine whether the software is normal. For example, in the case of the software for performing the above-described semiconductor process control, since a graph image is generated as test result data, the image verification unit 118 reproduces the first image and the first test script when capturing the input of the input means. Verification to determine whether the software is normal by comparing the difference between the second image generated according to the.

If the difference between the first image and the second image does not exceed the set reference value, the image verifying unit 118 may determine that the corresponding software is normal, and if not, may determine that it is abnormal. The determined result data may be transferred to the test result generator 150 and used to prepare an evaluation report.

3 is a block diagram of a second test unit according to an exemplary embodiment of the present invention.

As shown in FIG. 3, the second test unit 120 includes a second test script generation unit 122, a second test script execution unit 124, and an event verification unit 126.

The second test script generation unit 122 generates a second test script including a plurality of event information created by the user. For example, the event information can include information for testing a particular module of software. Here, the user may directly input the event information through the interface or select the event information to be tested to create a plurality of event information.

In addition, when basic event information is set in advance, a user may add or delete event information through a corresponding interface. Thereafter, the second test script generation unit 122 may generate the second test script by parsing event information input or selected by the user.

The second test script execution unit 124 performs a test on software based on the second test script. In this case, when the test for the software is performed according to the event information of the second test script, test data corresponding to the corresponding event information may be provided together to test the specific test data. Such test data may be input by a user or automatically generated according to event information selected through an interface.

The event verification unit 126 receives the test result data from the software on which the test is performed according to the event information included in the second test script, and compares the test result data with the expected result data generated based on the corresponding event information. Perform verification to determine whether the software is normal.

4 is a diagram illustrating a software test method through a first test unit according to an embodiment of the present invention.

As illustrated in FIG. 4, the user may perform a software test through the first test unit 110 through the interface 400. In this case, the user may set each value for performing the test, and if the basic values are set in advance, the user may modify the value and proceed with the software test. Hereinafter, this will be described in more detail.

First, the user can click the capture button 412 to capture the input of the input means performed on the software under test. At this time, input through the mouse is captured and displayed in the mouse capture area 402, and input through the keyboard is captured and displayed in the keyboard capture area 404.

Next, the user clicks the save script button 413 to generate and store the first test script based on the value of capturing the input of the input means. At this time, the script load button 414 may be clicked to load the pre-stored first test script. Here, the first test script may be automatically generated when the corresponding software is built, and the capture through the input of the input means is performed, and if there is a previously stored first test script, the first test script is automatically checked and the first stored test script is automatically stored. You can also load test scripts. Then, the content related to the generated first test script is displayed in the script display area 426.

Next, the number of test repetitions for the corresponding software is set by clicking the test repetition number setting button 409 and the test rate is set by clicking the test rate setting button 410. Next, when play button 416 is clicked, the first test script is played to test the software.

The user then clicks the capture button 418 to generate a test result image for the software. Here, the test result image may be automatically generated when the test for the software is completed.

5 is a diagram illustrating a test result image before and after a software test according to an embodiment of the present invention.

In the following description, Fig. 5A shows a test result image of the corresponding software before capturing the input of the input means. At this time, since the input of the input means is not captured, the test result image does not appear. 5B shows a test result image of the software after capturing the input of the input means.

In this case, the images of FIGS. 5A and 5B may be generated through screen capture when the capture button 418 is clicked on the test result data or automatically generated when the test is completed. 5C illustrates a first image generated based on a difference between the graph image of (a) and the graph image of (b).

As such, the first image may be generated based on a difference between the test result image of the software before capturing the input of the input means and the test result image of the software after the input of the input means.

In addition, the second image may be generated based on a difference between a test result image of the software before playing the first test script and a test result image of the software after playing the first test script.

4 again, the user clicks the image load button 422 to load test result images (see images of FIGS. 5A and 5B) generated before and after the test of the software, respectively. When the comparison button 424 is clicked on, a difference comparison between the loaded images is performed, thereby generating a first image (see FIG. 5C) or a second image. Here, a name for each loaded image may be displayed in the image generation area 406.

When a comparison is finally made between the first image and the second image through the image load button 422 and the compare button 424, the verification result of the software is transmitted to the test result area 408 based on the comparison result value. Can be displayed. In more detail, the test result region 408 may include information about a test step, a test image, a test result, a pixel expected to be an error, and the like.

By capturing the screen several times in the above-described process and extracting only the portion where the content to be tested is changed, the image generated by playing the test script and the image generated in advance through the capture is generated because the specific portion (GUI) is changed. The difference prevents the verification result from appearing as an error.

6A and 6B illustrate a software test method through a second test unit according to an exemplary embodiment of the present invention.

As shown in FIG. 6A, a user may input a plurality of event information to generate a second test script 502. Here, the user may input event information for testing the software through the interface or may modify the previously input event information. In this case, the interface may be provided in the form of a check list for selecting necessary event information among the event information. Thereafter, the event information is transmitted to the software according to each step of the test scenario included in the second test script 502, and the test is performed.

As illustrated in FIG. 6B, the event information included in the second test script 502 may be sequentially transmitted to the software according to the test scenario 504 to test whether the function of the specific module of the software is normal. . When the test for the software is completed according to the event information of the second test script 502, the test result data is displayed in the test result area 408 described above.

7 is a flowchart of a software test method according to an embodiment of the present invention.

As shown in FIG. 7, one of the first test unit 110 and the second test unit 120 is first executed according to a user's selection or a test setting value for the test target software (S701). For example, a user may select one of the first test unit 110 and the second test unit 120 through an interface through which one of the first test unit 110 and the second test unit 120 can be selected. Can be run. In this case, when a test set value for any one of the first test unit 110 and the second test unit 120 is set, any one of the first test unit 110 and the second test unit 120 is accordingly set. One can be executed.

Next, the software test is performed according to the execution of any one of the first test unit 110 and the second test unit 120 (S711). Here, a process of performing a test on software according to the execution of the first test unit 110 will be described in detail with reference to FIG. 8. In addition, a process of performing a test for the software according to the execution of the second test unit 120 will be described in detail with reference to FIG. 9.

Next, based on the test result data of the software on which the test is performed, verification is performed to determine whether the software is normal (S721). At this time, an evaluation report may be created to inform the user of the verification result.

8 is a flowchart illustrating a software test method through a first test unit according to an embodiment of the present invention.

As shown in FIG. 8, first, an input of an input means performed on the software under test is captured (S801).

Next, a first image is generated based on a difference between a test result image of software before capturing the input of the input means and a test result image of software after capturing the input of the input means (S811). This step (S811) is for determining whether the software is normal, and may be omitted when simply testing the software. The first image may be generated by the user clicking the screen capture button, or may be generated together with the completion button operation after capturing the input of the input means by the user.

Next, a first test script is generated based on the value of capturing the input of the input means (S821). Here, if there is a previously stored first test script, the first test script may be loaded.

Next, the first test script is reproduced to test the software (S831).

Next, a second image is generated based on a difference between a test result image of software before playing the first test script and a test result image of software after playing the first test script (S841).

Next, by comparing the difference between the first image and the second image, verification is performed to determine whether the software is normal (S851). At this time, when the difference between the first image and the second image is within the reference value range, it is determined that the test result of the corresponding software is normal.

9 is a flowchart illustrating a software test method through a second test unit according to an embodiment of the present invention.

As shown in FIG. 9, first, a second test script including a plurality of event information input by a user is generated (S901). Here, if there is a previously stored second test script, the second test script may be loaded.

Next, a test of the software is performed based on the event information of the second test script (S911).

Next, the test result data is received from the software on which the test is performed according to the event information included in the second test script (S921).

Next, the test result data is compared with the predicted result data previously generated according to the event information, and verification for determining whether the software is normal is performed (S931). If the result of comparing the test result data with the previously generated expected result data is within the reference range, the test result of the corresponding software is determined to be normal.

Meanwhile, each component illustrated in FIGS. 1 to 3 may be configured as a kind of 'module'. The term 'module' refers to a hardware component such as software or a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC), and the module performs certain roles. However, a module is not limited to software or hardware. A module may be configured to reside on an addressable storage medium and may be configured to execute one or more processors. The functionality provided by the components and modules may be combined into a smaller number of components and modules or further separated into additional components and modules.

The above-described script storage unit 160 and data storage unit 180 may include a cache, a read only memory (ROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), and a flash memory (Flash). It may be implemented as at least one of a nonvolatile memory device such as a memory, or a volatile memory device such as a random access memory (RAM), or a storage medium such as a hard disk drive (HDD) or a CD-ROM. Do not.

10 is a block diagram of a software test apparatus according to another embodiment of the present invention.

The overall configuration is almost the same as the test apparatus of FIG. 1, the hybrid test unit 190 is added, and the configuration of the test control unit 130 is somewhat different.

First, the test controller 130 executes any one of the first test unit 110, the second test unit 120, and the hybrid test unit 190 according to a user's selection, test setting values for software, and the like. Control the test.

When performing a test based on the second test unit 120 that performs a test based on an event, a second function is required if a function (such as a button not recognized or a custom pattern) that cannot be expressed as an event is required in the middle of the test. It is difficult to use only the test unit 120. In order to solve this problem, it is necessary to perform a test based on a test method of the first test unit 110 that performs a test based on capture and playback.

Thus, when the hybrid test is required based on the content of the test, the test controller 130 allows the test to be performed through the hybrid test unit 190.

The hybrid tester 190 performs a test based on a hybrid test script that mixes a first test based on capture and playback and a second test based on an event.

11 is a block diagram of a hybrid test unit according to an embodiment of the present invention.

The hybrid test unit 190 includes a first test script generation unit 192, a second test script generation unit 194, a hybrid test script execution unit 196, and a verification unit 198.

The first test script generation unit 192 captures the input of the input means performed on the software and generates the first test script. Here, input through a mouse, keyboard, touch pad, etc. may be captured and generated as a first test script. For example, if the user has made an input (click, drag, etc.) through a mouse or keyboard to a GUI component (or control) of the software, a capture of this is performed and the first based on the captured value. Test scripts can be generated.

At this time, the test data may be generated together according to the attribute value of the GUI component selected by the user. For example, when the GUI component is a module that adjusts the rotational speed and angle of the device in a semiconductor process control process, test data related to the rotational speed and angle control may be automatically generated to correspond to the module.

The second test script generation unit 194 generates a second test script including a plurality of event information created by the user. For example, the event information can include information for testing a particular module of software. Here, the user may directly input the event information through the interface or select the event information to be tested to create a plurality of event information.

In addition, when basic event information is set in advance, a user may add or delete event information through a corresponding interface. Thereafter, the second test script generation unit 194 may generate the second test script by parsing event information input or selected by the user.

The hybrid test script execution unit 196 combines the first test script generated by the first test script generator 192 and the second test script generated by the second test script generator 194 to execute in a hybrid mode. . In this case, the test script delivered to the hybrid test script execution unit 196 is a mixture of the first test script and the second test script, and according to the configuration, the first test and the second test are mixed in one test process. Can be run.

The hybrid test script execution unit 196 performs a test on the software by playing back or replaying the first test script when the first test script exists. At this time, the test may be repeatedly performed according to the set value. In addition, if there is a second test script, the software is tested based on the second test script. In this case, when the test for the software is performed according to the event information of the second test script, test data corresponding to the corresponding event information may be provided together to test the specific test data.

The verification unit 198 performs verification to determine whether the software is normal based on the test script execution result. As with the image verification unit 118 described above with reference to FIG. 2, the first test script performs verification to determine whether the software is normal by comparing differences between the first image and the second image. For example, in the case of the software for performing the above-described semiconductor process control, since the graph image is generated as the test result data, the verification unit 198 is used to reproduce the first image and the first test script when capturing the input of the input means. The verification is performed to determine whether the software is normal by comparing the differences of the second image generated accordingly.

If the difference between the first image and the second image does not exceed the set reference value, the verification unit 198 may determine that the corresponding software is normal, and if not, may determine that it is abnormal.

In addition, similar to the event verification unit 128, the second test script receives the test result data from the software on which the test is performed according to the event information included in the second test script, and based on the event information. Verification is performed to determine whether the software is normal by comparing with the expected result data.

12 is a flowchart of a software test method through a hybrid test unit according to another exemplary embodiment of the present invention.

First, a test condition set by a user is analyzed (S1210), and a determination is made as to whether a hybrid test is required (S1220). For example, if the test condition is analyzed through the test control unit 120 and a function that cannot be performed by the event-based test (a button is not recognized, a custom pattern, etc.) is required in the middle of the test, the hybrid test is performed. Do it.

If it is determined that the hybrid test is not necessary, the first test or the second test is selectively executed according to the above description (S1240).

However, when it is determined that a hybrid test is necessary, the hybrid test unit 190 executes a hybrid test in which the first test and the second test are mixed (S1230).

One embodiment of the present invention may also be embodied in the form of a recording medium including instructions executable by a computer, such as program modules, being executed by a computer. Computer readable media can be any available media that can be accessed by a computer and includes both volatile and nonvolatile media, removable and non-removable media. In addition, the computer-readable medium may include both computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Communication media typically includes any information delivery media, including computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave, or other transport mechanism.

While the methods and systems of the present invention have been described in connection with specific embodiments, some or all of those elements or operations may be implemented using a computer system having a general purpose hardware architecture.

The foregoing description of the present invention is intended for illustration, and it will be understood by those skilled in the art that the present invention may be easily modified in other specific forms without changing the technical spirit or essential features of the present invention. will be. It is therefore to be understood that the above-described embodiments are illustrative in all aspects and not restrictive. For example, each component described as a single entity may be distributed and implemented, and components described as being distributed may also be implemented in a combined form.

The scope of the present invention is shown by the following claims rather than the above description, and all changes or modifications derived from the meaning and scope of the claims and their equivalents should be construed as being included in the scope of the present invention. do.

110: first test unit 120: second test unit
130: test control unit 140: test verification unit
150: test result generation unit 160: script generation unit
170: load unit 180: data storage unit
190: hybrid test unit

Claims (5)

In the software test apparatus,
A first test unit which captures an input of an input means performed on a test target software to generate a first test script, and reproduces the generated first test script to perform a test on the software;
A second test unit configured to test the software based on event information of a second test script including a plurality of event information written by a user;
A hybrid test unit configured to perform a test on the software based on a hybrid test script including a first test script generated by capturing an input of the input means and a second test script including event information;
And a test control unit configured to execute one of the first test unit, the second test unit, and the hybrid test unit according to a user's selection or a test setting value of the software to perform a test on the software.
The first test unit
Generating a first image based on a difference between comparing test result images of the software before and after capturing the input of the input means,
An image generator for generating a second image based on a difference between the test result images of the software before and after playing the first test script;
And an image verification unit which compares the difference between the first image and the second image and performs verification to determine whether the software is normal.
The method of claim 1,
The hybrid test unit
A first test script generation unit for capturing an input of the input means to generate a first test script;
A second test script generation unit generating a second test script based on a plurality of event information created by a user;
And a hybrid test script execution unit configured to execute a hybrid test script including the first test script and the second test script.
The method of claim 1,
A script storage unit for storing one or more of the generated first test script, second test script, and hybrid script as a file;
And a load unit configured to load the stored file under the control of the test controller to perform a test on the software.
The method of claim 1,
The test control unit
As a result of performing a test on the software through the first test unit according to the test set value, when a specific module of the corresponding software is determined to be abnormal, a second test unit is executed to perform a more precise test on the corresponding module. Software test device.
5. The method according to any one of claims 1 to 4,
Wherein the software is semiconductor process control software, the software test apparatus comprising one or more of Fault Detection and Classification (FDC) and Run to Run (R2R).

Images