WO2022230189A1 - テスト支援装置、テスト支援方法、及びプログラム - Google Patents

テスト支援装置、テスト支援方法、及びプログラム Download PDF

Info

Publication number
WO2022230189A1
WO2022230189A1 PCT/JP2021/017247 JP2021017247W WO2022230189A1 WO 2022230189 A1 WO2022230189 A1 WO 2022230189A1 JP 2021017247 W JP2021017247 W JP 2021017247W WO 2022230189 A1 WO2022230189 A1 WO 2022230189A1
Authority
WO
WIPO (PCT)
Prior art keywords
screen
suspicion
degree
user
bug
Prior art date
Application number
PCT/JP2021/017247
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/JP2021/017247 priority Critical patent/WO2022230189A1/ja
Publication of WO2022230189A1 publication Critical patent/WO2022230189A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software

Definitions

  • the present invention relates to a test support device, test support method, and program.
  • Exploratory testing is a method of thinking about what to do next while conducting a test.
  • exploratory testing focusing on the results of the previous test and the behavior of the software at the time of the test, the test content is decided flexibly, and the test is performed intensively on the points where the system's failures are likely to lie. . For this reason, it is possible to reduce preparations such as preparation of a test design document, etc., and to efficiently discover system failures.
  • Exploratory testing requires a certain level of skill for the tester (hereafter referred to as a tester), but even if the development is carried out without the specifications being finalized, it can be done without depending on the design or specifications. It is excellent in that it can detect system failures.
  • exploratory testing the content of the test is determined by the tester, so there is the problem that the ability to detect bugs depends on the tester's knowledge of the test and the level of understanding of the system. In other words, exploratory testing is highly dependent on individual skills, and in general, there is a risk that bugs cannot be detected efficiently unless the tester is skilled.
  • An embodiment of the present invention has been made in view of the above points, and aims to support efficient bug detection.
  • a test support device is a test support device that supports testing of a Web application, and includes information about an operation performed on a screen of the Web application, a suspiciousness degree calculation unit for calculating a degree of suspicion representing a degree of suspicion that a bug is caused by an operation on the screen, using information about the bug; and testing on the screen of the web application based on the degree of suspicion. and a suggestion part for proposing a place to be edited.
  • FIG. 6 is a flowchart showing an example of test support processing according to the embodiment; It is a figure which shows an example of the proposal result of a test location. 6 is a flowchart showing an example of suspiciousness degree calculation processing according to the present embodiment; 8 is a flowchart showing an example of test point proposal processing according to the present embodiment;
  • test support device 10 capable of supporting efficient bug detection when testing a Web application, particularly for exploratory testing, will be described.
  • test support method proposed in this embodiment will be described.
  • the test support device 10 according to the present embodiment can implement efficient bug detection support by executing this test support method as processing (test support processing described later).
  • test support method proposed in this embodiment targets web applications displayed on web browsers installed in PCs (personal computers), mobile terminals, and the like.
  • PCs personal computers
  • mobile terminals mobile terminals
  • Information indicating web elements operated by the tester e.g., buttons, select boxes, input fields, etc.
  • time stamp i.e. date and time of operation
  • Information showing screens operated by the tester (4) Information related to bugs detected during testing Web application screens are described in a markup language such as HTML (HyperText Markup Language). Web elements are described by HTML elements (or HTML tags), for example.
  • the information including the above (1) to (3) is also called “operation information”, and the above (4) is also called “bug information”.
  • the operation information also includes information indicating the tester who performed the operation (for example, user ID or tester ID).
  • the bug information also includes information indicating the tester who detected and reported the bug (eg, user ID or tester ID, etc.).
  • the bug information includes information indicating the timing at which the bug was detected (for example, operation information about the operation performed immediately before the bug was detected and operation information about the operation performed immediately after the bug was detected. information (eg, operation information ID, etc.)) is also included.
  • the above operation information and bug information can be recorded by any known method.
  • the operation information it is possible to automatically record the operation information by monitoring the operation on the Web browser.
  • bug information can be recorded using the technique described in International Publication No. 2020/230241.
  • a value called a degree of suspicion defined by these index values is calculated. calculate.
  • the degree of suspicion is a value introduced in the test support method according to this embodiment, and represents the suspicion that an operation on a web element or screen causes a bug.
  • highly suspicious portions that is, highly suspicious Web elements and screens in which bugs are likely to be detected
  • highly suspicious portions that is, highly suspicious Web elements and screens in which bugs are likely to be detected
  • Index values f w1 to f w5 for Web elements and index values f p1 to f p8 for screens are defined using operation information and bug information.
  • input to a Web element refers to, for example, pressing or selecting the Web element when the Web element is a button, link, check box, select box, etc., or inputting text when the Web element is an input form or the like. It refers to input, etc.
  • a unique input to a web element refers to an input excluding duplication among inputs to the web element.
  • the input value set given to the screen is, for example, the input values given to all web elements in the screen after transitioning to the screen until transitioning to another screen ( For example, item values selected by the user, text entered by the user, etc.).
  • the number of input value sets given to a screen refers to a set of input values excluding duplication among the input value sets given to the screen.
  • index values fw1 and fp2 also include the number of operations for reporting bugs (bug reporting operations). Also, if a plurality of bugs are detected and reported for one operation or screen transition, it is assumed that the bug reporting operation has been performed the same number of times as the number of bugs. For example, when n bugs are detected and reported for one operation or screen transition, it is assumed that n bug reporting operations have been performed. This is to prevent an inappropriate value when calculating the degree of suspicion, which will be described later.
  • index values f w1 to f w5 and f p1 to f p8 described above are calculated by substituting specific values for the variables U, W, and P.
  • f w1 ( ⁇ u 1 , u 2 ⁇ , ⁇ w 1 , w 2 ⁇ ) is The number of operations performed on the web element w1, the number of times the user u1 performed operations on the web element w2, the number of times the user u2 performed operations on the web element w1, It is the sum of the number of times user u 2 has performed an operation on web element w 2 .
  • the number of operations performed by the user u on the web element w is calculated as the number of pieces of operation information for the web element w among the operation information of the user u. can be done.
  • the number of times user u transitioned to screen p is the operation information for the Web element (link or the like) for transitioning to screen p, among the operation information of user u. It can be calculated as a number.
  • index values f w2 to f w5 and f p2 to f p8 can be similarly calculated from operation information and bug information.
  • u ⁇ U, w ⁇ W, and p ⁇ P are similarly calculated from operation information and bug information.
  • fw2 can be calculated from the number of operation information for the web element w among the operation information of the user u.
  • fw3 can be calculated from the number of pieces of operation information of the user u, excluding pieces of operation information for the Web element w that have duplicate operation details.
  • fw4 can be calculated from the time stamp of the operation information of the user u for the web element w and the time stamp of the operation information when the user u operates the web element w next time. can.
  • fw5 can be calculated from the number of pieces of bug information related to the web element w among the pieces of bug information of the user u.
  • fp2 can be calculated from the number of pieces of operation information for web elements in the screen p among pieces of operation information of the user u.
  • f p3 is calculated from the number of operation information for web elements that take input values such as input fields and select boxes in screen p until transition to the next screen among the operation information of user u. be able to.
  • fp4 is, among the operation information of the user u, operation information for a Web element that takes input values such as an input form and a select box in the screen p until transition to the next screen, and also operation information. It can be calculated from the number of pieces of operation information excluding duplicate input values included in the content.
  • f p5 is, of the operation information of the user u, a time stamp of operation information for a web element for transitioning to screen p and a time stamp for operation information for a web element for transition from screen p to another screen.
  • fp6 can be calculated from the number of pieces of bug information related to the screen p among the bug information of the user u.
  • fp7 can be calculated as the number of Web elements included in the screen p by analyzing HTML or the like describing the screen p.
  • fp8 can be calculated as the total number of pieces of operation information for web elements for transitioning to screen p.
  • the degree of suspicion is defined using the above index values f w1 to f w5 and f p1 to f p8 .
  • the degree of suspicion is d below.
  • Condition 1 Select r and s so that 0 ⁇ d ⁇ 1.
  • Condition 2 Do not use a combination of index values for web elements and index values for screens. That is, if either r or s is the index value for the web element, the other also uses the index value for the web element. Similarly, if either r or s is an index value for the screen, the other also uses the index value for the screen.
  • Condition 3 Since the unit of fw4 and fp5 is time, they are not used in combination with other index values. That is, if one of r and s is f w4 , the other also uses f w4 , taking into account condition 2 above. Similarly, if one of r or s is fp5 , the other also uses fp5 .
  • bugs are likely to be detected in the following locations (web elements, screens).
  • the suspiciousness degree d1w due to the bug of the Web element w is calculated as follows, with all users as U all .
  • the degree of suspicion increases due to bugs in Web elements and screens that are considered to be related to many bugs even though the number of times they have been confirmed in tests is small.
  • Suspiciousness due to a small number of times that a web element or screen has been checked is defined as "suspiciousness degree based on the number of times".
  • the degree of suspicion d2w based on the number of web elements w is calculated as follows, with all web elements as Wall.
  • the degree of suspicion d2p based on the number of screens p is calculated as follows, with the entire screen being P all .
  • the Web element here is an element that takes an input value such as an input form or a select box.
  • the degree of suspicion d3w based on the input of the web element w is calculated as follows.
  • FIG. 1 is a diagram showing an example of the hardware configuration of a test support device 10 according to this embodiment.
  • the test support device 10 is realized by the hardware configuration of a general computer or computer system. /F 104 , processor 105 and memory device 106 . Each of these pieces of hardware is communicably connected via a bus 107 .
  • the input device 101 is, for example, a keyboard, mouse, touch panel, or the like.
  • the display device 102 is, for example, a display.
  • the external I/F 103 is an interface with an external device such as the recording medium 103a.
  • the test support device 10 can perform reading and writing of the recording medium 103a via the external I/F 103.
  • FIG. Examples of the recording medium 103a include CD (Compact Disc), DVD (Digital Versatile Disk), SD memory card (Secure Digital memory card), USB (Universal Serial Bus) memory card, and the like.
  • the communication I/F 104 is an interface for connecting the test support device 10 to a communication network.
  • the processor 105 is, for example, various arithmetic units such as a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit).
  • the memory device 106 is, for example, various storage devices such as HDD (Hard Disk Drive), SSD (Solid State Drive), RAM (Random Access Memory), ROM (Read Only Memory), and flash memory.
  • the test support device 10 has the hardware configuration shown in FIG. 1, so that the test support processing described later can be realized.
  • the hardware configuration shown in FIG. 1 is an example, and the test support device 10 may have other hardware configurations.
  • the test support device 10 may have multiple processors 105 and may have multiple memory devices 106 .
  • FIG. 2 is a diagram showing an example of the functional configuration of the test support device 10 according to this embodiment.
  • the test support device 10 has a web browser 201, an information recording unit 202, a suspiciousness degree calculation unit 203, and a proposal unit 204.
  • Each of these units is implemented by, for example, one or more programs installed in the test support apparatus 10 causing the processor 105 or the like to execute processing.
  • the test support device 10 has a storage unit 205 .
  • the storage unit 205 is implemented by, for example, the memory device 106 or the like.
  • the storage unit 205 may be implemented by, for example, a storage device or the like connected to the test support apparatus 10 via a communication network.
  • the web browser 201 is a web browser that displays web application screens and accepts operations on the screens.
  • the information recording unit 202 collects operation information for the screen displayed on the web browser 201 and bug information of the test for the screen, and saves (records) these operation information and bug information in the storage unit 205 . Note that, as described above, the operation information and bug information can be recorded by any known method.
  • the suspiciousness degree calculation unit 203 uses at least one of the operation information and the bug information stored in the storage unit 205 to calculate at least one of the index value for the web element and the index value for the screen. Calculate the degree of suspicion from the value.
  • the suggestion unit 204 uses the suspiciousness degree calculated by the suspiciousness degree calculation unit 203 to highlight the highly suspicious Web element and the highly suspicious screen, and suggests to the user the part to be tested next. .
  • the storage unit 205 stores the operation information and bug information collected by the information recording unit 202 .
  • FIG. 3 is a flowchart showing an example of test support processing according to this embodiment. It is assumed below that operation information and bug information are stored (recorded) in the storage unit 205 by the information recording unit 202 .
  • the suspiciousness degree calculation unit 203 uses at least one of the operation information and the bug information stored in the storage unit 205 to calculate at least one of the index value for the web element and the index value for the screen. A degree of suspicion is calculated from the value (step S101). Details of the processing for calculating the suspiciousness degree (suspiciousness degree calculation processing) will be described later.
  • the proposal unit 204 uses the degree of suspicion calculated in step S101 to highlight web elements with a high degree of suspicion and screens with a high degree of suspicion, and proposes to the user the location to be tested next (step S102). The details of the process of making this proposal (test location proposal process) will be described later.
  • FIG. 4 is a diagram illustrating an example of test location proposal results.
  • step S101 the degree of suspicion due to bugs in each screen, the degree of suspicion due to bugs in each Web element, the degree of suspicion based on the number of times each screen appears, the degree of suspicion based on the number of times each Web element appears, and the degree of suspicion based on the input of each Web element is calculated.
  • the screens the screens with the degree of suspiciousness within the top TP are highlighted, and with respect to the web elements, the web elements with the degree of suspiciousness within the top TW are highlighted .
  • the value of suspiciousness x 100 is displayed on the upper right of the screen, and the Web element is surrounded by a thick line and the value of suspiciousness x 100 is displayed on the upper right.
  • the mode of highlighting is not limited to this, and may be, for example, a mode such as blinking or pointing with an arrow.
  • T P and T W are predetermined integers of 1 or more.
  • the degree of suspicion due to bugs on the screen 1000 is within the top TP , and the value "70" is displayed on the upper right of the screen 1000.
  • the value "70" is displayed on the upper right of the screen 1000.
  • the degree of suspicion due to the bug of the Web element 1001 is within the top TW rank, and the value "70” is displayed on the upper right of the Web element 1001.
  • the degree of suspicion by the input of the web element 1002 is within the top TW rank, and the value "74" is displayed on the upper right of the web element 1002.
  • the degree of suspicion by the input of the web element 1003 is within the top TW rank, and the value "80” is displayed on the upper right of the web element 1003.
  • the Web element 1004 has both the suspiciousness degree due to the bug and the suspiciousness degree due to the number of times within the top TW ranks. is multiplied by 100, and the value "70” is displayed.
  • the Web element 1005 has a suspiciousness degree within the top TW ranks, and a value of “65” is displayed on the upper right of the Web element 1005 .
  • the tester can determine the next test location (screen, web element) and the content of the test.
  • FIG. 5 is a flowchart showing an example of suspiciousness degree calculation processing according to the present embodiment.
  • the degree of suspicion due to bugs in each screen the degree of suspicion due to bugs in each web element, the degree of suspicion based on the number of times each screen appears, the degree of suspicion based on the number of times each web element appears, and the degree of suspicion based on the input of each web element are calculated. A case of doing so will be explained.
  • the suspiciousness degree calculation unit 203 calculates the number of bugs associated with the Web element w, the number of operations performed on the Web element w, and the number of operations performed on the Web element w. and the number of unique inputs made to the web element w are calculated (step S201).
  • the suspiciousness degree calculation unit 203 calculates the number of operations performed on all web elements (step S202). Note that this is the total number of operations performed on each web element w.
  • the suspiciousness degree calculation unit 203 calculates the number of bugs related to the screen p and the number of transitions to the screen p (step S203).
  • the suspiciousness degree calculation unit 203 calculates the number of transitions to the full screen (step S204). Note that this is the total number of transitions to each screen p.
  • the suspiciousness degree calculation unit 203 uses the calculation results in steps S201 to S204 to calculate the suspiciousness degree d 1p due to the bug in the screen p and the bug in the web element w for each screen p and each web element w.
  • the suspiciousness degree d 1w by the screen p, the suspiciousness degree d 2p by the number of times of the screen p, the suspiciousness degree d 2w by the number of times of the web element w, and the suspiciousness degree d 3w by the input of the web element w are calculated (step S205).
  • FIG. 6 is a flow chart showing an example of test point proposal processing according to the present embodiment.
  • the suspiciousness degree d 1p due to the bug of each screen p the suspiciousness degree d 1w due to the bug of each web element w
  • the suspiciousness degree d 2p based on the number of times each screen p occurs the suspiciousness degree d based on the number of times each web element w occurs 2w
  • the degree of suspicion d 3w based on the input of each Web element w is calculated.
  • the proposing unit 204 calculates the suspiciousness degree d 1p due to the bug of each screen p, the suspiciousness degree d 1w due to the bug of each web element w, the suspiciousness degree d 2p based on the number of times each screen p occurs, and the suspiciousness degree d 2w based on the number of times each web element w.
  • the degree of suspicion d 3 w by the input of each Web element w is sorted in descending order (step S301).
  • the proposing unit 204 identifies the screen currently being tested (step S302).
  • the screen under current test is assumed to be p'.
  • the proposing unit 204 emphasizes and displays the screen p' according to the suspiciousness degree (step S303).
  • the proposing unit 204 displays the value of d1p' ⁇ 100 on the upper right to emphasize the screen p'. Further, when the degree of suspicion d2p' based on the number of times of screen p' is within the top T P , the proposal unit 204 displays the value of d2p' x 100 in the upper right to emphasize screen p'.
  • the proposing unit 204 identifies all web elements in the screen p' (step S304). These Web elements are hereinafter referred to as w' ⁇ W'(W' is a set of all Web elements on the screen p').
  • the proposing unit 204 emphasizes and displays the web element w' according to the suspiciousness degree (step S305).
  • the proposing unit 204 displays the value of d1w' x 100 on the upper right of the web element w', The web element w' is highlighted with a bold line. Further, when the degree of suspicion d2w' based on the number of times of the web element w' is within the top T W , the proposing unit 204 displays the value of d2w' x 100 on the upper right of the web element w'. The web element w' is highlighted with a bold line.
  • the proposal unit 204 displays the value of d3w' x 100 on the upper right of the web element w', The web element w' is highlighted with a bold line.
  • the test support device 10 uses operation information and bug information during testing to calculate a value called a degree of suspicion that indicates the suspicion that an operation on a web element or screen will cause a bug. do. Then, the test support device 10 according to the present embodiment proposes the Web element or screen with a high degree of suspicion to the tester as a place to be tested next. This makes it possible to efficiently detect bugs even in an exploratory test that is particularly highly individualized and even by non-skilled testers.
  • test support device 101 input device 102 display device 103 external I/F 103a recording medium 104 communication I/F 105 Processor 106 Memory Device 107 Bus 201 Web Browser 202 Information Recording Unit 203 Suspicious Degree Calculation Unit 204 Proposal Unit 205 Storage Unit

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

一実施形態に係るテスト支援装置は、Webアプリケーションに対するテストを支援するテスト支援装置であって、前記Webアプリケーションの画面上で行われた操作に関する情報と、前記Webアプリケーションのバグに関する情報とを用いて、前記画面上における操作によってバグが引き起される疑わしさを表す不審度を算出する不審度算出部と、前記不審度に基づいて、前記Webアプリケーションの画面上でテストすべき箇所を提案する提案部と、を有する。

Description

テスト支援装置、テスト支援方法、及びプログラム
 本発明は、テスト支援装置、テスト支援方法、及びプログラムに関する。
 探索的テストとは、テストを実施しながら次に行うテスト内容を考える手法である。探索的テストでは、直前のテスト結果やテストした際のソフトウェアの振る舞いに着目し、臨機応変にテスト内容を決めることで、システムの不具合が潜んでいそうな箇所に対し集中的にテストが行われる。このため、テスト設計書の作成等といった事前準備を減らすことができ、効率よくシステムの不具合を発見することができる。
 探索的テストは、テストの実施者(以下、テスターともいう。)に一定のスキルが要求されるものの、仕様が未確定なまま開発を行った場合でも、設計書や仕様書に依存することなくシステムの不具合を発見できる点が優れている。
"「探索的テスト」を活用して品質を高める", 株式会社NTTデータ, DATA INSIGHT, 2014.7.24, 技術ブログ, インターネット<URL:https://www.nttdata.com/jp/ja/data-insight/2014/072401/>
 しかしながら、探索的テストでは、テストの内容をテスターが決定するため、バグ検出能力はテスターのテストに関する知識やシステム理解度等に依存してしまうという問題がある。すなわち、探索的テストは属人性が高く、一般に、熟練したテスターでなければ効率よくバグを検出できない恐れがある。
 なお、既存の探索的テスト支援ツールはテストケースのドキュメンテーションやテスト計画の策定を支援するものであり、それらはユーザが手作業で行う必要があるため、このようなツールを利用してもテスターのバグ検出能力が向上するわけではない。
 本発明の一実施形態は、上記の点に鑑みてなされたもので、効率的なバグ検出を支援することを目的とする。
 上記目的を達成するため、一実施形態に係るテスト支援装置は、Webアプリケーションに対するテストを支援するテスト支援装置であって、前記Webアプリケーションの画面上で行われた操作に関する情報と、前記Webアプリケーションのバグに関する情報とを用いて、前記画面上における操作によってバグが引き起される疑わしさを表す不審度を算出する不審度算出部と、前記不審度に基づいて、前記Webアプリケーションの画面上でテストすべき箇所を提案する提案部と、を有する。
 効率的なバグ検出を支援することができる。
本実施形態に係るテスト支援装置のハードウェア構成の一例を示す図である。 本実施形態に係るテスト支援装置の機能構成の一例を示す図である。 本実施形態に係るテスト支援処理の一例を示すフローチャートである。 テスト箇所の提案結果の一例を示す図である。 本実施形態に係る不審度算出処理の一例を示すフローチャートである。 本実施形態に係るテスト箇所提案処理の一例を示すフローチャートである。
 以下、本発明の一実施形態について説明する。本実施形態では、特に探索的テストを対象としてWebアプリケーションをテストする際に効率的なバグ検出を支援することが可能なテスト支援装置10について説明する。
 <テスト支援手法>
 まず、本実施形態で提案するテスト支援手法について説明する。本実施形態に係るテスト支援装置10は、このテスト支援手法を処理(後述するテスト支援処理)として実行することで、効率的なバグ検出の支援を実現することができる。
 上述したように、本実施形態で提案するテスト支援手法は、PC(パーソナルコンピュータ)やモバイル端末等に搭載されたWebブラウザ上に表示されるWebアプリケーションをテスト対象とする。テスターがWebアプリケーションの各画面でテストを行う際に、以下のような情報を記録する。
 (1)テスターによって操作されたWeb要素(例えば、ボタンやセレクトボックス、入力フィールド等)を示す情報
 (2)テスターの操作内容(クリック等によるボタンやリンクの押下、クリック等によって選択された項目値、テキスト入力等によって入力された値等)とタイムスタンプ(つまり、操作日時)を示す情報
 (3)テスターによって操作が行われた画面を示す情報
 (4)テスト中に検出されたバグに関する情報
 なお、Webアプリケーションの画面は、例えば、HTML(HyperText Markup Language)等のマークアップ言語により記述される。また、Web要素は、例えば、HTML要素(又はHTMLタグ)により記述される。
 以下では、上記の(1)~(3)が含まれる情報を「操作情報」、上記の(4)を「バグ情報」ともいう。操作情報には、当該操作を行ったテスターを示す情報(例えば、ユーザID又はテスターID等)も含まれる。同様に、バグ情報には、当該バグを検出及び報告したテスターを示す情報(例えば、ユーザID又はテスターID等)も含まれる。また、バグ情報には、当該バグを検出したタイミングを示す情報(例えば、当該バグの検出直前に行われた操作に関する操作情報と当該バグの検出直後に行われた操作に関する操作情報とをそれぞれ示す情報(例えば、操作情報ID等))も含まれる。
 上記の操作情報及びバグ情報は、既知の任意の手法により記録することが可能である。例えば、操作情報ついては、Webブラウザに対する操作を監視することでその操作情報を自動で記録することが可能である。また、例えば、バグ情報については、国際公開第2020/230241号に記載されている技術を用いて記録することが可能である。
 なお、例えば、複数のテスターによってテストが行われた場合は、全員分の操作情報及びバグ情報が記録される。
 本実施形態に係るテスト支援手法では、上記の操作情報及びバグ情報を用いて、Web要素と画面に対する所定の指標値を算出した上で、これらの指標値によって定義される不審度と呼ばれる値を算出する。不審度は、本実施形態に係るテスト支援手法で導入する値であり、Web要素又は画面への操作がバグを引き起こす疑わしさを表すものである。
 そして、本実施形態に係るテスト支援手法では、不審度が高い箇所(つまり、不審度が高く、バグが検出されやすいWeb要素・画面)を強調して表示する。このように、テスターに対して次に操作すべき箇所(つまり、バグが検出されやすい箇所)が提案されるため、効率的なバグ検出が支援される。
  ≪指標値≫
 ユーザ(テスター)の集合をU、Web要素の集合をW、画面の集合をPとする。なお、U、W、Pは変数であり、ユーザがその値を指定することができる。
 操作情報及びバグ情報を用いて、Web要素に対する指標値fw1~fw5と画面に対する指標値fp1~fp8を定義する。
 ・Web要素に対する指標値
 fw1(U,W)=UがWに対して行った操作の回数
 fw2(U,W)=UがWに対して行った入力の回数
 fw3(U,W)=UがWに対して行ったユニークな入力の回数
 fw4(U,W)=UがWに対して操作を行ってから次の操作を行うまでの時間(秒)
 fw5(U,W)=Uが検出したWに関連するバグの個数
 ・画面に対する指標値
 fp1(U,P)=UがPに遷移した回数
 fp2(U,P)=UがPに対して行った画面内での操作の回数
 fp3(U,P)=UがPに対して与えた入力値セットの個数
 fp4(U,P)=UがPに対して与えたユニークな入力値セットの個数
 fp5(U,P)=UによるPでの滞在時間(秒)
 fp6(U,P)=Uが検出したPに関連するバグの個数
 fp7(P)=PのWeb要素数
 fp8(P)=Pに遷移した回数
 ここで、Web要素に関連するバグとは、当該Web要素に対する操作の直後に検出されたバグのことを指すものとする。一方で、画面に関連するバグとは、当該画面上で検出されたバグのことを指すものとする。
 また、Web要素に対する入力とは、例えば、当該Web要素がボタンやリンク、チェックボックス、セレクトボックス等である場合にはその押下や選択を指し、当該Web要素が入力フォーム等である場合にはテキストの入力等を指すものとする。また、Web要素に対するユニークな入力とは、当該Web要素に対する入力の中から重複を除いた入力を指すものとする。
 一方で、画面に対して与えた入力値セットとは、例えば、当該画面に遷移してから他の画面に遷移するまでの間に、当該画面中の全てのWeb要素に与えられた入力値(例えば、ユーザによって選択された項目値、ユーザによって入力されたテキスト等)の集合のことを指すものとする。また、画面に対して与えた入力値セットの個数とは、当該画面に対して与えた入力値セットの中から重複を除いた入力値の集合を指すものとする。
 なお、上記の指標値fw1及びfp2にはバグ報告を行うための操作(バグ報告操作)の回数も含まれるものとする。また、1度の操作や画面遷移に対して複数個のバグが検出及び報告された場合、バグ報告操作はバグと同数の回数行われたものとみなすことにする。例えば、1回の操作又は画面遷移に対してn個のバグが検出及び報告された場合、n回のバグ報告操作が行われたものとみなすことにする。これは、後述する不審度を算出する際に、不適切な値となることを防止するためである。
 上記の各指標値fw1~fw5及びfp1~fp8は、変数U、W、Pに対して具体的な値が代入されることでその値が計算される。例えば、U={u,u}、W={w,w}とした場合、fw1({u,u},{w,w})は、ユーザuがWeb要素wに対して操作を行った回数と、ユーザuがWeb要素wに対して操作を行った回数と、ユーザuがWeb要素wに対して操作を行った回数と、ユーザuがWeb要素wに対して操作を行った回数との和となる。同様に、例えば、U={u,u}、P={p,p}とした場合、fp1({u,u},{p,p})は、ユーザuが画面pに遷移した回数と、ユーザuが画面pに遷移した回数と、ユーザuが画面pに遷移した回数と、ユーザuが画面pに遷移した回数との和となる。
 このとき、u∈U、w∈Wとして、ユーザuがWeb要素wに対して行った操作の回数は、当該ユーザuの操作情報のうち、当該Web要素wに対する操作情報の個数として算出することができる。同様に、u∈U、p∈Pとして、ユーザuが画面pに遷移した回数は、当該ユーザuの操作情報のうち、当該画面pに遷移するためのWeb要素(リンク等)に対する操作情報の個数として算出することができる。
 他の指標値fw2~fw5及びfp2~fp8についても同様に、操作情報及びバグ情報から算出することができる。なお、以下では、u∈U、w∈W、p∈Pとする。
 例えば、fw2は、ユーザuの操作情報のうち、当該Web要素wに対する操作情報の個数から算出することができる。また、例えば、fw3は、ユーザuの操作情報のうち、当該Web要素wに対する操作情報で、かつ、操作内容が重複するものを除いた操作情報の個数から算出することができる。また、例えば、fw4は、ユーザuのWeb要素wに対する操作情報のタイムスタンプと、当該ユーザuが当該Web要素wに対して次に操作したときの操作情報のタイムスタンプとから算出することができる。また、例えば、fw5は、ユーザuのバグ情報のうち、Web要素wに関連するバグのバグ情報の個数から算出することができる。
 同様に、例えば、fp2は、ユーザuの操作情報のうち、画面p内のWeb要素に対する操作情報の個数から算出することができる。また、例えば、fp3は、ユーザuの操作情報のうち、次の画面に遷移するまでの間における画面p内の入力フィールドやセレクトボックス等の入力値を取るWeb要素に対する操作情報の個数から算出することができる。また、例えば、fp4は、ユーザuの操作情報のうち、次の画面に遷移するまでの間における画面p内の入力フォームやセレクトボックス等の入力値を取るWeb要素に対する操作情報で、かつ、操作内容に含まれる入力値が重複するものを除いた操作情報の個数から算出することができる。また、例えば、fp5は、ユーザuの操作情報うち、画面pに遷移するためのWeb要素に対する操作情報のタイムスタンプと画面pから他の画面に遷移するためのWeb要素に対する操作情報のタイムスタンプとから算出することができる。また、例えば、fp6は、ユーザuのバグ情報のうち、画面pに関連するバグのバグ情報の個数から算出することができる。
 また、例えば、fp7は、画面pを記述するHTML等を解析することで、その画面pに含まれるWeb要素の個数として算出することができる。また、例えば、fp8は、画面pに遷移するためのWeb要素に対する操作情報の総数として算出することができる。
  ≪不審度≫
 上記の各指標値fw1~fw5及びfp1~fp8を用いて、不審度を定義する。以下、不審度をdとする。不審度dは、形式的には、r,s∈{fw1,fw2,fw3,fw4,fw5,fp1,fp2,fp3,fp4,fp5,fp6,fp7,fp8}として、d=r/s、又は、d=1-r/sで定義される。
 ただし、不審度dは、実質的には以下の条件を全て満たす必要がある。
 条件1:0≦d≦1となるようにr及びsを選択する。
 条件2:Web要素に対する指標値と画面に対する指標値とを組み合わせて使用しない。すなわち、r又はsのいずれか一方がWeb要素に対する指標値であれば他方もWeb要素に対する指標値を用いる。同様に、r又はsのいずれか一方が画面に対する指標値であれば他方も画面に対する指標値を用いる。
 条件3:fw4とfp5は単位が時間であるため、その他の指標値と組み合わせて使用しない。すなわち、上記の条件2も考慮すれば、r又はsのいずれか一方がfw4であれば他方もfw4を用いる。同様に、r又はsのいずれか一方がfp5であれば他方もfp5を用いる。
 条件4:fp7(P)とfp8(P)はsとして用いられ、rがfpN(U',P')(ただし、N∈{1,・・・,8})であるとき、P'⊆Pが成り立つ。
 条件5:s=fwM(U,W)(ただし、M∈{1,・・・,5})、r=fwL(U',W')(ただし、L∈{1,・・・,5})のとき、(a)U=U'かつW'⊆W、又は、(b)U'⊆UかつW'=W、のいずれかが成り立つ。
 条件6:s=fpM(U,W)(ただし、M∈{1,・・・,6})、r=fpL(U',W')(ただし、L∈{1,・・・,6})のとき、(a)U=U'かつW'⊆W、又は、(b)U'⊆UかつW'=W、のいずれかが成り立つ。
 不審度が高いWeb要素や画面ほどバグが見つかる可能性が高いため、そのようなWeb要素や画面を強調して表示し、次にテストすべき箇所として提案することで、テスターは探索的テストで次にテストすべき箇所を決める際の参考にすることができる。なお、テスターは必ずしも不審度に基づく強調表示に従う必要はないことに留意されたい。
 例えば、以下のような箇所(Web要素、画面)はバグが検出されやすいと考えられる。
 ・今までバグが多く発見されている箇所
 ・テスト全体で確認された回数が少ない箇所
 ・ユニークな入力値が試された回数が少ないWeb要素
 そこで、以下では、一例として、上記の仮定に基づいて、不審度の具体例について説明する。
  (今までバグが多く発見されている箇所)
 Web要素や画面への操作がバグを引き起こす疑わしさを「バグによる不審度」と定義する。
 Web要素wのバグによる不審度d1wは、全ユーザをUallとして、以下で算出される。
 d1w=fw5(Uall,{w})/fw1(Uall,{w})=(wに関連するバグの個数)/(wに対して行われた操作の回数)
 また、画面pのバグによる不審度d1pは、以下で算出される。
 d1p=fp6(Uall,{p})/fp1(Uall,{p})=(pに関連するバグの個数)/(pに遷移した回数)
 すなわち、テストで確認された回数が少ないも関わらず多くのバグに関連していると思われるWeb要素や画面のバグによる不審度は高くなる。
  (テスト全体で確認された回数が少ない箇所)
 Web要素や画面が確認された回数が少ないことによる疑わしさを「回数による不審度」と定義する。
 Web要素wの回数による不審度d2wは、全Web要素をWallとして、以下で算出される。
 d2w=1-fw1(Uall,{w})/fw1(Uall,Wall)=1-(wに対して行われた操作の回数)/(全Web要素に対して行われた操作の回数)
 画面pの回数による不審度d2pは、全画面をPallとして、以下で算出される。
 d2p=1-fp1(Uall,{p})/fp1(Uall,Pall)=1-(pに遷移した回数)/(全画面に遷移した回数)
 すなわち、テスト全体で全てのWeb要素や画面を確認した回数に対して、該当のWeb要素や画面が確認された回数が少なければ、回数による不審度は高くなる。
  (ユニークな入力値が試された回数が少ないWeb要素)
 ここでのWeb要素は、入力フォームやセレクトボックス等の入力値を取る要素であるものとする。入力値のバリエーションが試された回数が少ないことによる疑わしさを「入力による不審度」と定義する。
 Web要素wの入力による不審度d3wは、以下で算出される。
 d3w=1-fw2(Uall,{w})/fw3(Uall,{w})=1-(wに対して行ったユニークな入力の回数)/(wに対して行った全ての入力の回数)
 すなわち、あるWeb要素に対してテストで同じ入力ばかり行っていると、そのWeb要素に対して入力による不審度は高くなる。
 <テスト支援装置10のハードウェア構成>
 次に、本実施形態に係るテスト支援装置10のハードウェア構成について、図1を参照しながら説明する。図1は、本実施形態に係るテスト支援装置10のハードウェア構成の一例を示す図である。
 図1に示すように、本実施形態に係るテスト支援装置10は一般的なコンピュータ又はコンピュータシステムのハードウェア構成で実現され、入力装置101と、表示装置102と、外部I/F103と、通信I/F104と、プロセッサ105と、メモリ装置106とを有する。これらの各ハードウェアは、それぞれがバス107により通信可能に接続される。
 入力装置101は、例えば、キーボードやマウス、タッチパネル等である。表示装置102は、例えば、ディスプレイ等である。
 外部I/F103は、記録媒体103a等の外部装置とのインタフェースである。テスト支援装置10は、外部I/F103を介して、記録媒体103aの読み取りや書き込み等を行うことができる。なお、記録媒体103aとしては、例えば、CD(Compact Disc)、DVD(Digital Versatile Disk)、SDメモリカード(Secure Digital memory card)、USB(Universal Serial Bus)メモリカード等が挙げられる。
 通信I/F104は、テスト支援装置10を通信ネットワークに接続するためのインタフェースである。プロセッサ105は、例えば、CPU(Central Processing Unit)やGPU(Graphics Processing Unit)等の各種演算装置である。メモリ装置106は、例えば、HDD(Hard Disk Drive)やSSD(Solid State Drive)、RAM(Random Access Memory)、ROM(Read Only Memory)、フラッシュメモリ等の各種記憶装置である。
 本実施形態に係るテスト支援装置10は、図1に示すハードウェア構成を有することにより、後述するテスト支援処理を実現することができる。なお、図1に示すハードウェア構成は一例であって、テスト支援装置10は、他のハードウェア構成を有していてもよい。例えば、テスト支援装置10は、複数のプロセッサ105を有していてもよいし、複数のメモリ装置106を有していてもよい。
 <テスト支援装置10の機能構成>
 次に、本実施形態に係るテスト支援装置10の機能構成について、図2を参照しながら説明する。図2は、本実施形態に係るテスト支援装置10の機能構成の一例を示す図である。
 図2に示すように、本実施形態に係るテスト支援装置10は、Webブラウザ201と、情報記録部202と、不審度算出部203と、提案部204とを有する。これら各部は、例えば、テスト支援装置10にインストールされた1以上のプログラムが、プロセッサ105等に実行させる処理により実現される。
 また、本実施形態に係るテスト支援装置10は、記憶部205を有する。記憶部205は、例えば、メモリ装置106等により実現される。なお、記憶部205は、例えば、テスト支援装置10と通信ネットワークを介して接続される記憶装置等により実現されてもよい。
 Webブラウザ201は、Webアプリケーションの画面を表示したり、当該画面に対する操作を受け付けたりするWebブラウザである。
 情報記録部202は、Webブラウザ201上に表示された画面に対する操作情報と、当該画面に対するテストのバグ情報とを収集し、これらの操作情報とバグ情報を記憶部205に保存(記録)する。なお、上述したように、操作情報及びバグ情報は、既知の任意の手法により記録することが可能である。
 不審度算出部203は、記憶部205に保存されている操作情報及びバグ情報の少なくとも1つを用いて、Web要素に対する指標値と画面に対する指標値の少なくとも一方を算出した上で、これらの指標値から不審度を算出する。
 提案部204は、不審度算出部203によって算出された不審度を用いて、不審度が高いWeb要素と、不審度が高い画面とを強調表示し、次にテストすべき箇所をユーザに提案する。
 記憶部205は、情報記録部202によって収集された操作情報とバグ情報を記憶する。
 <テスト支援処理>
 次に、本実施形態に係るテスト支援装置10が実行するテスト支援処理について、図3を参照しながら説明する。図3は、本実施形態に係るテスト支援処理の一例を示すフローチャートである。なお、以下では、情報記録部202によって操作情報及びバグ情報が記憶部205に保存(記録)されているものとする。
 不審度算出部203は、記憶部205に保存されている操作情報及びバグ情報の少なくとも1つを用いて、Web要素に対する指標値と画面に対する指標値の少なくとも一方を算出した上で、これらの指標値から不審度を算出する(ステップS101)。なお、不審度を算出する処理(不審度算出処理)の詳細については後述する。
 提案部204は、上記のステップS101で算出された不審度を用いて、不審度が高いWeb要素と、不審度が高い画面とを強調表示し、次にテストすべき箇所をユーザに提案する(ステップS102)。なお、この提案を行う処理(テスト箇所提案処理)の詳細については後述する。
 ここで、上記のステップS102における提案結果の一例について、図4を参照しながら説明する。図4は、テスト箇所の提案結果の一例を示す図である。
 以下では、上記のステップS101で各画面のバグによる不審度、各Web要素のバグによる不審度、各画面の回数による不審度、各Web要素の回数による不審度、各Web要素の入力による不審度が算出されたものとする。また、画面に関しては不審度が上位T位以内の画面を強調表示し、Web要素に関しては不審度が上位T位以内のWeb要素を強調表示するものとする。更に、強調表示は、画面に関しては不審度×100の値を画面右上に表示し、Web要素に関しては当該Web要素を太線で囲った上で不審度×100の値を右上に表示するものとする。ただし、強調表示の態様はこれに限られず、例えば、点滅させたり、矢印で指し示したりする等といった態様であってもよい。なお、T及びTは、予め決められた1以上の整数である。
 図4に示す例では、画面1000のバグによる不審度は上位T位以内であり、画面1000の右上に値「70」が表示されている。
 また、図4に示す例では、Web要素1001のバグによる不審度は上位T位以内であり、Web要素1001の右上に値「70」が表示されている。同様に、Web要素1002の入力による不審度は上位T位以内であり、Web要素1002の右上に値「74」が表示されている。同様に、Web要素1003の入力による不審度は上位T位以内であり、Web要素1003の右上に値「80」が表示されている。同様に、Web要素1004のバグによる不審度と回数による不審度は共に上位T位以内であり、Web要素1004の右上にはバグによる不審度を100倍した値「55」と回数による不審度を100倍した値「70」とが表示されている。同様に、Web要素1005の回数による不審度は上位T位以内であり、Web要素1005の右上に値「65」が表示されている。
 テスターは、図4に示すような強調表示を参考にすることで、次にテストを行う箇所(画面、Web要素)とそのテスト内容を決定することができる。
  ≪不審度算出処理≫
 次に、上記のステップS101の不審度算出処理について、図5を参照しながら説明する。図5は、本実施形態に係る不審度算出処理の一例を示すフローチャートである。以下では、一例として、各画面のバグによる不審度、各Web要素のバグによる不審度、各画面の回数による不審度、各Web要素の回数による不審度、各Web要素の入力による不審度を算出する場合について説明する。
 不審度算出部203は、各Web要素w∈Wallに関して、当該Web要素wに関連数するバグの個数と、当該Web要素wに対して行われた操作の回数と、当該Web要素wに対して行われた入力の回数と、当該Web要素wに対して行われたユニークな入力の回数とを算出する(ステップS201)。
 次に、不審度算出部203は、全Web要素に対して行われた操作の回数を算出する(ステップS202)。なお、これは、各Web要素wに対して行われた操作の回数の合計である。
 次に、不審度算出部203は、各画面p∈Pallに関して、当該画面pに関連するバグの個数と、当該画面pに遷移した回数とを算出する(ステップS203)。
 次に、不審度算出部203は、全画面に遷移した回数を算出する(ステップS204)。なお、これは、各画面pに遷移した回数の合計である。
 そして、不審度算出部203は、上記のステップS201~ステップS204における算出結果を用いて、各画面pと各Web要素wに関して、当該画面pのバグによる不審度d1p、当該Web要素wのバグによる不審度d1w、当該画面pの回数による不審度d2p、当該Web要素wの回数による不審度d2w、当該Web要素wの入力による不審度d3wを算出する(ステップS205)。
  ≪テスト箇所提案処理≫
 次に、上記のステップS102のテスト箇所提案処理について、図6を参照しながら説明する。図6は、本実施形態に係るテスト箇所提案処理の一例を示すフローチャートである。以下では、一例として、各画面pのバグによる不審度d1p、各Web要素wのバグによる不審度d1w、各画面pの回数による不審度d2p、各Web要素wの回数による不審度d2w、各Web要素wの入力による不審度d3wがそれぞれ算出された場合について説明する。
 提案部204は、各画面pのバグによる不審度d1p、各Web要素wのバグによる不審度d1w、各画面pの回数による不審度d2p、各Web要素wの回数による不審度d2w、各Web要素wの入力による不審度d3wのそれぞれを降順にソートする(ステップS301)。
 次に、提案部204は、現在テスト中の画面を特定する(ステップS302)。以下、現在のテスト中の画面をp'とする。
 次に、提案部204は、画面p'の不審度が上位T位以内である場合はその不審度により画面p'を強調して表示する(ステップS303)。
 すなわち、画面p'のバグによる不審度d1p'が上位T位以内である場合、提案部204は、d1p'×100の値を右上に表示して画面p'を強調する。また、画面p'の回数による不審度d2p'が上位T位以内である場合、提案部204は、d2p'×100の値を右上に表示して画面p'を強調する
 次に、提案部204は、画面p'内の全てのWeb要素を特定する(ステップS304)。以下では、これらのWeb要素をw'∈W'(W'は画面p'の全てのWeb要素の集合)とする。
 次に、提案部204は、Web要素w'の不審度が上位T位以内である場合はその不審度によりWeb要素w'を強調して表示する(ステップS305)。
 すなわち、Web要素w'のバグによる不審度d1w'が上位T位以内である場合、提案部204は、d1w'×100の値を当該Web要素w'の右上に表示すると共に、当該Web要素w'を太線で囲んで強調する。また、Web要素w'の回数による不審度d2w'が上位T位以内である場合、提案部204は、d2w'×100の値を当該Web要素w'の右上に表示すると共に、当該Web要素w'を太線で囲んで強調する。また、Web要素w'の入力による不審度d3w'が上位T位以内である場合、提案部204は、d3w'×100の値を当該Web要素w'の右上に表示すると共に、当該Web要素w'を太線で囲んで強調する。
 <まとめ>
 以上のように、本実施形態に係るテスト支援装置10は、テスト中の操作情報やバグ情報を用いて、Web要素又は画面に対する操作によってバグが引き起こされる疑わしさを表す不審度と呼ばれる値を算出する。そして、本実施形態に係るテスト支援装置10は、この不審度が高いWeb要素又は画面を、次にテストすべき箇所としてテスターに提案する。これにより、特に属人性が高い探索的テストであっても、また熟練のテスターでなくても、バグを効率よく検出することができることが可能となる。
 本発明は、具体的に開示された上記の実施形態に限定されるものではなく、請求の範囲の記載から逸脱することなく、種々の変形や変更、既知の技術との組み合わせ等が可能である。
 10    テスト支援装置
 101   入力装置
 102   表示装置
 103   外部I/F
 103a  記録媒体
 104   通信I/F
 105   プロセッサ
 106   メモリ装置
 107   バス
 201   Webブラウザ
 202   情報記録部
 203   不審度算出部
 204   提案部
 205   記憶部

Claims (7)

  1.  Webアプリケーションに対するテストを支援するテスト支援装置であって、
     前記Webアプリケーションの画面上で行われた操作に関する情報と、前記Webアプリケーションのバグに関する情報とを用いて、前記画面上における操作によってバグが引き起される疑わしさを表す不審度を算出する不審度算出部と、
     前記不審度に基づいて、前記Webアプリケーションの画面上でテストすべき箇所を提案する提案部と、
     を有するテスト支援装置。
  2.  前記不審度には、前記画面に対する操作によってバグが引き起こされる疑わしさを表す第1の不審度と、前記画面の構成要素に対する操作によってバグが引き起こされる疑わしさを表す第2の不審度とが含まれ、
     前記提案部は、
     前記Webアプリケーションの各画面うち、前記第1の不審度が上位所定の件数以内の画面をテストすべき箇所として提案し、
     前記画面の構成要素のうち、前記第2の不審度が上位所定の件数以内の構成要素をテストすべき箇所として提案する、請求項1に記載のテスト支援装置。
  3.  前記不審度算出部は、
     前記テストを実施したユーザが前記画面に他の画面から遷移した回数、前記ユーザが前記画面内で操作した回数、前記画面内で前記ユーザの入力操作によって入力された入力値の個数、前記画面内で前記ユーザの入力操作によって入力された入力値の中でユニークな入力値の個数、前記画面における前記ユーザの滞在時間、前記画面で前記ユーザが検出したバグの個数、前記画面の構成要素数、前記画面に他の画面から遷移した回数の合計、のうちの2つの組み合わせにより前記第1の不審度を算出し、
     前記ユーザが前記構成要素に対して行った操作の回数、前記ユーザが前記構成要素に対して行った入力操作の回数、前記ユーザが前記構成要素に対して行った入力操作の中でユニークな入力操作の回数、前記ユーザが前記構成要素に対して操作を行ってから次の操作を行うまでの時間、前記ユーザが検出したバグのうち前記構成要素に関連するバグの個数、のうちの2つの組み合わせにより前記第2の不審度を算出する、請求項2に記載のテスト支援装置。
  4.  前記第1の不審度には、
     前記画面で各ユーザによって検出されたバグの個数と、各ユーザが前記画面に他の画面から遷移した回数との比で表される不審度と、
     各ユーザが前記画面に他の画面から遷移した回数と、前記Webアプリケーションの各画面の各々から他の画面に各ユーザが遷移した回数の合計との比を1から減じた値で表される不審度と、の少なくとも1つが含まれ、
     前記第2の不審度には、
     各ユーザが検出したバグのうち前記構成要素に関連するバグの個数と、各ユーザが前記構成要素に対して行った操作の回数との比で表される不審度と、
     各ユーザが前記構成要素に対して行った操作の回数と、前記Webアプリケーションの各画面の構成要素の各々に対して各ユーザが行った操作の回数の合計との比を1から減じた値で表される不審度と、
     前記構成要素に対して各ユーザが行ったユニークな入力操作の回数と、前記構成要素に対して各ユーザが行った全ての入力操作の回数との比を1から減じた値で表される不審度と、の少なくとも1つが含まれる、請求項2又は3に記載のテスト支援装置。
  5.  前記提案部は、
     前記第1の不審度が上位所定の件数以内の画面に対して、前記第1の不審度に基づく値を付与して強調表示することで前記テストすべき箇所として提案し、
     前記第2の不審度が上位所定の件数以内の構成要素に対して、前記第2の不審度に基づく値を付与して強調表示することで前記テストすべき箇所として提案する、請求項2乃至4の何れか一項に記載のテスト支援装置。
  6.  Webアプリケーションに対するテストを支援するコンピュータが、
     前記Webアプリケーションの画面上で行われた操作に関する情報と、前記Webアプリケーションのバグに関する情報とを用いて、前記画面上における操作によってバグが引き起される疑わしさを表す不審度を算出する不審度算出手順と、
     前記不審度に基づいて、前記Webアプリケーションの画面上でテストすべき箇所を提案する提案手順と、
     を実行するテスト支援方法。
  7.  コンピュータを、請求項1乃至5の何れか一項に記載のテスト支援装置として機能させるプログラム。
PCT/JP2021/017247 2021-04-30 2021-04-30 テスト支援装置、テスト支援方法、及びプログラム WO2022230189A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/017247 WO2022230189A1 (ja) 2021-04-30 2021-04-30 テスト支援装置、テスト支援方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/017247 WO2022230189A1 (ja) 2021-04-30 2021-04-30 テスト支援装置、テスト支援方法、及びプログラム

Publications (1)

Publication Number Publication Date
WO2022230189A1 true WO2022230189A1 (ja) 2022-11-03

Family

ID=83848167

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/017247 WO2022230189A1 (ja) 2021-04-30 2021-04-30 テスト支援装置、テスト支援方法、及びプログラム

Country Status (1)

Country Link
WO (1) WO2022230189A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013125420A (ja) * 2011-12-14 2013-06-24 Shift Inc コンピュータプログラムのテスト仕様を生成するための装置およびプログラム
JP2014026579A (ja) * 2012-07-30 2014-02-06 Nippon Telegr & Teleph Corp <Ntt> バグ検出装置およびバグ検出方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013125420A (ja) * 2011-12-14 2013-06-24 Shift Inc コンピュータプログラムのテスト仕様を生成するための装置およびプログラム
JP2014026579A (ja) * 2012-07-30 2014-02-06 Nippon Telegr & Teleph Corp <Ntt> バグ検出装置およびバグ検出方法

Similar Documents

Publication Publication Date Title
US9164870B2 (en) Integrated fuzzing
US9213625B1 (en) Method and apparatus for performing automated user-interface layout testing
JP4140916B2 (ja) Webページにおける状態遷移を解析する方法
US7827486B2 (en) Evaluation of visual content usage
US8418149B2 (en) Differential comparison system and method
US20090031227A1 (en) Intelligent screen capture and interactive display tool
US8135572B2 (en) Integrated debugger simulator
US8621613B1 (en) Detecting malware in content items
US20130159326A1 (en) Solution monitoring system
JP4023803B2 (ja) ウェブアプリケーション開発支援装置、データ処理方法及びプログラム
US8607197B2 (en) Displaying HTTP session entry and exit points
Walsh et al. Automatically identifying potential regressions in the layout of responsive web pages
US20160261623A1 (en) Detecting Malware In Content Items
EP3635563B1 (en) Application analysis with flexible post-processing
Mao et al. User behavior pattern mining and reuse across similar Android apps
US20090064102A1 (en) Method and system for navigationally displaying http session entry and exit points
Huber et al. Analysing the performance of mobile cross-platform development approaches using ui interaction scenarios
WO2020209227A1 (ja) 解析装置、解析方法、及びプログラム
Insfran et al. Evaluating the usability of mashups applications
WO2022230189A1 (ja) テスト支援装置、テスト支援方法、及びプログラム
Wang et al. JSTrace: Fast reproducing web application errors
Anand et al. Software reliability modeling with impact of beta testing on release decision
US20100251211A1 (en) Generating and using code-based diagrams
JP7116313B2 (ja) 修正候補特定プログラム
JP5319643B2 (ja) ソフトウェアプロダクトライン開発支援装置およびその方法

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18555629

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21939346

Country of ref document: EP

Kind code of ref document: A1