今日読んだのはこちら。
Harrold, Mary Jean, James A. Jones, Tongyu Li, Donglin Liang, Alessandro Orso, Maikel Pennings, Saurabh Sinha, S. Alexander Spoon, and Ashish Gujarathi. 2001. “Regression Test Selection for Java Software.” SIGPLAN Not. 36 (11): 312–26.
読もうと思ったきっかけ、参照していたもの
メモ
論文の概要
- 回帰テストは広く用いられるが、実行コストがかかる場合がある
- これを削減するため、Regression Test Selection（回帰テスト選択、RTS）という手法がある
- ここまでは昨日読んだUnderstanding and Improving Regression Test Selection in Continuous Integration.と同じ
- Java向けのRTSで、他の手法が対応していないもの（例外処理、多相などを含むコード）も扱える手法を提案
- かつ、RETESTという仕組みとして実装した
背景
- 回帰テストはコストがかかるので、それを削減する技術が考えられている
- これまで、手続き型言語向けのものや、オブジェクト指向言語向けのものが開発されてきた
- しかし、例外処理、多相などがあると扱えなかった
- 一方テストの専門家は、テストケースの削減には消極的
- そのため、安全な回帰テスト選択手法がこれまでも開発されている
- 適切にRTSができると、実行時間が短くなるので、テストの頻度を上げられる
手法
- 制御フローグラフ（Control Flow Graph, CFG）を拡張したJava Interclass Graph(JIG)という表現を用いる
- 変数とオブジェクト型情報
- 内部・外部メソッド
- メソッド間呼び出しの相互作用
- 例外処理
- などを扱える
正直この先の、JIGでモデル化したコードをグラフトラバーサルして危険なところを見つけ、そこから実行すべきテストを判断する流れが理解できず・・・。
RETESTの構成がこれ。
- Profiler:動的情報を収集するコンポーネント
- JABA(JavaARchitecture for Bytecode Analysys)
- DejaV00:静的解析コンポーネント
- デジャヴと読ませるのかな
- SelectTest:テスト選択コンポーネント
結果
Java製の以下4つを対象に調査した。
- Siena
- JEdit
- JMeter
- RegExp
調査は大きく２つ。
- Test Suite Reduction どのくらいテストスイートを削減できるか
- Test Selection Granularity テスト選択の粒度
ひとつめの削減度合いは、（当然な気もするけれども）対象のコードやソフトウェアやバージョンに依存するため、傾向などは見られない。
Vがソースのバージョン。安直に考えて、バージョン間の変更差異が少ない場合はテストの削減量も多くなり（選択されるテストが少なくなり）、変更差異が大きければテストの削減量が減る。今回の調査だと、バージョン間の差異は各ソフトによって完全にバラけているので、横ならびに比較するのは厳しいのでは・・・と思った。
テスト選択の粒度について。こちらは、
- メソッドレベルの選択
- エッジレベルの選択
という2つの手法を比較している。これはコード変更の影響範囲を調べる際のやり方の違いで、ざっくりエッジレベルのほうが細かいところまで見るので、よりテストケースを削減できるはず、と理解。
実際Sienaでは効果が出ているが、必ずエッジレベルが削減されるというわけではなく、メソッドレベルとエッジレベルとで選択されるテストケースが同数なこともあれば、エッジレベルのほうが少ないこともある。という結果。
さすがにメソッド＜エッジ、は無い模様。
感想
内容とは直接関係ないけれど、ソースコードをグラフ化してそこに対して危険なエッジを見つけに行く手法が理解できなかった。
論文読むスタンスとして、本当は読み込んで理解するまでやるべきなんだろうけれども、そもそも前提知識が足らんので一旦区切りにする。
今やっているこの毎日論文読み自体が筋トレみたいなもので、一つを深く読み込むよりも習慣化と浅く広くを重視するので、まずはわからなかったら分からなかったで、読み始めたその日にメモを記事化して読み終わりとする。（翌日は別の論文を読む）。というルールでやってみることにする。
参考
次に気になっているもの
ちょっと別の方面に手を伸ばしてみようかと思うので。