テスト自動化の基本的な考え方とNTTにおける研究開発の紹介
丹野 治門 （NTT研究所）
2019年3月26日(火)第25回 SPIトワイライトフォーラム

Copyright©2019 NTT Corp. All Rights Reserved.

自己紹介 丹野 治門(たんの はると)
 NTT ソフトウェアイノベーションセンタ
ソフトウェア開発技術プロジェクト– 勤務場所：田町グランパークタワー33F

 2009年-現在：NTT研究所で勤務– ソフトウェアテスト自動化に関する研究開発業務• 主にＷｅｂ系業務システムを対象としたテスト自動化技術(2018年4月から電気通信大学の博士後期課程にも在学) 最近の対外活動– 情報処理学会 ソフトウェア工学研究会 運営委員会 幹事– Workshop on Testing: Academia-Industry Collaboration, Practice andResearch Techniques (TAICPART2019),プログラム委員– 25th Asia-Pacific Software Engineering Conference (APSEC2018),
Registration Co-Chairs
参考ページ：http://mintsuku.main.jp/tanno/
Copyright©2019 NTT Corp. All Rights Reserved. 2

本日の話第一部：テスト自動化の基本的な考え方(※1)– テスト自動化の既存ツール，研究の動向– テスト自動化のコツ，課題第二部：NTTにおける研究開発の紹介– 回帰テストの自動化を支援する技術• テスト設計/実装の支援：Regumo• テスト結果確認の支援：ULTDiff– NTTグループにおける普及展開活動※1：今回，機能性に関する話題に絞ります．（性能，セキュリティ等の話はしません．）
Copyright©2019 NTT Corp. All Rights Reserved. 3

本日の話第一部：テスト自動化の基本的な考え方– テスト自動化の既存ツール，研究の動向– テスト自動化のコツ，課題第二部：NTTにおける研究開発の紹介– 回帰テストの自動化を支援する技術• テスト設計/実装の支援：Regumo• テスト結果確認の支援：ULTDiff– NTTグループにおける普及展開活動

Copyright©2019 NTT Corp. All Rights Reserved. 4

ソフトウェア開発におけるテストの位置づけ
 ソフトウェアテストの主な目的– ソフトウェアが要求通りに動作することを確認する– バグを検出してソフトウェアの品質を向上させる

 テストは開発において，– 全体に占める稼働の割合が大きい– 品質確保における最後の砦– （回帰テストは）機能追加，バグ修正後のリリースまでの期間へ大きく影響

 テスト効率化はソフトウェア開発のQCD改善の要– テスト自動化は効率化のためのアプローチの1つ
Copyright©2019 NTT Corp. All Rights Reserved. 5

テストにおけるタスク
識別

設計

実装

実行

比較

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

テストケー
スを設計す
る

テストケー
スを実装す
る

テストケー
スを実行す
る

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

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

テストケース
テストケース
入力 テストケース
テスト条件
の識別

テストケースを実行
テスト対象
ソフトウェア

テスト結果

期待結果
設計

スクリプト実装(※1)

比較

合否結果

※1：テスト自動実行ツールを使う場合はツールの入力となるスクリプトを実装する
Copyright©2019 NTT Corp. All Rights Reserved. 6

テストにおけるタスクの特徴
識別知的
1回だけ実行
テストの質を決める

設計

実装

実行

比較

自動化向き
複数回繰り返す
事務的Mark Fewster et al. システムテスト自動化 標準ガイド, テスト自動化研究会訳, 翔泳社, 2014, 23p.の図1.5を引用
Copyright©2019 NTT Corp. All Rights Reserved. 7

テスト自動化の現状
より自動化しやすく，効果が見込める部分から現場導入が進んでいる
学術研究が
盛んな領域
識別
※1

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

設計

実装
※2

実行

比較

※3

※1：テスト識別ではテスト条件を導き出すためにテスト技法（同値分割，境界値分析，ユースケース技法など）を活用することがある．
テスト設計におけるテストケース自動生成は，テスト技法の考え方に基づいているものも多い．
※2：テスト設計自動化技術はテスト実装まで同時に行うことも多い※3：テスト実行ツールは入力となるテストスクリプトの実装が必要となる■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.
Copyright©2019 NTT Corp. All Rights Reserved. 8

テスト自動化の現状（続き）
 83ヶ国1433人のソフトウェアテスト専門家のアンケート回答– アジャイル開発は89%，ウォータフォール開発は33%– テスターにとって大事なスキル
短期繰り返しリリースのためには，• 1位 コミュニケーションスキル

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

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

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

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

20

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

テスト自動化技術の動向
以下の技術領域(1a),(1b),(2),(3),(4)ごとに技術の動向を紹介する
識別

設計

実装

実行

比較
※1

（１）テストケース生成（１a）テスト入力値生成（１b）テスト期待結果生成（2）回帰テスト(テストスイートの最小化，
テストケースの選択，優先度付，)※2（3）テスト実行ツール(4)テストスクリプティング※1：「比較」については「(1b)テスト期待結果生成」と関連深いため，(1b)の説明の中で紹介する．
※2： (1a),(1b),(2)の分類はMECEになっているわけではない．
Copyright©2019 NTT Corp. All Rights Reserved. 10

テスト自動化技術の動向
以下の技術領域(1a),(1b),(2),(3),(4)ごとに技術の動向を紹介する
識別

設計

実装

実行

比較
※1

（１）テストケース生成（１a）テスト入力値生成（１b）テスト期待結果生成（2）回帰テスト(テストスイートの最小化，
テストケースの選択，優先度付，)※2（3）テスト実行ツール(4)テストスクリプティング※1：「比較」については「(1b)テスト期待結果生成」と関連深いため，(1b)の説明の中で紹介する．
※2： (1a),(1b),(2)の分類はMECEになっているわけではない．
Copyright©2019 NTT Corp. All Rights Reserved. 11

(1a)テスト入力値生成
 2005年前頃から大きな進歩があった– 計算機性能の向上により，現実的な時間で入力値生成可能となった– 現実的なアプリケーションへの適用を可能とする新技術の登場，• 2004年：Adaptive Random Testing• 2005年：動的記号実行• 2007年：Feedback-Directed Random Test

– 研究を進める上で基盤となる実装の登場し，研究が加速• CUTE，CREST（動的記号実行の実装）• Randoop（Feedback-Directed Random Testの実装）• EvoSuite（サーチベーステストの実装 ）– 今後,産業界での活用も見込まれる• 特に動的記号実行は登場から10年でめざましく進歩．Microsoft Visual Studio2015 EnterpriseへInteliTest機能として組み込まれた．
Copyright©2019 NTT Corp. All Rights Reserved. 12

(1a)テスト入力値生成
 テスト入力値生成の目的– ソフト工学，テスト分野の主要国際会議5つについて2006年-2016年までの研究論文を調査した結果
テスト入力値生成

ソフトウェア構造の網羅を目指す

割合
コード網羅率向上

39%(63本)

モデル網羅率向上

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

24%(39本)

入力空間を効果的に狭める

16%(25本)

その他

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

 代表的なテスト入力値生成の手法– ランダムテスト，記号実行，サーチベーステスト– モデルベーステスト，組み合わせテスト※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つをテスト入力値生成ではなくテスト戦略と分類している．

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

Copyright©2019 NTT Corp. All Rights Reserved. 13

(1a-1)ランダムテスト(RT) 無作為・均一にテストを実行するので，自動化に適している しかし，コード網羅率向上，バグ検出の観点においてテストケー
ス1件あたりの効率は著しく悪い
 この欠点を改良するため，古典的RTを改良した手法として以下が提案された(最近のRTの研究は主にこの2つがベースになっているものが多い)– Adaptive Random Testing(※1)– Feedback-Directed Random Test(※2)※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.
Copyright©2019 NTT Corp. All Rights Reserved. 14

(1a-1)Adaptive Random Testing (ART) テストケース（テスト入力値）生成時に，過去に生成したテストケースからの「距離」が等しいテストケースを生成することで，より均一に分布しプログラムの入力空間
たテストを生成するテスト– 「距離」の定義方法がポイント
テスト
ケース1• 例えば，複雑な構造をもつオブジェクトがテスト入力値の場合，テスト入力値同士の距離をどのように定義するか，といった研究がなされている

ケース3

テスト
ケース4

 ARTの課題

テスト
ケース2– テストケースが増えるに従って計算量が多くなる• 場合によっては古典的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.

Copyright©2019 NTT Corp. All Rights Reserved. 15

(1a-1) Feedback-Directed Random Test(FDRT) オブジェクト指向言語のプログラムであるメソッドFのテストするためには，Fを呼び出すインスタンスとFへの引数となるインスタンスが必要
 FDRTではこれらのインスタンスを自動で生成しメソッドFのテストを行う
 FDRTの手順– ①引数が不要なメソッドの呼び出しを最初に行い，結果として得られたインスタンスを蓄えておく– ②蓄えられたインスタンスを活用して別のメソッドを呼び出す– ①，②を繰り返し，プログラム中のあらゆるメソッドをテストしていく
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)の結果を利用
Copyright©2019 NTT Corp. All Rights Reserved. 16

(1a-2) 記号実行(SE) 静的記号実行(SSE) 1970年代に登場(※1)– プログラムにおける変数を記号値で表現し，分岐条件へ影響する変数への制約を静的に解析，コード上の各パスを活性化する条件を抽出– 条件群を制約ソルバで解き，パスを活性化させる具体的な値を得る– コード網羅率の向上させるテストを生成可能

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

 動的記号実行(DSE) 2006年に登場(※2)– SSEで解析できなかった(解けなかった)部分は，ソフトウェアを実際に動作させたときの具体値を活用して解くことで，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 SIGInternational Symposium on Foundations of Software Engineering, ESEC/FSE-13, pp. 263–272,
SEの適用範囲を大きく拡大 SOFT
New York, NY, USA, 2005. ACM.

Copyright©2019 NTT Corp. All Rights Reserved. 17

(1a-2) 静的記号実行(SSE)の例
記号値（x0,y0）(1)x = x0, y = y0

public int testme(int x, int y)(2)z = y0*2{
int z = y*2;
(3)x0 != y0*2
静的解析
if (x != z)
true
false
{
(4)return 10(5)return 20
return 10;
パス パス条件
パス
}
番号
else
{
1
x0 != y0*2(1),(2),(3),(4)return 20;
2!(x0 != y0*2)(1),(2),(3),(5)}
パス条件を制約ソルバで解き，それぞれのパスを}活性化させる具体的な入力値を得る
Copyright©2019 NTT Corp. All Rights Reserved. 18

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

実行回数：１

Symbolic
Execution

concretepublic int testme(int x, int y) state

symbolicstate{

x = 1, y = 1

x = x0, y = y0

Concrete実行より具体値を生成Symbolic実行より記号を記録

int z = y*2;
if (x != z){
return 10;}
else{
return 20;}

path
condition}

Copyright©2019 NTT Corp. All Rights Reserved. 19

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

実行回数：１

concretepublic int testme(int x, int y) state

Symbolic
Execution

symbolic
state

path
condition{
int z = y*2;
if (x != z){
return 10;}
else{
return 20;}

x = 1, y = 1
z=2

x = x0, y = y0z0 = y0 * 2}

Copyright©2019 NTT Corp. All Rights Reserved. 20

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

実行回数：１

concretepublic int testme(int x, int y) state

symbolic
state

path
condition

Solve: ! (x0 != y0 * 2){
int z = y*2;
if (x != z){
return 10;}
else{
return 20;}}

Symbolic
Execution

Solution:x0 != y0 * 2

x0 = 2, y0 = 1
x = 1, y = 1
z=2

x = x0, y = y0z0 = y0 * 2

パス
return 10
テスト入力値
x = 1, y = 1
テストケース１

Copyright©2019 NTT Corp. All Rights Reserved. 21

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

実行回数：２

Symbolic
Execution

concretepublic int testme(int x, int y) state

symbolicstate{

x = x0, y = y0

x = 2, y = 1

path
condition

int z = y*2;
if (x != z){
return 10;}
else{
return 20;}}

Copyright©2019 NTT Corp. All Rights Reserved. 22

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

実行回数：２

concretepublic int testme(int x, int y) state

Symbolic
Execution

symbolic
state

path
condition{
int z = y*2;
if (x != z){
return 10;}
else{
return 20;}

x = 2, y = 1
z=2

x = x0, y = y0z0 = y0 * 2}

Copyright©2019 NTT Corp. All Rights Reserved. 23

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

実行回数：２

concretepublic int testme(int x, int y) state

Symbolic
Execution

symbolic
state

path
condition{

int z = y*2;
if (x != z){
return 10;}
else{
return 20;}x0 == y0 * 2

テストケース2実行完了
パス
return 20
テスト入力値
x = 2, y = 1
x = 2, y = 1
z=2

x = x0, y = y0z0 = y0 * 2}

Copyright©2019 NTT Corp. All Rights Reserved. 24

(1a-2) 動的記号実行(DSE)の例
実行回数：２Concrete
Execution

concretepublic int testme(int x, int y) state

Symbolic
Execution

symbolic
state

path
condition{

int z = y*2;
if (x != z)
x0 == y0 * 2
テストケース2実行完了{
パス
return 10;
return 20}
テストデータ
ここが例えば「x!=z+ReadInt(“test.txt”)」だと，
x = 2, y = 1else
静的記号実行では制約を解くことが難しい．
{
x = 2, y = 1
x = x0, y = y0
return 20;
動的記号実行ではReadInt(“test.txt”）の部分は実行時情報を用いて制約を解く．
z=2
z0 = y0 * 2}（例） 実行したらReadIntの戻り値が2だったった場合，制約条件は「 x != z + 2 」}

Copyright©2019 NTT Corp. All Rights Reserved. 25

(1a-3) サーチベーステスト(SBST)
 ヒューリスティック探索アルゴリズムを用いて達成したい要件を満足するテストスイート（テストケースの集合）を生成する技術の総称
 以下の手順で行われる– (1)達成したい要件に対する達成度合いを定量的に評価できる評価関数を設計– (2)(最初は予め用意した)テストスイートをテスト対象に対して実行し，実行したテストスイートの評価関数の値を取得– (3)評価関数の値が優れているテストスイートを元に，ヒューリスティッ
ク探索アルゴリズムによって新規にテストスイートを生成 要件に対してうまく評価関数を設計することがポイント
 ヒューリスティック探索アルゴリズム– 遺伝的アルゴリズム，山登り法，焼きなまし法，粒子群最適化
Copyright©2019 NTT Corp. All Rights Reserved. 26

(1a-3) SBSTの例(遺伝的アルゴリズムを使用)
要件：分岐１で「b>1」が真(Yes)となるテスト入力値を得る(1)評価関数Eを，E=b-1と設計（Eが大きいほど解に近い）(2)第一世代テストスイートとしてTC1,2,3を用意し実行
TC1(a=-10)E = -10
TC2(a=-3)E= -3
TC3(a=-2)E= -2(3)以下のルールで第一世代から第二世代を生成
・評価値が低いものは殺す
・評価値が高いものは交配してTC4(a=-2.5)を生成
・突然変異としてTC5(a=-14)
第二世代テストスイートTC2,TC3,TC4,TC5を実行，
以降，(2)-(3)を要件を満たす解を得られるまで繰り返す

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

(1a-4)モデルベーステスト(MBT) モデルに基づいてテストスイートを生成する技術の総称– モデルは，何らかの形でテスト対象を記述したもの• モデル：フローモデル，状態遷移モデル，組み合わせモデル，代数的モデルなど• 記法：UML，形式仕様記述，など
Anand, E. K. Burke, T. Y. Chen, J. Clark, M. B. Cohen, W. Grieskamp, M. Harman, M. J. Harrold,– 産業でも成功事例あり(※1) ※1：S.
and P. Mcminn. An orchestrated survey of methodologies for automated software test case generation. Journal

 MBTの特徴

of Systems and Software, 86(8):1978–2001,– モデル(例えばソフトウェア仕様)を用い，様々なテスト技法に基づいて，期待結果も含め網羅的なテストケースを生成できる点は強力– モデルを作るコストがオーバーヘッドとしてかかるため，導入の敷居が高い– 詳細なテストケースを生成しようとすれば，より詳細なモデルが必要
 以下がモデル作成オーバーヘッド軽減には有効・上流工程成果物の一部をモデルとして作りそのモデルからテストをつくる・ソフトウェア実行時の情報から雛形を作る
Copyright©2019 NTT Corp. All Rights Reserved. 28

(1a-4) MBTの例
 機能テスト設計支援ツールTesMa (丹野らの過去の取り組み)※1– 入力はある程度の記述ルールを定めたソフトウェア設計書– ユースケース技法，同値分割/境界値分析といったテスト技法に基づき網羅的なテストケースを生成
出力
入力
テスト項目表ソフトウェア設計書

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

（例）

画面設計書

項番
1
2
…
N

手順
…
…
…
…

テスト用データ

実行用
スクリプト
ファイル

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

処理フロー図

画面遷移図
Copyright©2019 NTT Corp. All Rights Reserved. 29

(1a-5)組み合わせテスト(CT) プログラムへの入力パラメータ(因子)間の相互作用に起因する不具合を効
果的に発見することを目的とする
 テストケースとして因子に割り当てる値(水準)の組み合わせを生成する
 組み合わせ技法に基づくテスト生成ツール– PictMaster，MatrixTester®
 CTの特徴– 因子の組み合わせが膨大に存在し組み合わせの制約などもあり，実施するテス
トケースを絞り込みたいときに有効．
– ユーティリティ的に活用できるので，導入の負担が少ない– 因子，水準の洗い出し作業は人が行う(もしくは別の技術を用いる)必要がある
ソフトウェア実行時情報から因子，水準を抽出する手法もある

Copyright©2019 NTT Corp. All Rights Reserved. 30

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

入力：因子と水準
因子

水準

OS

Win7, Win10, CentOS6

CPU

Corei3, Corei5, Corei7

MEM

2GB, 4GB, 8GB

HDD

128GB, 512GB, 2TB

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

OS
CentOS6
Win7
CentOS6
Win10
Win7
CentOS6
Win7
Win7
Win10
Win10
Win10

CPU
Corei3
Corei7
Corei5
Corei3
Corei3
Corei7
Corei5
Corei7
Corei7
Corei3
Corei5

MEM
2GB
2GB
8GB
8GB
4GB
4GB
2GB
8GB
4GB
4GB
4GB

HDD
2TB
128GB
128GB
512GB
512GB
512GB
512GB
2TB
2TB
128GB
2TB

ペアワイズ法を実装したツールPictMasterを用いて生成した，
2因子間網羅を達成するテストスイート
Copyright©2019 NTT Corp. All Rights Reserved. 31

テスト自動化技術の動向
以下の技術領域(1a),(1b),(2),(3),(4)ごとに技術の動向を紹介する
識別

設計

実装

実行

比較
※1

（１）テストケース生成（１a）テスト入力値生成（１b）テスト期待結果生成（2）回帰テスト(テストスイートの最小化，
テストケースの選択，優先度付，)※2（3）テスト実行ツール(4)テストスクリプティング※1：「比較」については「(1b)テスト期待結果生成」と関連深いため，(1b)の説明の中で紹介する．
※2： (1a),(1b),(2)の分類はMECEになっているわけではない．
Copyright©2019 NTT Corp. All Rights Reserved. 32

(1b)テスト期待結果生成
 テストオラクル問題– 期待結果生成は特に「自動化」が技術的に難しくチャレンジングな領域– 完全な自動生成は本質的に難しい「プログラムへの入力に対する出力(期待結果)が自動生成できるならば，それは正しいプログラムが自動で作れることと同義」• 「テスト不可能プログラム」というオラクルが本質的に存在しないプログラムも存在– テスト入力値生成技術で自動生成したテストケースを活用するためには，
Test Oracle Problemをどのように扱うかが肝 テスト期待結果生成には以下のようなアプローチがある(※1)– (1b-1) 仕様オラクル (Specified test oracle)– (1b-2) 派生オラクル (Derived test )– (1b-3) 暗黙的オラクル (Implicit test oracle)– (1b-4) 人力オラクルの負荷軽減 (Human oracle problem)※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.」における分類

Copyright©2019 NTT Corp. All Rights Reserved. 33

(1b-1)仕様オラクル
 形式的に記述された仕様情報に基づいて，期待結果の生成やテスト結果との比較を行う– 仕様言語• Z言語，UML/OCL，VDM，Alloy，など• モデルの抽象度と同じレベルの期待結果を生成する（より詳細な期待結果を生成したければ，モデルをより詳細化する必要がある）• モデルベーステストはこれに含まれる– アサーション• アサーションは多くのプログラミング言語で提供されている– 契約プログラミング• プログラムコード中にプログラムが満たすべき仕様の記述を盛り込
み，設計の安全性を高める手法

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

(1b-1)派生オラクル
 様々な開発資材(ドキュメント，動的解析情報，システム旧版，など)から派生させてテスト期待結果を生成する– (1b-1-1)疑似オラクル• 「絶対的なオラクル」(仕様オラクル)ではなく，「相対的なオラクル」を用いる（例：Ｎバージョンプログラミング）– (1b-1-2)回帰テスト向けオラクル• 正解とみなせるような「入力-出力のペア」 (例：テスト済みのシステ
ム旧版の入出力結果)を期待結果として用いる– (1b-1-3)仕様オラクルを推定• ドキュメント，動的解析情報などから，仕様オラクルを推定する

Copyright©2019 NTT Corp. All Rights Reserved. 35

(1b-2-1)派生オラクル：疑似オラクル
 デザイン多様性の活用– 同じ機能仕様を満たすプログラムを複数開発し，同じ入力に対して出力結果に差異があれば，どちらかが誤っているとみなす• （例）Nバージョンプログラミング データ多様性の活用– 1つのプログラムに対して，ある入力に対して出力の変化を理論上予想できる
とき，様々な入力に対し予想に反する変化があれば誤りとみなす• （例）メタモルフィックテスティング：「入力の変化」と「出力の変化」の関係で※1：「メタモルフィックプロパティ」と呼ばれることもある．
あるメタモルフィック関係(※1)により期待結果を判定

メタモルフィック関係

変換M(T)
出力値(1)
テスト対象
比較
変換T
出力値(2)
ソフトウェア
期待結果(2)（例）sin関数では「sin (x) = sin (x + 360°)」がメタモルフィック関係となる
入力値(1)
入力値(2)• 疑似オラクルは絶対的なオラクルではないため，正しさの保証はない．
• 疑似オラクルはテスト不可能プログラム(※2)のテストで有効とされている．
※2：人工知能などのように正解値が予めわからず，厳密なオラクルが本質的に存在しないプログラムの総称．

Copyright©2019 NTT Corp. All Rights Reserved. 36

(1b-2-1)派生オラクル：疑似オラクル メタモルフィックテスティング(MT)– 数値計算だけではなく様々な分野へ適用可能• 最近では機械学習プログラムへの適用でも注目されている

メタモルフィックテスティングの適用ドメイン「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を引用– 補足：MTをより一般化した「プロパティベーステスト」という考え方もある• プログラムの入力と出力の関係性に着目して期待結果を自動判定する• QuickCheck(Haskell)が有名，他にも様々な言語においてライブラリが存在
Copyright©2019 NTT Corp. All Rights Reserved. 37

(1b-2-2)派生オラクル：回帰テスト向けオラクル 正解とみなせるような「入力-出力のペア」を用意し，それらを期待結果として用いる– システムの新旧比較，多環境(端末，OS，ブラウザ)間の比較など– 「入力-出力のペア」の作成ではテスト入力値生成技術も活用可能 回帰テスト向けオラクルでは正解との「比較」がポイントとなる(※1)– 比較対象は様々• （例）画面のスクリーンショット，実行ログ，DB状態，バイナリデータ– そのままでは比較しにくいデータはテキスト形式に変換すると比較しやすい– 画面についてはVisual Regression Testing(※2)という分野で多くの画面画像比較ツールが開発されている– 「比較」を自動化する場合，差分として検出してほしくない部分はうまくマ
スキングする必要がある• （例）画面の広告部分，ログにおける時刻※1：「Mark Fewster et al. システムテスト自動化 標準ガイド, テスト自動化研究会訳, 翔泳社, 2014, 第4章」に，回帰テストの場合だけではなく一般の場合の自動比較の方法論が述べられており，参考になる．
※2： https://visualregressiontesting.com/
Copyright©2019 NTT Corp. All Rights Reserved. 38

(1b-2-3)派生オラクル：仕様オラクルの推定 不変条件の推定– 動的解析によりプログラムにおける不変条件を抽出し，アサーションを自動生成する• (例) Daikon(※1)– 精度の高い不変条件が得られるかは与えるテストスイート次第
 機械学習によるオラクル推定– （例）ANNベースオラクル (Artificial neural networks)• 「入力，出力」の正解ペアから学習を行い，モデルを作る• モデルを用いて回帰テスト，新規テストにおいて正解の予測を行う

 自然言語ドキュメントベースのオラクル推定– 自然言語 (or 少し記述にルールを設けた自然言語)ドキュメントからの仕様及び期待結果を抽出• これらの手法はあくまで正解を推定しているのであり厳密ではない※1：https://plse.cs.washington.edu/daikon/

Copyright©2019 NTT Corp. All Rights Reserved. 39

(1b-3) 暗黙的オラクル
 システムの振る舞いを「正しくない」と判断する暗黙的な知識を活用する– オラクルとして活用する暗黙的な知識の例• Null Pointer Exceptions• バッファオーバーフロー• メモリーリーク• ライブロック，デッドロック• Webページのリンク切れ• …

– 低コストで期待結果を作成できるが，確認できる範囲は狭い（システムが仕様に沿って動作しているかは判断できない）– 「暗黙的な知識」は普遍的ではないことにも注意が必要• システムクラッシュは正しい動作でないことが多いが，クラッシュを許容する(or 意
図的にクラッシュするよう設計されている）場合もある

Copyright©2019 NTT Corp. All Rights Reserved. 40

(1b-4)人力オラクルの負荷軽減
 人が確認したいことを確認してくれるテスト期待結果を自動生成することはなかなか難しい そのため，テスト結果は人が確認することも多い
 いかに人が結果確認をする負担を軽減するか？
 人力オラクルの負荷軽減アプローチ– テストを量的に減らす• テストケースの数を減らす(※1)• テストケースの手順やテストデータを最小化する– （例）デルタデバッギング(※2)の考え方を活用し，バグ再現させつ
つテスト手順，テストデータを最小化する– テストの質(人の理解しやすさ)を改善する• 可読性の高いテストケースを生成する– （例）UserNameなら”aaa”ではなく”Taro”と生成※1：これらは「(1)テスト入力値生成」における生成方法の工夫や，「(2)回帰テスト」により実現される※2： A. Zeller and R. Hildebrandt. Simplifying and isolating failure-inducing input. IEEE Trans. Software Engineering, 28(2), Febuary 2002.

Copyright©2019 NTT Corp. All Rights Reserved. 41

テスト自動化技術の動向
以下の技術領域(1a),(1b),(2),(3),(4)ごとに技術の動向を紹介する
識別

設計

実装

実行

比較
※1

（１）テストケース生成（１a）テスト入力値生成（１b）テスト期待結果生成（2）回帰テスト(テストスイートの最小化，
テストケースの選択，優先度付)※2（3）テスト実行ツール(4)テストスクリプティング※1：「比較」については「(1b)テスト期待結果生成」と関連深いため，(1b)の説明の中で紹介する．
※2： (1a),(1b),(2)の分類はMECEになっているわけではない．
Copyright©2019 NTT Corp. All Rights Reserved. 42

(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. 」における分類 (2-1)テストスイート最小化– 特定の要件を満した上で，テストケース数を最小化する• (例)分岐網羅率は同じままテストケース数を最小化する• 一般にはNP困難問題• (1b-4)で紹介した人力オラクルの負荷，メンテナンスコスト，実行時間の削減などが目的

 (2-2)テストケース選択– 修正箇所を意識して，修正版のプログラムをテストするテストケー
ス集合を選び出す• Googleでは13000以上のPJがあり，1日に合計1.5億個のテストケースを実行しているそう．テストケース選択技術の話題もあった(※1)

 (2-3)テストケース優先度付– 順に実行したときに，早く要求を満たすように並べ替える• (例)バグ検出が早く多く行われるよう並べ替える※1：John Micco,” The State of Continuous Integration Testing at Google.”, ICST2017 KeyNote
http://aster.or.jp/conference/icst2017/program/jmicco-keynote.pdf
Copyright©2019 NTT Corp. All Rights Reserved. 43

テスト自動化技術の動向
以下の技術領域(1a),(1b),(2),(3),(4)ごとに技術の動向を紹介する
識別

設計

実装

実行

比較
※1

（１）テストケース生成（１a）テスト入力値生成（１b）テスト期待結果生成（2）回帰テスト(テストスイートの最小化，
テストケースの選択，優先度付)※2（3）テスト実行ツール(4)テストスクリプティング※1：「比較」については「(1b)テスト期待結果生成」と関連深いため，(1b)の説明の中で紹介する．
※2： (1a),(1b),(2)の分類はMECEになっているわけではない．
Copyright©2019 NTT Corp. All Rights Reserved. 44

(3)テスト自動実行ツール/(4)テストスクリプティング
 (3)テスト自動実行ツール：主な自動操作対象 (※1)
– 単体テスト– WebAPIテスト– GUI (Webアプリ，モバイルアプリ)テスト※1：GUIテスト，WebAPIテストは多くのベンダが自動化対象としている（”Magic Quadrant for Software
Test Automation”, Gartner, Nov. 2018より）

 (4)テストスクリプトプティング– テストケースをテストスクリプトとして実装する– テストスクリプトの例 (GUIテスト)
テストスクリプト

テスト
手順

①
②
③

入力値

命令

ロケータ

値

type

id=modlgn_username

user01

type

id=modlgn_passwd

pass01click

css=div.button1

assertTitle

Main

期待結果

テスト対象アプリ

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

①
②

③

Copyright©2019 NTT Corp. All Rights Reserved. 45

(3)テスト自動実行ツール：既存技術の動向
 単体テスト– OSSツール（例：JUnit），市販ツールがある– 市販ツールの方がテストの自動実行以外の機能（例：テストドライバ、スタブの自動生成機能）が充実している
 GUIテスト– Seleniumが有名• プログラミングして作成されたテストスクリプトを実行するSelenium WebDriver• ユーザ操作を記録し実行するキャプチャ＆リプレイツール Selenium IDE– 市販ツールは，Windowsアプリ，Webアプリ，モバイルアプリに対応しているなど使用可能な範囲が広い– 最近はKatalon Studioという無料ツールもあり，ユーザ操作を記録し実行できるだけでなく，マルチブラウザ対応やキーワード駆動を備えるなど高機能である
 WebAPIテスト– Chrome拡張機能（例：Postman）を用いることで，ツール上からWebAPIを呼び出し
結果を確認可能– 市販ツール（例：SOAtest/Virtualize）では，同様の機能に加えてテスト環境の仮想化機能もあり，DBやWebサービスを仮想化でき，他機能が完成してなくてもテスト可

Copyright©2019 NTT Corp. All Rights Reserved. 46

(4)テストスクリプティング
 テストスクリプティングの技法
Mark Fewster et al. システムテスト自動化 標準ガイド, テスト自動化研究会訳, 翔泳社, 2014, 3.2節における分類

リニアスクリプト

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

構造化スクリプティング

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

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

データ駆動スクリプト

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

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

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

より保守性
が高い
Copyright©2019 NTT Corp. All Rights Reserved. 47

(4)テストスクリプティング：データ駆動
データ駆動スクリプトのイメージ– 外部のデータシートを編集することで簡単に実行するテストのバリエーションを増やせる
外部のデータシート
テストスクリプト

テスト
手順

①
②
③

入力値

命令

ロケータ

値

type

id=modlgn_username

input.username

type

id=modlgn_passwd

input.password

click

css=div.button1

assertTitle

usernamepassword

user01

pass01

user02

pass02

・・・

・・・

Main

期待結果

Copyright©2019 NTT Corp. All Rights Reserved. 48

(4)テストスクリプティング：キーワード駆動
 キーワード駆動スクリプトの例– キーワードに対応する操作は外部で実装されている– テスト内容をテストの詳細な実装と分離して記述できる• テストケース作成者とテスト実装者の役割分担も容易になる– キーワードをあらかじめ決めておけば実装工程よりも前の工程でテストスクリプトを作成できる
入力値
テストスクリプト

①
テスト
手順 ②
③

キーワード

ターゲット

値

SetText

Username

input.username

SetText

Password

input.password

Click

LoginButton

CheckTitle

Main

期待結果

Copyright©2019 NTT Corp. All Rights Reserved. 49

(4)テストスクリプティング：ビヘイビア駆動
 関連する話題として「ビヘイビア駆動開発(BDD)」がある– テスト駆動開発から派生– 自然言語に近い書き方で例として仕様を記述– その仕様は自動実行可能なテストとなる– 多くのツールが存在• Specflow, Cucumber, など「いまさら聞けないTDD/BDD超入門（1）：テスト駆動開発／振る舞い駆動開発を始めるための基礎知識 (3/3)」(https://www.atmarkit.co.jp/ait/articles/1403/05/news035_3.html) における「BDDフレームワーク「Cucumber」でのEndTo-Endテストのスクリプトの例」の例を引用

Copyright©2019 NTT Corp. All Rights Reserved. 50

本日の話第一部：テスト自動化の基本的な考え方– テスト自動化の既存ツール，研究の動向– テスト自動化のコツ，課題第二部：NTTにおける研究開発の紹介– 回帰テストの自動化を支援する技術• テスト設計/実装の支援：Regumo• テスト結果確認の支援：ULTDiff– NTTグループにおける普及展開活動

Copyright©2019 NTT Corp. All Rights Reserved. 51

テスト自動化の基本的な方針
 事務的で繰り返し実施する部分を優先的に自動化する（そして，自動化しにくい領域へ人の稼働をまわす）– 自動化は初期コストが手動で1回行うよりもかかるので，繰り返し回数が多くないと元がとれない– テストの「実行，比較」は繰り返すことが多く，効果が出やすい領域• 特に，テストケース間で共通する事前,事後手順部分の自動化は効果あり

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

テスト設計自動化のコツ，課題 ランダムテスト，記号実行，サーチベーステスト– 課題：オラクル問題にうまく対処しないとテスト結果分析に手間がかかる低コストにオラクルを作成でき，効果のある領域を自動化する• セキュリティパッチ適用時に「回帰テスト向けオラクル」でシステムを新旧比較 (※1)
• テスト不可能プログラムや，実装が複雑なアルゴリズムについて，メタモルフィッ
クテスティングなど「疑似オラクル」を活用して強化テストを行う• 暗黙的オラクルを活用し致命的なバグ(クラッシュなど)の検出を狙った強化テスト

 モデルベーステスト– 期待結果含め仕様を網羅的に確認するテストケースを生成できる点は強力– 課題：ただし，モデル作成にはコストがかかる上流工程の成果物(モデル)をうまく活用する，モデルの抽象度をうまく調整
する（どこまで詳細なテストを作りたいか？） 組み合わせテスト– PICTなどのツールがあり，手軽にユーティリティとして活用できる※1：このアプローチには「松尾谷ら: “Concolic Testing を活用した実装ベースの回帰テスト 人手によるテストケース設計の全廃”, SS2015 和歌山」や，第二部で紹介する
Regumo(http://www.ntt.co.jp/RD/active/201702/jp/pdf_jpn/04/D-21_j.pdf)などがある．

Copyright©2019 NTT Corp. All Rights Reserved. 53

テスト実装とテスト実行自動化のコツ，課題(1) 上位のテストほどテスト実装に手間がかかり，テスト実行には時間がかかる– GUIのテストは特に実装，実行のコストが大きい
 UIは変更頻度が高い場合が多く，テストのメンテナンス頻度も高くなるなるべく下位で自動実行できるテストケースを用意する
・作成にコスト(大)・実行時間(長)UI(例)GUI

Service(例)WebAPI

・作成にコスト(小)・実行時間(短)Unit(例)Java, JavaScriptのメソッド
Martin FowlerのTest Pyramid（例はWebアプリケーション）

Copyright©2019 NTT Corp. All Rights Reserved. 54

テスト実装とテスト実行自動化のコツ，課題(2) 手軽に始めるならばキャプチャ＆リプレイ– SeleniumIDE，KataronStudioなどはフリーで使える 再利用性，保守性を高めるにはデータ駆動，キーワード駆動などの考え方を導入– プログラマとテスト担当者の役割分担を明確化することも重要 課題– スクリプトを作成することは手間 (手動作成の約5倍かかるといわれる)– 5回以上繰り返される部分に絞る（ただ，投資対効果を予想するのは難しい…）継続的インテグレーション(CI)と併用するのがよさそう– GUIテストのスクリプトは壊れやすい• GUI変更に伴いテストスクリプトにおけるロケータの参照先が存在しなくなるなど– CIで動かし続ける．CIはソフトウェア，テストの両方について壊れたらすぐに検知してくれる
Copyright©2019 NTT Corp. All Rights Reserved. 55

本日の話第一部：テスト自動化の基本的な考え方– テスト自動化の既存ツール，研究の動向– テスト自動化のコツ，課題第二部：NTTにおける研究開発の紹介– 回帰テストの自動化を支援する技術• テスト設計/実装の支援：Regumo• テスト結果確認の支援：ULTDiff– NTTグループにおける普及展開活動

Copyright©2019 NTT Corp. All Rights Reserved. 56

NTTにおける研究開発の紹介
 今回，回帰テストの自動化を支援する技術の取り組みを紹介します Regumo– 今あるソフトウェアの仕様を復元し，自動でテスト設計，実装を行う技術 ULTDiff– 2つのアプリ画面の差異を画面要素単位で検出し，テスト結果確認を支援する技術

Copyright©2019 NTT Corp. All Rights Reserved. 57

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 NEXt
level 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)

Copyright©2019 NTT Corp. All Rights Reserved. 58

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

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

テスト

開発

そのため、テスト自動化による省力化が求められています。
Copyright©2019 NTT Corp. All Rights Reserved. 59

課題
テスト実行を自動化する場合の課題
 テストスクリプト作成に稼働がかかる テストスクリプト作成のスキルが必要
テストススクリプト作成作業
仕様・テスト項目
理解

具体的手順
作成

スクリプト
作成

画面自動操作＆結果確認

スクリプト
修正＆再実行

Copyright©2019 NTT Corp. All Rights Reserved. 60

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

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

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

テスト自動実行
出力情報<HTML><HEAD>#CONFIG
Param1=あいうえお

public class Hello{
public static voidmain(String[]args){
System.out.
println("Hello,world.");}}

旧ソースコード

動作する
旧アプリ

リ

グ

モ

Regumo

自動で実行できるテスト
スクリプト
アプリの
仕様情報

テスト結果
テスト実行
ツール
（市中技術）

テスト結果
レポート
テスト項目1
テスト項目2
・・・

成功
失敗
・・・

新アプリ

(画面遷移図など)

特徴

 ソースコードと動作するアプリを与えれば使える
 スクリプト作成に稼働がかからず、スキルも不要
 テスト対象アプリを知らなくてもよい
Copyright©2019 NTT Corp. All Rights Reserved. 61

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

Copyright©2019 NTT Corp. All Rights Reserved. 62

Regumo：工夫点
 自動で判断できない箇所は人がヒントを与え，その情報を活用してRegumoが再度解析を行い，より多くの画面を網羅するテストスクリプトを生成する– 課題(1)：特定の入力値がないと先へ遷移できないケースがある• (例)ログイン画面では適切なログインID，パスワードによりログイン可– 人が各画面で用いる入力値を補助することが可能(※1)• Regumoはテスト対象から入力フォームを自動で検出し，各入力フォームに対応する入力値を指定するフォーマットを自動生成– 課題(2)：Regumoが認識する「画面」の粒度と，テスト担当者が期待する「画面」の粒度は異なる– 人がRegumo出力結果の画面遷移図を確認し，Regumoが認識する「画面」の粒度を調整することが可能(※2)• (例)以下の画面(a),(b)はテスト担当者としては同一画面/異なる画面のどちらと判断したいか？
画面(a)
画面(b)
※1：倉林 利行, 切貫 弘之, 丹野 治門: "テストスクリプトの自動生成におけるテスト入力値作成支援技術の提案",情報処理学会 研究報告ソフトウェア工学 , vol. 2018-SE-199, no. 13, pp.1-7, 2018年7月※2：倉林 利行, 切貫 弘之, 吉村 優, 安達 悠, 丹野 治門: "テストスクリ
プト自動生成における適切な粒度の画面遷移テストの試み",電子情報通信学会技術研究報, vol. 118, no. 471, SS2018-75, pp. 139-144,
2019年3月
Copyright©2019 NTT Corp. All Rights Reserved. 63

ULTDiffの紹介– 2つのアプリ画面の差異を画面要素単位で検出し，テスト結果確認を支援する技術– 参考文献• Haruto Tanno, Yuu Adachi: “Support for Finding Presentation Failures by Using
Computer Vision Techniques”, Testing – Practice and Research Techniques, 13thWorkshop on Testing: Academia-Industry Collaboration, Practice and ResearchTechniques (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)

Copyright©2019 NTT Corp. All Rights Reserved. 64

背景
改造や移行に伴いアプリ画面の「現新比較」
が必要• 機能の追加・修正• サーバやフレームワークの更改• OS・ミドルウェアのアップデート

アプリ画面がデグレードなく表示されることを目視で確認することは大変
Copyright©2019 NTT Corp. All Rights Reserved. 65

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

Copyright©2019 NTT Corp. All Rights Reserved. 66

正解
1

1

2

2

3

3

Copyright©2019 NTT Corp. All Rights Reserved. 67

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

様々な環境でアプリ画面の間違い探しを簡単に
UIレイアウトテスト技術ULTDiff
様々な環境ごとのアプリ画面における間違い(画面要素の位置ズ
レ、消失等)を自動検出し、テスト結果確認、報告を楽にします
製造して
設計して
テストする
ソフトウェア開発
様々な環境

誤り箇所の詳細[誤り箇所の詳細]

テスト実行結果
スクリーン
ショット[誤り箇所の詳細]

① ①①
②
② ②③
③
④
④

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

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

実施者

目視で大量のテスト結果を確認
Copyright©2019 NTT Corp. All Rights Reserved. 69

様々な環境でアプリ画面の間違い探しを簡単に
UIレイアウトテスト技術ULTDiff
様々な環境ごとのアプリ画面における間違い(画面要素の位置ズ
レ、消失等)を自動検出し、テスト結果確認、報告を楽にします
製造して
設計して
テストする
ソフトウェア開発

本技術により支援！

誤り箇所の詳細[誤り箇所の詳細]
① ①①

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

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

実施者

テスト実行結果
スクリーン
ショット[誤り箇所の詳細]

②
② ②③
③
④
④

様々な環境

目視で大量のテスト結果を確認
Copyright©2019 NTT Corp. All Rights Reserved. 70

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

さきほどの，Regumoのデモの続きをご紹介
Copyright©2019 NTT Corp. All Rights Reserved. 71

ULTDiff：工夫点
 課題：「比較」を自動化する場合，差分として検出してほしくない部分はうまくマスキングする必要がある– （例）広告部分，ニュース部分など 画面構成部品との相対的な位置関係によって領域を指定する(※1)– テスト対象の画面において，部品との位置関係からマスク領域を再計算し，領域のサイズ・位置の変化に追随①マスク領域指定フェーズ②差異検出フェーズ
正しく表示された画面（旧バージョン）正しく表示された画面（旧バージョン）

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

マスク方向
マスク方向

マスク方向

比較

マスク方向

マスク方向
マスク方向
※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.

Copyright©2019 NTT Corp. All Rights Reserved. 72

NTTグループにおける技術の普及展開活動
以下のようなことを心がけて普及展開活動を行っています 技術開発– (1)コンセプト段階から現場と議論することで，現場担当者にも技術の愛着を醸成 (IKEA効果)– (2)開発と現場評価のサイクルを回し，フィードバックを元に繰り返し改善

 事業展開– (3)愚直な営業活動による顧客エンゲージメントの獲得
個別訪問，勉強会/展示会を多数実施– (4)わかりやすいコンセプトを提示することで、現場業務での具体的な利用シーン・価値を容易に想起– (5)トータルソリューションでの提案により、プロダクトの価値訴求を強化
Copyright©2019 NTT Corp. All Rights Reserved. 73

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

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

1
2

3

3

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

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

トータル
ソリューション

Regumo
NTT技術

Selenium

ULTDiff

市中技術

NTT技術

Jenkins

市中技術
Copyright©2019 NTT Corp. All Rights Reserved. 75

NTTグループにおける技術の普及展開活動（続き）
 事業展開⇔技術開発の好循環は，両者を大きくレベルア
ップしてくれる
 技術開発と事業展開の両立は大変だが，作った成果が活用される喜びは技術者冥利につきる 国内外のコミュニティで対外発表，議論をして視野を広げ人脈形成することも技術開発，事業展開で有用– 丹野はチームメンバ全員が積極的に対外発表していく雰囲気づくりを推進している• 今年度の実績：メンバ5人で17件(1人3件以上)の投稿
Copyright©2019 NTT Corp. All Rights Reserved. 76

本日の話（振り返り）第一部：テスト自動化の基本的な考え方– テスト自動化の既存ツール，研究の動向– テスト自動化のコツ，課題第二部：NTTにおける研究開発の紹介– 回帰テストの自動化を支援する技術• テスト設計/実装の支援：Regumo• テスト結果確認の支援：ULTDiff– NTTグループにおける普及展開活動

Copyright©2019 NTT Corp. All Rights Reserved. 77

おわりに：テスト自動化の将来
 現在は「テストの実行」自動化が主流，次は「テストの設計，メンテ
ナンス，最適化」自動化へと進む (※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.

Copyright©2019 NTT Corp. All Rights Reserved. 78