200 likes | 265 Views
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. 担当:山内寛己 株式会社アクセス. 概要. プラグインベースシステムのテストは非常に複雑であり,テストが難しい 数多くのプラグインとの相互作用(競合の確認)
E N D
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 担当:山内寛己株式会社アクセス
概要 • プラグインベースシステムのテストは非常に複雑であり,テストが難しい • 数多くのプラグインとの相互作用(競合の確認) • 異なるバージョン(プラグイン,プラットホーム),設定など • プラグインベースシステムにおけるテストにおいて,テストエンジニアおよび,開発者の意識と行動の実態をより理解する
ResearchQuestion RQ1: プラグインベースシステムのテストにおいて,広く行われているテストプラクティスは何か.そのプラクティスは非プラグインシステムと異なるのか. RQ2: プラグインのアーキテクチャがプラグイン特有のテストアプローチにつながるのか.何がテストを困難にさせるのか. RQ3: プラグインベースシステムのテストを困難にさせる要因は何か. RQ4: プラグインのテストを支援する付加的な補償の戦略があるのか.
調査対象とその採択理由 • 調査対象: • Eclipseプラグインとその開発コミュニティ • 採択理由: • 洗練されたプラグイン機構を持ち,数々のプラグインが広く使われている.また,個々の開発規模が大きく,複雑で,業務用途にも耐えうる • 大きな開発コミュニティを持ち,専門的知識を持つ開発者が多い. • Eclipseコミュニティ全体がテストについて前向きに取り組んでおり,プラグイン開発環境(PDE)が整っている. • プラグイン開発プロジェクトの多くがオープンソースで他の研究者と議論もしやすい.
本論文の研究アプローチ • サーベイ:一般的なプラグイン開発に関する情報とEclipseプラグインに特化した情報の収集(開発フォーラムや文献などから) • インタビュー:25人(18組織)の様々なドメインのEclipseプラグインエキスパート*に1~2時間のgrounded theory (GT)によるインタビューを実施 • 会議で報告:2.の結果,分析と見解をEclipseCon**で発表 • アンケート:3.の発表に対するフィードバックとアンケートに151人のエキスパートから回答があった(そのうち,60%ほどが開発者). * 開発者12名,プロジェクトリーダ11名,テスタ1名,テストマネージャ1名 **http://www.eclipsecon.org/2011/sessions/?page=sessions&id=2207
ResearchQuestion • RQ1: プラグインベースシステムのテストにおいて,広く行われているテストプラクティスは何か.そのプラクティスは非プラグインシステムと異なるのか. • 非プラグインシステムとプラクティスは変わらない. • Eclipseコミュニティでは,unit testingが重要な役割を担っており,そのほとんど(およそ70%)が自動化されている.一方で,system testing, integration testing, acceptance testing は unit testing ほど頻繁ではないが導入,自動化がされている. • RQ2: プラグインのアーキテクチャがプラグイン特有のテストアプローチにつながるのか.何がテストを困難にさせるのか. • プラグインの性質がテストアプローチに与える影響はあまりない. • 拡張ポイントの使用やプラグインの組み合わせ,プラグインのバージョン,プラットホームのバージョンが特有のチャレンジになる.
ResearchQuestion • RQ3: プラグインベースシステムのテストを困難にさせる要因は何か. • 主な障壁は,不明確な説明責任や当事者意識,容易にテストするためのインフラの欠如,テスト容易性が担保できない,テスト実施時間の長さである • RQ4: プラグインのテストを支援する付加的な補償の戦略があるのか. • ユーザや開発者をコミュニティに巻き込む.そのためには… • オープンなコミュニケーションが可能な環境の整備 • 機能拡張のリクエストやバグレポートの報告 • テスト環境やリソースの提供,self-hostingなど
Resources • 文献[11]のTechnical Report: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
Asking and Answering Questions about Unfamiliar APIs:An Exploratory Study Ekwa Duala-Ekoko and Martin P. Robillard (McGill University) 担当:吉田 則裕奈良先端大
本研究の概要 • 大量のAPIの使い方を学ばなければ,開発を行うことができない時代になってきた. • 本研究では,被験者にAPIを使ったプログラミングを行なってもらうことで,以下を調査した. • 開発者が,APIを使用する際に持つ疑問(question) • その疑問に答えることが難しい理由 • 実験結果を踏まえ,APIを用いた開発に必要と考えられるツールについて述べる
被験者とタスク • 被験者 • 著者らが所属する大学の学生20名 • 最低一年間のJava言語を使った開発経験 • 対象のAPIに詳しくない • タスク • タスク1:JFreeChart APIを使って円グラフを描く • タスク2:JAXPを使って,与えられたXMLスキーマにXMLファイルが合っているか検証する • 時間制限は,35分間 • Eclipseを使用 • APIドキュメントとWebを閲覧可
データ収集の方法 • think-aloudプロトコル • タスクを解決する際に考えたことを言語化 • スクリーンキャプチャの録画 • 実験後インタビュー
分析結果 • 被験者がAPIを使用する際に持つ疑問を,20種類発見した. • 更に,被験者が手戻りを起こすなど,解決の難しかった疑問を5つ特定した(抜粋). • 型XとYの関係は何か? • Publicコンストラクトを使わずオブジェクトを生成する方法は? • メソッド呼び出しの結果,得られるものは何か?
考察 • 観察(抜粋) • 開発者が使用している型から直接アクセスできないが,関連するAPIを発見することが難しい • APIの一部をクエリとして取り込むと,良いコード例を探しやすい • メソッド実行と例外の関係の理解が難しい • 実験結果から必要と考えられるツール • 開発者が使用している型から直接アクセスできないが,関連するAPIの情報を提供する • タスクに関連する型の発見する • API間の関係を発見する
How Do Professional Developers Comprehend Software? Tobias Roehm*, Rebecca Tiarks**, Rainer Koschke**, WalidMaalej**: TU München,**: University of Bremen 担当:戸田 航史福岡工業大学
概要 • プログラム理解については,これまで多くの研究で様々な手法やツールが提案されてきた • しかし現実の開発者のプログラム理解における行動や,利用されている手法やツールについてはほとんど知られていない • 特に納期等の実プロジェクトでのプレッシャーがかかる中での行動についてはほとんど知られていない • そこで,開発者のソフトウェア理解に関する業務中の行動の観察し,現実のプログラム理解行動の内容を明らかにする • 研究と実践のギャップを埋める
貢献 • 実環境でのプログラム理解戦略について詳細に記述した • プログラム理解についての行動仮説をまとめた • これは応用研究やツール開発の助けとなる • 実験の手順や内容について詳細に記述した • 本研究の実験デザインは同種の実験でも利用できる • 開発者の振る舞いに関する研究での実験
実験環境 • 7企業28人の開発者に対し,作業内容の観察とインタビューをそれぞれ45分行った • 観察対象作業はソフトウェア理解に関する業務 • 日常の業務を勝手に観察しているというスタンス • ただし観察時には,ある程度以上(45分以上)の規模のソフトウェアを理解の対象にしてもらった • 観察とインタビューから,ソフトウェア理解で行われる20の行動を特定し,そこから23の行動仮説を立てた
S5:クローン作成による理解の回避と工数削減 • コード変更の結果が予測できないとき,開発者は既存コードをコピーすることで,プログラムの理解自体を避けようとする • ある開発者はオリジナルのソースコードをリファクタリングする代わりにコードをそのままコピーしていた • その開発者は「オリジナルのコードを改ざんするとどこに影響が出るか分からないし,その影響は調べるのは時間がかかりすぎる」と述べている • 開発者は必要な情報を見つけやすいように統一された構造のドキュメントを好む • ある開発者は「ドキュメントはコピーして使い回した方が統一性が取れる」と述べている • 開発者は通常,ソフトウェアを理解することよりもタスクを完了することを優先する
I6:現実の利用シナリオの有用性とその稀少性I6:現実の利用シナリオの有用性とその稀少性 • 「エンドユーザがアプリケーションをどのように利用するか」はプログラム理解において有用な情報源である • 「ユーザのニーズのうち,アプリケーションで実装されているものはプログラムを理解する上で必要な情報である」とある開発者は述べている • 多くの場合,1.の情報は存在しない • 「「アプリケーションをエンドユーザはどのように使うのか」が不明である場合や,アプリケーションのドメインについての知識がほとんどないという状況は多々ある」とある開発者は述べている