WO2018159997A1 - 테스트 케이스를 이용하여 테스트를 수행하는 방법 및 장치 - Google Patents

테스트 케이스를 이용하여 테스트를 수행하는 방법 및 장치 Download PDF

Info

Publication number
WO2018159997A1
WO2018159997A1 PCT/KR2018/002452 KR2018002452W WO2018159997A1 WO 2018159997 A1 WO2018159997 A1 WO 2018159997A1 KR 2018002452 W KR2018002452 W KR 2018002452W WO 2018159997 A1 WO2018159997 A1 WO 2018159997A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
database
value
test case
target system
Prior art date
Application number
PCT/KR2018/002452
Other languages
English (en)
French (fr)
Inventor
권오승
Original Assignee
주식회사 스페로우
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 스페로우 filed Critical 주식회사 스페로우
Priority to JP2019546812A priority Critical patent/JP6859449B2/ja
Priority to US16/486,079 priority patent/US20200019494A1/en
Priority to CN201880014545.4A priority patent/CN110337642A/zh
Publication of WO2018159997A1 publication Critical patent/WO2018159997A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3608—Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2246—Trees, e.g. B+trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation

Definitions

  • the present invention relates to a test method and an apparatus using a test case, and more particularly, a method for automatically generating a test case for finding an error of a system during a work system development process and testing a system using the generated test case. Relates to a device.
  • Test methods include static tests that test by analyzing the source code statically without actually executing the program, and dynamic tests that test by actually executing the program and checking the execution result returned.
  • Static tests can find patterns or generate test case values by analyzing patterns and processing flows in the source code to detect errors. Developers can test programs using test cases.
  • Dynamic tests require testing the program's behavior, so inputs are required, and output is generated as a result of the program's operation.
  • the basic unit is a function whose program is the minimum module.
  • the function has an input parameter and an output parameter, and the function may return a value.
  • test case was selected based on a basis path, and a solution was obtained using a Gaussian elimination method.
  • the solution obtained here is a test path value.
  • this study did not consider SQL query statements that are mostly used in corporate work systems, and there were problems that Gaussian elimination could not be solved when there were many variables.
  • the data in the database can be changed by SQL query statements for registration, modification, and deletion when testing the enterprise system, and the change affects the test results. It cannot proceed.
  • An object of the present invention for solving the above problems is to provide a test method using a test case.
  • Another object of the present invention for solving the above problems is to provide a test case generating device.
  • Another object of the present invention for solving the above problems is to provide a test apparatus using a test case.
  • the present invention for achieving the above object, provides a test method using a test case.
  • the test method using the test case may include generating a test case for source code including a structured query language (SQL) statement based on a symbolic execution, and a test case in a test target system interoperating with a database. It includes the step of performing a test by applying.
  • SQL structured query language
  • the test case is an input value of the test target system, an expected output value predicted when the input value is processed in the test target system, a setting value of the database, and a database when the test target system is processed in conjunction with a database to which the setting value is applied. It may include at least one of the expected result value predicted the result value to be stored in.
  • the generating of the test case may include determining at least one or more program paths for the source code, performing symbolic execution according to the at least one or more program paths, and using a solver for a logical expression generated according to the symbolic execution. To generate a test case.
  • the determining of the program path may include generating an abstract syntax tree (AST) by parsing the source code, and generating a control flow graph (CFG) based on the generated summary syntax tree. Determining at least one program path based on the generating and control flow graphs.
  • AST abstract syntax tree
  • CFG control flow graph
  • performing the symbolic execution may include mapping a column of a table included in a database according to a host variable of the source code and an SQL statement when the SQL statement is included in at least one program path.
  • the mapping may include parsing an SQL statement to identify a table, acquiring columns constituting the checked table using metadata of a database, and mapping the obtained columns to host variables in the source code. It may include.
  • the method may further include storing the generated test case in one of XML and JSON.
  • the method may include the step of calling and comparing the output value of the test target system obtained as a result of the function call with the expected output value, and comparing the result value stored in the database with the expected result value.
  • the test target system is a middleware service
  • generating an input full text using a test case calling the service of middleware to which the test target system is interworked, and inputting the input full text to the middleware. And transmitting the full test result from the middleware.
  • the middleware checks the database setting values of the test case from the input message, performs initial setting on the database using the confirmed database setting values, checks the input value of the test case from the input message, and checks the system under test. It can be configured to run the system under test by inputting with an input parameter of.
  • the expected output value may be excluded from the test case or determined by one of a macro, a reference, and a script when the output value is changed every time the system under test is executed.
  • One aspect of the present invention for achieving the above another object provides a test case generating device.
  • the test case generating apparatus includes a processor for executing at least one instruction and a memory for storing the at least one instruction, wherein the processor is based on a symbolic execution. Determining at least one or more program paths for source code including Structured Query Language (SQL) statements, performing symbolic execution along at least one or more program paths, and using the solver for logical expressions generated by symbolic execution You can create test cases.
  • SQL Structured Query Language
  • the processor parses the source code to generate an abstract syntax tree (AST), and generates a control flow graph (CFG) based on the generated summary syntax tree, and controls the control flow graph. Based on the at least one program path may be determined.
  • AST abstract syntax tree
  • CFG control flow graph
  • One aspect of the present invention for achieving the above another object provides a test apparatus using a test case.
  • the test apparatus using the test case includes a processor that executes at least one instruction and a memory that stores at least one instruction.
  • the processor generates a test case for a source code including a structured query language (SQL) statement based on a symbolic execution, and applies the test case to a test target system interworking with a database to perform a test.
  • the test case is a database when the input value of the test target system, the expected output value predicted when the input value is processed in the test target system, the setting value of the database, and the target system are processed in conjunction with the database to which the setting value is applied. It may include at least one of the expected result value predicted the result value to be stored in.
  • the processor may determine at least one or more program paths for the source code, perform symbolic execution according to the at least one or more program paths, and generate a test case using a solver for a logical expression generated according to the symbolic execution. have.
  • the processor parses the source code to generate an abstract syntax tree (AST), and generates a control flow graph (CFG) based on the generated summary syntax tree, and controls the control flow graph. Based on the at least one program path may be determined.
  • AST abstract syntax tree
  • CFG control flow graph
  • the processor may map a column of a table included in the database according to the host variable of the source code and the SQL statement.
  • the processor may parse a SQL statement to identify a table, obtain a column constituting the checked table using metadata of a database, and map the obtained column to a host variable of the source code.
  • the processor may store the generated test case in one of XML and JSON formats.
  • the processor applies the setting value to the database, sets input parameters of the test target system as input values, calls a function of the test target system with the set input parameters, and executes a function call.
  • the output value of the test target system obtained as a result may be compared with the expected output value, and the result stored in the database may be compared with the expected result value.
  • the processor when the system under test is a middleware service, the processor generates an input message using a test case, calls a service of middleware to which the system under test is interworked, and transmits the input message to the middleware.
  • the full text of the test results can be received.
  • test case according to the present invention When using the test method and apparatus using the test case according to the present invention as described above it is possible to provide a test case that can be repeatedly tested, which has the advantage that can be used in the regression test to find the regression error.
  • test case can be generated in consideration of embedded SQL statements included in the program, so it is easy to test a system linked to a database.
  • test cases are automatically generated, which can dramatically reduce the effort and time required for testing.
  • FIG. 1 is a conceptual diagram of a test method using a test case according to an embodiment of the present invention.
  • FIG. 2 is a flowchart of a test method using a test case according to an embodiment of the present invention.
  • FIG. 3 is a flowchart illustrating steps for performing symbolic execution according to a program path according to an embodiment of the present invention.
  • AST abstract syntax tree
  • FIG. 5 is an exemplary diagram of source code for deriving a test case according to an embodiment of the present invention.
  • FIG. 6 is a conceptual diagram illustrating a control flow graph (CFG) according to an embodiment of the present invention.
  • Figure 7 shows the results of simulating the symbolic execution process for the path 6.
  • FIG. 8 is a first exemplary diagram of a process of performing a test according to an embodiment of the present invention.
  • FIG. 9 is a second exemplary diagram of a process of performing a test according to an embodiment of the present invention.
  • first, second, A, and B may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another.
  • the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component.
  • FIG. 1 is a conceptual diagram of a test method using a test case according to an embodiment of the present invention.
  • a test method using a test case includes a symbolic executor 10, a test manager 20, and a concrete executor 40. It can be performed by a test device.
  • the test apparatus may include a separate test database 30 inside or outside.
  • the test manager 20 may receive or receive a test case generation request from the tester.
  • the test manager 20 may request the symbol executor 10 to generate a test case.
  • the symbolic executor 10 requested to generate a test case downloads source code from configuration management.
  • the configuration management can be managed with the latest source code to reflect the changes even if the source code or database table changes frequently during the development process, the source code includes a structured querylanguage (SQL) statement It can be interpreted as.
  • the source code downloaded here may be input directly to the symbolic executor 10 by the developer.
  • the symbolic executor 10 may generate a test case and send it to the test manager 20.
  • the test manager 20 may store the received test case in the test DB 30.
  • the stored test case may be provided to the tester through the test manager 20 when the tester requests an inquiry through the tester manager 20.
  • the test manager 20 may request the test runner 40 to execute the test.
  • the detailed executor 40 requested to execute may query a test case from the test DB 30, and the database 50 interoperating with the system under test (SUT) 60 from the inquired test case.
  • SUT system under test
  • the setting value for the test may mean an initial value that should be stored in the database 50 in order for the test target system 60 to operate in conjunction with the database 50. In some cases, the initial value may be no or null. It may be.
  • the detailed executor 40 may input an input value to the test target system 60 from the inquired test case to obtain an output value of the test target system 60.
  • test target system 60 receives and operates an input value
  • a new result value may be stored in the database 50 interworking with the test target system.
  • the detailed executor 40 may also obtain a result value in the database. can do.
  • the detailed executor 40 may compare the obtained output value of the test target system 60 and the result value of the database 50 with the confirmation value stored in the test DB 30, and through the check process, the test target system 60. Can diagnose and identify errors.
  • the detailed executor 40 may store the test result in the test DB 30 and return the test result to the test manager 20.
  • the test manager 20 may provide the tester with the returned test results.
  • This process can be used to support a series of test life cycles, such as creating, storing, and executing test cases, storing test results, and providing statistics and reports on test results.
  • the symbolic executor 10 may use meta information provided by the database 50 to obtain the columns of the table and constraints of each column required to understand the SQL query statement when performing the symbolic operation.
  • the test manager 20 may store and manage the test path, test cases, and test result values thereof in the test DB 30 in an extensible markup language (XML) format.
  • XML extensible markup language
  • test case and the test target system 60 may be required so that the test may be performed by using the test case reflecting the latest source code.
  • the test target system 60 is changed, it is confirmed from the configuration management.
  • the test case can be created, and the test case can be generated by checking the latest status from the configuration management only when the test request is made.
  • test manager 20 when the test manager 20 receives a test request from a user or an administrator, after checking whether a test case is generated in the test DB 30, if the test case exists and there are no new modifications (or for the latest source code) In the case of a generated test case, the tester may request a test while passing the identifier of the test case system 60 and the test case to the detail executor 40. In addition, if there is no test case in the test DB 30 or the test case generated based on the latest test target system 60, the symbol executor 10 may request the test case generation.
  • the detailed executor 40 draws out a test case stored in the test DB 30 to execute the test, generates a driver or full text using the values, executes the test, and stores the test result value in the test DB 30. Can manage
  • Configuration management manages all source codes to be tested, and the symbolic executor 10 may generate test cases for the latest source code.
  • the system under test 60 may be a module or a service for testing.
  • modules can exist in the form of source code, objects, static libraries, and dynamic libraries.
  • the service may be a binary program executed under the middleware. The service can perform testing through a full text.
  • preambles There are two types of preambles: position-based and tag-based types.
  • position-based preambles the meaning of the data can be defined by the location and length of the data.
  • Object Notation Object Notation
  • XML Extensible Markup Language
  • the test manager 20 may provide developers, quality assurance personnel, and project managers with various test results in the form of statistics and status reports. These reports can show project status, project status, test status by module or service, and the results of excluding or addressing defects.
  • test manager 20 may support unit tests, integration tests, and regression tests.
  • Test cases created for unit tests can also be used in integration tests and regression tests.
  • Integration tests consist of scenarios, which can be constructed by chaining unit test cases together. In order to map unit test cases into scenarios, it may be necessary to map the actual output of previous test cases to input values. The expected output value may be provided with an arithmetic expression to map the input value.
  • the test case to be used in the regression test can use the test case of the unit test without modification, but it may be necessary to select various test cases according to the regression analysis. In other words, the scope of the regression analysis may be applied to the selection of test cases based on program dependencies, test case selection based on function dependencies, and selecting only affected test cases.
  • the symbolic executor 10, the test manager 20, and the detailed executor 40 have been described as components for convenience of description, but each is not only implemented as a separate device, but some are combined and implemented in one device. It should be understood that it may be, and should not be construed as limited to the present embodiment.
  • FIG. 2 is a flowchart of a test method using a test case according to an embodiment of the present invention.
  • a test method using a test case includes generating a test case for a source code including a structured query language (SQL) statement based on a symbolic execution (S200) and interworking with a database.
  • a test may be performed by applying a test case to a test target system.
  • the test case is an input value of the test target system, an expected output value predicted when the input value is processed in the test target system, a setting value of the database, and a database when the test target system is processed in conjunction with a database to which the setting value is applied. It may include at least one of the expected result value predicted the result value to be stored in.
  • the input value may be a value corresponding to the input parameter of the function
  • the expected output value may be a value corresponding to the output parameter to check the result returned after the function is executed
  • the set value is the system under test It may be an initial value to be stored in the database to operate in conjunction with the database
  • the expected result value may be a value that can be stored in the database as a result of the test target system operating in conjunction with the database.
  • the input value, the expected output value, or the expected result value may be an integer or string type depending on the input parameter or return type (or output parameter) of the function or the data type stored in the database.
  • the database setting value can be an SQL query statement composed of at least one of INSERT, UPDATE, and DELETE statements.
  • a test case including at least one of an input value, an expected output value, a database setting value, and an expected result value may be stored in a format of one of JSON (JavaScript Object Notation) and XML (Extensible Markup Language).
  • JSON JavaScript Object Notation
  • XML Extensible Markup Language
  • the present invention is not limited thereto and may be stored in a form of a string or a binary.
  • the source code may mean source code of the test target system.
  • the source code may include an SQL statement.
  • the source code used here may include all code written in a commercial language including JAVA, Swift, Object C, and the like. It can be a language that has been removed and defined separately.
  • the SQL statements included here may be defined as embedded SQL, such as Oracle's PL / SQL, PostgreSQL's ECPG, Sybase's ASE, etc.
  • the languages supported by embedded SQL include C / C ++, COBOL, PL / 1, and the like.
  • the exemplary source code of the present invention has been described by removing some syntaxes for convenience of description in a commercial language, but the present invention is not limited thereto, and various programming languages may be applied.
  • the system under test may be an information system using a database, where the database may store one or more records and a table having at least one attribute for the records.
  • test target system will be described using a business interest calculation program that works with a database as an example, but is not limited to a specific system.
  • source code of the business interest calculation program see FIG. 5 below. can do.
  • symbolic execution refers to using a value defined as a symbol instead of a specific value in order to analyze a program, and will be described below based on example source code.
  • the calculation for the conditional expression composed of the symbol value as described above may use a variety of solvers (solver). For example, you can use Z3, which Microsoft has released for research.
  • the solver can be difficult to calculate, in which case one of the symbol values is actually assigned a specific value. This can be solved by changing to a linear condition using a method.
  • the account table stored in the database can be checked, and information on attributes such as account number and loan amount can be stored.
  • account data stored in the account table may be as shown in Table 3 below.
  • the account data stored in the database can be checked.
  • the values for the account number and loan amount in Table 2 may be stored.
  • the interest repayment table may be as follows.
  • the repayment date according to the account number may be stored in the interest repayment table.
  • the interest redemption data recorded in the interest redemption table may be as follows.
  • the repayment date and interest may be stored according to each account number.
  • a test case (S200)
  • a test case may be generated using a solver for the generated logical expression.
  • FIG. 3 is a flowchart illustrating steps for determining a program path according to an embodiment of the present invention.
  • 4 is a conceptual diagram illustrating an abstract syntax tree (AST) according to an embodiment of the present invention.
  • 5 is an exemplary diagram of source code for deriving a test case according to an embodiment of the present invention.
  • 6 is a conceptual diagram for describing a control flow graph (CFG).
  • the determining of the program path of FIG. 2 may include parsing source code to generate an abstract syntax tree (AST) (S211), based on the generated summary syntax tree.
  • the method may include generating a control flow graph (CFG) (S212) and determining at least one program path based on the control flow graph (S213).
  • CFG control flow graph
  • Abstract syntax is an inductive definition of an abstract syntax tree (AST) consisting of operators. Summary syntax can use operators to remove ambiguity in the syntax of source code. In addition, the summary syntax tree can be generated by combining other summary syntax trees with constructors and operators.
  • AST abstract syntax tree
  • the summary syntax tree may also be represented in the form 400 of the structure, or in the illustrated form 410 when the diagram is conveniently illustrated for easy understanding.
  • the summary syntax tree is a tree structure, and the tree may be represented in various forms. For example, it can be implemented using data structures such as ArrayList, List, and Map.
  • the top node may be a ⁇ Program>.
  • ⁇ Program> may be composed of one or more functions, that is, a list.
  • a function can consist of a return type, a function name, parameters, and a block declaration.
  • a parameter can consist of a type and a variable name.
  • Block declarations can consist of zero or more statements.
  • Statements can consist of local variable declarations, assignments, if statements, and query statements.
  • executing a symbolic operation including the query statement may be the most important element.
  • control flow graph can be introduced.
  • the control flow graph can graph all paths through the program during execution.
  • Each node in the graph represents a basic block and arrows can be used to represent jumps.
  • the graph may have one entry block and an exit block. Every line that is an arrow can have attributes that are Outdegree (A)> 1 or Indegree (B)> 1 (or both).
  • the program path determination may result in a path explosion in which a myriad of paths are derived.
  • Independent program paths can be used to solve path explosion problems.
  • the independent program path is not a combination of specific paths, but may be a path that is differentiated from other unique paths.
  • Basis Path Testing can be used as a technique for finding independent program paths. Specifically, McCabe (McCabe, TJ, 1976, A Complexity Measure, IEEE Transactions on Software Engineering, Vol.SE) -2, Issue 4).
  • a node may be a value obtained by adding a decision and a process.
  • the formula for calculating the independent program path by the graph theory can be as follows.
  • independent program paths can be derived by adding 2 to the number of edges minus the number of nodes (Edges-Nodes), adding 1 to the number of regions, or Decisions.
  • the number may be one plus one.
  • sample source code of FIG. 5 may be generated as the control flow graph 500 of FIG. 6 using the summary syntax tree of FIG. 4, and the independent source 6 may be visited by visiting the path of the generated control flow graph.
  • Program paths 510 can be derived.
  • the sample source code according to FIG. 5 was used to derive each of the program paths 510 according to FIG. 6.
  • the number of each line may indicate a syntax number, and in syntax number 7, 7.1 and 7.2 are shown depending on whether each conditional expression (accNo ⁇ 0, paydate ⁇ 0) is established in the if statement, and satisfies the if statement. Will move the path to phrase number 8.
  • the syntax number 11 may also be branched as a conditional statement, and the SQL statement of the syntax number 14 may also be branched to another path depending on whether an INSERT is performed.
  • control flow graph 500 of FIG. 6 and the program path 510 corresponding thereto may be derived.
  • the program path derived here may include a syntax number and information indicating whether the statement is a branch statement.
  • the syntax number can be used to get the actual syntax to execute, and the branch statement can be used to create constraints on the value of the variable to follow the path.
  • Figure 7 shows the results of simulating the symbolic execution process for the path 6.
  • step S220 of performing symbolic execution according to the program path of FIG. 2 may be described in detail.
  • (1), (2), (3), (4), and ⁇ may each indicate a syntax number in FIG. 5.
  • syntax numbers 1 to 4 in FIG. 5 denote syntaxes for declaring variables, and thus, (1) to (4) of FIG. Can be set to a value.
  • the variable name can be converted to uppercase, the name can be set to a symbol value, and if there is a value in the declaration part, the value can be set to an initial value. .
  • Host variables can be mapped to database columns and used to enter (or register) values in a database or to retrieve values from a database. This value can also play an important role in setting up your database environment to allow for repeated tests.
  • test cases can vary depending on the number of SQL statements in the independent program path.
  • the account table may have a record whose value in the ACC_NO column is the same as the value of the host variable accNo or no record. Therefore, you can create a test case and calculate the value of that test case by considering two cases.
  • the four kinds of SQL statements, SELECT, UPDATE, INSERT, and DELETE statements, are described below to understand the considerations for host variables used in SQL statements.
  • the syntax that includes the WHERE conditional clause in these SQL statements is SELECT, UPDATE, and DELETE.
  • the conditional clauses of these query statements are branch statements compared to the existing programming languages, so they can be included in path constraints.
  • syntax numbers 7 and 9 in FIG. 5, which are sample source codes, are shown. Specifically, syntax number 7, which is a sample of an if statement, and syntax number 9, which is a SELECT statement sample created by an SQL statement.
  • the path constraint of syntax number 7 (if statement) may need to be changed as follows to get a normal query result.
  • the value of the host variable: accNo can be a symbolic value of ACCNO after performing symbolic execution.
  • symbolic execution can be assumed to be performed in two passes for convenience of explanation.
  • the first pass is for creating a test case, and the path may need to be broken down considering the condition of the WHERE clause of the SQL query statement.
  • Path 6 has three possible paths, considering the result of executing SELECT and INSERT statements as success and failure. Considering the pair of SELECT and INSERT, there are three cases of success and success, success and failure, and failure and failure (or success). There are four cases of simple combination, but if SELECT fails, INSERT statement can have no effect and can be excluded.
  • the SQL query statement can be parsed to find the tables used in the FROM clause, and all the columns that make up the table can be retrieved from the metadata of the work database.
  • the column and host variable mapping tables for the account table in Table 2.
  • the columns of this table can consist of sentence number, table name, column / constant, host variable name, delimitation, item status, and value.
  • the column / constant may have a column name or a constant value. In the case of having a constant value, it may be assumed that a value of 100 is set to addin as shown in Table 7 above.
  • K For example,? Can be one of a host variable, a constant, or a column. If? Is a host variable, the value of the host variable is set earlier in the sequence, so the value at the point of time when the expression of the corresponding SQL query statement is calculated during symbolic execution is found.
  • the value of the host variable may be a constant value or an arithmetic expression composed of symbols. If? Is a constant, it immediately assigns the value corresponding to the K column. However, if? Is a symbolic arithmetic expression, then the value for the arithmetic expression must be calculated at this point. If? Is a column, it can occur in the case of a join query, but the calculation is a bit complicated, and can be applied in a similar way.
  • the second pass is symbolic execution.
  • Table 11 is a symbol table that is the result of symbolic execution.
  • a symbol table can consist of variables, initial values, and symbolic expressions.
  • Table 13 below is a symbol table reflecting a value retrieved from a database for executing a SELECT statement according to line (9) of FIG. 7.
  • loanAmt can be the value of LOANAMTDB read from the LOAN_AMT column
  • interestRate can be the INTERESTRATEDB value read from the INTEREST_RATE column.
  • the host variable can find the value corresponding to the execution point of the symbolic variable in the symbol table and register or modify it in the table column structure. If the host variable is not present in the symbol table, it can be set as a value. When all of this is done, we can recalculate the arithmetic formula consisting of symbols. In the case of a constant, the column value can be registered in the value column of the column and host variable mapping table as shown in ⁇ Table 5>.
  • the path constraint may be derived as follows.
  • PC3 PC2 AND days> 0
  • Table 14 is a mapping table that executes line 14 of FIG. 7.
  • a column of the interest repayment table may be generated and a host variable mapping table may be generated by querying a column of the interest repayment table.
  • the values in the column and host variable mapping tables are one symbolic variable, as shown in Tables 10 and 14 of the table, you can choose the default or the values defined in the constraints set in the database.
  • the value of LOAN_PERIOD can be a positive value using random numbers
  • the value of LOAN_TYPE can be a value declared in column constraints, or a valid value can be inferred from the check expression.
  • mapping a column of a table included in the database according to a host variable of the source code and the SQL statement may include a step.
  • the mapping may include parsing an SQL statement to check a table;
  • the method may include acquiring the columns constituting the identified table using metadata of the database and mapping the acquired columns with host variables of the source code.
  • Generating a test case using a solver may further include converting the generated logical expression into a Satsfiability Modulo Theories (SMT) language.
  • This step can be a step in which the solver transforms the constraints of the logical expression into understandable forms.
  • the solver can use Z3, for example, released by Microsoft.
  • Table 15 shows the results of converting the constraints into the SMT language.
  • test case in the present invention may include a database setting value to be applied to a system interworking with the database. Therefore, a method of generating database setting values is described below.
  • Database settings can be created in the form of an INSERT, UPDATE, or DELETE statement. Each time a test is run, these query statements can be run against the tables used by the business program to create the database state just before the test is run.
  • a query statement as shown in Table 18 may be generated.
  • the record can be registered by executing the INSERT statement. If the record exists, the value of the record can be changed by executing the UPDATE statement.
  • Table 19 is a query statement to configure the database environment to test the case where the registration is normally executed for the INSERT statement. Referring to Table 19, whether or not a record exists in the interest repayment table, the record can be deleted from the table so that the record does not exist in the table.
  • test cases in program path 6 There are three test cases in program path 6 derived from FIG. 6, and the test cases may be increased by a factor of two for each SQL query statement. So we can test case in the second mathematical query count Is generated, and summarized the test case generated by the path 6 is shown in Table 20 below.
  • test case 6-1 may test a case where an account is held but interest is not repaid.
  • the input values may be 12345678901234, the account number registered in the table, and PAYDATE, the result of the symbolic execution.
  • the database setting value can register an account with the INSERT statement and delete the interest payment history with the DELETE statement.
  • the LOAN_PERIOD and LOAN_METHOD values of the INSERT statement can be set to any value or the query result value of the account table.
  • Test case 6-2 can test the case of holding an account and repaying interest.
  • the input value may be the same as 6-1, and the database setting value may be to register an account and interest payment history with an INSERT statement.
  • REPAY_DATE can be set using a macro called TODAY.
  • Test case 6-3 can test if you do not have an account. Therefore, in this case, the input value can be 0, which is an account number that does not exist in the account table, and the account and interest payment history can be deleted using the DELETE statement.
  • Database settings may be calculated by symbolic calculations, but there may be items that cannot be calculated by symbolic calculations. These can be referred to as free variables and can be generated as close as possible by referring to the constraints of the database or transaction log information left by the application so that any value can be generated. have.
  • the test case according to the present invention is to predict the output value (or expected result value) to check the output value corresponding to the input value to test the accuracy of the test and the database expected to check the actual value stored in the test result database It may contain a result (or expected confirmation).
  • Table 21 is a table of expected output values and database expected result values to confirm test results.
  • the expected output value (or expected result value) may be a return value of a function.
  • the value for calcInterest which is an expected output value (or expected result value) in 6-1, may be derived from PAYDATE, which is a result of symbolic execution, and LOANAMTDB, LOANDATEDB, and INTERESTRATEDB, which are inquiries from the database.
  • the database expected result value (or expected confirmation value) may be generated by a SELECT statement.
  • the expected database result is the result of executing the SELECT statement a
  • test cases 6-2 and 6-3 are error values in which expected result values are returned.
  • the database expected result values (or expected confirmation values) may be generated as shown in Table 20 or not generated at all.
  • an automatically generated test case may generate an expected output value corresponding to an input value in order to confirm a test result, and generate an expected database value corresponding to a database setting value.
  • the method may further include storing the test case generated after generating the test case of FIG. 2 in one of XML and JSON formats.
  • the present invention is not limited thereto and may be stored in a form of a string or a binary.
  • the location information where the test case is stored may be referred to by giving an info tag, and may be stored using a path, a file name, a method name, and a test case number, which are location information of the info tag, as a primary key. Therefore, a separate test case database may be implemented to manage only test cases.
  • test cases need to be synchronized as the system under test changes.
  • One of the synchronization methods may be a method of changing all test cases immediately after the change of the test target system, and the other may be a method of changing test cases by synchronizing at the time of executing the test.
  • the first method has the advantage that the system under test and the test case always match, but there can be a drawback to the overall performance of the test if there is a large change.
  • the second method may have a disadvantage in that test execution time is long because synchronization is performed at execution time.
  • FIG. 8 is a first exemplary diagram of a process of performing a test according to an embodiment of the present invention.
  • 9 is a second exemplary diagram of a process of performing a test according to an embodiment of the present invention.
  • the system under test according to the present invention may be a service or a module.
  • the generation method of the test driver executed when the test is performed may vary depending on the type of the system under test.
  • the form of the system under test may be provided in the form of source code or object, and in the form of a shared library. If the test target is in the form of source code or object, the build environment can be complicated because the build (compile and link) must be performed including the test target. In this case, the test target is built and executed in one body with the test driver, and if the test target has an error, the test build is not performed. If the test target is in the form of a shared library, you can use the dynamic invocation of the module to run the test. The presence of a shared library of the module may mean that the module under test has no error.
  • a method of performing a test when a test target system is a module includes applying a database setting value included in a test case to a database of a test target system, and inputting a test value as an input value included in the test case. Setting the input parameters of the system, calling a function of the test target system with the set input parameters, and comparing the output of the test target system with the expected output included in the test case as a result of the function call, and the result stored in the database. And comparing the database expected result with the test case.
  • each step can be performed by executing the compiled test driver.
  • the structure and database tables and columns constituting the output value and the expected output value of the test target system may be changed at any time during the development process, it may additionally support a function of detecting and synchronizing changes in real time.
  • test method generated by the test driver has an advantage in that the test manager can directly control the transaction and test without having to completely build the actual test environment.
  • Table 22 shows the source code of the test method using the test driver.
  • a setting value can be input to a database
  • a test case input value can be input as a function parameter of a test target system, and the results performed accordingly can be compared.
  • test target system is a service
  • the method of performing a test may include generating an input text using a test case, calling a service of middleware to which the test target system is interworked, and inputting the input text to the middleware. And transmitting the full test result from the middleware.
  • the step of generating the input message may be processed as a step of acquiring the stored message since the test case is generated, and thus may be stored and stored in the form of a text such as XML or JSON first.
  • the method may further include converting the input text into a format supported by the middleware service after generating the input text. This may be to ensure compatibility because the format of the input professional storing and using the test case and the format supported by the middleware service may be different.
  • the middleware used to develop the system under test may include Socket, RMI, RPC, HTTP, TUXEDO, T-max, and Entera.
  • the service invocation method may be determined according to the middleware used by the developed test target system, and the method of controlling the transaction may also be changed.
  • Commercial middleware such as TUXEDO and T-max, provides two-phase commit, which allows you to effectively control transactions related to test and business tasks, such as setting up the database environment and processing expected results at test time, and leaving test results in the database. Also, if the system under test uses a framework, the system under test can provide a more structured form.
  • the framework allows you to call intercept routines such as preprocessing and postprocessing to process a transaction in a task, enabling you to perform common functions before calling the service. Transactions can be effectively processed by embedding modules to handle database configuration and expected results in such preprocessing and postprocessing.
  • Table 23 shows sample code for testing middleware-based test target systems.
  • each process on the test agent side and each process performed by the middleware framework can be checked.
  • the test agent can query the input text of the test case by the program number and the test case number, and set a value in the spare area of the input text.
  • the test agent can call the service by sending the input message to the framework.
  • the framework can pass the program number and test case number sent in the preliminary area of expertise to the preprocessing module of the service.
  • you can set the environment before running the test by reading the database settings from the database where the test case is stored using the program number and test case number.
  • the framework can call the system under test (SUT) to execute business logic.
  • the SUT can perform business processing while manipulating the data of the linked business database.
  • the framework can retrieve database expected results by program number and test case number. Queries can be executed on the business database to verify the accuracy of the test by comparing the expected and actual results. In each of the above steps, the information necessary to manage the test results can be recorded in the test database.
  • test case result specialized processing module may query the full text of the expected result of the test case by the program number and the test case number.
  • the test case result processing module may compare the expected output value with each value of the actual output message and store the result in a database in which the test case is recorded.
  • middleware (or a framework of middleware) checks the database setting values of the test case from an input message, performs initial setting on the database using the confirmed database setting values, and inputs the test case from the input message.
  • the controller may be configured to execute the test target system by checking an input value of and inputting the input parameter as an input parameter of the test target system.
  • Test method by middleware can make test agent by using generalized module without generating source code. There is also the advantage of using two-phase commit transaction management if the business system is developed using a framework.
  • test results cannot be statically defined. For example, information that changes each time, such as the serial number generated each time a test is run or the date or time at which the test is run, can increase the uncertainty of the test results. Thus, as a test case for this, it may be difficult to clearly define the expected output value or the expected result value of the database.
  • the test result may not be determined, or values such as macros, references, and scripts may be defined and responded to logic.
  • values can be entered according to constant values, macros, references, and scripts.
  • a constant value can be a number or a string
  • a macro can be a predefined name, such as TODATE, or, in the case of a current date, the current date of the system can be retrieved and used.
  • the reference can also retrieve the full column value of the preamble, in which form the test case is stored.
  • the script can compare the output from running the script with the output.
  • the script may mean to include a macro.
  • the expected output value may be excluded from the test case or determined by one of a macro, a reference, or a script when the output value changes every time the test target system is executed.
  • Test methods can be unit tests, integration tests, or regression tests.
  • unit test is a software test method to test individual units of the source code.
  • the unit is the smallest unit of the application and may mean a set of lines for testing.
  • Unit testing is a test method for finding problems in the early stages of development, with the goal of finding bugs, defects in specifications, or missed statements made at the time of implementation.
  • a module that has been unit tested can guarantee that it will work correctly when used in a regression test.
  • So test cases for unit tests can be written for programs that are likely to cause defects.
  • This unit test case can be used not only for regression testing of unit-tested programs, but also for integration tests that require integration into stable modules.
  • unit tests may not find all the errors in a program, and because you test only the functionality of the unit itself, you may not find errors such as integration errors or system errors.
  • test cases created with the symbolic executor may be first stored in a test DB.
  • the user and the administrator may manage by assigning an appropriate name to the automatically generated test case as described above.
  • test results are automatically aggregated into a test database and accumulated in statistics, providing information that makes it easier for administrators to understand the test status in real time.
  • integration testing can be defined as a software testing method in which unit modules or services are connected in a sequence to perform tests. Integration testing is for programs that have completed unit testing and can be performed by the analyst / designer prior to verification tests, such as pilot or full-scale.
  • Integrated test methods can include big bang, top-down, bottom-up, and hybrid methods.
  • the big bang method is to test developed modules by integrating them all at once.
  • the big bang method has the advantage of shortening the integration test time, but if the unit program is not sufficiently tested, testing may take more time and effort.
  • the bottom-up method involves testing the lowest unit first. When all the lower units related to the upper unit to be tested are tested, the procedure can be repeated up to the highest unit by repeating the procedure such as testing the upper unit.
  • the top-down method allows you to test from the top level. You can then test the subunits repeatedly.
  • the hybrid method may be a method of mixing a bottom up and a top down method. Integration tests may not test conditions that are not described in the integration test specification. Using automatically generated test cases, developers can configure module integration or service integration tests.
  • Module integration tests can be performed by weaving modules in order. In other words, you can create a test driver that binds the modules in order. When you test the top-level function in a module, the subfunctions are called and executed.
  • the user registration module, user list inquiry module, user modification module, and user deletion module can be configured and tested in a series of scenarios.
  • Service integration testing is a way to test services by binding them in order. Assume that you configure a user registration service, a user list lookup service, a user modification service, and a user deletion service as a series of scenarios as in the module integration test.
  • the tester can select a test case that registers a user in the test DB. In order to check whether the user is normally registered, a test case in which the user list is searched by the previously registered user number can be selected. In addition, a test case for testing a modified user's information can be selected. At this point, you can specify the same user number so that you can test it with the same user number. Finally, to test the user deletion, you can select the user deletion test case. Similarly, you can specify the same user number to test the deletion.
  • test cases can connect unit test cases to perform service integration tests. Since the test cases that make up the scenario must use the same user number, you can provide a way to use the user number that you registered in the user registration test case for future test cases.
  • One very simple way to do this is to provide a way to reference the input or actual output values previously used in the test case to determine accuracy.
  • the results of the integration tests may need to manage the results of the individual test cases that make up the scenario, and may also manage the results of the entire scenario. In addition, it may be necessary to manage test results for one scenario, history of test scenarios, and change history of scenarios. The manager is interested in whether the entire scenario has succeeded, and the developer is interested in information that can determine where the scenario failed and what caused the failure.
  • Regression testing is a software testing technique to verify that previously developed software still works well after a change.
  • Software changes can be caused by improvements, patches, and shape changes.
  • Regression testing can be aimed at finding regression errors caused by new bugs or program changes (collectively, add, delete, and fix).
  • Regression testing can be done by running the entire test case, or by finding and testing the program affected by the program change. This method can be difficult to use if you have limited test time, such as running the entire test case is ideal, but it must be completed within eight hours.
  • regression analysis Finding the targets affected by the program change through the impact analysis is called regression analysis, and the analysis result becomes a criterion for selecting regression test cases, and the regression test can be performed using the results of the regression analysis.
  • Regression testing can be advantageous in that the program has been modified so that only the test cases of the affected program can be found and run.
  • test cases to be used in the regression test may be in the form of unit test cases or in the form of integrated test cases.
  • the regression test can use all possible test cases, or you can specify which test case to use in the regression test to test efficiently.
  • the results of the regression test can be stored in the test DB.
  • a changed program may be prevented from being loaded into the operating system.
  • Regression testing can be a test that must be performed in an iterative development method.
  • iterative incremental development the program developed every day is committed to the configuration management system, the automatic build system downloads the program from configuration management, executes the build, and finds the affected function through the impact analysis to execute a series of test cases. The process can be repeated.
  • impact analysis Taking impact analysis as an example, suppose you first drop a column from a work table. The impact analysis system can find a function that uses the deleted column (and can also see the program that contains the function). You can iterate until you find all the parent functions that use this function. You can remove the same function from the ones found. You can use the list of deduplicated functions to find the test cases that accompany a function. You can run all of these test cases to complete the regression test.
  • Static analysis techniques can be used to track the flow of control to find the affected basis passes, find the test cases associated with them, and extract a minimal set of test cases.
  • the test case generating apparatus may include a processor that executes at least one instruction and a memory that stores at least one instruction.
  • the processor determines at least one or more program paths for the source code including the Structured Query Language (SQL) statement based on the symbolic execution, and performs symbolic execution according to the at least one or more program paths.
  • test cases can be generated using the solver on the logic generated by symbolic execution.
  • the processor parses the source code to generate an abstract syntax tree (AST), and generates a control flow graph (CFG) based on the generated summary syntax tree, and controls the control flow graph. Based on the at least one program path may be determined.
  • AST abstract syntax tree
  • CFG control flow graph
  • the test apparatus using the test case may include a processor for executing at least one instruction and a memory for storing at least one instruction.
  • the processor generates a test case for a source code including a structured query language (SQL) statement based on a symbolic execution, and applies the test case to a test target system interworking with a database to perform a test.
  • the test case is a database when the input value of the test target system, the expected output value predicted when the input value is processed in the test target system, the setting value of the database, and the target system are processed in conjunction with the database to which the setting value is applied. It may include at least one of the expected result value predicted the result value to be stored in.
  • the processor may determine at least one or more program paths for the source code, perform symbolic execution according to the at least one or more program paths, and generate a test case using a solver for a logical expression generated according to the symbolic execution. have.
  • the processor parses the source code to generate an abstract syntax tree (AST), and generates a control flow graph (CFG) based on the generated summary syntax tree, and controls the control flow graph. Based on the at least one program path may be determined.
  • AST abstract syntax tree
  • CFG control flow graph
  • the processor may map a column of a table included in the database according to the host variable of the source code and the SQL statement.
  • the processor may parse a SQL statement to identify a table, obtain a column constituting the checked table using metadata of a database, and map the obtained column to a host variable of the source code.
  • the processor may store the generated test case in one of XML and JSON formats.
  • the processor applies the setting value to the database, sets input parameters of the test target system as input values, calls a function of the test target system with the set input parameters, and executes a function call.
  • the output value of the test target system obtained as a result may be compared with the expected output value, and the result stored in the database may be compared with the expected result value.
  • the processor when the system under test is a middleware service, the processor generates an input message using a test case, calls a service of middleware to which the system under test is interworked, and transmits the input message to the middleware.
  • the full text of the test results can be received.
  • the test case generating device or the test device using the test case described above may be a desktop computer, a laptop computer, a notebook, a smartphone, a tablet PC, Mobile phone, smart watch, smart glass, e-book reader, portable multimediaplayer, portable game console, navigation device, digital camera, DMB ( or a digital multimedia broadcaster, a digital audio recorder, a digital audio player, a digital video recorder, a digital video player, a PDA, or a personal digital assistant.
  • the methods according to the invention can be implemented in the form of program instructions that can be executed by various computer means and recorded on a computer readable medium.
  • Computer-readable media may include, alone or in combination with the program instructions, data files, data structures, and the like.
  • the program instructions recorded on the computer readable medium may be those specially designed and constructed for the present invention, or may be known and available to those skilled in computer software.
  • Examples of computer readable media may include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like.
  • Examples of program instructions may include high-level language code that can be executed by a computer using an interpreter, as well as machine code such as produced by a compiler.
  • the hardware device described above may be configured to operate with at least one software module to perform the operations of the present invention, and vice versa.
  • the above-described method or apparatus may be implemented by combining all or part of the configuration or function, or may be implemented separately.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

테스트 케이스를 이용한 테스트 방법 및 장치가 개시된다. 테스트 케이스를 이용한 테스트 방법은 심볼릭 실행(symbolic execution)에 기초하여 SQL(Structured Query Language)문을 포함하는 소스 코드에 대한 테스트 케이스를 생성하는 단계 및 데이터베이스와 연동하는 테스트 대상 시스템에 상기 테스트 케이스를 적용하여 테스트를 수행하는 단계를 포함한다. 따라서, 테스트 케이스를 자동으로 생성하므로 테스트에 소요되는 노력과 시간이 획기적으로 절감할 수 있다.

Description

테스트 케이스를 이용하여 테스트를 수행하는 방법 및 장치
본 발명은 테스트 케이스를 이용한 테스트 방법 및 장치에 관한 것으로, 더욱 상세하게는 업무 시스템 개발 과정에서 시스템의 오류를 찾기 위한 테스트 케이스를 자동으로 생성하고 생성된 테스트 케이스를 이용하여 시스템을 테스트하는 방법 및 장치에 관한 것이다.
테스트 방법에는 프로그램을 실제로 실행하지 않고 소스코드를 정적 분석하여 테스트하는 정적 테스트와 프로그램을 실제로 실행하여 반환된 실행 결과를 확인함으로써 테스트하는 동적 테스트가 있다.
정적 테스트는 소스 코드의 패턴과 처리 흐름을 분석하여 오류를 검출하는 방법으로 테스트 케이스를 찾거나 테스트 케이스 값을 생성할 수 있고, 개발자는 테스트 케이스를 이용하여 프로그램을 테스트할 수 있다.
동적 테스트는 프로그램의 동작을 테스트해야 하므로 입력값이 필요하고, 프로그램의 동작 결과로 출력값이 생성된다. 또한 프로그램의 동작을 테스트할 때는 프로그램이 최소 모듈인 함수를 기본단위로 한다. 여기서, 함수는 입력 파라미터와 출력 파라미터를 가지며 함수는 값을 반환하기도 한다.
기존의 테스트 케이스를 생성하는 연구 중 하나(Gupta et al)는 반복적 완화 기법을 사용하여 테스트 데이터를 자동으로 생성하였다. 구체적으로, 베이시스 경로(Basis Path)를 기준으로 테스트 케이스를 선택하고, 가우스 소거법을 사용하여 해를 구하였는데, 여기서 구한 해가 테스트 경로 값이다. 그러나, 이러한 연구는 기업의 업무 시스템에 대부분 사용되는 SQL 쿼리문에 대한 고려가 없었으며, 변수가 많아지면 가우스 소거법으로 해결할 수 없는 문제가 있었다.
또 다른 연구 중 하나(Godefroid et al)는 심볼릭 실행과 구체적인 실행을 엮어서 테스트 케이스를 생성하였다. 구체적으로, 랜덤 테스트 방식, 코드 삽입 방식, 심볼릭 실행 방식을 이용하여 외부 환경에 영향을 미치는 변수를 추출하고, 추출된 변수로 랜덤하게 테스트 케이스를 생성하는 랜덤 테스트 방식으로 초기값을 생성했고, 계측기 코드를 통해서 실행 결과를 분석하였다. 그러나, 이러한 연구는 엄밀한 의미의 심볼릭 실행으로 보기 어려운 문제가 있었다.
그밖에도 심볼릭 실행 방법과 구체적인 실행 방법을 엮어서 테스트 케이스를 생성하는 다른 연구(Sen et al)는 심볼릭 실행을 위해 C 언어와 유사한 언어를 정의하여 사용하고, 주로 NULL Pointer를 찾는데 활용하였다. 그러나, 테스트 케이스를 명시적으로 생성하여 관리하지 않아 매번 전체 소스 코드를 재 파싱하는 문제점이 있었고, 이또한 SQL 쿼리문을 고려하지 않았다.
데이터 베이스 환경을 고려하지 않는다면, 기업 시스템에 대한 테스트가 이루어질 때 등록, 수정 그리고 삭제에 관한 SQL 쿼리문에 의하여 데이터베이스 내의 데이터가 변경될 수 있고, 이러한 변경은 테스트 결과에 영향을 미치므로 정확한 테스트가 진행될 수 없다.
상기와 같은 문제점을 해결하기 위한 본 발명의 목적은, 테스트 케이스를 이용한 테스트 방법을 제공하는 데 있다.
상기와 같은 문제점을 해결하기 위한 본 발명의 다른 목적은, 테스트 케이스 생성 장치를 제공하는 데 있다.
상기와 같은 문제점을 해결하기 위한 본 발명의 다른 목적은, 테스트 케이스를 이용한 테스트 장치를 제공하는 데 있다.
상기 목적을 달성하기 위한 본 발명은, 테스트 케이스를 이용한 테스트 방법을 제공한다.
여기서, 테스트 케이스를 이용한 테스트 방법은, 심볼릭 실행(symbolic execution)에 기초하여 SQL(Structured Query Language)문을 포함하는 소스 코드에 대한 테스트 케이스를 생성하는 단계 및 데이터베이스와 연동하는 테스트 대상 시스템에 테스트 케이스를 적용하여 테스트를 수행하는 단계를 포함한다.
여기서, 테스트 케이스는 테스트 대상 시스템의 입력값, 입력값이 테스트 대상 시스템에서 처리될 때 출력값을 예측한 예상출력값, 데이터베이스의 설정값 및 테스트 대상 시스템이 설정값이 적용된 데이터베이스와 연동하여 처리될 때 데이터베이스에 저장될 결과값을 예측한 예상결과값 중 적어도 하나를 포함할 수 있다.
여기서, 테스트 케이스를 생성하는 단계는, 소스 코드에 대하여 적어도 하나 이상의 프로그램 경로를 결정하는 단계, 적어도 하나 이상의 프로그램 경로에 따라 심볼릭 실행을 수행하는 단계 및 심볼릭 실행에 따라 생성된 논리식에 대하여 솔버를 이용하여 테스트케이스를 생성하는 단계를 포함할 수 있다.
여기서, 프로그램 경로를 결정하는 단계는, 소스 코드를 파싱하여 요약 구문 트리(Abstract Syntax Tree, AST)를 생성하는 단계, 생성된 요약 구문 트리를 기초로, 제어 흐름 그래프(Control Flow Graph, CFG)를 생성하는 단계 및 제어 흐름 그래프를 기초로 적어도 하나 이상의 프로그램 경로를 결정하는 단계를 포함할 수 있다.
여기서, 심볼릭 실행을 수행하는 단계는, 적어도 하나 이상의 프로그램 경로에 SQL문이 포함된 경우, 소스 코드의 호스트 변수와 SQL문에 따라 데이터베이스에 포함된 테이블의 컬럼을 매핑하는 단계를 포함할 수 있다.
여기서, 매핑하는 단계는, SQL문을 파싱하여 테이블을 확인하는 단계, 확인된 테이블을 구성하는 컬럼을 데이터베이스의 메타 데이터를 이용하여 획득하는 단계 및 획득된 컬럼을 소스 코드의 호스트 변수와 매핑하는 단계를 포함할 수 있다.
여기서, 테스트 케이스를 생성하는 단계 이후에, 생성된 테스트 케이스를 XML, JSON 중 하나의 포맷으로 저장하는 단계를 더 포함할 수 있다.
여기서, 테스트를 수행하는 단계는, 테스트 대상 시스템이 모듈인 경우, 설정값을 데이터베이스에 적용하는 단계, 입력값으로 테스트 대상 시스템의 입력 파라미터를 설정하는 단계, 설정된 입력 파라미터로 테스트 대상 시스템의 함수를 호출하는 단계 및 함수 호출의 결과로 획득된 테스트 대상 시스템의 출력값을 예상출력값과 비교하고, 데이터베이스에 저장된 결과값과 예상결과값을 비교하는 단계를 포함할 수 있다.
여기서, 테스트를 수행하는 단계는, 테스트 대상 시스템이 미들웨어 서비스인 경우, 테스트 케이스를 이용하여 입력 전문을 생성하는 단계, 테스트 대상 시스템이 연동되는 미들웨어(middleware)의 서비스를 호출하여 입력 전문을 미들웨어에 전송하는 단계 및 미들웨어로부터 테스트 결과 전문을 수신하는 단계를 포함할 수 있다.
여기서, 미들웨어는, 입력 전문으로부터 테스트 케이스의 데이터베이스 설정값을 확인하고, 확인된 데이터 베이스 설정값을 이용하여 데이터베이스에 대한 초기 설정을 수행하고, 입력 전문으로부터 테스트 케이스의 입력값을 확인하고 테스트 대상 시스템의 입력 파라미터로 입력하여 테스트 대상 시스템을 실행하도록 구성될 수 있다.
여기서, 예상출력값은, 테스트 대상 시스템의 실행시마다 출력값이 변경되는 경우, 테스트 케이스에서 제외되거나 매크로, 참조, 스크립트 중 하나의 방법으로 결정될 수 있다.
상기 다른 목적을 달성하기 위한 본 발명의 일 측면은 테스트 케이스 생성 장치를 제공한다.
여기서, 테스트 케이스 생성 장치는, 적어도 하나의 명령(instruction)을 실행하는 프로세서(processor) 및 적어도 하나의 명령을 저장하는 메모리(memory)를 포함하고, 프로세서는, 심볼릭 실행(symbolic execution)에 기초하여, SQL(Structured Query Language)문을 포함하는 소스 코드에 대해 적어도 하나 이상의 프로그램 경로를 결정하고, 적어도 하나 이상의 프로그램 경로에 따라 심볼릭 실행을 수행하고, 심볼릭 실행에 따라 생성된 논리식에 대하여 솔버를 이용하여 테스트케이스를 생성할 수 있다.
여기서, 프로세서는, 소스 코드를 파싱하여 요약 구문 트리(Abstract Syntax Tree, AST)를 생성하고, 생성된 요약 구문 트리를 기초로, 제어 흐름 그래프(Control Flow Graph, CFG)를 생성하고, 제어 흐름 그래프를 기초로 적어도 하나 이상의 프로그램 경로를 결정할 수 있다.
상기 다른 목적을 달성하기 위한 본 발명의 일 측면은 테스트 케이스를 이용한 테스트 장치를 제공한다.
여기서, 테스트 케이스를 이용한 테스트 장치는, 적어도 하나의 명령(instruction)을 실행하는 프로세서(processor), 적어도 하나의 명령을 저장하는 메모리(memory)를 포함한다.
여기서, 프로세서는, 심볼릭 실행(symbolic execution)에 기초하여 SQL(Structured Query Language)문을 포함하는 소스 코드에 대한 테스트 케이스를 생성하고, 데이터베이스와 연동하는 테스트 대상 시스템에 테스트 케이스를 적용하여 테스트를 수행하고, 테스트 케이스는 테스트 대상 시스템의 입력값, 입력값이 테스트 대상 시스템에서 처리될 때 출력값을 예측한 예상출력값, 데이터베이스의 설정값 및 테스트 대상 시스템이 설정값이 적용된 데이터베이스와 연동하여 처리될 때 데이터베이스에 저장될 결과값을 예측한 예상결과값 중 적어도 하나를 포함할 수 있다.
여기서, 프로세서는, 소스 코드에 대하여 적어도 하나 이상의 프로그램 경로를 결정하고, 적어도 하나 이상의 프로그램 경로에 따라 심볼릭 실행을 수행하고, 심볼릭 실행에 따라 생성된 논리식에 대하여 솔버를 이용하여 테스트케이스를 생성할 수 있다.
여기서, 프로세서는, 소스 코드를 파싱하여 요약 구문 트리(Abstract Syntax Tree, AST)를 생성하고, 생성된 요약 구문 트리를 기초로, 제어 흐름 그래프(Control Flow Graph, CFG)를 생성하고, 제어 흐름 그래프를 기초로 적어도 하나 이상의 프로그램 경로를 결정할 수 있다.
여기서, 프로세서는, 적어도 하나 이상의 프로그램 경로에 SQL문이 포함된 경우, 소스 코드의 호스트 변수와 SQL문에 따라 데이터베이스에 포함된 테이블의 컬럼을 매핑할 수 있다.
여기서, 프로세서는, SQL문을 파싱하여 테이블을 확인하고, 확인된 테이블을 구성하는 컬럼을 데이터베이스의 메타 데이터를 이용하여 획득하고, 획득된 컬럼을 소스 코드의 호스트 변수와 매핑할 수 있다.
여기서, 프로세서는 생성된 테스트 케이스를 XML, JSON 중 하나의 포맷으로 저장할 수 있다.
여기서, 프로세서는, 테스트 대상 시스템이 모듈인 경우, 설정값을 데이터베이스에 적용하고, 입력값으로 테스트 대상 시스템의 입력 파라미터를 설정하고, 설정된 입력 파라미터로 테스트 대상 시스템의 함수를 호출하고, 함수 호출의 결과로 획득된 테스트 대상 시스템의 출력값을 예상출력값과 비교하고, 데이터베이스에 저장된 결과값과 예상결과값을 비교할 수 있다.
여기서, 프로세서는, 테스트 대상 시스템이 미들웨어 서비스인 경우, 테스트 케이스를 이용하여 입력 전문을 생성하고, 테스트 대상 시스템이 연동되는 미들웨어(middleware)의 서비스를 호출하여 입력 전문을 미들웨어에 전송하고, 미들웨어로부터 테스트 결과 전문을 수신할 수 있다.
상기와 같은 본 발명에 따른 테스트 케이스를 이용한 테스트 방법 및 장치를 이용할 경우에는 반복적으로 테스트 가능한 테스트 케이스를 제공할 수 있고 이로 인해 회귀 오류를 찾을 수 있는 회귀 테스트에 사용될 수 있는 장점이 있다.
또한, 프로그램에 포함된 임베디드 SQL 문을 고려하여 테스트 케이스를 생성할 수 있어 데이터베이스와 연계된 시스템에 대한 테스트가 용이한 장점이 있다.
또한, 테스트 케이스를 자동으로 생성하므로 테스트에 소요되는 노력과 시간이 획기적으로 절감될 수 있다.
도 1은 본 발명의 일 실시예에 따른 테스트 케이스를 이용한 테스트 방법 에 대한 개념도이다.
도 2는 본 발명의 일 실시예에 따른 테스트 케이스를 이용한 테스트 방법의 흐름도이다.
도 3은 본 발명의 일 실시예에 따른 프로그램 경로에 따라 심볼릭 실행을 수행하는 단계를 구체화한 흐름도이다.
도 4는 본 발명의 일 실시예에 따른 요약 구문 트리(abstract syntax tree, AST)를 설명하기 위한 개념도이다.
도 5는 본 발명의 일 실시예에 따른 테스트 케이스를 도출하기 위한 소스 코드의 예시도이다.
도 6은 본 발명의 일 실시예에 따른 제어 흐름 그래프(control flow graph, CFG)를 설명하기 위한 개념도이다.
도 7은 경로 6에 대한 심볼릭 실행 과정을 시뮬레이션한 결과를 나타낸 것이다.
도 8은 본 발명의 일 실시예에 따른 테스트를 수행하는 과정에 대한 제1 예시도이다.
도 9는 본 발명의 일 실시예에 따른 테스트를 수행하는 과정에 대한 제2 예시도이다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.
제1, 제2, A, B 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
이하, 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.
도 1은 본 발명의 일 실시예에 따른 테스트 케이스를 이용한 테스트 방법 에 대한 개념도이다.
도 1을 참조하면, 본 발명의 일 실시예에 따른 테스트 케이스를 이용한 테스트 방법은 심볼릭 실행기(Symbolic Executor, 10), 테스트 매니저(Test Manager, 20), 세부 실행기(Concrete Executor, 40)을 포함하는 테스트 장치에 의해 수행될 수 있다.
여기서, 테스트 장치는 내부 또는 외부에 별도의 테스트 데이터베이스(30)을 포함할 수 있다.
본 발명의 일 실시예에 따른 테스트 방법을 설명하면, 먼저 테스트 매니저(20)는 테스터로부터 테스트 케이스 생성 요청을 입력받거나 수신할 수 있다. 테스트 매니저(20)는 심볼릭 실행기(10)에게 테스트케이스 생성을 요청할 수 있다. 테스트 케이스 생성을 요청받은 심볼릭 실행기(10)는 형상관리로부터 소스 코드를 다운로드한다. 여기서, 형상관리는 개발 과정에서 소스 코드나 데이터베이스의 테이블 등이 수시로 변경되더라도 변경사항을 반영하여 테스트가 가능하도록 최신 소스 코드로 관리할 수 있고, 소스 코드는 SQL(structured querylanguage)문을 포함하고 있는 것으로 해석될 수 있다. 또한, 여기서 다운로드되는 소스 코드는 개발자에 의해 직접 심볼릭 실행기(10)에 입력될 수도 있다.
심볼릭 실행기(10)는 테스트 케이스를 생성하고 테스트 매니저(20)에게 전송할 수 있다. 테스트 매니저(20)는 전송받은 테스트 케이스를 테스트 DB(30)에 저장할 수 있다. 여기서 저장된 테스트 케이스는 테스터가 테스터 매니저(20)를 통해 조회를 요청하면, 테스트 매니저(20)를 통해테스터에게 제공될 수 있다.
테스트 매니저(20)는 세부 실행기(40)에 테스트 실행을 요청할 수 있다. 실행을 요청받은 세부 실행기(40)는 테스트 DB(30)로부터 테스트 케이스를 조회할 수 있고, 조회된 테스트 케이스로부터 테스트 대상 시스템(System Under Test, SUT, 60)과 연동하는 데이터베이스(50)에 대하여 테스트를 위한 설정값을 적용할 수 있다. 여기서, 테스트를 위한 설정값은 테스트 대상 시스템(60)이 데이터베이스(50)와 연동하여 동작하기 위하여 데이터베이스(50)에 저장되어야 하는 초기값을 의미할 수 있고, 경우에 따라서 초기값은 없거나 Null일수도 있다.
세부 실행기(40)는 조회된 테스트 케이스로부터 입력값을 테스트 대상 시스템(60)에 입력하여 테스트 대상 시스템(60)의 출력값을 획득할 수 있다.
또한, 테스트 대상 시스템(60)이 입력값을 받아서 동작하면 테스트 대상 시스템과 연동하는 데이터베이스(50)에도 새로운 결과값이 저장될 수 있고, 따라서, 세부 실행기(40)는 데이터베이스에서의 결과값 또한 획득할 수 있다.
세부 실행기(40)는 획득된 테스트 대상 시스템(60)의 출력값과 데이터베이스(50)의 결과값을 테스트 DB(30)에 저장된 확인값과 대조할 수 있고, 대조과정을 통하여 테스트 대상 시스템(60)의 오류 여부를 진단하고 파악할 수 있다.
그 후, 세부 실행기(40)는 테스트 결과를 테스트 DB(30)에 저장할 수 있고, 테스트 매니저(20)에게 테스트 결과를 반환할 수 있다. 테스트 매니저(20)는 반환된 테스트 결과를 테스터에게 제공할 수 있다.
이와 같은 수행 절차를 통해서, 테스트 케이스를 생성하고, 저장하고, 실행하고, 테스트 결과를 저장하고, 그리고 테스트 결과의 통계와 리포트를 제공하는 등 일련의 테스트 생명 주기를 지원할 수 있다.
여기서, 심볼릭 실행기(10)는 심볼릭 연산 수행시 SQL 쿼리문을 이해하는데 필요한 테이블의 컬럼들과 각 컬럼의 제약사항들을 얻기 위해서 데이터베이스(50)가 제공하는 메타 정보를 사용할 수 있다.
테스트 매니저(20)는 테스트 경로와 그에 따른 테스트 케이스 및 테스트 결과값을 국제 표준인 XML(Extensible Markup Language) 형식으로 테스트 DB(30)에 저장하여 관리할 수 있다.
또한, 여기서 최신 소스 코드를 반영한 테스트 케이스를 이용하여 테스트가 진행될 수 있도록 테스트 케이스와 테스트 대상 시스템(60)의 동기화가 요구될 수 있는데, 테스트 대상 시스템(60)이 변경될 때마다 형상관리로부터 확인하여 테스트 케이스를 생성해 둘 수도 있으며, 테스트 요청시에만 형상관리로부터 최신 여부를 확인하여 테스트 케이스를 생성할 수 있다.
구체적으로, 테스트 매니저(20)가 사용자 또는 관리자로부터 테스트 요청을 받으면, 테스트 DB(30)에 테스트 케이스가 생성되어있는지 확인한 후, 테스트 케이스가 있고 새로운 수정사항이 없는 경우(또는 최신 소스 코드에 대하여 생성된 테스트 케이스인 경우)라면, 세부 실행기(40)에게 테스트 대상 시스템(60)과 테스트 케이스의 식별기호를 전달하면서 테스트를 요청할 수 있다. 또한, 테스트 DB(30)에 테스트 케이스가 없거나, 최신의 테스트 대상 시스템(60)을 기준으로 생성된 테스트 케이스가 아니라면, 심볼릭 실행기(10)에게 테스트 케이스 생성을 요청할 수 있다.
세부 실행기(40)는 테스트를 실행하기 위해서 테스트 DB(30)에 저장된 테스트 케이스를 인출하고, 그 값들로 드라이버나 전문을 생성하여 테스트를 실행하며, 테스트 결과값을 테스트 DB(30)에 저장하고 관리할 수 있다.
형상관리는 테스트 대상이 되는 소스 코드를 모두 관리하는데, 심볼릭 실행기(10)는 최신 소스 코드를 대상으로 하여 테스트 케이스를 생성할 수 있다.
테스트 대상 시스템(60)은 테스트하기 위한 모듈이나 서비스일 수 있다.
예를 들면, 모듈은 소스 코드, 오브젝트, 정적 라이브러리, 그리고 동적 라이브러리와 같은 형태로 존재할 수 있다. 또한 서비스는 미들웨어 기반 하에서 실행되는 바이너리 형태의 프로그램일 수 있다. 서비스는 전문을 통해 테스트를 수행할 수 있다.
전문은 위치 기반형과 태그 기반 형이 있는데 위치 기반 형 전문에서는 데이터의 위치와 길이에 의해서 데이터의 의미가 정의될 수 있고, 태그 기반 형 전문은 태그에 의해서 데이터의 의미가 정의되며, JSON(JavaScript Object Notation)과 XML(Extensible Markup Language)과 같은 형태가 있을 수 있다.
테스트 매니저(20)는 개발자, 품질 보증 담당자, 그리고 프로젝트 관리자에게 다양한 테스트 결과를 통계 및 현황 리포트 형태로 제공할 수 있다. 이러한 리포트에는 프로젝트별 테스트 현황, 업무 별 테스트 현황, 모듈 또는 서비스별 테스트 현황, 그리고 결함을 제외하거나 결함을 조치한 결과들이 나타날 수 있다.
또한, 테스트 매니저(20)는 단위 테스트, 통합 테스트, 그리고 회귀 테스트를 지원할 수 있다. 단위 테스트용으로 생성한 테스트 케이스는 통합 테스트와 회귀 테스트에서도 사용될 수 있다. 통합 테스트는 시나리오로 구성되는데 이것은 단위 테스트 케이스를 순서대로 엮어서 구성할 수 있다. 단위 테스트 케이스를 시나리오로 엮기 위해서는 이전 테스트 케이스의 실제출력값을 입력값으로 매핑해야 할 수 있다. 그리고 예상출력값에는 입력값을 매핑할 수 있는 산술식이 제공될 수 있다. 회귀 테스트에서 사용할 테스트 케이스는 단위 테스트의 테스트 케이스를 수정 없이 사용할 수 있으나, 회귀 분석에 따른 다양한 테스트 케이스의 선택 방법이 필요할 수 있다. 즉, 회귀 분석의 범위는 프로그램 의존 관계에 의한 테스트케이스 선택, 함수 의존 관계에 의한 테스트 케이스 선택, 그리고 영향 받는 테스트 케이스만 선택하는 등의 기술이 적용될 수 있다.
여기서, 심볼릭 실행기(10), 테스트 매니저(20), 세부 실행기(40)는 설명의 편의를 위하여 각 구성부로 설명하였으나, 각각 개별 장치로 구현되는 것뿐만 아니라, 일부가 결합하여 하나의 장치에서 구현될 수 있는 것으로 이해되어야 하고 본 실시예에 한정하여 해석되지 않는다.
도 2는 본 발명의 일 실시예에 따른 테스트 케이스를 이용한 테스트 방법의 흐름도이다.
도 2를 참조하면, 테스트 케이스를 이용한 테스트 방법은 심볼릭 실행(symbolic execution)에 기초하여 SQL(Structured Query Language)문을 포함하는 소스 코드에 대한 테스트 케이스를 생성하는 단계(S200) 및 데이터베이스와 연동하는 테스트 대상 시스템에 테스트 케이스를 적용하여 테스트를 수행하는 단계(S300)를 포함할 수 있다.
여기서, 테스트 케이스는 테스트 대상 시스템의 입력값, 입력값이 테스트 대상 시스템에서 처리될 때 출력값을 예측한 예상출력값, 데이터베이스의 설정값 및 테스트 대상 시스템이 설정값이 적용된 데이터베이스와 연동하여 처리될 때 데이터베이스에 저장될 결과값을 예측한 예상결과값 중 적어도 하나를 포함할 수 있다.
구체적으로 다시 설명하면, 입력값은 함수의 입력 파라미터에 대응되는 값일 수 있고, 예상출력값은 함수가 실행된 후 반환되는 결과를 확인하기 위해 출력 파라미터에 대응되는 값일 수 있으며, 설정값은 테스트 대상 시스템이 데이터베이스와 연동하여 동작하기 위해 데이터베이스에 저장되어야 하는 초기값일 수 있으며, 예상결과값은 테스트 대상 시스템이 데이터베이스와 연동하여 동작한 결과물로서 데이터베이스에 저장될 수 있는 값일 수 있다.
또한, 입력값과 예상출력값 또는 예상결과값은 함수의 입력 파라미터나 리턴 형식(또는 출력 파라미터) 또는 데이터베이스에 저장된 데이터 형식(data type)에 따라 정수(integer)나 문자열(string) 등의 형식(type)을 가질 수 있으며, 데이터베이스 설정값은 INSERT, UPDATE 그리고 DELETE 문 중 적어도 하나로 구성된 SQL 쿼리문일 수 있다.
또한, 입력값, 예상출력값, 데이터베이스의 설정값 및 예상결과값 중 적어도 하나를 포함하는 테스트 케이스는 JSON(JavaScript Object Notation)과 XML(Extensible Markup Language) 중 하나의 포맷으로 저장될 수 있다. 단 이에 한정되는 것은 아니고, 문자열, 바이너리 등의 형태로 저장될 수도 있다.
여기서, 소스 코드는 테스트 대상 시스템의 소스 코드를 의미할 수 있다.
또한, 소스 코드는 SQL 문을 포함할 수 있는데, 여기서 사용되는 소스 코드는 JAVA, Swift, Object C 등을 포함한 상용언어로 작성된 코드를 모두 포함할 수 있으며, 경우에 따라서는 상용언어에서 일부 구문을 제거하여 개별적으로 정의한 언어일 수 있다. 특히 여기에 포함된 SQL 문은 임베디드 SQL로 정의될 수도 있으며, 예를 들면 Oracle의 PL/SQL, PostgreSQL의 ECPG, Sybase의 ASE 등이 있을 수 있고, 이러한 임베디드 SQL이 지원하는 언어에는 C/C++, COBOL, PL/1 등이 있을 수 있다.
본 발명의 예시 소스코드는 상용언어에서 설명의 편의를 위하여 일부 구문을 제거하여 기술하였으나, 이에 한정되지 않으며, 각종 프로그래밍 언어 모두 적용될 수 있다.
여기서, 테스트 대상 시스템은 데이터베이스를 사용하는 정보 시스템일 수 있고, 여기서, 데이터베이스는 하나 이상의 레코드를 저장하고 레코드에 대하여 적어도 하나 이상의 속성을 갖는 테이블을 저장할 수 있다.
여기서 본 발명의 일 실시예에 따른 테스트 대상 시스템은 데이터베이스와 연동되는 업무용 이자 계산 프로그램을 예로 들어 설명하나, 특정 시스템에 한정되는 것이 아니며, 업무용 이자 계산 프로그램의 예제 소스 코드는 이하에서 도 5를 참조할 수 있다.
여기서, 심볼릭 실행이란, 프로그램을 분석하기 위하여 실제 특정한 값 대신에 심볼로 정의된 값을 이용하는 것으로서, 이하 예제 소스 코드를 기초로 설명한다.
Figure PCTKR2018002452-appb-T000001
표 1을 참조하면, 예제 소스 코드에 대하여 심볼릭 실행을 설명할 수 있는데, 먼저 입력 파라미터로 정의되는 a에는 심볼값으로 A가 할당될 수 있다. 따라서, 산술식 b=a*10+1은 b=A*10+1이 되고, 이것이 변수 b 대신에 그대로 할당될 수 있으며, 조건문 if식이 성립되는 경우를 A를 기준으로 계산하면 A != 3인 경우가 되므로 A는 3을 제외한 각종 정수(int)가 도출될 수 있다.
반대로, 조건문 if식이 성립되지 않는 경우(else 구문)을 A를 기준으로 계산하면 A가 3인 경우(A==3)가 심볼릭 A로 3이 도출될 수 있다.
여기서, 위와 같이 심볼값으로 구성된 조건식에 대한 계산은 다양한 솔버(solver)를 이용할 수 있다. 예를 들면, 마이크로소프트에서 연구용으로 사용할 수 있도록 공개한 Z3를 사용할 수 있다.
한편, 심볼식이 예를 들어 a*b=10이나 sin(a)=1 과 같이 비선형(nonlinear)식으로 이루어진 경우에 솔버로 계산이 어려울 수 있는데, 이러한 때에는 심볼값 중 하나에 실제 특정 값을 할당하는 방법 등을 이용하여 선형 조건으로 변경함으로써 해결할 수 있다.
여기서, 테스트 대상 시스템과 연동된 데이터베이스에 저장된 테이블의 예를 들면, 다음의 표 2와 같을 수 있다.
Figure PCTKR2018002452-appb-T000002
표 2를 참조하면, 데이터베이스에 저장된 계좌 테이블을 확인할 수 있는데, 계좌번호, 대출 금액 등의 속성에 대한 정보가 저장될 수 있다.
여기서, 계좌 테이블에 저장된 계좌 데이터의 예를 들면 다음의 표 3과 같을 수 있다.
Figure PCTKR2018002452-appb-T000003
표 3을 참조하면, 데이터베이스에 저장된 계좌 데이터를 확인할 수 있는데, 앞서 표 2에서의 계좌번호, 대출 금액 등에 대한 값이 저장될 수 있다.
한편, 테스트 대상 시스템과 연동된 데이터베이스 테이블은 하나 이상일 수 있고, 업무용 이자 계산을 예로 설명하므로 이자 상환 테이블을 다음과 같이 가질 수 있다.
Figure PCTKR2018002452-appb-T000004
표 4를 참조하면, 계좌번호에 따른 상환일자 등이 이자 상환 테이블에 저장되어 있을 수 있다.
여기서, 이자 상환 테이블에 기록된 이자 상환 데이터는 다음과 같을 수 있다.
Figure PCTKR2018002452-appb-T000005
표 5를 참조하면, 각 계좌번호에 따라 상환 일자와 이자가 저장되어 있을 수 있다.
여기서, 테스트 케이스를 생성하는 단계(S200)는, 소스 코드에 대하여 적어도 하나 이상의 프로그램 경로를 결정하는 단계(S210) 적어도 하나 이상의 프로그램 경로에 따라 상기 심볼릭 실행을 수행하는 단계(S220) 및 심볼릭 실행에 따라 생성된 논리식에 대하여 솔버(solver)를 이용하여 테스트케이스를 생성하는 단계(S230)를 포함할 수 있다.
이하에서 도면을 참조하여 각 단계를 상세히 설명할 수 있다.
도 3은 본 발명의 일 실시예에 따른 프로그램 경로를 결정하는 단계를 구체화한 흐름도이다. 도 4는 본 발명의 일 실시예에 따른 요약 구문 트리(abstract syntax tree, AST)를 설명하기 위한 개념도이다. 도 5는 본 발명의 일 실시예에 따른 테스트 케이스를 도출하기 위한 소스 코드의 예시도이다. 도 6은 제어 흐름 그래프(control flow graph, CFG)를 설명하기 위한 개념도이다.
도 3을 참조하면, 도 2의 프로그램 경로를 결정하는 단계(S210)는, 소스 코드를 파싱하여 요약 구문 트리(Abstract Syntax Tree, AST)를 생성하는 단계(S211), 생성된 요약 구문 트리를 기초로, 제어 흐름 그래프(Control Flow Graph, CFG)를 생성하는 단계(S212) 및 상기 제어 흐름 그래프를 기초로 적어도 하나 이상의 프로그램 경로를 결정하는 단계(S213)를 포함할 수 있다.
요약 구문(abstract syntax)은 연산자로 구성된 요약 구문 트리(AST)를 귀납적으로 정의한 것으로, 요약 구문은 연산자를 사용하여 소스 코드의 구문(syntax)이 갖는 모호함을 제거할 수 있다. 또한, 요약 구문 트리는 다른 요약 구문 트리를 생성자와 연산자로 조합하여 생성할 수 있다.
구체적인 요약 구문 트리 및 요약 구문에 대한 것은 R.Harper(Harper, R., 2005, op. cit. )를 참조할 수 있다.
도 4를 참조하면, 요약 구문 트리는 구조체의 형태(400)로도 표현할 수 있고, 이를 이해하기 편리하게 도식화하면 도식화된 형태(410)로도 표현할 수 있다.
구체적으로 요약 구문 트리는 트리 구조인데, 다양한 형태로 트리가 표현될 수 있다. 예를 들면 ArrayList나 List, Map과 같은 데이터 구조를 이용하여 구현할 수 있다.
도 4에 구조체의 형태(400)와 도식화된 형태(410)를 상호 비교하여보면, 최상위 노드는 <Program>일 수 있다. 여기서 <Program>은 1개 이상의 함수 즉 리스트(List)로 구성될 수 있다. 함수는 반환 타입, 함수명, 파라미터들, 그리고 블락 선언으로 구성될 수 있다. 파라미터는 타입과 변수명으로 구성될 수 있다. 블락 선언은 0개 이상의 문장으로 구성될 수 있다. 문장은 로컬변수 선언문, 할당문, if문, 쿼리문 등으로 구성될 수 있다. 여기서, 본 발명의 일 실시예에 따르면 SQL 쿼리문을 포함한 소스 코드를 대상으로 하므로, 쿼리문을 포함해서 심볼릭 연산을 실행하는 것이 가장 중요한 요소일 수 있다.
도 4에 따른 요약 구문 트리에서 프로그램 경로를 결정하려면, 요약 구문 트리 자체가 이미 트리 구조이긴 하지만, 다중 노드를 가지므로 여기서 프로그램 경로를 결정하기엔 어려울 수 있다.
따라서, 제어 흐름 그래프(Control Flow Graph, CFG)를 도입할 수 있다. 제어 흐름 그래프는 실행 중에 프로그램을 통과하는 모든 경로를 그래프로 표기할 수 있다. 그래프에서 각 노드는 기본 블락(basic block)을 나타내고 화살표는 점프(jump)를 나타내기 위해서 사용할 수 있다. 그래프는 하나의 진입 블락(entry block)과 종료 블락(exit block)를 가질 수 있다. 화살표인 모든 선은 Outdegree(A) > 1 이거나 Indegree(B) > 1 (또는 양쪽)인 속성을 가질 수 있다.
또한, 프로그램 경로 결정은 무수히 많은 경로가 도출되는 경로 폭발(Path Explosion)이 발생할 수 있다. 경로 폭발 문제를 해결하기 위해서 독립적인 프로그램 경로를 사용할 수 있다. 독립적인 프로그램 경로란 특정한 경로의 조합이 아니고, 고유한 다른 경로와 차별화되는 되는 경로일 수 있다. 독립적인 프로그램 경로를 찾는 기법으로 기초 경로 테스팅(Basis Path Testing)이라는 화이트 박스 테스팅 기법을 사용할 수 있는데, 상세하게는 McCabe(McCabe, T.J., 1976, A Complexity Measure, IEEE Transactions on Software Engineering, Vol.SE-2, Issue 4)를 참조할 수 있다.
독립적인 프로그램 경로를 구하기 위해서 채용한 그래프 이론에 따르면 노드(Node)는 판단(Decision)과 프로세스(Process)를 더한 값일 수 있다. 그래프 이론에 의해서 독립적인 프로그램 경로를 계산하는 계산식은 다음과 같을 수 있다.
Figure PCTKR2018002452-appb-T000006
표 6을 참조하면, 독립한 프로그램 경로는 엣지의 수에서 노드의 수를 뺀 값(Edges-Nodes)에 2를 더하여 도출할 수 있고, 지역(Regions)의 개수에 1을 더하거나, 판단(Decisions) 개수에 1을 더한 값일 수 있다.
도 5와 도 6을 참조하면, 도 4에서의 요약 구문 트리를 이진 트리 형태로 단순화한 제어 흐름 그래프를 설명할 수 있다.
구체적으로, 도 4의 요약 구문 트리를 이용하여 도 5의 샘플 소스 코드를 도 6의 제어 흐름 그래프(500)로 생성할 수 있고, 생성된 제어 흐름 그래프의 경로를 방문하는 방법으로, 독립한 6개의 프로그램 경로(510)를 도출해 낼 수 있다.
여기서 도 6에 따른 프로그램 경로(510) 각각을 도출하는 것에는 도 5에 따른 샘플 소스 코드를 사용하였다. 도 5에서 각 줄의 번호는 구문 번호를 지시할 수 있고, 구문 번호 7에서 if 문에 각각의 조건식(accNo<0 , paydate<0) 성립 여부에 따라 7.1, 7.2로 나타내었고, if문을 만족하면 구문 번호 8로 경로가 이동할 수 있다. 또한, 구문번호 11 또한 조건문으로서 분기될 수 있고, 구문번호 14의 SQL문 또한 INSERT 여부에 따라 다른 경로로 분기될 수 있다.
이와 같이 각각의 구문에 따른 독립한 경로를 추적하면 도 6의 제어 흐름 그래프(500)와 그에 따른 프로그램 경로(510)를 도출할 수 있다.
여기서 도출해 낸 프로그램 경로는 구문 번호와 분기문인지 여부를 지시하는 정보가 추가될 수 있다. 구문 번호는 실행할 실제 구문을 가져오기 위해 사용될 수 있고, 분기문 여부는 해당 경로를 수행할 변수값에 대한 제약조건을 만들기 위하여 사용될 수 있다.
도 7은 경로 6에 대한 심볼릭 실행 과정을 시뮬레이션한 결과를 나타낸 것이다.
도 7을 참조하면, 도 2의 프로그램 경로에 따라 심볼릭 실행을 수행하는 단계(S220)를 상세하게 설명할 수 있다.
구체적으로, 도 7에서 (1), (2), (3), (4), 쪋 는 각각 도 5에서의 구문 번호를 지시할 수 있다. 원 소스 코드인 도 5와 심볼릭 실행 결과인 도 7을 서로 비교하면 도 5에서 구문 번호 1 내지 4 는 변수를 선언하는 구문이므로, 도 7의 (1) 내지 (4)는 변수 선언부의 변수를 심볼값으로 설정할 수 있다. 이를 적용하는 하나의 예로서, 변수의 선언부에 값이 없으면, 변수명을 대문자로 변환하고, 그 명칭을 심볼값으로 설정할 수 있고, 선언부에 값이 있으면 그 값을 초기값으로 설정할 수 있다.
심볼릭 실행이 진행되면 숫자값인 상수들은 계산되어 하나의 상수값이 될 수 있고, 심볼은 산술식에서 그대로 변수처럼 남을 수 있다. 결국 심볼릭 실행을 수행한 후에는 심볼들로 구성된 하나의 산술식이 만들어질 수 있다. 도 7에서 독립적인 경로를 만족하는 하나의 산술식은 (7)과 (11)의 논리식이 TRUE가 되는 경우일 수 있다. 이러한 심볼릭 실행의 결과로 생성된 논리식은 이후, 솔버에 의해 해당 논리식을 만족하는 값의 조건(제약 조건)을 도출하는 데 적용될 수 있다.
한편, 도 5의 구문번호 9 및 14와 같이 SQL 문이 포함되어 있는 경우, 심볼릭 실행을 수행할 때 몇 가지 추가적인 고려가 필요할 수 있다. 그 중 하나는 호스트 변수에 대한 분석 및 관리가 필요할 수 있다. 호스트 변수는 데이터베이스 컬럼과 매핑이 되어 데이터베이스에 값을 입력(또는 등록)하거나 데이터 베이스로부터 값을 조회하기 위해 사용될 수 있다. 또한 이 값은 반복적인 테스트가 가능하도록 데이터베이스 환경을 설정하는데 중요한 역할을 할 수 있다.
다음으로, SQL문에서 사용하는 WHERE 조건문의 결과에 주의할 필요가 있다. SELECT 문의 경우 조건을 만족하는 레코드가 있을 때와 없을 때 두 가지 경우를 추가적으로 고려할 수 있다. 그러므로 독립한 프로그램 경로에 SQL문이 몇 개가 있는지에 따라서 테스트 케이스의 개수가 달라질 수 있다. 예를 들면, 계좌 테이블에는 ACC_NO 컬럼의 값이 호스트 변수인 accNo가 갖는 값과 같은 레코드가 있을 수도 있고, 레코드가 없을 수도 있다. 그러므로 두 가지 경우를 고려해서 테스트 케이스를 만들고, 해당하는 테스트 케이스의 값을 계산할 수 있다.
SQL 문에서 사용하는 호스트 변수에 대해 고려할 사항들을 알아 보기 위해 네 종류의 SQL 문인 SELECT, UPDATE, INSERT, 그리고 DELETE문을 설명하면 다음과 같다. 이들 SQL 문에서 WHERE 조건절을 포함하고 있는 구문은 SELECT, UPDATE, 그리고 DELETE 세 개의 쿼리문이다. 이들 쿼리문의 조건절은 기존의 프로그래밍 언어와 비교하면 분기문에 해당하므로 경로 제약사항에 포함할 수 있다.
Figure PCTKR2018002452-appb-T000007
표 7을 참조하면, 샘플 소스 코드인 도 5에서의 구문번호 7과 9를 나타낸 것으로 구체적으로는if문의 샘플인 구문번호 7과 SQL문으로 작성된 SELECT문 샘플인 구문번호9를 나타낸다. SQL 쿼리문의 실행 결과가 정상적인 조회가 되려면 구문번호 7(if 문)의 경로 제약사항은 아래와 같이 변경되어야 할 수 있다.
!(accNo < 0 || payDate < 0)
구문 9에서 호스트 변수 :accNo가 가지는 값은 심볼릭 실행을 수행하면 결국 ACCNO라는 심볼값이 될 수 있다. 앞의 절차를 보면 심볼릭 실행은 설명의 편의를 위해서 2 패스로 실행하는 것으로 가정할 수 있다.
먼저, 첫번째 패스는 테스트 케이스를 생성하기 위한 패스이며 SQL 쿼리문의 WHERE절의 조건을 고려하여 패스를 세분화해야 할 수 있다. 경로 6은 SELECT문과 INSERT문의 실행 결과를 성공과 실패의 두 경우로 고려하면 이것들의 조합으로 나올 수 있는 경로는 3개가 된다. SELECT와 INSERT의 쌍을 고려하면 성공과 성공, 성공과 실패, 실패와 실패(또는 성공)의 3가지 경우이다. 단순 조합으로는 4가지 경우가 나오지만 SELECT가 실패이면 INSERT문은 아무런 영향을 줄 수 없어 제외할 수 있다.
한편, 심볼릭 실행의 파싱 단계에서 SQL 쿼리문을 만나면 SQL쿼리문을 파싱하여 FROM 절에서 사용하는 테이블들을 찾고, 그 테이블을 구성하는 모든 컬럼을 업무 데이터베이스의 메타 데이터에서 가져올 수 있다.
Figure PCTKR2018002452-appb-T000008
표 8을 참조하면, Oracle DBMS의 경우 데이터베이스의 메타 데이터에서 테이블명을 조건으로 하여 모든 컬럼을 조회하는 SELECT 쿼리문을 확인할 수 있다.
Figure PCTKR2018002452-appb-T000009
표 9를 참조하면 MySQL에서 테이블명과 스키마명으로 메타 데이터인 컬럼 정보를 조회하는 SELECT 쿼리문을 확인할 수 있다.
테이블의 모든 컬럼에 대한 메터 정보를 데이터베이스에서 조회한 다음에는 컬럼과 값을 매핑하는 테이블에 저장할 수 있다.
Figure PCTKR2018002452-appb-T000010
표 10을 참조하면, 표 2의계좌 테이블에 대한 컬럼과 호스트변수 매핑 테이블을 확인할 수 있다. 이 테이블의 컬럼들은 문장번호, 테이블명, 컬럼/상수, 호스트변수명, 구분, 항목여부, 그리고 값으로 구성될 수 있다. 여기서 컬럼/상수는 컬럼명 또는 상수 값을 가질 수 있다. 상수 값을 가지는 경우는 상술한 표 7에서와 같이 100의 값이addin에 설정되는 경우를 가정할 수 있다.
SQL 쿼리문에 WHERE 조건이 K=? 인 경우를 예로 들면, ?는 호스트 변수, 상수, 그리고 컬럼 중에 하나가 될 수 있다. 만일 ?가 호스트변수라면 호스트변수의 값은 순서 상 앞에서 설정된 값이므로 심볼릭 실행 중에 해당 SQL 쿼리문의 식을 계산하는 시점의 값을 찾는다. 호스트 변수의 값은 상수 값일 수도 있고, 심볼로 구성된 산술식일 수도 있다. 만일 ?가 상수라면 즉시 K 컬럼에 해당하는 값을 할당한다. 그러나 ?가 심볼로 구성된 산술식이라면 이 시점에 산술식에 대한 값을 계산해야 한다. 만일 ?가 컬럼이라면 join 쿼리인 경우에 발생할 수가 있으나 계산이 약간 복잡할 뿐이지 비슷한 방법으로 적용할 수 있다.
두 번째 패스는 심볼릭 실행을 하는 것이다.
Figure PCTKR2018002452-appb-T000011
표 11은 심볼릭 실행의 결과로 만들어지는 심볼 테이블이다. 심볼 테이블은 변수, 초기값, 그리고 심볼식으로 구성될 수 있다.
도 7에서 (7)번 라인을 실행할 경우 경로 제약조건은 아래와 같다.
PC1 : !(ACCNO < 0 || PAYDATE < 0)도 7에서 (9)번 라인을 실행하면 SELECT문의 FROM절에서 추출한 테이블인 ACC 테이블의 컬럼 목록을 구해서 다음의 표 12와 같이 컬럼과 INTO절의 변수 매핑 테이블을 만들 수 있다.
Figure PCTKR2018002452-appb-T000012
표 12를 참조하면, 현재 경로의 WHERE절이 true인 경우라고 가정하고 계산을 진행한 컬럼과 INTO절의 변수 매핑 테이블을 확인할 수 있다.
아래 표 13은 도 7의 (9)번 라인에 따른 SELECT문의 실행 결과 데이터베이스에서 조회된 값을 반영한 심볼 테이블이다.
Figure PCTKR2018002452-appb-T000013
표 13을 참조하면, 각 변수에 대하여 조회된 결과가 반영되는데, 예를 들면, loanAmt는 LOAN_AMT 컬럼에서 읽은 LOANAMTDB의 값이 될 수 있고, interestRate는 INTEREST_RATE 컬럼에서 읽은 INTERESTRATEDB 값이 될 수 있다.
한편, SELECT문의 WHERE 조건절에 대한 값을 구해 보면 WHERE 조건절에 서 사용되는 조건의 유형에 따라서 값을 구할 수 있다. 호스트 변수는 심볼릭 변수의 실행 시점에 해당하는 값을 심볼 테이블에서 찾아서 테이블 컬럼 구조체에 등록하거나 수정하고, 심볼 테이블에 없으면 값으로 설정할 수 있다. 이와 같은 작업이 모두 끝나면 심볼로 구성된 산술식을 다시 계산할 수 있다. 상수인 경우에는 컬럼의 값을 바로 <표 5>와 같이 컬럼과 호스트변수 매핑 테이블의 값 컬럼에 등록할 수 있다.
도 7의 10번 라인을 실행하면 days의 식은 아래와 같이 도출될 수 있다.
days = PAYDATE - LOANDATE
도 7의 11번 라인을 실행하면 경로 제약조건은 아래와 같이 도출될 수 있다.
PC3: PC2 AND days > 0
도 7의 13번 라인을 실행하면 interest의 식은 아래와 같이 도출될 수 있다.
interest = LOANAMT * INTERESTRATE/1000 * days / 365
위의 식에 days식을 대입하면 아래와 같이 같이 도출될 수 있다.
interest = LOANAMT * INTERESTRATE/1000 * (PAYDATE - LOANDATE) / 365
표 14는 도 7의 14번 라인을 실행한 매핑 테이블이다.
Figure PCTKR2018002452-appb-T000014
도 14를 참조하면, 이자 상환(REPAY) 테이블의 컬럼을 조회해서 이자 상환(REPAY) 테이블의 컬럼과 호스트변수 매핑 테이블을 생성할 수 있다.
마지막으로 도 7의 15번 라인을 실행하면 calcInterest의 식은 아래와 같이 도출될 수 있다.
calcInterest = LOANAMT * INTERESTRATE/1000 * (PAYDATE - LOANDATE) / 365
심볼릭 실행이 끝난 후에 테이블의 표 10과 표 14처럼 컬럼과 호스트변수 매핑 테이블에 있는 값이 하나의 심볼릭 변수인 경우에는 디폴트값을 선택하거나 데이터베이스에 설정되어 있는 제약사항에 정의된 값을 선택할 수 있다. 예로 LOAN_PERIOD의 값은 난수를 이용하여 양수 값을 구하거나 LOAN_TYPE의 값은 컬럼 제약사항에 선언된 값을 사용하거나 점검식에서 유효한 값을 유추할 수 있다.
정리하면, 도 2에서 심볼릭 실행을 수행하는 단계(S220)는, 적어도 하나 이상의 프로그램 경로에 SQL문이 포함된 경우, 소스 코드의 호스트 변수와 SQL 문에 따라 데이터베이스에 포함된 테이블의 컬럼을 매핑하는 단계를 포함할 수 있다.
여기서, 매핑하는 단계는, SQL문을 파싱하여 테이블을 확인하는 단계; 확인된 테이블을 구성하는 컬럼을 데이터베이스의 메타 데이터를 이용하여 획득하는 단계 및 획득된 컬럼을 소스 코드의 호스트 변수와 매핑하는 단계를 포함할 수 있다.
이하에서는, 도 2의 심볼릭 실행에 따라 생성된 논리식에 대하여 솔버(solver)를 이용하여 테스트케이스를 생성하는 단계(S230)를 구체적으로 설명한다.
솔버(solver)를 이용하여 테스트케이스를 생성하는 단계(S230)는 생성된 논리식을 SMT(Satisfiability Modulo Theories) 언어로 변환하는 단계를 더 포함할 수 있다. 이 단계는 솔버가 논리식에 따른 제약사항을 이해할 수 있는 형태로 변환하는 단계가 될 수 있다. 여기서 솔버는 예를 들면 마이크로소프트에서 공개한 Z3를 사용할 수 있다.
또한, SMT 언어로 변환하는 과정은 상세하게는 Moura(Moura, L. De, Bjørner, N., 2008, Z3: An Efficient SMT Solver, 14th International Conference, TACAS 2008, pp.337-340)와 Brummayer(Brummayer, R., Biere, A., 2009, Boolector: An Efficient SMT Solver for Bit-Vectors and Arrays, Proceedings of the 15th International Conference on Tools and Algorithms for the Construction and Analysis of Systems:Held as part of the Joint EuropeanConference on Theory and Practice of Software, pp.174-177)를 참조할 수 있다.
도 7을 다시 참조하면, 경로 6의 심볼릭 실행에서, 구문번호 11번 라인에서 계산해야할 제약사항은 (7)과 (11)을 모두 만족해야 하므로 아래와 같이 도출될 수 있다.PC2 AND days >0 => !(ACCNO < 0 || PAYDATE < 0) && !((PAYDATE -LOANDATEDB) < 0)
표 15는 상기 제약사항을 SMT 언어로 변환한 결과를 나타낸 것이다.
Figure PCTKR2018002452-appb-T000015
표 15를 참조하면, 제약사항을 솔버가 해석 가능한 형태인 SMT 언어로 변환된 스크립트를 확인할 수 있고, 변환된 스크립트를 솔버를 통해서 실행하면, 심볼릭 변수에 해당하는 값을 구할 수 있다. 먼저 함수의 입력과 출력에 해당하는 심볼의 값을 구할 수 있다. 앞선 예제에서 함수의 입력인 accNo와 payDate의 구체적인 값은 각각 ACCNO와 PAYDATE라는 심볼이 계산되어 도출될 수 있다. 또한, 여기서 LOANDATEDB는 심볼이 아니라 데이터베이스에서 조회한 상수값을 의미할 수 있다.
한편, 본 발명에서의 테스트 케이스는 데이터베이스와 연동하는 시스템에 적용될 수 있도록 데이터베이스 설정값을 포함할 수 있다. 따라서, 데이터베이스 설정값을 생성하는 방법을 이하에서 설명한다.
데이터베이스 설정값들은 INSERT, UPDATE, 또는 DELETE 문의 형태로 생성될 수 있다. 테스트 실행 시마다 업무 프로그램에서 사용하는 테이블에 대해 이들 쿼리문을 실행하여 테스트를 실행하기 직전의 데이터베이스 상태를 만들 수 있다.
Figure PCTKR2018002452-appb-T000016
SELECT문의 조회 결과가 있는 경우를 테스트하려면 표 16과 같은 쿼리문을 데이터베이스 설정값으로 생성할 수 있다. 테스트 실행 시점에 계좌 테이블에 데이터가 있어야 하는 경우로 테이블에 레코드가 없으면 INSERT문으로 새로 등록하고, 데이터가 있으면 UPDATE문으로 해당 레코드의 값을 수정할 수 있다.
Figure PCTKR2018002452-appb-T000017
SELECT 결과가 없는 경우를 테스트하기 위해서는 표 17과 같은 쿼리문을 생성할 수 있다. 계좌 테이블에 레코드가 있거나 없거나 관계없이 DELETE문을 실행하여 레코드를 확실하게 삭제할 수 있다.
Figure PCTKR2018002452-appb-T000018
도 7의 14번 라인의 INSERT문에 대한 중복 테스트를 하는 경우에 데이터베이스 환경을 설정하기 위해서는 표 18과 같은 쿼리문을 생성할 수 있다.
표 14를 참조하면, 테스트 실행 시점에 이자 상환(REPAY) 테이블에 레코드가 없으면INSERT문을 실행하여 레코드를 등록하고, 레코드가 있으면 UPDATE문을 실행하여 해당 레코드의 값을 변경할 수 있다.
Figure PCTKR2018002452-appb-T000019
표 19는 INSERT문에 대해 정상적으로 등록이 되는 경우를 테스트하기 위한 데이터베이스 환경을 설정하기 위한 쿼리문이다. 표 19를 참조하면, 이자 상환 테이블에 해당 레코드가 있는지 여부에 관계없이 테이블에서 레코드를 삭제하여 해당 레코드가 테이블에 존재하지 않도록 할 수 있다.
앞에서 도 6에서 도출한 프로그램 경로 6의 테스트 케이스는 3개가 되며 테스트 케이스는 SQL 쿼리문마다 대략 2의 배수로 늘어날 수 있다. 그래서 테스트 케이스 수는 산술적으로는 2쿼리개수 만큼 생성되고, 경로 6에 의해 생성된 테스트 케이스를 요약하면 다음의 표 20과 같다.
Figure PCTKR2018002452-appb-T000020
표 20을 참조하면, 테스트 케이스 6-1은 계좌를 보유하고 있으나 이자를 상환하지 않은 경우를 테스트할 수 있다. 이때 입력값은 테이블에 등록된 계좌번호인 12345678901234와 심볼릭 실행의 결과인 PAYDATE가 될 수 있다. 또한 데이터베이스 설정값은 INSERT문으로 계좌를 등록하고 DELETE문으로 이자 상환 이력을 삭제할 수 있으며 INSERT문의 LOAN_PERIOD와 LOAN_METHOD값은 임의의 값이나 계좌 테이블의 조회결과값으로 설정할 수 있다.
테스트 케이스 6-2는 계좌를 보유하고 이자를 상환한 경우를 테스트할 수 있다. 입력값은 6-1과 동일할 수 있으며, 데이터베이스 설정값은 계좌와 이자 상환 이력을 INSERT문으로 등록하는 것일 수 있다. 이때, REPAY_DATE는 TODAY라는 매크로를 사용하여 값을 설정할 수 있다. 테스트 케이스 6-3은 계좌가 없는 경우를 테스트할 수 있다. 따라서 이 경우에 입력값으로는 계좌테이블에 존재하지 않는 계좌번호인 0을 사용할 수 있고, 데이터베이스의 설정값으로는 계좌와 이자 상환 이력을 DELETE문으로 모두 삭제할 수 있다.
데이터베이스 설정값은 심볼릭 계산에 의해서 계산된 값도 있지만 심볼릭 계산으로 계산될 수 없는 항목도 존재할 수 있다. 이들을 자유 변수(free variables)라고 지칭할 수 있고, 어떠한 값이 오더라도 괜찮으나 가급적 현실적인 값을 생성할 수 있도록 데이터베이스의 제약사항이나 어플리케이션이 실행하면서 남긴 거래 로그 정보를 참고하여 실제에 가깝게 생성할 수 있다.
한편, 본 발명에 따른 테스트 케이스는 테스트의 정확성을 테스트할 수 있도록 입력값에 대응한 출력값을 확인할 수 있는 예상출력값(또는 예상결과값)과 테스트 결과 데이터베이스에 실제 저장되는 값을 확인할 수 있는 데이터베이스 예상결과값(또는 예상확인값)을 포함할 수 있다.
표 21은 테스트 결과를 확인할 수 있는 출력예상값과 데이터베이스 예상결과값에 대한 표이다.
Figure PCTKR2018002452-appb-T000021
표 21을 참조하면, 예상출력값(또는 예상결과값)은 함수의 반환값일 수 있다. 구체적으로, 6-1에서 예상출력값(또는 예상 결과값)인 calcInterest에 대한 값은 심볼릭실행의 결과값인 PAYDATE와 데이터베이스에서 조회된 값인 LOANAMTDB, LOANDATEDB, INTERESTRATEDB으로부터 도출될 수 있다.
또한, 데이터베이스 예상결과값(또는 예상확인값)은 SELECT문으로 생성될 수 있다. 데이터베이스 예상결과값은 SELECT문을 실행하여 나온 결과 값 a || b와 같이 구분자로 구분된 문자열을 || 구분자로 나누어 좌우의 값을 비교하여 데이터베이스의 예상결과값과 실제결과값이 같은지 확인하기 위해서 사용할 수 있다.
또한, 테스트케이스 6-2와 6-3은 예상결과값이 반환된 오류값으로서, 이때 데이터베이스 예상결과값(또는 예상확인값)은 표 20과 같이 생성하거나 아예 생성하지 않도록 선택할 수 있다.
정리하면, 자동으로 생성되는 테스트 케이스는 테스트의 결과를 확인하기 위해 입력값에 대응하여 예상출력값을 생성하고, 데이터베이스 설정값에 대응하여 데이터베이스 예상결과값을 생성할 수 있다. 또한, 도 2의 테스트 케이스를 생성하는 단계(S300) 이후에 생성된 테스트 케이스를 XML, JSON 중 하나의 포맷으로 저장하는 단계를 더 포함할 수 있다. 단 이에 한정되는 것은 아니고, 문자열, 바이너리 등의 형태로 저장될 수도 있다.
이때 테스트 케이스가 저장될 위치 정보는 info 태그를 부여하여 참조될 수 있고, info 태그가 가지고 있는 위치 정보인 경로, 파일명, 메소드명, 테스트 케이스 번호를 주키(primary key)로 하여 저장될 수 있다. 따라서, 테스트 케이스만을 관리하기 위하여 별도의 테스트 케이스 데이터베이스가 구현될 수 있다.
또한, 테스트 케이스는 테스트 대상 시스템이 변경됨에 따라 동기화되어야 할 필요가 있다
동기화 방법의 하나는 테스트 대상 시스템의 변경 즉시 모든 테스트 케이스를 변경하는 방법이고 다른 하나는 테스트를 실행하는 시점에 동기화하여 테스트 케이스를 변경하는 방법일 수 있다. 첫번째 방법은 항상 테스트 대상 시스템과 테스트 케이스가 일치하는 장점이 있으나 대량 변경이 있는 경우에는 테스트를 수행하는 전체 성능에 영향을 미치는 단점이 있을 수 있다. 두번째 방법은 실행 시점에 동기화를 수행하므로 테스트 실행 시간이 길어지는 단점이 있을 수 있다.
도 8은 본 발명의 일 실시예에 따른 테스트를 수행하는 과정에 대한 제1 예시도이다. 도 9는 본 발명의 일 실시예에 따른 테스트를 수행하는 과정에 대한 제2 예시도이다.
도 8 및 도 9를 참조하면, 테스트 대상 시스템의 형태에 따라 서로 다른 방법으로 테스트를 수행하는 과정을 설명할 수 있다.
본 발명에 따른 테스트 대상 시스템은 서비스이거나, 모듈일 수 있다.
먼저, 도 8을 참조하여 테스트 대상 시스템(SUT)이 모듈인 경우에 테스트를 수행하는 방법을 설명할 수 있다.
테스트를 수행할 때 실행되는 테스트 드라이버의 생성 방식은 테스트 대상 시스템의 형태에 따라서 달라질 수 있다. 테스트 대상 시스템의 형태는 소스 코드 형태 또는 오브젝트 형태, 그리고 공유 라이브러리 형태로 제공될 수 있다. 테스트 대상이 소스 코드 형태 또는 오브젝트 형태인 경우에는 테스트 대상을 포함해서 빌드(컴파일과 링크)를 수행해야 하므로 빌드 환경의 구성이 복잡해 질 수 있다. 이런 형태인 경우에는 테스트 대상이 테스트 드라이버와 한 몸으로 빌드되고 실행되어 테스트 대상에 오류가 있으면 테스트 빌드가 되지 않는 단점이 있다. 테스트 대상이 공유 라이브러리 형태인 경우에는 테스트 실행을 위해 모듈의 동적 호출을 이용할 수 있다. 해당 모듈의 공유 라이브러리가 존재한다는 것은 테스트 대상인 모듈에 오류가 없다는 것을 의미할 수 있다.
도 8을 참조하면, 본 발명에서 테스트 대상 시스템이 모듈인 경우의 테스트 수행 방법은 테스트 케이스에 포함된 데이터베이스 설정값을 테스트 대상 시스템의 데이터베이스에 적용하는 단계, 테스트 케이스에 포함된 입력값으로 테스트 대상 시스템의 입력 파라미터를 설정하는 단계, 설정된 입력 파라미터로 테스트 대상 시스템의 함수를 호출하는 단계 및 함수 호출의 결과로 테스트 대상 시스템의 출력값을 테스트 케이스에 포함된 예상출력값과 비교하고, 데이터베이스에 저장된 결과값과 테스트 케이스에 포함된 데이터베이스 예상결과값과 비교하는 단계를 포함할 수 있다.
여기서, 각 단계는 컴파일된 테스트 드라이버를 실행함으로써 수행될 수 있다.
여기서, 테스트 대상 시스템의 출력값과 예상 출력값을 구성하는 구조체 및 데이터베이스의 테이블과 컬럼은 개발 과정에서 수시로 변경될 수 있으므로, 변화를 실시간으로 감지하고 동기화하는 기능을 추가로 지원할 수 있다.
이와 같이 테스트 드라이버 생성에 의한 테스트 방식은 테스트 관리자가 트랜잭션을 직접 제어할 수 있고, 실제 테스트 환경을 완전하게 구축하지 않아도 테스트할수 있다는 장점이 있다.
Figure PCTKR2018002452-appb-T000022
표 22는 테스트 드라이버를 이용한 테스트 방법에 대한 소스 코드이다. 표 22를 참조하면, 데이터베이스에 설정값을 입력할 수 있고, 테스트 케이스의 입력값을 테스트 대상 시스템의 함수 파라미터로 입력할 수 있으며, 그에 따라 수행된 결과를 비교할 수 있다.
한편, 도 9를 참조하면, 테스트 대상 시스템이 서비스인 경우 테스트하는 방법을 설명할 수 있다.
구체적으로, 테스트 대상 시스템이 미들웨어 서비스인 경우 테스트를 수행하는 방법은 테스트 케이스를 이용하여 입력 전문을 생성하는 단계, 테스트 대상 시스템이 연동되는 미들웨어(middleware)의 서비스를 호출하여 상기 입력 전문을 상기 미들웨어에 전송하는 단계 및 미들웨어로부터 테스트 결과 전문을 수신하는 단계를 포함할 수 있다.
여기서 입력 전문을 생성하는 단계는 테스트 케이스가 생성되면, XML, JSON과 같은 전문 형태로 먼저 저장되어 보관할 수 있으므로, 저장된 전문을 획득하는 단계로 처리될 수도 있다.
또한, 여기서, 입력 전문을 생성하는 단계 이후에 미들웨어 서비스에서 지원하는 포맷으로 입력 전문을 변환하는 단계를 더 포함할 수 있다. 이것은 테스트 케이스를 저장하고 사용하는 입력 전문의 포맷과 미들웨어 서비스에서 지원하는 포맷이 상이할 수 있으므로 호환성을 보장하기 위한 것일 수 있다.
여기서 테스트 대상 시스템을 개발하는데 사용되는 미들웨어는 Socket, RMI, RPC, HTTP, TUXEDO, T-max, Entera 등이 있을 수 있다. 개발된 테스트 대상 시스템이 사용하는 미들웨어에 따라 서비스 호출 방식이 결정될 수 있고, 트랜잭션의 제어 방법도 달라질 수 있다. TUXEDO와 T-max 같은 상용 미들웨어는 2 Phase Commit을 제공하므로 테스트 시에 데이터베이스 환경 설정 및 예상결과 처리와 데이터베이스에 테스트 결과를 남기는 등의 테스트 작업과 업무 작업과 관련한 트랜잭션을 효과적으로 제어할 수 있다. 또 테스트 대상 시스템이 프레임워크를 사용한다면 테스트 대상 시스템은 보다 더 구조화된 형태를 제공할 수 있다. 프레임워크는 업무의 한 트랜잭션을 처리하기 위해서 전처리와 후처리와 같은 인터셉트 루틴을 호출을 할 수 있도록 하여 서비스를 호출하기 전에 공통으로 사용하는 기능을 실행할 수 있다. 이와 같은 전처리와 후처리에 데이터베이스 환경 설정 및 예상결과를 처리하는 모듈을 끼워 넣어서 효과적으로 트랜잭션을 처리할 수 있다.
표 23은 미들웨어 기반의 테스트 대상 시스템을 테스트하는 샘플 코드이다.
Figure PCTKR2018002452-appb-T000023
표 23을 참조하면, 테스트 에이전트 측에서의 각 과정과 미들웨어의 프레임워크가 수행하는 각 과정을 확인할 수 있다.
위 과정을 상세하게 서술하면, 첫째, 테스트 에이전트는 프로그램 번호와 테스트 케이스 번호로 테스트 케이스의 입력전문을 조회하고 입력 전문의 예비 영역에 값을 설정할 수 있다.
둘째, 테스트 에이전트는 입력 전문을 프레임워크에 보내 서비스를 호출할 수 있다. 프레임워크는 전문의 예비 영역에 포함되어 전송된 프로그램 번호와 테스트 케이스 번호를 서비스의 전처리 모듈에 넘겨줄 수 있다. 서비스의 전처리 모듈에서는 프로그램 번호와 테스트 케이스 번호를 이용하여 테스트 케이스가 저장된 데이터베이스에서 데이터베이스 설정값을 읽어서 테스트 실행 전 환경을 설정할 수 있다. 그리고 프레임워크는 업무 로직을 실행하기 위해서 테스트 대상 시스템(SUT)을 호출할 수 있다. SUT는 연동된 업무 데이터베이스의 데이터를 조작하면서 업무 처리를 수행할 수 있다. 마지막으로 프레임워크는 프로그램 번호와 테스트 케이스 번호로 데이터베이스 예상결과값을 가져올 수 있다. 그리고 업무 데이터베이스에 쿼리들을 실행하여 예상결과값과 실제결과값을 대조하여 테스트의 정확성을 확인할 수 있다. 이상의 각 단계에서는 테스트를 수행한 결과를 관리하기 위해서 필요한 정보를 남김없이 테스트 데이터베이스에 기록할 수 있다.
셋째, 테스트 케이스 결과 전문 처리 모듈은 프로그램 번호와 테스트 케이스 번호로 테스트 케이스의 예상결과 전문을 조회할 수 있다. 테스트 케이스 결과 전문 처리 모듈은 예상출력값과 실제출력 전문의 각 값을 비교하고 그 결과를 테스트 케이스가 기록되는 데이터베이스에 저장할 수 있다.
따라서 미들웨어(또는 미들웨어의 프레임워크)는, 입력 전문으로부터 상기 테스트 케이스의 데이터베이스 설정값을 확인하고, 확인된 데이터 베이스 설정값을 이용하여 상기 데이터베이스에 대한 초기 설정을 수행하고, 입력 전문으로부터 상기 테스트 케이스의 입력값을 확인하고 상기 테스트 대상 시스템의 입력 파라미터로 입력하여 상기 테스트 대상 시스템을 실행하도록 구성될 수 있다.
미들웨어에 의한 테스트 방식은 소스 코드를 생성하지 않고 일반화된 모듈을 이용하여 테스트 에이전트를 만들 수 있다. 또 업무 시스템이 프레임워크를 시용하여 개발된다면 2 Phase Commit 트랜잭션 관리를 사용할 수 있는 이점도 있다.
여기서, 테스트 결과 중에는 정적으로 정의할 수 없는 값들이 있다. 예를 들어, 테스트를 실행할 때마다 생성되는 일련 번호나 테스트의 실행 시점의 날짜나 시간과 같이 매번 바뀌는 정보는 테스트 결과의 불확실성을 증가시킬 수 있다. 따라서, 이에 대한 테스트 케이스로서 예상출력값이나 데이터베이스의 예상결과값을 명확하게 정의하여 테스트하기 어려울 수 있다.
이런 경우 테스트 결과의 판단 대상으로 삼지 않을 수도 있고, 매크로, 참조, 스크립트와 같은 값을 정의하여 로직으로 대응할 수도 있다. 또한 값은 상수 값, 매크로, 참조, 스크립트에 따라 구분하여 입력할 수 있다. 예를 들어 상수 값은 숫자나 문자열일 수 있고, 매크로는 TODATE와 같이 미리 정의된 이름으로 정할 수 있으며, 현재 날짜와 같은 경우에는 시스템의 현재 날짜를 조회하여 사용할 수도 있다. 참조는 테스트 케이스가 저장된 형식인 전문의 특정 컬럼 값을 가져올 수도 있다. 스크립트는 스크립트를 실행하여 나온 결과값을 출력값과 비교할 수 있다. 다만, 스크립트는 매크로를 포함하는 의미일 수 있다.
따라서 예상출력값은, 상기 테스트 대상 시스템의 실행시마다 출력값이 변경되는 경우, 상기 테스트 케이스에서 제외되거나 매크로, 참조, 스크립트 중 하나의 방법으로 결정될 수 있다.
한편, 앞서 생성된 테스트 케이스를 이용하여 테스트를 수행하는 과정에는 다양한 테스트 방식이 적용될 수 있다. 테스트 방식에는 단위 테스트, 통합 테스트 또는 회귀 테스트가 있을 수 있다.
먼저 단위 테스트는, 단위 테스트는 소스 코드의 개별 단위를 테스트하는 소프트웨어 테스트 방법이다. 여기서 단위란 어플리케이션의 가장 작은 단위이며, 테스트를 할 수 있는 라인의 집합을 의미할 수 있다. 단위 테스트는 개발 초기 단계에 문제점들을 찾기 위한 테스트 방법으로 프로그래머가 구현 시점에 만든 버그나 명세서의 결함이나 놓친 것을 찾는 것에 목적이 있다. 단위 테스트를 마친 모듈은 회귀 테스트에서 사용될 때 정확하게 동작할 것이라는 점을 보증할 수 있다. 그래서 단위 테스트의 테스트 케이스는 결함이 발생할 가능성이 있는 프로그램을 위해 작성할 수 있다. 이렇게 작성한 단위 테스트 케이스는 단위 테스트를 거친 프로그램을 대상으로 하는 회귀 테스트에서도 사용할 수 있을 뿐만 아니라 안정된 모듈로 통합해야 하는 통합 테스트에서도 활용할 수 있다. 하지만 단위 테스트로 프로그램에 존재하는 모든 오류를 찾아내진 못할 수 있는데, 단위 자체의 기능만을 테스트하므로 통합 오류나 시스템 오류와 같은 오류는 찾지 못할 수 있다.
도 1을 다시 참조하면, 자동으로 생성된 테스트 케이스는 단위 테스트에서 사용할 수 있다. 심볼릭 실행기로 생성된 테스트 케이스는 먼저 테스트 DB에 저장될 수 있다. 이때 사용자와 관리자는 전술한 바와 같이 자동 생성된 테스트 케이스에 대해서 적절한 이름을 부여하여 관리할 수도 있다.
그리고 사용자와 관리자는 언제든지 테스트 시점에 이들을 사용할 수 있고, 원할 때 테스트 결과를 바로 확인할 수도 있다. 자동으로 생성된 테스트 케이스가 정확성을 요구하는 테스트에 적용된다면 적은 노력으로 많은 테스트를 실행하여 테스트 커버리지를 최대한으로 높일 수 있다. 마지막으로 단위 테스트 결과는 자동으로 테스트 데이터베이스에 집계되고 통계로 누적되어 관리자가 실시간으로 테스트 현황을 파악하기 용이하게 정보를 제공할 수 있다.
다음으로, 통합 테스트는 단위 모듈 또는 서비스를 일련의 순서로 연결하여 테스트를 수행하는 소프트웨어 테스팅 방법으로 정의할 수 있다. 통합 테스트는 단위 테스트를 완료한 프로그램을 대상으로 하며, 시범점 또는 전점 등 검증 테스트 전에 분석/설계자에 의해서 수행될 수 있다.
통합 테스트 방법을 보면 빅뱅 방식과 탑다운 방식, 버텀업 방식, 그리고 하이브리드 방식이 있을 수 있다. 빅뱅 방식은 개발된 모듈을 한 번에 전체를 통합하여 테스트하는 방식이다. 빅뱅 방식은 통합 테스트 시간을 단축할 수 있는 장점이 있으나 단위 프로그램이 충분히 테스트 되지 않은 상태에서 테스트를 하게 되면 오히려 더 많은 시간과 노력이 투입 될 수도 있다. 버텀업 방식은 가장 하위 단위를 먼저 통합하여 테스트하는 방식이다. 테스트할 상위 단위와 관련된 하위 단위가 모두 테스트가 되면 바로 상위 단위를 테스트하는 등의 절차를 반복하여 최상위 단위까지 테스트할 수 있다. 탑다운 방식은 최상위 단위부터 테스트를 수행할 수 있다. 그런 다음 하위 단위를 반복적으로 테스트를 수행할 수 있다. 하이브리드 방식은 버텀업과 탑다운 방식을 혼용하여 진행하는 방식일 수 있다. 통합 테스트에서는 통합 테스트 명세에 기술되지 않은 조건은 테스트하지 않을 수 있다. 자동으로 생성된 테스트 케이스를 활용하여 개발자는 모듈 통합 또는 서비스 통합 테스트를 구성할 수 있다.
모듈 통합 테스트는 모듈을 순서대로 엮어서 테스트를 수행할 수 있다. 즉 모듈을 순서대로 엮어 주는 테스트 드라이버를 생성할 수 있다. 모듈에서 최상위 함수를 테스트하면 하위 함수들이 호출되고 실행된다는 특징이 있다. 사용자 등록 모듈, 사용자 목록 조회 모듈, 사용자 수정 모듈, 그리고 사용자 삭제 모듈들을 일련의 시나리오로 구성하여 테스트 할 수 있다.
서비스 통합 테스트는 서비스를 순서대로 엮어서 테스트하는 방식이다. 모듈 통합 테스트에서와 같이 사용자 등록 서비스, 사용자 목록 조회 서비스, 사용자 수정 서비스, 그리고 사용자 삭제 서비스들을 일련의 시나리오로 구성한다고 가정하면, 테스터는 테스트 DB에서 사용자를 등록하는 테스트 케이스를 선택할 수 있다. 그리고 정상적으로 사용자가 등록되었는지 확인하기 위해서 앞서 등록한 사용자 번호로 사용자 목록을 조회 하는 테스트 케이스를 선택할 수 있다. 그리고 등록된 사용자의 정보를 수정하는 테스트를 위한 테스트 케이스를 선택할 수 있다. 이때 동일한 사용자 번호로 수정하는 테스트를 할 수 있도록 동일한 사용자 번호를 지정할 수 있다. 마지막으로 사용자 삭제를 테스트하기 위해서 사용자 삭제 테스트 케이스를 선택할 수 있다. 마찬가지로 동일한 사용자 번호를 지정하여 삭제를 테스트할 수 있도록 한다.
이와 같이 단위 테스트 케이스를 연결하여 서비스 통합 테스트를 수행할 수 있다. 시나리오를 구성하는 테스트 케이스는 동일한 사용자 번호를 사용해야 하므로 사용자 등록 테스트 케이스에서 등록한 사용자 번호를 이후 테스트 케이스에서 사용할 수 있는 방법을 제공할 수 있다. 이를 위한 아주 간단한 방법 중 하나는 정확성 판단을 위하여 이전에 테스트 케이스에서 사용된 입력값 또는 실제출력값을 참조할 수 있는 방법을 제공하는 것이다.
통합 테스트의 결과는 시나리오를 구성하는 개별 테스트 케이스의 결과도 관리해야 하고 시나리오 전체의 결과도 관리해야 할 수 있다. 또한 하나의 시나리오에 대한 테스트 결과, 테스트 시나리오의 이력, 그리고 시나리오의 변경 이력 등의 관리가 필요할 수 있다. 관리자는 시나리오 전체가 성공했는지에 관심이 있고, 개발자는 시나리오가 실패 했을 경우 어디서 실패 했는지 실패 원인이 무엇인지를 확인할 수 있는 정보에 관심이 있다.
회귀 테스트는 이전에 개발된 소프트웨어가 변경 후에도 여전히 잘 동작하는지 확인하기 위한 소프트웨어 테스팅 기법이다. 소프웨어 변경은 개선, 패치, 그리고 형상 변경 등에 의해서 발생할 수 있다. 회귀 테스트는 새로운 버그나 프로그램 변경(추가, 삭제, 수정을 통칭)에 의해 발생하는 회귀 오류를 찾아내는 것에 목적이 있을 수 있다.
회귀 테스트방식에는 전체 테스트 케이스를 모두 실행하는 방법도 있고 프로그램 변경에 영향을 받은 프로그램을 찾아서 테스트하는 방법도 있을 수 있다. 전체 테스트 케이스를 모두 실행하는 방법이 가장 이상적이나 8시간 이내에 테스트를 완료해야 한다와 같이 테스트 시간에 제약이 있는 경우에는 이 방법을 사용하기 어려울 수 있다.
영향도 분석을 통해서 프로그램 변경에 영향을 받은 대상을 찾는 것을 회귀 분석이라고 하고 분석 결과는 회귀 테스트 케이스를 선별하는 기준이 되며, 회귀 분석의 결과를 이용하여 회귀 테스트를 수행할 수 있다. 회귀 테스트는 프로그램이 수정되어 영향을 받은 프로그램의 테스트 케이스만 찾아서 테스트를 실행하는 것이 유리할 수 있다.
함수(또는 메소드) 수준에서 회귀 분석하는 방법을 설명하면, 먼저 프로그램 수정으로 영향을 받은 함수를 찾고, 그 함수를 사용하는 부모 함수와 그 부모 함수를 모두 찾을 때까지 반복할 수 있다. 영향 받는 모든 함수를 찾고 나면 중복된 함수를 제거할 수 있다. 마지막으로 정리된 함수에 딸려 있는 테스트 케이스를 순차적으로 실행할 수 있다.
회귀 테스트에서 사용할 테스트 케이스는 단위 테스트 케이스 형태 일 수도 있고 통합 테스트 케이스 형태 일 수도 있다. 회귀 테스트에서는 가능한 모든 테스트 케이스를 이용할 수도 있고, 또한 효율적으로 테스트하기 위해 회귀 테스트에서 사용할 테스트 케이스를 지정할 수도 있다. 회귀 테스트의 결과는 테스트 DB에 저장될 수 있다. 또한 결재시스템과 연동하여 오류 발생 시에는 운영 시스템에 변경된 프로그램이 적재되지 않도록 조치할 수도 있다.
회귀 테스트는 반복점진적인 개발 방법에서는 필수로 수행해야 하는 테스트일 수 있다. 반복점진적 개발을 보면 매일 개발된 프로그램은 형상관리 시스템에 커밋되고, 자동빌드 시스템은 형상관리에서 프로그램을 내려 받아 빌드를 수행하며, 영향도 분석을 통해서 영향 받은 함수를 찾아서 테스트 케이스를 실행하는 일련의 과정이 반복될 수 있다.
영향도 분석을 예로 들면 먼저, 업무 테이블에서 컬럼을 삭제한다고 가정한다. 영향도 분석 시스템은 삭제된 컬럼을 사용하는 함수(이때 함수가 포함된 프로그램도 알 수 있다)를 찾을 수 있다. 이 함수를 사용하는 부모 함수를 모두 찾을 때까지 반복해서 찾을 수 있다. 찾은 함수들 중에 동일한 함수를 제거할 수 있다. 중복 제거된 함수 목록을 이용하여 함수에 딸려 있는 테스트 케이스를 찾을 수 있다. 이 테스트 케이스들을 모두 실행하여 회귀 테스트를 완료할 수 있다.
영향도 분석에서 가장 중요한 요인 중에 하나는 영향 받은 테스트 케이스의 최소 집합을 구하는 것일 수 있다. 이와 같은 목적을 달성하기 위해서 정적 분석 기술을 이용할 수 있다. 정적 분석 기술을 이용하여 해당 제어 흐름을 추적하여 영향 받는 베이시스 패스를 찾고 이들과 관련된 테스트 케이스를 찾아 최소한의 테스트 케이스 집합을 추출할 수 있다.
본 발명의 일 실시예에 따른 테스트 케이스 생성 장치는, 적어도 하나의 명령(instruction)을 실행하는 프로세서(processor) 및 적어도 하나의 명령을 저장하는 메모리(memory)를 포함할 수 있다.
여기서, 프로세서는, 심볼릭 실행(symbolic execution)에 기초하여, SQL(Structured Query Language)문을 포함하는 소스 코드에 대해 적어도 하나 이상의 프로그램 경로를 결정하고, 적어도 하나 이상의 프로그램 경로에 따라 심볼릭 실행을 수행하고, 심볼릭 실행에 따라 생성된 논리식에 대하여 솔버를 이용하여 테스트케이스를 생성할 수 있다.
여기서, 프로세서는, 소스 코드를 파싱하여 요약 구문 트리(Abstract Syntax Tree, AST)를 생성하고, 생성된 요약 구문 트리를 기초로, 제어 흐름 그래프(Control Flow Graph, CFG)를 생성하고, 제어 흐름 그래프를 기초로 적어도 하나 이상의 프로그램 경로를 결정할 수 있다.
본 발명의 일 실시예에 따른 테스트 케이스를 이용한 테스트 장치는, 적어도 하나의 명령(instruction)을 실행하는 프로세서(processor), 적어도 하나의 명령을 저장하는 메모리(memory)를 포함할 수 있다.
여기서, 프로세서는, 심볼릭 실행(symbolic execution)에 기초하여 SQL(Structured Query Language)문을 포함하는 소스 코드에 대한 테스트 케이스를 생성하고, 데이터베이스와 연동하는 테스트 대상 시스템에 테스트 케이스를 적용하여 테스트를 수행하고, 테스트 케이스는 테스트 대상 시스템의 입력값, 입력값이 테스트 대상 시스템에서 처리될 때 출력값을 예측한 예상출력값, 데이터베이스의 설정값 및 테스트 대상 시스템이 설정값이 적용된 데이터베이스와 연동하여 처리될 때 데이터베이스에 저장될 결과값을 예측한 예상결과값 중 적어도 하나를 포함할 수 있다.
여기서, 프로세서는, 소스 코드에 대하여 적어도 하나 이상의 프로그램 경로를 결정하고, 적어도 하나 이상의 프로그램 경로에 따라 심볼릭 실행을 수행하고, 심볼릭 실행에 따라 생성된 논리식에 대하여 솔버를 이용하여 테스트케이스를 생성할 수 있다.
여기서, 프로세서는, 소스 코드를 파싱하여 요약 구문 트리(Abstract Syntax Tree, AST)를 생성하고, 생성된 요약 구문 트리를 기초로, 제어 흐름 그래프(Control Flow Graph, CFG)를 생성하고, 제어 흐름 그래프를 기초로 적어도 하나 이상의 프로그램 경로를 결정할 수 있다.
여기서, 프로세서는, 적어도 하나 이상의 프로그램 경로에 SQL문이 포함된 경우, 소스 코드의 호스트 변수와 SQL문에 따라 데이터베이스에 포함된 테이블의 컬럼을 매핑할 수 있다.
여기서, 프로세서는, SQL문을 파싱하여 테이블을 확인하고, 확인된 테이블을 구성하는 컬럼을 데이터베이스의 메타 데이터를 이용하여 획득하고, 획득된 컬럼을 소스 코드의 호스트 변수와 매핑할 수 있다.
여기서, 프로세서는 생성된 테스트 케이스를 XML, JSON 중 하나의 포맷으로 저장할 수 있다.
여기서, 프로세서는, 테스트 대상 시스템이 모듈인 경우, 설정값을 데이터베이스에 적용하고, 입력값으로 테스트 대상 시스템의 입력 파라미터를 설정하고, 설정된 입력 파라미터로 테스트 대상 시스템의 함수를 호출하고, 함수 호출의 결과로 획득된 테스트 대상 시스템의 출력값을 예상출력값과 비교하고, 데이터베이스에 저장된 결과값과 예상결과값을 비교할 수 있다.
여기서, 프로세서는, 테스트 대상 시스템이 미들웨어 서비스인 경우, 테스트 케이스를 이용하여 입력 전문을 생성하고, 테스트 대상 시스템이 연동되는 미들웨어(middleware)의 서비스를 호출하여 입력 전문을 미들웨어에 전송하고, 미들웨어로부터 테스트 결과 전문을 수신할 수 있다.
앞에서 설명한 테스트 케이스 생성 장치 또는 테스트 케이스를 이용한 테스트 장치는, 통신 가능한 데스크탑 컴퓨터(desktop computer), 랩탑 컴퓨터(laptop computer), 노트북(notebook), 스마트폰(smart phone), 태블릿 PC(tablet PC), 모바일폰(mobile phone), 스마트 워치(smart watch), 스마트 글래스(smart glass), e-book 리더기, PMP(portable multimediaplayer), 휴대용 게임기, 네비게이션(navigation) 장치, 디지털 카메라(digital camera), DMB(digital multimediabroadcasting) 재생기, 디지털 음성 녹음기(digital audiorecorder), 디지털 음성 재생기(digital audioplayer), 디지털 동영상 녹화기(digital video recorder), 디지털 동영상 재생기(digital video player), PDA(Personal Digital Assistant) 등일 수 있다.
본 발명에 따른 방법들은 다양한 컴퓨터 수단을 통해 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 컴퓨터 판독 가능 매체에 기록되는 프로그램 명령은 본 발명을 위해 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다.
컴퓨터 판독 가능 매체의 예에는 롬(ROM), 램(RAM), 플래시 메모리(flash memory) 등과 같이 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함될 수 있다. 프로그램 명령의 예에는 컴파일러(compiler)에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터(interpreter) 등을 사용해서 컴퓨터에 의해 실행될 수 있는 고급 언어 코드를 포함할 수 있다. 상술한 하드웨어 장치는 본 발명의 동작을 수행하기 위해 적어도 하나의 소프트웨어 모듈로 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
또한, 상술한 방법 또는 장치는 그 구성이나 기능의 전부 또는 일부가 결합되어 구현되거나, 분리되어 구현될 수 있다.
상기에서는 본 발명의 바람직한 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

Claims (20)

  1. 심볼릭 실행(symbolic execution)에 기초하여 SQL(Structured Query Language)문을 포함하는 소스 코드에 대한 테스트 케이스를 생성하는 단계; 및
    데이터베이스와 연동하는 테스트 대상 시스템에 상기 테스트 케이스를 적용하여 테스트를 수행하는 단계를 포함하고,
    상기 테스트 케이스는 상기 테스트 대상 시스템의 입력값, 상기 입력값이 상기 테스트 대상 시스템에서 처리될 때 출력값을 예측한 예상출력값, 상기 데이터베이스의 설정값 및 상기 테스트 대상 시스템이 상기 설정값이 적용된 상기 데이터베이스와 연동하여 처리될 때 상기 데이터베이스에 저장될 결과값을 예측한 예상결과값 중 적어도 하나를 포함하는, 테스트 케이스를 이용한 테스트 방법.
  2. 청구항 1에서,
    상기 테스트 케이스를 생성하는 단계는,
    상기 소스 코드에 대하여 적어도 하나 이상의 프로그램 경로를 결정하는 단계;
    상기 적어도 하나 이상의 프로그램 경로에 따라 상기 심볼릭 실행을 수행하는 단계; 및
    상기 심볼릭 실행에 따라 생성된 논리식에 대하여 솔버를 이용하여 테스트케이스를 생성하는 단계를 포함하는, 테스트 케이스를 이용한 테스트 방법.
  3. 청구항 2에서,
    상기 프로그램 경로를 결정하는 단계는,
    상기 소스 코드를 파싱하여 요약 구문 트리(Abstract Syntax Tree, AST)를 생성하는 단계;
    생성된 요약 구문 트리를 기초로, 제어 흐름 그래프(Control Flow Graph, CFG)를 생성하는 단계; 및
    상기 제어 흐름 그래프를 기초로 적어도 하나 이상의 프로그램 경로를 결정하는 단계를 포함하는, 테스트 케이스를 이용한 테스트 방법.
  4. 청구항 2에서,
    상기 심볼릭 실행을 수행하는 단계는,
    상기 적어도 하나 이상의 프로그램 경로에 SQL문이 포함된 경우,
    상기 소스 코드의 호스트 변수와 상기 SQL문에 따라 상기 데이터베이스에 포함된 테이블의 컬럼을 매핑하는 단계를 포함하는, 테스트 케이스를 이용한 테스트 방법.
  5. 청구항 4에서,
    상기 매핑하는 단계는,
    상기 SQL문을 파싱하여 테이블을 확인하는 단계;
    확인된 테이블을 구성하는 컬럼을 상기 데이터베이스의 메타 데이터를 이용하여 획득하는 단계; 및
    획득된 컬럼을 상기 소스 코드의 호스트 변수와 매핑하는 단계를 포함하는, 테스트 케이스를 이용한 테스트 방법.
  6. 청구항 1에서,
    상기 테스트 케이스를 생성하는 단계 이후에,
    생성된 테스트 케이스를 XML, JSON 중 하나의 포맷으로 저장하는 단계를 더 포함하는, 테스트 케이스를 이용한 테스트 방법.
  7. 청구항 1에서,
    상기 테스트를 수행하는 단계는,
    상기 테스트 대상 시스템이 모듈인 경우,
    상기 설정값을 상기 데이터베이스에 적용하는 단계;
    상기 입력값으로 상기 테스트 대상 시스템의 입력 파라미터를 설정하는 단계;
    설정된 입력 파라미터로 상기 테스트 대상 시스템의 함수를 호출하는 단계; 및
    함수 호출의 결과로 획득된 상기 테스트 대상 시스템의 출력값을 상기 예상출력값과 비교하고, 상기 데이터베이스에 저장된 결과값과 상기 예상결과값을 비교하는 단계를 포함하는, 테스트 케이스를 이용한 테스트 방법.
  8. 청구항 1에서,
    상기 테스트를 수행하는 단계는,
    상기 테스트 대상 시스템이 미들웨어 서비스인 경우,
    상기 테스트 케이스를 이용하여 입력 전문을 생성하는 단계;
    상기 테스트 대상 시스템이 연동되는 미들웨어(middleware)의 서비스를 호출하여 상기 입력 전문을 상기 미들웨어에 전송하는 단계; 및
    상기 미들웨어로부터 테스트 결과 전문을 수신하는 단계를 포함하는, 테스트 케이스를 이용한 테스트 방법.
  9. 청구항 8에서,
    상기 미들웨어는,
    상기 입력 전문으로부터 상기 테스트 케이스의 데이터베이스 설정값을 확인하고, 확인된 데이터 베이스 설정값을 이용하여 상기 데이터베이스에 대한 초기 설정을 수행하고,
    상기 입력 전문으로부터 상기 테스트 케이스의 입력값을 확인하고 상기 테스트 대상 시스템의 입력 파라미터로 입력하여 상기 테스트 대상 시스템을 실행하도록 구성되는, 테스트 케이스를 이용한 테스트 방법.
  10. 청구항 1에서,
    상기 예상출력값은,
    상기 테스트 대상 시스템의 실행시마다 출력값이 변경되는 경우, 상기 테스트 케이스에서 제외되거나 매크로, 참조, 스크립트 중 하나의 방법으로 결정되는, 테스트 케이스를 이용한 테스트 방법.
  11. 적어도 하나의 명령(instruction)을 실행하는 프로세서(processor); 및
    상기 적어도 하나의 명령을 저장하는 메모리(memory)를 포함하고,
    상기 프로세서는,
    심볼릭 실행(symbolic execution)에 기초하여, SQL(Structured Query Language)문을 포함하는 소스 코드에 대해 적어도 하나 이상의 프로그램 경로를 결정하고, 상기 적어도 하나 이상의 프로그램 경로에 따라 상기 심볼릭 실행을 수행하고, 상기 심볼릭 실행에 따라 생성된 논리식에 대하여 솔버를 이용하여 테스트케이스를 생성하는, 테스트 케이스 생성 장치.
  12. 청구항 11에서,
    상기 프로세서는,
    상기 소스 코드를 파싱하여 요약 구문 트리(Abstract Syntax Tree, AST)를 생성하고, 생성된 요약 구문 트리를 기초로, 제어 흐름 그래프(Control Flow Graph, CFG)를 생성하고, 상기 제어 흐름 그래프를 기초로 적어도 하나 이상의 프로그램 경로를 결정하는, 테스트 케이스 생성 장치.
  13. 적어도 하나의 명령(instruction)을 실행하는 프로세서(processor);
    상기 적어도 하나의 명령을 저장하는 메모리(memory)를 포함하고,
    상기 프로세서는,
    심볼릭 실행(symbolic execution)에 기초하여 SQL(Structured Query Language)문을 포함하는 소스 코드에 대한 테스트 케이스를 생성하고, 데이터베이스와 연동하는 테스트 대상 시스템에 상기 테스트 케이스를 적용하여 테스트를 수행하고,
    상기 테스트 케이스는 상기 테스트 대상 시스템의 입력값, 상기 입력값이 상기 테스트 대상 시스템에서 처리될 때 출력값을 예측한 예상출력값, 상기 데이터베이스의 설정값 및 상기 테스트 대상 시스템이 상기 설정값이 적용된 상기 데이터베이스와 연동하여 처리될 때 상기 데이터베이스에 저장될 결과값을 예측한 예상결과값 중 적어도 하나를 포함하는, 테스트 케이스를 이용한 테스트 장치.
  14. 청구항 13에서,
    상기 프로세서는,
    상기 소스 코드에 대하여 적어도 하나 이상의 프로그램 경로를 결정하고, 상기 적어도 하나 이상의 프로그램 경로에 따라 상기 심볼릭 실행을 수행하고, 상기 심볼릭 실행에 따라 생성된 논리식에 대하여 솔버를 이용하여 테스트케이스를 생성하는, 테스트 케이스를 이용한 테스트 장치.
  15. 청구항 14에서,
    상기 프로세서는,
    상기 소스 코드를 파싱하여 요약 구문 트리(Abstract Syntax Tree, AST)를 생성하고, 생성된 요약 구문 트리를 기초로, 제어 흐름 그래프(Control Flow Graph, CFG)를 생성하고, 상기 제어 흐름 그래프를 기초로 적어도 하나 이상의 프로그램 경로를 결정하는, 테스트 케이스를 이용한 테스트 장치.
  16. 청구항 14에서,
    상기 프로세서는,
    상기 적어도 하나 이상의 프로그램 경로에 SQL문이 포함된 경우,
    상기 소스 코드의 호스트 변수와 상기 SQL문에 따라 상기 데이터베이스에 포함된 테이블의 컬럼을 매핑하는, 테스트 케이스를 이용한 테스트 장치.
  17. 청구항 16에서,
    상기 프로세서는,
    상기 SQL문을 파싱하여 테이블을 확인하고, 확인된 테이블을 구성하는 컬럼을 상기 데이터베이스의 메타 데이터를 이용하여 획득하고, 획득된 컬럼을 상기 소스 코드의 호스트 변수와 매핑하는, 테스트 케이스를 이용한 테스트 장치.
  18. 청구항 13에서,
    상기 프로세서는,
    생성된 테스트 케이스를 XML, JSON 중 하나의 포맷으로 저장하는, 테스트 케이스를 이용한 테스트 장치.
  19. 청구항 13에서,
    상기 프로세서는,
    상기 테스트 대상 시스템이 모듈인 경우,
    상기 설정값을 상기 데이터베이스에 적용하고, 상기 입력값으로 상기 테스트 대상 시스템의 입력 파라미터를 설정하고, 설정된 입력 파라미터로 상기 테스트 대상 시스템의 함수를 호출하고, 함수 호출의 결과로 획득된 상기 테스트 대상 시스템의 출력값을 상기 예상출력값과 비교하고, 상기 데이터베이스에 저장된 결과값과 상기 예상결과값을 비교하는, 테스트 케이스를 이용한 테스트 장치.
  20. 청구항 13에서,
    상기 프로세서는,
    상기 테스트 대상 시스템이 미들웨어 서비스인 경우,
    상기 테스트 케이스를 이용하여 입력 전문을 생성하고, 상기 테스트 대상 시스템이 연동되는 미들웨어(middleware)의 서비스를 호출하여 상기 입력 전문을 상기 미들웨어에 전송하고, 상기 미들웨어로부터 테스트 결과 전문을 수신하는, 테스트 케이스를 이용한 테스트 장치.
PCT/KR2018/002452 2017-02-28 2018-02-28 테스트 케이스를 이용하여 테스트를 수행하는 방법 및 장치 WO2018159997A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2019546812A JP6859449B2 (ja) 2017-02-28 2018-02-28 テストケースを利用してテストを遂行する方法および装置
US16/486,079 US20200019494A1 (en) 2017-02-28 2018-02-28 Method and apparatus for performing test by using test case
CN201880014545.4A CN110337642A (zh) 2017-02-28 2018-02-28 通过使用测试用例来执行测试的方法和装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2017-0026398 2017-02-28
KR1020170026398A KR101989802B1 (ko) 2017-02-28 2017-02-28 테스트 케이스를 이용하여 테스트를 수행하는 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2018159997A1 true WO2018159997A1 (ko) 2018-09-07

Family

ID=63370189

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/002452 WO2018159997A1 (ko) 2017-02-28 2018-02-28 테스트 케이스를 이용하여 테스트를 수행하는 방법 및 장치

Country Status (5)

Country Link
US (1) US20200019494A1 (ko)
JP (1) JP6859449B2 (ko)
KR (1) KR101989802B1 (ko)
CN (1) CN110337642A (ko)
WO (1) WO2018159997A1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109509122A (zh) * 2018-10-15 2019-03-22 广州思谋信息科技有限公司 一种基于ar智能眼镜的软件测试培训系统
US10289409B2 (en) 2017-03-29 2019-05-14 The Travelers Indemnity Company Systems, methods, and apparatus for migrating code to a target environment
US10318412B1 (en) * 2018-06-29 2019-06-11 The Travelers Indemnity Company Systems, methods, and apparatus for dynamic software generation and testing
CN110825650A (zh) * 2019-11-29 2020-02-21 北京网聘咨询有限公司 单元测试覆盖精度检测方法及装置

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102452457B1 (ko) * 2017-11-13 2022-10-12 현대자동차주식회사 테스트 케이스 관리 시스템 및 테스트 케이스 관리 방법
CN109614309B (zh) * 2018-10-22 2023-10-20 中国平安财产保险股份有限公司 比较测试结果的方法、装置、计算机设备以及存储介质
US10949334B2 (en) * 2018-11-26 2021-03-16 Cognizant Technology Solutions India Pvt. Ltd. System and a method for automated unit test generation
KR102176133B1 (ko) * 2018-12-11 2020-11-09 (주)씽크포비엘 소프트웨어 테스트 케이스 자동 생성 방법 및 장치
US11157386B2 (en) * 2018-12-18 2021-10-26 Sap Se Debugging rules based on execution events stored in an event log
KR102639211B1 (ko) * 2019-03-22 2024-02-22 한국전력공사 소스코드 검사 시스템 및 방법
KR102271857B1 (ko) * 2019-06-21 2021-07-01 주식회사 엘지씨엔에스 테스트 자동화 시스템
US11579993B2 (en) * 2019-08-22 2023-02-14 Micro Focus Llc Regression testing of computer systems using recorded prior computer system communications
CN110825618B (zh) * 2019-10-10 2024-01-26 天航长鹰(江苏)科技有限公司 一种生成测试用例的方法及相关装置
CN113127335A (zh) * 2020-01-16 2021-07-16 北京京东振世信息技术有限公司 一种系统测试的方法和装置
CN111259082B (zh) * 2020-02-11 2023-07-21 深圳市六因科技有限公司 大数据环境下实现全量数据同步的方法
CN113495546B (zh) * 2020-03-20 2022-11-15 北京新能源汽车股份有限公司 一种实现测试用例自动测试的方法、控制器及测试台架
CN111459840A (zh) * 2020-04-26 2020-07-28 恩亿科(北京)数据科技有限公司 一种进程的调试方法及装置
JP7474132B2 (ja) 2020-06-24 2024-04-24 株式会社日立製作所 プログラム検証データ生成支援装置、及びプログラム検証データ生成支援方法
CN111897724B (zh) * 2020-07-21 2022-12-06 国云科技股份有限公司 一种适用于云平台的自动化测试方法及装置
CN112100071B (zh) * 2020-09-16 2022-03-18 腾讯科技（深圳）有限公司 测试用例生成方法、装置、计算机设备和存储介质
KR102496539B1 (ko) * 2020-12-15 2023-02-06 현대오토에버 주식회사 소프트웨어 검증 방법 및 이를 위한 장치
CN112732571B (zh) * 2021-01-05 2024-01-26 中国工商银行股份有限公司 一种测试数据生成方法及装置
CN113342649B (zh) * 2021-05-31 2023-11-14 上海创景信息科技有限公司 基于真实目标机实现单元测试的方法、介质和设备
CN113220597B (zh) * 2021-06-18 2024-04-16 中国农业银行股份有限公司 测试方法、测试装置、电子设备及存储介质
CN113448845A (zh) * 2021-06-22 2021-09-28 重庆长安汽车股份有限公司 一种ui自动化测试方法及系统
CN113504912A (zh) * 2021-07-22 2021-10-15 浙江大华技术股份有限公司 实时任务的处理方法和装置、存储介质及电子装置
CN113742251B (zh) * 2021-11-08 2022-01-28 山东建筑大学 基于集合进化的软件测试路径生成方法及系统
US11768761B2 (en) * 2021-12-08 2023-09-26 Sap Se Software application build testing
CN114048084B (zh) * 2022-01-11 2022-04-26 深圳佑驾创新科技有限公司 一种原理图的测试用例大纲的生成方法、装置和存储介质
CN114510429B (zh) * 2022-02-28 2024-05-07 中国人民解放军国防科技大学 一种基于动态符号执行的调试方法、系统和介质
WO2023199407A1 (ja) * 2022-04-12 2023-10-19 日本電信電話株式会社 保守作業支援装置、保守作業支援方法及びプログラム
WO2023210159A1 (ja) * 2022-04-27 2023-11-02 ソニーグループ株式会社 情報処理装置及び情報処理方法、並びにコンピュータプログラム
KR20240041017A (ko) 2022-09-22 2024-03-29 주식회사 스패로우 소프트웨어 회귀 테스트를 위한 최적의 테스트 케이스 선정 방법 및 장치
CN116048958B (zh) * 2022-11-17 2023-12-01 中山大学 医疗机器人控制软件测试数据的生成方法、注入方法
CN115794658B (zh) * 2023-01-09 2023-05-30 国网区块链科技(北京)有限公司 一种区块链的模糊测试方法及系统
CN116560998B (zh) * 2023-05-16 2023-12-01 中国人民解放军国防科技大学 一种面向i/o顺序性的数据库性能问题检测方法
CN117215965B (zh) * 2023-11-09 2024-02-27 恒生电子股份有限公司 基于测试用例识别的测试方法、装置、电子设备和介质
CN117724988B (zh) * 2024-02-18 2024-05-10 杭州玳数科技有限公司 一种基于Testing Library的UI组件库测试方法、存储介质及电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110055237A1 (en) * 2009-08-28 2011-03-03 Microsoft Corporation Symbolic Query Exploration
US8286250B1 (en) * 2011-11-16 2012-10-09 Google Inc. Browser extension control flow graph construction for determining sensitive paths
US8302080B2 (en) * 2007-11-08 2012-10-30 Ntt Docomo, Inc. Automated test input generation for web applications
US20150278393A1 (en) * 2014-03-25 2015-10-01 Wipro Limited System and method for business intelligence data testing

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001282578A (ja) * 2000-03-31 2001-10-12 Hitachi Software Eng Co Ltd プログラムテスト支援装置、方法、および該方法に係るプログラムを記憶した記憶媒体
CN101436128B (zh) * 2007-11-16 2012-10-31 北京邮电大学 软件测试用例自动生成方法及系统
CN102262580A (zh) * 2010-05-24 2011-11-30 南京航空航天大学 一种改进的基于符号执行的软件静态测试方法及工具
US8448146B2 (en) * 2011-03-31 2013-05-21 Infosys Limited Generation of functional tests for re-hosted applications
CN102289362A (zh) * 2011-08-26 2011-12-21 北京邮电大学 分段符号执行装置及其工作方法
GB2503893A (en) * 2012-07-10 2014-01-15 Ibm Selecting data from a database using data representing a sequence of operations
JP6217440B2 (ja) * 2014-02-18 2017-10-25 富士通株式会社 シンボリック実行プログラム、シンボリック実行方法及びシンボリック実行装置
JP6245006B2 (ja) * 2014-03-13 2017-12-13 富士通株式会社 テストケース生成装置、方法、及びプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8302080B2 (en) * 2007-11-08 2012-10-30 Ntt Docomo, Inc. Automated test input generation for web applications
US20110055237A1 (en) * 2009-08-28 2011-03-03 Microsoft Corporation Symbolic Query Exploration
US8286250B1 (en) * 2011-11-16 2012-10-09 Google Inc. Browser extension control flow graph construction for determining sensitive paths
US20150278393A1 (en) * 2014-03-25 2015-10-01 Wipro Limited System and method for business intelligence data testing

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KIM, JIN-A ET AL.: "M2M Transformation Rules for Automatic Test Case Generation from Sequence Diagram", KIISE TRANSACTIONS ON COMPUTING PRACTICES, vol. 22, no. 1, January 2016 (2016-01-01), pages 32 - 37 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10289409B2 (en) 2017-03-29 2019-05-14 The Travelers Indemnity Company Systems, methods, and apparatus for migrating code to a target environment
US10318412B1 (en) * 2018-06-29 2019-06-11 The Travelers Indemnity Company Systems, methods, and apparatus for dynamic software generation and testing
CN109509122A (zh) * 2018-10-15 2019-03-22 广州思谋信息科技有限公司 一种基于ar智能眼镜的软件测试培训系统
CN110825650A (zh) * 2019-11-29 2020-02-21 北京网聘咨询有限公司 单元测试覆盖精度检测方法及装置

Also Published As

Publication number Publication date
KR101989802B1 (ko) 2019-06-18
KR20180099241A (ko) 2018-09-05
CN110337642A (zh) 2019-10-15
JP6859449B2 (ja) 2021-04-14
JP2020510925A (ja) 2020-04-09
US20200019494A1 (en) 2020-01-16

Similar Documents

Publication Publication Date Title
WO2018159997A1 (ko) 테스트 케이스를 이용하여 테스트를 수행하는 방법 및 장치
WO2011122724A1 (ko) 아밥 소스코드의 코드 검사를 수행하는 코드검사 수행시스템
CN111666206B (zh) 变更代码的影响范围的获取方法、装置、设备及存储介质
Hassan et al. Rudsea: recommending updates of dockerfiles via software environment analysis
WO2013017037A1 (zh) 一种soc芯片的验证方法及系统
Zhong et al. Boosting complete-code tool for partial program
US9311077B2 (en) Identification of code changes using language syntax and changeset data
JPWO2015029154A1 (ja) ソースコード等価性検証装置、および、ソースコード等価性検証方法
WO2018188342A1 (zh) 脚本文件生成方法、装置、设备和计算机可读存储介质
WO2019004503A1 (ko) 어플리케이션의 취약점을 탐지하는 방법 및 시스템
Fazzini et al. Apimigrator: an api-usage migration tool for android apps
WO2022108318A1 (ko) 스마트 컨트랙트 코드 취약점 분석 장치 및 방법
Do et al. Cheetah: just-in-time taint analysis for android apps
WO2017094967A1 (ko) 자연 언어 처리 스키마 및 그 지식 데이터베이스 구축 방법 및 시스템
JP6013315B2 (ja) アプリケーション開発支援プログラム及びアプリケーション開発支援システム
Cox Our software dependency problem
WO2022102879A1 (ko) 스마트 컨트랙트 내의 취약 트랜잭션 시퀀스 획득 장치 및 방법
CN114691197A (zh) 代码分析方法、装置、电子设备和存储介质
JP2021163488A (ja) ソフトウェアプログラムの修復例からのストリング編集動作の学習
WO2024071505A1 (ko) 멀티-쿼리 스케줄러를 기반으로 멀티-쿼리를 처리하는 방법 및 이러한 방법을 제공하는 데이터 처리 시스템
WO2022114391A1 (ko) 네이티브 코드 분석방지 우회를 위한 프로세스 래핑 방법, 이를 수행하기 위한 기록 매체 및 장치
US7506287B2 (en) Method, system, and program product for pre-compile processing of hardware design language (HDL) source files
WO2024025328A1 (ko) 양자정보기술 시스템 설계/검증 및 사용자 이용 편의성 향상 처리 장치 및 방법
WO2024005318A1 (ko) 프로그래밍 모델을 이용한 자동프로그래밍 시스템 및 방법
CN112580282B (zh) 用于集成电路设计验证的方法、装置、设备以及存储介质

Legal Events

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

Ref document number: 18761380

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019546812

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18761380

Country of ref document: EP

Kind code of ref document: A1