開発技術(3)

品質管理

テスト

製品としてのソフトウェアの品質を評価する重要な工程。仕様通りに動くこと、仕様にない動作をしないことを確認する

テスト結果の評価

テストの終了はテスト項目の進捗とエラー(バグ)の検出数により判定する

網羅率(テストカバー率、カバレッジ)

テストを網羅した比率のこと。この比率が100％になるとテストが完了したと判断する

バグ管理図

テスト時間と検出されたバグ(エラー)の累積数の関係をグラフにしたもの。理想的なバグ管理図は、「ゴンベルツ曲線」(信頼度成長曲線)と呼ばれる形の曲線になる

ブラックボックステスト

入力データと出力データの結果だけに着目し、それが仕様書どおりに正しく処理されているかを調べるテストのこと。プログラムの内部的な仕組みは問題視せずに、あくまでも入力データの処理結果のみを確認する

同値分割

入力するデータを「有効同値クラス」と「無効同値クラス」にクラス分けし、それぞれのクラスを代表する値をテストデータとして採用する方法
特徴としては、テストデータを作成しやすいこと

有効同値クラス	入力データとして正常に処理される値の範囲
無効同値クラス	入力データとしてエラーとなるような値の範囲

限界値分析

同値分割のクラスの境界にあたる値を、テストデータとして採用する方法。境界の条件が複雑な場合には、テストデータの漏れが発生しやすいため注意が必要。条件を整理するときに決定表などが使われる

原因－結果グラフ

入力値に対する出力値を有向グラフ化し、テストケースを設計する方法

ホワイトボックステスト

システムの内部構造を理解し、各モジュールが意図した通りに動作するかを確認するプログラムテストの方法。アルゴリズムに着目し、コンポ―ネントの内部構造や論理をチェックする方法

命令網羅	すべての命令を一度は実行する
判定条件網羅	すべての分岐(判定の真偽)を一度は実行する
条件網羅	複合条件の各条件の真偽を一度は実行する
判定条件／条件網羅	条件網羅と判定条件網羅を同時に行う
複数条件網羅	複合条件の真偽すべての組合せを実行する

アサーションチェック

変数間で論理的に成立すべき条件をプログラムの適切な個所に入れ、実行時にその条件を満たしているかを検査する手法

スナップショットダンプ

プログラム中のある命令を実行したときに、主記憶装置の内容を書き出して、内容を確認すること。デバック手法の一つ

結合テスト

モジュール単位で作成したプログラム同士を結合するときのテスト手法

トップダウンテスト

上位のモジュールから順番にテストしていく方法。すべての下位のモジュールが完成していないことが多いため、上位のモジュールに呼び出される仮のモジュール「スタブ」を用意する
※stab：「試み」という意味
スタブ：テスト対象モジュールから呼出され、上位モジュールに適切な値を返す

ボトムアップテスト

下位のモジュールから順番にテストしていく方法。上位のモジュールが完成していない場合は、下位のモジュールを呼び出す仮のモジュール「ドライバ」を用意する
ドライバ：テスト対象モジュールを呼び出し、引数を渡す

ビッグバンテスト

すべてのモジュールの結合を同時に行うテスト。各モジュールのテストが終わった後に全モジュールの結合の一斉テストを行う方法

レグレッションテスト(退行テスト)

システムの修正・新機能の追加をしたときに、他の部分に影響が及んでいないかを確認するテスト

(デザイン)ビュー

システム開発の各工程の品質を確保するために、作成者以外のの第三者が成果物を検査・評価すること。早期に誤りを発見し、品質向上を図ることを目的としている。要求分析、システム基本計画、外部設計、内部設計、プログラミングといった各工程の成果物を対象に、レビューを行う

ウォークスルー

開発者が中心となって実施するレビュー。エラーの早期発見だけが目的で、その後修正作業についてはテーマとしない

インスペクション

モデレータと呼ばれる管理者を中心に実施するレビュー。エラーの早期発見とその解決策の検討が目的。修正結果まで追跡確認する

レビューの種類	進行役	目的	資料の事前配布	修正検討と確認
ウォークスルー	開発者	エラーの早期発見	あり	なし
インスペクション	モデレータ	エラーの早期発見	あり	あり

ラウンドロビン

参加者全員が持ち回りで、レビュー責任者を務めるレビュー

ソフトウェア開発の成熟度モデル

ソフトウェアの品質を向上させるために、製品を生み出すプロセスを評価する
成熟度：開発プロセスが、どの程度のレベルで定着しているか

成熟度モデル(CMMI)
レベル	段階	内容
成熟度レベル1	初期	プロジェクトの遂行は個人に依存、組織的な管理なし
成熟度レベル2	反復可能	プロジェクトの計画・管理手段が存在、プロセスを反復可能
成熟度レベル3	定義されている	開発プロセスの標準化がされ、標準プロセスの改善を行う
成熟度レベル4	管理されている	開発プロセスを定量的に管理し、変更にも即座に対応可能
成熟度レベル5	最適化	開発プロセスを自発的に改善可能

システム結合テスト

システム全体が要求したとおりに作られているかどうかをテストする

名称	説明
機能テスト	必要な機能がすべて含まれているかを検証する
性能テスト	応答時間やターンアラウンドタイム、スループットなどの処理性能が要求を満たしているかを検証する
負荷テスト	大量のデータの投入や長時間の稼働に耐えられる処理性能を持っているかを検証する。性能テストも同時に実施
操作性テスト	操作性や表示されるメッセージの適切さをテスト
例外処理テスト (異常時テスト)	わざと間違えたデータを入力し、その異常部分が正しく処理されるかどうかなど、エラーの処理や例外処理が正しく行われるかテストする
レグレッションテスト (退行テスト)	システムの修正・新機能の追加をしたときに、他の部分に影響が及んでいないかどうかをテストする
ペネトレーションテスト (侵入テスト)	外部からの攻撃や侵入を実際に行ってみて、システムのセキュリティホールやファイアウォールの弱点を検出する

ヒューマンインタフェース

ユーザビリティ

利用者の感じる使いやすさ、操作のわかりやすさを整え、使いやすいヒューマンインタフェースを設計するための指標
ISO9241-11

ヒューリスティック

一般的に専門家が、さまざまなユーザインタフェース設計によく当てはまる経験則を基にして、インタフェースを評価する方法

ニールセンのユーザビリティ10原則

システム状態の視認性を高める
　　　：今どういう状態にあるかを常にユーザに知らせているか
実環境に合ったシステムを構築する
　　　：ユーザになじみのある言葉、習慣で情報を提示しているか
ユーザーにコントロールの主導権と自由度を与える
　　　：常にユーザが動作をこのトロールできる状態にあるか
一貫性と標準化を保持する
　　　：操作性や用いられる用語は一貫しているか
エラーの発生を事前に防止する
　　　：エラーの発生そのものを防止できるような工夫がなされているか
記憶しなくても、見ればわかるようなデザインを行う
　　　：操作法や情報を覚えなくても、見ればわかるようになっているか
柔軟性と効率性を持たせる
　　　：上級者向けにはショートカット機能やカスタマイズ機能が用意されているか
最小限で美しいデザインを施す
　　　：情報を詰め込み過ぎていないか
ユーザーによるエラー認識、診断、回復をサポートする
　　　：エラーメッセージはわかりやすい表現で解決策が提示されているか
ヘルプとマニュアルを用意する
　　　：分かりやすく簡素なヘルプやマニュアルが用意されているか