ICST 2022 Research Papersに採択された論文のアブストラクトを翻訳したので紹介する

Jasst nano 2022/03/15にて。

Transcript

1. ICST 2022 に採択された論文の アブストラクトを紹介する hideshis
2. 目次 • 自己紹介 • 今回やること/やらないこと • ICST? • 各論文のアブストラクト紹介
3. 自己紹介 • 名前: hideshis（ひでしす） • 経歴: ◦ 現在: フリーランスQAエンジニア ◦ 過去: 日系ベンチャー→日系大手→日系ベンチャー→グローバル企業（全て QAエンジニア） • スキルセット: 主にテスト自動化（E2Eテスト、APIテスト） • twitter: @hideshis_qa2
4. 今回やること/やらないこと • やること ◦ ICST 2022 Research Paper で採択された論文のアブストラクトを、時間の許す限り（日本語で）紹 介する • やらないこと ◦ Research Paperで採択された論文の詳細な紹介 ◦ Research Paper以外のトラックで採択された論文の紹介 ◦ 専門用語の解説
5. ICST? • International Conference on Software Testing, Verification and Validation • ソフトウェアテストをテーマにした、国際的に有名な学術会議 ◦ アカデミックな研究だけでなく、産業界での取り組みを紹介するトラックもある • 2017年には東京で開催された ◦ http://aster.or.jp/conference/icst2017/ • 2022年は、4月にオンラインで開催される予定 ◦ https://icst2022.vrain.upv.es/
6. A Framework for Automated API Fuzzing at Enterprise Scale Webベースのアプリケーションプログラミングインターフェース（ API）は、SOAP、OpenAPI、GraphQLな どの仕様で記述されることが多い。これらの仕様は、ウェブサービスを定義する一貫した方法を提供し、 automated fuzz testingを可能にします。そのため、多くの fuzzerがこれらの仕様を利用している。しか し、企業環境では、通常、ツールは個々のチームによってインストールされ、拡張されるため、工数の重複 が発生します。必要に応じて fuzzerを導入できるような、共有された、コスト効率のよい、 off-nominalなテ ストを大規模に提供する、企業規模の fuzz testing solutionが必要となる。インターネットのクラウドベース のfuzz testing-as-a-service solutionsは、拡張性の懸念を軽減しますが、外部インフラに成果物をアップ ロードする必要があるため、必ずしも実行可能とは限らない。一般的に、企業のポリシーにより、コスト、知 的財産、およびセキュリティの懸念から、成果物を第三者と共有することはできない。本研究では、 APIの 仕様を活用し、cluster computing elasticityと組み合わせることで、複数のアプリを一度にファジングで き、企業の信頼境界を維持できる、自動的でスケーラブルなフレームワークを構築します。
7. An Empirical Study of IR-based Bug Localization for Deep Learning-based Software deep-learning-based software (DLSW)の影響力が増すにつれ、 DLSWの品質を保証するための自動デバッ グ技術の重要性が増している。 Information-retrieval-based bug localization (IRBL)技術は、バグのあるエン ティティ（ファイルや関数）を自動的に局所化することでデバッグを支援することができる。 IRBLは低コストである ため、DLSWの複雑さによるバグ位置の特定困難さを緩和することができます。しかし、 DLSWと従来のソフト ウェアには大きな違いがあり、その違いは IRBLの検索空間とクエリ品質の違いにつながる。つまり、 IRBLの性 能はDLSWで検証する必要がある。 我々は以下の4つの観点からDLSWにおけるIRBLの性能を実証的に検証した。 1) 類似性モデル、2) クエリ生 成、3) バグファイル局所化のためのランキングモデル、 4) バグ関数局所化のためのランキングモデルである。 4つのリサーチクエスチョンと 136のDLSWプロジェクトからの 2,365件のバグ報告を用いた大規模実験に基づ き、IRBLの観点からDLSWの顕著な特徴を確認し、実証結果から DLSWにおけるIRBL実用化のための4つの 提言を導き出した。 IRBL性能については、バグ関連機能を組み合わせた IRBL性能が、ファイルの類似性のみ を用いた場合の性能を 15%上回り、IRBLによるバグのあるファイルや関数の平均順位がそれぞれ 1.6位、2.9 位であることを検証した。本研究は、 IRBL研究者のベースラインとして、また、 DLSWの品質を確保するために IRBLを適用したいDLSW開発者のガイドラインとして有用である。
8. Applying Symbolic Execution to Test Implementations of a Network Protocol Against its Specification ネットワークプロトコルの実装は、セキュリティの脆弱性や相互運用性の問題を回避するため に、その仕様に準拠する必要があります。本論文では、あるネットワークセキュリティプロトコル の実装を、その仕様に照らして徹底的にテストするために、 symbolic executionを使用した経験 について述べる。私たちは、まずプロトコルのRFCから要件を抽出し、それを数式化する手法を 採用しています。この数式を利用して、プロトコルの実装をシンボリックに実行し、要件に違反す るパケットシーケンスで通過可能なコードパスを探索する。この探索によりバグが発見されると、 対応する入力値が生成され、元の実装のバグを検証するためのテストケースに変換される。 symbolic executionを要件によって誘導させるため、既存のプロトコルテスト技術では困難な、 多種多様な要件違反の入力列を自然に生成することが可能である。この手法を応用し、 DTLS の4種類の実装をプロトコルのRFCに照らしてテストしました。その結果、旧バージョンの OpenSSLに存在する既知のCVEを迅速に発見し、現在では実装者によって確認・修正されて いるDTLSの実装において多数の未知の脆弱性や不適合な問題を発見することができた。
9. A Qualitative Study on the Sources, Impacts, and Mitigation Strategies of Flaky Tests Test flakinessは、テストの大きな課題である。Flaky testsは、非決定的な結果をもたらし、継続 的インテグレーションを阻害し、開発者に誤ったアラートを調査させる。産業界の報告によると、 大規模なテストでは、flaky testsの蓄積はテストスイートの信頼を失い、大きな計算コストがかか ることが分かっている。このような状況を打開するために、実務者は、 flaky testsを特定し、その 影響を調査することを強いられている。このような軽減メカニズムを明らかにするために、我々は 14人の実務家にインタビューし、grey literature reviewを行った。その目的は、（i）testing ecosystem内のflakinessの原因、（ii）flakinessの影響、（iii）flakinessに対処するために実務家 が採用した手段、（iv）これらの手段の自動化の機会、を明らかにすることである。我々の分析に より、テストとコードの他に、システムコンポーネント、テストインフラ、および外部要因の間の相 互作用がflakinessを引き起こすことを判明した。また、flakinessがtesting practicesと製品品質 に与える影響を明らかにし、安定したインフラストラクチャとガイドラインの採用が、この問題を軽 減するための重要な手段であることを示す。
10. As Code Testing: Characterizing Test Quality in Open Source Ansible Development AnsibleのようなInfrastructure as code (IaC) scriptsは、コンピューティングインフラを大規模にプロビジョニング するために使用される。 IaCテストスクリプトに設定やセキュリティのバグが存在すると、プロビジョニングされた コンピューティングインフラにとって重大な影響を及ぼす可能性がある。 IaCテストスクリプトのバグの特徴に関 する研究は、IaCスクリプトのテスト中に発生する品質に関する懸念を理解し、実務者へ品質保証に関する提言 を行うための最初のステップとなるものである。我々は、 104のオープンソースソフトウェア（ OSS）リポジトリから 収集した4,831のAnsibleテストスクリプトを用いて実証研究を行い、バグ頻度の定量化とテストスクリプトのバグ の分類を行った。さらに、バグの出現頻度と相関のあるテストパターン（テストスクリプト内で繰り返されるコー ディングパターン）を分類している。実証実験の結果、 4,831個のAnsibleテストスクリプトのうち 1.8%がバグを含 んでおり、104個のリポジトリのうち 45.2%が少なくとも1つのバグを含むテストスクリプトを含んでいることが確認 された。バグには、セキュリティバグ、メタデータ抽出に関連するパフォーマンスバグなど、 7つのカテゴリがあ る。また、バグの出現と相関のあるテストパターンとして、「 assertion roulette」、「local only testing」、「remote mystery guest」の3つを特定した。最後に、本論文で得られた知見が実務家に与える影響について考察する。
11. A Survey on How Test Flakiness Affects Developers and What Support They Need To Address It 近年、ソフトウェア工学の研究において、非決定論的なテストケースの合格・不合格、いわゆる「 failing test」が注目されるようになってきている。この研究は産業界から熱狂的な支持を受けているが、先行研究 では、ソフトウェアリポジトリをマイニングしてコード中心のアプローチで flakinessを研究することがほとん どであった。しかし、ソフトウェアリポジトリから抽出されたデータでは、開発者が Flakinessをどのように認 識しているかはわかりません。開発者の日常生活において、 test flakinessはどの程度入り込んでいるの か、どのような影響を与えているのか、そして最も重要なことは、開発者は、私たち研究者にこの問題に対 して何を望んでいるのか、ということです。これらの問いに答えるために、我々は、異なるドメインの 335人 のソフトウェア開発者とテスターを調査した。この調査の回答者は、 flaky testsが一般的かつ深刻な問題 であることを確認し、flaky test detectionに関する現在進行中の研究の正当性が確かめられた。開発者 は、テストの再実行による計算コストよりも、テスト結果への信頼の喪失を懸念している。そのため、開発 者は、IDE プラグインによるflaky codeの検出や、問題の可視化、特にテスト結果の経時変化を示すダッ シュボードの充実を希望している。これらの重要な側面は、ツール開発者だけでなく、研究者の注意を引く と思われる。
12. Automated Detection of TalkBack Interactive Accessibility Failures in Android Applications TalkBackは、全世界で3億400万人の視覚障がい者がAndroid端末にアクセスする際に 最も利用されているスクリーンリーダーの一つである。しかし、人気のあるAndroidアプリ ケーションの多くは、適切なTalkBackのアクセス機構を備えておらず、アプリを使用でき なくする障害を引き起こす可能性がある。既存のアクセシビリティ関連技術は、これらの 問題を検出する点で限界がある。本論文では、TalkBackユーザーがAndroidアプリの中 核機能と対話することを妨げるTalkBack対話型アクセシビリティ障害を自動的に検出す るための新しいアプローチを提示する。本手法を実世界のAndroidアプリで評価した結 果、高い精度と再現率でこれらのTalkBackアクセシビリティ障害を検出できることが示さ れた。
13. Automated Repair of Responsive Web Page Layouts Responsive Web Design（RWD）とは、画面サイズに応じてレイアウトを調整する Webページを開発するための 戦略である。最近のウェブアプリケーションは、モバイルデバイスの小さなディスプレイからデスクトップコン ピューターの大きなディスプレイまで正しく表示する必要があり、このようにスクリーンスペースが大きく異なる場 合、Responsive Layout Failures（RLF）、つまり特定のスクリーンサイズでのみ明らかになる視覚的な差異が、 本番のウェブページに簡単に入り込んでしまうことがある。例えば、レイアウトスペースが不足すると、 HTML要 素がページの端からはみ出したり、互いに干渉し合ったりすることがある。このような現象が発生すると、 Web ページの見た目が悪くなり、最悪の場合、機能しなくなる。本論文では、 RLFを修正する技術を提案し、これを Layout Drというツールに実装する。 Layout Drは、RLFを検出した後、ページのレスポンシブデザインから、障 害点に最も近いが RLFが発生していないレイアウトを取得する。そして、これらのレイアウトを障害の上に移植 できるように変換し、エンドユーザーから元の RLFを効果的に「隠蔽」する。我々は合計 55のRLFを含む19の被 験者に対して、Layout Drを評価した。その結果、 Layout DrはそれぞれのRLFに対して適切な修正方法を見出 すことができた。修復について人間による調査を行ったところ、 92%の被験者が、RLFを含む元のページと比較 して、修復されたバージョンのページを好むことがわかった。
14. Automating Differential Testing with Overapproximate Symbolic Execution ソフトウェアのアップデートをリリースする前に、開発者は通常リグレッションテストスイートを実行して、コードの変更が意図し たとおりに動作するか、意図しない動作をしないかを検証する。しかし、リグレッションテストスイートは不完全であることが多 く、関連するソフトウェアの振る舞いを見逃してしまうことがある。この問題を軽減するために、我々は、意図しない動作の変 化を検出する技術を紹介する。 2つのバージョンのソフトウェアが与えられたとき、本手法はまず、いずれかのバージョンで変 更されたコードに到達する関数を検出する。次に、特定された関数から始めて、元のプログラムと修正されたプログラムの両 方に対して、制約条件付きのsymbolic executionを実行する。実行の結果、変更されたコードに到達したとき、バージョン間 で対応するプログラムの状態を比較し、差分をログに記録する。このように生成された生のログには、多数の冗長なエントリ が含まれ、意図的な差分と非意図的な差分が混在する可能性があるため、本技術では、記録された差分をクラスタリング、 順序付け、ランク付けし、開発者が実現可能な非意図的差分を識別できるようにする。我々は、 (1)既知のリグレッションの大 規模なセットに適用し、(2)我々の結果を最新のアプローチと比較し、 (3)ポピュラーなプログラムである Redisのリファクタリン グバージョンのセットに適用し、我々の技術を評価した。全体として、我々の結果は有望であることがわかった。既知のリグ レッションに対して、我々の手法は半分以上のリグレッションを自動的に識別し、偽陽性の発生が少なく、ほとんどの場合、 偽陽性よりも真陽性を優先し、ベースラインとして使用した最先端の手法よりも多くのリグレッションを報告することができた。 リファクタリングされたRedisのバージョンでは、我々の技術はリグレッションをレポートしなかった。
15. Evaluating Features for Machine Learning Detection of Order- and Non-Order-Dependent Flaky Tests Flaky testsとは、コードを変更することなく合格または不合格となるテストケースのことである。これらは、開発者の時間を浪 費させ、継続的インテグレーションを阻害するなど、ソフトウェア開発における大きな問題の原因となる。 research communityではflaky testを自動修正する技術を提案しているが、その多くは、テストの繰り返し実行と重要な計測を伴うた め、侵入的であり、かつ高コストである可能性がある。このため、研究者は、抜けがあるテストを検出するための機械学習モ デルを評価しているが、テストケースを符号化するための特徴量に関する研究は限られている。このトピックに関する研究が さらに進まなければ，機械学習モデルはこの領域でその潜在能力を十分に発揮することができない．また、これまでの研究 では、特定の、しかし一般的で問題のある、 order-dependent (OD) flaky testsを除外している。このため、先行研究は、 flaky test検出問題のサブセットしか扱っていない。本論文では、テストケースを符号化するための新しい機能セットを提示す る。本論文では，テストケースを符号化するための新しい特徴量を提示し，データ前処理，データバランシング，機械学習の 54のパイプラインによるnon-order-dependent (NOD)およびOD型欠陥テストの検出性能の評価を行い，既存の特徴量と比 較した．データセットとして、26のPythonプロジェクトのテストスイート（ 67,000以上のテストケースから構成）を使用した。本論 文の実証研究により、(1) 我々の新機能セットを用いてNOD flakyテストを検出した場合、全体の F1スコアが13%増加するこ と、(2) 我々の新機能セットを用いてOD flakyテストを検出した場合、全体の F1スコアが17%増加すること、(3) 我々の新機 能セットが両種のflakyテストの検出に対して最も影響するメトリクスであることなどの多くの結果が明らかにされた。
16. GUI Test Transfer from Web to Android GUIテストは、GUIベースのソフトウェアのエンドツーエンドのワークフローとユーザビリティを検 証するために重要である。GUIテストを書く工数を減らすために、最近の研究では、類似のアプ リケーション間でGUIテストをtransferringすることによって自動的にGUIテストを再利用する可 能性が検討されています。しかし、先行研究に欠けているのは、異なるプラットフォームで利用 可能なアプリケーションに対して、transferringが必要になる場合があるということである。特に、 WebとAndroidは、多くの組織がソフトウェアサービスを提供する上で、主要なプラットフォームと なる。しかし、現状では、ある組織が提供するアプリのWeb版とAndroid版が実質的に機能を共 有していたとしても、開発者はそれぞれのバージョンに対して別々のテストセットを手作業で記述 しなければならない。本論文では、WebアプリのGUIテストをAndroidアプリに転送する自動化 ツール、TransDroidを提案する。実世界のウェブアプリとAndroidアプリでTransDroidを評価し たところ、転送の成功率は77％、GUIイベントとオラクルのマッピングでは82％の精度と99％の 再現率を達成し、その有効性が裏付けられた。
17. Harvesting Production GraphQL Queries to Detect Schema Faults GraphQL は、Web API を設計するための新しいパラダイムである。その人気は高まっているものの、 GraphQL APIの実装を検証する技術はほとんどない。私たちは、ユーザーが実運用中のアプリケーショ ンを操作している間に記録された GraphQLクエリに基づく新しいテストアプローチを提示する。私たちの主 な動機は、本番のクエリがアプリケーションの実際の使用状況をキャプチャし、開発者がテストしないかも しれない動作を認知することです。ログに記録された各クエリに対して、スキーマに対する GraphQL レス ポンスの有効性を保証するためのテストが生成される。私たちは、 AutoGraphQLというツールに私たちの アプローチを実装し、ドメインと技術スタックが多様な 2つの実世界のケーススタディでそれを評価しました ：SaleorというPythonで実装されたオープンソースの電子商取引アプリケーションと FrontappというPHP ベースの金融ウェブサイトの産業事例。 AutoGraphQLは、この2つのアプリケーションのテストケースを生 成することに成功しました。生成されたテストは、 Saleorスキーマの26.9%をカバーし、オリジナルのテスト スイートで実行されなかった APIの部分を含んでいます。また Frontappスキーマの48.7%をカバーし、本 番クエリのおかげで8つのスキーマ障害を検出することができました。
18. IFRIT: Focused Testing through Deep Reinforcement Learning ソフトウェアは、開発者が新機能を追加したり、変更を加えたりすることで、常に変化して いる。この変化は、ソフトウェアに対して書かれたテストスイートの効果に直接影響を与 える。テストケースが存在しない部分に変更が行われた場合はなおさらである。本論文 では、プログラムのあるポイントを繰り返しカバーし、そのポイントに影響する欠陥を発 見することを最終目的とした、高品質のテストスイートを開発する課題に取り組む。我々 のアプローチであるIFRITは、深層強化学習を使用して、目的のプログラムポイントへの 高い到達性を維持しながら多様な入力を生成する。IFRITは、到達可能性、多様性、故 障検出を向上させ、最先端ツールやベースラインツールよりも優れた結果を達成してい ます。
19. JavaScript Instrumentation for Search-Based Software Testing: A Study with RESTful APIs JavaScriptは最も人気のあるプログラミング言語の1つである。しかし、その動的な性質 から、自動テスト技術にはいくつかの課題がある。本論文では、Search-Based Software Testing techniquesを使用して、JavaScriptアプリケーションのホワイトボック ステストを可能にするアプローチとオープンソースツールのサポートを提案する。我々 は、一般的なBranch Distanceのようなsearch-based heuristicsを収集するための自動 化されたアプローチを提供する。また、テスト生成ツールEvoMasterに本手法を組み込 み、RESTful APIの自動システムテストに関する分析を実施し、その結果を実証的に評 価した。5つのNodeJS APIを対象とした実験では、コードカバレッジと障害検出の観点 から、我々の手法が既存のブラックボックスおよびグレーボックステストツールより大幅 に優れた結果を導くことが示された。
20. Learning Realistic Mutations: Bug Creation for Neural Bug Detectors Mutationsは、プログラムコードに対する小さな、しばしばトークン・レベルの変更で、通常、テストスイートの品質 を評価するための mutation testingで実行されます。また最近、 code mutationsは、バグのあるコードのベンチ マークを作成するために使用されるようになった。このようなバグベンチマークは、テストツール、デバッグツー ル、バグ修正ツールの評価のための貴重な補助となる。また、学習型（ニューラル）バグ検出器の学習データと しても利用できる。これらの応用の鍵は、ソフトウェア開発者が作成する欠陥に酷似した現実的なバグを作成す ることである。本論文では、 mutationに対する学習ベースのアプローチを提案する。本論文では、自然でより現 実的なバグをコードに注入するために、突然変異の文脈に関する知識を組み込んだ新しい文脈的 mutation演 算子を提案する。本アプローチでは、実行可能なトークン置き換えに対する文脈依存の分布を生成するため に、マスクされた言語モデルを採用する。このようにして、現実的な mutationを生成するための戦略が学習され る。Java、JavaScript、Pythonのプログラムを用いた実験的評価により、言語モデルからのサンプリングは、実 際のバグをより正確に表現する mutationを生成するだけでなく（テストで採用した mutationに比べて再現率が約 70%高い）、このようにして生成したバグベンチマークで訓練した場合、より優れた性能のバグ検出器につなが ることが示された。
21. Machine Learning Based Invariant Generation: A Framework and Reproducibility Study ソフトウェア検証は、指定された要件に対するプログラムの正しさを証明する作業である。ソフトウェア検証の鍵 は、loop invariantsの自動生成にある。近年、テンプレートやロジックに基づく不変量生成の手法に、機械学習 （ML）の手法が加わってきている。現在、このような手法の提案が多数存在する。しかし，ベンチマークが異なる ，ハイパーパラメータが異なる，公開されていない，前処理や実行環境が特殊であるなどの理由により，各提案 の比較可能性に問題がある． 本論文では、ML不変量生成器の実験と比較のためのモジュラーフレームワーク MIGMLを紹介する。MIGML は、ML不変量生成器の核となる要素（すなわち、教師および学習者）を、明確なインターフェースを持つインスタ ンス化可能なコンポーネントとして含んでいる。この概念的に新しいフレームワークは、既存の 4つのML不変量 生成器の再現性を研究することを可能にする。我々は、 4つの手法の教師と学習者のコンポーネントを我々のフ レームワーク内に再実装し、同等の根拠で比較することを可能にした。その結果、報告された結果を再現し、部 分的に確認することに成功した。さらに、データ生成器を A手法の教師器とB手法の学習器の両方に用いるな ど、新しい組み合わせの実験も行った結果、このような組み合わせが全体的な効果を高めることを確認した。
22. Metamorphic Fuzzing of C++ Libraries C++ライブラリを対象とした新しいオープンソースツールMF++として実装された、ソフトウェアライブラリの自動メタモーフィックファジングの方 法を紹介する。本手法を利用するために、ライブラリ開発者はまず、ライブラリに実行させることができる高レベルの操作をいくつか特定す る。そして、それぞれの操作について、(a)テスト対象ライブラリの機能、(b)他の高レベル操作、を組み合わせた複数の等価な実装を提供す る。つまり、ある高水準演算を他の高水準演算を呼び出す実装に拡張すると、その演算もランダムに拡張される。高位演算間の相互再帰に より、大規模かつ複雑な等価コールシーケンスを生成することができる。等価な呼び出し列は、ランダムな入力に対して自動的にクロスチェッ クを行い、等価な出力が得られることを確認することができる。高位演算の実装が正しいと仮定すれば、出力の不一致はテスト対象のライブ ラリのバグを示す。このアプローチは、オラクル問題を回避する。つまり、特定の操作シーケンスに対して期待される結果を知る必要はなく、 等価なシーケンスから得られる結果と等価であることだけを知ることができる。したがって、このアプローチはメタモーフィックテストの一例であ る。階層的デルタデバッグによるテストケース削減は、バグを誘発するのに十分な最小化された高レベル操作シーケンスの最小拡張ペアを 見つけるために適用され、デバッグに役立つテストケースとして機能することができる。また、テストケースの削減は、ライブラリ開発者が誤っ て高位演算の非等価な実装を提供してしまったケースを特定し、修正する際にも役立つ。MF++を4つのSMTソルバと2つのPresburger算術 ライブラリという6つのライブラリに対して評価した結果、15個のバグを発見することができた。また、MF++とそのテストケース削減機能を用 いて、テスト対象の様々なライブラリの回帰テスト・スイートでカバーされていないソースコードを実行する小さなテストケースを自動生成する ことに成功した。メタモーフィックなアプローチにより、合成されたテストは自動的に等価ベースオラクルを備えている。我々は、isl、Yices2、 Z3プロジェクトに新しいテストケースに貢献するパッチを提出しました。これらのプロジェクトの開発者はこれらの貢献を受け入れ、これまでに 私たちのパッチに基づく21のテストを受け入れた。
23. Patterns of Code-to-Test Co-evolution for Automated Test Suite Maintenance ソフトウェアシステムは継続的な変化を特徴とし、多くの場合、様々な種類の成果物間で同時に発生す る。先行研究では、個々の成果物の進化に焦点が当てられているが、本論文では、ソースコードとテスト コードの間の共進化のパターンを研究している。この研究では、文献を参照し、また、いくつかのオープン ソースソフトウェアシステムの手動分析を行い、まず、ソースコードとテストスイートの間の共進化の共通 パターンをパターン化し、文書化する。提案したパターンを活用し、ソースコードの変更に対応したテストス イートの必要な改善策をさらに推論する。このアプローチにより、システムの現行バージョンに不足してい るテストケースを追加すること（ augmentation）が可能になり、さらに、システムの修正バージョンに対して 既存のテストスイートを再利用し進化させること（ evolution）も可能になる。さらに、同時進行の進化のパ ターンを特定することで、ソースコードとテストケースの両方の成果物に対して、双方向の変更検出と修正 の機会を提供し、さらに、コードとテストのトレースリンクを維持するプロセスを自動化することができる。 5 つの大規模なオープンソースアプリケーションにおけるパターンと改善策の評価では、パターンがソース コードの変更の最大42%を含み、改善策が特定のケースで影響を受けたテストケースの最大 100%を回 復することが示さた。
24. POWER: Program Option-Aware Fuzzer for High Bug Detection Ability command-line interface(CLI)を持つほとんどのプログラムは、プログラムの動作を代替するた めに数十のコマンドラインオプション（例えば、lsのための-l、-F、-R）を持っている。そのため、 ファジング時に適用するオプション設定（-l -F や -F -R などのオプションのリスト）により、テスト カバレッジやクラッシュ検出結果が大きく異なることがある。本論文では、様々なプログラムオプ ション構成をアクティブに構築し、慎重に選択することで、最先端のファザーよりも多くのクラッ シュを検出する新しいファジング技術POWERを提案する。POWERの主要なアイデアは、他の オプション設定とは「異なる／遠い」オプション設定のセットを選択することで、ターゲットプログラ ムの多様な実行を強制することである。POWERのもう1つの中核的な考え方は、異なる入力領 域（すなわち、オプション設定と入力ファイル）に異なるファジング戦略を適用して、限られた時間 予算内でテストの有効性を高めることである。30の実世界プログラムを用いた実験の結果、 POWERは最先端のファジング技術よりも大幅に多くのクラッシュバグを検出することができた。
25. Providing Real-time Assistance for Repairing Runtime Exceptions using Stack Overflow Posts Runtime Exceptions（RE）は、コード開発中に頻繁に発生する重要なバグの 1つである。従来のAutomatic Program Repair （APR）ツールは、この「開発中」のユースケースでは、パッチ適用用のオラクルとしてテストスイートを利用する必要があるた め、利用が制限されている。そのため、開発者は通常、開発中の REを手動で解決する傾向があり、多くの場合、 Stack Overflow (SO)などの技術フォーラムを参照する。本論文では、この手動プロセスを自動化するために、リアルタイムで開発 者を支援する新しい技術REXを紹介する。この技術は、関連するパッチを提案する SOの投稿をサジェストし、この投稿から 開発者のコード内のREを修正するパッチを合成することによって Java REを修正するものである。REXは、SOポストから半 自動的に採掘されたREP（Runtime Exception Patterns）ライブラリを利用し、比較的安価な 1回限りの漸進的プロセスによ り、REXを実現する。REPは、あるREを引き起こす一連のステートメントを抽象化したものである。 REPは、SO投稿のイン デックスを作成し、開発者のコードが示す REインスタンスに最も関連する投稿を検索し、 SO投稿から具体的な修復を抽出 し、投稿固有の詳細を抽象化して、開発者のバギーコードに修復を具体化するプロセスを仲介するために使用される。 78個 のJavaインスタンスで構成される公開 REベンチマークでREXを評価した。その結果、REXは27%のケースで上位に、40%の ケースで上位3位以内に、81%のケースで有用な成果物を生成できることがわかった。さらに、 REPの使用は、SO投稿のラ ンキングや検索から、与えられた投稿からのパッチの合成まで、 REXの性能のあらゆる側面に役立っていることが証明され た。特に、REXが生成した正しいパッチの45%は、REXのSOポストランキングが提供された場合でも、 REPを使用しない ベースライン技術では生成することができなかった。また、 REXは高速であり、出力に要する時間は平均 1秒程度であった。 これらの結果から、REXはREを修復する際に、開発者をリアルタイムで効果的に支援できることがわかった。
26. Smoke Testing of Cloud Systems クラウドシステムの信頼性の高い自動テスト環境を構築することは、設定不良のサービスやインフラのスクリプ トの欠陥など、デプロイの安定性を損なう可能性のある多くの問題のために困難な場合がある。導入手順が正 しく終了しなかったことによるテストの失敗は、組織に多大な労力、リソース、時間を浪費させる可能性がある。 スモークテストは、スモークテストケースに合格した場合にのみ実行される他のテストスイートを実行する前に、 テスト対象のシステムが動作可能かどうかを確認するために迅速に実行できるテストスイートを設計するために 使用することができる。実際、スモークテストは、検査する価値のない偽のテスト失敗の発生を防止するのに役 立つ。 これまで、スモークテストスイートの設計は、テスト担当者の直感に委ねられており、その設計には、任意の、そ して潜在的に弱い基準が適用されることがあった。本論文では，クラウドアプリケーションのスモークテストを体 系的にアプローチすることで，この問題を解決する．特に，クラウドアプリケーションの効果的なスモークテストス イートの設計に役立つ，参照モデルと 9つの妥当性基準を紹介する． 2つの産業用システムの 60バージョンにつ いて、9つの適切な基準を満たすスモークテストスイートを評価することで、基準のコストと故障検出能力のト レードオフを証明する。
27. Symbolic Verification of Message Signatures in MPI MPI（Message Passing Interface）は、ハイパフォーマンス・コンピューティングにおけるプログ ラミングの標準的なパラダイムである。しかし、MPI標準の固有の複雑さと大きなサイズが、プロ グラマがMPI APIを正しく使用することを困難にしている。本論文では、メッセージシグネチャのミ スマッチエラーに焦点を当てる。MPIエラーは、特定の入力の下で、複雑で低確率のインター リーブ中に発生する可能性があることを考慮し、メッセージ署名の正しい一致を検証するために 記号的検証を採用する。具体的には、実行パスのメッセージシグネチャの一致を通信シーケン シャルプロセスでモデル化する精密な手法を提案する。また、スケーラビリティを向上させるた め、部分順序削減に基づく最適化を行い、パスレベルの通信モデルの複雑さを軽減する。本手 法をプロトタイプツールとして実装し、典型的な正しさベンチマークである MPI-Corbenchと8つの 実オープンソースMPIプログラム、合計37,000行のコードで評価した。実験結果は、本手法の有 効性とスケーラビリティを実証している。
28. TESRAC: A Framework for Test Suite Reduction Assessment at Scale 大規模なソフトウェアプロジェクトにおいて回帰テストは重要なタスクであるが、コードベースの増加に伴 い、テストスイートが増大し、冗長性の高いテストケースで構成されるようになり、テストに要する時間が大 幅に増加してしまう。この問題を解決するために、様々なテストスイート削減ツールが提案されているが、 最適な削減ツールを選択するための標準的な評価やアプローチがないため、その絶対的・相対的性能は 利用者には不明である。本研究では、テストスイート削減ツールを評価・比較するためのフレームワークで あるTESRACを提案する。このフレームワークでは、カスタマイズ可能なツール群を、基準（カバレッジ、 次元、実行時間）に従って削減性能の観点から評価・順位付けし、特定の基準を優先するよう設定するこ とが可能である。我々は、 TESRACを使用して、様々な次元と特性を持つ 11のプロジェクトにおいて、3つ のテストスイート削減ツールと、テストスイート削減を行うために適応された 1つのテストスイート優先順位 付けツールを評価・比較した。その結果、テストスイート優先順位付けツールは、適切なテストスイート削 減を行うために適応可能であり、ツールのサブセットは、大部分のプロジェクトで残りのツールより優れて いることが示された。しかし、プロジェクトとテストスイートは、ツールの性能に強い影響を与える可能性が ある。
29. Testing Software in Production Environments with Data from the Field ソフトウェアシステムは、本番環境において不具合が発生し、システムクラッシュや誤った出力、システム全体の不安定化な どを引き起こすことがある。徹底的なソフトウェアテストは本番環境での不具合発生を減らすことはできるが完全に回避する ことはできない。これは、現代のソフトウェアアプリケーションの複雑さにより、網羅的なサンプリングが不可能な無数の実行 条件が存在すること、また、開発時には予測・演習できない動作が本番環境では発生することの両方が理由である。 本論文では、本番環境でソフトウェアシステムをテストし、新しい実行シナリオを探索し、本番環境でのみ発生するエラー状 態を、システム障害に伝播する前に早期に検出するためのアプローチを紹介する。本論文では、未知の実行シナリオの存在 下でソフトウェア部品を実行するための実運用環境から得られるテストデータと、システムが故障する前にエラー状態を明ら かにするための一般的なアサーションを組み合わせた現場対応型テストケースを提案する。直感的には、本アプローチは本 番環境をテストベッドと見なし、本番環境でのみ利用可能となるオブジェクトをテストデータとして利用する単体テストケースを 日和見的に実行し、システム障害前にエラー状態を明らかにするものである。 本論文では、JFreeChartおよびApache Commons Langライブラリのオリジナルのテストスイートを保守的に適用して作成し た、フィールドレディのテストケースを用いた一連の実験結果を示す。その結果， JFreeChartとApache Commons Langのテ ストケースは，オリジナルのテストケースの 64%のフォルトを実行し，33%の失敗を発見した。
30. To Seed or Not to Seed? An Empirical Analysis of Usage of Seeds for Testing in Machine Learning Projects Machine Learning（ML）アルゴリズムは、本質的にランダムな性質を持っている。同じ入力で実行すると、異なる実行結果でわずかに異なる 結果を導くことがある。このようなランダム性は、ML アルゴリズムの実装のためのテストを書くことを困難にしている。このようなランダム性の 結果として，同じバージョンのコードに対して，テストが非決定論的に合格したり不合格になったりする，test flakinessが発生する。 開発者はしばしば、テスト対象のコードで使用する乱数生成器に種を設定することで、MLプロジェクトにおけるテストのばらつきを緩和するこ とを選択する。しかし、この方法は、「回避策」としての役割しか果たさない。この方法は、テストを修正する代わりに、テストをより脆弱にし、異 なる計算順序によってのみ引き起こされるかもしれないバグを開発者が見落とす原因となる可能性がある。 我々は、114の機械学習プロジェクトのコーパスを用いて、シードの使用とそのテストへの影響に関する最初の大規模な実証研究を行う。こ れらのプロジェクトにおいて、seedなしで失敗する461のテストを特定し、その性質と根本原因を研究する。また、アルゴリズムのハイパーパ ラメータの調整やアサーション境界の調整などの代替戦略を用いて、特定した42個のテストのサブセットのflakinessを最小化することを試 み、開発者に送信した。これまでのところ、19 個のテストについて、開発者は私たちの修正を受け入れている。 また，56 個のテストのサブセットを手動で解析し，テストオラクルの性質や，シード設定の経時的な変化など，さまざまな特性を調査する。最 後に、テストにおける種設定の文脈で、いくつかの重要な洞察と研究者と開発者の両方に対するその含意を提供する。