JP2020510925A - テストケースを利用してテストを遂行する方法および装置 - Google Patents

テストケースを利用してテストを遂行する方法および装置 Download PDF

Info

Publication number
JP2020510925A
JP2020510925A JP2019546812A JP2019546812A JP2020510925A JP 2020510925 A JP2020510925 A JP 2020510925A JP 2019546812 A JP2019546812 A JP 2019546812A JP 2019546812 A JP2019546812 A JP 2019546812A JP 2020510925 A JP2020510925 A JP 2020510925A
Authority
JP
Japan
Prior art keywords
test
database
test case
value
input
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2019546812A
Other languages
English (en)
Other versions
JP6859449B2 (ja
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 スパロー カンパニー リミテッド
Publication of JP2020510925A publication Critical patent/JP2020510925A/ja
Application granted granted Critical
Publication of JP6859449B2 publication Critical patent/JP6859449B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

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

Landscapes

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

Abstract

テストケースを利用したテスト方法および装置が開示される。テストケースを利用したテスト方法は、シンボリック実行に基づいてＳＱＬ文を含むソースコードに対するテストケースを生成する段階およびデータベースと連動するテスト対象システムに前記テストケースを適用してテストを遂行する段階を含む。したがって、テストケースを自動で生成するためテストに必要とされる努力と時間が画期的に節減され得る。

Description

本発明はテストケースを利用したテスト方法および装置に関し、さらに詳細には、業務システム開発過程でシステムのエラーを探すためのテストケースを自動で生成し、生成したテストケースを利用してシステムをテストする方法および装置に関する。
テスト方法には、プログラムを実際に実行せずにソースコードを静的分析してテストする静的テストと、プログラムを実際に実行して返還された実行結果を確認することによってテストする動的テストと、がある。
静的テストはソースコードのパターンと処理の流れを分析してエラーを検出する方法であって、テストケースを探したりテストケース値を生成することができ、開発者はテストケースを利用してプログラムをテストすることができる。
動的テストはプログラムの動作をテストしなければならないため入力値が必要であり、プログラムの動作の結果で出力値が生成される。また、プログラムの動作をテストする時はプログラムが最小モジュールである関数を基本単位とする。ここで、関数は入力パラメーターと出力パラメーターを有し、関数は値を返還したりもする。
既存のテストケースを生成する研究の一つ（Ｇｕｐｔａ ｅｔ ａｌ）は、反復的緩和技法を使ってテストデータを自動で生成された。具体的には、ベーシス経路（Ｂａｓｉｓ Ｐａｔｈ）を基準にテストケースを選択し、ガウスの消去法を使って解を求めたが、ここで求めた解がテスト経路値である。しかし、このような研究は、企業の業務システムに多く使われるＳＱＬクエリ文に対する考慮がなかったのであり、変数が多くなるとガウスの消去法で解決できない問題があった。
さらに他の研究の一つ（Ｇｏｄｅｆｒｏｉｄ ｅｔ ａｌ）は、シンボリック実行と具体的な実行を組み合わせてテストケースを生成した。具体的には、ランダムテスト方式、コード挿入方式、シンボリック実行方式を利用して外部環境に影響を及ぼす変数を抽出し、抽出した変数でランダムにテストケースを生成するランダムテスト方式で初期値を生成したし、計測器コードを通じて実行結果を分析した。しかし、このような研究は厳密な意味のシンボリック実行と見難い問題があった。
その他にも、シンボリック実行方法と具体的な実行方法を組み合わせてテストケースを生成する他の研究（Ｓｅｎ ｅｔ ａｌ）は、シンボリック実行のためにＣ言語と類似する言語を定義して使用し、主にＮＵＬＬ Ｐｏｉｎｔｅｒを探すのに活用した。しかし、テストケースを明示的に生成して管理しないため、毎度全体のソースコードを再パーシングする問題点があったし、これもＳＱＬクエリ文を考慮していなかった。
データベースの環境を考慮しないと、企業システムに対するテストが行われる時に登録、修正そして削除に関するＳＱＬクエリ文によってデータベース内のデータが変更され得、このような変更はテスト結果に影響を及ぼすため正確なテストが進行され得ない。
前記のような問題点を解決するための本発明の目的は、テストケースを利用したテスト方法を提供することである。
前記のような問題点を解決するための本発明の他の目的は、テストケース生成装置を提供することである。
前記のような問題点を解決するための本発明の他の目的は、テストケースを利用したテスト装置を提供することである。
前記目的を達成するための本発明は、テストケースを利用したテスト方法を提供する。
ここで、テストケースを利用したテスト方法は、シンボリック実行（ｓｙｍｂｏｌｉｃ ｅｘｅｃｕｔｉｏｎ）に基づいてＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）文を含むソースコードに対するテストケースを生成する段階およびデータベースと連動するテスト対象システムにテストケースを適用してテストを遂行する段階を含む。
ここで、テストケースは、テスト対象システムの入力値、入力値がテスト対象システムで処理される時に出力値を予測した予想出力値、データベースの設定値およびテスト対象システムが設定値が適用されたデータベースと連動して処理される時、データベースに保存される結果値を予測した予想結果値のうち少なくとも一つを含むことができる。
ここで、テストケースを生成する段階は、ソースコードに対して少なくとも一つ以上のプログラム経路を決定する段階、少なくとも一つ以上のプログラム経路によりシンボリック実行を遂行する段階およびシンボリック実行により生成された論理式に対してソルバーを利用してテストケースを生成する段階を含むことができる。
ここで、プログラム経路を決定する段階は、ソースコードをパーシングして要約構文ツリー（Ａｂｓｔｒａｃｔ Ｓｙｎｔａｘ Ｔｒｅｅ、ＡＳＴ）を生成する段階、生成した要約構文ツリーに基づいて、制御流れグラフ（Ｃｏｎｔｒｏｌ Ｆｌｏｗ Ｇｒａｐｈ、ＣＦＧ）を生成する段階および制御流れグラフに基づいて少なくとも一つ以上のプログラム経路を決定する段階を含むことができる。
ここで、シンボリック実行を遂行する段階は、少なくとも一つ以上のプログラム経路にＳＱＬ文が含まれた場合、ソースコードのホスト変数とＳＱＬ文によってデータベースに含まれたテーブルのコラムをマッピングする段階を含むことができる。
ここで、マッピングする段階は、ＳＱＬ文をパーシングしてテーブルを確認する段階、確認したテーブルを構成するコラムをデータベースのメタデータを利用して獲得する段階および獲得したコラムをソースコードのホスト変数とマッピングする段階を含むことができる。
ここで、テストケースを生成する段階後に、生成したテストケースをＸＭＬ、ＪＳＯＮのうち一つのフォーマットで保存する段階をさらに含むことができる。
ここで、テストを遂行する段階は、テスト対象システムがモジュールである場合、設定値をデータベースに適用する段階、入力値でテスト対象システムの入力パラメーターを設定する段階、設定した入力パラメーターでテスト対象システムの関数を呼び出す段階および関数呼び出しの結果で獲得したテスト対象システムの出力値を予想出力値と比較し、データベースに保存された結果値と予想結果値とを比較する段階を含むことができる。
ここで、テストを遂行する段階は、テスト対象システムがミドルウェアサービスである場合、テストケースを利用して入力全文を生成する段階、テスト対象システムが連動するミドルウェア（ｍｉｄｄｌｅｗａｒｅ）のサービスを呼び出して入力全文をミドルウェアに伝送する段階およびミドルウェアからテスト結果全文を受信する段階を含むことができる。
ここで、ミドルウェアは、入力全文からテストケースのデータベース設定値を確認し、確認したデータベース設定値を利用してデータベースに対する初期設定を遂行し、入力全文からテストケースの入力値を確認してテスト対象システムの入力パラメーターとして入力してテスト対象システムを実行するように構成され得る。
ここで、予想出力値は、テスト対象システムの実行時ごとに出力値が変更される場合、テストケースから除外されたり、マクロ、参照、スクリプトのうち一つの方法で決定され得る。
前記他の目的を達成するための本発明の一側面はテストケース生成装置を提供する。
ここで、テストケース生成装置は、少なくとも一つの命令（ｉｎｓｔｒｕｃｔｉｏｎ）を実行するプロセッサ（ｐｒｏｃｅｓｓｏｒ）および少なくとも一つの命令を保存するメモリー（ｍｅｍｏｒｙ）を含み、プロセッサは、シンボリック実行に基づいて、ＳＱＬ文を含むソースコードに対して少なくとも一つ以上のプログラム経路を決定し、少なくとも一つ以上のプログラム経路によりシンボリック実行を遂行し、シンボリック実行により生成された論理式に対してソルバーを利用してテストケースを生成することができる。
ここで、プロセッサは、ソースコードをパーシングして要約構文ツリーを生成し、生成した要約構文ツリーに基づいて、制御流れグラフを生成し、制御流れグラフに基づいて少なくとも一つ以上のプログラム経路を決定することができる。
前記他の目的を達成するための本発明の一側面はテストケースを利用したテスト装置を提供する。
ここで、テストケースを利用したテスト装置は、少なくとも一つの命令を実行するプロセッサ、少なくとも一つの命令を保存するメモリーを含む。
ここで、プロセッサは、シンボリック実行に基づいてＳＱＬ文を含むソースコードに対するテストケースを生成し、データベースと連動するテスト対象システムにテストケースを適用してテストを遂行し、テストケースはテスト対象システムの入力値、入力値がテスト対象システムで処理される時に出力値を予測した予想出力値、データベースの設定値およびテスト対象システムが設定値が適用されたデータベースと連動して処理される時、データベースに保存される結果値を予測した予想結果値のうち少なくとも一つを含むことができる。
ここで、プロセッサは、ソースコードに対して少なくとも一つ以上のプログラム経路を決定し、少なくとも一つ以上のプログラム経路によりシンボリック実行を遂行し、シンボリック実行により生成された論理式に対してソルバーを利用してテストケースを生成することができる。
ここで、プロセッサは、ソースコードをパーシングして要約構文ツリーを生成し、生成した要約構文ツリーに基づいて、制御流れグラフを生成し、制御流れグラフに基づいて少なくとも一つ以上のプログラム経路を決定することができる。
ここで、プロセッサは、少なくとも一つ以上のプログラム経路にＳＱＬ文が含まれた場合、ソースコードのホスト変数とＳＱＬ文によってデータベースに含まれたテーブルのコラムをマッピングすることができる。
ここで、プロセッサは、ＳＱＬ文をパーシングしてテーブルを確認し、確認したテーブルを構成するコラムをデータベースのメタデータを利用して獲得し、獲得したコラムをソースコードのホスト変数とマッピングすることができる。
ここで、プロセッサは生成したテストケースをＸＭＬ、ＪＳＯＮのうち一つのフォーマットで保存することができる。
ここで、プロセッサは、テスト対象システムがモジュールである場合、設定値をデータベースに適用し、入力値でテスト対象システムの入力パラメーターを設定し、設定した入力パラメーターでテスト対象システムの関数を呼び出し、関数呼び出しの結果で獲得したテスト対象システムの出力値を予想出力値と比較し、データベースに保存された結果値と予想結果値とを比較することができる。
ここで、プロセッサは、テスト対象システムがミドルウェアサービスである場合、テストケースを利用して入力全文を生成し、テスト対象システムが連動するミドルウェアのサービスを呼び出して入力全文をミドルウェアに伝送し、ミドルウェアからテスト結果全文を受信することができる。
前記のような本発明に係るテストケースを利用したテスト方法および装置を利用する場合には、繰り返しテスト可能なテストケースを提供することができ、これによって回帰エラーを探すことができる回帰テストに使われ得る長所がある。
また、プログラムに含まれた埋め込みＳＱＬ文を考慮してテストケースを生成できるため、データベースと関連したシステムに対するテストが容易である長所がある。
また、テストケースを自動で生成するため、テストに要される努力と時間が画期的に節減され得る。
本発明の一実施例に係るテストケースを利用したテスト方法についての概念図である。 本発明の一実施例に係るテストケースを利用したテスト方法のフローチャートである。 本発明の一実施例に係るプログラム経路によりシンボリック実行を遂行する段階を具体化したフローチャートである。 本発明の一実施例に係る要約構文ツリー（ａｂｓｔｒａｃｔ ｓｙｎｔａｘ ｔｒｅｅ、ＡＳＴ）を説明するための概念図である。 本発明の一実施例に係るテストケースを導き出すためのソースコードの例示図である。 本発明の一実施例に係る制御流れグラフ（ｃｏｎｔｒｏｌ ｆｌｏｗ ｇｒａｐｈ、ＣＦＧ）を説明するための概念図である。 経路６についてのシンボリック実行過程をシミュレーションした結果を示した図面である。 本発明の一実施例に係るテストを遂行する過程についての第１例示図である。 本発明の一実施例に係るテストを遂行する過程についての第２例示図である。
本発明は多様な変更を加えることができ、多様な実施例を有することができるところ、特定の実施例を図面に例示して詳細な説明に詳細に説明する。しかし、これは本発明を特定の実施形態に対して限定しようとするものではなく、本発明の思想および技術範囲に含まれるすべての変更、均等物乃至代替物を含むものと理解されるべきである。各図面の説明において、類似する参照符号は類似する構成要素を示す。
第１、第２、Ａ、Ｂなどの用語は多様な構成要素の説明に使われ得るが、前記構成要素は前記用語によって限定されはしない。前記用語は一つの構成要素を他の構成要素から区別する目的でのみ使われる。例えば、本発明の権利範囲を逸脱することなく第１構成要素は第２構成要素と命名され得、同様に第２構成要素も第１構成要素と命名され得る。および／またはという用語は、複数の関連した記載された項目の組み合わせまたは複数の関連した記載された項目のいずれかの項目を含む。
ある構成要素が他の構成要素に「連結されて」いるとか「接続されて」いると言及された時には、その他の構成要素に直接的に連結されていたり、または接続されていてもよいが、中間に他の構成要素が存在してもよいと理解されるべきである。その反面、ある構成要素が他の構成要素に「直接連結されて」いるとか「直接接続されて」いると言及された時には、中間に他の構成要素が存在しないものと理解されるべきである。
本出願で使った用語は単に特定の実施例を説明するために使われたものであって、本発明を限定しようとする意図ではない。単数の表現は文脈上明白に異なることを意味しない限り、複数の表現を含む。本出願で、「含む」または「有する」等の用語は、明細書上に記載された特徴、数字、段階、動作、構成要素、部品またはこれらを組み合わせたものが存在することを指定しようとするものであって、一つまたはそれ以上の他の特徴や数字、段階、動作、構成要素、部品またはこれらを組み合わせたものなどの存在または付加の可能性をあらかじめ排除しないものと理解されるべきである。
異なって定義されない限り、技術的または科学的な用語を含んでここで使われるすべての用語は、本発明が属する技術分野で通常の知識を有する者によって一般的に理解されるものと同じ意味を有している。一般的に使われる辞書に定義されているような用語は、関連技術の文脈上有する意味と一致する意味を有するものと解析されるべきであり、本出願で明白に定義しない限り、理想的または過度に形式的な意味で解析されない。
以下、本発明に係る好ましい実施例を添付された図面を参照して詳細に説明する。
図１は、本発明の一実施例に係るテストケースを利用したテスト方法についての概念図である。
図１を参照すると、本発明の一実施例に係るテストケースを利用したテスト方法は、シンボリック実行器（Ｓｙｍｂｏｌｉｃ Ｅｘｅｃｕｔｏｒ、１０）、テストマネジャー（Ｔｅｓｔ Ｍａｎａｇｅｒ、２０）、細部実行器（Ｃｏｎｃｒｅｔｅ Ｅｘｅｃｕｔｏｒ、４０）を含むテスト装置によって遂行され得る。
ここで、テスト装置は内部または外部に別途のテストデータベース３０を含むことができる。
本発明の一実施例に係るテスト方法を説明すると、まず、テストマネジャー２０はテスターからテストケースの生成要請の入力を受けたり、受信することができる。テストマネジャー２０はシンボリック実行器１０にテストケースの生成を要請することができる。テストケースの生成を要請されたシンボリック実行器１０は、形状管理からソースコードをダウンロードする。ここで、形状管理は開発過程でソースコードやデータベースのテーブルなどが随時変更されても、変更事項を反映してテストができるように最新のソースコードで管理することができ、ソースコードはＳＱＬ（ｓｔｒｕｃｔｕｒｅｄ ｑｕｅｒｙｌａｎｇｕａｇｅ）文を含んでいるものと解析され得る。また、ここでダウンロードされるソースコードは開発者によって直接シンボリック実行器１０に入力されてもよい。
シンボリック実行器１０はテストケースを生成してテストマネジャー２０に伝送することができる。テストマネジャー２０は伝送されたテストケースをテストＤＢ３０に保存することができる。ここで保存されたテストケースは、テスターがテストマネジャー２０を通じて照会を要請すれば、テストマネジャー２０を通じてテストに提供され得る。
テストマネジャー２０は細部実行器４０にテストの実行を要請することができる。実行を要請された細部実行器４０はテストＤＢ３０からテストケースを照会することができ、照会したテストケースからテスト対象システム（Ｓｙｓｔｅｍ Ｕｎｄｅｒ Ｔｅｓｔ、ＳＵＴ、６０）と連動するデータベース５０に対してテストのための設定値を適用することができる。ここで、テストのための設定値は、テスト対象システム６０がデータベース５０と連動して動作するためにデータベース５０に保存されなければならない初期値を意味し、場合によっては初期値はないかＮｕｌｌでもよい。
細部実行器４０は照会したテストケースから入力値をテスト対象システム６０に入力してテスト対象システム６０の出力値を獲得することができる。
また、テスト対象システム６０が入力値を受けて動作すると、テスト対象システムと連動するデータベース５０にも新しい結果値が保存され得、したがって、細部実行器４０はデータベースでの結果値も獲得することができる。
細部実行器４０は獲得したテスト対象システム６０の出力値とデータベース５０の結果値をテストＤＢ３０に保存された確認値と対照することができ、対照過程を通じてテスト対象システム６０のエラーの有無を診断し把握することができる。
その後、細部実行器４０はテスト結果をテストＤＢ３０に保存することができ、テストマネジャー２０にテスト結果を返還することができる。テストマネジャー２０は返還されたテスト結果をテスターに提供することができる。
このような実行手続きを通じて、テストケースを生成し、保存し、実行し、テスト結果を保存し、そしてテスト結果の統計とレポートを提供するなどの一連のテストライフサイクルを支援することができる。
ここで、シンボリック実行器１０は、シンボリック演算を遂行する時、ＳＱＬクエリ文を理解するのに必要なテーブルのコラムと各コラムの制約事項を得るために、データベース５０が提供するメタ情報を使うことができる。
テストマネジャー２０は、テスト経路とそれによるテストケースおよびテスト結果値を国際標準であるＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式でテストＤＢ３０に保存して管理することができる。
また、ここで最新のソースコードを反映したテストケースを利用してテストが進行され得るように、テストケースとテスト対象システム６０の同期化が要求され得るが、テスト対象システム６０が変更されるたびに形状管理から確認してテストケースを生成しておくこともでき、テスト要請時にのみ形状管理から最新の有無を確認してテストケースを生成することができる。
具体的には、テストマネジャー２０がユーザーまたは管理者からテスト要請を受けると、テストＤＢ３０にテストケースが生成されているかを確認した後、テストケースがあって新しい修正事項がない場合（または最新のソースコードに対して生成されたテストケースである場合）であると、細部実行器４０にテスト対象システム６０とテストケースの識別記号を伝達しながらテストを要請することができる。また、テストＤＢ３０にテストケースがないか、最新のテスト対象システム６０を基準に生成されたテストケースではなければ、シンボリック実行器１０にテストケースの生成を要請することができる。
細部実行器４０はテストを実行するためにテストＤＢ３０に保存されたテストケースを引き出し、その値でドライバーや全文を生成してテストを実行し、テスト結果値をテストＤＢ３０に保存し管理することができる。
形状管理はテスト対象となるソースコードをすべて管理するが、シンボリック実行器１０は最新のソースコードを対象としてテストケースを生成することができる。
テスト対象システム６０はテストするためのモジュールやサービスであり得る。
例えば、モジュールはソースコード、オブジェクト、静的ライブラリ、そして動的ライブラリのような形態で存在することができる。また、サービスはミドルウェア基盤下で実行されるバイナリー形態のプログラムであり得る。サービスは全文を通じてテストを遂行することができる。
全文は位置基盤型とタグ基盤型があるが、位置基盤型全文ではデータの位置と長さによってデータの意味が定義され得、タグ基盤型全文はタグによってデータの意味が定義され、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）とＸＭＬのような形態が存在し得る。
テストマネジャー２０は、開発者、品質保証担当者、そしてプロジェクト管理者に多様なテスト結果を統計および現況レポートの形態で提供することができる。このようなレポートには、プロジェクト別テスト現況、業務別テスト現況、モジュールまたはサービス別テスト現況、そして欠陥を除くか欠陥を措置した結果が示され得る。
また、テストマネジャー２０は、単位テスト、統合テスト、そして回帰テストを支援することができる。単位テスト用として生成したテストケースは統合テストと回帰テストにおいても使われ得る。統合テストはシナリオで構成されるが、これは単位テストケースを順に組み合わせて構成することができる。単位テストケースをシナリオに組み合わせるためには、以前のテストケースの実際の出力値を入力値でマッピングしなければならない。そして、予想出力値には入力値をマッピングできる算術式が提供され得る。回帰テストで使うテストケースは単位テストのテストケースを修正せずに使うことができるが、回帰分析による多様なテストケースの選択方法が必要な場合もある。すなわち、回帰分析の範囲はプログラム依存関係によるテストケースの選択、関数依存関係によるテストケースの選択、そして影響を受けるテストケースのみ選択するなどの技術が適用され得る。
ここで、シンボリック実行器１０、テストマネジャー２０、細部実行器４０は説明の便宜のために各構成部として説明したが、それぞれ個別の装置で具現され得るだけでなく、一部が結合して一つの装置で具現され得るものと理解されるべきであり、本実施例に限定して解析されない。
図２は、本発明の一実施例に係るテストケースを利用したテスト方法のフローチャートである。
図２を参照すると、テストケースを利用したテスト方法はシンボリック実行に基づいてＳＱＬ文を含むソースコードに対するテストケースを生成する段階Ｓ２００およびデータベースと連動するテスト対象システムにテストケースを適用してテストを遂行する段階Ｓ３００を含むことができる。
ここで、テストケースはテスト対象システムの入力値、入力値がテスト対象システムで処理される時に出力値を予測した予想出力値、データベースの設定値およびテスト対象システムが設定値が適用されたデータベースと連動して処理される時、データベースに保存される結果値を予測した予想結果値のうち少なくとも一つを含むことができる。
具体的に再度説明すると、入力値は関数の入力パラメーターに対応する値であり得、予想出力値は関数が実行された後に返還される結果を確認するために出力パラメーターに対応する値であり得、設定値はテスト対象システムがデータベースと連動して動作するためにデータベースに保存されなければならない初期値であり得、予想結果値はテスト対象システムがデータベースと連動して動作した結果物としてデータベースに保存され得る値であり得る。
また、入力値と予想出力値または予想結果値は、関数の入力パラメーターやリターン形式（または出力パラメーター）またはデータベースに保存されたデータ形式（ｄａｔａ ｔｙｐｅ）により、整数（ｉｎｔｅｇｅｒ）や文字列（ｓｔｒｉｎｇ）等の形式（ｔｙｐｅ）を有することができ、データベース設定値はＩＮＳＥＲＴ、ＵＰＤＡＴＥそしてＤＥＬＥＴＥ文のうち少なくとも一つで構成されたＳＱＬクエリ文であり得る。
また、入力値、予想出力値、データベースの設定値および予想結果値のうち少なくとも一つを含むテストケースは、ＪＳＯＮとＸＭＬのうち一つのフォーマットで保存され得る。ただし、これに限定されず、文字列、バイナリーなどの形態で保存されてもよい。
ここで、ソースコードはテスト対象システムのソースコードを意味し得る。
また、ソースコードはＳＱＬ文を含むことができるが、ここで使われるソースコードは、ＪＡＶＡ（登録商標）、Ｓｗｉｆｔ、Ｏｂｊｅｃｔ Ｃなどを含む常用言語で作成されたコードをすべて含むことができ、場合によっては常用言語から一部の構文を除去して個別的に定義した言語であり得る。特にここに含まれたＳＱＬ文は、埋め込みＳＱＬで定義されてもよく、例えばＯｒａｃｌｅのＰＬ／ＳＱＬ、ＰｏｓｔｇｒｅＳＱＬのＥＣＰＧ、ＳｙｂａｓｅのＡＳＥなどが存在し得、このような埋め込みＳＱＬが支援する言語にはＣ／Ｃ＋＋、ＣＯＢＯＬ、ＰＬ／１等が存在し得る。
本発明の例示ソースコードは常用言語から説明の便宜のために一部の構文を除去して記述したが、これに限定されず、各種プログラミング言語がすべて適用され得る。
ここで、テスト対象システムはデータベースを使う情報システムであり得、ここで、データベースは一つ以上のレコードを保存し、レコードに対して少なくとも一つ以上の属性を有するテーブルを保存することができる。
ここで、本発明の一実施例に係るテスト対象システムはデータベースと連動する業務用利子計算プログラムを例にして説明するか、特定のシステムに限定されるものではなく、業務用利子計算プログラムの例題ソースコードは以下で図５を参照することができる。
ここで、シンボリック実行とは、プログラムを分析するために実際の特定の値の代わりにシンボルで定義された値を利用するものであって、以下例題ソースコードに基づいて説明する。
Figure 2020510925
表１を参照すると、例題ソースコードに対してシンボリック実行を説明することができるが、まず、入力パラメーターで定義されるａにはシンボル値としてＡが割り当てられ得る。したがって、算術式ｂ＝ａ＊１０＋１はｂ＝Ａ＊１０＋１となり、これが変数ｂの代わりにそのまま割り当てられ得、条件文ｉｆ式が成立する場合をＡを基準に計算するとＡ！＝３の場合となるので、Ａは３を除いた各種整数（ｉｎｔ）が導き出され得る。
その反対に、条件文ｉｆ式が成立しない場合（ｅｌｓｅ構文）をＡを基準に計算するとＡが３の場合（Ａ＝＝３）がシンボリックＡで３が導き出され得る。
ここで、前記のようにシンボル値で構成された条件式に対する計算は多様なソルバー（ｓｏｌｖｅｒ）を利用することができる。例えば、マイクロソフトから研究用に使用できるように公開されたＺ３を使うことができる。
一方、シンボル式が例えばａ＊ｂ＝１０やｓｉｎ（ａ）＝１のように、非線形（ｎｏｎｌｉｎｅａｒ）式で表される場合はソルバーで計算が困難であり得るが、このような時にはシンボル値の一つに実際の特定値を割り当てる方法などを利用して線形条件に変更することによって解決することができる。
ここで、テスト対象システムと連動したデータベースに保存されたテーブルの例を挙げると、次の表２の通りであり得る。
Figure 2020510925
表２を参照すると、データベースに保存された口座テーブルを確認することができるが、口座番号、貸し出し金などの属性に対する情報が保存され得る。
ここで、口座テーブルに保存された口座データの例を挙げると次の表３の通りであり得る。
Figure 2020510925
表３を参照すると、データベースに保存された口座データを確認することができるが、前記表２での口座番号、貸し出し金などに対する値が保存され得る。
一方、テスト対象システムと連動したデータベーステーブルは一つ以上であり得、業務用利子計算を例にして説明するので、利子償還テーブルを次のように有することができる。
Figure 2020510925
表４を参照すると、口座番号による償還日などが利子償還テーブルに保存されていてもよい。
ここで、利子償還テーブルに記録された利子償還データは次の通りであり得る。
Figure 2020510925
表５を参照すると、各口座番号により償還日と利子が保存されていてもよい。
ここで、テストケースを生成する段階Ｓ２００は、ソースコードに対して少なくとも一つ以上のプログラム経路を決定する段階Ｓ２１０、少なくとも一つ以上のプログラム経路により前記シンボリック実行を遂行する段階Ｓ２２０およびシンボリック実行により生成された論理式に対してソルバーを利用してテストケースを生成する段階Ｓ２３０を含むことができる。
以下、図面を参照して各段階を詳細に説明することができる。
図３は、本発明の一実施例に係るプログラム経路を決定する段階を具体化したフローチャートである。図４は、本発明の一実施例に係る要約構文ツリーを説明するための概念図である。図５は、本発明の一実施例に係るテストケースを導き出すためのソースコードの例示図である。図６は、制御流れグラフを説明するための概念図である。
図３を参照すると、図２のプログラム経路を決定する段階Ｓ２１０は、ソースコードをパーシングして要約構文ツリーを生成する段階Ｓ２１１、生成した要約構文ツリーに基づいて、制御流れグラフを生成する段階Ｓ２１２および前記制御流れグラフに基づいて少なくとも一つ以上のプログラム経路を決定する段階Ｓ２１３を含むことができる。
要約構文（ａｂｓｔｒａｃｔ ｓｙｎｔａｘ）は演算子で構成された要約構文ツリー（ＡＳＴ）を帰納的に定義したものであって、要約構文は演算子を使ってソースコードの構文（ｓｙｎｔａｘ）が有する曖昧さを除去することができる。また、要約構文ツリーは他の要約構文ツリーを生成子と演算子で組み合わせて生成することができる。
具体的な要約構文ツリーおよび要約構文については、Ｒ．Ｈａｒｐｅｒ（Ｈａｒｐｅｒ、Ｒ．、２００５、ｏｐ． ｃｉｔ．）を参照することができる。
図４を参照すると、要約構文ツリーは構造体の形態４００でも表現することができ、これを分かりやすくする図式化すれば、図式化された形態４１０でも表現することができる。
具体的には、要約構文ツリーはツリー構造であるが、多様な形態にツリーが表現され得る。例えばＡｒｒａｙＬｉｓｔやＬｉｓｔ、Ｍａｐのようなデータ構造を利用して具現することができる。
図４に構造体の形態４００と図式化された形態４１０とを互いに比較すると、最上位ノードは＜Ｐｒｏｇｒａｍ＞であり得る。ここで＜Ｐｒｏｇｒａｍ＞は１個以上の関数、すなわちリスト（Ｌｉｓｔ）で構成され得る。関数は返還タイプ、関数名、パラメーター、そしてブロック宣言で構成され得る。パラメーターはタイプと変数名で構成され得る。ブロック宣言は０個以上の文章で構成され得る。文章はローカル変数宣言文、割当文、ｉｆ文、クエリ文などで構成され得る。ここで、本発明の一実施例によると、ＳＱＬクエリ文を含むソースコードを対象とするため、クエリ文を含んでシンボリック演算を実行することが最も重要な要素であり得る。
図４による要約構文ツリーでプログラム経路を決定するには、要約構文ツリーそのものがすでにツリー構造ではあるが、多重ノードを有するのでここでプログラム経路を決定するのは困難であり得る。
したがって、制御流れグラフを導入することができる。制御流れグラフは実行中にプログラムを通過するすべての経路をグラフで表記することができる。グラフにおいて、各ノードは基本ブロック（ｂａｓｉｃ ｂｌｏｃｋ）を表し、矢印はジャンプ（ｊｕｍｐ）を表すために使うことができる。グラフは一つの進入ブロック（ｅｎｔｒｙ ｂｌｏｃｋ）と終了ブロック（ｅｘｉｔ ｂｌｏｃｋ）を有することができる。矢印であるすべての線はＯｕｔｄｅｇｒｅｅ（Ａ）＞１であるか、Ｉｎｄｅｇｒｅｅ（Ｂ）＞１（または両側）の属性を有することができる。
また、プログラム経路の決定は、無数に多くの経路が導き出される経路爆発（Ｐａｔｈ Ｅｘｐｌｏｓｉｏｎ）が発生し得る。経路爆発問題を解決するために、独立的なプログラム経路を使うことができる。独立的なプログラム経路とは、特定の経路の組み合わせではなく、固有な他の経路と差別化される経路であり得る。独立的なプログラム経路を探す技法として基礎経路テスティング（Ｂａｓｉｓ Ｐａｔｈ Ｔｅｓｔｉｎｇ）というホワイトボックステスティング技法を使うことができるが、詳細にはＭｃＣａｂｅ（ＭｃＣａｂｅ、Ｔ．Ｊ．、１９７６、Ａ Ｃｏｍｐｌｅｘｉｔｙ Ｍｅａｓｕｒｅ、ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ、Ｖｏｌ．ＳＥ−２、Ｉｓｓｕｅ ４）を参照することができる。
独立的なプログラム経路を求めるために採用したグラフ理論によると、ノード（Ｎｏｄｅ）は判断（Ｄｅｃｉｓｉｏｎ）とプロセス（Ｐｒｏｃｅｓｓ）を足した値であり得る。グラフ理論によって独立的なプログラム経路を計算する計算式は次の通りであり得る。
Figure 2020510925
表６を参照すると、独立したプログラム経路はエッジの数からノードの数を引いた値（Ｅｄｇｅｓ−Ｎｏｄｅｓ）に２を足して導き出すことができ、地域（Ｒｅｇｉｏｎｓ）の個数に１を足したり、判断（Ｄｅｃｉｓｉｏｎｓ）の個数に１を足した値であり得る。
図５と図６を参照すると、図４での要約構文ツリーを２進のツリー形態に単純化した制御流れグラフを説明することができる。
具体的には、図４の要約構文ツリーを利用して図５のサンプルソースコードを図６の制御流れグラフ５００に生成することができ、生成した制御流れグラフの経路を訪問する方法で、独立した６個のプログラム経路５１０を導き出すことができる。
ここで図６によるプログラム経路５１０のそれぞれを導き出すことには図５によるサンプルソースコードを使った。図５で各列の番号は構文番号を指示し得、構文番号７でｉｆ文にそれぞれの条件式（ａｃｃＮｏ＜０，ｐａｙｄａｔｅ＜０）の成立の可否によって７．１、７．２で表したし、ｉｆ文を満足すれば構文番号８に経路が移動することができる。また、構文番号１１も条件文として分岐され得、構文番号１４のＳＱＬ文もＩＮＳＥＲＴの有無により他の経路に分岐され得る。
このように、それぞれの構文による独立した経路を追跡すれば、図６の制御流れグラフ５００とそれによるプログラム経路５１０を導き出すことができる。
ここで導き出したプログラム経路は、構文番号と分岐文であるかの可否を指示する情報が追加され得る。構文番号は実行する実際の構文を持ってくるために使われ得、分岐文の可否は該当経路を遂行する変数値に対する制約条件を作るために使われ得る。
図７は、経路６についてのシンボリック実行過程をシミュレーションした結果を示した図面である。
図７を参照すると、図２のプログラム経路によりシンボリック実行を遂行する段階Ｓ２２０を詳細に説明することができる。
具体的には、図７で（１）、（２）、（３）、（４）は、それぞれ図５での構文番号を指示することができる。ワンソースコードである図５とシンボリック実行結果である図７を互いに比較すると、図５で構文番号１〜４は変数を宣言する構文であるので、図７の（１）〜（４）は変数宣言部の変数をシンボル値に設定することができる。これを適用する一例として、変数の宣言部に値がなければ、変数名を大文字に変換し、その名称をシンボル値に設定することができ、宣言部に値があればその値を初期値に設定することができる。
シンボリック実行が進行されると、数字値である定数は計算されて一つの定数値となり得、シンボルは算術式でそのまま変数のように残ることができる。その結果、シンボリック実行を遂行した後にはシンボルで構成された一つの算術式が作られ得る。図７で独立的な経路を満足する一つの算術式は（７）と（１１）の論理式がＴＲＵＥとなる場合であり得る。このようなシンボリック実行の結果で生成された論理式は、以降、ソルバーによって該当論理式を満足する値の条件（制約条件）を導き出すのに適用され得る。
一方、図５の構文番号９および１４のようにＳＱＬ文が含まれている場合、シンボリック実行を遂行する時にいくつかの追加的な考慮が必要であり得る。そのうちの一つはホスト変数に対する分析および管理が必要であり得る。ホスト変数は、データベースコラムとマッピングされてデータベースに値を入力（または登録）したり、データベースから値を照会するために使われ得る。また、この値は反復的なテストができるようにデータベース環境を設定するのに重要な役割をすることができる。
次いで、ＳＱＬ文で使うＷＨＥＲＥ条件文の結果に注意する必要がある。ＳＥＬＥＣＴ文の場合、条件を満足するレコードがある時とない時の二つの場合を追加的に考慮することができる。したがって、独立したプログラム経路にＳＱＬ文がいくつあるかによってテストケースの個数が変わり得る。例えば、口座テーブルにはＡＣＣ＿ＮＯコラムの値がホスト変数であるａｃｃＮｏが有する値と同じレコードが存在してもよく、レコードがなくてもよい。したがって、二つの場合を考慮してテストケースを作り、該当するテストケースの値を計算することができる。
ＳＱＬ文で使うホスト変数について考慮する事項を調べるために、４種類のＳＱＬ文であるＳＥＬＥＣＴ、ＵＰＤＡＴＥ、ＩＮＳＥＲＴ、そしてＤＥＬＥＴＥ文を説明すると次の通りである。これらＳＱＬ文でＷＨＥＲＥ条件節を含んでいる構文は、ＳＥＬＥＣＴ、ＵＰＤＡＴＥ、そしてＤＥＬＥＴＥの三つのクエリ文である。これらクエリ文の条件節は既存のプログラミング言語と比較すると分岐文に該当するので、経路制約事項に含むことができる。
Figure 2020510925
表７を参照すると、サンプルソースコードである図５での構文番号７と９を表したものであって、具体的には、ｉｆ文のサンプルである構文番号７とＳＱＬ文で作成されたＳＥＬＥＣＴ文サンプルである構文番号９を表す。ＳＱＬクエリ文の実行結果が正常な照会になるには、構文番号７（ｉｆ文）の経路制約事項は下記のように変更されなければならない。
！（ａｃｃＮｏ＜０||ｐａｙＤａｔｅ＜０）
構文９でホスト変数：ａｃｃＮｏが有する値は、シンボリック実行を遂行すればＡＣＣＮＯというシンボル値となり得る。前の手続きを見ると、シンボリック実行は説明の便宜のために２パスで実行するものと仮定することができる。
まず、第１のパスはテストケースを生成するためのパスであり、ＳＱＬクエリ文のＷＨＥＲＥ節の条件を考慮してパスを細分化されなければならない。経路６はＳＥＬＥＣＴ文とＩＮＳＥＲＴ文の実行結果を成功と失敗の二つの場合として考慮すれば、これらの組み合わせで発生し得る経路は３個となる。ＳＥＬＥＣＴとＩＮＳＥＲＴの対を考慮すれば、成功と成功、成功と失敗、失敗と失敗（または成功）の３つの場合である。単純組み合わせでは４つの場合が発生するが、ＳＥＬＥＣＴが失敗であればＩＮＳＥＲＴ文は何の影響も与えることができないため除くことができる。
一方、シンボリック実行のパーシング段階でＳＱＬクエリ文に会うと、ＳＱＬクエリ文をパーシングしてＦＲＯＭ節で使うテーブルを探し、そのテーブルを構成するすべてのコラムを業務データベースのメタデータから持ってくることができる。
Figure 2020510925
表８を参照すると、Ｏｒａｃｌｅ ＤＢＭＳの場合、データベースのメタデータでテーブル名を条件としてすべてのコラムを照会するＳＥＬＥＣＴクエリ文を確認することができる。
Figure 2020510925
表９を参照すると、ＭｙＳＱＬでテーブル名とスキーマ名でメタデータであるコラム情報を照会するＳＥＬＥＣＴクエリ文を確認することができる。
テーブルのすべてのコラムに対するメタ情報をデータベースで照会した後にはコラムと値をマッピングするテーブルに保存することができる。
Figure 2020510925
表１０を参照すると、表２の口座テーブルに対するコラムとホスト変数マッピングテーブルを確認することができる。このテーブルのコラムは文章番号、テーブル名、コラム／定数、ホスト変数名、区分、項目の有無、そして値で構成され得る。ここでコラム／定数はコラム名または定数値を有することができる。定数値を有する場合は前述した表７でのように１００の値がａｄｄｉｎに設定される場合を仮定することができる。
ＳＱＬクエリ文にＷＨＥＲＥ条件がＫ＝？である場合を例にすると、？はホスト変数、定数、そしてコラムのうち一つとなり得る。万一？がホスト変数であれば、ホスト変数の値は順序上前の方で設定された値であるので、シンボリック実行中に該当ＳＱＬクエリ文の式を計算する時点の値を探す。ホスト変数の値は定数値でもよく、シンボルで構成された算術式でもよい。万一？が定数であれば、直ちにＫコラムに該当する値を割り当てる。しかし、？がシンボルで構成された算術式であれば、この時点で算術式に対する値を計算しなければならない。万一？がコラムであれば、ｊｏｉｎクエリである場合に発生することができるが、計算が若干複雑であるだけであって、類似する方法で適用することができる。
第２のパスはシンボリック実行をするものである。
Figure 2020510925
表１１はシンボリック実行の結果で作られるシンボルテーブルである。シンボルテーブルは変数、初期値、そしてシンボル式で構成され得る。
図７で（７）番ラインを実行する場合、経路制約条件は下記の通りである。
ＰＣ１：！（ＡＣＣＮＯ＜０||ＰＡＹＤＡＴＥ＜０）図７で（９）番ラインを実行すると、ＳＥＬＥＣＴ文のＦＲＯＭ節から抽出したテーブルであるＡＣＣテーブルのコラム目録を求めて次の表１２のようにコラムとＩＮＴＯ節の変数マッピングテーブルを作ることができる。
Figure 2020510925
表１２を参照すると、現在の経路のＷＨＥＲＥ節がｔｒｕｅであると仮定して計算を進めたコラムとＩＮＴＯ節の変数マッピングテーブルを確認することができる。
下記の表１３は図７の（９）番ラインによるＳＥＬＥＣＴ文の実行結果データベースで照会された値を反映したシンボルテーブルである。
Figure 2020510925
表１３を参照すると、各変数に対して照会された結果が反映されるが、例えば、ｌｏａｎＡｍｔはＬＯＡＮ＿ＡＭＴコラムで読んだＬＯＡＮＡＭＴＤＢの値となり得、ｉｎｔｅｒｅｓｔＲａｔｅはＩＮＴＥＲＥＳＴ＿ＲＡＴＥコラムで読んだＩＮＴＥＲＥＳＴＲＡＴＥＤＢ値となり得る。
一方、ＳＥＬＥＣＴ文のＷＨＥＲＥ条件節に対する値を求めると、ＷＨＥＲＥ条件節で使われる条件の類型にしたがって値を求めることができる。ホスト変数はシンボリック変数の実行時点に該当する値をシンボルテーブルで探してテーブルコラム構造体に登録するか修正し、シンボルテーブルになければ値に設定することができる。このような作業がすべて終了すると、シンボルで構成された算術式を再び計算することができる。定数の場合はコラムの値をすぐに＜表５＞のようにコラムとホスト変数マッピングテーブルの値のコラムに登録することができる。
図７の１０番ラインを実行すると、ｄａｙｓの式は下記のように導き出され得る。
ｄａｙｓ＝ＰＡＹＤＡＴＥ−ＬＯＡＮＤＡＴＥ
図７の１１番ラインを実行すると、経路制約条件は下記のように導き出され得る。
ＰＣ３：ＰＣ２ ＡＮＤ ｄａｙｓ＞０
図７の１３番ラインを実行すると、ｉｎｔｅｒｅｓｔの式は下記のように導き出され得る。
ｉｎｔｅｒｅｓｔ＝ＬＯＡＮＡＭＴ＊ＩＮＴＥＲＥＳＴＲＡＴＥ／１０００＊ｄ
ａｙｓ／３６５
前記式にｄａｙｓ式を代入すると、下記のように導き出され得る。
ｉｎｔｅｒｅｓｔ＝ＬＯＡＮＡＭＴ＊ＩＮＴＥＲＥＳＴＲＡＴＥ／１０００＊（
ＰＡＹＤＡＴＥ−ＬＯＡＮＤＡＴＥ）／３６５
表１４は、図７の１４番ラインを実行したマッピングテーブルである。
Figure 2020510925
図１４を参照すると、利子償還（ＲＥＰＡＹ）テーブルのコラムを照会して利子償還（ＲＥＰＡＹ）テーブルのコラムとホスト変数マッピングテーブルを生成することができる。
最後に図７の１５番ラインを実行すると、ｃａｌｃＩｎｔｅｒｅｓｔの式は下記のように導き出され得る。
ｃａｌｃＩｎｔｅｒｅｓｔ＝ＬＯＡＮＡＭＴ＊ＩＮＴＥＲＥＳＴＲＡＴＥ／１０
００ ＊（ＰＡＹＤＡＴＥ−ＬＯＡＮＤＡＴＥ）／３６５
シンボリック実行の終了後に、テーブルの表１０と表１４のようにコラムとホスト変数マッピングテーブルにある値が一つのシンボリック変数である場合には、デフォルト値を選択するか、データベースに設定されている制約事項に定義された値を選択することができる。一例として、ＬＯＡＮ＿ＰＥＲＩＯＤの値は乱数を利用して正数値を求めたり、ＬＯＡＮ＿ＴＹＰＥの値はコラム制約事項に宣言された値を使ったり、点検式で有効な値を類推することができる。
整理すると、図２でシンボリック実行を遂行する段階Ｓ２２０は、少なくとも一つ以上のプログラム経路にＳＱＬ文が含まれた場合、ソースコードのホスト変数とＳＱＬ文によってデータベースに含まれたテーブルのコラムをマッピングする段階を含むことができる。
ここで、マッピングする段階は、ＳＱＬ文をパーシングしてテーブルを確認する段階；確認したテーブルを構成するコラムをデータベースのメタデータを利用して獲得する段階および獲得したコラムをソースコードのホスト変数とマッピングする段階を含むことができる。
以下では、図２のシンボリック実行により生成された論理式に対してソルバーを利用してテストケースを生成する段階Ｓ２３０を具体的に説明する。
ソルバーを利用してテストケースを生成する段階Ｓ２３０は、生成された論理式をＳＭＴ（Ｓａｔｉｓｆｉａｂｉｌｉｔｙ Ｍｏｄｕｌｏ Ｔｈｅｏｒｉｅｓ）言語に変換する段階をさらに含むことができる。この段階は、ソルバーが論理式による制約事項を理解できる形態に変換する段階となり得る。ここでソルバーは例えばマイクロソフトで公開したＺ３を使うことができる。
また、ＳＭＴ言語に変換する過程は、詳細には、Ｍｏｕｒａ（Ｍｏｕｒａ、Ｌ． Ｄｅ、Ｂｊ〓ｒｎｅｒ、Ｎ．、２００８、Ｚ３：Ａｎ Ｅｆｆｉｃｉｅｎｔ ＳＭＴ Ｓｏｌｖｅｒ、１４ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ、ＴＡＣＡＳ ２００８、ｐｐ．３３７−３４０）とＢｒｕｍｍａｙｅｒ（Ｂｒｕｍｍａｙｅｒ、Ｒ．、Ｂｉｅｒｅ、Ａ．、２００９、Ｂｏｏｌｅｃｔｏｒ：Ａｎ Ｅｆｆｉｃｉｅｎｔ ＳＭＴ Ｓｏｌｖｅｒ ｆｏｒ Ｂｉｔ−Ｖｅｃｔｏｒｓ ａｎｄ Ａｒｒａｙｓ、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １５ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｔｏｏｌｓ ａｎｄ Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ ｔｈｅ Ｃｏｎｓｔｒｕｃｔｉｏｎ ａｎｄ Ａｎａｌｙｓｉｓ ｏｆ Ｓｙｓｔｅｍｓ：Ｈｅｌｄ ａｓ ｐａｒｔ ｏｆ ｔｈｅ Ｊｏｉｎｔ ＥｕｒｏｐｅａｎＣｏｎｆｅｒｅｎｃｅ ｏｎ Ｔｈｅｏｒｙ ａｎｄ Ｐｒａｃｔｉｃｅ ｏｆ Ｓｏｆｔｗａｒｅ、ｐｐ．１７４−１７７）を参照することができる。
図７を再び参照すると、経路６のシンボリック実行で、構文番号１１番ラインで計算しなければならない制約事項は（７）と（１１）をすべて満足しなければならないので、下記のように導き出され得る．ＰＣ２ ＡＮＤ ｄａｙｓ＞０＝＞！（ＡＣＣＮＯ＜０||ＰＡＹＤＡＴＥ＜０） ＆＆！（（ＰＡＹＤＡＴＥ −ＬＯＡＮＤＡＴＥＤＢ）＜０）
表１５は前記制約事項をＳＭＴ言語に変換した結果を示した図面である。
Figure 2020510925
表１５を参照すると、制約事項をソルバーが解析可能な形態であるＳＭＴ言語に変換されたスクリプトを確認することができ、変換されたスクリプトをソルバーを通じて実行すると、シンボリック変数に該当する値を求めることができる。先に関数の入力と出力に該当するシンボルの値を求めることができる。前記の例題において、関数の入力であるａｃｃＮｏとｐａｙＤａｔｅの具体的な値はそれぞれＡＣＣＮＯとＰＡＹＤＡＴＥというシンボルが計算されて導き出され得る。また、ここでＬＯＡＮＤＡＴＥＤＢはシンボルではなくデータベースで照会した定数値を意味し得る。
一方、本発明でのテストケースは、データベースと連動するシステムに適用され得るようにデータベース設定値を含むことができる。したがって、データベース設定値を生成する方法を以下で説明する。
データベース設定値は、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、またはＤＥＬＥＴＥ文の形態で生成され得る。テスト実行時ごとに業務プログラムで使うテーブルに対して、これらのクエリ文を実行してテストを実行する直前のデータベースの状態を作ることができる。
Figure 2020510925
ＳＥＬＥＣＴ文の照会結果がある場合をテストするには、表１６のようなクエリ文をデータベース設定値として生成することができる。テスト実行時点に口座テーブルにデータがなければならない場合であって、テーブルにレコードがなければＩＮＳＥＲＴ文で新しく登録し、データがあればＵＰＤＡＴＥ文で該当レコードの値を修正することができる。
Figure 2020510925
ＳＥＬＥＣＴ結果がない場合をテストするためには、表１７のようなクエリ文を生成することができる。口座テーブルにレコードがあるかないかにかかわらず、ＤＥＬＥＴＥ文を実行してレコードを確実に削除することができる。
Figure 2020510925
図７の１４番ラインのＩＮＳＥＲＴ文に対する重複テストをする場合、データベース環境を設定するためには表１８のようなクエリ文を生成することができる。
表１４を参照すると、テスト実行時点に利子償還（ＲＥＰＡＹ）テーブルにレコードがなければＩＮＳＥＲＴ文を実行してレコードを登録し、レコードがあればＵＰＤＡＴＥ文を実行して該当レコードの値を変更することができる。
Figure 2020510925
表１９は、ＩＮＳＥＲＴ文に対して正常に登録される場合をテストするためのデータベース環境を設定するためのクエリ文である。表１９を参照すると、利子償還テーブルに該当レコードがあるかどうかにかかわらず、テーブルでレコードを削除して該当レコードがテーブルに存在しないようにすることができる。
前記において、図６で導き出したプログラム経路６のテストケースは３個となり、テストケースはＳＱＬクエリ文ごとに略２の倍数で増加し得る。したがって、テストケースの数は算術的には２クエリ個数だけ生成され、経路６によって生成されたテストケースを要約すると次の表２０の通りである。
Figure 2020510925
表２０を参照すると、テストケース６−１は口座を保有しているが利子を償還していない場合をテストすることができる。この時、入力値はテーブルに登録された口座番号である１２３４５６７８９０１２３４とシンボリック実行の結果であるＰＡＹＤＡＴＥとなり得る。また、データベース設定値はＩＮＳＥＲＴ文で口座を登録し、ＤＥＬＥＴＥ文で利子償還履歴を削除することができ、ＩＮＳＥＲＴ文のＬＯＡＮ＿ＰＥＲＩＯＤとＬＯＡＮ＿ＭＥＴＨＯＤ値は任意の値であるが、口座テーブルの照会結果値として設定することができる。
テストケース６−２は口座を保有し利子を償還した場合をテストすることができる。入力値は６−１と同じであり得、データベース設定値は口座と利子償還履歴をＩＮＳＥＲＴ文で登録するものであり得る。この時、ＲＥＰＡＹ＿ＤＡＴＥはＴＯＤＡＹというマクロを使って値を設定することができる。テストケース６−３は口座がない場合をテストすることができる。したがって、この場合に入力値としては口座テーブルに存在しない口座番号である０を使用することができ、データベースの設定値としては口座と利子償還履歴をＤＥＬＥＴＥ文ですべて削除することができる。
データベース設定値はシンボリック計算によって計算された値もあるが、シンボリック計算で計算できない項目も存在し得る。これらを自由変数（ｆｒｅｅ ｖａｒｉａｂｌｅｓ）と指称することができ、いかなる値がきてもよいが、できるだけ現実的な値を生成できるように、データベースの制約事項やアプリケーションが実行しながら残した取引ログ情報を参照して実際に近いように生成することができる。
一方、本発明に係るテストケースはテストの正確性をテストできるように、入力値に対応した出力値を確認できる予想出力値（または予想結果値）とテスト結果データベースに実際に保存される値を確認できるデータベース予想結果値（または予想確認値）を含むことができる。
表２１は、テスト結果を確認できる出力予想値とデータベース予想結果値についての表である。
Figure 2020510925
表２１を参照すると、予想出力値（または予想結果値）は関数の返還値であり得る。具体的には、６−１で予想出力値（または予想結果値）のｃａｌｃＩｎｔｅｒｅｓｔに対する値はシンボリック実行の結果値であるＰＡＹＤＡＴＥとデータベースで照会された値であるＬＯＡＮＡＭＴＤＢ、ＬＯＡＮＤＡＴＥＤＢ、ＩＮＴＥＲＥＳＴＲＡＴＥＤＢから導き出され得る。
また、データベース予想結果値（または予想確認値）はＳＥＬＥＣＴ文で生成され得る。データベース予想結果値はＳＥＬＥＣＴ文を実行して出た結果値ａ||ｂのように、区分子に区分された文字列を||区分子で分けて左右の値を比較して、データベースの予想結果値と実際の結果値が同じであるかを確認するために使うことができる。
また、テストケース６−２と６−３は予想結果値が返還されたエラー値であって、この時、データベース予想結果値（または予想確認値）は表２０のように生成するか最初から生成しないように選択することができる。
整理すると、自動で生成されるテストケースはテストの結果を確認するために入力値に対応して予想出力値を生成し、データベース設定値に対応してデータベース予想結果値を生成することができる。また、図２のテストケースを生成する段階Ｓ３００後に生成したテストケースを、ＸＭＬ、ＪＳＯＮのうち一つのフォーマットで保存する段階をさらに含むことができる。ただしこれに限定されるものではなく、文字列、バイナリーなどの形態で保存されてもよい。
この時、テストケースが保存される位置情報はｉｎｆｏタグを付与して参照され得、ｉｎｆｏタグが有している位置情報である経路、ファイル名、メソッド名、テストケース番号を主キー （ｐｒｉｍａｒｙ ｋｅｙ）にして保存され得る。したがって、テストケースのみを管理するために別途のテストケースデータベースが具現され得る。
また、テストケースはテスト対象システムが変更されることによって同期化されなければならない必要がある
同期化方法の一つはテスト対象システムを変更したときに直ちにすべてのテストケースを変更する方法であり、他の一つはテストを実行する時点で同期化してテストケースを変更する方法であり得る。前者の場合は常にテスト対象システムとテストケースが一致する長所があるものの、大量に変更がある場合にはテストを遂行する全体の性能に影響を及ぼす短所が存在し得る。後者の場合は実行時点で同期化を遂行するため、テスト実行時間が長くなる短所が存在し得る。
図８は、本発明の一実施例に係るテストを遂行する過程についての第１例示図である。図９は、本発明の一実施例に係るテストを遂行する過程についての第２例示図である。
図８および図９を参照すると、テスト対象システムの形態に応じて互いに異なる方法でテストを遂行する過程を説明することができる。
本発明に係るテスト対象システムはサービスであるか、モジュールであり得る。
まず、図８を参照してテスト対象システム（ＳＵＴ）がモジュールである場合にテストを遂行する方法を説明することができる。
テストを遂行する時に実行されるテストドライバーの生成方式は、テスト対象システムの形態によって変わり得る。テスト対象システムの形態は、ソースコードの形態またはオブジェクトの形態、そして共有ライブラリの形態で提供され得る。テスト対象がソースコードの形態またはオブジェクトの形態である場合にはテスト対象を含んでビルド（コンパイルとリンク）を遂行しなければならないため、ビルド環境の構成が複雑となり得る。このような形態である場合には、テスト対象がテストドライバーと一体にビルドされて実行されてテスト対象にエラーがあればテストビルドとならない短所がある。テスト対象が共有ライブラリの形態である場合には、テスト実行のためにモジュールの動的呼び出しを利用することができる。該当モジュールの共有ライブラリが存在するということは、テスト対象であるモジュールにエラーがないということを意味し得る。
図８を参照すると、本発明でテスト対象システムがモジュールである場合のテスト実行方法は、テストケースに含まれたデータベース設定値をテスト対象システムのデータベースに適用する段階、テストケースに含まれた入力値でテスト対象システムの入力パラメーターを設定する段階、設定した入力パラメーターでテスト対象システムの関数を呼び出す段階および関数呼び出しの結果でテスト対象システムの出力値をテストケースに含まれた予想出力値と比較し、データベースに保存された結果値とテストケースに含まれたデータベース予想結果値と比較する段階を含むことができる。
ここで、各段階はコンパイルされたテストドライバーを実行することによって遂行され得る。
ここで、テスト対象システムの出力値と予想出力値を構成する構造体およびデータベースのテーブルとコラムは、開発過程で随時変更され得るため、変化をリアルタイムで感知して同期化する機能をさらに支援することができる。
このようにテストドライバー生成によるテスト方式は、テスト管理者がトランザクションを直接制御することができ、実際のテスト環境を完全に構築しなくてもテストすることができるという長所がある。
Figure 2020510925
表２２はテストドライバーを利用したテスト方法に対するソースコードである。表２２を参照すると、データベースに設定値を入力することができ、テストケースの入力値をテスト対象システムの関数パラメーターとして入力することができ、それにより実行された結果を比較することができる。
一方、図９を参照すると、テスト対象システムがサービスである場合、テストする方法を説明することができる。
具体的には、テスト対象システムがミドルウェアサービスである場合、テストを遂行する方法は、テストケースを利用して入力全文を生成する段階、テスト対象システムが連動するミドルウェアのサービスを呼び出して前記入力全文を前記ミドルウェアに伝送する段階およびミドルウェアからテスト結果全文を受信する段階を含むことができる。
ここで入力全文を生成する段階は、テストケースが生成されると、ＸＭＬ、ＪＳＯＮのような全文形態で先に保存されて保管することができるので、保存された全文を獲得する段階に処理されてもよい。
また、ここで、入力全文を生成する段階後に、ミドルウェアサービスで支援するフォーマットに入力全文を変換する段階をさらに含むことができる。これはテストケースを保存して使う入力全文のフォーマットとミドルウェアサービスで支援するフォーマットとが異なり得るため、互換性を保証するためのものであり得る。
ここで、テスト対象システムの開発に使われるミドルウェアは、Ｓｏｃｋｅｔ、ＲＭＩ、ＲＰＣ、ＨＴＴＰ、ＴＵＸＥＤＯ、Ｔ−ｍａｘ、Ｅｎｔｅｒａなどが存在し得る。開発されたテスト対象システムが使うミドルウェアによりサービス呼び出し方式が決定され得、トランザクションの制御方法も変わり得る。ＴＵＸＥＤＯとＴ−ｍａｘのような常用ミドルウェアは２ Ｐｈａｓｅ Ｃｏｍｍｉｔを提供するので、テスト時にデータベースの環境設定および予想結果処理とデータベースにテスト結果を残すなどのテスト作業と業務作業と関連したトランザクションを効果的に制御することができる。また、テスト対象システムがフレームワークを使うのであれば、テスト対象システムはより構造化された形態を提供することができる。フレームワークは、業務の一つのトランザクションを処理するために前処理と後処理のようなインターセプトルーチンを呼び出しできるようにして、サービスを呼び出す前に共通で使う機能を実行することができる。このような前処理と後処理にデータベース環境設定および予想結果を処理するモジュールを入れ込んで効果的にトランザクションを処理することができる。
表２３は、ミドルウェア基盤のテスト対象システムをテストするサンプルコードである。
Figure 2020510925
表２３を参照すると、テストエージェント側での各過程とミドルウェアのフレームワークが遂行する各過程を確認することができる。
前記過程を詳細に説明すると、第１、テストエージェントはプログラム番号とテストケース番号でテストケースの入力全文を照会し、入力全文の予備領域に値を設定することができる。
第２、テストエージェントは入力全文をフレームワークに送ってサービスを呼び出すことができる。フレームワークは全文の予備領域に含まれて伝送されたプログラム番号とテストケース番号をサービスの前処理モジュールに渡すことができる。サービスの前処理モジュールでは、プログラム番号とテストケース番号を利用してテストケースが保存されたデータベースからデータベース設定値を読み込んでテスト実行前の環境を設定することができる。そして、フレームワークは業務ロジックを実行するために、テスト対象システムを呼び出すことができる。ＳＵＴは連動された業務データベースのデータを操作しながら業務処理を遂行することができる。最後に、フレームワークはプログラム番号とテストケース番号でデータベース予想結果値を持ってくることができる。そして、業務データベースにクエリを実行して予想結果値と実際の結果値を対照してテストの正確性を確認することができる。以上の各段階ではテストを遂行した結果を管理するために、必要な情報を残らずテストデータベースに記録することができる。
第３、テストケース結果全文処理モジュールはプログラム番号とテストケース番号でテストケースの予想結果全文を照会することができる。テストケース結果全文処理モジュールは予想出力値と実際の出力全文の各値を比較して、その結果をテストケースが記録されるデータベースに保存することができる。
したがって、ミドルウェア（またはミドルウェアのフレームワーク）は、入力全文から前記テストケースのデータベース設定値を確認し、確認したデータベース設定値を利用して前記データベースに対する初期設定を遂行し、入力全文から前記テストケースの入力値を確認して前記テスト対象システムの入力パラメーターとして入力して前記テスト対象システムを実行するように構成され得る。
ミドルウェアによるテスト方式は、ソースコードを生成せずに一般化されたモジュールを利用してテストエージェントを作ることができる。また、業務システムがフレームワークを使用して開発されるのであれば、２ Ｐｈａｓｅ Ｃｏｍｍｉｔトランザクション管理を使用できる利点もある。
ここで、テスト結果の中には静的に定義できない値がある。例えば、テストを実行するたびに生成される一連番号やテストの実行時点の日付や時間のように、毎度変わる情報はテスト結果の不確実性を増加させ得る。したがって、これに対するテストケースとして、予想出力値やデータベースの予想結果値を明確に定義してテストし難い場合が存在し得る。
このような場合、テスト結果の判断対象としなくてもよく、マクロ、参照、スクリプトのような値を定義してロジックで対応してもよい。また、値は定数値、マクロ、参照、スクリプトにより区分して入力することができる。例えば定数値は数字や文字列であり得、マクロはＴＯＤＡＴＥのようにあらかじめ定義された名前で定めることができ、現在の日付と同じ場合にはシステムの現在の日付を照会して使うこともできる。参照はテストケースが保存された形式である全文の特定のコラム値を持ってくることもできる。スクリプトはスクリプトを実行して出た結果値を出力値と比較することができる。ただし、スクリプトはマクロを含む意味であり得る。
したがって予想出力値は、前記テスト対象システムの実行時ごとに出力値が変更される場合、前記テストケースから除外されるか、マクロ、参照、スクリプトのうち一つの方法で決定され得る。
一方、前記で生成したテストケースを利用してテストを遂行する過程には多様なテスト方式が適用され得る。テスト方式には単位テスト、統合テストまたは回帰テストが存在し得る。
まず、単位テストはソースコードの個別単位をテストするソフトウェアテスト方法である。ここで、単位はアプリケーションの最も小さい単位であり、テストできるラインの集合を意味し得る。単位テストは開発の初期段階で問題点を探すためのテスト方法であって、プログラマーが具現時点で作ったバグや明細書の欠陥や逃したものを探すことに目的がある。単位テストを終えたモジュールは、回帰テストで使われる時に正確に動作するという点が保証できる。したがって、単位テストのテストケースは欠陥が発生する可能性があるプログラムのために作成することができる。このように作成した単位テストケースは、単位テストを経たプログラムを対象とする回帰テストにおいても使用できるだけでなく、安定したモジュールし統合しなければならない統合テストにおいても活用することができる。しかし、単位テストでプログラムに存在するすべてのエラーを捜し出せるわけではなく、単位自らの機能だけをテストするので、統合エラーやシステムエラーのようなエラーは探し出せない場合もある。
図１を再び参照すると、自動で生成されたテストケースは単位テストで使うことができる。シンボリック実行器で生成したテストケースは先にテストＤＢに保存され得る。この時、ユーザーと管理者は前述した通り、自動生成されたテストケースに対して適切な名前を付与して管理することもできる。
そして、ユーザーと管理者はいつでもテスト時点でこれらを使用することができ、所望の時にテスト結果をすぐに確認することもできる。自動で生成されたテストケースが正確性を要求するテストに適用されるのであれば、少ない努力で多くのテストを実行してテストカバレッジを最大限に高めることができる。最後に、単位テスト結果は自動でテストデータベースに集計され統計で累積されて、管理者がリアルタイムでテスト現況を把握しやすく情報を提供することができる。
次いで、統合テストは単位モジュールまたはサービスを一連の順序で連結してテストを遂行するソフトウェアテスティング方法で定義することができる。統合テストは単位テストを完了したプログラムを対象とし、示範店または
全店 など検証テスト前に分析／設計者によって実行され得る。
統合テスト方法は、ビッグバン方式とトップダウン方式、ボトムアップ方式、そしてハイブリッド方式が存在し得る。ビッグバン方式は開発されたモジュールを一度に全体を統合してテストする方式である。ビッグバン方式は統合テスト時間を短縮できる長所があるものの、単位プログラムが十分にテストされていない状態でテストをすると、かえってより多くの時間と努力が投入される可能性がある。ボトムアップ方式は最も下位の単位を先に統合してテストする方式である。テストする上位の単位と関連した下位の単位がすべてテストされるとすぐに上位の単位をテストするなどの手続きを繰り返して最上位の単位までテストすることができる。トップダウン方式は最上位の単位からテストを遂行することができる。その後、下位の単位を繰り返してテストを遂行することができる。ハイブリッド方式はボトムアップとトップダウン方式を混用して進行する方式であり得る。統合テストでは、統合テスト明細に記述されていない条件はテストしなくてもよい。自動で生成されたテストケースを活用して開発者はモジュール統合またはサービス統合テストを構成することができる。
モジュール統合テストはモジュールを順に構成してテストを遂行することができる。すなわちモジュールを順に構成するテストドライバーを生成することができる。モジュールで最上位の関数をテストすると下位の関数が呼び出されて実行されるという特徴がある。ユーザー登録モジュール、ユーザー目録照会モジュール、ユーザー修正モジュール、そしてユーザー削除モジュールを一連のシナリオに構成してテストすることができる。
サービス統合テストはサービスを順に構成してテストする方式である。モジュール統合テストでのように、ユーザー登録サービス、ユーザー目録照会サービス、ユーザー修正サービス、そしてユーザー削除サービスを一連のシナリオに構成すると仮定すれば、テスターはテストＤＢでユーザーを登録するテストケースを選択することができる。そして、正常にユーザーが登録されたかを確認するために、先に登録したユーザー番号でユーザー目録を照会するテストケースを選択することができる。そして、登録されたユーザーの情報を修正するテストのためのテストケースを選択することができる。この時、同じユーザー番号で修正するテストができるように、同じユーザー番号を指定することができる。最後に、ユーザー削除をテストするためにユーザー削除テストケースを選択することができる。同様に同じユーザー番号を指定して削除をテストできるようにする。
このように単位テストケースを連結してサービス統合テストを遂行することができる。シナリオを構成するテストケースは同じユーザー番号を使わなければならないため、ユーザー登録テストケースで登録したユーザー番号を、以降のテストケースで使用できる方法を提供することができる。このための非常に簡単な方法の一つは、正確性判断のために以前にテストケースで使われた入力値または実際の出力値を参照できる方法を提供することである。
統合テストの結果はシナリオを構成する個別テストケースの結果も管理しなければならず、シナリオの全体の結果も管理しなければならない。また、一つのシナリオに対するテスト結果、テストシナリオの履歴、そしてシナリオの変更履歴などの管理が必要であり得る。管理者はシナリオ全体が成功したかに関心があり、開発者はシナリオが失敗した場合、どこで失敗したのか失敗の原因は何であるかを確認できる情報に関心がある。
回帰テストは、以前に開発されたソフトウェアが変更後にも相変らずよく動作するかを確認するためのソフトウェアテスティング技法である。ソフトウェアの変更は改善、パッチ、そして形状の変更などによって発生し得る。回帰テストは新しいバグやプログラムの変更（追加、削除、修正を通称）により発生する回帰エラーを捜し出すことに目的があり得る。
回帰テスト方式には全体のテストケースをすべて実行する方法もあれば、プログラムの変更に影響を受けたプログラムを探してテストする方法もあり得る。全体のテストケースをすべて実行する方法が最も理想的であるが、８時間以内にテストを完了しなければならないように、テスト時間に制約がある場合にはこの方法を使うのが困難な場合もある。
影響度分析を通じてプログラムの変更に影響を受けた対象を探すのを回帰分析と言い、分析結果は回帰テストケースを選別する基準となり、回帰分析の結果を利用して回帰テストを遂行することができる。回帰テストはプログラムが修正されて影響を受けたプログラムのテストケースのみを探してテストを実行することが有利であり得る。
関数（またはメソッド）レベルで回帰分析する方法を説明すると、まずプログラムの修正で影響を受けた関数を探し、その関数を使用する親関数とその親関数をすべて探すまで繰り返すことができる。影響を受けるすべての関数を探した後は重複した関数を除去することができる。最後に、整理された関数に付いているテストケースを順次実行することができる。
回帰テストで使うテストケースは単位テストケースの形態でもよく、統合テストケースの形態でもよい。回帰テストでは可能なすべてのテストケースを利用してもよく、また、効率的にテストするために回帰テストで使うテストケースを指定してもよい。回帰テストの結果はテストＤＢに保存され得る。また、決裁システムと連動してエラー発生時には運営システムに変更されたプログラムが積載されないように措置してもよい。
回帰テストは反復漸進的な開発方法では必須に遂行すべきテストであり得る。反復漸進的な開発は、毎日開発されたプログラムは形状管理システムにコミットされ、自動ビルドシステムは形状管理からプログラムをダウンロードしてビルドを遂行し、影響度分析を通じて影響を受けた関数を探してテストケースを実行する一連の過程が繰り返され得る。
影響度分析を例にすると、まず、業務テーブルからコラムを削除すると仮定する。影響度分析システムは削除されたコラムを使う関数（この時、関数が含まれたプログラムも分かる）を探すことができる。この関数を使用する親関数をすべて探すまで繰り返して探すことができる。探した関数の中から同じ関数を除去することができる。重複除去された関数の目録を利用して関数に付いているテストケースを探すことができる。このテストケースをすべて実行して回帰テストを完了することができる。
影響度分析で最も重要な要因の一つは、影響を受けたテストケースの最小集合を求めることであり得る。このような目的を達成するために静的分析技法を利用することができる。静的分析技法を利用して該当制御の流れを追跡して影響を受けるベーシスパスを探し、これらと関連したテストケースを探して最小限のテストケース集合を抽出することができる。
本発明の一実施例に係るテストケース生成装置は、少なくとも一つの命令を実行するプロセッサおよび少なくとも一つの命令を保存するメモリーを含むことができる。
ここで、プロセッサは、シンボリック実行に基づいて、ＳＱＬ文を含むソースコードに対して少なくとも一つ以上のプログラム経路を決定し、少なくとも一つ以上のプログラム経路によりシンボリック実行を遂行し、シンボリック実行により生成された論理式に対してソルバーを利用してテストケースを生成することができる。
ここで、プロセッサは、ソースコードをパーシングして要約構文ツリーを生成し、生成した要約構文ツリーに基づいて、制御流れグラフを生成し、制御流れグラフに基づいて少なくとも一つ以上のプログラム経路を決定することができる。
本発明の一実施例に係るテストケースを利用したテスト装置は、少なくとも一つの命令を実行するプロセッサ、少なくとも一つの命令を保存するメモリーを含むことができる。
ここで、プロセッサは、シンボリック実行に基づいてＳＱＬ文を含むソースコードに対するテストケースを生成し、データベースと連動するテスト対象システムにテストケースを適用してテストを遂行し、テストケースはテスト対象システムの入力値、入力値がテスト対象システムで処理される時に出力値を予測した予想出力値、データベースの設定値およびテスト対象システムが設定値が適用されたデータベースと連動して処理される時、データベースに保存される結果値を予測した予想結果値のうち少なくとも一つを含むことができる。
ここで、プロセッサは、ソースコードに対して少なくとも一つ以上のプログラム経路を決定し、少なくとも一つ以上のプログラム経路によりシンボリック実行を遂行し、シンボリック実行により生成された論理式に対してソルバーを利用してテストケースを生成することができる。
ここで、プロセッサは、ソースコードをパーシングして要約構文ツリーを生成し、生成した要約構文ツリーに基づいて、制御流れグラフを生成し、制御流れグラフに基づいて少なくとも一つ以上のプログラム経路を決定することができる。
ここで、プロセッサは、少なくとも一つ以上のプログラム経路にＳＱＬ文が含まれた場合、ソースコードのホスト変数とＳＱＬ文によってデータベースに含まれたテーブルのコラムをマッピングすることができる。
ここで、プロセッサは、ＳＱＬ文をパーシングしてテーブルを確認し、確認したテーブルを構成するコラムをデータベースのメタデータを利用して獲得し、獲得したコラムをソースコードのホスト変数とマッピングすることができる。
ここで、プロセッサは生成したテストケースをＸＭＬ、ＪＳＯＮのうち一つのフォーマットで保存することができる。
ここで、プロセッサは、テスト対象システムがモジュールである場合、設定値をデータベースに適用し、入力値でテスト対象システムの入力パラメーターを設定し、設定した入力パラメーターでテスト対象システムの関数を呼び出し、関数呼び出しの結果で獲得したテスト対象システムの出力値を予想出力値と比較し、データベースに保存された結果値と予想結果値とを比較することができる。
ここで、プロセッサは、テスト対象システムがミドルウェアサービスである場合、テストケースを利用して入力全文を生成し、テスト対象システムが連動するミドルウェアのサービスを呼び出して入力全文をミドルウェアに伝送し、ミドルウェアからテスト結果全文を受信することができる。
前述したテストケース生成装置またはテストケースを利用したテスト装置は、通信可能なデスクトップコンピュータ（ｄｅｓｋｔｏｐ ｃｏｍｐｕｔｅｒ）、ラップトップコンピュータ（ｌａｐｔｏｐ ｃｏｍｐｕｔｅｒ）、ノートパソコン（ｎｏｔｅｂｏｏｋ）、スマートフォン（ｓｍａｒｔ ｐｈｏｎｅ）、タブレットＰＣ（ｔａｂｌｅｔ ＰＣ）、モバイルフォン（ｍｏｂｉｌｅ ｐｈｏｎｅ）、スマートウォッチ（ｓｍａｒｔ ｗａｔｃｈ）、スマートグラス（ｓｍａｒｔ ｇｌａｓｓ）、ｅ−ｂｏｏｋリーダー、ＰＭＰ（ｐｏｒｔａｂｌｅ ｍｕｌｔｉｍｅｄｉａｐｌａｙｅｒ）、携帯用ゲーム機、ナビゲーション（ｎａｖｉｇａｔｉｏｎ）装置、デジタルカメラ（ｄｉｇｉｔａｌ ｃａｍｅｒａ）、ＤＭＢ（ｄｉｇｉｔａｌ ｍｕｌｔｉｍｅｄｉａｂｒｏａｄｃａｓｔｉｎｇ）再生機、デジタル音声録音機（ｄｉｇｉｔａｌ ａｕｄｉｏｒｅｃｏｒｄｅｒ）、デジタル音声再生機（ｄｉｇｉｔａｌ ａｕｄｉｏｐｌａｙｅｒ）、デジタル動画録画機（ｄｉｇｉｔａｌ ｖｉｄｅｏ ｒｅｃｏｒｄｅｒ）、デジタル動画再生機（ｄｉｇｉｔａｌ ｖｉｄｅｏ ｐｌａｙｅｒ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）等であり得る。
本発明に係る方法は、多様なコンピュータ手段を通じて実行され得るプログラム命令の形態で具現されてコンピュータ読み取り可能媒体に記録され得る。コンピュータ読み取り可能媒体は、プログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含むことができる。コンピュータ読み取り可能媒体に記録されるプログラム命令は、本発明のために特別に設計されて構成されたものであるかコンピュータソフトウェア当業者に公知とされて使用可能なものでもよい。
コンピュータ読み取り可能媒体の例には、ロム（ＲＯＭ）、ラム（ＲＡＭ）、フラッシュメモリー（ｆｌａｓｈ ｍｅｍｏｒｙ）等のように、プログラム命令を保存して遂行するように特別に構成されたハードウェア装置が含まれ得る。プログラム命令の例には、コンパイラ（ｃｏｍｐｉｌｅｒ）により作られるような機械語コードだけでなく、インタープリタ（ｉｎｔｅｒｐｒｅｔｅｒ）等を使ってコンピュータによって実行され得る高級な言語コードを含むことができる。前述したハードウェア装置は、本発明の動作を遂行するために少なくとも一つのソフトウェアモジュールで作動するように構成され得、その逆も同様である。
また、前述した方法または装置はその構成や機能の全部または一部が結合されて具現されたり、分離して具現され得る。
前記では本発明の好ましい実施例を参照して説明したが、該当技術分野の熟練した当業者は、下記の特許請求の範囲に記載された本発明の思想および領域から逸脱しない範囲内で本発明を多様に修正および変更できることが理解できるはずである。

Claims (20)

  1. シンボリック実行に基づいてＳＱＬ文を含むソースコードに対するテストケースを生成する段階；および
    データベースと連動するテスト対象システムに前記テストケースを適用してテストを遂行する段階を含み、
    前記テストケースは、前記テスト対象システムの入力値、前記入力値が前記テスト対象システムで処理される時に出力値を予測した予想出力値、前記データベースの設定値および前記テスト対象システムが前記設定値が適用された前記データベースと連動して処理される時、前記データベースに保存される結果値を予測した予想結果値のうち少なくとも一つを含む、テストケースを利用したテスト方法。
  2. 前記テストケースを生成する段階は、
    前記ソースコードに対して少なくとも一つ以上のプログラム経路を決定する段階；
    前記少なくとも一つ以上のプログラム経路により前記シンボリック実行を遂行する段階；および
    前記シンボリック実行により生成された論理式に対してソルバーを利用してテストケースを生成する段階を含む、請求項１に記載のテストケースを利用したテスト方法。
  3. 前記プログラム経路を決定する段階は、
    前記ソースコードをパーシングして要約構文ツリーを生成する段階；
    生成した要約構文ツリーに基づいて、制御流れグラフ（を生成する段階；および
    前記制御流れグラフに基づいて少なくとも一つ以上のプログラム経路を決定する段階を含む、請求項２に記載のテストケースを利用したテスト方法。
  4. 前記シンボリック実行を遂行する段階は、
    前記少なくとも一つ以上のプログラム経路にＳＱＬ文が含まれた場合、
    前記ソースコードのホスト変数と前記ＳＱＬ文により前記データベースに含まれたテーブルのコラムをマッピングする段階を含む、請求項２に記載のテストケースを利用したテスト方法。
  5. 前記マッピングする段階は、
    前記ＳＱＬ文をパーシングしてテーブルを確認する段階；
    確認したテーブルを構成するコラムを前記データベースのメタデータを利用して獲得する段階；および
    獲得したコラムを前記ソースコードのホスト変数とマッピングする段階を含む、請求項４に記載のテストケースを利用したテスト方法。
  6. 前記テストケースを生成する段階後に、
    生成したテストケースをＸＭＬ、ＪＳＯＮのうち一つのフォーマットで保存する段階をさらに含む、請求項１に記載のテストケースを利用したテスト方法。
  7. 前記テストを遂行する段階は、
    前記テスト対象システムがモジュールである場合、
    前記設定値を前記データベースに適用する段階；
    前記入力値で前記テスト対象システムの入力パラメーターを設定する段階；
    設定した入力パラメーターで前記テスト対象システムの関数を呼び出す段階；および
    関数呼び出しの結果で獲得された前記テスト対象システムの出力値を前記予想出力値と比較し、前記データベースに保存された結果値と前記予想結果値を比較する段階を含む、請求項１に記載のテストケースを利用したテスト方法。
  8. 前記テストを遂行する段階は、
    前記テスト対象システムがミドルウェアサービスである場合、
    前記テストケースを利用して入力全文を生成する段階；
    前記テスト対象システムが連動するミドルウェアのサービスを呼び出して前記入力全文を前記ミドルウェアに伝送する段階；および
    前記ミドルウェアからテスト結果全文を受信する段階を含む、請求項１に記載のテストケースを利用したテスト方法。
  9. 前記ミドルウェアは、
    前記入力全文から前記テストケースのデータベース設定値を確認し、確認したデータベース設定値を利用して前記データベースに対する初期設定を遂行し、
    前記入力全文から前記テストケースの入力値を確認して前記テスト対象システムの入力パラメーターとして入力して前記テスト対象システムを実行するように構成される、請求項８に記載のテストケースを利用したテスト方法。
  10. 前記予想出力値は、
    前記テスト対象システムの実行時ごとに出力値が変更される場合、前記テストケースから除外されるか、マクロ、参照、スクリプトのうち一つの方法で決定される、請求項１に記載のテストケースを利用したテスト方法。
  11. 少なくとも一つの命令を実行するプロセッサ；および
    前記少なくとも一つの命令を保存するメモリーを含み、
    前記プロセッサは、
    シンボリック実行に基づいて、ＳＱＬ文を含むソースコードに対して少なくとも一つ以上のプログラム経路を決定し、前記少なくとも一つ以上のプログラム経路により前記シンボリック実行を遂行し、前記シンボリック実行により生成された論理式に対してソルバーを利用してテストケースを生成する、テストケース生成装置。
  12. 前記プロセッサは、
    前記ソースコードをパーシングして要約構文ツリーを生成し、生成した要約構文ツリーに基づいて、制御流れグラフを生成し、前記制御流れグラフに基づいて少なくとも一つ以上のプログラム経路を決定する、請求項１１に記載のテストケース生成装置。
  13. 少なくとも一つの命令を実行するプロセッサ；
    前記少なくとも一つの命令を保存するメモリーを含み、
    前記プロセッサは、
    シンボリック実行に基づいてＳＱＬ文を含むソースコードに対するテストケースを生成し、データベースと連動するテスト対象システムに前記テストケースを適用してテストを遂行し、
    前記テストケースは、前記テスト対象システムの入力値、前記入力値が前記テスト対象システムで処理される時に出力値を予測した予想出力値、前記データベースの設定値および前記テスト対象システムが前記設定値が適用された前記データベースと連動して処理される時、前記データベースに保存される結果値を予測した予想結果値のうち少なくとも一つを含む、テストケースを利用したテスト装置。
  14. 前記プロセッサは、
    前記ソースコードに対して少なくとも一つ以上のプログラム経路を決定し、前記少なくとも一つ以上のプログラム経路により前記シンボリック実行を遂行し、前記シンボリック実行により生成された論理式に対してソルバーを利用してテストケースを生成する、請求項１３に記載のテストケースを利用したテスト装置。
  15. 前記プロセッサは、
    前記ソースコードをパーシングして要約構文ツリーを生成し、生成した要約構文ツリーに基づいて、制御流れグラフを生成し、前記制御流れグラフに基づいて少なくとも一つ以上のプログラム経路を決定する、請求項１４に記載のテストケースを利用したテスト装置。
  16. 前記プロセッサは、
    前記少なくとも一つ以上のプログラム経路にＳＱＬ文が含まれた場合、
    前記ソースコードのホスト変数と前記ＳＱＬ文により前記データベースに含まれたテーブルのコラムをマッピングする、請求項１４に記載のテストケースを利用したテスト装置。
  17. 前記プロセッサは、
    前記ＳＱＬ文をパーシングしてテーブルを確認し、確認したテーブルを構成するコラムを前記データベースのメタデータを利用して獲得し、獲得したコラムを前記ソースコードのホスト変数とマッピングする、請求項１６に記載のテストケースを利用したテスト装置。
  18. 前記プロセッサは、
    生成したテストケースをＸＭＬ、ＪＳＯＮのうち一つのフォーマットで保存する、請求項１３に記載のテストケースを利用したテスト装置。
  19. 前記プロセッサは、
    前記テスト対象システムがモジュールである場合、
    前記設定値を前記データベースに適用し、前記入力値で前記テスト対象システムの入力パラメーターを設定し、設定した入力パラメーターで前記テスト対象システムの関数を呼び出し、関数呼び出しの結果で獲得された前記テスト対象システムの出力値を前記予想出力値と比較し、前記データベースに保存された結果値と前記予想結果値を比較する、請求項１３に記載のテストケースを利用したテスト装置。
  20. 前記プロセッサは、
    前記テスト対象システムがミドルウェアサービスである場合、
    前記テストケースを利用して入力全文を生成し、前記テスト対象システムが連動するミドルウェアのサービスを呼び出して前記入力全文を前記ミドルウェアに伝送し、前記ミドルウェアからテスト結果全文を受信する、請求項１３に記載のテストケースを利用したテスト装置。
JP2019546812A 2017-02-28 2018-02-28 テストケースを利用してテストを遂行する方法および装置 Active JP6859449B2 (ja)

Applications Claiming Priority (3)

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

Publications (2)

Publication Number Publication Date
JP2020510925A true JP2020510925A (ja) 2020-04-09
JP6859449B2 JP6859449B2 (ja) 2021-04-14

Family

ID=63370189

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019546812A Active JP6859449B2 (ja) 2017-02-28 2018-02-28 テストケースを利用してテストを遂行する方法および装置

Country Status (5)

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

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023199407A1 (ja) * 2022-04-12 2023-10-19 日本電信電話株式会社 保守作業支援装置、保守作業支援方法及びプログラム
WO2023210159A1 (ja) * 2022-04-27 2023-11-02 ソニーグループ株式会社 情報処理装置及び情報処理方法、並びにコンピュータプログラム
JP7474132B2 (ja) 2020-06-24 2024-04-24 株式会社日立製作所 プログラム検証データ生成支援装置、及びプログラム検証データ生成支援方法

Families Citing this family (35)

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

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001282578A (ja) * 2000-03-31 2001-10-12 Hitachi Software Eng Co Ltd プログラムテスト支援装置、方法、および該方法に係るプログラムを記憶した記憶媒体
JP2015153323A (ja) * 2014-02-18 2015-08-24 富士通株式会社 シンボリック実行プログラム、シンボリック実行方法及びシンボリック実行装置
JP2015176230A (ja) * 2014-03-13 2015-10-05 富士通株式会社 テストケース生成装置、方法、及びプログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8302080B2 (en) * 2007-11-08 2012-10-30 Ntt Docomo, Inc. Automated test input generation for web applications
CN101436128B (zh) * 2007-11-16 2012-10-31 北京邮电大学 软件测试用例自动生成方法及系统
US8180786B2 (en) * 2009-08-28 2012-05-15 Microsoft Corporation Symbolic query exploration
CN102262580A (zh) * 2010-05-24 2011-11-30 南京航空航天大学 一种改进的基于符号执行的软件静态测试方法及工具
US8448146B2 (en) * 2011-03-31 2013-05-21 Infosys Limited Generation of functional tests for re-hosted applications
CN102289362A (zh) * 2011-08-26 2011-12-21 北京邮电大学 分段符号执行装置及其工作方法
US8286250B1 (en) * 2011-11-16 2012-10-09 Google Inc. Browser extension control flow graph construction for determining sensitive paths
GB2503893A (en) * 2012-07-10 2014-01-15 Ibm Selecting data from a database using data representing a sequence of operations
US9710528B2 (en) * 2014-03-25 2017-07-18 Wipro Limited System and method for business intelligence data testing

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001282578A (ja) * 2000-03-31 2001-10-12 Hitachi Software Eng Co Ltd プログラムテスト支援装置、方法、および該方法に係るプログラムを記憶した記憶媒体
JP2015153323A (ja) * 2014-02-18 2015-08-24 富士通株式会社 シンボリック実行プログラム、シンボリック実行方法及びシンボリック実行装置
JP2015176230A (ja) * 2014-03-13 2015-10-05 富士通株式会社 テストケース生成装置、方法、及びプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
林昌吾、外１名: "スクリプト言語によるオブジェクト指向のＷＥＢアプリケーションにおけるＸＳＳ攻撃脆弱性に対するクラスキ", ２０１７年 暗号と情報セキュリティシンポジウム概要集, JPN6020038108, 24 January 2017 (2017-01-24), ISSN: 0004361633 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7474132B2 (ja) 2020-06-24 2024-04-24 株式会社日立製作所 プログラム検証データ生成支援装置、及びプログラム検証データ生成支援方法
WO2023199407A1 (ja) * 2022-04-12 2023-10-19 日本電信電話株式会社 保守作業支援装置、保守作業支援方法及びプログラム
WO2023210159A1 (ja) * 2022-04-27 2023-11-02 ソニーグループ株式会社 情報処理装置及び情報処理方法、並びにコンピュータプログラム

Also Published As

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

Similar Documents

Publication Publication Date Title
JP6859449B2 (ja) テストケースを利用してテストを遂行する方法および装置
US9898280B2 (en) Automatic code review and code reviewer recommendation
US9208057B2 (en) Efficient model checking technique for finding software defects
US8875110B2 (en) Code inspection executing system for performing a code inspection of ABAP source codes
US8561036B1 (en) Software test case management
US11726969B2 (en) Matching metastructure for data modeling
JP2018501538A (ja) 影響分析
Hassan et al. Rudsea: recommending updates of dockerfiles via software environment analysis
US8122440B1 (en) Method and apparatus for enumerating external program code dependencies
Kling et al. MoScript: A DSL for querying and manipulating model repositories
CA2980333A1 (en) Field specialization systems and methods for improving program performance
CN112765017A (zh) 基于MySQL数据库的数据查询性能测试方法和装置
EP2199905A1 (en) Lifecycle management and consistency checking of object models using application platform tools
CN103186463A (zh) 确定软件的测试范围的方法和系统
US20200097260A1 (en) Software application developer tools platform
CN114756456A (zh) 一种持续集成方法、装置以及计算机可读存储介质
CN112650526B (zh) 版本一致性的检测方法、装置、电子设备和介质
US9396239B2 (en) Compiling method, storage medium and compiling apparatus
Rietveld et al. Reducing layered database applications to their essence through vertical integration
EP2919132A1 (en) Method for automatic generation of test data for testing a data warehouse system
Szalay et al. Towards better symbol resolution for C/C++ programs: A cluster-based solution
US11100131B2 (en) Simulation of a synchronization of records
Nooraei Abadeh et al. Delta‐based regression testing: a formal framework towards model‐driven regression testing
Anderson Modeling and analysis of SQL queries in PHP systems
Drago et al. QVTR2: A Rational and Performance-Aware Extension to the Relations Language.

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190826

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200928

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20201006

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210105

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210323

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210325

R150 Certificate of patent or registration of utility model

Ref document number: 6859449

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250