今日読んだのはこちら。
Wetzlmaier, Thomas, and Rudolf Ramler. 2017. “Hybrid Monkey Testing: Enhancing Automated GUI Tests with Random Test Generation.” In Proceedings of the 8th ACM SIGSOFT International Workshop on Automated Software Testing, 5–10. A-TEST 2017. New York, NY, USA: Association for Computing Machinery.
読もうと思ったきっかけ、参照していたもの
大昔に「読もう」と思ってPDF保存していたのが目に入った
メモ
論文の概要
- 多くのプロジェクトで回帰テストのために自動GUIテストが導入されている
- しかし、これらは新しいバグは見つけられない
- 既存の自動化された回帰テストに、ランダムなテストを生成して組み合わせるハイブリッドな手法を提案する
- 本手法により、画面のカバレッジが平均23.6%、コードカバレッジが12.9%向上した。
背景
- GUIでの回帰テストが自動化されることは多いが、バグを見つけるという点では実装中もしくは最初の実行時だけで、以降は確認が主になる
- 新しいバグを見つけようとする、破壊的なテストとは対照的
- ランダムテスト、という手法はテストケース生成技術として研究されてきた
- メリットは、普通ユーザーがやらないようなシナリオを実行できる点
手法
- 著者らの以前の研究で、ランダムテスト生成のフレームワークを実装した
- 本研究では、既存の自動テストケースのステップが終了した後に、そのままランダム操作を追加する
- この間SUTの再起動などははさまない
- SUTはKeePassというアプリケーション
- C#製、Windowsデスクトップアプリ、38のダイアログウィンドウがある
- Ranorexを使用
結果
実験によって新しい欠陥が見つかることは考えにくいので、欠陥検出ではなくカバレッジを指標とした。
カバレッジが増えれば、欠陥検出能力が高くなる、という考え。
- RQ1:本手法によって、既存のテストケースからどのくらい、操作するダイアログウィンドウが増えるか
- RQ2:本手法によって、コードカバレッジはどの程度増加するか
- RQ3:新たにいくつの欠陥が検出されるか
RQ1について、つまりウィンドウカバレッジについては、平均で23.6%増加した。 ただし、既存のテストすべて合わせると38の全ウィンドウをカバーするようになっているので、テスト総体としてのカバレッジは変わらない。あくまでもテストケースごとのカバレッジの増加。
RQ2については平均12.9%増加した。
また本実験では、RQ3については3つの欠陥を発見した。クラッシュ2件、例外がスローされるのが1件。
感想
考え方としては面白いものの、ランダム実行でカバレッジを擬似的に増加させることによるメリットをあまり感じない気がした。使い所のイメージがついていない、が正しいかもしれない。
2017年の論文ではあるが対象がデスクトップアプリという点が影響しているのかもしれない。
むしろ最近読んでいたRegression Test Selection関連の論文のように、テストケースをいかに絞るかのほうがリリースサイクル高速化に効いて来るはず。本研究だとリグレッションテストのケース数は（見かけ上）変わらないけれども、実行時間は確実に増えてしまうので、その点が許容できるか。
またWebアプリケーションの場合、ランダムに画面を行き来したり、画面のカバレッジを考えたりするのは厳しい予感。
そうした意味でも、高速にリリースサイクル回したいという場面ではなく、多少時間がかかったとしてもカバレッジを上げて欠陥を見つけたい、という性質のアプリケーションに向いているかもしれない。
自動化されたリグレッションテスト＋テストエンジニアが設計したテスト＋ランダム生成したモンキーテスト、の組み合わせでTesting＋Chekingをカバーかな。それこそAI-drivenな手法が登場して、各レイヤーにおける自動テスト＋プロによる探索的テスト＋AIによるアプリケーション回遊モンキーテスト、みたいな組み合わせで品質担保するようになるのかな。
次に気になっているもの
ICST2022の一覧を眺めていたところ目に止まったので。