2.3 テストタイプ
2.3.1 機能テスト
システムが「何を」すべきかテストする
機能カバレッジを用いて計測できる
- テストした機能の範囲におけるカバーした要素の種類の割合
必要となる知識・スキル
- ソフトウェアが解決する特定のビジネス問題
- ソフトウェアが果たす役割
2.3.2 非機能テスト
システムが「どのように上手く」振る舞うかテストする
非機能カバレッジを用いて計算できる
- テストした非機能要素の種類の範囲におけるカバーした要素の種類の割合
非機能要素の種類については ISO/IEC25010 に詳しい
必要となる知識・スキル
-
設計や技術に特有な条件
- 例: Cのprintfの脆弱性
-
特定のユーザーの知識
- 例: 電子カルテの認可・セキュリティ
セキュリティの分類について
- 昔は機能性 > 機能適合性 の副特性だったため機能テストだった
- さいきん品質特性の一つに格上げされて非機能テストに分類された
2.3.3 ホワイトボックステスト(構造テスト)
システムの内部構造や実装に基づいたテスト
内部構造とは？
- コード
- アーキテクチャ
- ワークフロー
- システム内のデータフロー
テストベース
- 制御フローグラフ
- コールフローダイアグラム
-
画面遷移図
- 【補】つまり、システムテストでも実施可能
- コンポーネントやシステム間のインタフェースがわかるアーキテクチャー図
テストレベルがコンポーネントテストの場合は例えばコードカバレッジで計測できる
必要となる知識・スキル
- コードのビルド方法
- データの格納方法
- カバレッジツールの使用方法・計測結果を正しく解釈する方法
2.3.4 変更部分のテスト
システムが本質的に進化するものである場合必須
-
コードへの頻繁な変更が生じる(イテレーティブ/インクリメンタル開発)
- 新機能追加
- 既存機能の変更
- リファクタリング
確認テスト
デバッグ(開発活動)の後に行う
欠陥修正後、この欠陥に起因する故障が再現しなくなることを確認するためのテスト
リグレッションテスト
欠陥の修正により生じた意図しない副作用を検出するためのテスト
-
欠陥修正箇所だけテストすればよい、とはいかない
- 修正箇所とはまったく別の場所で故障が現れることも
-
実行範囲はプロダクトリスクに基づいて決める
- 【補】リスクベースドテストというやつ
2.3.5 テストタイプとテストレベル
| テストタイプ | テストレベル | 例 |
|---|---|---|
| 機能テスト | コンポーネントテスト | 複利計算をどう行うか |
| 機能テスト | コンポーネント統合テスト | UIで取得した口座情報をどうビジネスロジックに取り込むか |
| 機能テスト | システムテスト | 口座保有者が当座預金口座にクレジット限度額をどう適用するか |
| 機能テスト | システム統合テスト | 外部MSを使用して口座保有者のクレジット利用状況をどう確認するか |
| 機能テスト | 受け入れテスト | 銀行のクレジット取引承認での判定方法 |
| 非機能テスト | コンポーネントテスト | 性能テスト: 複雑な利息総額計算に必要なCPUサイクル数 |
| 非機能テスト | コンポーネント統合テスト | セキュリティテスト: UIからビジネスロジックに情報を渡す際のバッファオーバーフロー脆弱性 |
| 非機能テスト | システムテスト | 移植テスト: すべてのブラウザやモバイルデバイスで正しく動作するか |
| 非機能テスト | システム統合テスト | 信頼性テスト: MSの応答がない場合の堅牢性を評価する |
| 非機能テスト | 受け入れテスト | 使用性テスト: アクセシビリティを評価する |
| ホワイトボックステスト | コンポーネントテスト | ステートメントカバレッジ/デシジョンカバレッジ |
| ホワイトボックステスト | コンポーネント統合テスト | 各画面で次の画面やビジネスロジックに所定の方法でデータを渡していること |
| ホワイトボックステスト | システムテスト | Webページの遷移順序のカバレッジ |
| ホワイトボックステスト | システム統合テスト | MSへ送信可能なすべての検索条件 |
| ホワイトボックステスト | 受け入れテスト | 銀行感資金移動用のすべてのサポート対象金融データファイル形式と値の範囲 |
| 変更部分のテスト | コンポーネントテスト | CI |
| 変更部分のテスト | コンポーネント統合テスト | コードをチェックインする際にインタフェース関連のテスト再実行 |
| 変更部分のテスト | システムテスト | ワークフロー上のいずれかの画面を変更したらそのワークフローの前テスト再実行 |
| 変更部分のテスト | システム統合テスト | MS連携部のテストを毎日 |
| 変更部分のテスト | 受け入れテスト | 受け入れテストで検出した欠陥を修正した後にテスト再実行 |
-
すべてのテストタイプはすべてのテストレベルで実行できる
- する必要があるとは言ってない
-
同一のテストタイプが複数のテストタイプで必要となる場合、最も早期のテストレベルで行うのが肝要
- 性能テストはコンポーネントテストから！！
2.4 メンテナンス(保守)テスト
メンテナンスには計画的/非計画的(hotfix)があり、両方についてメンテナンステストを行うべき
- 変更が正しく適用されていることを評価するため
- 副作用(リグレッション)を検出するため
前述の通り、変更箇所と関係ない場所に副作用が生じることがあるため、下記のような変数に基づいてテスト範囲を決定する:
- 変更のリスク度合い
- 既存システムの規模
- 変更の規模
2.4.1 メンテナンスが必要となる理由
メンテナンスが必要となる理由
-
変更作業
- ソフトウェア自体の変更(当然)
- 動作環境の変更(パッチやアップグレード等)
-
移行作業
- 新しい環境へ
- 廃棄
-
IoTにおけるモノの追加変更等
- 統合テストが重要
- 個人データ周りはセキュリティが特に重要
2.4.2 メンテナンスの影響度分析
変更により予想される副作用を識別する
-
行った変更に対して行う
- 既存のテストに変更が必要なことがある(何がvalidかが変わる)
- これから行う変更に対して潜在的な影響度を分析するために行うこともある
以下の場合に難しくなる
- 仕様が最新版でない、または存在しない
- テストケースが文書化されていない、または最新版でない
- テストとテストベースとの間の双方向のトレーサビリティが維持されていない
-
ツールによる影響度分析のためのサポートが貧弱であるか、まったくない
- 【所感】静的解析が効くのはここかな
- ドメインやシステムの知識を持つ担当者がいない
-
開発時にソフトウェアの保守性が考慮されていない
- 高凝集・低結合度にする、共通化、リファクタリング等できれいにするとよい効果がある