NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'14 Shikoku

高木実行委員長挨拶

JaSST Shikoku は、今回で7回目の開催となる。JaSST Shikoku の特徴・方針は、産学が融合できるコンテンツの提供で、毎回講演とワークショップの2部構成で開催している。今回初の試みで、遠隔中継で工学部の学生に講義の一つとしても提供する（工学部の聴講生約70名とのこと）。

ワークショップ
「Selenium IDEを使った記録再生体験ワークショップ」
伊藤 望 氏（TRIDENT）
東 大輔（日本ノーベル）

冒頭の15分を使って、テスト自動化概論として、テスト自動化がカバーできる範囲をプロセス図を用いてそれぞれのツールタイプがどこで使われるかをマッピングして説明し、最後に TestAutomater を目指してもらうよう技術者の特徴などを概説した。
続いて伊藤氏のワークショップを開始した。
Selenium の概要説明から始め、HTMLのタグ構造を振り返り、簡単な操作で初めて Selenium を操作する聴講者でも達成できるレベルのスクリプト作成から始まった。
1時間ほどで Selenium の概要が掴めたところで休憩を入れ、続いて実践的な課題にチャレンジした。実践課題の Web サイトの仕様変更した場合のスクリプトの対応が、難易度が少し高く、テスト自動化の難しさを垣間見ることができたと思われる。
聴講者の1/3が実践課題を完了したところで、最後に Selenium IDE の問題点について説明し、Selenium 開発者が薦めている WebDriver の紹介をした。
最後に継続的インテグレーションを説明し、Jenkins と連携して運用する方法をお薦めして締めくくった。

講演
「ソフトウェアメトリクスについて知っておきたいこと」
阿萬 裕久氏 (愛媛大学)

阿萬先生は、メトリクスが専門。講演内容は以下の3点だった。

１．ソフトウェアメトリクスとは

• 例1. コード行数（LOC）
  • 伝統的かつ有効
• 例2. サイクロマティック数
  • 条件分岐の数＋１で算出可能
  • プログラムの制御フローの複雑さを定量化
  • 1976年の第2回ICSEですでに発表されている
  • 7～10を超えるような関数は要注意
• 例3. 過去のバグ修正回数
  • リポジトリに記録されているソースコードの変更の中で、バグ修正に関するものの回数
    Google Bugspotsなどがその例。
• 測定の対象
  • プロダクト（ソースコード、設計書）
  • プロセス（修正履歴、レビュー活動）
  • リソース（開発者、プロジェクト）
• メトリクスの利点
  • 明確で伝えやすい
  • 分析しやすい

注意点としては、数字のひとり歩きや、数値だけを見て判断するようになることは避けること。現場のコンセンサスを得ること。数値化する式を例示し、その評価結果の数値に意味があるのかを問いかける。順序尺度や間隔尺度などの尺度水準例を挙げ、数値として計算して意味がない例を紹介し、統計的に意味があるのは比率尺度のみである。
測定法・測定条件にも注意が必要。コードの行数を数えるのに、コメントや空白行も含めるのかなど。数値化は大事だが、定義が曖昧だと、次のプロジェクトに参考にならないものになってしまう。

２．代表的なメトリクスと関連する技術・理論

バグの存在が疑わしいモジュールを絞り込む

• McCabeのサイクロマティック数
  制御フローの複雑さを定量化し、7～10あたりをこえると単体テストも大変になり、バグの見落としが起こりやすい。言語に依存していないため、現在でも有効。
• Halsteadのソフトウェアサイエンス理論
  プログラムの持つ情報量や理解・保守の難度を定量化する理論で、最近10年くらいは学術論文でみかけなくなった。問題点は、言語に依存してしまうこと。
• Chidamber & Kemerer（CK）メトリクス
  オブジェクト指向ソフトウェアのためのメトリクスで、6つのメトリクスからなるセットである。
  • WWC＝重み付きメソッド数
  • DIT＝継承木の深さ
  • NOC＝サブクラスの数
  • CBO＝結合関係にあるクラス数
  • RFC＝メッセージ応答で呼び出されるメソッド数
  • LCOM＝クラス内での凝集度の欠如
  6つのメトリクスで定量化し、バグが存在しているかどうかを予測する。ロジスティック回帰モデルを使用している。LCOMは有効ではなかったと報告されている。
• Lorenz & Kidd メトリクス
  オブジェクト指向でのソフトウェア開発についての多くのシンプルなメトリクス。開発者1人あたりの担当クラス数やオーバーライドされたメソッドの数などを測定する。
• ソフトウェア信頼度成長モデル
  累積障害件数の推移を数理モデル化し、収束の時期などを評価予測する。遅延S字形モデル、習熟S字形モデルなど。注意点は、数値化、モデル化した数字に振り回されないこと。
• 工数見積もり
  プロジェクトの特性や上流工程で得られたメトリクス値をもとに全工数を見積もる。古くはCOCOMO、COCOMO-Ⅱ。
• メトリクスそのものの性質を研究
  数学的に証明する講演者の研究がある。

３．エンピリカルアプローチの活発化

メトリクスの提案は2000年代前半までで、どのように使えるかを実データで分析・議論になっていく。

1. 実証データ収集
2. 実証データを分析・モデル化
3. 実証

OSS(Open Source Software)が市民権を得るようになり、実リポジトリで研究されるようになった。測定するツールもOSSで出てきている。

まとめとして、メトリクスは数値化の道具だが、評価システムではないので安易な計算は避けるべき。OSSの普及により、データ指向の研究が盛んになっているとして講演を締めくくった。

さいごに

前半のワークショップではテスト自動化を体験するワークショップで、参加者は基礎的なWebアプリケーションの自動化を体験できた。実際に手を動かして、テストツールとWebブラウザの動作・仕組みを理解できたと思う。技術サポートがついていたので、とまどう聴講者はおらず、全員ゴールを達成できていた。現場でトライしてみる人が増えることを期待する。
後半の講演では、授業の一環も兼ねており、ソフトウェアメトリクスの歴史を学べたと同時に、陥ってはいけない注意点を聞くことができたと思う。学生達は、将来の実現場に生かしてもらえることを期待しつつ、会場を後にした。