1. ソフトウェア品質の基礎知識
2011.10
Reiko Yamashita

2. 品質の定義いろいろ
（大辞林） 品物の質
（ISO・JISの定義）
明示または暗黙のニーズを満たす能力に関する、
ある“もの”の特性の全体
（PMBOK） 要求事項への適合と使用適合性。
プロジェクトでは、作成すると約束したものを作成し、
その成果物で顧客満足度を実現すべき
（QMS/ISO9001）
顧客満足を得るために仕事をきっちりやる仕組み

3. 「品質の良いソフトウェア」とは
昔：あたりまえ品質 今：魅力品質
品質＝障害がないこと 品質＝ユーザ満足度
バグの少なさだけでなく
機能、魅力、提供スピードなども含めた顧客満足度
品質の良いソフトを作るためには
・最初にきちんとした品質基準書を作る メンバー全員で
共有
・前向き品質を品質目標に組み入れる

4. ソフトウェアライフサイクルと品質の視点
（ISO 9126-1/JIS X 0129-1）
プロセス品質 設計／開発のやり方や手順
ソースコード、仕様書など
内部品質 ソフトの内部的な特徴
外部品質 ソフトが実行されるときの品質
テストデータによるテスト結果など
利用時の品質 利用者の必要性に合致するかどうか
テストだけで品質を確保するのではなく、
「品質を作りこむ」という考え方が大切。
プロセス、設計、開発、テストで何をすべきか考える。

5. ソフトウェア品質特性（外部品質、内部品質）
（ISO 9126-1/JIS X 0129-1）
機能性 ソフトウェア製品の能力
信頼性 故障間隔、障害からの回復、障害許容性
使用性 使い勝手、使いやすさ、操作性
効率性 スピード、資源の有効活用
保守性 修正のしやすさ
移植性 別の環境に容易に移行できるか

6. 利用時の品質特性
（ISO/IEC 9126-4）
有効性 正確かつ完全に目標を達成する能力
適切な資源（時間、労力、材料など）を
生産性
使う能力
安全性 人、事業、ソフトウェア、財産、環境への
害に対してリスクの水準を達成
満足性 利用者を満足させる能力

7. ソフトウェアの品質状態の把握
バグ曲線
• 発生数が十分小さくなった段階で
品質が良くなったと認識する
• 障害が最初から少なく、ピークを迎えない場合は、
テスト方法やテスターの技量不足も
障害の発生原因
• 単純ミスが多いうちはまだまだ品質が悪い
• 品質が向上するにつれて、複雑な要因の障害が中心
障害の重大度
• 大きな障害が発生している状態では
テスト完了できない

8. バグの抽出・対処
• バグゼロは理想だが、無限の時間を費やす
ことはできない。コストも品質のうち。
• テストケースは多様かつほどほどが良い。
• 限られたリソースの中で、バグを対処するか、
無視するか（トリアージ）
※トリアージ：時間的・資源的制約で任務や課題のすべてを実施・完了
できない時、一定の基準に従って着手の優先度を判断すること。
例：災害医療などで、疾病者を重症度と緊急性によって選び分ける

9. テスト手法の分類（SWEBOK）
静的テスト 人間による検査
レビュー、インスペクションなど
コンピュータによる検査
解析ツール
動的テスト ホワイトボックステスト（構造テスト）
ブラックボックステスト（機能テスト）
SWEBOK：Software Engineering Body of Knowledge

10. テスト手法
• ブラックボックステスト
同値分割
限界値（境界値）分析
デシジョンテーブル
ペアテスト（直交表）
• ホワイトボックステスト
命令網羅
分岐網羅
条件網羅

11. テストツール
静的テストツール
ソースコードの複雑度やクラス間の
• コード解析 結合度を計測
• メトリクス計測 テスト重点化部分の決定
動的テストツール
• カバレッジ計測
• テストケース作成支援 クラス・オブジェクトごとの実行時間や
• 負荷（性能）試験ツール メモリ使用量、実行順序などを監視。
性能上のボトルネックやメモリリークを
• プロファイルツール 発見するために利用
• テスト実行ツール
• バグ管理システム(BTS:Bug Tracking System)

12. 品質メトリクス測定
• 欠陥を「テスト」でとらえるだけでなく、
欠陥の兆候を事前にとらえる
• テスト範囲を狭めて効率と効果を高める
• 欠陥予防と欠陥計測に役立てる
• 欠陥密度の絶対値では品質を評価できない。
プロジェクト規模、アプリの複雑度、開発者スキ
ルなどに依存

13. ソフトウェアメトリクス
代表的な測定対象
• LOC（Line of Code） コード行数
• LCOM(Lack of Cohesion of Methods) メソッド凝集度
の欠落
• 複雑度
• 結合度：あるクラスが別のクラスに依存している度合い
・怪しいところを効率的にテスト
・よりシンプルに。リファクタリングの推奨

14. まとめ：品質向上を握るカギ
• 前向き品質の実現。
バグの少なさだけでなく、機能、魅力、提供ス
ピードなども含めた顧客満足度
• プロセス、設計、開発、テスト。
トータルで「品質を作りこむ」という考え方。
• 欠陥予防、欠陥計測の活用により
テスト効率を上げる

15. 参考：各種テストツール（Javaの例）
静的テストツール
◆メトリクス計測：ソースコードの複雑度（注2）やクラス間の結合度を計測す
るツール。計測値を基に、ソースコードの修正・テスト重点化部分の決定
などを行う
MetrixPlugin for Eclipse Eclipse Metrics
Jmetric Jdepend
◆コード解析
PMD FindBugs JCSC Checkstyle Jlint
Hammurapi

16. 参考：各種テストツール（Javaの例）
動的テストツール
◆カバレッジ計測
JCoverage(dj Unit) Clover Coverlipse EMMA JCover Jester
◆テストケース作成支援
JTestCase Struts TestCase EasyMock jMock dbMonster TestGen4J
◆負荷（性能）試験ツール
Eclipse TPTP JMeter OpenSTA JCrawler Dieseltest The Grinder
◆プロファイルツール：クラスやオブジェクトごとの実行時間やメモリ使用量、実行順序などを監
視するツール。性能上のボトルネックやメモリリークを発見するために利用できる
Eclipse TPTP NetBeans Profiler jconsole(Java5付属) FProfiler
◆テスト実行ツール
JUnit、Cactus、HttpUnit djUnit、Eclipse TPTP、Selenium jfcUnit、Abbot、Jamelon
その他
◆ BTSツール：バグ管理システム（Bug Tracking System）
Bugzilla scarab Trac

17. 参考文献
• 品質とは http://homepage3.nifty.com/kaku-chan/q_and_p/what_quality.html
• ThinkIT 品質管理 http://www.thinkit.co.jp/cert/project/1/5/2.htm
• ソフトウェア品質特性 http://sw-quality.com/swcharast.aspx
• いまさら聞けない 形式手法入門 http://monoist.atmarkit.co.jp/fembedded/special/fm/fm01.html
• 誰でも使える形式手法（1）
http://monoist.atmarkit.co.jp/fembedded/articles/formalmethod/01/formalmethod01a.html
• 初めてのソフトウェアメトリクス http://www.atmarkit.co.jp/farc/rensai/matrix01/matrix01.html
• 開発プロジェクトのライフサイクル全体でテストを考える http://gihyo.jp/news/interview/20090714
• 日産自動車におけるソフトウェア品質向上活動 http://www.jasst.jp/archives/jasst06e/pdf/B3-1.pdf
• Visual Studio 2005を活用した、テスト駆動開発とソフトウェア品質向上アプローチ
http://www.thinkit.co.jp/free/project/13/1/
• チーム開発ここまできた、個人からチームの生産性向上へ http://www.thinkit.co.jp/free/project/17/1/
• ソフトウェア品質改善のすすめ http://www.ashisuto.co.jp/service/consul/column/1184256_3224.html
• 基本設計におけるレビューの勘どころ http://itpro.nikkeibp.co.jp/article/COLUMN/20060809/245521/?ST=upper&P=2
• 根性論では改善しない組み込みソフトの品質 http://monoist.atmarkit.co.jp/fembedded/special/scm/scm_a.html