Presentation is loading. Please wait.

Presentation is loading. Please wait.

Test Confessions: A Study of Testing Practice for Plug-In Systems Michaela Greiler †, Arie van Deursen †, Margaret-Anne Storey ‡ † : Delft University of.

Similar presentations


Presentation on theme: "Test Confessions: A Study of Testing Practice for Plug-In Systems Michaela Greiler †, Arie van Deursen †, Margaret-Anne Storey ‡ † : Delft University of."— Presentation transcript:

1 Test Confessions: A Study of Testing Practice for Plug-In Systems Michaela Greiler †, Arie van Deursen †, Margaret-Anne Storey ‡ † : Delft University of Technology ‡ : University of Victoria 担当:山内寛己 株式会社アクセス

2 概要 プラグインベースシステムのテストは非常に複 雑であり,テストが難しい – 数多くのプラグインとの相互作用(競合の確認) – 異なるバージョン(プラグイン,プラットホーム), 設定など プラグインベースシステムにおけるテストにお いて,テストエンジニアおよび,開発者の意識 と行動の実態をより理解する

3 Research Question RQ1: プラグインベースシステムのテストにおいて,広 く行われているテストプラクティスは何か.そのプラク ティスは非プラグインシステムと異なるのか. RQ2: プラグインのアーキテクチャがプラグイン特有の テストアプローチにつながるのか.何がテストを困難に させるのか. RQ3: プラグインベースシステムのテストを困難にさせ る要因は何か. RQ4: プラグインのテストを支援する付加的な補償の戦 略があるのか.

4 調査対象とその採択理由 調査対象: – Eclipse プラグインとその開発コミュニティ 採択理由: – 洗練されたプラグイン機構を持ち,数々のプラグイ ンが広く使われている.また,個々の開発規模が大 きく,複雑で,業務用途にも耐えうる – 大きな開発コミュニティを持ち,専門的知識を持つ 開発者が多い. – Eclipse コミュニティ全体がテストについて前向きに 取り組んでおり,プラグイン開発環境 (PDE) が整って いる. – プラグイン開発プロジェクトの多くがオープンソー スで他の研究者と議論もしやすい.

5 本論文の研究アプローチ 1. サーベイ: 一般的なプラグイン開発に関する情報と Eclipse プラグ インに特化した情報の収集(開発フォーラムや文献な どから) 2. インタビュー: 25 人( 18 組織)の様々なドメインの Eclipse プラグイン エキスパート * に 1 ~ 2 時間の grounded theory (GT) に よるインタビューを実施 3. 会議で報告: 2. の結果,分析と見解を EclipseCon** で発表 4. アンケート: 3. の発表に対するフィードバックとアンケートに 151 人 のエキスパートから回答があった(そのうち, 60% ほ どが開発者). * 開発者 12 名,プロジェクトリーダ 11 名,テスタ 1 名,テストマネージャ 1 名 **http://www.eclipsecon.org/2011/sessions/?page=sessions&id=2207http://www.eclipsecon.org/2011/sessions/?page=sessions&id=2207

6 Research Question RQ1: プラグインベースシステムのテストにおいて,広 く行われているテストプラクティスは何か.そのプラク ティスは非プラグインシステムと異なるのか. – 非プラグインシステムとプラクティスは変わらない. – Eclipse コミュニティでは, unit testing が重要な役割を担っており, そのほとんど(およそ 70% )が自動化されている.一方で, system testing, integration testing, acceptance testing は unit testing ほど頻繁ではないが導入,自動化がされている. RQ2: プラグインのアーキテクチャがプラグイン特有の テストアプローチにつながるのか.何がテストを困難に させるのか. – プラグインの性質がテストアプローチに与える影響はあまりな い. – 拡張ポイントの使用やプラグインの組み合わせ,プラグインの バージョン,プラットホームのバージョンが特有のチャレンジ になる.

7 Research Question RQ3: プラグインベースシステムのテストを困難にさせ る要因は何か. – 主な障壁は,不明確な説明責任や当事者意識,容易にテストす るためのインフラの欠如,テスト容易性が担保できない,テス ト実施時間の長さである RQ4: プラグインのテストを支援する付加的な補償の戦 略があるのか. – ユーザや開発者をコミュニティに巻き込む.そのためには … オープンなコミュニケーションが可能な環境の整備 – 機能拡張のリクエストやバグレポートの報告 – テスト環境やリソースの提供, self-hosting など

8 Resources 文献 [11] の Technical Report: http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD -SERG-2011-010.pdf インタビューおよび,アンケートの質問内容や項目,そ の回答の統計などのデータが掲載さている. http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD -SERG-2011-010.pdf ICSE 2012 の発表スライド : http://www.slideshare.net/mgreiler/icse-2012-test- confessions-a-study-of-testing-practices-for-plugin-systems http://www.slideshare.net/mgreiler/icse-2012-test- confessions-a-study-of-testing-practices-for-plugin-systems

9 Asking and Answering Questions about Unfamiliar APIs: An Exploratory Study Ekwa Duala-Ekoko and Martin P. Robillard (McGill University) 担当:吉田 則裕 奈良先端大

10 本研究の概要 大量の API の使い方を学ばなければ,開発を行う ことができない時代になってきた. 本研究では,被験者に API を使ったプログラミン グを行なってもらうことで,以下を調査した. – 開発者が, API を使用する際に持つ疑問( question ) – その疑問に答えることが難しい理由 実験結果を踏まえ, API を用いた開発に必要と考 えられるツールについて述べる

11 被験者とタスク 被験者 – 著者らが所属する大学の学生20名 – 最低一年間の Java 言語を使った開発経験 – 対象の API に詳しくない タスク – タスク1: JFreeChart API を使って円グラフを描く – タスク2: JAXP を使って,与えられた XML スキーマに XML ファイルが合っているか検証する – 時間制限は, 35 分間 – Eclipse を使用 – API ドキュメントと Web を閲覧可

12 データ収集の方法 think-aloud プロトコル – タスクを解決する際に考えたことを言語化 スクリーンキャプチャの録画 実験後インタビュー

13 分析結果 被験者が API を使用する際に持つ疑問を,20種 類発見した. 更に,被験者が手戻りを起こすなど,解決の難 しかった疑問を5つ特定した(抜粋). – 型 X と Y の関係は何か? – Public コンストラクトを使わずオブジェクトを生成す る方法は? – メソッド呼び出しの結果,得られるものは何か?

14 考察 観察(抜粋) – 開発者が使用している型から直接アクセスできない が,関連する API を発見することが難しい – API の一部をクエリとして取り込むと,良いコード例 を探しやすい – メソッド実行と例外の関係の理解が難しい 実験結果から必要と考えられるツール – 開発者が使用している型から直接アクセスできない が,関連する API の情報を提供する – タスクに関連する型の発見する – API 間の関係を発見する

15 How Do Professional Developers Comprehend Software? Tobias Roehm*, Rebecca Tiarks**, Rainer Koschke**, Walid Maalej* *: TU München, **: University of Bremen 担当:戸田 航史 福岡工業大学

16 概要 プログラム理解については,これまで多くの研 究で様々な手法やツールが提案されてきた しかし現実の開発者のプログラム理解における 行動や,利用されている手法やツールについて はほとんど知られていない – 特に納期等の実プロジェクトでのプレッシャーがか かる中での行動についてはほとんど知られていない そこで,開発者のソフトウェア理解に関する業 務中の行動の観察し,現実のプログラム理解行 動の内容を明らかにする – 研究と実践のギャップを埋める

17 貢献 1. 実環境でのプログラム理解戦略について詳細に 記述した 2. プログラム理解についての行動仮説をまとめた – これは応用研究やツール開発の助けとなる 3. 実験の手順や内容について詳細に記述した – 本研究の実験デザインは同種の実験でも利用できる 開発者の振る舞いに関する研究での実験

18 実験環境 7 企業 28 人の開発者に対し,作業内容の観察とイ ンタビューをそれぞれ 45 分行った – 観察対象作業はソフトウェア理解に関する業務 日常の業務を勝手に観察しているというスタンス – ただし観察時には,ある程度以上( 45 分以上)の規模の ソフトウェアを理解の対象にしてもらった 観察とインタビューから,ソフトウェア理解で 行われる 20 の行動を特定し,そこから 23 の行動 仮説を立てた

19 状況 S2: problem-solution-test パターン ソースコードの修正を含むタスクに開発者は 3 ス テップで対処する 1. 問題点の特定 2. 解決策の適用 3. 適用結果のテスト ある開発者は UI の色に関するバグの解決のため ,デバッグと print 命令を実行し(ステップ 1 ), ソースコードについていくつかの修正を施し( ステップ 2 ),その後テストを行っていた(ステ ップ 3 ) – ちなみに時間内にはバグは取れなかったらしい

20 S5: クローン作成による理解の回避と工数削減 1. コード変更の結果が予測できないとき,開発者は 既存コードをコピーすることで,プログラムの理 解自体を避けようとする – ある開発者はオリジナルのソースコードをリファクタリン グする代わりにコードをそのままコピーしていた その開発者は「オリジナルのコードを改ざんするとど こに影響が出るか分からないし,その影響は調べるの は時間がかかりすぎる」と述べている 2. 開発者は必要な情報を見つけやすいように統一さ れた構造のドキュメントを好む – ある開発者は「ドキュメントはコピーして使い回した方が 統一性が取れる」と述べている 3. 開発者は通常,ソフトウェアを理解することより もタスクを完了することを優先する

21 I6 :現実の利用シナリオの有用性とその稀少性 1. 「エンドユーザがアプリケーションをどのよう に利用するか」はプログラム理解において有用 な情報源である – 「ユーザのニーズのうち,アプリケーションで実装さ れているものはプログラムを理解する上で必要な情報 である」とある開発者は述べている 2. 多くの場合, 1. の情報は存在しない – 「「アプリケーションをエンドユーザはどのように使 うのか」が不明である場合や,アプリケーションのド メインについての知識がほとんどないという状況は多 々ある」とある開発者は述べている

22 その他の行動 ドキュメント読むよりソースコード見た方が早 い ドキュメント読むよりも隣の部屋にいる同僚に 聞いた方が早い Eclipse の全文検索機能とか知らんし,という開 発者が居た プログラム理解を助ける特別なツール類を使っ ている開発者は一人もいなかった – 可視化,コンセプトロケーション,ソフトウェアメ トリクスツール等 – IDE とデバッガくらいしか使われない


Download ppt "Test Confessions: A Study of Testing Practice for Plug-In Systems Michaela Greiler †, Arie van Deursen †, Margaret-Anne Storey ‡ † : Delft University of."

Similar presentations


Ads by Google