ライブラリのバージョン更新支援のための実行トレースからのテストケース生成
嶋利 一真1,a)

石尾 隆2,b)

井上 克郎1,c)

概要：ソフトウェア開発において，ライブラリの利用が盛んに行われている．ライブラリは機能追加やバグ修正のために頻繁に更新されており，その変更がソフトウェアの振舞いを変えてしまう可能性がある．
本研究では，利用するライブラリを更新したときの影響の評価を低コストで行うために，ライブラリ更新前後におけるソフトウェアの動作を記録，比較する手法を提案する．

1. はじめに互換性を効率的に検証可能とすることを目標とする．具体的なアプローチとして，ライブラリ更新前後におけるソフ

ソフトウェア開発において，ライブラリの利用が盛んにトウェアの動作を比較する手法を提案する．ライブラリ更行われている．ライブラリは機能追加やバグ修正のために新前の入力と出力の組をテストケースとして，更新後の入頻繁に更新される [1]．しかし，ライブラリの新しいバー力に対しての出力と比較しそれが一致するかどうかを確認

ジョンが後方互換性を持たない場合もあり，開発に利用すすることで，ライブラリ更新の影響がソフトウェアにあるるライブラリを更新することがソフトウェアの振舞いを変かどうかを確認する．

えてしまう可能性がある．Mostafa らの調査 [2] では，ライブラリの新しいバージョンの 76.5%が後方互換性を持っ2. 背景ていなかったと報告されている．また，ライブラリ更新時ライブラリの更新がソフトウェアに与える影響を評価すの回帰テストが不十分である場合が多いことも指摘されてる方法としては，回帰テストの実施が一般的である．ソフいる．

トウェアに対して用意されたテストスイートをライブラ

ライブラリの更新の中には，セキュリティ脆弱性などのリ更新後のソフトウェアに対して実行し，更新前と同様の問題の修正も含まれるため，利用するライブラリの更新を動作をすれば影響がないと判断できる．しかし，単体テス行わないと，ソフトウェアがライブラリに起因する問題のトのような単純なテストでは，ライブラリの振舞いのバー影響を受ける危険性が高まる．しかし，ライブラリの振舞ジョン間での差異が十分に検証できない場合があり，連続いの変化の影響を避けるためにライブラリの更新バージョした多くの API の呼出しを含むような回帰テストの充実

ンの利用に消極的な開発者も多い [1]．ライブラリの新しが必要である [2]．そのためには結合テストや受け入れテ

いバージョンが公開されたことを開発者に通知する仕組み

ストの実施が考えられるが，ライブラリの更新は頻繁に行は存在しているが，新しいバージョンのライブラリではソわれるため，更新の都度，結合テスト等を実施すると実施フトウェアが動作せず，開発者が以前のバージョンに戻すコストが大きくなるという問題がある．という事例も観測，報告されている [3]．

類似した挙動をするソフトウェアの振舞いの差異を見つ

本研究では，ライブラリ利用者の新しいバージョンへのける手法としては，Relative Debugging [4] がある．これ

移行を支援するために，利用している機能に限定した後方はソフトウェアの実行環境の変化やマイグレーションの際

12a)
b)
c)

大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology, Osaka University.
奈良先端科学技術大学院大学情報科学研究科
Graduate School of Information Science, Nara Institute ofScience and Technology.
k-simari@ist.osaka-u.ac.jpishio@is.naist.jp
inoue@ist.osaka-u.ac.jpに，新しいソフトウェアが過去のバージョンと同様の動作をするかの確認のために提案された手法である．両ソフト
ウェアが各実行ステップにおいて同一のデータを保持しているかを確認していき，差分が生じた段階でそれを開発者に通知する．この手法は，性質上，各ステップごとにすべてのデータを記録，比較する必要があり，大規模ソフトウェ

アで取り扱うデータ量が大きくなると適用が困難となる．

䝷䜲䝤䝷䝸A᭦᪂๓䝷䜲䝤䝷䝸A᭦᪂ᚋ

1: private void test(int x){
2: int a=0;
3: // A:ᐇ⾜๓
4: x=library(a);//ver1.0
5: // B:ᐇ⾜ᚋ
6: System.out.println(x);7: }1: private void test(int x){
2: int a=0;
3: // A’:ᐇ⾜๓
4: x=library(a);//ver1.15: // B’:ᐇ⾜ᚋ
6: System.out.println(x);7: }ライブラリの更新前後でのプログラムの実行トレースを比較する手法として POLLUX [5] が提案されている．この手法はライブラリが内部で呼び出すシステムコールの列の変化や，メモリへの書き込みの変化を比較し，動作の変化を検出する．しかし，動作の変化があると判断された場合に，利用ソフトウェアの機能に与える影響を確認することは難しい．
ライブラリの動作の差異を可視化する手法として，Dif-fGen [6] が提案されている．この手法は Java クラスの 2つのバージョンを入力として受け取り，それらの振舞いの違いが明らかになるように，同一の入力を 2 つのクラスに与えて出力を比較するようなテストケースを生成する．こ

図 1

ライブラリ更新時の振舞いの変化の確認

手作業でライブラリのテストケースを記述することなく，ソフトウェアの何らかの動作に対応したライブラリの振舞いに関するテストを可能とする．

4. まとめと今後の課題の手法はクラスの動作の差異を容易に確認することができるが，ソフトウェアでの API の利用方法に対応したテストケースとなるとは限らない．

本研究では，ライブラリの新しいバージョンが後方互換性を持つかを検証するために，ライブラリの更新前後におけるソフトウェアの動作を記録，比較するためのテスト

3. 提案手法
本研究では，利用するライブラリの更新がソフトウェアの振舞いに与える影響を低コストで評価するために，ライブラリの更新前後におけるソフトウェアの動作を記録，比較する手法を提案する．具体的な方法としては，ソフトウェアの実行から現在利用中のライブラリに対する入力と出力の組を収集し，テストケースへと変換することで，新ケースを生成する手法に取り組んでいる．今後の課題として，十分なテストケースの作成のためにソフトウェアにおいてどのような情報を必要とするのか，そして実際のライブラリの更新に対して十分なテストケースを生成できるかどうかを調査していく必要がある．
謝辞 本研究は JSPS 科研費 JP25220003，JP26280021の助成を受けたものです．

しいバージョンのライブラリに対して同じ入力を行った場合の出力と一致するかどうかを確認する．テスト実行の結果が完全に一致した場合は，ライブラリが後方互換性を維

参考文献
[1]

持していると推測できる．
提案手法の動作を図 1 に示すプログラム例を通じて説明する．更新前のライブラリを v1 ，更新後のライブラリ[2]を v2 とすると，まず，プログラム中で 4 行目のライブラ
リ v1 に対する呼び出し直前の 3 行目の地点 A で，ライブラリへの入力を記録し，次に，ライブラリ v1 を呼び出し[3]た直後の 5 行目の地点 B でライブラリの出力を記録する．
ライブラリ v2 に対しても同様の操作を行い，ライブラリv1 における地点 A から B にかけての入出力の情報の変化と，ライブラリ v2 における地点 A’ から B’ にかけての入[4]出力の情報の変化を比較する．そして，ソフトウェア側で利用する変数の情報の変化が同一であれば，ライブラリの更新はソフトウェアに影響を全く与えていないことが分か[5]

る．ライブラリ呼び出し前後の値のみを比較するため，差異が生じた場合は，その原因はライブラリ側にあり，ソフトウェア側の影響ではないこともわかる．
実行トレースの比較を継続的に利用するために，ソフトウェアに対する単体テスト，結合テストや受け入れテストの実行からトレースを収集し，ライブラリに対する操作のみを抽出してテストケースへと変換する．結合テストや受け入れテストにおける動作を再利用することで，開発者が[6]Ihara, A., Fujibayashi, D., Suwa, H., Kula, R. G. and Matsumoto, K.: Understanding When to Adopt a Library: A
Case Study on ASF Projects, Open Source Systems: Towards Robust Practices, pp. 128–138 (2017).
Mostafa, S., Rodriguez, R. and Wang, X.: Experience paper: a study on behavioral backward incompatibilities ofJava software, Proceedings of the 26th ACM SIGSOFTInternational Symposium on Software Testing and Analysis, pp. 215–225 (2017).
Mirhosseini, S. and Parnin, C.: Can automated pull requests encourage software developers to upgrade out-ofdate dependencies?, Proceedings of the 32nd IEEE/ACM
International Conference on Automated Software Engineering, pp. 84–94 (2017).
Abramson, D., Foster, I., Michalakes, J. and Sosi, R.:
Relative debugging: a new methodology for debugging
scientific applications, Communications of the ACM, pp.
69–77 (1996).
Kalra, S., Goel, A., Khanna, D., Dhawan, M., Sharma,
S. and Purandare, R.: POLLUX: safely upgrading dependent application libraries, Proceedings of the 2016 24thACM SIGSOFT International Symposium on Foundations of Software Engineering, pp. 290–300 (2016).
Taneja, K. and Xie, T.: DiﬀGen: Automated Regression
Unit-Test Generation, 2008 23rd IEEE/ACM International Conference on Automated Software Engineering,pp. 407–410 (2008).