テスト自動化の基本的な考え方と - 日本spiコンソー …title...

Copyright©2019 NTT Corp. All Rights Reserved.

テスト自動化の基本的な考え方とNTTにおける研究開発の紹介

丹野治門（NTT研究所）2019年3月26日(火)

第25回 SPIトワイライトフォーラム

Copyright©2019 NTT Corp. All Rights Reserved. 2

丹野治門(たんのはると) NTT ソフトウェアイノベーションセンタソフトウェア開発技術プロジェクト

– 勤務場所：田町グランパークタワー33F

2009年-現在：NTT研究所で勤務

– ソフトウェアテスト自動化に関する研究開発業務• 主にＷｅｂ系業務システムを対象としたテスト自動化技術

最近の対外活動– 情報処理学会ソフトウェア工学研究会運営委員会幹事

– Workshop on Testing: Academia-Industry Collaboration, Practice and Research Techniques (TAICPART2019),プログラム委員

– 25th Asia-Pacific Software Engineering Conference (APSEC2018), Registration Co-Chairs

参考ページ：http://mintsuku.main.jp/tanno/

自己紹介

(2018年4月から電気通信大学の博士後期課程にも在学)

http://mintsuku.main.jp/tanno/


第一部：テスト自動化の基本的な考え方(※1)

– テスト自動化の既存ツール，研究の動向

– テスト自動化のコツ，課題

第二部：NTTにおける研究開発の紹介

– 回帰テストの自動化を支援する技術

• テスト設計/実装の支援：Regumo

• テスト結果確認の支援：ULTDiff

– NTTグループにおける普及展開活動

本日の話

※1：今回，機能性に関する話題に絞ります．（性能，セキュリティ等の話はしません．）


第一部：テスト自動化の基本的な考え方








本日の話


ソフトウェアテストの主な目的

– ソフトウェアが要求通りに動作することを確認する

– バグを検出してソフトウェアの品質を向上させる

テストは開発において，

– 全体に占める稼働の割合が大きい

– 品質確保における最後の砦

– （回帰テストは）機能追加，バグ修正後のリリースまでの期間へ大きく影響

テスト効率化はソフトウェア開発のQCD改善の要

– テスト自動化は効率化のためのアプローチの1つ

ソフトウェア開発におけるテストの位置づけ


テストケーステストケーステストケース

テストにおけるタスク

識別テスト条件を識別し，優先順位付

けする

設計テストケースを設計す

る

実装テストケースを実装す

る

実行テストケースを実行す

る

比較テストケースの出力と期待結果を比較する

Mark Fewster et al. システムテスト自動化標準ガイド, テスト自動化研究会訳, 翔泳社, 2014, 17p.における分類

テスト対象ソフトウェア

入力

期待結果

テスト結果

比較合否結果

テストケースを実行

テスト条件の識別

スクリプト実装(※1)

※1：テスト自動実行ツールを使う場合はツールの入力となるスクリプトを実装する

設計


テストにおけるタスクの特徴

識別設計実装実行比較

Mark Fewster et al. システムテスト自動化標準ガイド, テスト自動化研究会訳, 翔泳社, 2014, 23p.の図1.5を引用

知的1回だけ実行

複数回繰り返す事務的

テストの質を決める自動化向き



テスト自動化の現状

学術研究が盛んな領域

開発現場で活用が進む領域

■2000年～2014年の間で・・・・テストの「設計」は，テスト入力値生成などで大きな進歩．期待結果生成は今後に期待．・テストの「実行」は，自動実行フレームワークが開発現場でも広く使われるようになった．Alessandro Orso and Gregg Rothermel. 2014. Software testing: a research travelogue (2000–2014). In Proceedings of the on Future of Software Engineering

(FOSE 2014). ACM, New York, NY, USA, 117-132.

※1：テスト識別ではテスト条件を導き出すためにテスト技法（同値分割，境界値分析，ユースケース技法など）を活用することがある．テスト設計におけるテストケース自動生成は，テスト技法の考え方に基づいているものも多い．

※2：テスト設計自動化技術はテスト実装まで同時に行うことも多い※3：テスト実行ツールは入力となるテストスクリプトの実装が必要となる

より自動化しやすく，効果が見込める部分から現場導入が進んでいる

※1 ※2 ※3


83ヶ国1433人のソフトウェアテスト専門家のアンケート回答

– アジャイル開発は89%，ウォータフォール開発は33%

– テスターにとって大事なスキル• 1位コミュニケーションスキル

• 2位機能テスト自動化・スクリプト作成

日本国内のデバッグ/テストツールの使用割合(日本国内)

テスト自動化の現状（続き）

0

20

40

60

年

割合

「STATE OF TESTING REPORT 2018 Sponsored by TM テストの現状調査レポート」より(https://qablog.practitest.com/wp-content/uploads/2018/10/State_of_Testing_2018_Japanese.pdf)

短期繰り返しリリースのためには，テスト自動化は必須

テスト自動化ツールの導入は年々，進んでいる？

「ソフトウェア開発データ白書2018-2019，2016-2017,2015-1014,2013-2012,2010-2011」における「デバッグ/テストツールの使用割合」より算出

短期繰り返しリリースのためには，テスト自動化は必須

https://qablog.practitest.com/wp-content/uploads/2018/10/State_of_Testing_2018_Japanese.pdf



テスト自動化技術の動向

（１）テストケース生成（１a）テスト入力値生成（１b）テスト期待結果生成（2）回帰テスト(テストスイートの最小化，

テストケースの選択，優先度付，)※2

（3）テスト実行ツール(4)テストスクリプティング

※1：「比較」については「(1b)テスト期待結果生成」と関連深いため，(1b)の説明の中で紹介する．※2： (1a),(1b),(2)の分類はMECEになっているわけではない．

以下の技術領域(1a),(1b),(2),(3),(4)ごとに技術の動向を紹介する

※1









※1


2005年前頃から大きな進歩があった

– 計算機性能の向上により，現実的な時間で入力値生成可能となった

– 現実的なアプリケーションへの適用を可能とする新技術の登場，• 2004年：Adaptive Random Testing

• 2005年：動的記号実行

• 2007年：Feedback-Directed Random Test

– 研究を進める上で基盤となる実装の登場し，研究が加速• CUTE，CREST（動的記号実行の実装）

• Randoop（Feedback-Directed Random Testの実装）

• EvoSuite（サーチベーステストの実装）

– 今後,産業界での活用も見込まれる• 特に動的記号実行は登場から10年でめざましく進歩．Microsoft Visual Studio

2015 EnterpriseへInteliTest機能として組み込まれた．

(1a)テスト入力値生成


テスト入力値生成の目的– ソフト工学，テスト分野の主要国際会議5つについて2006年-2016年まで

の研究論文を調査した結果

(1a)テスト入力値生成

「丹野治門, 倉林利行, 張暁晶, 伊山宗吉, 安達悠, 岩田真治, 切貫弘之: “テスト入力値生成技術の研究動向”, コンピュータソフトウェア, Vol. 34, No. 3, pp. 3_121-3_147, 2017」の表1より計算

テスト入力値生成割合

ソフトウェア構造の網羅を目指すコード網羅率向上 39%(63本)

モデル網羅率向上 7%(11本)

バグをピンポイントで検出する 24%(39本)

入力空間を効果的に狭める 16%(25本)

その他 14%(22本)

代表的なテスト入力値生成の手法

– ランダムテスト，記号実行，サーチベーステスト

– モデルベーステスト，組み合わせテスト※1

それぞれの手法について紹介する

「Alessandro Orso and Gregg Rothermel. 2014. Software testing: a research travelogue (2000–2014). In

Proceedings of the on Future of Software Engineering (FOSE 2014). ACM, New York, NY, USA, 117-132.」では，モデルベーステスト，組み合わせテストの2つをテスト入力値生成ではなくテスト戦略と分類している．


無作為・均一にテストを実行するので，自動化に適している

しかし，コード網羅率向上，バグ検出の観点においてテストケース1件あたりの効率は著しく悪い

この欠点を改良するため，古典的RTを改良した手法として以下が提案された(最近のRTの研究は主にこの2つがベースになっているものが多い)

– Adaptive Random Testing(※1)

– Feedback-Directed Random Test(※2)

(1a-1)ランダムテスト(RT)

※1：Chen T.Y., Leung H., Mak I.K. (2004) Adaptive Random Testing. In: Maher M.J. (eds) Advances in Computer Science - ASIAN 2004. Higher-Level

Decision Making. ASIAN 2004. Lecture Notes in Computer Science, vol 3321. Springer, Berlin, Heidelberg

※2：Carlos Pacheco, Shuvendu K. Lahiri, Michael D. Ernst, and Thomas Ball. 2007. Feedback-Directed Random Test Generation. In Proceedings of the 29th

international conference on Software Engineering (ICSE '07). IEEE Computer Society, Washington, DC, USA, 75-84.


(1a-1)Adaptive Random Testing (ART)

テストケース（テスト入力値）生成時に，過去に生成したテストケースからの「距離」が等しいテストケースを生成することで，より均一に分布したテストを生成する

– 「距離」の定義方法がポイント• 例えば，複雑な構造をもつオブジェクトが

テスト入力値の場合，テスト入力値同士の距離をどのように定義するか，といった研究がなされている

ARTの課題

– テストケースが増えるに従って計算量が多くなる• 場合によっては古典的RTよりも効率が悪くなるという報告もある(※1)

– 古典的RTと同様に生成されるテストケースは数は多く，結果確認のコストは課題となる．これには期待結果生成技術を組み合わせることが有効

• ARTの発明者(T.Y.Chen)は期待結果確認技術(メタモルフィックテスティング)の発明者でもある

※1：Arcuri, Andrea & Briand, Lionel. (2011). Adaptive random testing: An illusion of effectiveness?. 2011 International Symposium on Software Testing and Analysis, ISSTA 2011 -

Proceedings. 265-275.

プログラムの入力空間

テストケース1

テストケース2

テストケース3

テストケース4


オブジェクト指向言語のプログラムであるメソッドFのテストするためには，Fを呼び出すインスタンスとFへの引数となるインスタンスが必要 FDRTではこれらのインスタンスを自動で生成しメソッドFのテストを行う

FDRTの手順

– ①引数が不要なメソッドの呼び出しを最初に行い，結果として得られたインスタンスを蓄えておく

– ②蓄えられたインスタンスを活用して別のメソッドを呼び出す

– ①，②を繰り返し，プログラム中のあらゆるメソッドをテストしていく

(1a-1) Feedback-Directed Random Test(FDRT)

(1)HashMap h = new HashMap();(2)Collection c = h.values(); //(1)の結果を利用(3)Object[] a = c.toArray(); //(2)の結果を利用(4)LinkedList l = new LinkedList();(5)l.addFirst(a); //(3)の結果を利用(6)TreeSet t = new TreeSet(l); //(4)の結果を利用(7)Set u = c.unmodifiableSet(t) //(2),(6)の結果を利用

FDRTの例：順番にインスタンス生成，メソッド呼び出し


静的記号実行(SSE) 1970年代に登場(※1)

– プログラムにおける変数を記号値で表現し，分岐条件へ影響する変数への制約を静的に解析，コード上の各パスを活性化する条件を抽出

– 条件群を制約ソルバで解き，パスを活性化させる具体的な値を得る

– コード網羅率の向上させるテストを生成可能

動的記号実行(DSE) 2006年に登場(※2)

– SSEで解析できなかった(解けなかった)部分は，ソフトウェアを実際に動作させたときの具体値を活用して解くことで，SSEの課題を解決

SEの適用範囲を大きく拡大

(1a-2) 記号実行(SE)

課題：SSEは，以下のような場合，解を得ることができなくなる・外部ライブラリ呼び出しなどコードを静的解析できない個所がある・制約ソルバで解くことができない条件がある

(※1)James C. King. Symbolic execution and program testing. Commun. ACM, Vol. 19, No. 7, pp.385–394,

July 1976.

(※2) Koushik Sen, Darko Marinov, and Gul Agha. Cute: A concolic unit testing engine for c. In

Proceedings of the 10th European Software Engineering Conference Held Jointly with 13th ACM SIG-

SOFT International Symposium on Foundations of Software Engineering, ESEC/FSE-13, pp. 263–272,

New York, NY, USA, 2005. ACM.


(1a-2) 静的記号実行(SSE)の例

public int testme(int x, int y)

{

int z = y*2;

if (x != z)

{

return 10;

}

else

{

return 20;

}

}

静的解析

(1)x = x0, y = y0

(2)z = y0*2

(3)x0 != y0*2

true false

(4)return 10 (5)return 20

パス番号

パス条件パス

1 x0 != y0*2 (1),(2),(3),(4)

2 !(x0 != y0*2) (1),(2),(3),(5)

パス条件を制約ソルバで解き，それぞれのパスを活性化させる具体的な入力値を得る

記号値（x0,y0）


(1a-2) 動的記号実行(DSE)の例

Concrete

Execution

Symbolic

Execution

concrete

state

symbolic

state

path condition

x = x0, y = y0x = 1, y = 1

実行回数：１

Concrete実行より具体値を生成

Symbolic実行より記号を記録


{

int z = y*2;

if (x != z)

{

return 10;

}

else

{

return 20;

}

}




{

int z = y*2;

if (x != z)

{

return 10;

}

else

{

return 20;

}

}

Concrete

Execution

Symbolic

Execution

concrete

state

symbolic

state

path condition

x = x0, y = y0

z0 = y0 * 2

x = 1, y = 1

z = 2

実行回数：１



Concrete

Execution

Symbolic

Execution

concrete

state

symbolic

state

path condition

x = x0, y = y0

z0 = y0 * 2

x = 1, y = 1

z = 2

実行回数：１

x0 != y0 * 2

パスreturn 10

テスト入力値x = 1, y = 1

テストケース１

Solve: ! (x0 != y0 * 2)

Solution:

x0 = 2, y0 = 1


{

int z = y*2;

if (x != z)

{

return 10;

}

else

{

return 20;

}

}



Concrete

Execution

Symbolic

Execution

concrete

state

symbolic

state

path condition

x = x0, y = y0x = 2, y = 1

実行回数：２


{

int z = y*2;

if (x != z)

{

return 10;

}

else

{

return 20;

}

}



Concrete

Execution

Symbolic

Execution

concrete

state

symbolic

state

path condition

x = x0, y = y0

z0 = y0 * 2

x = 2, y = 1

z = 2

実行回数：２


{

int z = y*2;

if (x != z)

{

return 10;

}

else

{

return 20;

}

}



Concrete

Execution

Symbolic

Execution

concrete

state

symbolic

state

path condition

x = x0, y = y0

z0 = y0 * 2

x = 2, y = 1

z = 2

実行回数：２

x0 == y0 * 2

パスreturn 20

テスト入力値x = 2, y = 1

テストケース2実行完了


{

int z = y*2;

if (x != z)

{

return 10;

}

else

{

return 20;

}

}



Concrete

Execution

Symbolic

Execution

concrete

state

symbolic

state

path condition

x = x0, y = y0

z0 = y0 * 2

x = 2, y = 1

z = 2

実行回数：２

x0 == y0 * 2

パスreturn 20

テストデータx = 2, y = 1

テストケース2実行完了


{

int z = y*2;

if (x != z)

{

return 10;

}

else

{

return 20;

}

}

ここが例えば「x != z + ReadInt(“test.txt”)」だと，静的記号実行では制約を解くことが難しい．動的記号実行ではReadInt(“test.txt”）の部分は実行時情報を用いて制約を解く．（例）実行したらReadIntの戻り値が2だったった場合，制約条件は「 x != z + 2 」


ヒューリスティック探索アルゴリズムを用いて達成したい要件を満足するテストスイート（テストケースの集合）を生成する技術の総称

以下の手順で行われる

– (1)達成したい要件に対する達成度合いを定量的に評価できる評価関数を設計

– (2)(最初は予め用意した)テストスイートをテスト対象に対して実行し，実行したテストスイートの評価関数の値を取得

– (3)評価関数の値が優れているテストスイートを元に，ヒューリスティック探索アルゴリズムによって新規にテストスイートを生成

要件に対してうまく評価関数を設計することがポイント

ヒューリスティック探索アルゴリズム

– 遺伝的アルゴリズム，山登り法，焼きなまし法，粒子群最適化

(1a-3) サーチベーステスト(SBST)


(1a-3) SBSTの例(遺伝的アルゴリズムを使用)

要件：分岐１で「b>1」が真(Yes)となるテスト入力値を得る

(1)評価関数Eを，E=b-1と設計（Eが大きいほど解に近い）(2)第一世代テストスイートとしてTC1,2,3を用意し実行TC1(a=-10)E = -10TC2(a=-3)E= -3TC3(a=-2)E= -2

(3)以下のルールで第一世代から第二世代を生成・評価値が低いものは殺す・評価値が高いものは交配してTC4(a=-2.5)を生成・突然変異としてTC5(a=-14)第二世代テストスイートTC2,TC3,TC4,TC5を実行，以降，(2)-(3)を要件を満たす解を得られるまで繰り返す

記号実行ではテスト入力値を用いてどのように計算が進んでいくかを記号値で追跡していくが，SBSTでは追跡はしていない．SBSTでは「テスト入力値が変わると，評価関数がどのように変わるか」という情報のみ使用している．


モデルに基づいてテストスイートを生成する技術の総称– モデルは，何らかの形でテスト対象を記述したもの

• モデル：フローモデル，状態遷移モデル，組み合わせモデル，代数的モデルなど

• 記法：UML，形式仕様記述，など

– 産業でも成功事例あり(※1)

MBTの特徴– モデル(例えばソフトウェア仕様)を用い，様々なテスト技法に基づいて，期

待結果も含め網羅的なテストケースを生成できる点は強力

– モデルを作るコストがオーバーヘッドとしてかかるため，導入の敷居が高い

– 詳細なテストケースを生成しようとすれば，より詳細なモデルが必要

以下がモデル作成オーバーヘッド軽減には有効・上流工程成果物の一部をモデルとして作りそのモデルからテストをつくる・ソフトウェア実行時の情報から雛形を作る

(1a-4)モデルベーステスト(MBT)

※1：S. Anand, E. K. Burke, T. Y. Chen, J. Clark, M. B. Cohen, W. Grieskamp, M. Harman, M. J. Harrold,

and P. Mcminn. An orchestrated survey of methodologies for automated software test case generation. Journal

of Systems and Software, 86(8):1978–2001,


機能テスト設計支援ツールTesMa (丹野らの過去の取り組み)※1– 入力はある程度の記述ルールを定めたソフトウェア設計書

– ユースケース技法，同値分割/境界値分析といったテスト技法に基づき網羅的なテストケースを生成

(1a-4) MBTの例

機能テスト設計支援ツール

TesMa

ソフトウェア設計書

テスト項目表テスト用データ

入力出力

画面設計書

（例）

処理フロー図画面遷移図

項番手順

1 …2 …… …N … 実行用

スクリプトファイル

※1：丹野治門，生沼守英，夏川勝行: "ソフトウェアを低コストで早期にリリースすることをめざしたテスト自動化技術", NTT技術ジャーナル, 2016, Vol 28, No.12, pp.19-22, 2016年12月


プログラムへの入力パラメータ(因子)間の相互作用に起因する不具合を効果的に発見することを目的とする

テストケースとして因子に割り当てる値(水準)の組み合わせを生成する

組み合わせ技法に基づくテスト生成ツール

– PictMaster，MatrixTester®

CTの特徴

– 因子の組み合わせが膨大に存在し組み合わせの制約などもあり，実施するテストケースを絞り込みたいときに有効．

– ユーティリティ的に活用できるので，導入の負担が少ない

– 因子，水準の洗い出し作業は人が行う(もしくは別の技術を用いる)必要があるソフトウェア実行時情報から因子，水準を抽出する手法もある

(1a-5)組み合わせテスト(CT)


(1a-5)組み合わせテストの例

因子水準

OS Win7, Win10, CentOS6

CPU Corei3, Corei5, Corei7

MEM 2GB, 4GB, 8GB

HDD 128GB, 512GB, 2TB

禁則： OS==Win10 のとき MEM==2GB は不可

OS CPU MEM HDD

CentOS6 Corei3 2GB 2TBWin7 Corei7 2GB 128GB

CentOS6 Corei5 8GB 128GBWin10 Corei3 8GB 512GB

Win7 Corei3 4GB 512GBCentOS6 Corei7 4GB 512GBWin7 Corei5 2GB 512GBWin7 Corei7 8GB 2TBWin10 Corei7 4GB 2TBWin10 Corei3 4GB 128GBWin10 Corei5 4GB 2TB

入力：因子と水準

出力：組み合わせ

ペアワイズ法を実装したツールPictMasterを用いて生成した，2因子間網羅を達成するテストスイート









※1


テストオラクル問題

– 期待結果生成は特に「自動化」が技術的に難しくチャレンジングな領域

– 完全な自動生成は本質的に難しい「プログラムへの入力に対する出力(期待結果)が自動生成できるならば，それは正しいプログラムが自動で作れることと同義」

• 「テスト不可能プログラム」というオラクルが本質的に存在しないプログラムも存在

– テスト入力値生成技術で自動生成したテストケースを活用するためには，Test Oracle Problemをどのように扱うかが肝

テスト期待結果生成には以下のようなアプローチがある(※1)

– (1b-1) 仕様オラクル (Specified test oracle)

– (1b-2) 派生オラクル (Derived test )

– (1b-3) 暗黙的オラクル (Implicit test oracle)

– (1b-4) 人力オラクルの負荷軽減 (Human oracle problem)

(1b)テスト期待結果生成

※1：「E. T. Barr, M. Harman, P. McMinn, M. Shahbaz and S. Yoo, “The Oracle Problem in Software Testing: A Survey,” in IEEE Transactions on

Software Engineering, vol. 41, no. 5, pp. 507-525, 1 May 2015.」における分類


形式的に記述された仕様情報に基づいて，期待結果の生成やテスト結果との比較を行う

– 仕様言語

• Z言語，UML/OCL，VDM，Alloy，など

• モデルの抽象度と同じレベルの期待結果を生成する（より詳細な期待結果を生成したければ，モデルをより詳細化する必要がある）

• モデルベーステストはこれに含まれる

– アサーション

• アサーションは多くのプログラミング言語で提供されている

– 契約プログラミング

• プログラムコード中にプログラムが満たすべき仕様の記述を盛り込み，設計の安全性を高める手法

(1b-1)仕様オラクル

これらの手法では，人が期待結果生成及びテスト結果との比較のための仕様情報(or期待結果そのもの)を作成する必要がある


様々な開発資材(ドキュメント，動的解析情報，システム旧版，など)から派生させてテスト期待結果を生成する

– (1b-1-1)疑似オラクル• 「絶対的なオラクル」(仕様オラクル)ではなく，「相対的なオラクル」

を用いる（例：Ｎバージョンプログラミング）

– (1b-1-2)回帰テスト向けオラクル• 正解とみなせるような「入力-出力のペア」 (例：テスト済みのシステ

ム旧版の入出力結果)を期待結果として用いる

– (1b-1-3)仕様オラクルを推定• ドキュメント，動的解析情報などから，仕様オラクルを推定する

(1b-1)派生オラクル


デザイン多様性の活用

– 同じ機能仕様を満たすプログラムを複数開発し，同じ入力に対して出力結果に差異があれば，どちらかが誤っているとみなす

• （例）Nバージョンプログラミング

データ多様性の活用

– 1つのプログラムに対して，ある入力に対して出力の変化を理論上予想できるとき，様々な入力に対し予想に反する変化があれば誤りとみなす

• （例）メタモルフィックテスティング：「入力の変化」と「出力の変化」の関係であるメタモルフィック関係(※1)により期待結果を判定

(1b-2-1)派生オラクル：疑似オラクル

※1：「メタモルフィックプロパティ」と呼ばれることもある．

入力値(1) テスト対象ソフトウェア

出力値(1)

入力値(2) 出力値(2)変換T

変換M(T)

期待結果(2)比較

（例）sin関数では「sin (x) = sin (x + 360°)」がメタモルフィック関係となる

メタモルフィック関係

• 疑似オラクルは絶対的なオラクルではないため，正しさの保証はない．• 疑似オラクルはテスト不可能プログラム(※2)のテストで有効とされている．※2：人工知能などのように正解値が予めわからず，厳密なオラクルが本質的に存在しないプログラムの総称．


メタモルフィックテスティング(MT)

– 数値計算だけではなく様々な分野へ適用可能

• 最近では機械学習プログラムへの適用でも注目されている

– 補足：MTをより一般化した「プロパティベーステスト」という考え方もある

• プログラムの入力と出力の関係性に着目して期待結果を自動判定する

• QuickCheck(Haskell)が有名，他にも様々な言語においてライブラリが存在

(1b-2-1)派生オラクル：疑似オラクル

「S. Segura, G. Fraser, A. B. Sanchez and A. Ruiz-Cortés, “A Survey on

Metamorphic Testing,” in IEEE Transactions on Software Engineering, vol. 42,

no. 9, pp. 805-824, 1 Sept. 2016.」のFig.4を引用

メタモルフィックテスティングの適用ドメイン


正解とみなせるような「入力-出力のペア」を用意し，それらを期待結果として用いる

– システムの新旧比較，多環境(端末，OS，ブラウザ)間の比較など

– 「入力-出力のペア」の作成ではテスト入力値生成技術も活用可能

回帰テスト向けオラクルでは正解との「比較」がポイントとなる(※1)

– 比較対象は様々

• （例）画面のスクリーンショット，実行ログ，DB状態，バイナリデータ

– そのままでは比較しにくいデータはテキスト形式に変換すると比較しやすい

– 画面についてはVisual Regression Testing(※2)という分野で多くの画面画像比較ツールが開発されている

– 「比較」を自動化する場合，差分として検出してほしくない部分はうまくマスキングする必要がある

• （例）画面の広告部分，ログにおける時刻

(1b-2-2)派生オラクル：回帰テスト向けオラクル

※1：「Mark Fewster et al. システムテスト自動化標準ガイド, テスト自動化研究会訳, 翔泳社, 2014, 第4章」に，回帰テストの場合だけではなく一般の場合の自動比較の方法論が述べられており，参考になる．※2： https://visualregressiontesting.com/


不変条件の推定

– 動的解析によりプログラムにおける不変条件を抽出し，アサーションを自動生成する

• (例) Daikon(※1)

– 精度の高い不変条件が得られるかは与えるテストスイート次第

機械学習によるオラクル推定

– （例）ANNベースオラクル (Artificial neural networks)

• 「入力，出力」の正解ペアから学習を行い，モデルを作る

• モデルを用いて回帰テスト，新規テストにおいて正解の予測を行う

自然言語ドキュメントベースのオラクル推定

– 自然言語 (or 少し記述にルールを設けた自然言語)ドキュメントからの仕様及び期待結果を抽出

(1b-2-3)派生オラクル：仕様オラクルの推定

※1：https://plse.cs.washington.edu/daikon/

• これらの手法はあくまで正解を推定しているのであり厳密ではない


システムの振る舞いを「正しくない」と判断する暗黙的な知識を活用する

– オラクルとして活用する暗黙的な知識の例

• Null Pointer Exceptions

• バッファオーバーフロー

• メモリーリーク

• ライブロック，デッドロック

• Webページのリンク切れ

• …

– 低コストで期待結果を作成できるが，確認できる範囲は狭い（システムが仕様に沿って動作しているかは判断できない）

– 「暗黙的な知識」は普遍的ではないことにも注意が必要• システムクラッシュは正しい動作でないことが多いが，クラッシュを許容する(or 意

図的にクラッシュするよう設計されている）場合もある

(1b-3) 暗黙的オラクル


人が確認したいことを確認してくれるテスト期待結果を自動生成することはなかなか難しい

そのため，テスト結果は人が確認することも多いいかに人が結果確認をする負担を軽減するか？

人力オラクルの負荷軽減アプローチ

– テストを量的に減らす

• テストケースの数を減らす(※1)

• テストケースの手順やテストデータを最小化する

– （例）デルタデバッギング(※2)の考え方を活用し，バグ再現させつつテスト手順，テストデータを最小化する

– テストの質(人の理解しやすさ)を改善する

• 可読性の高いテストケースを生成する

– （例）UserNameなら”aaa”ではなく”Taro”と生成

(1b-4)人力オラクルの負荷軽減

※1：これらは「(1)テスト入力値生成」における生成方法の工夫や，「(2)回帰テスト」により実現される※2： A. Zeller and R. Hildebrandt. Simplifying and isolating failure-inducing input. IEEE Trans. Software Engineering, 28(2), Febuary 2002.





テストケースの選択，優先度付)※2




※1


(2-1)テストスイート最小化

– 特定の要件を満した上で，テストケース数を最小化する

• (例)分岐網羅率は同じままテストケース数を最小化する

• 一般にはNP困難問題

• (1b-4)で紹介した人力オラクルの負荷，メンテナンスコスト，実行時間の削減などが目的

(2-2)テストケース選択

– 修正箇所を意識して，修正版のプログラムをテストするテストケース集合を選び出す

• Googleでは13000以上のPJがあり，1日に合計1.5億個のテストケースを実行しているそう．テストケース選択技術の話題もあった(※1)

(2-3)テストケース優先度付

– 順に実行したときに，早く要求を満たすように並べ替える

• (例)バグ検出が早く多く行われるよう並べ替える

(2)回帰テスト(テストスイート最小化，テストケース選択，優先度付)

(2-1),(2-2),(2-3)は「S. Yoo and M. Harman. 2012. Regression testing minimization, selection and prioritization: a survey. Softw. Test. Verif. Reliab. 22, 2 (March 2012), 67-120. 」における分類

※1：John Micco,” The State of Continuous Integration Testing at Google.”, ICST2017 KeyNote

http://aster.or.jp/conference/icst2017/program/jmicco-keynote.pdf





テストケースの選択，優先度付)※2




※1


(3)テスト自動実行ツール：主な自動操作対象 (※1)

– 単体テスト

– WebAPIテスト

– GUI (Webアプリ，モバイルアプリ)テスト

(4)テストスクリプトプティング

– テストケースをテストスクリプトとして実装する

– テストスクリプトの例 (GUIテスト)

(3)テスト自動実行ツール/(4)テストスクリプティング

※1：GUIテスト，WebAPIテストは多くのベンダが自動化対象としている（”Magic Quadrant for Software

Test Automation”, Gartner, Nov. 2018より）

テスト対象アプリ

①

②

③

命令ロケータ値

type id=modlgn_username user01

type id=modlgn_passwd pass01

click css=div.button1

assertTitle Main

テスト手順

入力値

期待結果

テストスクリプト

①②③

テスト自動実行ツール入力自動

操作


単体テスト

– OSSツール（例：JUnit），市販ツールがある

– 市販ツールの方がテストの自動実行以外の機能（例：テストドライバ、スタブの自動生成機能）が充実している

GUIテスト

– Seleniumが有名

• プログラミングして作成されたテストスクリプトを実行するSelenium WebDriver

• ユーザ操作を記録し実行するキャプチャ＆リプレイツール Selenium IDE

– 市販ツールは，Windowsアプリ，Webアプリ，モバイルアプリに対応しているなど使用可能な範囲が広い

– 最近はKatalon Studioという無料ツールもあり，ユーザ操作を記録し実行できるだけでなく，マルチブラウザ対応やキーワード駆動を備えるなど高機能である

WebAPIテスト

– Chrome拡張機能（例：Postman）を用いることで，ツール上からWebAPIを呼び出し結果を確認可能

– 市販ツール（例：SOAtest/Virtualize）では，同様の機能に加えてテスト環境の仮想化機能もあり，DBやWebサービスを仮想化でき，他機能が完成してなくてもテスト可

(3)テスト自動実行ツール：既存技術の動向


テストスクリプティングの技法

(4)テストスクリプティング

リニアスクリプトテスト実行ツール上でテストケースを手動で実行し，記録したときに生成されるスクリプト

構造化スクリプティング

制御構造(順次，分岐，反復)，呼び出し構造(サブスクリプト呼び出し)をもつ

共有スクリプト複数のテストケース間でスクリプトを共有する

データ駆動スクリプト

テストにおける入力値，テストスクリプトではなく別の「データファイル」へ格納する

キーワード駆動スクリプト

実行すべきタスクを意味する「キーワード」によってテストケースを記述する

Mark Fewster et al. システムテスト自動化標準ガイド, テスト自動化研究会訳, 翔泳社, 2014, 3.2節における分類

より保守性が高い


データ駆動スクリプトのイメージ

– 外部のデータシートを編集することで簡単に実行するテストのバリエーションを増やせる

(4)テストスクリプティング：データ駆動

命令ロケータ値

type id=modlgn_username input.username

type id=modlgn_passwd input.password

click css=div.button1

assertTitle Main

テスト手順

期待結果


①②③

入力値username password

user01 pass01

user02 pass02

・・・・・・

外部のデータシート


キーワード駆動スクリプトの例

– キーワードに対応する操作は外部で実装されている

– テスト内容をテストの詳細な実装と分離して記述できる• テストケース作成者とテスト実装者の役割分担も容易になる

– キーワードをあらかじめ決めておけば実装工程よりも前の工程でテストスクリプトを作成できる

(4)テストスクリプティング：キーワード駆動

キーワードターゲット値

SetText Username input.username

SetText Password input.password

Click LoginButton

CheckTitle Main

テスト手順

期待結果


①②③

入力値


関連する話題として「ビヘイビア駆動開発(BDD)」がある

– テスト駆動開発から派生

– 自然言語に近い書き方で例として仕様を記述

– その仕様は自動実行可能なテストとなる

– 多くのツールが存在• Specflow, Cucumber, など

(4)テストスクリプティング：ビヘイビア駆動

「いまさら聞けないTDD/BDD超入門（1）：テスト駆動開発／振る舞い駆動開発を始めるための基礎知識 (3/3)」(https://www.atmarkit.co.jp/ait/articles/1403/05/news035_3.html) における「BDDフレームワーク「Cucumber」でのEnd-

To-Endテストのスクリプトの例」の例を引用










本日の話


事務的で繰り返し実施する部分を優先的に自動化する（そして，自動化しにくい領域へ人の稼働をまわす）

– 自動化は初期コストが手動で1回行うよりもかかるので，繰り返し回数が多くないと元がとれない

– テストの「実行，比較」は繰り返すことが多く，効果が出やすい領域• 特に，テストケース間で共通する事前,事後手順部分の自動化は効果あり

テスト自動化の基本的な方針

再掲：Mark Fewster et al. システムテスト自動化標準ガイド, テスト自動化研究会訳, 翔泳社, 2014, 23p.の図1.5を引用


ランダムテスト，記号実行，サーチベーステスト

– 課題：オラクル問題にうまく対処しないとテスト結果分析に手間がかかる低コストにオラクルを作成でき，効果のある領域を自動化する

• セキュリティパッチ適用時に「回帰テスト向けオラクル」でシステムを新旧比較 (※1)

• テスト不可能プログラムや，実装が複雑なアルゴリズムについて，メタモルフィックテスティングなど「疑似オラクル」を活用して強化テストを行う

• 暗黙的オラクルを活用し致命的なバグ(クラッシュなど)の検出を狙った強化テスト

モデルベーステスト

– 期待結果含め仕様を網羅的に確認するテストケースを生成できる点は強力

– 課題：ただし，モデル作成にはコストがかかる上流工程の成果物(モデル)をうまく活用する，モデルの抽象度をうまく調整する（どこまで詳細なテストを作りたいか？）

組み合わせテスト

– PICTなどのツールがあり，手軽にユーティリティとして活用できる

テスト設計自動化のコツ，課題

※1：このアプローチには「松尾谷ら: “Concolic Testing を活用した実装ベースの回帰テスト人手によるテストケース設計の全廃”, SS2015 和歌山」や，第二部で紹介するRegumo(http://www.ntt.co.jp/RD/active/201702/jp/pdf_jpn/04/D-21_j.pdf)などがある．


テスト実装とテスト実行自動化のコツ，課題(1)

上位のテストほどテスト実装に手間がかかり，テスト実行には時間がかかる

– GUIのテストは特に実装，実行のコストが大きい

UIは変更頻度が高い場合が多く，テストのメンテナンス頻度も高くなる

なるべく下位で自動実行できるテストケースを用意する

UI

(例)GUI

Service

(例)WebAPI

Unit

(例)Java, JavaScriptのメソッド

Martin FowlerのTest Pyramid

（例はWebアプリケーション）

・作成にコスト(大)

・実行時間(長)

・作成にコスト(小)

・実行時間(短)


手軽に始めるならばキャプチャ＆リプレイ

– SeleniumIDE，KataronStudioなどはフリーで使える

再利用性，保守性を高めるにはデータ駆動，キーワード駆動などの考え方を導入

– プログラマとテスト担当者の役割分担を明確化することも重要

課題

– スクリプトを作成することは手間 (手動作成の約5倍かかるといわれる)

– 5回以上繰り返される部分に絞る（ただ，投資対効果を予想するのは難しい…）継続的インテグレーション(CI)と併用するのがよさそう

– GUIテストのスクリプトは壊れやすい• GUI変更に伴いテストスクリプトにおけるロケータの参照先が存在しなくなるなど

– CIで動かし続ける．CIはソフトウェア，テストの両方について壊れたらすぐに検知してくれる

テスト実装とテスト実行自動化のコツ，課題(2)










本日の話


今回，回帰テストの自動化を支援する技術の取り組みを紹介します

Regumo

– 今あるソフトウェアの仕様を復元し，自動でテスト設計，実装を行う技術

ULTDiff

– 2つのアプリ画面の差異を画面要素単位で検出し，テスト結果確認を支援する技術

NTTにおける研究開発の紹介


Regumoの紹介

– 今あるソフトウェアの仕様を復元し，自動でテスト設計，実装を行う技術

– 参考文献• 倉林利行, 伊山宗吉, 切貫弘之, 丹野治門: "画面操作を伴うテストにおけるテストスクリプ

トの自動生成手法", ソフトウェアエンジニアリングシンポジウム2017論文集 pp. 260-264, 2017年9月 [一般論文]

• Toshiyuki Kurabayashi, Muneyoshi Iyama, Hiroyuki Kirinuki, Haruto Tanno: “Automatically Generating Test Scripts for GUI Testing”, 1st IEEE Workshop on NEXtlevel of Test Automation (NEXTA 2018)

• Muneyoshi Iyama, Hiroyuki Kirinuki, Toshiyuki Kurabayashi, Haruto Tanno: “Test Script Generation Tool for Regression Testing using Static and Dynamic Analysis”, 11th IEEE Conference on Software Testing, Validation and Verification (ICST2018) [Demo], April 2018 (https://www.youtube.com/watch?v=amLyaGb4c_E)

https://www.youtube.com/watch?v=amLyaGb4c_E


短期繰り返し開発では、頻繁に動作確認のテストを行います。

そのため、テスト自動化による省力化が求められています。

背景

リリース

開発テスト

• 機能の追加・修正• サーバやフレームワークの更改• OS, ミドルウェアのアップデート

動作確認テストの契機


テスト実行を自動化する場合の課題テストスクリプト作成に稼働がかかるテストスクリプト作成のスキルが必要

課題

仕様・テスト項目理解

具体的手順作成

スクリプト作成

テストススクリプト作成作業

画面自動操作＆結果確認

スクリプト修正＆再実行


旧ソースコード

動作する旧アプリ

入力情報出力情報

アプリの仕様情報(画面遷移図など)

自動で実行できるテストスクリプト

テスト結果レポート

ソースコードと動作するアプリを与えれば使える

スクリプト作成に稼働がかからず、スキルも不要

テスト対象アプリを知らなくてもよい

テスト項目1 成功テスト項目2 失敗

・・・・・・

特徴

リバースエンジニアリングを利用したテスト自動化技術「Regumo」

短期間に繰り返しリリースするサービスのテストを簡単に

テスト対象アプリを解析して得た仕様から実行可能なテストスクリプトを自動生成

Regumoでできること

テストスクリプト作成テスト自動実行

新アプリ

<HTML><HEAD>

#CONFIGParam1=あいうえお

public class Hello{public static voidmain(String[]

args){System.out.println("Hello,

world.");}

}

Regumoリグモ

テスト実行ツール

（市中技術）

テスト結果


デモ

ショッピングサイトの購入画面において商品の画像サイズを修正後、複数の環境（OS、ブラウザ）での自動テストのデモをします


自動で判断できない箇所は人がヒントを与え，その情報を活用してRegumoが再度解析を行い，より多くの画面を網羅するテストスクリプトを生成する

– 課題(1)：特定の入力値がないと先へ遷移できないケースがある

• (例)ログイン画面では適切なログインID，パスワードによりログイン可

– 人が各画面で用いる入力値を補助することが可能(※1)

• Regumoはテスト対象から入力フォームを自動で検出し，各入力フォームに対応する入力値を指定するフォーマットを自動生成

– 課題(2)：Regumoが認識する「画面」の粒度と，テスト担当者が期待する「画面」の粒度は異なる

– 人がRegumo出力結果の画面遷移図を確認し，Regumoが認識する「画面」の粒度を調整することが可能(※2)

• (例)以下の画面(a),(b)はテスト担当者としては同一画面/異なる画面のどちらと判断したいか？

Regumo：工夫点

※1：倉林利行,切貫弘之,丹野治門: "テストスクリプトの自動生成におけるテスト入力値作成支援技術の提案",情報処理学会研究報告ソフトウェア工学 , vol. 2018-SE-199, no. 13, pp.1-7, 2018年7月※2：倉林利行, 切貫弘之, 吉村優, 安達悠, 丹野治門: "テストスクリプト自動生成における適切な粒度の画面遷移テストの試み",電子情報通信学会技術研究報, vol. 118, no. 471, SS2018-75, pp. 139-144,

2019年3月

画面(a) 画面(b)


ULTDiffの紹介

– 2つのアプリ画面の差異を画面要素単位で検出し，テスト結果確認を支援する技術

– 参考文献• Haruto Tanno, Yuu Adachi: “Support for Finding Presentation Failures by Using

Computer Vision Techniques”, Testing – Practice and Research Techniques, 13th Workshop on Testing: Academia-Industry Collaboration, Practice and Research Techniques (TAIC PART 2018)

• 丹野治門: "画像処理を活用したUIレイアウト崩れ検出支援手法の提案", 情報処理学会研究報告ソフトウェア工学 , vol. 2016-SE-194, no. 9, pp.1-8, 2016年11月

• R&Dフォーラム2016 紹介動画(https://www.youtube.com/watch?v=OUeAz-iBLuY)

https://www.youtube.com/watch?v=OUeAz-iBLuY


背景

改造や移行に伴いアプリ画面の「現新比較」が必要

アプリ画面がデグレードなく表示されることを目視で確認することは大変

• 機能の追加・修正• サーバやフレームワークの更改• OS・ミドルウェアのアップデート


「間違い」はいくつあるでしょうか？


正解

1

2

3

1

2

3


多くの画面について，誤り箇所を目視で漏れなく検出し、開発者へテスト結果報告するのは意外に大変


様々な環境でアプリ画面の間違い探しを簡単にUIレイアウトテスト技術ULTDiff

ソフトウェア開発

設計して製造して

実施者様々な環境

[誤り箇所の詳細]

①

②③

④

① 消失② 変更③ 消失④ 変更


①

②③

④


誤り箇所の詳細

① 変更② 消失

テスト実行結果スクリーンショット

②

①

テストする

様々な環境ごとのアプリ画面における間違い(画面要素の位置ズレ、消失等)を自動検出し、テスト結果確認、報告を楽にします

手作業で大量のテスト結果報告を作成

目視で大量のテスト結果を確認


様々な環境でアプリ画面の間違い探しを簡単にUIレイアウトテスト技術ULTDiff

ソフトウェア開発

設計して製造して

実施者様々な環境


①

②③

④



①

②③

④


誤り箇所の詳細

① 変更② 消失

テスト実行結果スクリーンショット

②

①

テストする

様々な環境ごとのアプリ画面における間違い(画面要素の位置ズレ、消失等)を自動検出し、テスト結果確認、報告を楽にします

手作業で大量のテスト結果報告を作成

目視で大量のテスト結果を確認

本技術により支援！


デモ

ショッピングサイトの購入画面において商品の画像サイズを修正後、複数の環境（OS、ブラウザ）での自動テストのデモをします

さきほどの，Regumoのデモの続きをご紹介


課題：「比較」を自動化する場合，差分として検出してほしくない部分はうまくマスキングする必要がある– （例）広告部分，ニュース部分など

画面構成部品との相対的な位置関係によって領域を指定する(※1)

– テスト対象の画面において，部品との位置関係からマスク領域を再計算し，領域のサイズ・位置の変化に追随

ULTDiff：工夫点

①マスク領域指定フェーズ ②差異検出フェーズ

正しく表示された画面（旧バージョン）

テスト対象の画面（新バージョン）

正しく表示された画面（旧バージョン）

比較

マスク方向

マスク方向

マスク方向

マスク方向

マスク方向

マスク方向

※1：安達悠,丹野治門,吉村優: "Visual Regression Testingにおいて画面要素の位置関係によってマスク領域を指定する手法",ソフトウェア工学の基礎２５日本ソフトウェア科学会ＦＯＳＥ２０１８（レクチャーノート／ソフトウェア学） pp. 25-30, 2018年11

月 [ショートペーパー]

Haruto Tanno, Yu Adachi and Yu Yoshimura: "Masking Dynamic Content Areas Based on Positional Relationship of Screen Elements for Visual Regression Testing", 12th IEEE Conference on

Software Testing, Validation and Verification (ICST2019) [Demo], April 2019, to appear.


技術開発

– (1)コンセプト段階から現場と議論することで，現場担当者にも技術の愛着を醸成 (IKEA効果)

– (2)開発と現場評価のサイクルを回し，フィードバックを元に繰り返し改善

事業展開

– (3)愚直な営業活動による顧客エンゲージメントの獲得個別訪問，勉強会/展示会を多数実施

– (4)わかりやすいコンセプトを提示することで、現場業務での具体的な利用シーン・価値を容易に想起

– (5)トータルソリューションでの提案により、プロダクトの価値訴求を強化

NTTグループにおける技術の普及展開活動

以下のようなことを心がけて普及展開活動を行っています


(4)コンセプトを分かりやすく

アプリ画面がデグレードなく表示されているか確認できる！機能の追加・修正、サーバやフレームワークの更改、OS・ミドルウェアのアップデートに使える！

さまざまな端末でアプリ画面の間違い探しを簡単に

12

3

12

3


(5)トータルソリューション

Selenium

Jenkins

NTT技術市中技術

市中技術

トータルソリューション

RegumoNTT技術

ULTDiff


事業展開⇔技術開発の好循環は，両者を大きくレベルアップしてくれる

技術開発と事業展開の両立は大変だが，作った成果が活用される喜びは技術者冥利につきる

国内外のコミュニティで対外発表，議論をして視野を広げ人脈形成することも技術開発，事業展開で有用

– 丹野はチームメンバ全員が積極的に対外発表していく雰囲気づくりを推進している

• 今年度の実績：メンバ5人で17件(1人3件以上)の投稿

NTTグループにおける技術の普及展開活動（続き）










本日の話（振り返り）


現在は「テストの実行」自動化が主流，次は「テストの設計，メンテナンス，最適化」自動化へと進む (※1)

– テスト自動実行ツールの産業導入が進み，自動化は次の段階へ

– 機械学習の活用も期待されている

• Webアプリクローリングにおける画面入力値の自動推定

• 人が行いそうなシナリオの自動生成

• テストスクリプトのロケータ自動修正(※2)

最近，多く研究されている「バグ自動修正(※3)」でも自動テストは重要

– 自動バグ修正では，コード修正パターンを色々と試し，用意されたテストスイートをパスする正解の修正パターンを探す自動実行可能なテストの用意や，テスト生成技術がキモとなる

• (例) Facebookでバグ自動修正ツール「SapFix」開発

おわりに：テスト自動化の将来

※1： ”Magic Quadrant for Software Test Automation”, Gartner, Nov. 2018より※2：AI for element selection(Selenium Conf 2018) (https://www.seleniumconf.us/talks#jason-arbon)

※3：Martin Monperrus. 2018. Automatic Software Repair: A Bibliography. ACM Comput. Surv. 51, 1, Article 17 (January 2018), 24 pages.

今後も，テスト自動化技術は産業/学術両面での活用，発展が期待できる！

テスト自動化の基本的な考え方と - 日本spiコンソー …title...

Documents