Basic JSTQB試験カンニングペーパー

2024-12-22

2024
97.3% (356.2/366)
December
68.5% (21.2/31)
Week 51
89.2% (6.2/7)
Day 22 Sun
24.5% (5.9/24)

目次

FrontPage
・Windows11
・Chromebook
・Random
・機械学習
・さくらVPS
・Fedora13
・SuSe10
・Docker
・Ansible
・Java
・Scala
・Python
・Ruby
・Lisp
・Computer
・GIS
・HTML
・Culture
・Link

訪問者

total: 24431
today: 1
yesterday: 1
now: 1

更新

最新の10件

人気の10件

MenuBar

ソフトウェアが期待通りに動かない事による不都合 †

1. 経済的な損失
2. 時間の浪費
3. 信用の失墜
4. 傷害や死亡事故

ソフトウェアの欠陥の原因 †

1. エラー(error)
   • 「間違った結果を生み出す人間の行為」
2. フォールト(fault)
   • 「要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の不備」
   • ≒ バグ、欠陥
   • プログラマのエラー(error)によって、プログラムにフォールト(fault)が埋め込まれる
3. 故障(failure)
   • 「コンポーネントやシステムが期待した機能、サービス、結果を提供できないこと」
   • フォールト(fault)が、発現して故障(failure)になる。
   • フォールト(fault)のあるコンポーネントが使われることがなければ故障(failure)は発生しない
   • フォールト(fault)が無くても、放射能や電磁波、コンピュータウイルスにより故障(failure)が発生する
4. インシデント(incident)
   • 「ソフトウェア･システムを実際に使うユーザやテスト担当者が期待する動きと、実際の動きが一致しない事象」
   • ≒ 不具合、傷害
   • テスト環境や期待値の設定が間違っている場合があるので、インシデント(incident)があることが、直ちに故障(failure)があることを意味しない

テストの役割 †

1. リスクを低減する
   • リスク = 不確実 x 損失
   • プロジェクトリスク(ヒト・モノ・カネ）
   • プロダクトリスク
     • ソフトウェアやシステムで失敗する可能性のある領域
     • テストが漏れたことにより発生しうる損失や損害に対するリスク
   • リスクベースのアプローチ
     • 適用するテスト技法を決める
     • テストを実行する範囲を決める
     • 重大な欠陥をなるべく早く検出する(テストの優先順位を変える)
     • テスト以外でリスクを減らす方法を積極的に取り入れる
2. 使い勝手などの非機能要件に関わる課題を発見し、修正することで製品の魅力を高める
3. 契約や法律上の適格要件や各業界の標準に合致していることを証明するため

品質 †

• 品質の観点「顧客が喜ばなければ品質は高いとは言えない」

---

1. 当たり前品質
   • その製品の機能そのものが意図したとおりに動くこと
2. 魅力的品質
   • その製品が使いたくなるような特徴を持つこと

品質とテスト †

1. 品質を確保する
   • テストを行いインシデントを解消する
2. 品質を計測する
   • 客観的に判断できる指標で品質を判断する
   • ISO/IEC9126

     品質特性	品質副特性
     機能性	合目的性,正確性,相互運用性,セキュリティ,適合性
     信頼性	成熟性,障害許容性,回復性,適合性
     使用性	理解性,習得性,運用性,魅力性,適合性
     効率性	時間効率性,資源効率性,適合性
     保守性	解析性,変更性,安定性,試験性,適合性
     移植性	環境適応性,設置性,共存性,置換性,適合性

3. プロセス改善のための情報提供をする
   • 同じ原因のフォールト(fault、欠陥)を作り込まない

テストの十分性 †

• 十分なテストを行った ＝ テストの終了基準を満たしている
• テストの終了基準の観点
  1. リスク(プロダクトリスク・プロジェクトリスク）
     • 未修正の欠陥や、カバレッジ不足の領域
  2. 完全性の値
     • テストカバレッジ
  3. 納期
     • 出荷時期などのスケジュール
  4. コスト
     • 計画された予算
  5. テストの見積もり値
     • 欠陥密度や信頼性の指標
  6. 工程や予算などのプロジェクトの制限
• 終了時の引き継ぎ資料
  • 未対応インシデント一覧
  • 欠陥原因の分析資料
• 引き継ぎ資料の利用法
  • ステークホルダー(利害関係者)への情報提供
  • 次の開発ステップや次回リリースにおけるリリース戦略の基礎情報

テスト作業 †

テスト計画 †

1. テストの目的を定める
   • 欠陥の検出を主眼にする? 外部IFとの疎通確認をする?
   • 対象範囲の決定
     • サブシステムをテスト対象とするか･システム全体をテスト対象とするか
   • リスクの列挙
     • テストの目的を達成するときに傷害となる要因を挙げる
2. テストポリシーや戦略を作る
   • テストの目的の具体化 = 終了基準の設定
   • ステークホルダー間で合意をとる
3. テストの実施方法の決定
   • テスト技法
   • テストアイテム
   • カバレッジ
   • テストウェア
   • テストチームの立ち上げ
4. テストに必要なリソースを決める
   • 人員・テスト環境・端末など
5. テストの分析のスケジュールの立案
   • 分析材料をそろえる( RFP を始めとする各種設計書 )
   • 分析のスケジュールを立てる(テスト技術紗々のスキルを勘案すること)
6. テストの実装･実行･検証のスケジュールの立案

   概算スケジュール	リーダークラス以上の開発担当者やプロジェクトマネージャによる概算
   詳細スケジュール	テストを実施する開発担当者の積み上げ

テストの分析と設計 †

1. テストベースをレビューする
   • RFP、企画書、設計仕様書、アーキテクチャ定義書、社内標準・・・文書化されていない設計
2. テストベースやテスト対象のテスト容易性を評価する
3. テストアイテム、仕様、動作、構造などの分析に基づいて、テスト条件を識別し優先順位を付ける
4. テストケースを設計し、優先順位を付ける
   • テスト条件の設計法　：　大項目→中項目
   • 2つの網羅性を満たすように設計する
     1. 要求や仕様に対するカバレッジ
     2. コードカバレッジ
   • テスト条件の観点

     	ユーザ指向	フォールト指向
     要件指向		ブラックボックステスト
     設計指向	ホワイトボックステスト

5. テスト要件やテストケースをサポートする上で必要なテストデータを識別する
6. テスト環境を設計し、必要なインフラストラクチャやツール類を洗い出す

テストの実装と実行 †

• テスト設計で導き出されたテストの大･中項目から次の物を作る
  1. 詳細テストケース
  2. テスト手順書
  3. テストスクリプト
  4. テスト環境

---

1. テストケースを開発、実装し、優先順位を付ける
2. テスト手順を開発し、優先順位を付け、テストデータを作成し、テストハーネスを準備し、テストの自動実行スクリプトを書く
3. 効率よくテストを実行するため、テスト手順をベースにしてテストスイートを作る
4. テスト環境を正しくセットアップしたことを確認する
5. テスト手順に従い、テスト手順を人力、もしくはテストツールで実行する
6. テストの実行結果のログをとり、テスト対象のソフトウェア、テストツール、テストウェアのIDとバージョンを記録する
7. 実行結果と期待された結果を比較する
8. テスト実行結果と期待された結果が一致しない場合、インシデントとして報告し、原因を解明するためにインシデントを分析する
9. 実行結果と期待する結果が一致しないケース毎にテスト作業を繰り返す

   確認テスト	そのインシデントが発生しなくなることを確認する
   回帰テスト	関連箇所のテストをやり直し、修正により欠陥を作り込んでいないか or 隠れていた欠陥が無いかを確認する

終了基準の確認とレポート †

1. ドキュメント化
   • 提供を計画しているシステムの内どれがリリースされたかをチェック
   • インシデントレポートの終了作業
   • 未対策の欠陥を変更記録に載せる
   • システム受領（研修に必要なドキュメントを準備)
2. 次回でも使えるように、テストウェア、テスト環境、テストのインフラストラクチャーをまとめる。
3. テストウェアを保守部門に引き渡す
4. 次回のリリースやプロジェクトのために教訓とすべきことを糧にして、テストの成熟度を改善する

テストのコントロール †

1. テスト結果の計測と分析
2. テストカバレッジ･終了基準のモニタリングと文書化
   • メトリックスの収集と分析

     収集	日々
     分析	日々〜週次

     • テストの準備作業が完了した割合
     • テスト環境準備で完了した割合
     • テストケースの実行した割合
     • 欠陥情報 (欠陥密度 = 欠陥の数 ÷ プログラムの規模)
       ※「規模」の定義が微妙。いつから何を計るのか決めないと意味のない数字になる
     • 要件・リスク・コードにおけるカバレッジ
     • テスト担当者の主観的な信頼度
     • テスト作業のマイルストーン
     • テストに要するコスト
   • 分析結果は、ステークホルダー全員で共有する
3. 欠陥修正の影響調査
   • インシデント対処のタイミングを管理する
   • 優先順位、インシデント同士の依存関係、再テストの必要な範囲の特定
4. 意志決定
   • テストの中断･再開･終了
   • 手に負えなくなったらエスカレーションする

テスト種類と目的 †

1. ドキュメントテスト(要件定義書のレビューなど)
   • 欠陥の作り込みの防止
2. 開発時のテスト(コンポーネントテスト・統合テスト・システムテスト)
   • ソフトウェアの欠陥を修正する
   1. コンポーネントテスト
      • スタブとドライバを使う
      • 非機能(性能)。メモリリーク(リソース)。ロバストネス。ブランチカバレッジ(構造テスト)
   2. 統合テスト
      • コンポーネント間の相互作用
      • 非機能(性能)。トランザクション。OSや外部IFとの相互作用
   3. システムテスト
      • セキュリティテストを行う
      • 本番環境に近い環境でテストを行う
      • 機能・非機能のテストを行う
      • ブラックボックステスト(納入準備)で行う
3. 受け入れテスト
   • 対象ソフトウェアの品質レベルが十分であることの確認と提示
4. 保守テスト
   • ソフトウェアの変更時に、新たなエラーが潜んでいないかを確認する
5. 運用テスト
   • 信頼性や可用性などのシステムの特性を確認する

---

要件定義              受け入れテスト
  基本設計          システムテスト
    詳細設計    　統合テスト
      実装    コンポーネントテスト(ユニットテスト)

デバッグはテストぢゃないよ †

テストの7原則 †

1. テストは欠陥があることしか示せない
   • 欠陥がないことは示せない
2. 全数テストは不可能
3. 初期テスト
   • 作り込んでしまった欠陥を見つけるのは早いほうが良い
4. 欠陥の偏在
5. 殺虫剤のパラドックス
   • 同じ観点からのテストばかりをしていると、バグに耐性が出てくる(その観点からはバグが見つからなくなる)
6. テストは条件次第
   • 実地に使われる環境に近いテストケースを作る
   • 24h365d止められないシステムなのか? 夜間は止められるのか?
7. 「バグゼロ」の落とし穴
   • あるとき取りまとめたインシデントが全て対処されたとしても、そのインシデント対処の過程で新たなバグ(fault)が埋め込まれているかもよ

テストの独立性 †

機能テスト・非機能テスト・構造テスト・確認テスト・回帰テスト †

1. 機能テスト
   • 機能 = 「What(何をするのか)」≠「How(どうやって)」
   • 機能テスト = 機能が仕様通りに実装されているのかのテスト = ブラックボックステスト = 仕様ベースのテスト技法
   • ISTQB では、セキュリティは、セキュリティ機能のテスト （一般的には非機能っぽいけど)
2. 非機能テスト
   • 非機能 = 「How(どうやって)」 ≠ 「What(何をするのか)」
   • コンポーネントテスト・統合テスト・システムテスト・受け入れテスト、それぞれの段階で非機能テストを行う
   • ISO/ICE9126の観点を参考する
     • 性能テスト
     • ロードテスト
     • ストレステスト
     • ユーザビリティテスト
     • 相互運用性テスト
     • 保守性テスト
     • 信頼性テスト
     • 移植性テスト
3. 構造テスト
   • システムテストレベルでも構造テストを行うことがあることに注意(制御フロー･ワークフロー)
4. 確認テスト、回帰テスト

   確認テスト	対処したインシデントが発生しなくなることを確認する
   回帰テスト	関連箇所のテストをやり直し、修正により欠陥を作り込んでいないか or 隠れていた欠陥が無いかを確認する

5. 保守テスト
   • 保守テストを行うとき
     1. ソフトウェアの変更作業を行ったとき
     2. 新しい環境への移行作業を行ったとき
     3. システムの入れ替え(改修作業）を行ったとき
   • 影響度分析を行う
   • 影響度分析を元に回帰テストの範囲を決める

静的テスト †

• ドキュメントは、動的テストできないので静的テストでやるしかないね
  • 静的テストは、あらゆる段階に適用可能。動的テストは動く物ができてから
• 動的テストの比べて、ソフトウェアの構造的欠陥(処理抜け)を発見しやすい
• 動かさないと分からないのは、動的テストで発見しやすい

---

1. レビュー

   フェーズ	概要	担当者
   1.計画	期間見積もり、関係者の招集、開始基準・終了基準の定義	ﾏﾈｰｼﾞｬ、ﾓﾃﾞﾚｰﾀ(まとめ役)
   2.ｷｯｸｵﾌ		全員
   3.個々の準備	事前資料(問題点、質問、ｺﾒﾝﾄ、静的解析ﾂｰﾙのﾚﾎﾟｰﾄ)の作成・配布、cﾁｪｯｸﾘｽﾄの作成。配付資料の読み込み	各担当者
   4.ﾚﾋﾞｭｰﾐｰﾃｨﾝｸﾞ	議事録と課題一覧を忘れずに	全員、書記
   5.再作業	課題解決	各担当者
   6.ﾌｫﾛｰｱｯﾌﾟ	(a)修正結果の確認、(b)ﾒﾄﾘｯｸｽ(品質ﾃﾞｰﾀ)の収集、(c)終了基準を満たしているかの確認	検証者

    

   	公式	主導者	概要・備考
   非公式レビュー	非公式	特になし	XPのペアプログラミングも非公式レビューの一種
   ウォークスルー	非公式	作成者
   テクニカルレビュー	非公式	経験を積んだモデレータ
   インスペクション	公式	経験を積んだモデレータ	記録を残す

    
   • モデレータはまとめ役。レビュアーは特定の分野の専門家
2. ツールによる解析
   • 構造分析
   • 複雑度分析(ソースコード分析ソフトを使う)
   • モジュール/オブジェクト分析
   • サイクロマティック複雑度
     • M = L - N + 2P
     • L : 分岐数(Link) --> 分岐が収束するときのアークの数も数える
     • N : 行数(Node)
     • P : ブロック(Part)

       if( a == b ){ //L=1
         a++;
       } else {      //L=2
         a = 0;
       }             //L=4(ifとelseが統合されるので2)

     • M = 4 - 4 + 2 x 1 = 2

テストの設計手順 †

1. テスト条件を決定し、テストを設計する
   • テスト対象 = 「テストアイテム」= 何をテストするか
   • テスト条件 = テストアイテムをどういう切り口でテストするか
     1. 機能
     2. 構造的要素
     3. トランザクション
     4. 品質特性
   • テストの設計
     • テスト条件をどのような方法でテストするかの戦略を決める
     • その優先順位、影響範囲を付記する
2. テストケースを定義する
   • テスト条件を具体的にどのようにテストするかを定義する
     • 要件との間に明確なトレーサビリティがあること
     • 期待する出力も記述してあること
   • 一つのテスト条件に付き最低一つ以上のテストケース
3. テスト手順仕様書を定義する
   • 複数のテストケースをどのような環境でどのような順番で実行するか
   • テスト担当者の力量に合わせた粒度で記述することが必要

テストのアプローチ †

• 予防的アプローチ vs 対処的アプローチ

---

1. 分析的アプローチ
2. モデルベースアプローチ(過去の指標値を使う)
3. 方法論的アプローチ
4. プロセス準拠アプローチ
5. 動的で経験則に基づいたアプローチ
6. コンサルテーションベースのアプローチ
7. 回帰的アプローチ

---

アプローチ方法を決める要素

1. リスク
2. スキル・経験
3. 規則
4. 特性(プロダクトや業界の)

テストの設計手法 †

• 仕様ベースの技法を使ったあとに、構造ベースの技法を補足的に使うことができる
  • 仕様ベースのテストで、表に出ている仕様を満たしていることを証明
  • そのあと、構造ベースの技法で、仕様ベースのテストで見逃されていたところをテストする

仕様ベース †

1. 同値分割法
   • 入出力の組を同値クラスにまとめて、同値クラス内の代表的なデータをテストする
   • 値による同値クラス (0〜100、100〜1000 など)
   • 時間による同値クラス (イベント発生前、後 など)
   • カバレッジ = テストケース数 ÷ 同値クラス数
2. 境界値分析
   • 0〜100の同値クラスについて
   • ISTQB では、-1,0,100,101 を境界値分析としてテストしろと言っている
   • 一般的には、-1,0,1,99,100,101 をテストするのが無難
   • カバレッジ = テストケース数 ÷ (同値クラス数 x 2)
3. デシジョンテーブルテスト
   • x,y,z が入力。a,b が出力とすると

     	規則1	規則2	規則3
     条件x	1	5	100
     条件y	2	6	200
     条件z	3	7	300
     結果a	10	null	error
     結果b	20	-1

     とか
   • 順列組み合わせでテストケースを列挙しやすい
   • カバレッジ = テスト実施数 ÷ 規則数
4. 状態遷移テスト
   • 状態遷移図
   • 状態遷移表

     	状態1	状態2
     イベント1	状態2になる	状態1になる
     イベント2	状態1のまま	状態2のまま

   • chowカバレジ(0スイッチ)=セル網羅基準
     状態遷移表を全網羅しているかのカバレッジ

     状態1 → イベント1 → 状態2

     状態1 → イベント2 → 状態1

     状態2 → イベント1 → 状態1

     状態2 → イベント2 → 状態2

   • chowカバレジ(1スイッチ)
     2つの遷移と3つの状態を網羅しているかのカバレッジ

     状態1 → イベント1 → 状態2 → イベント1 → 状態1

     状態1 → イベント1 → 状態2 → イベント2 → 状態2

     状態1 → イベント2 → 状態1 → イベント1 → 状態2

     状態1 → イベント2 → 状態1 → イベント2 → 状態1

     状態2 → イベント1 → 状態1 → イベント1 → 状態2

     状態2 → イベント1 → 状態1 → イベント2 → 状態1

     状態2 → イベント2 → 状態2 → イベント1 → 状態1

     状態2 → イベント2 → 状態2 → イベント2 → 状態2

5. ユースケーステスト
   
   • ユースケーステストのフォーマット

     項目	概要・備考
     ユースケース名
     目的
     アクタ
     事前条件
     事後条件
     基本フロー
     代替えフロー	基本フローと事前・事後条件が同じだが、マイナーな操作
     例外フロー	基本フローと事前・事後条件が違う
     備考

     • ユースケース図ではなく、ユースケース記述からテストケースを作る

構造ベース †

• コンポーネントテストでなくても構造ベースのテストを実行できる

  テストレベル	構造
  コンポーネントテスト	コード
  統合テスト	コールツリー
  システムテスト	メニューの構造、ビジネスプロセス

• コードのテストとカバレッジ

  ステートメントテスト	コードの全行通るテストケースを作る
  デシジョンテスト	コードの全分岐を通るテストケースを作る

  • デシジョンテスト ⊃ ステートメントテスト
  • デシジョンテストのややこしいの

    条件カバレッジ	if( a>100 and b>50 ) の条件文の中身を分けて考える
    複合条件カバレッジ	if( a>100 or b>50 ) では b>50 が評価されないことを考慮する

経験ベース †

• 単なる闇雲なテストになる恐れ有り（モンキーテスト）
• 経験者がテストを設計すれば、最終確認的な位置づけとして効果有り
  • エラー推測（フォールト攻撃)
    • 経験や一般知識からエラーが起きそうなテストケースを作る
    • 0,null,空白,閏年など
  • 探索的テスト
    • アタリを付けてバグの巣を見つける
    • テストケースを事前に設計できない場合に用いる
    • 仕様ベース･構造ベースのテストを行った後の最終確認に用いる ← これは効果大

テストの見積もり †

• ダメなやり方　：　作業の担当者やエキスパートが見積もる(どうしても納期と費用から帳尻を合わせてしまう)
• 良いやり方 ：　類似プロジェクトやメトリクスを元に算出
• 見積もり要素
  • プロダクトの特性
  • 開発プロセスの特性
  • テスト出力結果

構成管理とテスト †

• ある時点の製品の部品が一意に特定できるように管理し、記録すること
  • 製品を構成する実行ファイル、ヘルプマニュアルなどが取り出せること
  • 実行ファイルを作るためのソースやスクリプトなどが管理されていること(トレーサビリティ)
• テスト成果物も構成管理の対象だよ
  • テスト対象となるソフトウェア
  • ソフトウェアの動作環境
  • テストウェア(スクリプト・データ)
  • 欠陥(故障、インシデント)
  • テスト結果
  • ドキュメント

IEEE829-1998 †

ドキュメント体系 †

PRJECT DOCUMET        TEST ITEM
(ﾌﾟﾛｼﾞｪｸﾄﾄﾞｷｭﾒﾝﾄ)     (テスト実施対象)
ITEM DOCUMENT           ｜
(開発関連ﾄﾞｷｭﾒﾝﾄ)       ｜
 ↓                     ｜ 
TEST PLAN               ｜
(テスト計画)            ｜
 ↓                     ｜
TEST DESIGN SPEC        ｜
(テスト設計仕様)        ｜
 ↓                     ｜
TEST CASE SPEC          ｜
(テストケース仕様)      ↓
 ↓                    TEST ITEM TRANSMITTAL REPORT
TEST PROCEDURE SPEC    (テスト実施対象伝達報告書)
(テスト手順仕様)        ｜
 ↓                     ↓
[ ■■■■■ TEST EXCLUSION ■■■■■ ]
 ↓
TEST LOG
TEST INCIDENT REPORT
 ↓
TEST SUMMARY REPORT

テスト計画書の構成 †

• マスターテスト計画書
  • 統合テスト計画書
  • システムテスト計画書
    • 性能テスト計画書
    • セキュリティテスト計画書
  • 受け入れテスト計画書

テスト計画書の内容 †

• Test plan identifier
• Introduction
• Test items
• Features to be tested (テストすべき機能)
• Features not to be tested (テストしない機能)
• Approach
• Item pass / fail criteria (合否判定基準)
• Suspension criteria and resumption requirement (中止／再開基準)
• Test deliverables (テスト成果物)
• Testing task
• Environmental needs
• Responsibilities (責任範囲)
• Staffing and training needs
• Schedule
• Risk and contingencies (リスクと対策)
• Approvals (承認)

テストレポートの内容 †

• Test summary report identifier
• Summary
• Variances (変更点)
• Comprehensive assessment (総合評価)
• Summary of result
• Summary of activities (テスト作業の概要)
• Approvals (承認)
• ※ Incident は 付録

インシデントレポートの内容 †

インシデントレポートの目的

1. 開発者に、問題を明らかにし、原因を特定して解決していけるように情報を提供する
2. テストリーダーに、テスト実行中のシステムの品質や、テストの進捗に関する情報を提供する
3. テストプロセスの改善のためのヒント提供する

---

• Test incident report identifier
• Summary
• Incident description
  • Inputs
  • Expect results
  • Actual results
  • Anomalies (異常)
  • Date and time
  • Procedure step (実行手順)
  • Environment
  • Attempts to repeat (再現手順)
  • Testers (テスト担当者)
  • Observer (確認者)
• Impact (影響範囲)

インシデントレポートの対処手順 †

              -------- Failure
             ↓           ↑
Open ----> Assign ----> Test ----> Close ---> End
              |
               -------> Reject -------------> End

---

Computer