狠狠撸

狠狠撸Share a Scribd company logo
Software Test Basic
目次
? ソフトウェテストとは
? 開発プロセス
? ホワイトボックステスト
? ブラックボックステスト
What is Software Test
ソフトウェアテストとは
? 「不具合」と「欠陥」の違い
? ソフトウェアテストの必要性
? ソフトウェア品質
? 求められる品質意識
「不具合」と「欠陥」
? 不具合
– 原因が特定される前の誤動作と思われる現象
? 欠陥
– 誤動作の原因がソフトウェアにあることが特定されたもの
「バグ」、「不具合」、「障害」と呼ばれることがある
ソフトウェアテストの必要性
? 欠陥の温床
– 身の回りでソフトウェアを利用したものが増えている
– ソフトウェアの欠陥による被害が大きくなっている
– 機能は多機能化しているのに工期は短縮されている
ソフトウェアテストの必要性
? そもそも…
– ソフトウェアは人が作るので完全なもの(欠陥のないもの)は
作成できない
ソフトウェアテストの必要性
? テストを効果的?効率的に行うことが重要
ソフトウェア品質
? ISO/IEC 9126-1 品質特性規格 (JIS X 0129-1)
– 機能性 (必要な機能が実装されているか)
– 信頼性 (機能が正しく動作し続けられるか)
– 使用性 (利用者に使いやすく魅力的であるか)
– 効率 (資源の使用量に対して適切な性能か)
– 保守性 (維持、変更がしやすいか)
– 移植性 (別環境に移植しやすいか)
求められる品質意識
? テスターは基本的な品質概念以外にも
「ユーザー満足度」に対する意識が必要
求められる品質意識 (検証と妥当性)
? Verification (検証)
– 設計書通りにソフトウェアが動作するかどうか
? Validation (妥当性)
– ユーザーの要求通りにソフトウェアが動作するかどうか
求められる品質意識 (ユーザー満足度)
? Validation (妥当性) をどう評価するか
? 狩野モデル
品質要素 充足 不充足
当たり前品質 当たり前 不満
一元的品質 満足 不満
魅力的品質 満足 仕方がない
Development Process
ウォーターフォール开発
サンプル開発(要望)
? スポーツジムで見かけるエアロバイクの開発例
エアロバイクユーザーに聞き取り調査したところ、運動に飽きやす
いという声が多かった。知らず知らずのうちにペースが落ちてしま
うから時間をかけている割に運動できていない。
新製品では運動している人を励ます機能を入れてほしい。具体的に
は、ゆっくり漕いでいるときにはバイクからゆっくりとしたテンポ
の曲が流れてきて、漕ぐスピードを上げたら自動的に速いテンポの
曲に切り替わる。
サンプル開発(要求定義)
? (要求1)飽きずに運動したい。
– (要求仕様1)音楽を聴きながら運動できる。
? (要求2)運動中のペースを維持したい。
– (要求仕様2)ペダルを漕ぐペースにあったテンポの音楽を聴
きながら運動できる。
サンプル開発(基本設計)
? 画面設計
サンプル開発(基本設計)
? 機能設計(音楽メニュー)
– 音楽再生の 再生/停止 を切り替えられる
– 音量を10段階で調整できる
– 音楽のテンポは スロー/アップ/自動 を切り替えられる
サンプル開発(詳細設計)
? 音楽再生を切り替えるモジュール
– 「再生」ボタンが押された場合
? 音楽再生を開始する
? 「停止」ボタンを有効にし、「再生」ボタンを無効にする
– 「停止」ボタンが押された場合
? 音楽再生を停止する
? 「再生」ボタンを有効にし、「停止」ボタンを無効にする
? 音量調整モジュール
???
? テンポ調整モジュール
???
サンプル开発(実装)
サンプル開発(単体テスト)
? 制御フローテスト
– 制御フローをベースにケース作成
No. 再生中 期待結果 判定
1 true 停止
2 false 再生
サンプル開発(結合テスト)
? 状態遷移テスト
– 状態遷移図をベースにケース作成
No. 遷移前 イベント 期待結果 判定
1 停止中 再生 アップ再生中
2 アップ再生中 停止 停止
3 スロー再生中 停止 停止
? ? ? ?
? ? ? ?
? ? ? ?
サンプル開発(システムテスト)
? 機能確認テスト
– 因子水準一覧から組み合わせテストを作成
再生 音量 テンポ
再生 10 スロー
停止 20 アップ
30 自動
…
100
No. 再生 音量 テンポ
1 再生 90 スロー
2 再生 20 アップ
3 停止 80 スロー
4 停止 90 自動
? ? ? ?
? ? ? ?
? ? ? ?
因子水準一覧 組み合わせテスト
テスト分类
? 内部構造に注目する/しない
– ホワイトボックステスト or ブラックボックステスト
? ソフトウェアを動作させる /させない
– 静的テスト or 動的テスト
? ソフトウェア開発工程
– 要件定義、設計、実装、
単体テスト、結合テスト、システムテスト
テスト分类
テスト概要
? インスペクション(公式レビュー)
公式記録を残す重要度が高い文書のレビュー
? テクニカルレビュー
専門技術を持つレビュアーによる技術的問題を確認
するレビュー
? 非公式レビュー
特に決まりのないレビュー
? ウォークスルー
データフローや業務をシミュレーションするレ
ビュー
? コードレビュー
ソースコードを目視確認するレビュー
テスト概要
? 機能確認テスト
1つのモジュールが詳細設計書通りに動作するか確
認するテスト
? 制御フローテスト
プログラムの論理構造に従って「命令」や「分岐」
が行われるか確認するテスト
? データフローテスト
データや変数が「定義」→「使用」→「消滅」の順に
実行されるか確認するテスト
(一般には静的解析ツールを使う)
テスト概要
? 状態遷移テスト
状態遷移図、状態遷移表に基づいて動作確認を行う
テスト
? 機能確認テスト
モジュール同士の連携や複数モジュールで実現され
る機能が設計通りに動作するか確認するテスト
テスト概要
? 確認テスト
– 回帰テスト
修正箇所に関連する箇所が正しく動作するか
– デグレードチェックテスト
修正箇所に関連しない箇所に影響がないか
– スモークテスト
テスト工程開始前に行う簡易的な動作確認
? 評価テスト
– セキュリティテスト
脆弱性がないか
– ユーザビリティテスト
操作性、学習性、理解性見やすさの確認
テスト概要
? 性能テスト
– 処理能力
スループットやレスポンスタイムなどの確認
– ロングラン
長時間稼働時の動作確認
– 大容量(ボリュームテスト)
容量の大きいデータ、大量のデータでの動作確認
– 記憶域(ストレージテスト)
リソース不足している状況での動作確認
– 負荷(ストレステスト)
高負荷(一定時間内に繰り返し大量処理)での動作
確認
テスト概要
? 環境テスト
– 構成テスト
ハードとソフトの組み合わせテスト
– 互換性テスト
外部のハードやソフトと正しく連携できるか確認
? 機能確認テスト
要求通りに動作するか
? アドホックテスト
テスト設計せず場当たり的(アドホック)に行う
テスト概要
? 受入テスト
要求を満たしているか公式に確認し受入判定?承認
を行うテスト
? 運用テスト
実際の動作環境で動作確認するテスト
? αテスト
試作品を開発者以外の人が操作して不具合がないか
確認するテスト
? βテスト
発売?リリース前の製品を開発者以外の一般ユー
ザーが操作して不具合がないか確認するテスト
White-Box Test
ホワイトボックステスト
? ソフトウェアの中身を意識して行うテスト
ホワイトボックステスト
? ソフトウェアの中身を意識して行うテスト
論理構造を確認する
ホワイトボックステスト
? ソフトウェアの中身を意識して行うテスト
論理構造を確認する
必要とされる計算結果を得るための処理の実行順序
ホワイトボックステスト
? ソフトウェアで必要とされる計算結果を得るための処理
の実行順序を確認するテスト
– 制御フローテスト
– データフローテスト
制御フローテスト
? モジュール構成要素(以下の要素)に着目したテスト
– 命令文
– 分岐経路
– 条件
制御フローテスト(実施手順)
1. フローチャートを描く
2. カバレッジ基準を決める
3. カバレッジ基準を満たす経路を抽出する
4. 抽出した経路を通るテストを実施
5. 結果確認
制御フローテスト(フローチャート)
制御フローテスト(カバレッジ基準)
? ステートメントカバレッジ
? デシジョンカバレッジ
? 复合条件カバレッジ
制御フローテスト(カバレッジ基準)
? ステートメントカバレッジ
– すべての命令文を1度は通る
制御フローテスト(カバレッジ基準)
? デシジョンカバレッジ
– すべての経路を最低1度は通る
制御フローテスト(カバレッジ基準)
? 复合条件カバレッジ
– 因子水準を考慮した組み合わせテスト
因子と水準の組み合わせパターン
を作成してテスト
制御フローテスト(カバレッジ基準の選定)
? 以下を考慮して選定
– テストに投入できる工数
– テスト対象モジュールの重要度
データフローテスト
? ソフトウェアの中で使われるデータや変数が
「定義」→「使用」→「消滅」
の順に正しく処理されているか確認するテスト
データフローテスト
? 手で確認する場合はデータフロー図を作成して確認する
UMLのデータフロー図とは少し違う…
データフローテスト
? 手で確認する場合はデータフロー図を作成して確認する
…が、一般的には静的解析ツールで分析する
Black-Box Test
ブラックボックステスト
? ソフトウェアの中身を意識せずに行うテスト
– 機能確認テスト
– 状態遷移テスト
– 確認テスト
– 評価テスト
– 負荷テスト
…など。
「テスト工程」と「テストフェーズ」
単体
テスト
計画 設計
ケース
作成
実施
結果報
告
結合
テスト
計画 設計
ケース
作成
実施
結果報
告
システム
テスト
計画 設計
ケース
作成
実施
結果報
告
テスト工程 テストフェーズ
テストフェーズ
フェーズ 概要
テスト計画 テスト工程の目的と範囲を明確化。
必要な設備、環境、人員、スケジュールなどを決める。
テスト設計 テスト工程で実施するテストの種類、対象機能、テスト
技法などを決める。
テストケース作成 テスト実施前提条件、期待結果、判定を記入するドキュ
メントを作成。
テスト実施 テストケースに従ってテスト実施。期待結果と異なるテ
ストケースがあれば不具合報告書を作成。
テスト結果報告 各種データ(実施項目数、消化率、実施工数など)や不
具合データをもとに評価する。
テストフェーズ
フェーズ 概要
テスト計画 テスト工程の目的と範囲を明確化。
必要な設備、環境、人員、スケジュールなどを決める。
テスト設計 テスト工程で実施するテストの種類、対象機能、テスト
技法などを決める。
テストケース作成 テスト実施前提条件、期待結果、判定を記入するドキュ
メントを作成。
テスト実施 テストケースに従ってテスト実施。期待結果と異なるテ
ストケースがあれば不具合報告書を作成。
テスト結果報告 各種データ(実施項目数、消化率、実施工数など)や不
具合データをもとに評価する。
テスト計画
? テスト目的の確認
? 機能一覧の作成
? テスト観点の抽出
テスト計画
? テスト目的の確認
? 機能一覧の作成
? テスト観点の抽出
該当テスト工程で何を確認するか
重点的に確認する品質特性は何か
テスト計画
? テスト目的の確認
? 機能一覧の作成
? テスト観点の抽出
テストの目的を品質特性に変換し、
品質特性に対応したテスト観点を抽出する
テスト計画
? テスト目的の確認
? 機能一覧の作成
? テスト観点の抽出
テストの目的を品質特性に変換し、
品質特性に対応したテスト観点を抽出する
ISO/IEC 9126-1 品質特性規格
(機能性、信頼性、使用性、効率性、保守性、移植性)
テスト設計
? テスト観点の機能への割り当て
? テスト技法の検討と適用
テスト設計
? テスト観点の機能への割り当て
? テスト技法の検討と適用
機能観点一覧表を作成
機能(正常系) 機能(組合せ) 非機能 ???
基本機能 画面遷移 ??? 同時動作 割込動作 ??? 処理速度 負荷 ??? ???
運動
制御 〇 〇 〇
???
音楽
再生 〇 〇 〇
音量 〇 〇 〇
テンポ 〇 〇 〇
???
??? ???
テスト観点(分類例)
機能
非機能
ユーザー
確認
異常系
正常系
組合せ
大分類 中分類
テスト観点(一覧例)
大分類 小分類 テスト観点
機能 正常系 基本機能 表示
遷移(状態、画面) ユーザーインターフェース
設定(保存、変更、反映) セキュリティ
異常系 異常値 記憶装置異常
エラー処理(検知、復旧) 異常環境(ネットワーク等)
異常データ 異常操作
組合せ 同時動作 構成
割込み動作 相互運用
排他処理
非機能 処理速度 連続動作
負荷 通信帯域不足
大容量 リソース不足
ユーザー 出力品質 業務シナリオ
導入、保守
確認 回帰 デグレード
Summary
まとめ
? テストの重要度は増している
? テストは
「内部構造確認の有無」と「行程(or動作有無)」
で分類できる
? テスト観点の洗い出しが重要
Software Test Basic

More Related Content

Software Test Basic