WO2024052991A1 - テストスクリプト修正装置、テストスクリプト修正方法及びプログラム - Google Patents

テストスクリプト修正装置、テストスクリプト修正方法及びプログラム Download PDF

Info

Publication number
WO2024052991A1
WO2024052991A1 PCT/JP2022/033416 JP2022033416W WO2024052991A1 WO 2024052991 A1 WO2024052991 A1 WO 2024052991A1 JP 2022033416 W JP2022033416 W JP 2022033416W WO 2024052991 A1 WO2024052991 A1 WO 2024052991A1
Authority
WO
WIPO (PCT)
Prior art keywords
locator
locators
test script
screen element
value
Prior art date
Application number
PCT/JP2022/033416
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 PCT/JP2022/033416 priority Critical patent/WO2024052991A1/ja
Publication of WO2024052991A1 publication Critical patent/WO2024052991A1/ja

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

Definitions

  • the present invention relates to a test script modification device, a test script modification method, and a program.
  • test scripts tests are automated using locators to identify screen elements for operation of the test target.
  • locator is defined using attributes such as id and name of a screen element, and structural information such as XPath.
  • Non-patent Document 1 a screen element is correctly captured but the locator is partially broken, the broken locator can be automatically corrected using information on the correct screen element.
  • the present invention has been made in view of the above points, and an object of the present invention is to improve the efficiency of dealing with multiple locators.
  • the test script modification device uses a search instruction configured to capture a certain screen element using each of a plurality of locators specified in the source code of the test script regarding the screen of the application. and replacing the value of a first locator among the plurality of locators that could not capture the certain screen element with the value of an attribute corresponding to the type of the first locator in the certain screen element.
  • a locator modification unit configured to modify the source code so as to modify the source code.
  • FIG. 1 is a diagram showing an example of a hardware configuration of a test script correction device 10 according to an embodiment of the present invention.
  • 1 is a diagram showing an example of a functional configuration of a test script modification device 10 according to an embodiment of the present invention.
  • 12 is a flowchart for explaining an example of a processing procedure executed by the search command extension unit 11 and the locator correction unit 12.
  • 3 is a flowchart for explaining an example of a processing procedure executed by the search command conversion unit 14.
  • FIG. 3 is a flowchart for explaining an example of a processing procedure executed by the locator rearranging unit 13.
  • FIG. 1 is a diagram showing an example of the hardware configuration of a test script modification device 10 according to an embodiment of the present invention.
  • the test script modification device 10 in FIG. 1 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a processor 104, an interface device 105, etc., which are interconnected by a bus B.
  • a program that realizes the processing by the test script modification device 10 is provided by a recording medium 101 such as a CD-ROM.
  • a recording medium 101 such as a CD-ROM.
  • the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100.
  • the program does not necessarily need to be installed from the recording medium 101, and may be downloaded from another computer via a network.
  • the auxiliary storage device 102 stores installed programs as well as necessary files, data, and the like.
  • the memory device 103 reads and stores the program from the auxiliary storage device 102 when there is an instruction to start the program.
  • the processor 104 is a CPU, a GPU (Graphics Processing Unit), or a CPU and a GPU, and executes functions related to the test script correction device 10 according to a program stored in the memory device 103.
  • the interface device 105 is used as an interface for connecting to a network.
  • FIG. 2 is a diagram showing an example of the functional configuration of the test script modification device 10 according to the embodiment of the present invention.
  • the test script modification device 10 includes a search command extension section 11, a locator modification section 12, a locator rearrangement section 13, and a search command conversion section 14. Each of these units is realized by one or more programs installed in the test script correction device 10 causing the processor 104 to execute the process.
  • the test script modification device 10 also utilizes a modification history storage section 15.
  • the modification history storage unit 15 can be realized using, for example, the auxiliary storage device 102 or a storage device connectable to the test script modification device 10 via a network.
  • the search command extension unit 11 extends the existing test library and provides an command (API) for searching one screen element in response to designation of a plurality of locators.
  • the existing test library is an existing GUI test library that is called from a test script.
  • screen elements displayed on the screen being displayed for testing (for example, a web page being displayed in a web browser) are An instruction to search for one specific element (for example, to be manipulated) using an existing test library is written in the source code of the test script.
  • One locator is given to the argument of the command to search for the element (hereinafter referred to as "existing search command"). If the existing search command is able to capture an element, it returns the captured element (an object thereof). Note that within the test script, the returned element (object thereof) can be used to execute operation instructions, etc. for the element.
  • a unique instruction (hereinafter referred to as an "extended search instruction") that can give multiple locators as arguments to an instruction to search for an element is added from the outside to an existing test library.
  • the locator group has a priority order, and the earlier the locator in the order of designation of the locator for the extended search command, the higher the priority.
  • the extended search instruction searches for elements using locators one by one in order from the beginning of the specified locator group, and returns the first captured element.
  • the existing search instruction is used as is for the process of searching for an element using one locator.
  • a locator is composed of a type k and a value v k , and an element whose attribute k has a value v k is a search target.
  • An attribute group K (id, name, XPath, etc.) that can be used as k is defined in advance. k is limited to what can be obtained and calculated from the element and the screen being displayed (for example, a web page) to be tested.
  • an existing search instruction for searching for an element whose id attribute value is "password” in a certain Web application can be written as follows.
  • an existing test library is extended, and an element specifying multiple locators is defined by defining a unique instruction "findElementMulti" as an extended search instruction that functions as the search instruction extension section 11. It is possible to search for For example, the interface specifications of "findElementMulti" are as follows.
  • driver.findElementMulti ( ⁇ id: "password” ⁇ , ⁇ name: “password” ⁇ , ⁇ xpath: "/html/body/nav/div/ul/li[3]” ⁇ );
  • This extended search instruction first searches for an element whose id attribute value is "password”, and if the element cannot be captured, it searches for an element whose name attribute value is "password”, and if the element cannot be captured even then. In this case, it indicates that an element whose XPath is "/html/body/nav/div/ul/li[3]" is to be searched.
  • Locator correction unit 12 During execution of a test script that uses an extended search instruction (findElementMulti), the locator modification unit 12 corrects some of the locators specified in the extended search instruction in the source code of the test script. Determine whether or not it is broken. If there is a broken locator, the locator correction unit 12 rewrites the source code to correct the broken locator.
  • the locator modification unit 12 is implemented within the extended search instruction (findElementMulti). Therefore, it can be said that the extended search instruction (findElementMulti) has a search instruction extension section 11 and a locator modification section 12.
  • search command converter 14 When an existing search instruction is called during execution of a test script that uses an existing search instruction, the search instruction conversion unit 14 converts the existing search instruction into an extended search instruction provided by the search instruction extension unit 11 (i.e. , an instruction to search for one element in response to multiple locator specifications).
  • the search instruction converter 14 is implemented within an existing search instruction (for example, findElement). Therefore, in this embodiment, the existing search instruction includes the search instruction converter 14.
  • the locator rearranging unit 13 changes the order of designation of the plurality of locators specified in the extended search command based on the robustness of the locators. Sort in descending order.
  • the robustness of a locator refers to the locator's resistance to breakage.
  • a locator that is likely to be modified means that it is fragile.
  • the locator rearrangement unit 13 is implemented within the extended search instruction (findElementMulti). Therefore, it can be said that the extended search instruction (findElementMulti) includes the locator rearrangement section 13 in addition to the search instruction extension section 11 and the locator modification section 12.
  • FIG. 3 is a flowchart for explaining an example of the processing procedure executed by the search command extension unit 11 and the locator correction unit 12.
  • the search instruction extension unit 11 executes a loop process including steps S102 and S103 for each locator specified as an argument.
  • the locator to be processed in the loop processing is referred to as a "target locator.”
  • Each locator becomes a target locator in the order specified in the argument.
  • step S102 the search instruction extension unit 11 specifies the target locator as an argument and calls an existing search instruction (for example, findElement) to find an element (object of) from the currently displayed screen (for example, a web page). ) can be captured. If the element cannot be captured (No in S102), the locator specified next to the target locator is set as the target locator and loop processing is executed.
  • an existing search instruction for example, findElement
  • the search command extension unit 11 records the captured element as the correct element e in the memory device 103 (S103), and exits the loop process. That is, elements are searched for in order using a plurality of locators, and the first element that can be captured is recorded as the correct element e.
  • the search instruction extension unit 11 determines whether element e is recorded in the memory device 103 (that is, whether element e could be captured by any locator). is determined (S104). If element e is not recorded in the memory device 103 (No in S104), the search command extension unit 11 returns an error to the test script that called the extended search command (S105).
  • the locator correction unit 12 identifies the calling location of the called extended search instruction on the source code of the test script (S106). Specifically, the locator modification unit 12 analyzes the stack trace of the program and determines the path name of the file that includes the call location of the extended search command among the files that make up the test script, and the location of the call location in the file. Get the line number.
  • the locator correction unit 12 performs syntax analysis on the line with the line number of the file, and for each locator specified in the extended search instruction, the locator correction unit 12 determines the line number where the locator is written, the locator The type and value of the locator, the start string (from which character) and the end string (from which character) of the locator are acquired (S107).
  • the locator modification unit 12 executes a loop process including steps S108 to S113 for every locator specified in the extended search command.
  • the locator to be processed in the loop processing is referred to as a "target locator.”
  • step S108 the locator modification unit 12 assigns the type of the target locator (id, name, XPath, etc.) to the variable k, and assigns the value of the target locator to the variable vk .
  • the locator modification unit 12 specifies the target locator as an argument and calls an existing search command (for example, findElement) to search for an element corresponding to the target locator from the currently displayed screen (for example, a web page). An attempt is made to capture (the object) (S109).
  • an existing search command for example, findElement
  • the locator modification unit 12 executes processing for modifying the target locator in steps S111 to S113.
  • step S111 the locator correction unit 12 attempts to obtain the value v' k of the attribute k from the element e. If the value v'k can be obtained (that is, if the element e has the attribute k) (Yes in S111), the locator correction unit 12 performs a correction on the source code of the test script based on the information obtained in step S107. The source code is modified (rewritten) so as to replace the value v k of the target locator identified by v k with v' k (S112).
  • the locator correction unit 12 updates the information about the target locator on the source code of the test script in step S107.
  • the source code is modified (rewritten) so that the target locator is deleted from the position specified based on the source code (S113).
  • the locator modification unit 12 modifies the extended search command as follows.
  • FIG. 4 is a flowchart for explaining an example of a processing procedure executed by the search command conversion unit 14.
  • step S202 the search command conversion unit 14 specifies the target locator as an argument and executes the existing implementation of the existing search command (for example, findElement), thereby converting the contents of the currently displayed screen (for example, a web page). It is determined whether the element e (object thereof) corresponding to the locator specified as an argument of the existing search command can be acquired from the search command. If element e cannot be captured (No in S202), the search command conversion unit 14 returns an error to the test script that called the existing search command (S203).
  • the existing search command for example, findElement
  • the search instruction extension unit 11 records element e in the memory device 103 (S204).
  • the search command conversion unit 14 executes a loop process including steps S205 to S207 for each of the plurality of attributes k included in the predefined attribute group K.
  • the attribute k targeted for processing in the loop processing is referred to as a "target attribute k.”
  • attribute group K is a collection of attributes that can be used as locators.
  • the attribute group K may be a set of attributes that can uniquely identify the element e among the attributes that the element e has. In this case, the attribute group K may not be defined in advance, but may be determined by the search command conversion unit 14 at this timing.
  • step S205 the search command conversion unit 14 obtains the value v k of the target attribute k from the element e. If the value v k of the target attribute k is successfully acquired (that is, if the element e has the target attribute k) (Yes in S206), the search command conversion unit 14 converts the set of the target attribute k and its value v k to , is added to the locator group L as a locator of type k and value vk (S207).
  • the locator group L is, for example, list-structured data that can store one or more locators.
  • step S207 is not executed. Therefore, in the loop processing, among the attribute group K, the attribute k that can be used as a locator and the locator corresponding to its value vk are stored in the locator group L. For example, if ⁇ k 1 , k 2 , . . . , k n ⁇ K exists in element e, n locators are stored in locator group L.
  • the search command conversion unit 14 determines whether the locator group L includes two or more locators (S208). If the locator group L does not include two or more locators (No in S208), steps S209 to S212 are not executed and the process advances to step S213.
  • the search command conversion unit 14 in subsequent steps S209 and S210, converts the called existing search command into The path name of the file that contains the call location, the line number of the location in the file, the type and value of the locator specified in the existing search command, the starting column (from which character) and ending column (from which character) of the locator. (up to the first character).
  • the search instruction conversion unit 14 replaces the called existing search instruction with an extended search instruction (findElementMulti), and each locator included in the locator group L is specified for the replaced extended search instruction. (that is, the original locator is replaced with the locator group L), the calling portion of the existing search instruction is rewritten in the source code of the test script (S211). Note that the original locator description position can be specified from the information acquired in step S210.
  • step S212 the search command conversion unit 14 requests the locator rearrangement unit 13 to rearrange the locators of each extended search command called from the test script in the specified order (S212).
  • the locator designation order rewritten in step S211 can also be modified based on robustness.
  • the process advances to step S213. Note that step S212 does not have to be executed at this timing.
  • the locator rearrangement unit 13 may be called at a timing specified by the user after the test is finished.
  • step S213 the search instruction conversion unit 14 returns element e to the test script that called the existing search instruction.
  • driver.findElement ( ⁇ id: "password” ⁇ ); It is assumed that element e has a name attribute and an XPath attribute in addition to the id attribute. In this case, if the priority order of these attributes is id, name, and XPath, the above existing search command is rewritten as follows. driver.findElementMulti( ⁇ id: "password” ⁇ , ⁇ name: "password” ⁇ , ⁇ xpath: "/html/body/nav/div/ul/li[3]” ⁇ ); Note that although the XPath cannot be obtained only from element e, it can be calculated from element e and the screen to be tested.
  • FIG. 5 is a flowchart for explaining an example of a processing procedure executed by the locator rearranging unit 13.
  • step S112 or S113 in FIG. 3 is executed and any locator in the extended search instruction is modified (Yes in S301)
  • the locator rearrangement unit 13 calculates the number of modifications p k for the modified locator type k. 1 is added to (S302). That is, step S302 is executed within step S112 or S113 in FIG.
  • the number of modifications for each type of locator is stored in the modification history storage section 15, and its initial value is zero.
  • the susceptibility to modification (fragility) of a locator is defined by the number of modifications.
  • step S212 of FIG. 4 or when the user requests to change the order of the locators (Yes in S303), the locator rearranging unit 13 inserts an extended search command in the source code of the test script. All locations where ⁇ are called'' are identified (S304). In this embodiment, the location can be specified based on a character string search of "findElementMulti".
  • the locator rearrangement unit 13 performs the same process as step S107 to determine the line number where the locator is described in the file including the location, the type and value of the locator, and the start of the locator.
  • the sequence (from which character) and the end sequence (from which character) are acquired (S305).
  • the locator rearranging unit 13 executes a loop process including steps S306 and S307 for each call location identified in step S304.
  • step S306 the locator rearranging unit 13 acquires the number of modifications p k for each locator type k specified in the calling location to be processed (hereinafter referred to as “target calling location”) from the modification history storage unit 15. do.
  • the locator rearranging unit 13 changes (corrects) the target call location so that the designated order of locators at the target call location is in ascending order of the number of modifications pk (S307).
  • the types of locators specified in the target call location are types k 1 to types k n , and due to multiple past locator corrections, the magnitude relationship of the number of corrections p k is p k1 >p k2 > ⁇ ...>p kn , the locator rearrangement unit 13 changes the order of the locators so that they are specified in the order of [k n , . . . , k 2 , k 1 ].
  • the number of times the locator is modified using id is 10 times
  • the number of times the locator is modified using name is 7 times
  • the number of times using XPath is Assume that the number of times the locator has been modified is eight times.
  • driver.findElementMulti ( ⁇ id: "password” ⁇ , ⁇ name: “password” ⁇ , ⁇ xpath: "/html/body/nav/div/ul/li[3]” ⁇ ); It can be rewritten as follows. driver.findElementMulti( ⁇ name: "password” ⁇ , ⁇ xpath: "/html/body/nav/div/ul/li[3]” ⁇ , ⁇ id: "password” ⁇ );
  • the extended search instruction can search for elements preferentially using more robust locators. Therefore, it is possible to increase the possibility that the element captured by the extended search command is the element intended by the user.
  • a broken locator among a plurality of locators can be automatically corrected. Therefore, dealing with a plurality of locators can be made more efficient. For example, the effort for maintaining multiple locators can be reduced.
  • existing search instructions in the test script can be automatically converted to extended search instructions. Therefore, dealing with a plurality of locators can be made more efficient. For example, the effort for implementing multiple locators can be reduced.
  • Test script modification device 11
  • Search command expansion unit 12
  • Locator modification unit 13
  • Locator rearrangement unit 14
  • Search command conversion unit 15
  • Modification history storage unit 100
  • Drive device 101
  • Recording medium 102
  • Auxiliary storage device 103
  • Memory device 104
  • Processor 105 Interface device B bus

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)
  • Stored Programmes (AREA)

Abstract

テストスクリプト修正装置は、アプリケーションの画面に関するテストスクリプトのソースコードにおいて指定された複数のロケータのそれぞれを用いて或る画面要素を捕捉するように構成されている探索命令拡張部と、前記複数のロケータのうち前記或る画面要素を捕捉できなかった第１のロケータの値を、前記或る画面要素において前記第１のロケータの種類に対応する属性の値によって置換するように前記ソースコードを修正するように構成されているロケータ修正部と、を有することで、複数のロケータに対する対処を効率化する。

Description

テストスクリプト修正装置、テストスクリプト修正方法及びプログラム
　本発明は、テストスクリプト修正装置、テストスクリプト修正方法及びプログラムに関する。
　ＧＵＩアプリケーションにおける画面操作を伴うＥｎｄ－ｔｏ－Ｅｎｄテストの自動化においては、テストスクリプトのメンテナンスが求められる。テストスクリプトではテスト対象の操作のため、画面要素を特定するためのロケータを用いてテストの自動化が行われる。一般的にロケータは、画面要素のｉｄ，ｎａｍｅ等の属性やＸＰａｔｈのような構造的な情報を用いて定義される。
　テスト対象アプリケーションの修正により、ロケータとして用いられている情報に変更があると、テストスクリプト内では既存のロケータで画面要素が捕捉できなくなってしまう。このことをロケータが壊れると表現する。
　ロケータが壊れることが、テストスクリプトのメンテナンスが必要とされる要因の大半を占めており、テスト自動化の障壁となっている。
　従来、メンテナンスの労力を減らすために複数のロケータを用いる方法が提案されている。複数のロケータを用いることで、正しく画面要素を捕捉できたが部分的にロケータが壊れている場合に、正しい画面要素の情報を用いて壊れたロケータを自動修正することができる（非特許文献１）。
Leotta, M., A. Stocco, F. Ricca, and P. Tonella、"Using Multi-Locators to Increase the Robustness of Web Test Cases"、In 2015 IEEE 8th International Conference on Software Testing, Verification and Validation (ICST), 1-10, 2015
　従来手法に対応したツールは存在しないため人手で対処する必要が有るところ、複数のロケータを人手で対処するのは困難である。
　本発明は、上記の点に鑑みてなされたものであって、複数のロケータに対する対処を効率化することを目的とする。
　そこで上記課題を解決するため、テストスクリプト修正装置は、アプリケーションの画面に関するテストスクリプトのソースコードにおいて指定された複数のロケータのそれぞれを用いて或る画面要素を捕捉するように構成されている探索命令拡張部と、前記複数のロケータのうち前記或る画面要素を捕捉できなかった第１のロケータの値を、前記或る画面要素において前記第１のロケータの種類に対応する属性の値によって置換するように前記ソースコードを修正するように構成されているロケータ修正部と、を有する。
　複数のロケータに対する対処を効率化することができる。
本発明の実施の形態におけるテストスクリプト修正装置１０のハードウェア構成例を示す図である。 本発明の実施の形態におけるテストスクリプト修正装置１０の機能構成例を示す図である。 探索命令拡張部１１及びロケータ修正部１２が実行する処理手順の一例を説明するためのフローチャートである。 探索命令変換部１４が実行する処理手順の一例を説明するためのフローチャートである。 ロケータ並替部１３が実行する処理手順の一例を説明するためのフローチャートである。
　以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるテストスクリプト修正装置１０のハードウェア構成例を示す図である。図１のテストスクリプト修正装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、プロセッサ１０４、及びインタフェース装置１０５等を有する。
　テストスクリプト修正装置１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。プロセッサ１０４は、ＣＰＵ若しくはＧＰＵ（Graphics Processing Unit）、又はＣＰＵ及びＧＰＵであり、メモリ装置１０３に格納されたプログラムに従ってテストスクリプト修正装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
　図２は、本発明の実施の形態におけるテストスクリプト修正装置１０の機能構成例を示す図である。図２において、テストスクリプト修正装置１０は、探索命令拡張部１１、ロケータ修正部１２、ロケータ並替部１３及び探索命令変換部１４を有する。これら各部は、テストスクリプト修正装置１０にインストールされた１以上のプログラムが、プロセッサ１０４に実行させる処理により実現される。テストスクリプト修正装置１０は、また、修正履歴記憶部１５を利用する。修正履歴記憶部１５は、例えば、補助記憶装置１０２、又はテストスクリプト修正装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
　［探索命令拡張部１１］
　探索命令拡張部１１は、既存テストライブラリを拡張して、複数のロケータの指定を受けて１つの画面要素を探索する命令（ＡＰＩ）を提供する。既存テストライブラリとは、テストスクリプトから呼び出される既存のＧＵＩテストライブラリである。
　一般的に、Ｗｅｂアプリケーションやモバイルアプリケーションのテストでは、テスト用に表示中の画面（例えば、ウェブブラウザに表示中のＷｅｂページ）に表示されている画面要素（以下、単に「要素」という。）の中から、既存テストライブラリを用いて特定の（例えば、操作対象とする）１つの要素を探す命令がテストスクリプトのソースコード内に記述される。当該要素を探す命令（以下、「既存探索命令」という。）の引数には１つのロケータが与えられる。既存探索命令は、要素を捕捉できた場合、捕捉した要素（のオブジェクト）を返却する。なお、テストスクリプト内では、返却された要素（のオブジェクト）を用いて、当該要素に対する操作命令等を実行することができる。
　本実施の形態で、要素を探す命令の引数として複数のロケータを与えることができる独自の命令（以下、「拡張探索命令」という。）が外部から既存テストライブラリに追加される。
　ロケータ群は優先順位を持ち、拡張探索命令に対するロケータの指定順において前の順番のロケータほど優先度が高い。具体的には、拡張探索命令は、指定されたロケータ群の先頭から順番に１つずつロケータを用いて要素を探索し、最初に捕捉した要素を返す。なお、拡張探索命令内において、１つのロケータを用いて要素を探索する処理には既存探索命令がそのまま用いられる。
　ロケータは種類ｋと値ｖｋから構成され、属性ｋの値がｖｋである要素が探索対象となる。ｋとして用いることができる属性群Ｋ（ｉｄ，ｎａｍｅ，ＸＰａｔｈ等）は事前に定義される。ｋは要素及びテスト対象の表示中の画面（例えば、Ｗｅｂページ）から取得及び計算できるものに限られる。
　例えば、既存テストライブラリがＳｅｌｅｎｉｕｍ（登録商標）の場合、或るＷｅｂアプリケーションにおいて、ｉｄ属性の値が"ｐａｓｓｗｏｒｄ"である要素を探索する既存探索命令は以下のように記述できる。
driver.findElement({ id: "password" });
　本実施の形態では、既存テストライブラリを拡張し、本実施の形態において独自の命令"findElementMulti"を探索命令拡張部１１としての機能を有する拡張探索命令として定義することで複数のロケータを指定した要素の探索が可能とされる。 "findElementMulti"のインタフェース仕様は、例えば、以下の通りである。
driver.findElementMulti({ id: "password" }, { name: "password" }, { xpath: "/html/body/nav/div/ul/li[3]" });
　この拡張探索命令は、まず、ｉｄ属性の値が"ｐａｓｓｗｏｒｄ"である要素を探索し、要素を捕捉できない場合にはｎａｍｅ属性の値が"ｐａｓｓｗｏｒｄ"である要素を探索し、それでも要素を捕捉できない場合には、ＸＰａｔｈが"／ｈｔｍｌ／ｂｏｄｙ／ｎａｖ／ｄｉｖ／ｕｌ／ｌｉ［３］"である要素を探索することを示す。
　ＷｅｂＤｒｉｖｅｒＩＯ等の他のＧＵＩ自動テストライブラリに対しても同様に拡張可能である。
　［ロケータ修正部１２］
　ロケータ修正部１２は、拡張探索命令（findElementMulti）を利用しているテストスクリプトの実行中に、当該テストスクリプトのソースコードにおいて当該拡張探索命令に指定されている複数のロケータのうちの一部のロケータが壊れているか否かを判定する。ロケータ修正部１２は、壊れたロケータが有れば、当該ロケータを修正するために当該ソースコードを書き換える。ロケータ修正部１２は、拡張探索命令（findElementMulti）内において実装される。したがって、拡張探索命令（findElementMulti）は、探索命令拡張部１１及びロケータ修正部１２を有するといえる。
　［探索命令変換部１４］
　探索命令変換部１４は、既存探索命令を利用しているテストスクリプトの実行中において既存探索命令が呼び出された際に、当該既存探索命令を探索命令拡張部１１によって提供される拡張探索命令（すなわち、複数のロケータの指定を受けて１つの要素を探索する命令）に自動的に変換する。探索命令変換部１４は、既存探索命令（例えば、findElement）内に実装される。したがって、本実施の形態では、既存探索命令が探索命令変換部１４を有する。
　［ロケータ並替部１３］
　拡張探索命令において、ロケータが正しい要素以外の要素を捕捉すると、テストスクリプトは間違った要素を操作することになり正しくテスト実行を行うことができない。そのため、壊れにくいロケータが優先して用いられる必要が有る。そこで、ロケータ並替部１３は、拡張探索命令を利用しているテストスクリプトが実行される際に、当該拡張探索命令に指定されている複数のロケータの指定順を、ロケータの頑健性の高さの降順に並び替える。ロケータの頑健性とは、ロケータの壊れにくさをいう。修正される可能性が高いロケータは壊れやすいことを意味する。ロケータ並替部１３は、拡張探索命令（findElementMulti）内において実装される。したがって、拡張探索命令（findElementMulti）は、探索命令拡張部１１及びロケータ修正部１２に加えてロケータ並替部１３を有するといえる。
　［処理手順］
　以下、各部に関する処理手順について説明する。図３は、探索命令拡張部１１及びロケータ修正部１２が実行する処理手順の一例を説明するためのフローチャートである。
　テストの実行中に、拡張探索命令（findElementMulti）がテストスクリプトから呼び出されると（Ｓ１０１でＹｅｓ）、当該拡張探索命令内においてステップＳ１０２以降の処理手順が実行される。
　ます、探索命令拡張部１１は、引数に指定されたロケータごとにステップＳ１０２及びＳ１０３を含むループ処理を実行する。当該ループ処理において処理対象とされているロケータを「対象ロケータ」という。各ロケータは引数に指定された順に対象ロケータになる。
　ステップＳ１０２において、探索命令拡張部１１は、対象ロケータを引数に指定して既存探索命令（例えば、findElement）を呼び出すことで、現在表示中の画面（例えば、Ｗｅｂページ）の中から要素（のオブジェクト）を捕捉できるか否かを判定する。要素を捕捉できない場合（Ｓ１０２でＮｏ）、対象ロケータの次に指定されているロケータが対象ロケータとされてループ処理が実行される。
　要素を捕捉できた場合（Ｓ１０２でＹｅｓ）、探索命令拡張部１１は、捕捉できた要素を正しい要素ｅとしてメモリ装置１０３に記録しておき（Ｓ１０３）、ループ処理を抜ける。すなわち、複数のロケータで順番に要素を探索し、最初に捕捉できた要素が正しい要素ｅとして記録される。
　ステップＳ１０３に続いて、又はループ処理が終了すると、探索命令拡張部１１は、要素ｅがメモリ装置１０３に記録されているか否か（すなわち、いずれかのロケータで要素ｅを捕捉できたか否か）を判定する（Ｓ１０４）。要素ｅがメモリ装置１０３に記録されていない場合（Ｓ１０４でＮｏ）、探索命令拡張部１１は、拡張探索命令の呼び出し元であるテストスクリプトにエラーを返却する（Ｓ１０５）。
　要素ｅがメモリ装置１０３に記録されている場合（Ｓ１０４でＹｅｓ）、ロケータ修正部１２は、テストスクリプトのソースコード上において、呼び出された拡張探索命令の呼び出し箇所を特定する（Ｓ１０６）。具体的には、ロケータ修正部１２は、プログラムのスタックトレースを解析して、テストスクリプトを構成するファイル群の中で当該拡張探索命令の呼び出し箇所を含むファイルのパス名及び当該ファイルにおける当該箇所の行番号を取得する。
　続いて、ロケータ修正部１２は、当該ファイルの当該行番号の行について構文解析を行うことで、当該拡張探索命令に指定されているロケータごとに、当該ロケータが記述されている行番号、当該ロケータの種類及び値、当該ロケータの開始列（何文字目から）及び終了列（何文字目まで）を取得する（Ｓ１０７）。
　構文解析は、例えば、Ｎ個のロケータを引数として指定可能な拡張探索命令は以下の形式で記述されているとの前提で行われる。なお、本実施の形態において、以下の＜拡張探索命令名＞は、「findElementMulti」である。
　＜拡張探索命令名＞（｛種類１：値１｝，｛種類２：値２｝，...，｛種類Ｎ：値Ｎ｝）
　続いて、ロケータ修正部１２は、拡張探索命令に指定された全てのロケータごとに、ステップＳ１０８～Ｓ１１３を含むループ処理を実行する。当該ループ処理において処理対象とされているロケータを「対象ロケータ」という。
　ステップＳ１０８において、ロケータ修正部１２は、対象ロケータの種類（ｉｄ，ｎａｍｅ，ＸＰａｔｈ等）を変数ｋに代入し、対象ロケータの値を変数ｖｋに代入する。
　続いて、ロケータ修正部１２は、対象ロケータを引数に指定して既存探索命令（例えば、findElement）を呼び出すことで、現在表示中の画面（例えば、Ｗｅｂページ）の中から対象ロケータに対応する要素（のオブジェクト）の捕捉を試行する（Ｓ１０９）。
　対象ロケータで要素を取得できない場合、又は対象ロケータで捕捉した要素（以下、「捕捉要素」という。）が要素ｅと異なる場合（Ｓ１１０でＹｅｓ）、対象ロケータは壊れている。そこで、この場合、ロケータ修正部１２は、対象ロケータを修正するための処理をステップＳ１１１～Ｓ１１３において実行する。
　ステップＳ１１１において、ロケータ修正部１２は、要素ｅから属性ｋの値ｖ'ｋの取得を試みる。値ｖ'ｋを取得できた場合（すなわち、要素ｅが属性ｋを有する場合）（Ｓ１１１でＹｅｓ）、ロケータ修正部１２は、テストスクリプトのソースコード上において、ステップＳ１０７で取得された情報に基づいて特定される対象ロケータの値ｖｋの箇所を、ｖ'ｋに置換するように当該ソースコードを修正する（書き換える）（Ｓ１１２）。値ｖ'ｋを取得できない場合（すなわち、要素ｅが属性ｋを有さない場合）（Ｓ１１１でＮｏ）、ロケータ修正部１２は、対象ロケータについて、テストスクリプトのソースコード上においてステップＳ１０７において情報に基づいて特定される位置から対象ロケータが削除されるように当該ソースコードを修正する（書き換える）（Ｓ１１３）。
　以上のような修正が、呼び出された全ての拡張探索命令について実行されることで、全ての壊れたロケータが修正される。
　例えば、以下の拡張探索命令を利用して探索できていた要素について、ｉｄ属性の値が"ｎｅｗ－ｐａｓｓｗｏｒｄ"に変更され、ｎａｍｅ属性が削除されていたとする。一方、ＸＰａｔｈには変更が無いとする。
driver.findElementMulti({ id: "password" }, { name: "password" }, { xpath: "/html/body/nav/div/ul/li[3]" });
　ＸＰａｔｈは変更がなく、ロケータ｛ｘｐａｔｈ："／ｈｔｍｌ／ｂｏｄｙ／ｎａｖ／ｄｉｖ／ｕｌ／ｌｉ［３］"｝により正しい要素を捕捉できるとする。
　この場合、｛ｉｄ："ｐａｓｓｗｏｒｄ"｝，｛ｎａｍｅ："ｐａｓｓｗｏｒｄ"｝では正しい要素を捕捉できないため、この２つのロケータは壊れたロケータであると判定される。一方、ロケータ｛ｘｐａｔｈ："／ｈｔｍｌ／ｂｏｄｙ／ｎａｖ／ｄｉｖ／ｕｌ／ｌｉ［３］"｝では要素を捕捉できるため、当該要素が正しい要素ｅとされる。要素ｅからｉｄ属性の値を取得することができ、この値が"ｎｅｗ－ｐａｓｓｗｏｒｄ"であるとする。また、要素ｅからｎａｍｅ属性の値は取得できないとする。この場合、ロケータ修正部１２は、以下のように拡張探索命令を修正する。
driver.findElementMulti({ id: "new-password" }, { xpath: "/html/body/nav/div/ul/li[3]" });
　すなわち、種類がｉｄであるロケータの値が"ｎｅｗ－ｐａｓｓｗｏｒｄ"に変更され、種類がｎａｍｅであるロケータが削除される。
　図４は、探索命令変換部１４が実行する処理手順の一例を説明するためのフローチャートである。
　テストの実行中に、既存探索命令（例えば、findElement）がテストスクリプトから呼び出されると（Ｓ２０１でＹｅｓ）、当該既存探索命令内においてステップＳ２０２以降の処理手順が実行される。
　ステップＳ２０２において、探索命令変換部１４は、対象ロケータを引数に指定して既存探索命令（例えば、findElement）の既存の実装を実行することで、現在表示中の画面（例えば、Ｗｅｂページ）の中から既存探索命令の引数に指定されたロケータに対応する要素ｅ（のオブジェクト）を捕捉できるか否かを判定する。要素ｅを捕捉できない場合（Ｓ２０２でＮｏ）、探索命令変換部１４は、既存探索命令の呼び出し元であるテストスクリプトにエラーを返却する（Ｓ２０３）。
　要素ｅを捕捉できた場合（Ｓ１０２でＹｅｓ）、探索命令拡張部１１は、要素ｅをメモリ装置１０３に記録しておく（Ｓ２０４）。
　続いて、探索命令変換部１４は、事前に定義された属性群Ｋに含まれる複数の属性ｋごとに、ステップＳ２０５～Ｓ２０７を含むループ処理を実行する。当該ループ処理において処理対象とされている属性ｋを「対象属性ｋ」という。例えば、属性群Ｋは、ロケータとして利用可能な属性の集合である。又は、属性群Ｋは、要素ｅが有する属性のうち、要素ｅを一意に特定可能な属性の集合であってもよい。この場合、属性群Ｋは、事前に定義されるのではなく、このタイミングで探索命令変換部１４が決定してもよい。
　ステップＳ２０５において、探索命令変換部１４は、対象属性ｋの値ｖｋを要素ｅから取得する。対象属性ｋの値ｖｋの取得に成功した場合（すなわち、要素ｅが対象属性ｋを有する場合）（Ｓ２０６でＹｅｓ）、探索命令変換部１４は、対象属性ｋ及びその値ｖｋの組を、種類ｋ及び値ｖｋのロケータとしてロケータ群Ｌに追加する（Ｓ２０７）。ロケータ群Ｌは、例えば、１以上のロケータを格納可能なリスト構造のデータである。対象属性ｋの値ｖｋの取得に失敗した場合（すなわち、要素ｅが対象属性ｋを有さない場合）（Ｓ２０６でＮｏ）、ステップＳ２０７は実行されない。したがって、当該ループ処理では、属性群Ｋのうち、ロケータとして利用可能な属性ｋとその値ｖｋに対応するロケータがロケータ群Ｌに格納される。例えば、｛ｋ１，ｋ２，…，ｋｎ｝∈Ｋが要素ｅに存在する場合、ｎ個のロケータがロケータ群Ｌに格納される。
　属性群Ｋに含まれる全ての属性ｋについて当該ループ処理が実行されると、探索命令変換部１４は、ロケータ群Ｌが２以上のロケータを含むか否かを判定する（Ｓ２０８）。ロケータ群Ｌが２以上のロケータを含まない場合（Ｓ２０８でＮｏ）、ステップＳ２０９～Ｓ２１２は実行されずにステップＳ２１３へ進む。
　ロケータ群Ｌが２以上のロケータを含む場合（Ｓ２０８でＹｅｓ）、探索命令変換部１４は、続くステップＳ２０９及びＳ２１０において、図３のステップＳ１０６及びＳ１０７と同様の処理によって、呼び出された既存探索命令の呼び出し箇所を含むファイルのパス名、当該ファイルにおける当該箇所の行番号、当該既存探索命令に指定されているロケータの種類及び値、当該ロケータの開始列（何文字目から）及び終了列（何文字目まで）を取得する。
　続いて、探索命令変換部１４は、呼び出された既存探索命令を拡張探索命令（findElementMulti）に置換し、置換後の拡張探索命令に対してロケータ群Ｌに含まれている各ロケータが指定されるように（すなわち、元のロケータがロケータ群Ｌに置換されるように）、テストスクリプトのソースコードにおいて当該既存探索命令の呼び出し箇所を書き換える（Ｓ２１１）。なお、元のロケータの記述位置は、ステップＳ２１０において取得されている情報から特定可能である。
　続いて、探索命令変換部１４は、テストスクリプトから呼び出される各拡張探索命令のロケータの指定順の並び替えをロケータ並替部１３に要求する（Ｓ２１２）。その結果、ステップＳ２１１において書き換えられたロケータの指定順も頑健性に基づいて修正されうる。続いて、ステップＳ２１３へ進む。なお、ステップＳ２１２はこのタイミングで実行されなくてもよい。例えば、テスト終了後においてユーザから指定されるタイミングで、ロケータ並替部１３が呼び出されてもよい。
　ステップＳ２１３において、探索命令変換部１４は、既存探索命令の呼び出し元のテストスクリプトへ要素ｅを返却する。
　例えば、呼び出された既存探索命令が以下の通りであるとする。
driver.findElement({ id: "password" });
　要素ｅは、ｉｄ属性に加え、ｎａｍｅ属性及びＸＰａｔｈ属性を有するとする。この場合、これらの属性の優先順位が、ｉｄ、ｎａｍｅ、ＸＰａｔｈの順であれば、上記の既存探索命令は以下のように書き換えられる。
driver.findElementMulti({ id: "password" }, { name: "password" }, { xpath: "/html/body/nav/div/ul/li[3]" });
　なお、ＸＰａｔｈは、要素ｅのみから取得することはできないが、要素ｅとテスト対象の画面から計算可能である。
　図５は、ロケータ並替部１３が実行する処理手順の一例を説明するためのフローチャートである。
　図３のステップＳ１１２又はＳ１１３が実行されて、拡張探索命令のいずれかのロケータが修正されると（Ｓ３０１でＹｅｓ）、ロケータ並替部１３は、修正されたロケータの種類ｋの修正回数ｐｋに１を加算する（Ｓ３０２）。すなわち、ステップＳ３０２は、図３のステップＳ１１２又はＳ１１３内において実行される。ロケータの種類ごとの修正回数は、修正履歴記憶部１５に記憶され、その初期値は０である。本実施の形態では、ロケータの修正されやすさ（壊れやすさ）が修正回数によって定義される。
　一方、図４のステップＳ２１２において、又はユーザの任意のタイミングでロケータの順番の入れ替えが要求されると（Ｓ３０３でＹｅｓ）、ロケータ並替部１３は、テストスクリプトのソースコード内において、拡張探索命令を呼び出している全ての箇所を特定する（Ｓ３０４）。本実施の形態であれば、「findElementMulti」の文字列検索に基づいて当該箇所を特定することができる。
　続いて、ロケータ並替部１３は、特定した各箇所について、ステップＳ１０７と同様の処理によって、当該箇所を含むファイルにおいてロケータが記述されている行番号、当該ロケータの種類及び値、当該ロケータの開始列（何文字目から）及び終了列（何文字目まで）を取得する（Ｓ３０５）。
　続いて、ロケータ並替部１３は、ステップＳ３０４において特定された呼び出し箇所ごとにステップＳ３０６及びＳ３０７を含むループ処理を実行する。
　ステップＳ３０６において、ロケータ並替部１３は、処理対象の呼び出し箇所（以下、「対象呼び出し箇所」という。）において指定されている各ロケータの種類ｋに関する修正回数ｐｋを修正履歴記憶部１５から取得する。
　続いて、ロケータ並替部１３は、対象呼び出し箇所におけるロケータの指定順が修正回数ｐｋの昇順となるように対象呼び出し箇所を変更（修正）する（Ｓ３０７）。
　対象呼び出し箇所に指定されているロケータの種類が種類ｋ１～種類ｋｎであり、過去の複数回のロケータの修正によって、これらの修正回数ｐｋの大小関係が、ｐｋ１＞ｐｋ２＞・・・＞ｐｋｎとなっている場合、ロケータ並替部１３は、［ｋｎ，…，ｋ２，ｋ１］の順番で指定されるようにロケータの順番を変更する。
　例えば、複数回のテストスクリプトの実行（すなわち、図４の処理手順の実行）後において、ｉｄを用いたロケータの修正回数が１０回、ｎａｍｅを用いたロケータの修正回数が７回、ＸＰａｔｈを用いたロケータの修正回数が８回であるとする。
　この場合、以下の拡張探索命令は、
driver.findElementMulti({ id: "password" }, { name: "password" }, { xpath: "/html/body/nav/div/ul/li[3]" });
以下のように書き換えられる。
driver.findElementMulti({ name: "password" }, { xpath: "/html/body/nav/div/ul/li[3]" }, { id: "password" });
　その結果、拡張探索命令は、より頑健性の高いロケータを優先的に用いて要素の探索を行うことができる。したがって、拡張探索命令によって捕捉される要素が、ユーザが意図した要素である可能性を高めることができる。
　上述したように、本実施の形態によれば、複数のロケータのうち壊れたロケータを自動的に修正することができる。したがって、複数のロケータに対する対処を効率化することができる。例えば、複数のロケータの保守のための労力を軽減することができる。
　また、テストスクリプト中の既存探索命令を自動的に拡張探索命令に変換することができる。したがって、複数のロケータに対する対処を効率化することができる。例えば、複数のロケータの実装のための労力を軽減することができる。
　以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
１０　　　　　テストスクリプト修正装置
１１　　　　　探索命令拡張部
１２　　　　　ロケータ修正部
１３　　　　　ロケータ並替部
１４　　　　　探索命令変換部
１５　　　　　修正履歴記憶部
１００　　　　ドライブ装置
１０１　　　　記録媒体
１０２　　　　補助記憶装置
１０３　　　　メモリ装置
１０４　　　　プロセッサ
１０５　　　　インタフェース装置
Ｂ　　　　　　バス

Claims (7)

  1. 　アプリケーションの画面に関するテストスクリプトのソースコードにおいて指定された複数のロケータのそれぞれを用いて或る画面要素を捕捉するように構成されている探索命令拡張部と、
    　前記複数のロケータのうち前記或る画面要素を捕捉できなかった第１のロケータの値を、前記或る画面要素において前記第１のロケータの種類に対応する属性の値によって置換するように前記ソースコードを修正するように構成されているロケータ修正部と、
    を有することを特徴とするテストスクリプト修正装置。
  2. 　前記ロケータ修正部は、前記第１のロケータで前記或る画面要素と異なる画面要素を捕捉できた場合に、前記或る画面要素が前記第１のロケータの種類に対応する属性を有すれば、当該属性の値によって前記第１のロケータの値を書き換えるように構成されている、
    ことを特徴とする請求項１記載のテストスクリプト修正装置。
  3. 　前記ロケータ修正部は、前記第１のロケータで前記或る画面要素と異なる画面要素を捕捉できた場合に、前記或る画面要素が前記第１のロケータの種類に対応する属性を有さなければ、前記第１のロケータを前記ソースコードから削除するように構成されている、
    ことを特徴とする請求項１又は２記載のテストスクリプト修正装置。
  4. 　前記探索命令拡張部は、前記複数のロケータのそれぞれを前記ソースコードにおいて指定されている順番で用いて前記画面要素を捕捉するように構成されており、
    　前記ロケータ修正部は、最初に捕捉できた画面要素において前記第１のロケータの種類に対応する属性の値によって前記第１のロケータの値を置換するように前記ソースコードを書き換えるように構成されている、
    ことを特徴とする請求項１記載のテストスクリプト修正装置。
  5. 　前記ロケータの種類ごとに、前記ロケータ修正部によって値が書き換えられた回数を記録し、前記ソースコードにおいて指定されている前記複数のロケータの順番を、前記複数のロケータに係る前記回数の昇順に変更するように構成されているロケータ並替部、
    を有することを特徴とする請求項４記載のテストスクリプト修正装置。
  6. 　アプリケーションの画面に関するテストスクリプトのソースコードにおいて指定された複数のロケータのそれぞれを用いて或る画面要素を捕捉する探索命令拡張手順と、
    　前記複数のロケータのうち前記或る画面要素を捕捉できなかった第１のロケータの値を、前記或る画面要素において前記第１のロケータの種類に対応する属性の値によって置換するように前記ソースコードを修正するロケータ修正手順と、
    をコンピュータが実行することを特徴とするテストスクリプト修正方法。
  7. 　アプリケーションの画面に関するテストスクリプトのソースコードにおいて指定された複数のロケータのそれぞれを用いて或る画面要素を捕捉する探索命令拡張手順と、
    　前記複数のロケータのうち前記或る画面要素を捕捉できなかった第１のロケータの値を、前記或る画面要素において前記第１のロケータの種類に対応する属性の値によって置換するように前記ソースコードを修正するロケータ修正手順と、
    をコンピュータに実行させることを特徴とするプログラム。
PCT/JP2022/033416 2022-09-06 2022-09-06 テストスクリプト修正装置、テストスクリプト修正方法及びプログラム WO2024052991A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/033416 WO2024052991A1 (ja) 2022-09-06 2022-09-06 テストスクリプト修正装置、テストスクリプト修正方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/033416 WO2024052991A1 (ja) 2022-09-06 2022-09-06 テストスクリプト修正装置、テストスクリプト修正方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2024052991A1 true WO2024052991A1 (ja) 2024-03-14

Family

ID=90192398

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/033416 WO2024052991A1 (ja) 2022-09-06 2022-09-06 テストスクリプト修正装置、テストスクリプト修正方法及びプログラム

Country Status (1)

Country Link
WO (1) WO2024052991A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019101538A (ja) * 2017-11-29 2019-06-24 日本電信電話株式会社 テストスクリプト修正装置及びプログラム
JP2021163123A (ja) * 2020-03-31 2021-10-11 株式会社 ディー・エヌ・エー 情報処理プログラム、情報処理装置及び情報処理方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019101538A (ja) * 2017-11-29 2019-06-24 日本電信電話株式会社 テストスクリプト修正装置及びプログラム
JP2021163123A (ja) * 2020-03-31 2021-10-11 株式会社 ディー・エヌ・エー 情報処理プログラム、情報処理装置及び情報処理方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LEOTTA MAURIZIO; STOCCO ANDREA; RICCA FILIPPO; TONELLA PAOLO: "Using Multi-Locators to Increase the Robustness of Web Test Cases", 2015 IEEE 8TH INTERNATIONAL CONFERENCE ON SOFTWARE TESTING, VERIFICATION AND VALIDATION (ICST), IEEE, 13 April 2015 (2015-04-13), pages 1 - 10, XP032774755, DOI: 10.1109/ICST.2015.7102611 *

Similar Documents

Publication Publication Date Title
US7165074B2 (en) Software development test case analyzer and optimizer
JP4436036B2 (ja) 情報処理装置、トレース処理方法、プログラム及び記録媒体
US8006229B2 (en) Program maintenance support device and program for the same
US10887171B2 (en) Routing configuration method of view files, storage medium, terminal device and apparatus
US7316015B2 (en) Method, apparatus, and program for constructing an execution environment, and computer readable medium recording program thereof
JPH0830620A (ja) 構造検索装置
CN106469049B (zh) 一种文件扫描的方法及装置
CN111813412B (zh) 构建评测二进制代码比对工具的测试数据集的方法及***
JP2006268118A (ja) アプリケーション環境チェック装置及び方法とそのプログラム
US8281289B2 (en) Device, method, and program for generating and executing execution binary image, and computer-readable recording medium containing the execution binary image execution program
US20230113783A1 (en) Cross-platform code conversion method and device
US6877156B2 (en) Recognition of command related items in object code
CN114003269A (zh) 组件处理方法、装置、电子设备及存储介质
WO2024052991A1 (ja) テストスクリプト修正装置、テストスクリプト修正方法及びプログラム
WO2024052992A1 (ja) テストスクリプト修正装置、テストスクリプト修正方法及びプログラム
US7831964B2 (en) Program automatic converting method and program automatic converting device
CN113515303A (zh) 一种项目转型方法、装置和设备
US20040117780A1 (en) Method and system for detecting and resolving unnecessary source module dependencies
US9396239B2 (en) Compiling method, storage medium and compiling apparatus
CN115080114A (zh) 应用程序的移植处理方法、装置和介质
KR102256894B1 (ko) 크래시 리포트 그룹핑 방법, 서버 및 컴퓨터 프로그램
CN114816437A (zh) 一种逆向生成Java实体类的方法、***和设备
CN110321130B (zh) 基于***调用日志的不可重复编译定位方法
CN110032366B (zh) 一种代码定位方法及装置
CN113792026A (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: 22958070

Country of ref document: EP

Kind code of ref document: A1