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

    • 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 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

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

Description

テスト支援装置、テスト支援方法、及びプログラム
　本発明は、テスト支援装置、テスト支援方法、及びプログラムに関する。
　探索的テストとは、テストを実施しながら次に行うテスト内容を考える手法である。探索的テストでは、直前のテスト結果やテストした際のソフトウェアの振る舞いに着目し、臨機応変にテスト内容を決めることで、システムの不具合が潜んでいそうな箇所に対し集中的にテストが行われる。このため、テスト設計書の作成等といった事前準備を減らすことができ、効率よくシステムの不具合を発見することができる。
　探索的テストは、テストの実施者（以下、テスターともいう。）に一定のスキルが要求されるものの、仕様が未確定なまま開発を行った場合でも、設計書や仕様書に依存することなくシステムの不具合を発見できる点が優れている。
"「探索的テスト」を活用して品質を高める", 株式会社NTTデータ, DATA INSIGHT, 2014.7.24, 技術ブログ, インターネット＜ＵＲＬ：https://www.nttdata.com/jp/ja/data-insight/2014/072401/＞
　しかしながら、探索的テストでは、テストの内容をテスターが決定するため、バグ検出能力はテスターのテストに関する知識やシステム理解度等に依存してしまうという問題がある。すなわち、探索的テストは属人性が高く、一般に、熟練したテスターでなければ効率よくバグを検出できない恐れがある。
　なお、既存の探索的テスト支援ツールはテストケースのドキュメンテーションやテスト計画の策定を支援するものであり、それらはユーザが手作業で行う必要があるため、このようなツールを利用してもテスターのバグ検出能力が向上するわけではない。
　本発明の一実施形態は、上記の点に鑑みてなされたもので、効率的なバグ検出を支援することを目的とする。
　上記目的を達成するため、一実施形態に係るテスト支援装置は、Ｗｅｂアプリケーションに対するテストを支援するテスト支援装置であって、前記Ｗｅｂアプリケーションの画面上で行われた操作に関する情報と、前記Ｗｅｂアプリケーションのバグに関する情報とを用いて、前記画面上における操作によってバグが引き起される疑わしさを表す不審度を算出する不審度算出部と、前記不審度に基づいて、前記Ｗｅｂアプリケーションの画面上でテストすべき箇所を提案する提案部と、を有する。
　効率的なバグ検出を支援することができる。
本実施形態に係るテスト支援装置のハードウェア構成の一例を示す図である。 本実施形態に係るテスト支援装置の機能構成の一例を示す図である。 本実施形態に係るテスト支援処理の一例を示すフローチャートである。 テスト箇所の提案結果の一例を示す図である。 本実施形態に係る不審度算出処理の一例を示すフローチャートである。 本実施形態に係るテスト箇所提案処理の一例を示すフローチャートである。
　以下、本発明の一実施形態について説明する。本実施形態では、特に探索的テストを対象としてＷｅｂアプリケーションをテストする際に効率的なバグ検出を支援することが可能なテスト支援装置１０について説明する。
　＜テスト支援手法＞
　まず、本実施形態で提案するテスト支援手法について説明する。本実施形態に係るテスト支援装置１０は、このテスト支援手法を処理（後述するテスト支援処理）として実行することで、効率的なバグ検出の支援を実現することができる。
　上述したように、本実施形態で提案するテスト支援手法は、ＰＣ（パーソナルコンピュータ）やモバイル端末等に搭載されたＷｅｂブラウザ上に表示されるＷｅｂアプリケーションをテスト対象とする。テスターがＷｅｂアプリケーションの各画面でテストを行う際に、以下のような情報を記録する。
　（１）テスターによって操作されたＷｅｂ要素（例えば、ボタンやセレクトボックス、入力フィールド等）を示す情報
　（２）テスターの操作内容（クリック等によるボタンやリンクの押下、クリック等によって選択された項目値、テキスト入力等によって入力された値等）とタイムスタンプ（つまり、操作日時）を示す情報
　（３）テスターによって操作が行われた画面を示す情報
　（４）テスト中に検出されたバグに関する情報
　なお、Ｗｅｂアプリケーションの画面は、例えば、ＨＴＭＬ（HyperText Markup Language）等のマークアップ言語により記述される。また、Ｗｅｂ要素は、例えば、ＨＴＭＬ要素（又はＨＴＭＬタグ）により記述される。
　以下では、上記の（１）～（３）が含まれる情報を「操作情報」、上記の（４）を「バグ情報」ともいう。操作情報には、当該操作を行ったテスターを示す情報（例えば、ユーザＩＤ又はテスターＩＤ等）も含まれる。同様に、バグ情報には、当該バグを検出及び報告したテスターを示す情報（例えば、ユーザＩＤ又はテスターＩＤ等）も含まれる。また、バグ情報には、当該バグを検出したタイミングを示す情報（例えば、当該バグの検出直前に行われた操作に関する操作情報と当該バグの検出直後に行われた操作に関する操作情報とをそれぞれ示す情報（例えば、操作情報ＩＤ等））も含まれる。
　上記の操作情報及びバグ情報は、既知の任意の手法により記録することが可能である。例えば、操作情報ついては、Ｗｅｂブラウザに対する操作を監視することでその操作情報を自動で記録することが可能である。また、例えば、バグ情報については、国際公開第２０２０／２３０２４１号に記載されている技術を用いて記録することが可能である。
　なお、例えば、複数のテスターによってテストが行われた場合は、全員分の操作情報及びバグ情報が記録される。
　本実施形態に係るテスト支援手法では、上記の操作情報及びバグ情報を用いて、Ｗｅｂ要素と画面に対する所定の指標値を算出した上で、これらの指標値によって定義される不審度と呼ばれる値を算出する。不審度は、本実施形態に係るテスト支援手法で導入する値であり、Ｗｅｂ要素又は画面への操作がバグを引き起こす疑わしさを表すものである。
　そして、本実施形態に係るテスト支援手法では、不審度が高い箇所（つまり、不審度が高く、バグが検出されやすいＷｅｂ要素・画面）を強調して表示する。このように、テスターに対して次に操作すべき箇所（つまり、バグが検出されやすい箇所）が提案されるため、効率的なバグ検出が支援される。
　　≪指標値≫
　ユーザ（テスター）の集合をＵ、Ｗｅｂ要素の集合をＷ、画面の集合をＰとする。なお、Ｕ、Ｗ、Ｐは変数であり、ユーザがその値を指定することができる。
　操作情報及びバグ情報を用いて、Ｗｅｂ要素に対する指標値ｆｗ１～ｆｗ５と画面に対する指標値ｆｐ１～ｆｐ８を定義する。
　・Ｗｅｂ要素に対する指標値
　ｆｗ１（Ｕ，Ｗ）＝ＵがＷに対して行った操作の回数
　ｆｗ２（Ｕ，Ｗ）＝ＵがＷに対して行った入力の回数
　ｆｗ３（Ｕ，Ｗ）＝ＵがＷに対して行ったユニークな入力の回数
　ｆｗ４（Ｕ，Ｗ）＝ＵがＷに対して操作を行ってから次の操作を行うまでの時間（秒）
　ｆｗ５（Ｕ，Ｗ）＝Ｕが検出したＷに関連するバグの個数
　・画面に対する指標値
　ｆｐ１（Ｕ，Ｐ）＝ＵがＰに遷移した回数
　ｆｐ２（Ｕ，Ｐ）＝ＵがＰに対して行った画面内での操作の回数
　ｆｐ３（Ｕ，Ｐ）＝ＵがＰに対して与えた入力値セットの個数
　ｆｐ４（Ｕ，Ｐ）＝ＵがＰに対して与えたユニークな入力値セットの個数
　ｆｐ５（Ｕ，Ｐ）＝ＵによるＰでの滞在時間（秒）
　ｆｐ６（Ｕ，Ｐ）＝Ｕが検出したＰに関連するバグの個数
　ｆｐ７（Ｐ）＝ＰのＷｅｂ要素数
　ｆｐ８（Ｐ）＝Ｐに遷移した回数
　ここで、Ｗｅｂ要素に関連するバグとは、当該Ｗｅｂ要素に対する操作の直後に検出されたバグのことを指すものとする。一方で、画面に関連するバグとは、当該画面上で検出されたバグのことを指すものとする。
　また、Ｗｅｂ要素に対する入力とは、例えば、当該Ｗｅｂ要素がボタンやリンク、チェックボックス、セレクトボックス等である場合にはその押下や選択を指し、当該Ｗｅｂ要素が入力フォーム等である場合にはテキストの入力等を指すものとする。また、Ｗｅｂ要素に対するユニークな入力とは、当該Ｗｅｂ要素に対する入力の中から重複を除いた入力を指すものとする。
　一方で、画面に対して与えた入力値セットとは、例えば、当該画面に遷移してから他の画面に遷移するまでの間に、当該画面中の全てのＷｅｂ要素に与えられた入力値（例えば、ユーザによって選択された項目値、ユーザによって入力されたテキスト等）の集合のことを指すものとする。また、画面に対して与えた入力値セットの個数とは、当該画面に対して与えた入力値セットの中から重複を除いた入力値の集合を指すものとする。
　なお、上記の指標値ｆｗ１及びｆｐ２にはバグ報告を行うための操作（バグ報告操作）の回数も含まれるものとする。また、１度の操作や画面遷移に対して複数個のバグが検出及び報告された場合、バグ報告操作はバグと同数の回数行われたものとみなすことにする。例えば、１回の操作又は画面遷移に対してｎ個のバグが検出及び報告された場合、ｎ回のバグ報告操作が行われたものとみなすことにする。これは、後述する不審度を算出する際に、不適切な値となることを防止するためである。
　上記の各指標値ｆｗ１～ｆｗ５及びｆｐ１～ｆｐ８は、変数Ｕ、Ｗ、Ｐに対して具体的な値が代入されることでその値が計算される。例えば、Ｕ＝｛ｕ１，ｕ２｝、Ｗ＝｛ｗ１，ｗ２｝とした場合、ｆｗ１（｛ｕ１，ｕ２｝，｛ｗ１，ｗ２｝）は、ユーザｕ１がＷｅｂ要素ｗ１に対して操作を行った回数と、ユーザｕ１がＷｅｂ要素ｗ２に対して操作を行った回数と、ユーザｕ２がＷｅｂ要素ｗ１に対して操作を行った回数と、ユーザｕ２がＷｅｂ要素ｗ２に対して操作を行った回数との和となる。同様に、例えば、Ｕ＝｛ｕ１，ｕ２｝、Ｐ＝｛ｐ１，ｐ２｝とした場合、ｆｐ１（｛ｕ１，ｕ２｝，｛ｐ１，ｐ２｝）は、ユーザｕ１が画面ｐ１に遷移した回数と、ユーザｕ１が画面ｐ２に遷移した回数と、ユーザｕ２が画面ｐ１に遷移した回数と、ユーザｕ２が画面ｐ２に遷移した回数との和となる。
　このとき、ｕ∈Ｕ、ｗ∈Ｗとして、ユーザｕがＷｅｂ要素ｗに対して行った操作の回数は、当該ユーザｕの操作情報のうち、当該Ｗｅｂ要素ｗに対する操作情報の個数として算出することができる。同様に、ｕ∈Ｕ、ｐ∈Ｐとして、ユーザｕが画面ｐに遷移した回数は、当該ユーザｕの操作情報のうち、当該画面ｐに遷移するためのＷｅｂ要素（リンク等）に対する操作情報の個数として算出することができる。
　他の指標値ｆｗ２～ｆｗ５及びｆｐ２～ｆｐ８についても同様に、操作情報及びバグ情報から算出することができる。なお、以下では、ｕ∈Ｕ、ｗ∈Ｗ、ｐ∈Ｐとする。
　例えば、ｆｗ２は、ユーザｕの操作情報のうち、当該Ｗｅｂ要素ｗに対する操作情報の個数から算出することができる。また、例えば、ｆｗ３は、ユーザｕの操作情報のうち、当該Ｗｅｂ要素ｗに対する操作情報で、かつ、操作内容が重複するものを除いた操作情報の個数から算出することができる。また、例えば、ｆｗ４は、ユーザｕのＷｅｂ要素ｗに対する操作情報のタイムスタンプと、当該ユーザｕが当該Ｗｅｂ要素ｗに対して次に操作したときの操作情報のタイムスタンプとから算出することができる。また、例えば、ｆｗ５は、ユーザｕのバグ情報のうち、Ｗｅｂ要素ｗに関連するバグのバグ情報の個数から算出することができる。
　同様に、例えば、ｆｐ２は、ユーザｕの操作情報のうち、画面ｐ内のＷｅｂ要素に対する操作情報の個数から算出することができる。また、例えば、ｆｐ３は、ユーザｕの操作情報のうち、次の画面に遷移するまでの間における画面ｐ内の入力フィールドやセレクトボックス等の入力値を取るＷｅｂ要素に対する操作情報の個数から算出することができる。また、例えば、ｆｐ４は、ユーザｕの操作情報のうち、次の画面に遷移するまでの間における画面ｐ内の入力フォームやセレクトボックス等の入力値を取るＷｅｂ要素に対する操作情報で、かつ、操作内容に含まれる入力値が重複するものを除いた操作情報の個数から算出することができる。また、例えば、ｆｐ５は、ユーザｕの操作情報うち、画面ｐに遷移するためのＷｅｂ要素に対する操作情報のタイムスタンプと画面ｐから他の画面に遷移するためのＷｅｂ要素に対する操作情報のタイムスタンプとから算出することができる。また、例えば、ｆｐ６は、ユーザｕのバグ情報のうち、画面ｐに関連するバグのバグ情報の個数から算出することができる。
　また、例えば、ｆｐ７は、画面ｐを記述するＨＴＭＬ等を解析することで、その画面ｐに含まれるＷｅｂ要素の個数として算出することができる。また、例えば、ｆｐ８は、画面ｐに遷移するためのＷｅｂ要素に対する操作情報の総数として算出することができる。
　　≪不審度≫
　上記の各指標値ｆｗ１～ｆｗ５及びｆｐ１～ｆｐ８を用いて、不審度を定義する。以下、不審度をｄとする。不審度ｄは、形式的には、ｒ，ｓ∈｛ｆｗ１，ｆｗ２，ｆｗ３，ｆｗ４，ｆｗ５，ｆｐ１，ｆｐ２，ｆｐ３，ｆｐ４，ｆｐ５，ｆｐ６，ｆｐ７，ｆｐ８｝として、ｄ＝ｒ／ｓ、又は、ｄ＝１－ｒ／ｓで定義される。
　ただし、不審度ｄは、実質的には以下の条件を全て満たす必要がある。
　条件１：０≦ｄ≦１となるようにｒ及びｓを選択する。
　条件２：Ｗｅｂ要素に対する指標値と画面に対する指標値とを組み合わせて使用しない。すなわち、ｒ又はｓのいずれか一方がＷｅｂ要素に対する指標値であれば他方もＷｅｂ要素に対する指標値を用いる。同様に、ｒ又はｓのいずれか一方が画面に対する指標値であれば他方も画面に対する指標値を用いる。
　条件３：ｆｗ４とｆｐ５は単位が時間であるため、その他の指標値と組み合わせて使用しない。すなわち、上記の条件２も考慮すれば、ｒ又はｓのいずれか一方がｆｗ４であれば他方もｆｗ４を用いる。同様に、ｒ又はｓのいずれか一方がｆｐ５であれば他方もｆｐ５を用いる。
　条件４：ｆｐ７（Ｐ）とｆｐ８（Ｐ）はｓとして用いられ、ｒがｆｐＮ（Ｕ'，Ｐ'）（ただし、Ｎ∈｛１，・・・，８｝）であるとき、Ｐ'⊆Ｐが成り立つ。
　条件５：ｓ＝ｆｗＭ（Ｕ，Ｗ）（ただし、Ｍ∈｛１，・・・，５｝）、ｒ＝ｆｗＬ（Ｕ'，Ｗ'）（ただし、Ｌ∈｛１，・・・，５｝）のとき、（ａ）Ｕ＝Ｕ'かつＷ'⊆Ｗ、又は、（ｂ）Ｕ'⊆ＵかつＷ'＝Ｗ、のいずれかが成り立つ。
　条件６：ｓ＝ｆｐＭ（Ｕ，Ｗ）（ただし、Ｍ∈｛１，・・・，６｝）、ｒ＝ｆｐＬ（Ｕ'，Ｗ'）（ただし、Ｌ∈｛１，・・・，６｝）のとき、（ａ）Ｕ＝Ｕ'かつＷ'⊆Ｗ、又は、（ｂ）Ｕ'⊆ＵかつＷ'＝Ｗ、のいずれかが成り立つ。
　不審度が高いＷｅｂ要素や画面ほどバグが見つかる可能性が高いため、そのようなＷｅｂ要素や画面を強調して表示し、次にテストすべき箇所として提案することで、テスターは探索的テストで次にテストすべき箇所を決める際の参考にすることができる。なお、テスターは必ずしも不審度に基づく強調表示に従う必要はないことに留意されたい。
　例えば、以下のような箇所（Ｗｅｂ要素、画面）はバグが検出されやすいと考えられる。
　・今までバグが多く発見されている箇所
　・テスト全体で確認された回数が少ない箇所
　・ユニークな入力値が試された回数が少ないＷｅｂ要素
　そこで、以下では、一例として、上記の仮定に基づいて、不審度の具体例について説明する。
　　（今までバグが多く発見されている箇所）
　Ｗｅｂ要素や画面への操作がバグを引き起こす疑わしさを「バグによる不審度」と定義する。
　Ｗｅｂ要素ｗのバグによる不審度ｄ１ｗは、全ユーザをＵａｌｌとして、以下で算出される。
　ｄ１ｗ＝ｆｗ５（Ｕａｌｌ，｛ｗ｝）／ｆｗ１（Ｕａｌｌ，｛ｗ｝）＝（ｗに関連するバグの個数）／（ｗに対して行われた操作の回数）
　また、画面ｐのバグによる不審度ｄ１ｐは、以下で算出される。
　ｄ１ｐ＝ｆｐ６（Ｕａｌｌ，｛ｐ｝）／ｆｐ１（Ｕａｌｌ，｛ｐ｝）＝（ｐに関連するバグの個数）／（ｐに遷移した回数）
　すなわち、テストで確認された回数が少ないも関わらず多くのバグに関連していると思われるＷｅｂ要素や画面のバグによる不審度は高くなる。
　　（テスト全体で確認された回数が少ない箇所）
　Ｗｅｂ要素や画面が確認された回数が少ないことによる疑わしさを「回数による不審度」と定義する。
　Ｗｅｂ要素ｗの回数による不審度ｄ２ｗは、全Ｗｅｂ要素をＷａｌｌとして、以下で算出される。
　ｄ２ｗ＝１－ｆｗ１（Ｕａｌｌ，｛ｗ｝）／ｆｗ１（Ｕａｌｌ，Ｗａｌｌ）＝１－（ｗに対して行われた操作の回数）／（全Ｗｅｂ要素に対して行われた操作の回数）
　画面ｐの回数による不審度ｄ２ｐは、全画面をＰａｌｌとして、以下で算出される。
　ｄ２ｐ＝１－ｆｐ１（Ｕａｌｌ，｛ｐ｝）／ｆｐ１（Ｕａｌｌ，Ｐａｌｌ）＝１－（ｐに遷移した回数）／（全画面に遷移した回数）
　すなわち、テスト全体で全てのＷｅｂ要素や画面を確認した回数に対して、該当のＷｅｂ要素や画面が確認された回数が少なければ、回数による不審度は高くなる。
　　（ユニークな入力値が試された回数が少ないＷｅｂ要素）
　ここでのＷｅｂ要素は、入力フォームやセレクトボックス等の入力値を取る要素であるものとする。入力値のバリエーションが試された回数が少ないことによる疑わしさを「入力による不審度」と定義する。
　Ｗｅｂ要素ｗの入力による不審度ｄ３ｗは、以下で算出される。
　ｄ３ｗ＝１－ｆｗ２（Ｕａｌｌ，｛ｗ｝）／ｆｗ３（Ｕａｌｌ，｛ｗ｝）＝１－（ｗに対して行ったユニークな入力の回数）／（ｗに対して行った全ての入力の回数）
　すなわち、あるＷｅｂ要素に対してテストで同じ入力ばかり行っていると、そのＷｅｂ要素に対して入力による不審度は高くなる。
　＜テスト支援装置１０のハードウェア構成＞
　次に、本実施形態に係るテスト支援装置１０のハードウェア構成について、図１を参照しながら説明する。図１は、本実施形態に係るテスト支援装置１０のハードウェア構成の一例を示す図である。
　図１に示すように、本実施形態に係るテスト支援装置１０は一般的なコンピュータ又はコンピュータシステムのハードウェア構成で実現され、入力装置１０１と、表示装置１０２と、外部Ｉ／Ｆ１０３と、通信Ｉ／Ｆ１０４と、プロセッサ１０５と、メモリ装置１０６とを有する。これらの各ハードウェアは、それぞれがバス１０７により通信可能に接続される。
　入力装置１０１は、例えば、キーボードやマウス、タッチパネル等である。表示装置１０２は、例えば、ディスプレイ等である。
　外部Ｉ／Ｆ１０３は、記録媒体１０３ａ等の外部装置とのインタフェースである。テスト支援装置１０は、外部Ｉ／Ｆ１０３を介して、記録媒体１０３ａの読み取りや書き込み等を行うことができる。なお、記録媒体１０３ａとしては、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（Secure Digital memory card）、ＵＳＢ（Universal Serial Bus）メモリカード等が挙げられる。
　通信Ｉ／Ｆ１０４は、テスト支援装置１０を通信ネットワークに接続するためのインタフェースである。プロセッサ１０５は、例えば、ＣＰＵ（Central Processing Unit）やＧＰＵ（Graphics Processing Unit）等の各種演算装置である。メモリ装置１０６は、例えば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ等の各種記憶装置である。
　本実施形態に係るテスト支援装置１０は、図１に示すハードウェア構成を有することにより、後述するテスト支援処理を実現することができる。なお、図１に示すハードウェア構成は一例であって、テスト支援装置１０は、他のハードウェア構成を有していてもよい。例えば、テスト支援装置１０は、複数のプロセッサ１０５を有していてもよいし、複数のメモリ装置１０６を有していてもよい。
　＜テスト支援装置１０の機能構成＞
　次に、本実施形態に係るテスト支援装置１０の機能構成について、図２を参照しながら説明する。図２は、本実施形態に係るテスト支援装置１０の機能構成の一例を示す図である。
　図２に示すように、本実施形態に係るテスト支援装置１０は、Ｗｅｂブラウザ２０１と、情報記録部２０２と、不審度算出部２０３と、提案部２０４とを有する。これら各部は、例えば、テスト支援装置１０にインストールされた１以上のプログラムが、プロセッサ１０５等に実行させる処理により実現される。
　また、本実施形態に係るテスト支援装置１０は、記憶部２０５を有する。記憶部２０５は、例えば、メモリ装置１０６等により実現される。なお、記憶部２０５は、例えば、テスト支援装置１０と通信ネットワークを介して接続される記憶装置等により実現されてもよい。
　Ｗｅｂブラウザ２０１は、Ｗｅｂアプリケーションの画面を表示したり、当該画面に対する操作を受け付けたりするＷｅｂブラウザである。
　情報記録部２０２は、Ｗｅｂブラウザ２０１上に表示された画面に対する操作情報と、当該画面に対するテストのバグ情報とを収集し、これらの操作情報とバグ情報を記憶部２０５に保存（記録）する。なお、上述したように、操作情報及びバグ情報は、既知の任意の手法により記録することが可能である。
　不審度算出部２０３は、記憶部２０５に保存されている操作情報及びバグ情報の少なくとも１つを用いて、Ｗｅｂ要素に対する指標値と画面に対する指標値の少なくとも一方を算出した上で、これらの指標値から不審度を算出する。
　提案部２０４は、不審度算出部２０３によって算出された不審度を用いて、不審度が高いＷｅｂ要素と、不審度が高い画面とを強調表示し、次にテストすべき箇所をユーザに提案する。
　記憶部２０５は、情報記録部２０２によって収集された操作情報とバグ情報を記憶する。
　＜テスト支援処理＞
　次に、本実施形態に係るテスト支援装置１０が実行するテスト支援処理について、図３を参照しながら説明する。図３は、本実施形態に係るテスト支援処理の一例を示すフローチャートである。なお、以下では、情報記録部２０２によって操作情報及びバグ情報が記憶部２０５に保存（記録）されているものとする。
　不審度算出部２０３は、記憶部２０５に保存されている操作情報及びバグ情報の少なくとも１つを用いて、Ｗｅｂ要素に対する指標値と画面に対する指標値の少なくとも一方を算出した上で、これらの指標値から不審度を算出する（ステップＳ１０１）。なお、不審度を算出する処理（不審度算出処理）の詳細については後述する。
　提案部２０４は、上記のステップＳ１０１で算出された不審度を用いて、不審度が高いＷｅｂ要素と、不審度が高い画面とを強調表示し、次にテストすべき箇所をユーザに提案する（ステップＳ１０２）。なお、この提案を行う処理（テスト箇所提案処理）の詳細については後述する。
　ここで、上記のステップＳ１０２における提案結果の一例について、図４を参照しながら説明する。図４は、テスト箇所の提案結果の一例を示す図である。
　以下では、上記のステップＳ１０１で各画面のバグによる不審度、各Ｗｅｂ要素のバグによる不審度、各画面の回数による不審度、各Ｗｅｂ要素の回数による不審度、各Ｗｅｂ要素の入力による不審度が算出されたものとする。また、画面に関しては不審度が上位ＴＰ位以内の画面を強調表示し、Ｗｅｂ要素に関しては不審度が上位ＴＷ位以内のＷｅｂ要素を強調表示するものとする。更に、強調表示は、画面に関しては不審度×１００の値を画面右上に表示し、Ｗｅｂ要素に関しては当該Ｗｅｂ要素を太線で囲った上で不審度×１００の値を右上に表示するものとする。ただし、強調表示の態様はこれに限られず、例えば、点滅させたり、矢印で指し示したりする等といった態様であってもよい。なお、ＴＰ及びＴＷは、予め決められた１以上の整数である。
　図４に示す例では、画面１０００のバグによる不審度は上位ＴＰ位以内であり、画面１０００の右上に値「７０」が表示されている。
　また、図４に示す例では、Ｗｅｂ要素１００１のバグによる不審度は上位ＴＷ位以内であり、Ｗｅｂ要素１００１の右上に値「７０」が表示されている。同様に、Ｗｅｂ要素１００２の入力による不審度は上位ＴＷ位以内であり、Ｗｅｂ要素１００２の右上に値「７４」が表示されている。同様に、Ｗｅｂ要素１００３の入力による不審度は上位ＴＷ位以内であり、Ｗｅｂ要素１００３の右上に値「８０」が表示されている。同様に、Ｗｅｂ要素１００４のバグによる不審度と回数による不審度は共に上位ＴＷ位以内であり、Ｗｅｂ要素１００４の右上にはバグによる不審度を１００倍した値「５５」と回数による不審度を１００倍した値「７０」とが表示されている。同様に、Ｗｅｂ要素１００５の回数による不審度は上位ＴＷ位以内であり、Ｗｅｂ要素１００５の右上に値「６５」が表示されている。
　テスターは、図４に示すような強調表示を参考にすることで、次にテストを行う箇所（画面、Ｗｅｂ要素）とそのテスト内容を決定することができる。
　　≪不審度算出処理≫
　次に、上記のステップＳ１０１の不審度算出処理について、図５を参照しながら説明する。図５は、本実施形態に係る不審度算出処理の一例を示すフローチャートである。以下では、一例として、各画面のバグによる不審度、各Ｗｅｂ要素のバグによる不審度、各画面の回数による不審度、各Ｗｅｂ要素の回数による不審度、各Ｗｅｂ要素の入力による不審度を算出する場合について説明する。
　不審度算出部２０３は、各Ｗｅｂ要素ｗ∈Ｗａｌｌに関して、当該Ｗｅｂ要素ｗに関連数するバグの個数と、当該Ｗｅｂ要素ｗに対して行われた操作の回数と、当該Ｗｅｂ要素ｗに対して行われた入力の回数と、当該Ｗｅｂ要素ｗに対して行われたユニークな入力の回数とを算出する（ステップＳ２０１）。
　次に、不審度算出部２０３は、全Ｗｅｂ要素に対して行われた操作の回数を算出する（ステップＳ２０２）。なお、これは、各Ｗｅｂ要素ｗに対して行われた操作の回数の合計である。
　次に、不審度算出部２０３は、各画面ｐ∈Ｐａｌｌに関して、当該画面ｐに関連するバグの個数と、当該画面ｐに遷移した回数とを算出する（ステップＳ２０３）。
　次に、不審度算出部２０３は、全画面に遷移した回数を算出する（ステップＳ２０４）。なお、これは、各画面ｐに遷移した回数の合計である。
　そして、不審度算出部２０３は、上記のステップＳ２０１～ステップＳ２０４における算出結果を用いて、各画面ｐと各Ｗｅｂ要素ｗに関して、当該画面ｐのバグによる不審度ｄ１ｐ、当該Ｗｅｂ要素ｗのバグによる不審度ｄ１ｗ、当該画面ｐの回数による不審度ｄ２ｐ、当該Ｗｅｂ要素ｗの回数による不審度ｄ２ｗ、当該Ｗｅｂ要素ｗの入力による不審度ｄ３ｗを算出する（ステップＳ２０５）。
　　≪テスト箇所提案処理≫
　次に、上記のステップＳ１０２のテスト箇所提案処理について、図６を参照しながら説明する。図６は、本実施形態に係るテスト箇所提案処理の一例を示すフローチャートである。以下では、一例として、各画面ｐのバグによる不審度ｄ１ｐ、各Ｗｅｂ要素ｗのバグによる不審度ｄ１ｗ、各画面ｐの回数による不審度ｄ２ｐ、各Ｗｅｂ要素ｗの回数による不審度ｄ２ｗ、各Ｗｅｂ要素ｗの入力による不審度ｄ３ｗがそれぞれ算出された場合について説明する。
　提案部２０４は、各画面ｐのバグによる不審度ｄ１ｐ、各Ｗｅｂ要素ｗのバグによる不審度ｄ１ｗ、各画面ｐの回数による不審度ｄ２ｐ、各Ｗｅｂ要素ｗの回数による不審度ｄ２ｗ、各Ｗｅｂ要素ｗの入力による不審度ｄ３ｗのそれぞれを降順にソートする（ステップＳ３０１）。
　次に、提案部２０４は、現在テスト中の画面を特定する（ステップＳ３０２）。以下、現在のテスト中の画面をｐ'とする。
　次に、提案部２０４は、画面ｐ'の不審度が上位ＴＰ位以内である場合はその不審度により画面ｐ'を強調して表示する（ステップＳ３０３）。
　すなわち、画面ｐ'のバグによる不審度ｄ１ｐ'が上位ＴＰ位以内である場合、提案部２０４は、ｄ１ｐ'×１００の値を右上に表示して画面ｐ'を強調する。また、画面ｐ'の回数による不審度ｄ２ｐ'が上位ＴＰ位以内である場合、提案部２０４は、ｄ２ｐ'×１００の値を右上に表示して画面ｐ'を強調する
　次に、提案部２０４は、画面ｐ'内の全てのＷｅｂ要素を特定する（ステップＳ３０４）。以下では、これらのＷｅｂ要素をｗ'∈Ｗ'（Ｗ'は画面ｐ'の全てのＷｅｂ要素の集合）とする。
　次に、提案部２０４は、Ｗｅｂ要素ｗ'の不審度が上位ＴＷ位以内である場合はその不審度によりＷｅｂ要素ｗ'を強調して表示する（ステップＳ３０５）。
　すなわち、Ｗｅｂ要素ｗ'のバグによる不審度ｄ１ｗ'が上位ＴＷ位以内である場合、提案部２０４は、ｄ１ｗ'×１００の値を当該Ｗｅｂ要素ｗ'の右上に表示すると共に、当該Ｗｅｂ要素ｗ'を太線で囲んで強調する。また、Ｗｅｂ要素ｗ'の回数による不審度ｄ２ｗ'が上位ＴＷ位以内である場合、提案部２０４は、ｄ２ｗ'×１００の値を当該Ｗｅｂ要素ｗ'の右上に表示すると共に、当該Ｗｅｂ要素ｗ'を太線で囲んで強調する。また、Ｗｅｂ要素ｗ'の入力による不審度ｄ３ｗ'が上位ＴＷ位以内である場合、提案部２０４は、ｄ３ｗ'×１００の値を当該Ｗｅｂ要素ｗ'の右上に表示すると共に、当該Ｗｅｂ要素ｗ'を太線で囲んで強調する。
　＜まとめ＞
　以上のように、本実施形態に係るテスト支援装置１０は、テスト中の操作情報やバグ情報を用いて、Ｗｅｂ要素又は画面に対する操作によってバグが引き起こされる疑わしさを表す不審度と呼ばれる値を算出する。そして、本実施形態に係るテスト支援装置１０は、この不審度が高いＷｅｂ要素又は画面を、次にテストすべき箇所としてテスターに提案する。これにより、特に属人性が高い探索的テストであっても、また熟練のテスターでなくても、バグを効率よく検出することができることが可能となる。
　本発明は、具体的に開示された上記の実施形態に限定されるものではなく、請求の範囲の記載から逸脱することなく、種々の変形や変更、既知の技術との組み合わせ等が可能である。
　１０　　　　テスト支援装置
　１０１　　　入力装置
　１０２　　　表示装置
　１０３　　　外部Ｉ／Ｆ
　１０３ａ　　記録媒体
　１０４　　　通信Ｉ／Ｆ
　１０５　　　プロセッサ
　１０６　　　メモリ装置
　１０７　　　バス
　２０１　　　Ｗｅｂブラウザ
　２０２　　　情報記録部
　２０３　　　不審度算出部
　２０４　　　提案部
　２０５　　　記憶部

Claims (7)

  1. 　Ｗｅｂアプリケーションに対するテストを支援するテスト支援装置であって、
    　前記Ｗｅｂアプリケーションの画面上で行われた操作に関する情報と、前記Ｗｅｂアプリケーションのバグに関する情報とを用いて、前記画面上における操作によってバグが引き起される疑わしさを表す不審度を算出する不審度算出部と、
    　前記不審度に基づいて、前記Ｗｅｂアプリケーションの画面上でテストすべき箇所を提案する提案部と、
    　を有するテスト支援装置。
  2. 　前記不審度には、前記画面に対する操作によってバグが引き起こされる疑わしさを表す第１の不審度と、前記画面の構成要素に対する操作によってバグが引き起こされる疑わしさを表す第２の不審度とが含まれ、
    　前記提案部は、
    　前記Ｗｅｂアプリケーションの各画面うち、前記第１の不審度が上位所定の件数以内の画面をテストすべき箇所として提案し、
    　前記画面の構成要素のうち、前記第２の不審度が上位所定の件数以内の構成要素をテストすべき箇所として提案する、請求項１に記載のテスト支援装置。
  3. 　前記不審度算出部は、
    　前記テストを実施したユーザが前記画面に他の画面から遷移した回数、前記ユーザが前記画面内で操作した回数、前記画面内で前記ユーザの入力操作によって入力された入力値の個数、前記画面内で前記ユーザの入力操作によって入力された入力値の中でユニークな入力値の個数、前記画面における前記ユーザの滞在時間、前記画面で前記ユーザが検出したバグの個数、前記画面の構成要素数、前記画面に他の画面から遷移した回数の合計、のうちの２つの組み合わせにより前記第１の不審度を算出し、
    　前記ユーザが前記構成要素に対して行った操作の回数、前記ユーザが前記構成要素に対して行った入力操作の回数、前記ユーザが前記構成要素に対して行った入力操作の中でユニークな入力操作の回数、前記ユーザが前記構成要素に対して操作を行ってから次の操作を行うまでの時間、前記ユーザが検出したバグのうち前記構成要素に関連するバグの個数、のうちの２つの組み合わせにより前記第２の不審度を算出する、請求項２に記載のテスト支援装置。
  4. 　前記第１の不審度には、
    　前記画面で各ユーザによって検出されたバグの個数と、各ユーザが前記画面に他の画面から遷移した回数との比で表される不審度と、
    　各ユーザが前記画面に他の画面から遷移した回数と、前記Ｗｅｂアプリケーションの各画面の各々から他の画面に各ユーザが遷移した回数の合計との比を１から減じた値で表される不審度と、の少なくとも１つが含まれ、
    　前記第２の不審度には、
    　各ユーザが検出したバグのうち前記構成要素に関連するバグの個数と、各ユーザが前記構成要素に対して行った操作の回数との比で表される不審度と、
    　各ユーザが前記構成要素に対して行った操作の回数と、前記Ｗｅｂアプリケーションの各画面の構成要素の各々に対して各ユーザが行った操作の回数の合計との比を１から減じた値で表される不審度と、
    　前記構成要素に対して各ユーザが行ったユニークな入力操作の回数と、前記構成要素に対して各ユーザが行った全ての入力操作の回数との比を１から減じた値で表される不審度と、の少なくとも１つが含まれる、請求項２又は３に記載のテスト支援装置。
  5. 　前記提案部は、
    　前記第１の不審度が上位所定の件数以内の画面に対して、前記第１の不審度に基づく値を付与して強調表示することで前記テストすべき箇所として提案し、
    　前記第２の不審度が上位所定の件数以内の構成要素に対して、前記第２の不審度に基づく値を付与して強調表示することで前記テストすべき箇所として提案する、請求項２乃至４の何れか一項に記載のテスト支援装置。
  6. 　Ｗｅｂアプリケーションに対するテストを支援するコンピュータが、
    　前記Ｗｅｂアプリケーションの画面上で行われた操作に関する情報と、前記Ｗｅｂアプリケーションのバグに関する情報とを用いて、前記画面上における操作によってバグが引き起される疑わしさを表す不審度を算出する不審度算出手順と、
    　前記不審度に基づいて、前記Ｗｅｂアプリケーションの画面上でテストすべき箇所を提案する提案手順と、
    　を実行するテスト支援方法。
  7. 　コンピュータを、請求項１乃至５の何れか一項に記載のテスト支援装置として機能させるプログラム。
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
JP3008872B2 (ja) Ｇｕｉシステム自動操作装置および操作マクロ実行装置
US9213625B1 (en) Method and apparatus for performing automated user-interface layout testing
JP4140916B2 (ja) Ｗｅｂページにおける状態遷移を解析する方法
US8898178B2 (en) Solution monitoring system
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
US20050160405A1 (en) System and method for generating code coverage information
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
US11055209B2 (en) Application analysis with flexible post-processing
TW200406692A (en) Semiconductor test data analysis system
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
US20100251211A1 (en) Generating and using code-based diagrams
Mateos et al. Migration from COBOL to SOA: measuring the impact on web services interfaces complexity

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