JP2018055190A - Test process management system, test process management method, and test process management program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a test process management system, a test process management method, and a test process management program for efficiently performing a test in a test object system.SOLUTION: A client tool acquires a flow pass pattern in which a flow pass pattern is generated by a FDL generation tool which defines a flow of commodity service constituting a transaction service S1-1, and generates a commodity service string by arranging all commodity services included in the flow pass pattern. In the commodity service string for each flow pass pattern, a flow pass pattern table sheet for displaying the presence or absence of the commodity service included in the flow pass pattern is generated S1-2. In the flow pass pattern table sheet, the flow pass pattern necessary for the test is acquired S1-3, and a test case is generated for each flow pass pattern S1-4, and a telegraphic message used for each test case is outputted S1-5.SELECTED DRAWING: Figure 3

Description

  The present invention relates to a test process management system, a test process management method, and a test process management program for performing a test in a test target system.

  When building a system, various tests are performed. These tests include, for example, a unit test for testing each module, an integration test for performing a test in a state where the modules are combined, an acceptance test by a user, and an operation test for performing a test in a production environment.

  Then, in a system composed of a plurality of modules, an integration test system for efficiently performing an integration test by reducing the burden at the time of performing a test has been studied (see, for example, Patent Document 1). . In the technology described in this document, a general-purpose driver generated by processing a common control module that performs necessary common control processing in the application execution environment is used to verify the module name obtained from the external interface after executing the common control processing. Call the module. This verification module calls the individual business module to be tested after initial setting of the database (DB). The individual business module executes individual business processing using test data and DB setting values in the same test environment as the application execution environment. The verification module that acquired the output value from the individual business module verifies the output result.

  Moreover, in one transaction service, a plurality of individual processes (product services) may be performed in combination. For example, in a transaction service for purchasing securities using account balances, account balance management and securities sales product services are used. In view of this, a cooperative processing management system for supporting the handling of errors that occur in some processes when a plurality of processes are executed in cooperation has been studied (for example, see Patent Document 2). In the technology described in this document, the control unit of the transaction common system transmits a processing request message generated based on the transaction message received from the transaction terminal to the service management server, and receives the processing result message. If an error is determined in the processing result message, the error is registered, the detour setting is performed, and the processing request message is transmitted again, so that the transaction process is continued until all the individual processes are completed. When all the individual processes are completed, if an error is registered, the executed process is canceled. Then, all errors that occur in the transaction process are collectively output at the transaction terminal, and the approval process is performed at the approval terminal.

JP 2011-186696 A JP 2013-246753 A

  In the cooperation process performed by combining a plurality of individual processes, the necessary individual processes differ depending on various conditions of the transaction service. Therefore, in the test related to the cooperation processing, it is necessary to verify the cooperation processing (flow path pattern) for performing the necessary individual processing based on various conditions. However, there are a variety of combinations of various conditions, and it takes time to create a message to be used for testing in consideration of these. In particular, when a plurality of individual processes are linked, it is necessary to consider a message layout for each individual process.

  The present invention has been made to solve the above-described problem, and provides a test process management system, a test process management method, and a test process management program for efficiently performing a test in a test target system. .

  The test process management system that solves the above problem includes a control unit that manages the test process in the test target system. And the said control part acquires the flow path pattern produced | generated in the flow definition production | generation tool which defines the flow of the product service which comprises a transaction service, The product service sequence which arranged all the product services contained in the said flow path pattern is arranged. Generate a flow path pattern list that displays the presence or absence of the product service included in the flow path pattern in the product service column for each flow path pattern, and obtain a flow path pattern that needs to be tested in the flow path pattern list Then, a test case is generated for each flow path pattern, and a message used in each test case is output. Thereby, the message used in the flow path pattern to be tested can be efficiently created.

  In the test process management system, the control unit acquires a set value and an expected value of each item of each message used in each test case, and executes the test using each message, thereby acquiring the response It is preferable that the item value of the message is acquired and the comparison result with the expected value is output to the test case description for each test case. Thereby, verification can be performed efficiently.

  In the test process management system, it is preferable that the flow path pattern list that is usable and the flow path pattern that cannot be used are distinguished and output based on conditions used in the product service. In a combination of various conditions used in the product service, a flow path pattern that does not actually occur may be generated, but the test target can be efficiently identified using the usable flow path pattern.

  According to the present invention, a test can be efficiently performed in a test target system.

The system schematic of this embodiment. The system schematic in the FDL verification of this embodiment. Explanatory drawing of the FDL verification flow of this embodiment. Explanatory drawing of each sheet | seat in the FDL verification of this embodiment. Explanatory drawing of the flow path pattern table | surface sheet | seat in the FDL verification of this embodiment. Explanatory drawing of the message | telegram data specification in the FDL verification of this embodiment. Explanatory drawing of the message | telegram setting sheet in the FDL verification of this embodiment.

  DESCRIPTION OF EMBODIMENTS Hereinafter, embodiments embodying the present invention will be described with reference to FIGS. Here, when testing a transaction system that manages transactions with customers, product service verification, FDL verification, and transaction service verification are performed. In this embodiment, FDL verification will be described. In a transaction service for realizing a transaction, one or more product services may be used. In this case, in order to use these product services, test the flow definition described in FDL (FlowMark Definition Language) for calling (data transfer) / transmission / transmission of messages, editing of transaction response messages based on response results, etc. Is called FDL verification.

(Outline of trading system)
The outline | summary of the transaction system used for a test is demonstrated using FIG. The transaction system to be tested is composed of a channel 10, main HUBs 20 and 40, a transaction common system 30, and a product layer 50. The main HUBs 20 and 40 are computer systems that relay electronic messages, and are configured by a first hierarchy and a second hierarchy, respectively. In this embodiment, the transaction common system 30, the main HUB 40, and the product layer 50 are test targets.

Channel 10 is a system that accepts transactions with customers, such as store terminals, storefront terminals, automatic teller machines (ATMs), and Internet banking servers.
The main HUB 20 is a computer system (front connection system) that relays a request message acquired from the channel 10 to the transaction common system 30 and returns a response message acquired from the transaction common system 30 to the channel 10.

  The transaction common system 30 is a computer system that manages processes (common tasks) that are commonly performed in transactions with customers. This common transaction system is composed of a mainframe (first platform), and common business includes, for example, management of transaction mains, bank accounts, liquid deposits, domestic exchange, CIF (customer number), fees, etc. .

  The main HUB 40 is a computer system (back-end connection system) that relays the request message acquired from the transaction common system 30 to the product layer 50 and returns the response message acquired from the product layer 50 to the transaction common system 30.

  The product layer 50 is a computer system that manages each product provided by a financial institution. The product layer 50 includes a plurality of open environment systems provided from different system providers. For example, in the open environment system 50a that is the second platform, product services used in financing, foreign exchange, trust, and the like are managed. The open environment system 50b, which is the third platform, manages product services used for time deposits and the like.

In this embodiment, a client terminal T1 and a test management server T2 are used for testing.
The client terminal T1 is a computer terminal used by a person in charge of the test, and includes a control unit, an input unit including a keyboard and a pointing device, and an output unit including a display.

  Further, the client terminal T1 activates the client tool T11 in the control unit. The client tool T11 is a user interface for using the test process management system, and information related to test contents is set by a tester. For this reason, the client tool T11 holds the message layout information of the input message. In the message layout information, items set in the input message, the request message, and the response message are set. The client tool T11 acquires and outputs the verification result of each test.

  In the client tool T11, a test case necessary for FDL verification is set. Then, the client tool T11 controls a scenario control shell T21 and a control shell T3, which will be described later, based on a test case set as a test target. Further, when operating the database of the product layer 50, the local shell T6 is used.

  The test management server T2 is a computer system that controls test cases set by the client tool T11. The test management server T2 includes a scenario control shell T21, a repository T24, and the like. Further, the test management server T2 includes a test result storage unit (not shown) that stores the test result at the time of transaction service verification in association with information (test case ID) for specifying the test case.

  Further, the client tool T11 is connected to the FDL server T4. The FDL server T4 includes an FDL generation tool T40. The FDL generation tool T40 is a functional unit (flow definition generation tool) that generates a flow path pattern. The FDL generation tool T40 generates a flow path pattern using the flow definition, mapping definition, and service interface information. Here, the flow definition is information that defines a flow (order) of product services to be used for each transaction service. Mapping definition is used to transfer transaction service request message item values to product service request message items, product service response message item values to other product service request message items, etc. Definition (item association).

  The scenario control shell T21 functions as a verification unit and controls execution of FDL verification and the like according to a test case created by the client tool T11 of the client terminal T1. As will be described later, the test case also executes processing associated with verification of DB data preparation and evidence acquisition (DB pre- and post-inquiry, message, transaction log acquisition, acquisition data shaping, etc.).

  The repository T24 is a storage unit that temporarily stores a telegram generated by a keystroke at a store terminal, an automatic teller machine (ATM), or the like.

  The control shell T3 is an interface function unit for the test management server T2 of the transaction common system 30. The control shell T3 relays a request from the test management server T2 to the transaction common system 30. The control shell T3 implements sub-functions such as test case execution and stack table redirection in response to a request from the test management server T2.

  In the FDL verification, various drivers and stubs are provided in the transaction common system 30. In the present embodiment, functional units necessary for the test, such as the client tool T11, various shells, various drivers, various stubs, and the like are collectively referred to as a test process management system. Details of various drivers and various stubs will be described later.

(FDL verification)
Next, FDL verification will be described with reference to FIG. In this case, the HUB connect 31, the transaction main 33, the MDF 34, and the HUB connect 36 in the transaction common system 30 are used. In the FDL verification, a request message and a response message transmitted / received in the MDF 34 of the transaction common system 30 are to be verified.

The HUB connect 31 is a functional unit that is connected to the main HUB 20 in the transaction common system 30 and manages the transfer of messages.
The transaction main 33 specifies a business component 35 that needs to be processed in the common business, transmits a request message to each business component 35, and acquires a response message from the business component 35.

The HUB connect 36 is a functional unit that is connected to the main HUB 40 in the transaction common system 30 and manages the transfer of electronic messages.
The MDF 34 is a functional unit that performs message distribution, cooperation between a plurality of systems, and message conversion required when a plurality of systems corresponding to product services are integrated.

  In the transaction common system 30, one or more product services for realizing a transaction are used for each transaction service corresponding to each transaction. For this reason, in this MDF 34, the calling (data transfer) / transmission / reception of the product service request message and the editing of the transaction response message based on the response result are registered in advance as a flow definition (FDL) in advance for each transaction.

Further, an MQ driver 60, an AFE simulator 61, a product service stub 62, an MQ stub 63, and an ICAL stub 64 are used for testing.
The MQ driver 60 simulates the operation of the channel 10 and the main HUB 20, transmits a request message to the HUB connect 31, and receives a response message (temporary upper layer module for testing). It is.

  The AFE simulator 61 executes a process of transferring a request message from the HUB connect 31 to the transaction main 33 and transferring a response message from the transaction main 33 to the HUB connect 31.

  The product service stub 62 is a stub (temporary lower layer module for testing) of the business component 35 in the transaction common system 30 in the FDL verification. The product service stub 62 receives the request message from the MDF 34 and returns a response message.

The MQ stub 63 is a stub that simulates the operations of the main HUB 40 and the product layer 50 and transmits / receives request messages and response messages to / from the HUB connect 36.
The ICAL stub 64 is a stub that calls IMS (registered trademark), which is a hierarchical DB, from the MDF 34.

  At the time of FDL verification, the MQ driver 60 is connected to the HUB connect 31. Then, a transaction service request message is input from the MQ driver 60 to the HUB connect 31. This transaction service request message is transmitted to the test target MDF 34 via the AFE simulator 61 and the transaction main 33.

  In this case, the MDF 34 calls the merchandise service request message based on the flow definition and transmits it to the MQ stub 63 and the ICAL stub 64 via the merchandise service stub 62 and the HUB connect 36. The MDF 34 receives the product service response message from the MQ stub 63 and the ICAL stub 64 via the product service stub 62 and the HUB connect 36. Further, the MDF 34 returns a transaction service response message to the MQ driver 60 via the transaction main 33, the AFE simulator 61, and the HUB connect 31 when each product service is terminated. In this case, the transaction common system 30 captures each product service request message, product service response message, and transaction service response message for the input transaction service request message, and stores them in the test result storage unit.

  The client tool T11 compares and verifies the captured response message with the expected value, and displays the verification result on the display of the client terminal T1. If it is confirmed that the verification result matches the expected value, the test is terminated. On the other hand, when the verification result is different from the expected value, the tester visually confirms the different value.

(Flow in FDL verification)
Next, the flow in FDL verification will be described with reference to FIG.
First, the flow path pattern generation process is executed using the FDL generation tool T40 (step S1-1). Specifically, the test management server T2 prepares the flow definition, mapping definition, and service interface information. Then, the FDL generation tool T40 generates a flow path pattern (product service sequence) using the flow definition, mapping definition, and service interface information. Here, a flow path pattern covering all branches in the transaction service flow is generated.

Furthermore, since the generated flow path pattern includes a flow path pattern that does not actually pass, the FDL generation tool T40 classifies unnecessary flow path patterns.
Specifically, a meaningful flow path pattern is classified by rearranging the branch conditions in a predetermined order and nesting them in that order. For example, assume that there is a branch that determines “message item a> 10”, “message item a> 9”, “message item a> 8”, “message item a> 7”, and “message item a ≦ 7”. To do. When all branches (determinants) are combined, 16 flow path patterns are generated. Therefore, the message values are rearranged in ascending order, and “message item a ≦ 7”, “message item a> 7”, “message item a> 8”, “message item a> 9”, “message item a> 10”. Can be narrowed down to five flow path patterns.

  In addition, a meaningful flow path pattern is classified by using a multi-branch condition. For example, “message item b = 10”, “message item b = 9”, “message item b = 8”, “message item b = 7”, and “message item b ≠ 7, 8, 9, 10” are determined. Assume that there is a branch. Also in this case, when all branches (determinants) are combined, 16 flow path patterns are generated. Therefore, a single multiple branch “message item b = 7”, “message item b = 8”, “message item b = 9”, “message item b = 10”, “message item b ≠ 7” using item values. , 8, 9, 10 "can be narrowed down to five flow path patterns.

Then, by analysis, a meaningful flow path pattern is classified and stored in the repository T24.
Next, the client terminal T1 executes a flow path pattern list display process (step S1-2). Specifically, a flow path pattern table generation instruction is input in the client tool T11 of the client terminal T1. In this case, the client tool T11 calls the flow path pattern stored in the repository T24. Then, the flow path pattern form is output on the display of the client terminal T1.

  As shown in FIG. 4, the flow path pattern form 900 is configured by a spreadsheet file. The flow path pattern form 900 includes a flow path pattern table sheet 901, a composite condition sheet 902, an FDL condition direct description sheet 903, a simple condition sheet 904, and a repetition condition sheet 905.

  The flow path pattern table sheet 901 shows, for each target FDL, the product service to be called and the condition to be used and the true / false for the condition for every pattern of the flow by conditional branching.

As shown in FIG. 5, the flow path pattern table sheet 901 includes columns for a test execution target, a flow path pattern, a transaction service, a plurality of product services, and a condition.
The test execution target column is blank as an initial value, and is used when a test target is selected. When executing a test, enter “O” in the test execution target column to create a test case description. On the other hand, if the test is not performed, “x” is entered in the test execution target column. Note that the blank (initial value) is also not subject to testing. Then, in the FDL generation tool T40, the flow path pattern determined not to actually pass is mechanically excluded in advance.

Information relating to an identifier for specifying each flow path pattern is recorded in the flow path pattern column.
In the transaction service column, information relating to the transaction service using this flow path pattern is recorded.

In the product service column, information related to the product service used for the transaction service is recorded.
In the condition column, the presence / absence of selection in the compound condition, FDL condition direct description, simple condition, and repetition condition, which will be described later, is displayed.

The composite condition sheet 902 records reference information for setting a composite condition combining conditions described in the simple condition among the conditions used in the flow.
The FDL condition direct description sheet 903 records reference information for directly describing the setting of conditions at the time of FDL condition description.

The simple condition sheet 904 records reference information for setting a single condition among the conditions used in the flow.
The repetition condition sheet 905 records reference information for setting the maximum number of repetitions until the break condition is reached when the repetition condition is used in the flow.

  Next, the client terminal T1 executes a test target selection process (step S1-3). Specifically, the person in charge selects the test target flow path pattern using the test execution target column of the flow path pattern table sheet 901. In this case, the client tool T11 of the client terminal T1 temporarily stores the flow path pattern in which “◯” is input as a test case.

Then, when execution input is performed in the client tool T11, the following processing is repeated for each flow path pattern specified as a test case.
Here, the client terminal T1 executes a test case generation process (step S1-4). Specifically, the client tool T11 of the client terminal T1 creates a test case description for the test target flow path pattern.

  As shown in FIG. 4, the test case description 910 is generated based on the flow path pattern form 900. In the header sheet of the test case description 910, parameters for each product service are set for the type “transaction service call” for the step ID of the test case.

  Next, the client terminal T1 executes a telegram data specification creation process (step S1-5). Specifically, the message definition sheet used in the test case set in the test case description 910 is generated in the client tool T11 of the client terminal T1.

  As shown in FIG. 4, the message definition sheet 920 is generated based on the flow path pattern form 900. This message definition sheet 920 includes a message data specification and a message setting sheet.

As shown in FIG. 6, the message data specification 921 includes columns for service code, service name, From, To, usage, and result (expected value, capture value, and determination result).
Here, in the usage column, the purpose of the message for input, verification, stub response, and verification is set.
As shown in FIG. 7, in the message setting sheet 922, item values are set for each item of the message layout of each message (for input and verification) used in the message data specification 921. The input message setting sheet 922 records the input message setting value for each item and specification, and the verification message setting sheet 922 records the expected value in the setting value column. Then, after the test, the capture value and the verification result acquired for each item and specification are recorded in the verification message setting sheet 922.
Then, the above processing is repeated for all the flow path patterns to be tested.

  Next, the client terminal T1 executes a test case description output process (step S1-6). Specifically, the client tool T11 outputs a test case description on the display of the client terminal T1.

When the test case description can be confirmed, a test execution input is performed in the client tool T11.
In this case, the test management server T2 executes a test execution process (step S1-7). Specifically, the test management server T2 inputs the message set on the message setting sheet 922 for input from the MQ driver 60 by the scenario control shell T21 and the control shell T3. Then, the verification target message is acquired and recorded in the test result storage unit and the capture field of the verification message setting sheet 922. Then, the value is compared with the value recorded in the setting value column of the verification message setting sheet 922, and the comparison result of this comparison is recorded in the result column of the message setting sheet 922.

As described above, according to the present embodiment, the following effects can be obtained.
(1) In the present embodiment, the FDL generation tool T40 executes a flow path pattern generation process (step S1-1). In this case, unnecessary flow path patterns are classified. Thereby, it is possible to efficiently identify a meaningful flow path pattern by eliminating a flow path pattern through which a message does not pass.

  (2) In the present embodiment, the client terminal T1 executes a flow path pattern list display process (step S1-2) and a test target selection process (step S1-3). As a result, a desired test target flow path pattern can be selected.

  (3) In this embodiment, for each flow path pattern specified as a test target, the client terminal T1 performs a test case generation process (step S1-4) and a message data specification creation process (step S1-5). Run. As a result, it is possible to efficiently generate a message corresponding to the flow path pattern to be tested, input it to the test target system, and perform FDL verification.

In addition, you may change the said embodiment into the following aspects.
In the above embodiment, although applied to FDL verification, the test to be applied is not limited to this, and can be applied to a combination with other tests.

  In the above embodiment, the test process is managed in the test target system configured by the transaction common system 30 to the product layer 50. The test target system is not limited to this, and can be applied to a flow in which a plurality of individual processes are performed in cooperation.

  In the above embodiment, the flow path pattern is generated using the FDL generation tool T40. The flow path pattern generation method is not limited to this. For example, the client tool T11 may be provided with the function of the FDL generation tool T40.

  10 ... Channel, 20, 40 ... Main HUB, 30 ... Transaction common system, 31, 36 ... HUB Connect, 33 ... Transaction main, 34 ... MDF, 35 ... Business component, 50 ... Product layer, 60 ... MQ driver, 61 ... AFE simulator, 62 ... product service stub, 63 ... MQ stub, 64 ... ICAL stub, T1 ... client terminal, T11 ... client tool, T2 ... test management server, T4 ... FDL server, T40 ... FDL generation tool, T21 ... scenario control Shell, T24 ... Repository, T3 ... Control shell, T6 ... Local shell.

Claims (5)

A test process management system including a control unit for managing a test process in a test target system,
The control unit is
Get the flow path pattern generated in the flow definition generation tool that defines the flow of the product service that constitutes the transaction service,
Generate a product service column in which all product services included in the flow path pattern are arranged,
For each flow path pattern, in the product service column, generate a flow path pattern list that displays the presence or absence of the product service included in the flow path pattern,
In the flow path pattern list, obtain a flow path pattern that requires testing, generate a test case for each flow path pattern,
A test process management system for outputting a message used in each test case. The control unit acquires a set value and an expected value of each item of each message used in each test case,
By executing a test using each message, an item value of the acquired response message is acquired, and a comparison result with the expected value is output to a test case description for each test case. The test process management system according to claim 1.   3. The test process management system according to claim 1, wherein in the flow path pattern list, the usable flow path pattern and the unusable flow path pattern are distinguished and output based on a condition used in a product service. . A method for managing a test process using a test process management system having a control unit for managing a test process in a test target system,
The control unit is
Get the flow path pattern generated in the flow definition generation tool that defines the flow of the product service that constitutes the transaction service,
Generate a product service column in which all product services included in the flow path pattern are arranged,
For each flow path pattern, in the product service column, generate a flow path pattern list that displays the presence or absence of the product service included in the flow path pattern,
In the flow path pattern list, obtain a flow path pattern that requires testing, generate a test case for each flow path pattern,
A test process management method, wherein a message used in each test case is output. A program for managing a test process using a test process management system having a control unit for managing a test process in a test target system,
The control unit
Get the flow path pattern generated in the flow definition generation tool that defines the flow of the product service that constitutes the transaction service,
Generate a product service column in which all product services included in the flow path pattern are arranged,
For each flow path pattern, in the product service column, generate a flow path pattern list that displays the presence or absence of the product service included in the flow path pattern,
In the flow path pattern list, obtain a flow path pattern that requires testing, generate a test case for each flow path pattern,
A test process management program which functions as means for outputting a message used in each test case.

Images