WO2024048833A1 - Api 테스트를 위한 전자 장치 및 그 방법 - Google Patents

Api 테스트를 위한 전자 장치 및 그 방법 Download PDF

Info

Publication number
WO2024048833A1
WO2024048833A1 PCT/KR2022/013891 KR2022013891W WO2024048833A1 WO 2024048833 A1 WO2024048833 A1 WO 2024048833A1 KR 2022013891 W KR2022013891 W KR 2022013891W WO 2024048833 A1 WO2024048833 A1 WO 2024048833A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
test
api
request
test case
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/KR2022/013891
Other languages
English (en)
French (fr)
Inventor
리우인링
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Coupang Corp
Original Assignee
Coupang Corp
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 Coupang Corp filed Critical Coupang Corp
Publication of WO2024048833A1 publication Critical patent/WO2024048833A1/ko
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3604—Analysis of software for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3696—Methods or tools to render software testable

Definitions

  • This disclosure relates to an electronic device and method for automatically testing an API called in various test cases.
  • the present disclosure is proposed to solve the above-mentioned problems, and its purpose is to provide an electronic device and method that can automatically test APIs called according to various test cases without separate coding.
  • An API testing method includes obtaining test case setting information including application programming interface (API) request information and verification information for an API response; transmitting a first request for test case execution to a backend server based on at least part of the test case setting information; and providing first result information generated based on a first response corresponding to the first request and the verification information.
  • API application programming interface
  • the test case setting information may be classified and stored to be searchable based on a hierarchical structure including a service, a domain within the service, and an API that requires a call within the domain.
  • the test case setting information may be generated based on at least some of simulated data corresponding to the traffic history of the terminal corresponding to the test code input by the user and specific terminal identification information.
  • the test case setting information may include at least some of regional information related to execution of the test case, language information, application operating system information, application version information, test environment information, and group setting information for AB testing. You can.
  • the API request information includes information about the transmission method of the first request, mock data usage information to be applied when the first request is transmitted, test parameter information, and test header information. , may include at least some of the test body information.
  • the simulated data use information may include information on whether to use simulated data as data related to a response that must be maintained regardless of changes in the test environment at the time the test case is executed. .
  • the verification information includes field information to be verified in a test case, expected field value information corresponding to the field to be verified, and function information defining the relationship between the actual value information corresponding to the field to be verified and the expected field value information. may include.
  • the API testing method includes receiving a change request for at least some of the obtained test case setting information; And it may further include changing the test case setting information requested to be changed.
  • the API testing method may further include outputting visual information about at least a portion of case coverage and code coverage by cumulatively generated test cases for individual APIs.
  • the API testing method may further include adding a test case that has been debugged and marked as a test automation target among the generated test cases to a candidate list that can be included in the test plan.
  • the API testing method includes obtaining test plan setting information including selection information about one or more test cases selected from the candidate list; and transmitting a second request for test plan execution to the backend server based on at least part of the test plan setting information. And it may further include providing second result information generated based on a second response corresponding to the second request.
  • the test plan setting information includes regional information related to the execution of the test plan, language information, application operating system information, application version information, test environment information, group setting information for AB testing, schedule information for executing the test plan, and the above.
  • At least part of the second result information may further include at least part of the collaboration tool channel information to be transmitted.
  • the second result information may include a report in HTML format in which an execution log of the test plan is recorded.
  • the API testing method includes merging at least some of the changes resulting from the execution of the test plan based on the second result information into a branch separate from the branch on which the test plan was executed. More may be included. More specifically, in the merging step, if the test pass rate among the second result information is more than a set reference rate, at least some of the changes resulting from the execution of the test plan are merged into the separate branch, and the second result is If the test pass rate among the information is less than a set standard rate, changes resulting from the execution of the test plan may not be merged into the separate branch.
  • the API testing method includes the steps of checking whether an error occurred according to the second result information when the test plan is executed in the same test environment as the master branch; And when the error occurs, it may further include reporting the error to a set developer terminal.
  • An electronic device for API testing includes a transceiver, a memory for storing instructions, and a processor, and the processor is connected to the transceiver and the memory to provide Application Programming Interface (API) request information and Obtain configuration information for a test case including verification information for an API response, transmit a first request for test case execution to a backend server based on at least part of the configuration information for the test case, and transmit the first request for test case execution to the backend server.
  • API Application Programming Interface
  • various use cases can be automatically verified without directly coding the API that must be called when executing the test case. This can improve the reliability of the service.
  • FIG. 1 is a schematic configuration diagram showing an environment in which an electronic device operates, according to an embodiment.
  • Figure 2 is a flowchart explaining an API testing method according to an embodiment.
  • 3 to 8 are flowcharts for explaining an API testing method according to an additional embodiment.
  • 9A and 9B are exemplary diagrams of a main page on which visual information is output according to an embodiment.
  • Figure 10 is an example diagram of a first test case page that provides an interface for manually writing test cases according to an embodiment.
  • 11A to 11E are exemplary diagrams of a second test case page that provides an interface for automatically generating and executing test cases according to an embodiment.
  • 12A to 12G are exemplary diagrams of a test plan page that provides an interface for automatically generating and executing a test plan according to an embodiment.
  • FIG. 13 is a block diagram illustrating an electronic device that tests an API according to an embodiment.
  • the “terminal” or “user terminal” mentioned below may be implemented as a computer or portable terminal that can connect to a server or other terminal through a network.
  • the computer includes, for example, a laptop, desktop, laptop, etc. equipped with a web browser
  • the portable terminal is, for example, a wireless communication device that guarantees portability and mobility.
  • all types of communication-based terminals such as IMT (International Mobile Telecommunication), CDMA (Code Division Multiple Access), W-CDMA (W-Code Division Multiple Access), and LTE (Long Term Evolution), smartphones, tablet PCs, etc. It may include a handheld-based wireless communication device.
  • transmission “communication,” “transmission,” “reception,” “transmission,” “transmission,” “reception,” or similar terms of a signal, message, or information refer to the direct transmission of information, message, or information from one component to another. It includes not only what is done, but also what is transmitted through other components.
  • “transmitting” or “transmitting” a signal, message or information as a component indicates the final destination of the signal, message or information and does not mean the direct destination.
  • “related” to two or more data or information means that if one data (or information) is acquired, at least part of other data (or information) can be obtained based on it.
  • first and second may be used to describe various components, but the components should not be limited by the terms. The above terms may be used for the purpose of distinguishing one component from another component.
  • a first component may be referred to as a second component, and similarly, the second component may also be referred to as the first component without departing from the scope of the present disclosure.
  • each block of the processing flow diagrams and combinations of the flow diagram diagrams may be performed by computer program instructions.
  • These computer program instructions can be mounted on a processor of a general-purpose computer, special-purpose computer, or other programmable data processing equipment, so that the instructions performed through the processor of the computer or other programmable data processing equipment are described in the flow chart block(s). It creates the means to perform functions.
  • These computer program instructions may also be stored in computer-usable or computer-readable memory that can be directed to a computer or other programmable data processing equipment to implement a function in a particular manner, so that the computer-usable or computer-readable memory It is also possible to produce manufactured items containing instruction means that perform the functions described in the flowchart block(s).
  • Computer program instructions can also be mounted on a computer or other programmable data processing equipment, so that a series of operational steps are performed on the computer or other programmable data processing equipment to create a process that is executed by the computer, thereby generating a process that is executed by the computer or other programmable data processing equipment. Instructions that perform processing equipment may also provide steps for executing the functions described in the flow diagram block(s).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s).
  • the network 150 includes a local area network (LAN), a wide area network (WAN), a value added network (VAN), a mobile radio communication network, a satellite communication network, and their respective networks. It is a comprehensive data communication network that includes a combination and allows each component shown in Figure 1 to communicate smoothly with each other, and may include wired Internet, wireless Internet, and mobile wireless communication network.
  • LAN local area network
  • WAN wide area network
  • VAN value added network
  • mobile radio communication network a mobile radio communication network
  • satellite communication network and their respective networks.
  • It is a comprehensive data communication network that includes a combination and allows each component shown in Figure 1 to communicate smoothly with each other, and may include wired Internet, wireless Internet, and mobile wireless communication network.
  • Wireless communications include, for example, wireless LAN (Wi-Fi), Bluetooth, Bluetooth low energy, ZigBee, WFD (Wi-Fi Direct), UWB (ultra wideband), and infrared communication (IrDA, infrared Data Association). ), NFC (Near Field Communication), etc., but are not limited thereto.
  • the electronic device 110 creates a test case based on input from the user terminal 120, sample data, predefined templates, etc., sends a request to an API necessary to execute the test case, and receives a response. Specifically, the electronic device 110 communicates with the backend server 120 to send a request to an API and receive a response thereto, communicates with the user terminal 130 to generate a test case, and results related to test execution. It may communicate with the user terminal 130 or the developer terminal 140 to provide.
  • the electronic device 110 may be a single server that performs calculations for API testing, but depending on the embodiment, it may be composed of multiple servers, and one or more servers and an external cloud server are connected to enable electronic communication. It may be configured in the form
  • the backend server 120 receives a request related to the API from the electronic device 110 and processes it.
  • FIGS. 2 to 8 may be performed, for example, by the electronic device 110 described above.
  • Figure 2 is a flowchart explaining an API testing method according to an embodiment.
  • step S210 the electronic device 110 obtains test case setting information including 1) Application Programming Interface (API) request information and 2) verification information for the API response.
  • API Application Programming Interface
  • test case setting information may be classified and stored so that the electronic device 110 can search based on a hierarchical structure including a service, a domain within the service, and an API that requires a call within the domain.
  • a service' - 'domain within service' - 'API requiring intra-domain call' is an example of a hierarchical structure.
  • 'service' represents an upper layer divided into applications
  • 'domain within service' represents an upper layer divided into applications.
  • the middle layer is divided into pages where detailed services are provided within the application
  • 'API that requires calls within the domain' can be an example of the lower layer divided by functions provided within each page.
  • the electronic device 110 can provide a directory interface with a hierarchical structure to the user terminal 130, and the user can use the interface to access test suites, You can select or set test cases, test steps, etc. in detail.
  • test case setting information may be generated based on at least a portion of simulated data corresponding to a test code input from a user and traffic history of a terminal corresponding to specific terminal identification information. For example, when a user manually inputs a test code through the user terminal 120, the electronic device 110 may load the corresponding test code as part of test case setting information when creating a test case. In this case, from the perspective of the user terminal 120, the test case creation task and the manual input task of test code may be performed on different pages. Meanwhile, as another example, the electronic device 110 extracts mock data based on the traffic history of terminal A corresponding to the identification information (PCID) specified by the user terminal 120, and uses the mock data as a test case. Test case setting information can be created by reflecting it in the request or response.
  • PCID identification information
  • the test case setting information may include at least some of regional information related to the execution of the test case, language information, application operating system information, application version information, test environment information, and group setting information for AB testing.
  • the test case configuration information includes which region the test case will be executed in (region information), what language it will be executed in (language information), which operating system it will be executed on (application operating system information), and which version of the application it will be executed based on. (application version information), how to set up the hardware/software/network that supports test execution (test environment information), how to set up the control group and experimental group for the AB test (group setting information for AB testing), etc. It may contain information about
  • the API request information includes information about the transmission method of the first request, mock data usage information to be applied when the first request is transmitted, test parameter information, test header information, and test body. It may contain at least some of the information.
  • information about the transmission method of the first request is determined based on which method among the GET method and the POST method. It refers to information that makes decisions. If you select the GET method, variables are exposed in the URL, data is included in the header, and caching is possible at the expense of being relatively vulnerable to security, whereas if you select the POST method, variables are not exposed in the URL, data is included in the body, and the data is included in the body. Although it is relatively secure, it cannot be cached.
  • the simulated data use information may include information on whether to use simulated data as data related to a response that must be maintained regardless of changes in the test environment at the time the test case is executed.
  • the mock data use information may further include information on whether to mock all data, only the data included in the request, or only the data included in the header.
  • test parameter information may include information about parameter types and parameter values related to the first request
  • test header information may include supplementary data for execution of the test case
  • test body information may include the first request. 1 May include the contents of the request.
  • the verification information includes 1) verification target field information of a test case, 2) expected field value information corresponding to the verification target field, and 3) between actual value information and expected field value information corresponding to the verification target field. It may contain function information that defines the relationship. Expected field value information refers to the expected value of the field to be verified when executing a test case, and function information refers to whether the relationship between the actual value and the expected value corresponding to the field to be verified is equal to, and whether the actual value is greater than the expected value. It can refer to a type of function that defines whether it is larger or smaller, whether the actual value is different from the expected value, etc.
  • step S220 the electronic device 110 transmits a first request for test case execution to the backend server 120 based on at least part of the test case setting information.
  • the electronic device 110 may transmit the first request to the backend server 120.
  • a test case execution request from the user terminal 130 may be made through manipulating the interface on the page output through the user terminal 130.
  • step S230 the electronic device 110 provides first result information generated based on the first response and verification information corresponding to the first request.
  • the first response includes code information of a test case executed according to the first request, and the first result information determines whether the actual value of the field to be verified in the first response satisfies the relationship between the expected value and function information. It may include information about whether or not
  • the electronic device 110 may provide the first response and first result information by dividing them with tabs on a page output to the user terminal 130.
  • the first result information provided by the electronic device 110 may include log information of a test case executed on the target terminal (console).
  • 3 to 8 are flowcharts for explaining an API testing method according to an additional embodiment.
  • FIG. 3 is a flowchart of an embodiment in which test case setting information is changed, after the electronic device 110 obtains test case setting information including API request information and verification information for the API response (step S310). , upon receiving a change request for at least part of the acquired test case setting information (step S320), the test case setting information requested to be changed can be changed (step S330). Thereafter, the electronic device 110 transmits a first request for test case execution to the backend server 120 based on at least part of the test case setting information (step S340), and provides a first response corresponding to the first request and First result information generated based on verification information may be provided (step S350).
  • test case Setting information may be stored in a storage space within the electronic device 110, but is not limited thereto and may be stored in the back-end server 120 or a separate storage or cache).
  • the electronic device 110 transmits a first request based on at least part of the updated test case setting information and allows the test case to be executed, so that changes desired by the user can be quickly reflected before the test case is executed.
  • FIG. 4 is a flowchart of an embodiment that provides cumulatively generated results in a visual form, in which the electronic device 110 obtains test case setting information including API request information and verification information for the API response (step S410), transmitting a first request for test case execution to the backend server 120 based on at least part of the test case setting information (step S420), and based on the first response and verification information corresponding to the first request
  • the generated first result information may be provided (step S430).
  • the electronic device 110 may output visual information about at least some of the case coverage and code coverage by the test cases accumulated for each API (step S440 ).
  • the electronic device 110 can help the user intuitively understand the current test situation by visually providing the degree of coverage by test case for each API to the user terminal 130.
  • 'case coverage' refers to the ratio of automated test cases among all test cases generated
  • 'code coverage' refers to the ratio of tests performed by code in the entire range of test subjects.
  • FIG 5 is a flowchart of an embodiment of adding a test case as a candidate to be included in a test plan, in which the electronic device 110 obtains test case setting information including API request information and verification information for the API response (Ste S510), transmitting a first request for test case execution to the backend server 120 based on at least part of the test case setting information (step S520), and based on the first response and verification information corresponding to the first request
  • the first result information generated can be provided (step S530).
  • the electronic device 110 may add test cases that have completed debugging and are marked as test automation targets among the generated test cases to the candidate list that can be included in the test plan (step S540).
  • the electronic device 110 marks the test case selected as an automation target by the user terminal 130 and adds it to a list of candidates that can be included in a test plan that is a higher hierarchy than the test case.
  • a candidate list may be provided to the user terminal 130. If the user selects a test case in the candidate list through the user terminal 130, the electronic device 110 adds the test case to the test plan corresponding to the upper hierarchy of the test case. can be updated.
  • the way the electronic device 110 marks test cases selected for automation may vary, and the electronic device 110 may apply graphic effects to the marked test cases on the page displayed on the user terminal 130. , graphic objects can be displayed around marked test cases.
  • Figure 6 is a flowchart of an embodiment of executing a test plan, in which the electronic device 110 acquires test case setting information including API request information and verification information for the API response (step S610), and executes the test case.
  • a first request for test case execution is transmitted to the backend server 120 based on at least some of the configuration information (step S620), and a first result is generated based on the first response and verification information corresponding to the first request.
  • Information is provided (step S630), and among the generated test cases, test cases that have completed debugging and are marked as test automation targets can be added to the candidate list that can be included in the test plan (step S640).
  • the electronic device 110 obtains test plan setting information including selection information about one or more test cases selected from the candidate list (step S650), and based on at least part of the test plan setting information, the backend server 120 A second request for test plan execution may be transmitted (step S660), and second result information generated based on the second response corresponding to the second request may be provided (step S670).
  • the test plan setting information includes 1) regional information, 2) language information, 3) application operating system information, 4) application version information, 5) test environment information, and 6) AB test related to the execution of the test plan. It may further include at least some of group setting information for the test plan, 7) schedule information for executing the test plan, and 8) collaboration tool channel information through which at least part of the second result information will be transmitted.
  • the test plan setting information includes which region the test plan will be executed in (region information), what language it will be executed in (language information), which operating system it will be executed on (application operating system information), and which version of the application it will be executed based on. (application version information), how to set up the hardware/software/network that supports test execution (test environment information), how to set up the control group and experimental group for the AB test (group setting information for AB testing), It may include information about the specific time or cycle at which the test plan will be executed (schedule information), and which channel in a specific collaboration tool will deliver at least part of the second result information (collaboration tool channel information).
  • the second result information may include a report in HTML format in which an execution log of the test plan is recorded.
  • the second result information may be provided in the form of a table divided by the identification number of the test plan, and when the identification number of a test plan is selected by the user terminal 130, the electronic device 110 displays the selected identification number.
  • a report in HTML format corresponding to can be provided through a new page.
  • FIG. 7 is a flowchart of an embodiment reflecting the results of executing a test plan, in which the electronic device 110 obtains test case setting information including API request information and verification information for the API response (step S710), transmitting a first request for test case execution to the backend server 120 based on at least part of the test case setting information (step S720), and based on the first response and verification information corresponding to the first request
  • the generated first result information is provided (step S730), and among the generated test cases, test cases that have completed debugging and are marked as test automation targets are added to the candidate list that can be included in the test plan (step S740), and the candidate list
  • step S760 and second result information generated based on the second response corresponding to the second request may be provided (step S770).
  • the electronic device 110 determines whether the test pass rate among the second result information is greater than or equal to a set reference rate (step S780), and in that case, at least some of the changes resulting from the execution of the test plan are transferred to the branch where the test plan was executed (step S780). branch) (step S790), and if the test pass rate is less than a set standard rate, changes resulting from the execution of the test plan may not be merged into the separate branch.
  • the electronic device 110 performs a test when the relationship between the actual value of the field to be verified, the expected value (expected field value), and function information in the second result information generated as the test plan is executed is satisfied. is determined to have passed, and if the test pass rate is higher than the standard rate (e.g., 98%), changes to the test plan can be reflected in the actual service by merging them into the master branch.
  • the standard rate e.g., 98%
  • Figure 8 relates to an embodiment of processing errors that occur during execution of a test plan, in which the electronic device 110 obtains test case setting information including API request information and verification information for the API response (step S810), transmitting a first request for test case execution to the backend server 120 based on at least part of the test case setting information (step S820), and based on the first response and verification information corresponding to the first request
  • the generated first result information is provided (step S830), and among the generated test cases, test cases that have completed debugging and are marked as test automation targets are added to the candidate list that can be included in the test plan (step S840), and the candidate list
  • step S860 second result information generated based on the second response corresponding to the second request may be provided (step S870).
  • the electronic device 110 checks whether an error has occurred according to the second result information (step S880), and if an error has occurred, sends the error to the set developer terminal (step S880). 140) (step S890).
  • the electronic device 110 may report to the developer terminal 140 an error that occurs as the test plan is executed in the same test environment as the environment in which the API is called from the master branch. According to an embodiment, the electronic device 110 may transmit at least some of a push notification, a vibration notification, a collaboration tool notification, a voice message, a text message, and an email indicating that an error has occurred to the developer terminal 140.
  • FIGS. 9A and 9B are exemplary diagrams of a main page on which visual information is output according to an embodiment. Shown in FIGS. 9A and 9B are some graphs on the main page displaying visual information, and the main page may display various graphs, tables, interfaces, etc. in addition to the graphs in FIGS. 9A and 9B.
  • Figure 9a is an example of visual information 910 showing case coverage, and the API that needs to be called for each domain within the service is displayed on the vertical axis.
  • the horizontal axis indicates the number of test cases that call each API
  • the hatched area slanted to the right indicates automated test cases
  • the hatched areas on both sides indicate test cases that have not been automated
  • the hatched area slanted to the left indicates whether or not it has been automated yet.
  • case coverage was 87.97%, indicating that 87.97% of test cases were automated.
  • case coverage was 50.00%, indicating that half of the test cases were automated.
  • Figure 9b is an example of visual information showing code coverage, showing the percentage of tests performed by code in the entire range of test targets corresponding to each of the three types of APIs called (active_line_cov cart_front_api, branch_coverage cart_front_api, line_coverage cart_front_api). It is shown.
  • the horizontal axis represents the time point per day when the test was run. For example, in the case of active_line_cov cart_front_api, the highest code coverage was 97.4%, the lowest 92.8%, and an average of 95.1% in tests run a total of 5 times, and the code coverage for branch_coverage cart_front_api was 23.7%, the lowest 22.6%, and 22.6% in tests run a total of 5 times. The average code coverage was 23.1%. By visually checking code coverage, users can quickly determine which APIs have had the most code executed compared to the total test coverage.
  • Figure 10 is an example diagram of a first test case page that provides an interface that can manually create test cases according to an embodiment
  • Figures 11A to 11E show an interface that can automatically create and execute test cases according to an embodiment. This is an example of the second test case page provided.
  • test contents are as described in 1010. Specifically, according to the test contents described in 1010, when the user enters the SDP (Single Detail Page), the expected result (test response that should be output) is 1) the badge indicating the rocket installation service should be displayed normally; , 2) the delivery company must be displayed normally, 3) the product delivery date (PDD) must be displayed normally, and 4) the shipping fee must be displayed normally.
  • SDP Single Detail Page
  • test cases including manually created test cases can be selectively executed as shown in FIG. 10, and the currently created test case is in the first section 1110.
  • a test step named '/ ⁇ productID ⁇ ' is selected.
  • an interface for selecting the request transmission method as API request information is provided at the top, and a tab (Step Mock) for checking and changing mock data use information is provided at the bottom.
  • a tab to check and change test parameter information (Params)
  • a tab to check and change test header information (Headers)
  • a tab to check and change test body information (Body)
  • a tab to check and change verification information There is a tab (Assertion) that allows you to check and change the data to be extracted for other test cases or test steps (Extract).
  • the electronic device 110 may provide the user terminal 130 with an interface in which each API request information or verification information is displayed divided by tabs.
  • the third section 1130 related to test case setting information displays mock data usage information corresponding to the currently selected tab (Step Mock). According to this, it can be seen that when the test case including the corresponding test step is executed, the delivery type will remain as 'rocket delivery'. As another example, looking at the third section 1130 of FIG. 11B, verification conditions for determining whether the test of the corresponding test step passes are shown.
  • the test case's verification target field information (expression), function information (function), and expected field value information (expected) can be set by the user.
  • the fourth section 1140 displays first response or first result information according to execution of the test case.
  • the first response and first result information may be displayed separated by tabs.
  • the first response may be displayed in the Response tab
  • the fourth section 1140 of FIG. 11D the first result information may be displayed in the Assertion Result tab. It can be.
  • the fourth section 1140 of FIG. 11D displays the actual value (actual) of the field to be verified according to test case execution, and since this value is the same as the expected value (expected) of the third section 1130, the electronic device 110 ) can be judged to have passed the test case.
  • the electronic device 110 provides the user terminal 130 with a page on which the first response or first result information is displayed on an interface different from the interface on which the API request information or verification information is displayed. can do. That is, the user requests the electronic device 110 to send a first request to execute the selected test case (or test suite or test step) (by selecting the Send button), and sends the first response and first result information. It can be provided immediately on the same page.
  • the display position and arrangement of the above-described interface may be set in various ways depending on the embodiment.
  • the electronic device 110 also provides an interface that provides log information according to test execution in the console or an interface that can change test case setting information by displaying a second test case page by the user terminal 130. It may be provided to the user terminal 130 according to the operation of the interface. For example, as shown in FIGS. 11A to 11D, log information according to test execution in the console may be displayed when the console log button in the fourth section 1140 is selected, and as shown in FIG. 11E, test case setting information A window where you can change can be displayed when you select the Config button.
  • test case setting information is a drop-down list corresponding to 'Region'
  • language information is a drop-down list corresponding to 'Language'
  • the application operating system information is a drop-down list corresponding to 'Android'
  • the application version information is a drop-down list corresponding to 'App Version'
  • the test environment information is a drop-down list corresponding to 'Test Env', enabling AB testing.
  • Group setting information can be changed through the text input box corresponding to 'Test AB'.
  • the on-off control corresponding to 'Diff Run' at the top is an interface that determines whether to activate the "Diff rule" that can be additionally included in the verification conditions to determine whether the test case passes.
  • the electronic device 110 when the "Diff rule" is activated, the same output is displayed on the user terminal 130 when the test case is executed in the predefined reference environment and the test environment at the time the test case is executed. It can be determined whether it is provided, and if the same output is provided, it can be determined that the "Diff rule", which is a condition for passing the test case, has passed.
  • Figures 12A to 12G are exemplary diagrams of a test plan page that provides an interface for automatically generating and executing a test plan according to an embodiment.
  • a list of test plans including one or more test cases is provided through a directory interface.
  • a test plan named 'Regression-sdp_front_api' among the test plans of the first section 1210 is executed (e.g., by the user selecting the Run button)
  • a test case configuring the test plan A list of may be displayed in the second section 1220.
  • a list of test cases included in the executed test plan may be displayed in another section of the same page.
  • the list of test cases may be provided in a table format with an identification number (Report Id) assigned to each test case, and whether each test case passes or not (status) may be provided together.
  • the execution log of the test case corresponding to the selected identification number is recorded in HTML format, as shown in FIG. 12C. Reports may be provided.
  • the report in HTML format can optionally display the number of test case executions, execution time, pass status, test content, test scenario, etc.
  • the third section 1230 displays the current test plan creation stage, and the fourth section 1240 displays step 1 ( A text input box that can perform the task of the test plan name designation step) may be displayed.
  • the fifth section 1250 may display an interface that can specify the hierarchy (case_level, suite_level, role_level) of the test plan in relation to the task of the second stage (test case selection stage to be included in the test plan),
  • Section 6 1260 may display a directory interface through which test cases can be directly selected.
  • the seventh section 1270 is a collaboration tool to which at least part of the schedule information for executing the test plan and the second result information will be transmitted.
  • An interface for setting channel information may be displayed.
  • FIG. 13 is a block diagram illustrating an electronic device that tests an API according to an embodiment.
  • the electronic device 110 may include a transceiver 111, a processor 113, and a memory 115.
  • the electronic device 110 is connected to the database 120 through the transceiver 111 and can exchange data.
  • the processor 113 may perform at least one method described above through FIGS. 1 to 12g.
  • the memory 115 may store information for performing at least one method described above with reference to FIGS. 1 to 12G.
  • Memory 115 may be volatile memory or non-volatile memory.
  • the processor 113 can control the electronic device 110 to execute programs and provide information.
  • the code of the program executed by the processor 113 may be stored in the memory 115.
  • the processor 113 is connected to the transceiver 111 and the memory 115 to obtain setting information for the test case including API request information and verification information for the API response, and at least part of the setting information for the test case Based on , a first request for test case execution may be transmitted to the backend server, and result information generated based on the first response and verification information corresponding to the first request may be provided.
  • the electronic device 110 shown in FIG. 13 shows only components related to this embodiment. Accordingly, those skilled in the art can understand that other general-purpose components may be included in addition to the components shown in FIG. 13.
  • Devices include a processor, memory for storing and executing program data, permanent storage such as a disk drive, a communication port for communicating with an external device, a touch panel, keys, buttons, etc. It may include a user interface device, etc.
  • Methods implemented as software modules or algorithms may be stored on a computer-readable recording medium as computer-readable codes or program instructions executable on the processor.
  • computer-readable recording media include magnetic storage media (e.g., ROM (read-only memory), RAM (random-access memory), floppy disk, hard disk, etc.) and optical read media (e.g., CD-ROM). ), DVD (Digital Versatile Disc), etc.
  • the computer-readable recording medium is distributed among computer systems connected to a network, so that computer-readable code can be stored and executed in a distributed manner.
  • the media may be readable by a computer, stored in memory, and executed by a processor.
  • This embodiment can be represented by functional block configurations and various processing steps. These functional blocks may be implemented as any number of hardware or/and software configurations that execute specific functions. For example, embodiments include integrated circuit configurations such as memory, processing, logic, look-up tables, etc. that can execute various functions under the control of one or more microprocessors or other control devices. can be hired. Similar to how the components can be implemented as software programming or software elements, this embodiment includes various algorithms implemented as combinations of data structures, processes, routines or other programming constructs, such as C, C++, Java ( It can be implemented in a programming or scripting language such as Java), assembler, etc. Functional aspects may be implemented as algorithms running on one or more processors.
  • this embodiment may employ conventional technologies for electronic environment setting, signal processing, message processing, and/or data processing.
  • Terms such as “mechanism,” “element,” “means,” and “composition” can be used broadly and are not limited to mechanical and physical components. The term may include the meaning of a series of software routines in connection with a processor, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

API 테스트를 위한 전자 장치 및 그 방법이 개시된다. 일 실시 예에 따른 API 테스트 방법은 Application Programming Interface(API) 요청 정보 및 API 응답에 대한 검증 정보를 포함하는 테스트 케이스 설정 정보를 획득하는 단계, 테스트 케이스 설정 정보 중 적어도 일부를 기반으로 백엔드 서버에 테스트 케이스 실행을 위한 제1 요청을 전송하는 단계 및 제1 요청에 대응하는 제1 응답 및 검증 정보를 기반으로 생성된 제1 결과 정보를 제공하는 단계를 포함한다.

Description

API 테스트를 위한 전자 장치 및 그 방법
본 개시는 다양한 테스트 케이스에서 호출되는 API를 자동으로 테스트하는 전자 장치 및 그 방법에 관한 것이다.
애플리케이션에서 제공하는 서비스의 종류가 다양해질수록, 예기치 않은 오류가 발생할 가능성은 높아진다. 이러한 오류가 누적되면 사용자가 서비스를 더 이상 이용하지 않게 되고, 이는 애플리케이션의 수익성 악화로 이어질 수 있다.
때문에, 애플리케이션의 품질보증(QA; Quality Assurance) 차원에서 오류를 미연에 방지하기 위한 테스트가 필수적으로 이루어져야 하고, 이러한 테스트는 다양한 유즈 케이스를 상정하여 정의되어야 한다.
그런데, 테스트해야 할 수많은 유즈 케이스 각각마다 호출이 필요한 API(Application Programming Interface) 역시 다양하므로, 테스트 관리자의 효율적인 업무를 위해서는 다양한 API를 별도의 코딩 없이 쉽게 테스트할 수 있는 시스템이 요구된다.
이와 관련하여, KR1003598B1 건 등의 선행문헌들을 참조할 수 있다.
본 개시는 상술한 문제점을 해결하기 위해 제안된 것으로, 다양한 테스트 케이스에 따라 호출되는 API를 별도의 코딩 없이 자동으로 테스트할 수 있는 전자 장치 및 방법을 제공하는 것을 목적으로 한다.
본 개시에 의해 이루고자 하는 기술적 과제는 상기된 바와 같은 기술적 과제들로 한정되지 않으며, 이하의 실시 예들로부터 또 다른 기술적 과제들이 유추될 수 있다.
개시되는 일 실시 예에 따른 API 테스트 방법은, Application Programming Interface(API) 요청 정보 및 API 응답에 대한 검증 정보를 포함하는 테스트 케이스 설정 정보를 획득하는 단계; 상기 테스트 케이스 설정 정보 중 적어도 일부를 기반으로 백엔드 서버에 테스트 케이스 실행을 위한 제1 요청을 전송하는 단계; 및 상기 제1 요청에 대응하는 제1 응답 및 상기 검증 정보를 기반으로 생성된 제1 결과 정보를 제공하는 단계를 포함한다.
일 실시 예에 따르면, 상기 테스트 케이스 설정 정보는, 서비스, 서비스 내 도메인(domain) 및 도메인 내 호출이 필요한 API를 포함하는 계층 구조에 기반하여 탐색 가능하도록 분류 및 저장될 수 있다.
일 실시 예에 따르면, 상기 테스트 케이스 설정 정보는, 사용자로부터 입력된 테스트 코드 및 특정 단말 식별 정보에 대응하는 단말의 트래픽 이력에 대응하는 모의 데이터 중 적어도 일부에 기반하여 생성될 수 있다.
일 실시 예에 따르면, 상기 테스트 케이스 설정 정보는, 테스트 케이스의 실행과 관련된 지역 정보, 언어 정보, 애플리케이션 운영체제 정보, 애플리케이션 버전 정보, 테스트 환경 정보, AB 테스트를 위한 그룹 설정 정보 중 적어도 일부를 포함할 수 있다.
일 실시 예에 따르면, 상기 API 요청 정보는, 상기 제1 요청의 전송 방식에 대한 정보, 상기 제1 요청이 전송될 시에 적용될, 모의 데이터(mock data) 이용 정보, 테스트 파라미터 정보, 테스트 헤더 정보, 테스트 바디 정보 중 적어도 일부를 포함할 수 있다.
구체적으로, 상기 모의 데이터 이용 정보는, 상기 테스트 케이스가 실행되는 시점의 테스트 환경의 변화와 무관하게 유지되어야 하는 응답(response)에 관련된 데이터로 모의 데이터를 이용할 것인지 여부에 대한 정보를 포함할 수 있다.
구체적으로, 상기 검증 정보는, 테스트 케이스의 검증 대상 필드 정보, 검증 대상 필드에 대응하는 예상 필드 값 정보 및 검증 대상 필드에 대응하는 실제 값 정보와 상기 예상 필드 값 정보 사이의 관계를 정의하는 함수 정보를 포함할 수 있다.
일 실시 예에 따르면, 상기 API 테스트 방법은, 상기 획득된 테스트 케이스 설정 정보 중 적어도 일부에 대한 변경 요청을 수신하는 단계; 및 상기 변경 요청된 테스트 케이스 설정 정보를 변경하는 단계를 더 포함할 수 있다.
일 실시 예에 따르면, 상기 API 테스트 방법은, 개별 API에 대해 누적 생성된 테스트 케이스에 의한 케이스 커버리지 및 코드 커버리지 중 적어도 일부에 대한 시각적 정보를 출력하는 단계를 더 포함할 수 있다.
일 실시 예에 따르면, 상기 API 테스트 방법은, 생성된 테스트 케이스 중 디버깅이 완료되어 테스트 자동화 대상으로 마킹된 테스트 케이스를 테스트 플랜에 포함될 수 있는 후보 리스트에 추가하는 단계를 더 포함할 수 있다.
추가적인 실시 예에 따르면, 상기 API 테스트 방법은, 상기 후보 리스트에서 선택된 하나 이상의 테스트 케이스에 대한 선택 정보를 포함하는 테스트 플랜 설정 정보를 획득하는 단계; 및 상기 테스트 플랜 설정 정보 중 적어도 일부를 기반으로 상기 백엔드 서버에 테스트 플랜 실행을 위한 제2 요청을 전송하는 단계; 및 상기 제2 요청에 대응하는 제2 응답을 기반으로 생성된 제2 결과 정보를 제공하는 단계를 더 포함할 수 있다.
구체적으로, 상기 테스트 플랜 설정 정보는, 테스트 플랜의 실행과 관련된 지역 정보, 언어 정보, 애플리케이션 운영체제 정보, 애플리케이션 버전 정보, 테스트 환경 정보, AB 테스트를 위한 그룹 설정 정보, 테스트 플랜이 실행될 스케줄 정보 및 상기 제2 결과 정보 중 적어도 일부가 전송될 협업 툴 채널 정보 중 적어도 일부를 더 포함할 수 있다.
구체적으로, 상기 제2 결과 정보는, 테스트 플랜의 실행 로그가 기록된 HTML 형식의 리포트를 포함할 수 있다.
추가적인 실시 예에 따르면, 상기 API 테스트 방법은, 상기 제2 결과 정보에 기반하여 테스트 플랜이 실행됨에 따른 변경 사항 중 적어도 일부를 테스트 플랜이 실행된 브랜치(branch)와는 별도의 브랜치에 병합하는 단계를 더 포함할 수 있다. 보다 구체적으로, 상기 병합하는 단계는, 상기 제2 결과 정보 중 테스트 패스 비율이 설정된 기준 비율 이상인 경우, 테스트 플랜이 실행됨에 따른 변경 사항 중 적어도 일부를 상기 별도의 브랜치에 병합하고, 상기 제2 결과 정보 중 테스트 패스 비율이 설정된 기준 비율 미만인 경우, 테스트 플랜이 실행됨에 따른 변경 사항을 상기 별도의 브랜치에 병합하지 않는 것을 특징으로 할 수 있다.
추가적인 실시 예에 따르면, 상기 API 테스트 방법은, 테스트 플랜이 마스터 브랜치와 동일한 테스트 환경에서 실행된 경우, 상기 제2 결과 정보에 따라 에러가 발생했는지 확인하는 단계; 및 상기 에러가 발생한 경우, 상기 에러를 설정된 개발자 단말에 보고하는 단계를 더 포함할 수 있다.
개시되는 일 실시 예에 따른 API 테스트를 위한 전자 장치는, 트랜시버, 명령어를 저장하는 메모리 및 프로세서를 포함하고, 상기 프로세서는, 상기 트랜시버 및 상기 메모리와 연결되어, Application Programming Interface(API) 요청 정보 및 API 응답에 대한 검증 정보를 포함하는 테스트 케이스에 대한 설정 정보를 획득하고, 상기 테스트 케이스에 대한 설정 정보 중 적어도 일부를 기반으로 백엔드 서버에 테스트 케이스 실행을 위한 제1 요청을 전송하고, 상기 제1 요청에 대응하는 제1 응답 및 상기 검증 정보를 기반으로 생성된 결과 정보를 제공한다.
기타 실시 예들의 구체적인 사항들은 상세한 설명 및 도면들에 포함되어 있다.
본 개시에 따르면, 테스트 케이스에 관한 설정 정보에 기반하여 테스트 케이스를 실행시키고 응답을 검증하여 사용자에게 제공함으로써, 테스트 케이스 실행 시 호출해야 하는 API를 직접 코딩하지 않고도 자동으로 다양한 유즈 케이스를 검증할 수 있어 서비스의 신뢰성을 제고할 수 있다.
발명의 효과는 이상에서 언급한 효과로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 청구범위의 기재로부터 당해 기술 분야의 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
도 1은 일 실시 예에 따른 전자 장치가 작동하는 환경을 나타낸 개략적인 구성도이다.
도 2는 일 실시 예에 따른 API 테스트 방법을 설명하기 위한 흐름도이다.
도 3 내지 8은 추가적인 실시 예에 따른 API 테스트 방법을 설명하기 위한 흐름도이다.
도 9a 및 9b는 일 실시 예에 따라 시각적 정보가 출력된 메인 페이지의 예시도이다.
도 10은 일 실시 예에 따라 테스트 케이스를 수동으로 작성 가능한 인터페이스를 제공하는 제1 테스트 케이스 페이지의 예시도이다.
도 11a 내지 11e는 일 실시 예에 따라 테스트 케이스를 자동으로 생성 및 실행 가능한 인터페이스를 제공하는 제2 테스트 케이스 페이지의 예시도이다.
도 12a 내지 12g는 일 실시 예에 따라 테스트 플랜을 자동으로 생성 및 실행 가능한 인터페이스를 제공하는 테스트 플랜 페이지의 예시도이다.
도 13은 일 실시 예에 따라 API를 테스트하는 전자 장치를 설명하기 위한 블록도이다.
실시 예들에서 사용되는 용어는 본 개시에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어들을 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 개시에서 사용되는 용어는 단순한 용어의 명칭이 아닌, 그 용어가 가지는 의미와 본 개시의 전반에 걸친 내용을 토대로 정의되어야 한다.
명세서 전체에서 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있음을 의미한다. 또한, 명세서에 기재된 "...부", "...모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하고, 이는 하드웨어 또는 소프트웨어로 구현되거나 하드웨어와 소프트웨어의 결합으로 구현될 수 있으며, 도시된 예와 달리 구체적 동작에 있어 명확히 구분되지 않을 수 있다.
명세서 전체에서 기재된 "a, b, 및 c 중 적어도 하나"의 표현은, 'a 단독', 'b 단독', 'c 단독', 'a 및 b', 'a 및 c', 'b 및 c', 또는 'a, b, 및 c 모두'를 포괄할 수 있다.
이하에서 언급되는 "단말" 또는 "사용자 단말"은 네트워크를 통해 서버나 타 단말에 접속할 수 있는 컴퓨터나 휴대용 단말로 구현될 수 있다. 여기서, 컴퓨터는 예를 들어, 웹 브라우저(WEB Browser)가 탑재된 노트북, 데스크톱(desktop), 랩톱(laptop) 등을 포함하고, 휴대용 단말은 예를 들어, 휴대성과 이동성이 보장되는 무선 통신 장치로서, IMT(International Mobile Telecommunication), CDMA(Code Division Multiple Access), W-CDMA(W-Code Division Multiple Access), LTE(Long Term Evolution) 등의 통신 기반 단말, 스마트폰, 태블릿 PC 등과 같은 모든 종류의 핸드헬드(Handheld) 기반의 무선 통신 장치를 포함할 수 있다.
이하의 설명에 있어서, 신호, 메시지 또는 정보의 "전송", "통신", "송신", "수신" 기타 이와 유사한 의미의 용어는 일 구성요소에서 다른 구성요소로 정보, 메시지 또는 정보가 직접 전달되는 것뿐만이 아니라 다른 구성요소를 거쳐 전달되는 것도 포함한다.
특히 신호, 메시지 또는 정보를 일 구성요소로 "전송" 또는 "송신"한다는 것은 그 신호, 메시지 또는 정보의 최종 목적지를 지시하는 것이고 직접적인 목적지를 의미하는 것이 아니다. 이는 신호, 메시지 또는 정보의 "수신"에 있어서도 동일하다. 또한 본 개시에 있어서, 2 이상의 데이터 또는 정보가 "관련"된다는 것은 하나의 데이터(또는 정보)를 획득하면, 그에 기초하여 다른 데이터(또는 정보)의 적어도 일부를 획득할 수 있음을 의미한다.
또한, 제1, 제2 등의 용어는 다양한 구성 요소들을 설명하는데 사용될 수 있지만, 상기 구성 요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성 요소를 다른 구성 요소로부터 구별하는 목적으로 사용될 수 있다.
예를 들어, 본 개시의 권리 범위를 벗어나지 않으면서 제1 구성 요소는 제2 구성 요소로 명명될 수 있고, 유사하게 제2 구성 요소도 제1 구성 요소로 명명될 수 있다.
아래에서는 첨부한 도면을 참고하여 본 개시의 실시 예에 대하여 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 개시는 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다.
이하에서는 도면을 참조하여 본 개시의 실시 예들을 상세히 설명한다.
실시 예를 설명함에 있어서 본 발명이 속하는 기술 분야에 익히 알려져 있고 본 발명과 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 발명의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
마찬가지 이유로 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.
본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.
도 1은 일 실시 예에 따른 전자 장치가 작동하는 환경을 나타낸 개략적인 구성도이다. 도 1을 참조하면, 전자 장치(110), 백엔드 서버(120), 사용자 단말(130) 및 개발자 단말(140)은 연결된 네트워크(150)를 통해 서로 통신하거나, 외부의 다른 장치와 통신할 수 있다. 네트워크(150)는 근거리 통신망(Local Area Network; LAN), 광역 통신망(Wide Area Network; WAN), 부가가치 통신망(Value Added Network; VAN), 이동 통신망(mobile radio communication network), 위성 통신망 및 이들의 상호 조합을 포함하며, 도 1에 도시된 각 구성 주체가 서로 원활하게 통신을 할 수 있도록 하는 포괄적인 의미의 데이터 통신망이며, 유선 인터넷, 무선 인터넷 및 모바일 무선 통신망을 포함할 수 있다. 무선 통신은 예를 들어, 무선 랜(Wi-Fi), 블루투스, 블루투스 저 에너지(Bluetooth low energy), 지그비, WFD(Wi-Fi Direct), UWB(ultra wideband), 적외선 통신(IrDA, infrared Data Association), NFC(Near Field Communication) 등이 있을 수 있으나, 이에 한정되는 것은 아니다.
전자 장치(110)는 사용자 단말(120)의 입력이나 샘플 데이터, 사전에 정의된 템플릿 등에 의해 테스트 케이스를 생성하고, 테스트 케이스를 실행하기 위해 필요한 API에 요청을 보내고 응답을 수신한다. 구체적으로, 전자 장치(110)는 API에 요청을 보내고 그에 대한 응답을 수신하기 위해 백엔드 서버(120)와 통신하고, 테스트 케이스를 생성하기 위해 사용자 단말(130)과 통신하며, 테스트 실행과 관련된 결과를 제공하기 위해 사용자 단말(130) 또는 개발자 단말(140)과 통신할 수 있다.
전자 장치(110)는 API 테스트를 위한 연산을 수행하는 하나의 서버일 수 있으나, 실시 예에 따라서는 복수의 서버로 구성될 수도 있으며, 하나 이상의 서버와 외부의 클라우드 서버가 전자적으로 통신 가능하도록 연결된 형태로 구성될 수도 있다.
한편, 백엔드 서버(120)는 사용자가 사용자 단말(120)에 표시되는, 전자 장치(110)가 제공하는 인터페이스를 통해 입력을 전송하면, 전자 장치(110)로부터 API와 관련된 요청을 수신하고 이를 처리하여 응답을 전자 장치(110)로 전송하는 장치를 통칭하는 것으로, 단일한 서버일 수도 있으나, 실시 예에 따라서는 복수의 서버를 포함할 수도 있다(예컨대, 요청된 테스트 케이스들을 분산 처리하는 서버나, 분배된 테스트 케이스를 직접적으로 실행하는 서버 등).
이상과 관련하여, 이하 도면들을 통해 보다 상세히 설명하기로 한다. 도 2 내지 8에 도시된 방법은 예를 들어, 상술한 전자 장치(110)에 의해 수행될 수 있다.
도 2는 일 실시 예에 따른 API 테스트 방법을 설명하기 위한 흐름도이다.
단계 S210에서, 전자 장치(110)는 1)Application Programming Interface(API) 요청 정보 및 2)API 응답에 대한 검증 정보를 포함하는 테스트 케이스 설정 정보를 획득한다.
일 실시 예에 따르면, 테스트 케이스 설정 정보는, 서비스, 서비스 내 도메인(domain) 및 도메인 내 호출이 필요한 API를 포함하는 계층 구조에 기반하여 전자 장치(110)가 탐색 가능하도록 분류 및 저장될 수 있다. 본 개시에 있어서, '서비스'-'서비스 내 도메인'-'도메인 내 호출이 필요한 API'는 계층 구조의 일 예시로서, 예컨대 '서비스'는 애플리케이션으로 구분되는 상위 계층을, '서비스 내 도메인'은 애플리케이션 내에서 세부 서비스가 제공되는 페이지로 구분되는 중위 계층을, '도메인 내 호출이 필요한 API'는 각 페이지 내에서 제공되는 기능 별로 구분되는 하위 계층을 예시할 수 있다. 테스트 케이스 설정 정보가 계층 구조로 분류 및 저장됨으로써, 전자 장치(110)는 계층 구조를 갖는 디렉토리 인터페이스를 사용자 단말(130)에 제공할 수 있고, 사용자는 해당 인터페이스를 통해 테스트 슈트(Test Suite), 테스트 케이스(Test case), 테스트 스텝(Test step) 등을 세부적으로 선택하거나 설정할 수 있다.
일 실시 예에 따르면, 테스트 케이스 설정 정보는 사용자로부터 입력된 테스트 코드 및 특정 단말 식별 정보에 대응하는 단말의 트래픽 이력에 대응하는 모의 데이터 중 적어도 일부에 기반하여 생성될 수 있다. 예컨대, 사용자가 사용자 단말(120)을 통해 테스트 코드를 수동으로(manually) 입력하면, 전자 장치(110)는 해당 테스트 코드를 테스트 케이스 설정 정보의 일부로서 테스트 케이스 생성 시 로드할 수 있다. 이 경우, 사용자 단말(120) 관점에서, 테스트 케이스 생성 태스크와 테스트 코드의 수동 입력 태스크는 서로 다른 페이지에서 수행될 수 있다. 한편 다른 예로서, 전자 장치(110)는 사용자 단말(120)이 지정한 식별 정보(PCID)에 대응하는 단말 A의 트래픽 이력에 기반하여 모의 데이터(mock data)를 추출하고, 해당 모의 데이터를 테스트 케이스의 요청(request) 또는 응답(response)에 반영함으로써 테스트 케이스 설정 정보를 생성할 수 있다.
일 실시 예에 따르면, 테스트 케이스 설정 정보는, 테스트 케이스의 실행과 관련된 지역 정보, 언어 정보, 애플리케이션 운영체제 정보, 애플리케이션 버전 정보, 테스트 환경 정보, AB 테스트를 위한 그룹 설정 정보 중 적어도 일부를 포함할 수 있다. 구체적으로, 테스트 케이스 설정 정보는 테스트 케이스가 어느 지역에서 실행될 것인지(지역 정보), 어떠한 언어로 실행될 것인지(언어 정보), 어떠한 운영체제 하에서 실행될 것인지(애플리케이션 운영체제 정보), 애플리케이션의 어느 버전에 기반하여 실행될 것인지(애플리케이션 버전 정보), 테스트 실행을 지원하는 하드웨어/소프트웨어/네트워크 등의 구성은 어떻게 설정할 것인지(테스트 환경 정보), AB 테스트의 대조군과 실험군을 어떻게 설정할 것인지(AB 테스트를 위한 그룹 설정 정보) 등에 관한 정보를 포함할 수 있다.
일 실시 예에 따르면, API 요청 정보는, 제1 요청의 전송 방식에 대한 정보, 제1 요청이 전송될 시에 적용될, 모의 데이터(mock data) 이용 정보, 테스트 파라미터 정보, 테스트 헤더 정보, 테스트 바디 정보 중 적어도 일부를 포함할 수 있다.
구체적으로, 제1 요청의 전송 방식에 대한 정보는 전자 장치(110)가 백엔드 서버(120)로 HTTP 방식에 기반하여 제1 요청을 전송할 때, GET 방식과 POST 방식 중 어느 방식에 기반하여 전송할지 결정하는 정보를 의미한다. GET 방식을 선택하면 URL에 변수가 노출되고, 데이터가 헤더에 포함되며, 상대적으로 보안에 취약한 대신 캐싱이 가능한 반면, POST 방식을 선택하면 URL에 변수가 노출되지 않고, 데이터가 바디에 포함되며, 상대적으로 보안이 강한 대신 캐싱할 수 없다.
또한 구체적으로, 모의 데이터 이용 정보는, 테스트 케이스가 실행되는 시점의 테스트 환경의 변화와 무관하게 유지되어야 하는 응답(response)에 관련된 데이터로 모의 데이터를 이용할 것인지 여부에 대한 정보를 포함할 수 있다. 더 나아가, 모의 데이터 이용 정보에는 모든 데이터를 전부 모의(mocking)할 것인지, 요청에 포함되는 데이터만 모의할 것인지, 헤더에 포함되는 데이터만 모의할 것인지 등에 대한 정보를 더 포함할 수도 있다. 모의 데이터 이용 정보 설정하여 모의 데이터를 이용하는 경우, 프론트엔드에서 백엔드의 데이터에 의존하지 않고 일부 모의 데이터를 이용하여 의도한 대로 유저 인터페이스(User Interface)가 구현되는지 확인, 검증하기 용이하다.
또한 구체적으로, 테스트 파라미터 정보는 제1 요청과 관련된 파라미터 종류 및 파라미터 값에 대한 정보를 포함할 수 있고, 테스트 헤더 정보는 테스트 케이스의 실행을 위한 보충 데이터를 포함할 수 있으며, 테스트 바디 정보는 제1 요청의 내용을 포함할 수 있다.
일 실시 예에 따르면, 검증 정보는, 1)테스트 케이스의 검증 대상 필드 정보, 2)검증 대상 필드에 대응하는 예상 필드 값 정보 및 3) 검증 대상 필드에 대응하는 실제 값 정보와 예상 필드 값 정보 사이의 관계를 정의하는 함수 정보를 포함할 수 있다. 예상 필드 값 정보는 테스트 케이스의 실행 시 검증 대상 필드의 기대 값을 의미하며, 함수 정보는 검증 대상 필드에 대응하는 실제 값과 기대 값의 관계가 동일한지(equal to), 실제 값이 기대 값보다 더 크거나 작은지, 실제 값이 기대 값과 다른지 등을 정의하는 함수의 종류를 의미할 수 있다.
단계 S220에서, 전자 장치(110)는 테스트 케이스 설정 정보 중 적어도 일부를 기반으로 백엔드 서버(120)에 테스트 케이스 실행을 위한 제1 요청을 전송한다.
일 실시 예에 따르면, 전자 장치(110)는 사용자 단말(130)로부터 테스트 케이스 실행 요청을 수신하는 경우에, 백엔드 서버(120)에 제1 요청을 전송할 수 있다. 이와 관련하여, 사용자 단말(130)의 테스트 케이스 실행 요청은 사용자 단말(130)을 통해 출력되는 페이지 상의 인터페이스 조작을 통해 이루어질 수 있다.
단계 S230에서, 전자 장치(110)는 제1 요청에 대응하는 제1 응답 및 검증 정보를 기반으로 생성된 제1 결과 정보를 제공한다. 구체적으로, 제1 응답은 제1 요청에 따라 실행된 테스트 케이스의 코드 정보를 포함하며, 제1 결과 정보는 제1 응답 중 검증 대상 필드의 실제 값이 기대 값과 함수 정보와의 관계를 만족하는지 여부에 대한 정보를 포함할 수 있다.
일 실시 예에 따르면, 전자 장치(110)는 제1 응답과 제1 결과 정보를 사용자 단말(130)에 출력되는 페이지 상에서 탭으로 구분하여 제공할 수 있다.
일 실시 예에 따르면, 전자 장치(110)가 제공하는 제1 결과 정보에는 대상 단말(콘솔)에서 실행된 테스트 케이스의 로그(log) 정보가 포함될 수도 있다.
도 3 내지 8은 추가적인 실시 예에 따른 API 테스트 방법을 설명하기 위한 흐름도이다.
먼저, 도 3은 테스트 케이스 설정 정보가 변경되는 실시 예에 관한 흐름도로서, 전자 장치(110)는 API 요청 정보 및 API 응답에 대한 검증 정보를 포함하는 테스트 케이스 설정 정보를 획득한 이후(단계 S310), 획득된 테스트 케이스 설정 정보 중 적어도 일부에 대한 변경 요청을 수신하면(단계 S320), 변경 요청된 테스트 케이스 설정 정보를 변경할 수 있다(단계 S330). 이후, 전자 장치(110)는 테스트 케이스 설정 정보 중 적어도 일부를 기반으로 백엔드 서버(120)에 테스트 케이스 실행을 위한 제1 요청을 전송하고(단계 S340), 제1 요청에 대응하는 제1 응답 및 검증 정보를 기반으로 생성된 제1 결과 정보를 제공할 수 있다(단계 S350).
자세하게는, 전자 장치(110)가 사용자 단말(130)로부터 테스트 케이스 설정 정보 중 적어도 일부에 대한 변경 요청을 수신하면, 변경 요청된 테스트 케이스 설정 정보를 요청 사항에 맞추어 갱신하고 저장할 수 있다(테스트 케이스 설정 정보는 전자 장치(110) 내 저장 공간에 저장될 수 있으나, 이에 한정되는 것은 아니며 백엔드 서버(120)나 별도의 스토리지 또는 캐시(cache)에 저장될 수도 있다). 이후, 전자 장치(110)는 갱신된 테스트 케이스 설정 정보 중 적어도 일부에 기반하여 제1 요청을 전송하고 테스트 케이스가 실행되도록 함으로써, 사용자가 변경을 원하는 사항을 테스트 케이스 실행 전에 신속히 반영할 수 있다.
한편, 도 4는 누적 생성된 결과를 시각적 형태로 제공하는 실시 예에 관한 흐름도로서, 전자 장치(110)는 API 요청 정보 및 API 응답에 대한 검증 정보를 포함하는 테스트 케이스 설정 정보를 획득하고(단계 S410), 테스트 케이스 설정 정보 중 적어도 일부를 기반으로 백엔드 서버(120)에 테스트 케이스 실행을 위한 제1 요청을 전송하고(단계 S420), 제1 요청에 대응하는 제1 응답 및 검증 정보를 기반으로 생성된 제1 결과 정보를 제공할 수 있다(단계 S430). 이어서, 복수 차례에 걸쳐 테스트 케이스가 실행된 이후, 전자 장치(110)는 개별 API에 대해 누적 생성된 테스트 케이스에 의한 케이스 커버리지 및 코드 커버리지 중 적어도 일부에 대한 시각적 정보를 출력할 수 있다(단계 S440). 전자 장치(110)는 API 별로 테스트 케이스에 의한 각 커버리지 정도를 시각적으로 사용자 단말(130)에 제공함으로써, 사용자가 현재까지의 테스트 상황을 직관적으로 파악하도록 도울 수 있다.
본 개시에 있어서, '케이스 커버리지'는 생성된 모든 테스트 케이스 중 자동화된 테스트 케이스의 비율을 의미하며, '코드 커버리지'는 테스트 대상의 전체 범위에서 코드에 의해 테스트가 수행된 비율을 의미한다. 상기 단계 S440과 관련해서는, 이하의 도 9a 및 9b를 이용하여 보다 상세히 설명하기로 한다.
한편, 도 5는 테스트 케이스를 테스트 플랜에 포함될 후보로 추가하는 실시 예에 관한 흐름도로서, 전자 장치(110)는 API 요청 정보 및 API 응답에 대한 검증 정보를 포함하는 테스트 케이스 설정 정보를 획득하고(단계 S510), 테스트 케이스 설정 정보 중 적어도 일부를 기반으로 백엔드 서버(120)에 테스트 케이스 실행을 위한 제1 요청을 전송하고(단계 S520), 제1 요청에 대응하는 제1 응답 및 검증 정보를 기반으로 생성된 제1 결과 정보를 제공할 수 있다(단계 S530). 이어서, 전자 장치(110)는 생성된 테스트 케이스 중 디버깅이 완료되어 테스트 자동화 대상으로 마킹된 테스트 케이스를 테스트 플랜에 포함될 수 있는 후보 리스트에 추가할 수 있다(단계 S540).
구체적으로, 단계 S540과 관련하여 전자 장치(110)는 사용자 단말(130)에 의해 자동화 대상으로 선택된 테스트 케이스를 마킹하고, 테스트 케이스보다 상위 계층 구조인 테스트 플랜에 포함될 수 있는 후보 리스트에 추가하여 해당 후보 리스트를 사용자 단말(130)에 제공할 수 있다. 만일 사용자가 사용자 단말(130)을 통해 후보 리스트 내 일 테스트 케이스를 선택하는 경우, 전자 장치(110)는 해당 테스트 케이스를 해당 테스트 케이스의 상위 계층 구조에 해당하는 테스트 플랜에 추가하는 형식으로 테스트 플랜을 갱신할 수 있다. 또한, 전자 장치(110)가 자동화 대상으로 선택된 테스트 케이스를 마킹하는 방식은 다양할 수 있으며, 전자 장치(110)는 사용자 단말(130)에 표시되는 페이지 상에서 마킹된 테스트 케이스에 그래픽 효과가 적용되거나, 마킹된 테스트 케이스 주위에 그래픽 오브젝트가 표시되도록 할 수 있다.
한편, 도 6은 테스트 플랜을 실행하는 실시 예에 관한 흐름도로서, 전자 장치(110)는 API 요청 정보 및 API 응답에 대한 검증 정보를 포함하는 테스트 케이스 설정 정보를 획득하고(단계 S610), 테스트 케이스 설정 정보 중 적어도 일부를 기반으로 백엔드 서버(120)에 테스트 케이스 실행을 위한 제1 요청을 전송하고(단계 S620), 제1 요청에 대응하는 제1 응답 및 검증 정보를 기반으로 생성된 제1 결과 정보를 제공하고(단계 S630), 생성된 테스트 케이스 중 디버깅이 완료되어 테스트 자동화 대상으로 마킹된 테스트 케이스를 테스트 플랜에 포함될 수 있는 후보 리스트에 추가할 수 있다(단계 S640). 이어서, 전자 장치(110)는 후보 리스트에서 선택된 하나 이상의 테스트 케이스에 대한 선택 정보를 포함하는 테스트 플랜 설정 정보를 획득하고(단계 S650), 테스트 플랜 설정 정보 중 적어도 일부를 기반으로 백엔드 서버(120)에 테스트 플랜 실행을 위한 제2 요청을 전송하고(단계 S660), 제2 요청에 대응하는 제2 응답을 기반으로 생성된 제2 결과 정보를 제공할 수 있다(단계 S670).
일 실시 예에 따르면, 테스트 플랜 설정 정보는 테스트 플랜의 실행과 관련된 1)지역 정보, 2)언어 정보, 3)애플리케이션 운영체제 정보, 4)애플리케이션 버전 정보, 5)테스트 환경 정보, 6)AB 테스트를 위한 그룹 설정 정보, 7)테스트 플랜이 실행될 스케줄 정보 및 8)제2 결과 정보 중 적어도 일부가 전송될 협업 툴 채널 정보 중 적어도 일부를 더 포함할 수 있다.
구체적으로, 테스트 플랜 설정 정보는 테스트 플랜이 어느 지역에서 실행될 것인지(지역 정보), 어떠한 언어로 실행될 것인지(언어 정보), 어떠한 운영체제 하에서 실행될 것인지(애플리케이션 운영체제 정보), 애플리케이션의 어느 버전에 기반하여 실행될 것인지(애플리케이션 버전 정보), 테스트 실행을 지원하는 하드웨어/소프트웨어/네트워크 등의 구성은 어떻게 설정할 것인지(테스트 환경 정보), AB 테스트의 대조군과 실험군을 어떻게 설정할 것인지(AB 테스트를 위한 그룹 설정 정보), 테스트 플랜이 실행될 특정 시점 또는 주기(스케줄 정보), 특정 협업 툴 내 어떠한 채널에 제2 결과 정보의 적어도 일부를 전달할 것인지(협업 툴 채널 정보) 등에 관한 정보를 포함할 수 있다.
일 실시 예에 따르면, 제2 결과 정보는 테스트 플랜의 실행 로그가 기록된 HTML 형식의 리포트를 포함할 수 있다. 예컨대, 제2 결과 정보는 테스트 플랜의 식별 번호 별로 구분된 테이블 형태로 제공될 수 있고, 사용자 단말(130)에 의해 어느 한 테스트 플랜의 식별 번호가 선택되면, 전자 장치(110)는 선택된 식별 번호에 대응하는 HTML 형식의 리포트가 새로운 페이지를 통해 제공되도록 할 수 있다.
한편, 도 7은 테스트 플랜의 실행에 따른 결과를 반영하는 실시 예에 관한 흐름도로서, 전자 장치(110)는 API 요청 정보 및 API 응답에 대한 검증 정보를 포함하는 테스트 케이스 설정 정보를 획득하고(단계 S710), 테스트 케이스 설정 정보 중 적어도 일부를 기반으로 백엔드 서버(120)에 테스트 케이스 실행을 위한 제1 요청을 전송하고(단계 S720), 제1 요청에 대응하는 제1 응답 및 검증 정보를 기반으로 생성된 제1 결과 정보를 제공하고(단계 S730), 생성된 테스트 케이스 중 디버깅이 완료되어 테스트 자동화 대상으로 마킹된 테스트 케이스를 테스트 플랜에 포함될 수 있는 후보 리스트에 추가하고(단계 S740), 후보 리스트에서 선택된 하나 이상의 테스트 케이스에 대한 선택 정보를 포함하는 테스트 플랜 설정 정보를 획득하고(단계 S750), 테스트 플랜 설정 정보 중 적어도 일부를 기반으로 백엔드 서버(120)에 테스트 플랜 실행을 위한 제2 요청을 전송하고(단계 S760), 제2 요청에 대응하는 제2 응답을 기반으로 생성된 제2 결과 정보를 제공할 수 있다(단계 S770). 이어서, 전자 장치(110)는 제2 결과 정보 중 테스트 패스 비율이 설정된 기준 비율 이상인지 판단하여(단계 S780), 그러한 경우 테스트 플랜이 실행됨에 따른 변경 사항 중 적어도 일부를 테스트 플랜이 실행된 브랜치(branch)와는 별도의 브랜치에 병합하고(단계 S790), 테스트 패스 비율이 설정된 기준 비율 미만인 경우, 테스트 플랜이 실행됨에 따른 변경 사항을 상기 별도의 브랜치에 병합하지 않을 수 있다.
일 실시 예에 따르면, 전자 장치(110)는 테스트 플랜이 실행됨에 따라 생성된 제2 결과 정보 상의 검증 대상 필드의 실제 값과 기대 값(예상 필드 값), 함수 정보의 관계가 만족되는 경우에 테스트가 패스된 것으로 판단하여, 이러한 테스트 패스 비율이 기준 비율(예컨대, 98%) 이상이면 해당 테스트 플랜의 변경 사항을 마스터 브랜치에 병합함으로써 실제 서비스에 반영할 수 있다.
한편, 도 8은 테스트 플랜의 실행에 따라 발생한 에러를 처리하는 실시 예에 관한 것으로서, 전자 장치(110)는 API 요청 정보 및 API 응답에 대한 검증 정보를 포함하는 테스트 케이스 설정 정보를 획득하고(단계 S810), 테스트 케이스 설정 정보 중 적어도 일부를 기반으로 백엔드 서버(120)에 테스트 케이스 실행을 위한 제1 요청을 전송하고(단계 S820), 제1 요청에 대응하는 제1 응답 및 검증 정보를 기반으로 생성된 제1 결과 정보를 제공하고(단계 S830), 생성된 테스트 케이스 중 디버깅이 완료되어 테스트 자동화 대상으로 마킹된 테스트 케이스를 테스트 플랜에 포함될 수 있는 후보 리스트에 추가하고(단계 S840), 후보 리스트에서 선택된 하나 이상의 테스트 케이스에 대한 선택 정보를 포함하는 테스트 플랜 설정 정보를 획득하고(단계 S850), 테스트 플랜 설정 정보 중 적어도 일부를 기반으로 백엔드 서버(120)에 테스트 플랜 실행을 위한 제2 요청을 전송하고(단계 S860), 제2 요청에 대응하는 제2 응답을 기반으로 생성된 제2 결과 정보를 제공할 수 있다(단계 S870). 이어서, 전자 장치(110)는 테스트 플랜이 마스터 브랜치와 동일한 테스트 환경에서 실행된 경우, 제2 결과 정보에 따라 에러가 발생했는지 확인하고(단계 S880), 에러가 발생한 경우, 에러를 설정된 개발자 단말(140)에 보고할 수 있다(단계 S890).
마스터 브랜치에서 API가 호출되는 환경과 테스트 플랜이 실행된 테스트 환경이 동일한 경우, 개발자가 해당 테스트 플랜의 실행에 따라 발생하는 에러를 파악할 중요성이 있다. 때문에, 전자 장치(110)는 마스터 브랜치에서 API가 호출되는 환경과 동일한 테스트 환경에서 테스트 플랜이 실행됨에 따라 발생한 에러를 개발자 단말(140)에 보고할 수 있다. 실시 예에 따르면, 전자 장치(110)는 개발자 단말(140)에 에러가 발생했음을 알리는 푸시 알림, 진동 알림, 협업 툴 알림, 음성 메시지, 텍스트 메시지, 메일 중 적어도 일부를 전송할 수 있다.
도 9a 및 9b는 일 실시 예에 따라 시각적 정보가 출력된 메인 페이지의 예시도이다. 도 9a 및 9b에 도시된 것은 시각적 정보가 표시된 메인 페이지 상의 일부 그래프이며, 메인 페이지에는 도 9a 및 9b의 그래프 이외에도 다양한 그래프, 테이블, 인터페이스 등이 표시될 수 있다.
도 9a는 케이스 커버리지를 나타낸 시각적 정보(910)의 예시로, 서비스 내 도메인 별로 호출이 필요한 API가 세로축 기준으로 표시되어 있다. 가로축은 각 API를 호출하는 테스트 케이스의 개수를 나타낸 것이고, 우측으로 기울어진 빗금 영역은 자동화된 테스트 케이스를, 양쪽 빗금 영역은 자동화가 되지 않은 테스트 케이스를, 좌측으로 기울어진 빗금 영역은 아직 자동화 여부가 정해지지 않은 테스트 케이스를 나타낸다. Cart API를 호출하는 테스트 케이스의 경우, 87.97%의 케이스 커버리지를 나타내어, 87.97%의 테스트 케이스가 자동화 되었음을 알 수 있다. 한편, review API를 호출하는 테스트 케이스의 경우, 50.00%의 케이스 커버리지를 나타내어, 전체 중 절반의 테스트 케이스가 자동화 되었음을 알 수 있다. 사용자는 케이스 커버리지를 시각적으로 확인하여, 어떠한 API에 대해 테스트 시 자동화가 상대적으로 많이 혹은 적게 이루어졌는지 신속히 파악할 수 있다.
한편, 도 9b는 코드 커버리지를 나타낸 시각적 정보의 예시로, 호출되는 세 종류의 API(active_line_cov cart_front_api, branch_coverage cart_front_api, line_coverage cart_front_api) 각각에 해당하는 테스트 대상의 전체 범위에서 코드에 의해 테스트가 수행된 비율이 도시되어 있다. 가로축은 테스트가 실행된 하루 단위의 시점을 나타낸다. 예컨대, active_line_cov cart_front_api의 경우 총 5번 실행된 테스트에서 최고 97.4%, 최저 92.8%, 평균 95.1%의 코드 커버리지를 나타냈고, branch_coverage cart_front_api의 경우 총 5번 실행된 테스트에서 최고 23.7%, 최저 22.6%, 평균 23.1%의 코드 커버리지를 나타내었다. 사용자는 코드 커버리지를 시각적으로 확인하여, 어떠한 API에 대해 전체 테스트 범위 대비 코드가 많이 실행되었는지 신속히 파악할 수 있다.
도 10은 일 실시 예에 따라 테스트 케이스를 수동으로 작성 가능한 인터페이스를 제공하는 제1 테스트 케이스 페이지의 예시도이며, 도 11a 내지 11e는 일 실시 예에 따라 테스트 케이스를 자동으로 생성 및 실행 가능한 인터페이스를 제공하는 제2 테스트 케이스 페이지의 예시도이다.
도 10에 도시된 대로, 사용자가 사용자 단말(130)을 통해 제1 테스트 케이스 페이지에서 C161178의 식별 번호에 대응하는 'test_rocket install_delivery info_Sansung'이라는 명칭의 테스트 케이스를 수동으로 작성하였고, 해당 테스트 케이스의 테스트 케이스 설정 정보에 따른 테스트 내용은 1010에 기재된 바와 같다. 구체적으로, 1010에 기재된 테스트 내용에 따르면, 사용자가 SDP(Single Detail Page)에 진입하면, 예상되는 결과(출력되어야 하는 테스트 응답)로 1)로켓설치 서비스를 나타내는 배지(badge)가 정상적으로 표시되어야 하고, 2)배송 회사가 정상적으로 표시되어야 하고, 3)제품 배송일(PDD; Product Delivery Date)이 정상적으로 표시되어야 하고, 4)배송비(Shipping fee)가 정상적으로 표시되어야 함이 나타나 있다.
도 11a에 도시된 제2 테스트 케이스 페이지에서는, 도 10에 도시된 바와 같이 수동으로 작성된 테스트 케이스들을 포함하여 복수의 테스트 케이스를 선택적으로 실행할 수 있으며, 현재 생성된 테스트 케이스는 제1 섹션(1110)에 나타난 바와 같다. 예시적으로, 'ATF_Shipping Fee'라는 명칭의 테스트 슈트의 하위 항목으로 복수의 테스트 케이스가 존재하며, 현재 '75789_test_rocket delivery Member'라는 명칭의 테스트 케이스의 하위 항목인 'GET/sdp/v2/platform/products/{{productID}}'라는 명칭의 테스트 스텝이 선택되어 있다.
테스트 케이스 설정 정보와 관련된 제2 섹션(1120)을 보면, 상단에는 API 요청 정보로서 요청의 전송 방식을 선택할 수 있는 인터페이스가 제공되고, 하단에는 모의 데이터 이용 정보를 확인 및 변경할 수 있는 탭(Step Mock), 테스트 파라미터 정보를 확인 및 변경할 수 있는 탭(Params), 테스트 헤더 정보를 확인 및 변경할 수 있는 탭(Headers), 테스트 바디 정보를 확인 및 변경할 수 있는 탭(Body), 검증 정보를 확인 및 변경할 수 있는 탭(Assertion), 다른 테스트 케이스 또는 테스트 스텝으로 추출할 데이터를 확인 및 변경할 수 있는 탭(Extract)이 제공되어 있다. 이처럼, 일 실시 예에 따르면, 전자 장치(110)는 각 API 요청 정보 또는 검증 정보가 탭으로 구분되어 표시되는 인터페이스를 사용자 단말(130)에 제공할 수 있다.
한편 테스트 케이스 설정 정보와 관련된 제3 섹션(1130)에는 현재 선택된 탭(Step Mock)에 해당하는 모의 데이터 이용 정보가 표시되어 있다. 이에 따르면, 해당 테스트 스텝을 포함하는 테스트 케이스의 실행 시 배송 타입은 '로켓 배송'으로 유지될 것임을 파악할 수 있다. 다른 예로서 도 11b의 제3 섹션(1130)을 살펴보면, 해당 테스트 스텝의 테스트 패스 여부를 결정하기 위한 검증 조건이 도시되어 있다. 테스트 케이스의 검증 대상 필드 정보(expression), 함수 정보(function), 예상 필드 값 정보(expected, 기대 값)는 사용자가 설정할 수 있다.
한편 제4 섹션(1140)에는 테스트 케이스의 실행에 따른 제1 응답 또는 제1 결과 정보가 표시되며, 예시적으로 제1 응답과 제1 결과 정보는 탭으로 구분되어 표시될 수 있다. 도 11c의 제4 섹션(1140)에 도시된 대로, 제1 응답은 Response 탭에서 표시될 수 있고, 도 11d의 제4 섹션(1140)에 도시된 대로, 제1 결과 정보는 Assertion Result 탭에서 표시될 수 있다. 도 11d의 제4 섹션(1140)에는 테스트 케이스 실행에 따른 검증 대상 필드의 실제 값(actual)이 표시되며, 이 값이 제3 섹션(1130)의 기대 값(expected)과 동일하므로 전자 장치(110)는 해당 테스트 케이스를 패스한 것으로 판단할 수 있다. 이처럼, 일 실시 예에 따르면, 전자 장치(110)는 API 요청 정보 또는 검증 정보가 표시되는 인터페이스와 서로 다른 인터페이스 상에 제1 응답 또는 제1 결과 정보가 표시되는 페이지를 사용자 단말(130)에 제공할 수 있다. 즉, 사용자는 선택된 테스트 케이스(또는 테스트 슈트나 테스트 스텝)를 실행하기 위한 제1 요청을 전송하도록 전자 장치(110)에 요청하고(Send 버튼을 선택함으로써), 제1 응답 및 제1 결과 정보를 즉각적으로 동일한 페이지에서 제공받을 수 있다. 다만, 상술한 인터페이스의 표시 위치, 배치 등은 실시 예에 따라 다양하게 설정될 수 있다.
한편, 일 실시 예에 따르면, 전자 장치(110)는 콘솔에서의 테스트 실행에 따른 로그 정보를 제공하는 인터페이스나 테스트 케이스 설정 정보를 변경할 수 있는 인터페이스도 사용자 단말(130)에 의한 제2 테스트 케이스 페이지 상의 인터페이스 조작에 따라 사용자 단말(130)에 제공될 수 있다. 예컨대, 도 11a 내지 11d에 도시된 대로, 콘솔에서의 테스트 실행에 따른 로그 정보는 제4 섹션(1140) 내 console log 버튼을 선택 시 표시될 수 있고, 도 11e에 도시된 바와 같이 테스트 케이스 설정 정보를 변경할 수 있는 윈도우는 Config 버튼 선택 시 표시될 수 있다.
테스트 케이스 설정 정보를 변경할 수 있는 윈도우의 구성을 보다 자세히 살펴보면, 테스트 케이스의 실행과 관련된 지역 정보는 'Region'에 해당하는 드롭다운 리스트로, 언어 정보는 'Language'에 해당하는 드롭다운 리스트로, 애플리케이션 운영체제 정보는 'Android'에 해당하는 드롭다운 리스트로, 애플리케이션 버전 정보는 'App Version'에 해당하는 드롭다운 리스트로, 테스트 환경 정보는 'Test Env'에 해당하는 드롭다운 리스트로, AB 테스트를 위한 그룹 설정 정보는 'Test AB'에 해당하는 텍스트 인풋 박스를 통해 변경할 수 있다. 또한, 상단의 'Diff Run'에 해당하는 온-오프 컨트롤은 테스트 케이스의 패스 여부를 결정하기 위해 검증 조건에 추가로 포함될 수 있는 "Diff rule"을 활성화할 것인지 결정하는 인터페이스로서, 일 실시 예에 따르면, 전자 장치(110)는 "Diff rule"이 활성화 상태인 경우 사전에 정의된 기준 환경과 테스트 케이스가 실행되는 시점의 테스트 환경에서 각각 테스트 케이스가 실행될 시, 사용자 단말(130)에 동일한 출력이 제공되는지 여부를 판단하고, 동일한 출력이 제공되는 경우에 테스트 케이스 패스를 위한 일 조건인 "Diff rule"을 통과한 것으로 판단할 수 있다.
한편, 도 12a 내지 12g는 일 실시 예에 따라 테스트 플랜을 자동으로 생성 및 실행 가능한 인터페이스를 제공하는 테스트 플랜 페이지의 예시도이다.
도 12a를 참조하면, 테스트 플랜 페이지의 제1 섹션(1210)에는 제2 테스트 케이스 페이지의 제1 섹션(1110)과 유사하게, 하나 이상의 테스트 케이스를 포함하는 테스트 플랜의 리스트가 디렉토리 인터페이스로 제공된다. 도 12b를 참조하면, 제1 섹션(1210)의 테스트 플랜 중 'Regression-sdp_front_api'라는 명칭의 테스트 플랜이 실행된 경우(예컨대, 사용자가 Run 버튼을 선택함으로써), 해당 테스트 플랜을 구성하는 테스트 케이스들의 리스트가 제2 섹션(1220)에 표시될 수 있다. 이처럼, 일 실시 예에 따르면, 테스트 플랜의 리스트 중 특정 테스트 플랜이 실행되는 경우, 실행된 테스트 플랜에 포함되는 테스트 케이스의 리스트가 동일 페이지의 다른 섹션에 표시될 수 있다. 또한, 테스트 케이스의 리스트는 각 테스트 케이스에 식별 번호(Report Id)가 부여된 테이블 형식으로 제공될 수 있으며, 각 테스트 케이스의 패스 여부(status)가 함께 제공될 수 있다.
일 실시 예에 따르면, 사용자 단말(130)에 의해 각 테스트 케이스에 부여된 식별 번호가 선택되는 경우, 도 12c에 도시된 바와 같이 선택된 식별 번호에 대응하는 테스트 케이스의 실행 로그가 기록된 HTML 형식의 리포트가 제공될 수 있다. HTML 형식의 리포트에는 테스트 케이스의 실행 횟수, 실행 시간, 패스 여부, 테스트 내용, 테스트 시나리오 등이 선택적으로 표시될 수 있다.
도 12d 내지 12g는 테스트 플랜의 생성을 위해 테스트 플랜 페이지에서 제공되는 윈도우를 나타낸 것으로, 제3 섹션(1230)에는 현재 테스트 플랜의 생성 진행 단계가 표시되며, 제4 섹션(1240)에는 1 단계(테스트 플랜 명칭 지정 단계)의 태스크를 수행할 수 있는 텍스트 인풋 박스가 표시될 수 있다. 이어서, 제5 섹션(1250)에는 제2 단계(테스트 플랜에 포함될 테스트 케이스 선택 단계)의 태스크와 관련하여 테스트 플랜의 계층(case_level, suite_level, role_level)을 지정할 수 있는 인터페이스가 표시될 수 있으며, 제6 섹션(1260)에는 직접 테스트 케이스를 선택 가능한 디렉토리 인터페이스가 표시될 수 있다. 이어서, 제3 단계 및 제4 단계(테스트 플랜 설정 정보의 설정 단계)의 태스크와 관련하여, 제7 섹션(1270)에는 테스트 플랜이 실행될 스케줄 정보 및 제2 결과 정보 중 적어도 일부가 전송될 협업 툴 채널 정보를 설정할 수 있는 인터페이스가 표시될 수 있다.
도 13은 일 실시 예에 따라 API를 테스트하는 전자 장치를 설명하기 위한 블록도이다.
전자 장치(110)는 일 실시 예에 따라, 트랜시버(111), 프로세서(113) 및 메모리(115)를 포함할 수 있다. 일 실시 예에서, 전자 장치(110)는 트랜시버(111)를 통하여 데이터베이스(120)와 연결되고, 데이터를 교환할 수 있다.
프로세서(113)는 도 1 내지 도 12g를 통하여 전술한 적어도 하나의 방법을 수행할 수 있다. 메모리(115)는 도 1 내지 도 12g를 통하여 전술한 적어도 하나의 방법을 수행하기 위한 정보를 저장할 수 있다. 메모리(115)는 휘발성 메모리 또는 비휘발성 메모리일 수 있다.
프로세서(113)는 프로그램을 실행하고, 정보를 제공하기 위해 전자 장치(110)를 제어할 수 있다. 프로세서(113)에 의하여 실행되는 프로그램의 코드는 메모리(115)에 저장될 수 있다.
프로세서(113)는 트랜시버(111) 및 메모리(115)와 연결되어, API 요청 정보 및 API 응답에 대한 검증 정보를 포함하는 테스트 케이스에 대한 설정 정보를 획득하고, 테스트 케이스에 대한 설정 정보 중 적어도 일부를 기반으로 백엔드 서버에 테스트 케이스 실행을 위한 제1 요청을 전송하고, 제1 요청에 대응하는 제1 응답 및 검증 정보를 기반으로 생성된 결과 정보를 제공할 수 있다.
도 13에 도시된 전자 장치(110)는 본 실시 예와 관련된 구성요소들만이 도시되어 있다. 따라서, 도 13에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 더 포함될 수 있음을 본 실시 예와 관련된 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다.
전술한 실시 예들에 따른 장치는 프로세서, 프로그램 데이터를 저장하고 실행하는 메모리, 디스크 드라이브와 같은 영구 저장부(permanent storage), 외부 장치와 통신하는 통신 포트, 터치 패널, 키(key), 버튼 등과 같은 사용자 인터페이스 장치 등을 포함할 수 있다. 소프트웨어 모듈 또는 알고리즘으로 구현되는 방법들은 상기 프로세서상에서 실행 가능한 컴퓨터가 읽을 수 있는 코드들 또는 프로그램 명령들로서 컴퓨터가 읽을 수 있는 기록 매체 상에 저장될 수 있다. 여기서 컴퓨터가 읽을 수 있는 기록 매체로 마그네틱 저장 매체(예컨대, ROM(read-only memory), RAM(random-Access memory), 플로피 디스크, 하드 디스크 등) 및 광학적 판독 매체(예컨대, 시디롬(CD-ROM), 디브이디(DVD: Digital Versatile Disc)) 등이 있다. 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템들에 분산되어, 분산 방식으로 컴퓨터가 판독 가능한 코드가 저장되고 실행될 수 있다. 매체는 컴퓨터에 의해 판독가능하며, 메모리에 저장되고, 프로세서에서 실행될 수 있다.
본 실시 예는 기능적인 블록 구성들 및 다양한 처리 단계들로 나타내어질 수 있다. 이러한 기능 블록들은 특정 기능들을 실행하는 다양한 개수의 하드웨어 또는/및 소프트웨어 구성들로 구현될 수 있다. 예를 들어, 실시 예는 하나 이상의 마이크로프로세서들의 제어 또는 다른 제어 장치들에 의해서 다양한 기능들을 실행할 수 있는, 메모리, 프로세싱, 로직(logic), 룩 업 테이블(look-up table) 등과 같은 직접 회로 구성들을 채용할 수 있다. 구성 요소들이 소프트웨어 프로그래밍 또는 소프트웨어 요소들로 실행될 수 있는 것과 유사하게, 본 실시 예는 데이터 구조, 프로세스들, 루틴들 또는 다른 프로그래밍 구성들의 조합으로 구현되는 다양한 알고리즘을 포함하여, C, C++, 자바(Java), 어셈블러(assembler) 등과 같은 프로그래밍 또는 스크립팅 언어로 구현될 수 있다. 기능적인 측면들은 하나 이상의 프로세서들에서 실행되는 알고리즘으로 구현될 수 있다. 또한, 본 실시 예는 전자적인 환경 설정, 신호 처리, 메시지 처리, 및/또는 데이터 처리 등을 위하여 종래 기술을 채용할 수 있다. “매커니즘”, “요소”, “수단”, “구성”과 같은 용어는 넓게 사용될 수 있으며, 기계적이고 물리적인 구성들로서 한정되는 것은 아니다. 상기 용어는 프로세서 등과 연계하여 소프트웨어의 일련의 처리들(routines)의 의미를 포함할 수 있다.
전술한 실시 예들은 일 예시일 뿐 후술하는 청구항들의 범위 내에서 다른 실시 예들이 구현될 수 있다.

Claims (18)

  1. 전자 장치에서 API를 테스트하는 방법에 있어서,
    Application Programming Interface(API) 요청 정보 및 API 응답에 대한 검증 정보를 포함하는 테스트 케이스 설정 정보를 획득하는 단계;
    상기 테스트 케이스 설정 정보 중 적어도 일부를 기반으로 백엔드 서버에 테스트 케이스 실행을 위한 제1 요청을 전송하는 단계; 및
    상기 제1 요청에 대응하는 제1 응답 및 상기 검증 정보를 기반으로 생성된 제1 결과 정보를 제공하는 단계를 포함하는, API 테스트 방법.
  2. 제1항에 있어서,
    상기 테스트 케이스 설정 정보는,
    서비스, 서비스 내 도메인(domain) 및 도메인 내 호출이 필요한 API를 포함하는 계층 구조에 기반하여 탐색 가능하도록 분류 및 저장되는 것을 특징으로 하는, API 테스트 방법.
  3. 제1항에 있어서,
    상기 테스트 케이스 설정 정보는,
    사용자로부터 입력된 테스트 코드 및 특정 단말 식별 정보에 대응하는 단말의 트래픽 이력에 대응하는 모의 데이터 중 적어도 일부에 기반하여 생성되는 것을 특징으로 하는, API 테스트 방법.
  4. 제1항에 있어서,
    상기 테스트 케이스 설정 정보는,
    테스트 케이스의 실행과 관련된 지역 정보, 언어 정보, 애플리케이션 운영체제 정보, 애플리케이션 버전 정보, 테스트 환경 정보, AB 테스트를 위한 그룹 설정 정보 중 적어도 일부를 포함하는, API 테스트 방법.
  5. 제1항에 있어서,
    상기 API 요청 정보는,
    상기 제1 요청의 전송 방식에 대한 정보, 상기 제1 요청이 전송될 시에 적용될, 모의 데이터(mock data) 이용 정보, 테스트 파라미터 정보, 테스트 헤더 정보, 테스트 바디 정보 중 적어도 일부를 포함하는, API 테스트 방법.
  6. 제5항에 있어서,
    상기 모의 데이터 이용 정보는,
    상기 테스트 케이스가 실행되는 시점의 테스트 환경의 변화와 무관하게 유지되어야 하는 응답(response)에 관련된 데이터로 모의 데이터를 이용할 것인지 여부에 대한 정보를 포함하는, API 테스트 방법.
  7. 제1항에 있어서,
    상기 검증 정보는,
    테스트 케이스의 검증 대상 필드 정보, 검증 대상 필드에 대응하는 예상 필드 값 정보 및 검증 대상 필드에 대응하는 실제 값 정보와 상기 예상 필드 값 정보 사이의 관계를 정의하는 함수 정보를 포함하는, API 테스트 방법.
  8. 제1항에 있어서,
    상기 획득된 테스트 케이스 설정 정보 중 적어도 일부에 대한 변경 요청을 수신하는 단계; 및
    상기 변경 요청된 테스트 케이스 설정 정보를 변경하는 단계를 더 포함하는, API 테스트 방법.
  9. 제1항에 있어서,
    개별 API에 대해 누적 생성된 테스트 케이스에 의한 케이스 커버리지 및 코드 커버리지 중 적어도 일부에 대한 시각적 정보를 출력하는 단계를 더 포함하는, API 테스트 방법.
  10. 제1항에 있어서,
    생성된 테스트 케이스 중 디버깅이 완료되어 테스트 자동화 대상으로 마킹된 테스트 케이스를 테스트 플랜에 포함될 수 있는 후보 리스트에 추가하는 단계를 더 포함하는, API 테스트 방법.
  11. 제10항에 있어서,
    상기 후보 리스트에서 선택된 하나 이상의 테스트 케이스에 대한 선택 정보를 포함하는 테스트 플랜 설정 정보를 획득하는 단계;
    상기 테스트 플랜 설정 정보 중 적어도 일부를 기반으로 상기 백엔드 서버에 테스트 플랜 실행을 위한 제2 요청을 전송하는 단계; 및
    상기 제2 요청에 대응하는 제2 응답을 기반으로 생성된 제2 결과 정보를 제공하는 단계를 더 포함하는, API 테스트 방법.
  12. 제11항에 있어서,
    상기 테스트 플랜 설정 정보는,
    테스트 플랜의 실행과 관련된 지역 정보, 언어 정보, 애플리케이션 운영체제 정보, 애플리케이션 버전 정보, 테스트 환경 정보, AB 테스트를 위한 그룹 설정 정보, 테스트 플랜이 실행될 스케줄 정보 및 상기 제2 결과 정보 중 적어도 일부가 전송될 협업 툴 채널 정보 중 적어도 일부를 더 포함하는, API 테스트 방법.
  13. 제11항에 있어서,
    상기 제2 결과 정보는,
    테스트 플랜의 실행 로그가 기록된 HTML 형식의 리포트를 포함하는, API 테스트 방법.
  14. 제11항에 있어서,
    상기 제2 결과 정보에 기반하여 테스트 플랜이 실행됨에 따른 변경 사항 중 적어도 일부를 테스트 플랜이 실행된 브랜치(branch)와는 별도의 브랜치에 병합하는 단계를 더 포함하는, API 테스트 방법.
  15. 제14항에 있어서,
    상기 병합하는 단계는,
    상기 제2 결과 정보 중 테스트 패스 비율이 설정된 기준 비율 이상인 경우, 테스트 플랜이 실행됨에 따른 변경 사항 중 적어도 일부를 상기 별도의 브랜치에 병합하고,
    상기 제2 결과 정보 중 테스트 패스 비율이 설정된 기준 비율 미만인 경우, 테스트 플랜이 실행됨에 따른 변경 사항을 상기 별도의 브랜치에 병합하지 않는 것을 특징으로 하는, API 테스트 방법.
  16. 제11항에 있어서,
    테스트 플랜이 마스터 브랜치와 동일한 테스트 환경에서 실행된 경우, 상기 제2 결과 정보에 따라 에러가 발생했는지 확인하는 단계; 및
    상기 에러가 발생한 경우, 상기 에러를 설정된 개발자 단말에 보고하는 단계를 더 포함하는, API 테스트 방법.
  17. 제1항의 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 비일시적 기록 매체.
  18. API 테스트를 위한 전자 장치로서,
    트랜시버, 명령어를 저장하는 메모리 및 프로세서를 포함하고,
    상기 프로세서는, 상기 트랜시버 및 상기 메모리와 연결되어,
    Application Programming Interface(API) 요청 정보 및 API 응답에 대한 검증 정보를 포함하는 테스트 케이스에 대한 설정 정보를 획득하고,
    상기 테스트 케이스에 대한 설정 정보 중 적어도 일부를 기반으로 백엔드 서버에 테스트 케이스 실행을 위한 제1 요청을 전송하고,
    상기 제1 요청에 대응하는 제1 응답 및 상기 검증 정보를 기반으로 생성된 결과 정보를 제공하는, 전자 장치.
PCT/KR2022/013891 2022-09-02 2022-09-16 Api 테스트를 위한 전자 장치 및 그 방법 Ceased WO2024048833A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020220111219A KR102913255B1 (ko) 2022-09-02 2022-09-02 Api 테스트를 위한 전자 장치 및 그 방법
KR10-2022-0111219 2022-09-02

Publications (1)

Publication Number Publication Date
WO2024048833A1 true WO2024048833A1 (ko) 2024-03-07

Family

ID=90098124

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/013891 Ceased WO2024048833A1 (ko) 2022-09-02 2022-09-16 Api 테스트를 위한 전자 장치 및 그 방법

Country Status (3)

Country Link
KR (2) KR102913255B1 (ko)
TW (2) TW202536655A (ko)
WO (1) WO2024048833A1 (ko)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20260034889A (ko) * 2024-09-05 2026-03-12 쿠팡 주식회사 테스트의 수행을 설정하는 전자 장치의 동작 방법 및 이를 지원하는 전자 장치
WO2026063574A1 (ko) * 2024-09-19 2026-03-26 엘지전자 주식회사 테스트 장치 및 그의 동작 방법
WO2026063572A1 (ko) * 2024-09-19 2026-03-26 엘지전자 주식회사 테스트 장치 및 그의 동작 방법
KR20260042623A (ko) * 2024-09-23 2026-03-31 쿠팡 주식회사 대상 api를 검증하기 위한 장치, 방법 및 명령을 기록한 기록 매체

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100809291B1 (ko) * 2006-02-15 2008-03-04 삼성전자주식회사 임베디드 소프트웨어의 ａｐｉ 테스트 방법 및 장치
JP2016149043A (ja) * 2015-02-13 2016-08-18 日本電信電話株式会社 テスト装置、および、テスト方法
US20200233786A1 (en) * 2019-01-18 2020-07-23 Salesforce.com. inc. Default mock implementations at a server
US20210405976A1 (en) * 2020-06-26 2021-12-30 Xoriant Corporation System and method for automated software engineering
US11379348B2 (en) * 2019-06-21 2022-07-05 ProKarma Inc. System and method for performing automated API tests

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113722201A (zh) * 2020-05-25 2021-11-30 中移(苏州)软件技术有限公司 一种API一致性检测方法及PaaS平台
US10956244B1 (en) * 2020-08-26 2021-03-23 Coupang Corp. Systems and methods for automated application programming interface evaluation and migration

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100809291B1 (ko) * 2006-02-15 2008-03-04 삼성전자주식회사 임베디드 소프트웨어의 ａｐｉ 테스트 방법 및 장치
JP2016149043A (ja) * 2015-02-13 2016-08-18 日本電信電話株式会社 テスト装置、および、テスト方法
US20200233786A1 (en) * 2019-01-18 2020-07-23 Salesforce.com. inc. Default mock implementations at a server
US11379348B2 (en) * 2019-06-21 2022-07-05 ProKarma Inc. System and method for performing automated API tests
US20210405976A1 (en) * 2020-06-26 2021-12-30 Xoriant Corporation System and method for automated software engineering

Also Published As

Publication number Publication date
KR20260020438A (ko) 2026-02-11
TWI888901B (zh) 2025-07-01
TW202536655A (zh) 2025-09-16
KR20240032347A (ko) 2024-03-12
KR102913255B1 (ko) 2026-01-15
TW202427161A (zh) 2024-07-01

Similar Documents

Publication Publication Date Title
US11362912B2 (en) Support ticket platform for improving network infrastructures
KR950010833B1 (ko) 컴퓨터 시스템의 서비스 네트워크에 컴퓨터 시스템의 자동 등록 방법
KR20240032347A (ko) Api 테스트를 위한 전자 장치 및 그 방법
US11470183B1 (en) Deriving proxy stability without network inspection
CN110321154B (zh) 一种微服务的接口信息展示方法、装置及电子设备
CN110069413B (zh) 测试数据通信、测试方法、装置、设备及存储介质
CN112115337B (zh) 展示数据的方法及装置、电子设备、计算机可读存储介质
US10275338B2 (en) Automated system for fixing and debugging software deployed to customers
CN117667065B (zh) 一种低代码应用配置平台
KR101123361B1 (ko) 네트워크를 통한 학습 분산 환경 관리 서버, 방법 및 그방법을 실행하는 프로그램이 기록된 기록매체
KR100496871B1 (ko) 웹서비스 테스터 및 웹서비스 테스트 방법
CN112084115A (zh) 软件缺陷的流程化操作方法和装置
US8838532B2 (en) Collaborative self-service contact architecture with automatic blog content mapping capability
WO2024158120A1 (ko) 애플리케이션에 대한 테스트 설정 환경을 제공하는 전자 장치 및 그 방법
KR20250017280A (ko) 정보를 제공하는 방법 및 장치
CN110908763A (zh) 一种验收方法、装置、设备和存储介质
WO2024058299A1 (ko) Ab 테스트 코드 정보 관리를 위한 전자 장치 및 그 방법
Haripriya et al. A Survey on Opensource Solutions for API Monitoring in Microservice Architecture.
CN113342736B (zh) 一种存储路径管理方法、装置、介质和计算设备
WO2024117381A1 (ko) 전자 장치 및 그의 api 관리 방법
Vo ATAK integration in COREMOTE Tactics
CN122069163A (en) Management method and system of network equipment
TWI623891B (zh) Ｉｃｔ設備改接管控系統及其方法
WO2024147388A1 (ko) 동일한 네트워크에 연결된 장치의 식별
WO2025164966A1 (ko) 전자 장치 및 그의 데이터 분석 방법

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: 22957512

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22957512

Country of ref document: EP

Kind code of ref document: A1