JSTQBテスト
①ソフトウェア開発のライフサイクルとテストのライフサイクルの対応付けで正しいものはどれか。
1) 高レベル設計 A) ユニットテスト
2) コード B) 受け入れテスト
3) 低レベル設計 C) システムテスト
4) ビジネス要求 D) 統合テスト
[a] 1-D, 2-A, 3-C, 4-B
[b] 1-C, 2-D, 3-A, 4-B
[c] 1-B, 2-A, 3-D, 4-C
[d] 1-C, 2-A, 3-D, 4-B
正解 [d]
ユニットテスト、コンポーネントテスト、モジュールテストはJSTQBでは同義としています。ソフトウェアの構成要素として最小の単位をコンポーネントと呼ぶか、ユニットと呼ぶか、モジュールと呼ぶかの差異です。
テストレベルとテストベースの関係をV字モデルで捉えると、以下の感じになるでしょう。テストベースを表現する用語は開発手法や組織に依存するので、厳密なものではありません。
ビジネスシナリオ・ビジネス要求・システム要求 --- 受け入れテスト
システム要件／仕様・外部設計・基本設計・高レベル設計 --- システムテスト
内部設計・詳細設計・低レベル設計 ---統合テスト
モジュール設計・コード ---コンポーネントテスト
②構造テストを適用できる範囲として適切なのはどれか。
[a] すべてのテストレベルで利用できる。 [b] システムテストでは利用できない。 [c] ユニットテストのみで利用できる。 [d] ユニットテストと統合テストで利用できる。
正解 [a]
構造テスト(structural test)とは、構造をベースとしたテスト、つまりホワイトボックステストのことです。構造テストは、いわゆる構造をもったテスト対象であれば全て適用できます。ユニットテストではコード、統合テストではコンポーネント、システムテストでは画面やメニューなどを構成要素として構造テストが行えます。
③公式なインスペクションで行うアクティビティの順序として正しいものはどれか。
[a] 計画→キックオフ→個々の準備→レビューミーティング→再作業→フォローアップ
[b] 計画→キックオフ→個々の準備→レビューミーティング→フォローアップ→再作業 [c] キックオフ→計画→個々の準備→レビューミーティング→フォローアップ→再作業 [d] キックオフ→計画→個々の準備→レビューミーティング→再作業→フォローアップ
正解 [a]
公式レビューは6つのアクティビティで構成されます。これらのアクティビティは通常、シーケンシャルに実施されます。「計画」では、レビュー参加者の人選をし、「キックオフ」において参加者にドキュメントの配布してレビューの目的や手順を説明します。また、レビューで指摘された欠陥を修正する作業が「再作業」で、レビュー終了基準を判断するのが「フォローアップ」です
4 インシデントレポートに含めなくていい情報はどれか。
[a] 欠陥の修正方法
[b] 欠陥を再現する方法
[c] 重要度や優先度
[d] 期待結果と実際の結果
正解 [a]
IEEE 829のインシデントレポート標準では、記載すべき項目として期待される結果、実際の結果、再現手順(attempts to repeat)が挙げられています。また影響範囲としてインシデントの範囲、重要度(severity)、優先順位(priority)を記録することを推奨しています。なお、IEEE 829の再現手順(attempts to repeat)には、再現性(reproducibility)も包含しているようです。再現させるための試行回数や毎回起きるか稀に起きるかといった再現頻度に関するノートを記述するように指示されています。欠陥の修正についての情報は、修正後のステータスや履歴、修正による他への影響は記載されますが、具体的な修正方法をインシデントレポートに記述することは必要なさそうです。
5 テストが終了したと判定された時点から「テスト終了作業」のフェーズに進むことになる。テスト終了の判断でないものはどれか。
[a] システムがリリースされた。
[b] プロジェクトが途中で打ち切られた。
[c] マイルストンを達成した。
[d] プロダクトを保守部門に引き渡した。
正解 [d]
プロダクトの保守部門への引き渡しは、テスト終了作業において行う内容です。設問では、テスト終了作業を開始できる条件が問われています。テスト終了の判断は、通常、計画された最後のテストレベルの「テスト終了基準の評価とレポート」で行われます。テスト終了作業は、テストレベルのループの中で行うものではなく、テストの全体計画(マスターテスト計画)に対応して、テストレベルのループの後に行うことが一般的です。ただし、計画によってはテストレベルのループの中に含まれる部分もあります。その場合、テストレベルごとのテスト終了作業と、テスト全体でのテスト終了作業に分離して考える必要があります。Foundationの学習者は、テスト全体のテスト終了作業のみを意識しておけば、それで十分でしょう。
6 ホワイトボックステストに分類されるのはどれか。 [a] 状態遷移テスト
[b] デシジョンテーブルテスト [c] デシジョンテスト
[d] 探索的テスト
正解 [c]
ホワイトボックステストは構造べースのテスト技法であり、JSTQBのシラバスでは、特に「ステートメントテスト」と「デシジョンテスト」が取り上げられています。 デシジョンテストは、if文などによる処理の判定(デシジョン)をベースにしています。JSTQBでは、デシジョンテストはブランチテストとほぼ同義としています。その網羅率を「デシジョンカバレッジ」または「ブランチカバレッジ」と呼びます。
7 JSTQBで定義している「エラー」の説明として適切なのはどれか。
[a] コンポーネントやシステムが期待される結果を提供できない状態 [b] コンポーネントやシステムの中の不備 [c] 期待結果と実際の動作が違った状況 [d] コードやドキュメントに不備を混入させる原因となった人の行為の誤り
正解 [d]
インシデント(incident)は、JSTQBの用語集では「発生する事象中で調査が必要なもの」とされています。[a]は欠陥(fault,defect)、[b]は不正(anomaly)、[c]は誤り(mistake,error)の定義です。
8 非機能テストでないものはどれか。
[a] セキュリティテスト
[b] ユーザビリティテスト
[c] ロードテスト
[d] インストールテスト
正解 [a]
セキュリティテストは、JSTQB/ISTQBでは機能テストとして分類されています。ユーザビリティ／使用性は品質特性です。ロードテストは性能テストの一部です。インストールテストは、微妙なところもありますが、ISO 9126に従う設置性(installability)のテストだとすると、非機能テストとなります。セキュリティは、ISO/IEC 9126では機能性(functionality)のサブカテゴリとされています。functionalityは機能(function)そのものではなく、機能の充足性を表現する非機能特性と捉えるべきです。機能性には他に相互運用性(interoperability)や正確性(accuracy)などがあります。ISTQB/JSTQBでは、これら機能性のテストは機能テストとみなすことにしたようです。厳密には、セキュリティには機能的な側面のテストと、非機能的な側面のテストを包含していると言えますが、Foundationのシラバス上では、機能テストとして語られているという状況です。
10 「テスト分析と設計」の目的は何か。
[a] テスト条件を識別することであり、テストケースを識別することではない。 [b] テスト条件を識別することではなく、テストケースを識別することである。 [c] テスト条件を識別し、テストケースを識別することである。 [d] テストケースの入力データ、テスト手順を具体化することである。
正解 [c]
テスト分析では、テスト条件を識別します。テスト設計は、そのテスト条件を網羅するテストケースを識別します。ですから、それらを包含したテスト分析と設計の活動は、テスト条件を識別し、テストケースを識別する目的で行う、と言えます。
11 あるレビューが計画され、レビューの開始基準と終了基準が定義されている。
特に終了基準についてはフォローアップのプロセスにおいて判定することになった。
このレビューの形式はどれか。
[a] ウォークスルー
[b] インスペクション
[c] テクニカルレビュー
[d] 非公式レビュー
正解 [b]
レビューの開始基準と終了基準が定義されているのは、公式性の高いレビューです。フォローアップのプロセスが明確化されているのは、インスペクションです。 本来、レビューの公式性とレビュータイプは別のものです。しかし、一般にインスペクションは公式性が高いということになっているようです。
12 小学校の学年について、境界値分析を行ってテストデータを決める場合、その組み合わせはどれか。
[a] 1, 6
[b] 1, 2, 3, 4, 5, 6
[c] 0, 1, 6, 7
[d] 0, 3, 6
正解 [c]
境界値分析では領域の上限と下限の近傍についてテストします。FL試験では、領域に含まれる値と含まれない値をテストケースとすることを推奨しています。小学校の学年は上限と下限が整数値で1と6です。ですから、その外側にある整数値0と7を加えてテストケースとします。
13 ホワイトボックスのテスト技法はどれか。
[a] 同値分割
[b] 状態遷移図
[c] ステートメントテスト
[d] デシジョンテーブル
正解 [c]
ホワイトボックステストは構造べースのテスト技法であり、JSTQBのシラバスでは、特に「ステートメントテスト」と「デシジョンテスト」が取り上げられています。ステートメントテストは、コードの実行可能なステートメント(1行ごと)が実際にどれだけ実行されたかをチェックするテストです。コードには、if文やswitch文、for文などのループ処理、例外処理などの分岐が含まれるため、それら分岐を網羅するようなテストケースを用意する必要があります。ステートメント(1行ごと)単位で網羅率をチェックするのがステートメントテストで、if文などの分岐でture/falseの両方を確実にチェックしていくのがデシジョンテスト(ブランチテスト)です。
14 テスト戦略をクラス分けする観点の1つとしてテスト設計を開始するタイミングがある。
欠陥の発生を予防するため、できるだけ早い時期にテスト設計を開始するアプロ-チを何と呼んでいるか
[a] 対処的アプローチ
[b] 分析的アプローチ
[c] 予防的アプローチ
[d] 回帰的アプローチ
正解 [c]
設問の記述は「予防的アプローチ」を説明しています。予防的アプローチに対して、プロダクトができてからテスト設計を開始するアプローチを「対処的アプローチ」と呼んでいます。ただし、シラバス2010以降、予防的アプローチ、対処的アプローチといった分類は除外されました。テストアプローチはテスト戦略にもとづいて具体化されますが、対処的アプローチが戦略的でないことから除外されたと思われます。戦略的に行えば、すべて予防的になるはずです。
15 JSTQBでは、テストツールをいくつかのカテゴリに分類している。動的解析ツールは、どのカテゴリに分類されるか。
[a] テストマネジメントの支援ツール [b] テスト仕様の支援ツール [c] テスト実行とロギングの支援ツール
[d] 性能・モニタリング支援ツール
正解 [d]
動的解析ツールは、性能・モニタリング支援ツールに分類されます。ツールの分類を下表で確認しておいてください。
16 段階的にではなく、ソフトウェアやハードウェアの要素を全て一挙に結合して、コンポーネントやシステム全体をテストする技法を何か。
[a] システムテスト
[b] ビッグバンテスト
[c] 統合テスト
[d] ユニットテスト
正解 [b]
ビッグバン(big-bang)は、コンポーネントを統合するアプローチの１つです。テストの際に統合を段階的に行うものをインクリメンタルテストと呼んでいるの対し、一挙に全てを統合するものをビッグバンテストと呼んでいます。
17 サイクロマティック複雑度が高いプログラムの説明として適切なのはどれか。
[a] 大規模なソフトウェアである。 [b] 高品質なソフトウェアである。 [c] コードを書くのが困難なソフトウェアである。
[d] テストするのが困難なソフトウェアである。
正解 [d]
サイクロマティック複雑度が高いプログラムは、テストするのが困難なソフトウェア、保守性の悪いソフトウェアと言えます。
18 スイッチのONとOFFについて状態遷移図(state transition diagram)を描いてみる。
その場合、状態遷移として表現されるものはどれか。 1) ON
2) ONからOFFへ
3) OFF
4) OFFからONへ
[a] 1, 2, 3
[b] 1, 2, 3, 4
[c] 1, 3
[d] 2, 4
正解 [d]
ON,OFFは状態です。状態遷移といえば、ONからOFFへの遷移とOFFからONへの遷移の2つです。
19 テストの進捗を監視するのに適した指標はどれか。
1) テストケースを実行したパーセンテージ 2) テスト環境の準備具合を示すパーセンテージ 3) 欠陥密度、発見された欠陥数、修正された欠陥数などの情報 4) テストチームの規模やエンジニアのスキル
[a] 1, 2
[b] 1, 2, 3
[c] 1, 4
[d] 4
正解 [b]
選択肢の 1),2),3)は、シラバスに代表的なメトリクスとして挙げられています。
テストチームの規模やエンジニアのスキルは、テスト進捗を監視する目的でメトリクスとして収集することはないでしょう。確かに、テスト進捗はテスト要員の数やスキルにも影響されますが、それはプロジェクト管理の領域です。
20 インシデントを登録した後にとった行動として適切であったのはどれか。 [a] インシデントのステータスを一旦、クローズとした。 [b] 実際と合うように、テストケースの期待結果を訂正しておいた。 [c] 原因がはっきりしなかったので、設計者にエスカレーションした。 [d] たまたま自身が書いたコードに原因があると分かったので、すみやかに修正した。
正解 [c]
新規に登録されたインシデントのステータスは、調査が開始された時点でオープン(Open)となり、原因分析や修正の担当者が割り当てられた時点で対応中(Assigned)などになります。一旦クローズにするということはありえません。テスト結果を評価した結果、テストケースのテストデータ、手順、期待結果の記述が誤っていることが判明する場合もあります。
21 キャプチャ再生機能を持つテストツールを利用すると、もっとも効果的であるのはどれか。
[a] 統合テスト
[b] システムテスト
[c] 回帰テスト
[d] ユーザー受け入れテスト
正解 [c]
キャプチャ/プレイバック機能をもつテストツールは、機能テストや回帰テストの自動化を行ったときに効果を発します。工数をかけずに繰り返してテストできるので、特に回帰テストに効果的です。
22 テストを行う順序として、どれが適切か。 [a] 重要なテストから
[b] 難しいテストから
[c] 簡単なテストから
[d] テストが作成された順で
正解 [a]
余計なことを考えず、素直に「重要なテストから」を選択しましょう。
23 システムテストで行う機能テストの説明として、もっとも適切なものはどれか。
[a] システム機能を他システムと合わせてテストする。 [b] システム機能を構成するコンポーネントを合わせてテストする。 [c] システム全体の機能性を隅から隅までテストする。 [d] システム機能のレスポンスタイムをテストする。
正解 [c]
[a]は一般に、受け入れテストや大規模システムでの統合テストの範囲となります。[b]はコンポーネントの統合テストです。[d]は性能テストであり、非機能テストになります。[c]はシステムテストで行う機能テストと言えそうです。
24 「ベータテスト」の説明としてもっとも適切なものはどれか。
[a] 顧客側の環境で顧客によって実施される。 [b] 開発側の環境で顧客によって実施される。 [c] 独立したテストチームがテストする。
[d] ライフサイクルのできるだけ早い時期に実施される。
正解 [a]
ベータテストは受け入れテストの1形態であり、実際のユーザーや想定されるユーザーが顧客側の環境でテストします。通常、開発側の環境でアルファテストを行った後で、ベータテストに移行します。
25 公式なレビューにおいて、レビューを実施することを決め、実施のスケジュールを立て、レビュー目的が合意できたかを判断するのは誰か。
[a] インスペクションリーダ [b] モデレータ
[c] スクライブ
[d] マネージャ
正解 [d]
設問は、公式レビューにおけるレビューマネージャの役割を説明しています。
一般的なレビューを想定して、JSTQBではレビュー参加者の役割として以下を定義しています。
マネージャ
モデレータ（※インスペクションリーダとも呼ぶ）
作成者
レビューア (＝チェッカー、インスペクタ)
書記（＝記録係、スクライブ）
読み手（※インスペクションのみ）
26 組織内にテストツールを展開しようとしている。適切でないものはどれか。
[a] ツール未使用の部署にツールを同時に展開する。 [b] ツールを適用しやすいようにプロセスを改善する。 [c] 新規ユーザに対し、教育やトレーニングを行う。 [d] ツールの利用状況や効果をモニタリングする。
正解 [a]
新規にツールを導入する場合には、リスクもあります。ツールがうまく適用できなかったり、思いの外、工数がかかることがあります。その場合でも被害が少なくて済むように、パイロットプロジェクトを選定して、そのプロジェクトでツール導入の効果を評価しておくことが有効です。
27 「テストベース」の説明としてもっとも適切なのはどれか。
[a] テスト対象と同義である。 [b] テストのもととなる開発関連のドキュメント
[c] テスト結果と比較するための期待結果を決定するソース [d] テストを行うために必要となるスタブやドライバからなる環境
正解 [b]
テストベースは、ドキュメントやコードです。要求、アーキテクチャ、設計、インタフェースなどを記述したドキュメントです。各テストレベルには対応するテストベースがあります。
28 人の年齢を扱う変数 x は1から130までの値をとるものとする。境界値分析で入力値を決めるとどの組み合わせが適切か。
[a] 0, 1, 2, 130
[b] 1, 129, 130, 131
[c] 0, 1, 130, 131
[d] -1, 0, 1, 130
正解 [c]
正常な入力値の境界は1と130なので、その外側にある整数の0と131を加えた入力値が正解です。
29 以下の4つの中で仲間はずれのテストはどれか。
[a] ホワイトボックステスト [b] グラスボックステスト [c] 構造テスト
[d] 機能テスト
正解 [d]
機能テストは仕様ベースのテスト技法です。他の3つは構造ベースのテスト技法です。グラスボックステストは、ホワイトボックステストの別称です。
30 保守テストの対象でないものはどれか。
[a] セキュリティホールなどのパッチ適用 [b] 使われていないデータの一括削除 [c] データベースのアップグレード [d] システム入れ替え時のデータの一時的な保管
正解 [b]
使われていないデータの一括削除は、通常運用の範囲です。OS、データベースやその他のミドルウェアの移行、アップグレード、パッチ適用は保守の範囲になります。
31 以下に挙げたテスト技法の中で、経験ベースの技法はいくつあるか。
1) エラー推測
2) モンキーテスト
3) 探索的テスト
4) リスクベーステスト
[a] 2つ
[b] 3つ
[c] 4つ
[d] 上記以外
正解 [a]
シラバスでは、経験ベースの技法として、エラー推測と探索的テストが取り上げられています。リスクベーステストはテストアプローチです。モンキーテストは、ランダムに操作を行うテストであり、経験ベースとは言えません。
32 大規模システムではどのようなテストアプローチが適切か。
[a] 同時に多くのテストをしないようにする。
[b] テストはリスクをベースに行う。 [c] 良質なテストケースのみを実行すればよい。 [d] 優秀なテストエンジニアによって書かれたテストケースを実行すればよい。
正解 [b]
大規模システムでは、緊急度の高い部分を重点的にテストするリスクベースのアプローチが有効です。
他の選択肢は、ほとんど論外でしょう。
33 特定の機能をテストするためにプログラマが作成したものであり、それにテストデータを流して機能をテストするものは何か。 [a] スタブ
[b] ドライバ
[c] プロキシー
[d] エミュレータ
正解 [b]
用語集では、ドライバ(driver)は「コンポーネントやシステムを制御したり呼出す上位コンポーネントの代わりとなるソフトウェアコンポーネントやテストツール」、スタブ(stub)は「特定のコンポーネントをテストするため、そのコンポーネントから呼び出されるコンポーネント。スタブがないと、実物ができるまで、開発やテストを待たなければならない。
34 以下に挙げた作業の中で、テストリーダが行うものはどれか。
1) テストの仕様、前準備、構築、実行をスタートさせ、テスト実施のモニタリングやコントロールをする。
2) テスト戦略を具体化し、プロジェクトマネージャとテスト計画を策定する。
3) テスト計画をレビューしたり、改善案を提案する。 4) テストの順番を決める。 5) テストの自動化を行う。
[a] 1, 2, 3, 4, 5
[b] 1, 2, 3, 5
[c] 1, 2, 4
[d] 3, 4, 5
正解 [c]
テストリーダ(test-leader)の作業とテスト担当者(tester)の作業を正しく認識できているかどうかを問う典型的な問題です。「テスト計画をレビューし、改善案を提案する」のはテスト担当者です。紛らわしい表現ですが、テストリーダが作成したテスト計画をメンバがレビューして、改善点があれば指摘して改良してもらうことです。
35 「故障率」の説明として正しいのはどれか。 [a] インシデントとして登録した故障の中で欠陥として修正した件数を、故障の全数で割った値
[b] 発生した故障の数を、実施したテストケース数で割った値 [c] 発生した故障の数を、テスト時間、トランザクション数、コンピュータの運用回数などで割った値
[d] 発生した故障の数を、規模を示すコード量やクラス数などで割った値
正解 [c]
故障率は、用語集では、「測定単位に発生したあるカテゴリの故障数の率。例えば、単位時間あたりの故障数、トランザクション数あたりの故障数、コンピュータの運用回数あたりの故障数。」と説明されています
36 ある整数値の変数 ｘ は、範囲として 0 ≦ ｘ ＜ 100 が許容される。
この変数 ｘ に対して境界値分析でテストデータを決める場合、どの組み合わせが適切か。
[a] -50, 50, 150
[b] 0, 1, 99, 100
[c] -1, 0, 99, 100
[d] -1, 0, 1, 99, 100
正解 [c]
FL試験では、境界値分析は境界値の範囲に含まれる値と含まれない値をテストケースとすることを推奨しています。FL試験では[c]が正解となります。
37 以下で説明しているテストツールは何か。 プログラムやHTML,XMLなどのコードを分析して、構造の依存関係をレポートしたり、事前に登録されたルールと照合することでエラーを検出できる。
また、これらの分析は構造を理解する上で非常に役立つ。
[a] レビューツール
[b] モデリングツール
[c] 動的解析ツール
[d] 静的解析ツール
正解 [d]
静的解析ツールを説明しています。コードを対象とした静的解析ツールは広く利用されています。コーディング規約を遵守しているかをチェックしたり、モジュール間の依存関係をグラフ化して複雑度を指摘したりします。静的解析ツールで得られるメトリクスの情報は、テスト計画やリスク分析に利用できます。
38 顧客自身が顧客の環境で実施するテストは何か。
[a] アルファテスト
[b] フィールドテスト
[c] 運用プロファイル
[d] システムテスト
正解 [b]
受け入れテストの１形態であるフィールドテストを説明しています。フィールドテスト＝ベータテストのことです。アルファテストは、ベータテストの前に行います。アルファテストは開発側の環境で行い、ベータテストは顧客側の環境で実際のユーザーや将来の想定されるユーザーがテストします。
39 静的解析ツールで検出できないものはどれか。 [a] 定義される前の変数の参照 [b] 到達することのない、死んだコード [c] メモリリーク
[d] 配列の境界違反
正解 [c]
メモリリーク以外は、静的解析ツールで検出できます。メモリリークを検出するには動的解析ツールが必要です。
JSTQB テスト用
間違えた問題系
■テストタイプ
・機能テスト：「何をするのか」のテスト
・非機能テスト：「どのように動作するのか」のテスト
・構造テスト：構造をどの程度網羅したかのテスト
・回帰テスト：テスト済みのプログラムを何度もテスト
■仕様ベースのテスト設計技法の特徴
モデルから体系的にテストケースを作成する技法
■要件カバレッジ
テストカバレッジとしては仕様ベースのテスト設計技法
■テストサイクルモデル
テストレベルの分析や設計は開発作業の完了後に実施すべきではない。同時に行うことが望ましい
■モデルベースアプローチ
信頼度成長曲線などの故障率や使用法に関する統計的情報を使う確率的テスト
■テストケース実行のメトリクス
実行/未実行のテストケース数=テストケースの消化に関するメトリクス
合格/不合格のテストケース=欠陥密度に関するメトリクス
合格のテストケース数/未実行のテストケース数ではメトリクスが成立しない
----追記----
自分がまだきちんと理解していない箇所を記載
テストオラクル：テストにおいて、ソフトウェアの実際の結果と比較するための予想結果を決定するソース」と定義される。
テストハーネス：テストアイテムであるコンポーネントを実行するドライブ、そのコンポーネントが呼び出すほかのコンポーネントの代わりをするスタブで構成されている
テストウェア：ドキュメント、スクリプト、予想結果、セットアップやファイル、データベース、テスト環境、利用されるソフトウェアなどテスト計画、設計、実行が行われるテストプロセス中に生み出される成果物。テスト計画書、テストベース、テストケース、テストスイート、テスト手順、テスト環境などテストに関するすべての成果物を指している
テストケース仕様：テストケースを記述するドキュメントでアイテム群、入力定義、出力定義、環境要求、手順に関する特別な要求が含まれる
テストケース手順：テスト手順を記述したドキュメントで特別な要求、手順のステップが含まれます
テストレベル：一緒に編成されてマネジメントされるテストアクティビティの集まり、プロジェクトの責務と紐づく
テストタイプ：一つ以上の品質特性にテストの照準を合わせたテストアクティビティの集まり
テストフェーズ：プロジェクトマネジメントのフェーズでテストアクティビティの集まり
性能テスト：レスポンスの早さ、トランザクションの処理能力など性能のテスト
ロードテスト：同時に使用するユーザ数やトランザクション量を高めることによりコンポーネントやシステムの負荷を高め、その振る舞いのテスト
JSTQB 6章 テスト支援ツール
■テストツール
・テストツールは「テストのマネジメント」「テスト設計」「テスト実行」などテスト全般を支援するツールを指す
・テストツールには6つの大分類がある
- テストマネジメントの支援用ツール
- 静的テスト支援ツール
- テスト仕様の支援ツール
- テスト実行と結果記録の支援ツール
- 性能・モニタリング支援ツール
- 特定のテストに対する支援ツール
■テストマネジメントの支援用ツール
・テストマネジメントツール：テストプロセスのテスト計画、テストモニタリング、テストレポート、テストコントロールを支援する
・要件マネジメントツール：要求仕様を登録し、開発の優先順位、個々の要求の状況記録、要求仕様や要求一覧のレポート出力の機能を有する
・インシデントマネジメントツール：インシデントを登録し、対応する優先順位、個々のインシデントの状況記録、インシデントの内容やインシデント一覧のレポート出力の機能を有する。インシデントではなくバグや欠陥を対象としたバグトラッキングツールや欠陥追跡ツールもある
・構成管理ツール：製品に紐づく要求仕様書や設計書などのドキュメント、ソースコード、システムを構成するコンポーネント、データなどの構成要素を構成管理ツールのリポジトリに保管し、バージョン管理やトレーサビリティの維持をする
■静的テスト支援ツール
・レビューツール：レビュープロセスで行われるレビューの計画や進捗の記録、レビューでのコメントの記録や共有、レビューのチェックリストやガイドラインを提供する。レビューは静的テスト技法であるので、テストマネジメントの支援用ツールではなく静的テスト支援ツールに分類されている
・静的解析ツール：コーディング規約を遵守しているかチェックするツール、コンポーネントやWebサイトのリンク構造や依存関係を分析・チェックしビジュアルに表示をするツールなどが該当する
・モデリングツール：UMLモデリングツール、データモデリングツールなど設計でモデルの整合性をチェック・維持できる機能を有する
■テスト仕様の支援ツール
・テスト設計ツール：テストケースやテスト手順の設計を支援するツールを指し、テストアイテムの仕様からテストケース、入力データ、予想結果などテストケース仕様を生成できる機能を有する
・テストデータ準備ツール：データベース、ファイル、転送データなどテストで使用するテストデータを生成する
■テスト実行と結果記録の支援ツール
・テスト実行ツール：テストケースやテスト手順を登録し、テストを自動あるいは半自動で実行する。ユーザインターフェースのテストで操作手順を記録し、その操作を再現するようなツールをキャプチャプレイバックツールと呼ぶ
・ユニットテストフレームワークツール：テストハーネスを含むコンポーネントテストのためのフレームワークを提供する
・テスト比較ツール：ユーザインターフェースの振る舞いや、データベースのテーブル、ファイルなどのテスト結果を予想結果や以前のテスト結果と比較する
・カバレッジ測定ツール：プログラムを実行するとソースコードのどこの部分が実行され、どこの部分が実行されていないかを示してくれたり、カバレッジを表示する機能を有する
・セキュリティツール：Webサイトの開発であれば、想定されるサイバー攻撃を実際に行ったり、静的に解析し、脆弱性を測定する機能を有する
■性能・モニタリング支援ツール
・動的解析ツール：実際にプログラムを実行したときに発生するメモリリークや配列を超えた参照などを発見する機能を有する
・性能テストツール、ロードテストツール、ストレステストツール：非機能要求として要求されている使用条件を再現して、実行しているソフトウェアの動作をモニタリングし、レポートする機能を有する
・モニタリングツール：OSのログ、ヒープメモリなどシステムリソースの使用状況の推移、ディスクの空き容量の推移、ネットワークのトラフィックの推移など、OSが用意しているコマンドや、本番運用で使われる運用監視ソフト、ネットワークアナライザーなどが含まれる
■特定のテストに対する支援ツール
・データ品質評価：データが仕様通りで完全にそろっており、目的のデータにコンバージョンやマイグレーションが可能かを評価する
■プローブ効果
・テストツールによって、実行のタイミングや結果が実際と異なること
- 追記
■テスト自動ツールの説明
Script言語を使用してテストを自動実行する
■パイロットプロジェクトの目的
ツールの詳細仕様を学習する
JSTQB ５章 テストのマネジメント
■テストアプローチとテスト戦略
・テスト戦略：組織やプログラムなどプロジェクト横断的に立てた戦略
・テストアプローチ：テスト戦略を具体化して、プロジェクトに特化した戦略
・代表的なテストアプローチ
- 分析的アプローチ：リスクの高いところを分析し、そこを重点的にテストするリスクベースドテストなど
- モデルべースアプローチ：統計モデルなどに基づきテストを進めるテストアプローチ
- 方法論的アプローチ：テストや欠陥発見の方法論に基づいてテストを進めるアプローチ
- プロセス準拠アプローチ、標準準拠アプローチ：採用している開発プロセスや業界固有の標準に準拠してテストを進めるアプローチ
- 動的で経験則に基づいたアプローチ：テスト技術者が自分の経験に基づきテストを進めるアプローチ
- コンサルテーションベースのアプローチ：テストチーム以外の技術や業務のエキスパートのアドバイスやガイドラインに従ってテストを進めるアプローチ
- 回帰的アプローチ：回帰テストを積極的に効率的に行ってテストを進めるアプローチ
■テストマネジメントプロセスと厚生管理
・テスト実行中のマネジメント：テストモニタリング→テストレポート→テストコントロールで進められる
・テストモニタリング：消化したテストケース数、テストケースの合否結果など、スケジュールや予定コストとの比較などテストの進捗状況を調べる
・テストレポート：モニタリングした結果と評価を、テストサマリレポートにドキュメント化する
・テストコントロール：テスト報告をもとに、今後計画されているテストに対して是正を行う
・構成管理：プロジェクトや製品のライフサイクルの間に、ドキュメント、ソースコード、システムを構成するコンポーネント、データなどの構成要素を統合し、バージョン管理やトレーサビリティを維持する
■プロジェクトリストとプロダクトリスク
・プロジェクトリスク：プロジェクトのマネジメントやコントロールに関連するリスクのことで、プロジェクトがプロジェクト計画やテスト計画を遂行できないリスク
・プロダクトリスク：開発するソフトウェアやシステムに直接的に関連するリスクのことでソフトウェアが機能要求や非機能要求を満たしていないなど品質に関するリスク
■テストに必要な役割
・テストリーダ：テストマネージャやテストコーディネータとも呼ばれ、テスト計画やテストマネジメントプロセスに必要な作業や構成管理を用意する
・テスト担当者：テストリーダが立てたテスト計画に沿ってテストを準備、実行する
追記
■テスト計画
テスト計画書の概要
・テスト計画識別番号：文書番号
・はじめに：テスト目的や戦略、どうテストするか。参照する文献や関連する標準を記述
・テストアイテム：テスト対象のバージョン
・テストすべき機能：テストすべき機能をリストアップする
・テストしない機能：テストしない機能を列挙し理由を記述する
・アプローチ：どのようなアプローチでテストするか記述
・テストアイテムの合否判定基準：合否とテスト終了する基準を記述
・中止/再開基準：中止する基準、また再開する基準を記述
・テスト成果物：テストで作成するドキュメントをリストアップ。テスト計画書も含む
・テストのタスク：準備も含めて必要な作業を記述
・環境要件：テストを実施する環境について記述
・責任範囲：テストに関わる関係者との責任範囲を記述
・要員計画とトレーニング計画：テストに必要なスキル、要員計画を立てる
・スケジュール：テストのマイルストーンを記述
・リスクと対策：テストに関わるリスクと対策について記述
・承認：計画を承認する人の名前を記載
■テスト工数の見積もりの説明
作業の担当者が工数を見積もる
■欠陥情報
欠陥密度=欠陥の数÷プログラムの規模
■テストレポート
・テストサマリレポート識別番号：管理番号、管理対象のため、構成管理も行う
・要約：テストで行った作業全般の要約を掲載。簡潔にする
・変更：テスト計画立案後、テスト実行、終了までに発生した変更内容を記述
・総合評価：テスト作業自身の評価を記述。テスト計画に沿って行えたか分析する
・結果の要約：要約を記述、発見したインシデントについて解決、未解決について記述
・評価：全体の評価を記述
・承認：テスト活動に関わったすべての関連者を承認者として記載し、責任の所在を明確化する
■テスト構成管理の対象
・テスト対象となるソフトウェア
・動作環境
・テストウェア(データなど)
・欠陥
・テスト結果
・ドキュメント
■インシデントレポートの構成
・テストインシデントレポートの識別番号：文書番号
・概要：発生したインシデントを簡潔にまとめる
・詳細
ログの作成日付、作成した組織、作成者、承認、現在の状況
テストケース仕様のID番号など参照情報
期待した結果と実際の結果
異常
日時
実行手順
環境
再現手順
テスト担当者
オブザーバー
・影響範囲
インシデントの範囲、重要度、有千住に
ステークホルダーの利益に対してどの程度影響を与えるか
JSTQB 4章 テスト設計技法
■テスト設計技法
・仕様ベースのテスト設計技法：テストアイテムの仕様に基づいてテスト設計する技法
・構造ベースのテスト設計技法：仕様を実現したテストアイテムの内部構造に基づいてテスト設計する技法
・経験ベースのテスト設計技法：テスト担当者の経験に基づきテスト設計をする技法
・ブラックボックステスト設計技法：仕様ベースのテスト設計技法と同義である
・ホワイトボックステスト設計技法：構造ベースのテスト設計技法と同義である
■仕様ベースのテスト設計技法
・同値分割法：数値など入力データが取り得る値を仕様上同様に扱えるもの(同値クラス)に分けて、テストケース数を経た素テスト設計技法
・境界値分析：同値クラス間の境界からテストケースを導き出すテスト設計技法
・デシジョンテーブルテスト：テストアイテムのデシジョンテーブルに表されているルールからテストケースを導き出すテスト設計技法
・状態遷移テスト：テストアイテムの状態遷移図や状態遷移表からテストケースを導き出すテスト設計技法
・ユースケーステスト：ユースケースのシナリオを元にテストケースを導き出すテスト設計技法
■構造ベースのテスト設計技法
・ステートメントカバレッジ：ステートメントに着目し、ステートメントの実行をどの程度網羅できるかという観点でテストケースを作成するテスト設計技法。100％のテストが行われたとき、テストアイテムのすべてのステートメントが実行されたと言える。
・デシジョンカバレッジ：ブランチカバレッジと同義でプログラム内の分岐に着目し、分岐をどの程度網羅できるかという観点でテストケースを作成するテスト設計技法。デシジョンカバレッジが100％のテストが行われたとき、テストアイテムすべての分岐の論理式が真のとき、偽のときの両方が実行されると言える
■経験ベースのテスト設計技法
・エラー推測：ソフトウェア開発でありがちな誤りをテスト担当者が推測してテストケースを作成する技法
・探索的テスト：テストアイテムの仕様がなかったり不十分であるときに正しいであろう仕様を推測してテストケースを作成したり、テスト期間が限られているときに公式なテストと平行してテスト担当者の知識や経験でテストケースを作成するテスト設計技法である
---追加要素---
■テスト条件とテストケースの関係
テストケースはあるテスト条件を網羅するために設計したものである
■テスト実行スケジュールを策定する上で考慮すべき事項の組み合わせ
テストの目的に基づいた優先順位、回帰テストでテスト実行する内容
■テスト設計技法のカテゴリになるもの
・経験ベースのテスト設計技法、仕様ベースのテスト設計技法、構造ベースのテスト設計技法
JSTQB ３章 静的技法
■テスト技法
・動的テスト技法：実際にテストアイテムを実行してテストする。テストアイテムが要求仕様通りの結果にならないことやメモリリークの発見に向いている
・静的テスト技法：テストアイテムを実行することなくテストする。要求仕様の誤りや漏れやコーディング規約に沿ってないことの発見に向いている
・レビュー：レビューも静的テスト技法の1つである
■レビューの種類
・非公式レビュー：特に決まったやり方があるわけではない。レビューアの技法に大きく依存する
・ウォークスルー：シナリオに沿ってシナリオに含まれる関連するグループを机上で実行する。目的はソフトウェアの内容を学習、理解、欠陥を見つけること
・テクニカルレビュー：同僚や技術のエキスパートが参加し、あらかじめ定義されたプロセスで実施される。目的はディスカッションすること、判断を下すこと、ほかの方法を評価すること、欠陥を見つけること、技術的な問題を解決すること、仕様や規則に準拠していることをチェックすること
・インスペクション：インスペクションのプロセスは形式的に進められる。目的は、欠陥の発見だけでなく、プロセス改善を目的にする場合もある
■公式レビューの活動
・計画：役割へ担当者を割り当てて、レビュー対象範囲を決定する
・キックオフ：レビューの開催に先立って、参加者にレビュー対象のドキュメントを配布し、レビューの目的など概要を説明する
・個々の準備：レビュー対象のドキュメントについて議論したり、議論の結果を記録する。より公式なレビューでは、議事の結果や議事内容を議事録に残す
・再作業：修正することになった欠陥を修正する
・フォローアップ：欠陥が対処されたかを確認する
■レビューの必要な役割
・マネージャ：レビューに関するマネジメントを行う。実施するレビューの種類を決定し、それぞれの実施スケジュールを立て、レビューが適切に実施されているかを管理する
・モデレータ：担当したレビューを取り仕切り、推進する。レビューの成否はモデレータを担当する人の取り仕切りの上手・下手に拠る
・作成者：レビュー対象のドキュメントに責任を持つ人
・レビューア：ある特定の技術に詳しかったり、業務のバックグラウンドを持つ人で、レビュー対象の欠陥など気が付いたことを示したり、述べたりする
・書記：レビューで取り上げたすべての課題、問題点、未解決事項を議事録に記録する
---追加要素---
■ツールによる静的解析
コードそのものの欠陥検出、保守性の改善、学習効果による欠陥予防などの効果がある。ユーザビリティに対する指摘はツールでは不可
JSTQB 2章 ソフトウェアサイクルを通じてのテスト
・テストレベル、テストフェーズ、テストタイプ：ソフトウェアライフサイクルで行われテストを異なる観点でテスト分類した用語
・テストカバレッジ：テストアイテム内部構造に対して考えられるすべてのテストケースに対して実施するテストスイートやテストケースの網羅度のこと
■テストレベル
・テストレベル：開発プロセス、システムの規模、アーキテクチャ、テストタイプによって適切なテストレベルが定義され、プロジェクトマネジメントの計画を立てたり、進捗を測る単位
・コンポーネントテスト：分離してテストが可能な単位の欠陥を摘出し、正しく作動することを検証するテスト。プログラミングと合わせて実施することが多く、インシデントレポートを書かずにすぐに修正していくことが多い
・結合テスト：コンポーネント間のインターフェース、OS、ファイルシステム、ハードウェアなどシステムの異なる部分同士の相互処理、あるいはシステム間のインターフェースなどの検証するテスト。
・システムテスト：プロジェクトが開発したシステムが要求を実現できていることを確認するテスト。
たとえば、業務フローが要求された効率で正しく実行できるか検証する。
テスト環境は限りなく実際に使われる環境に近くなければならない。
・受け入れテスト：誰から誰が受けいれるかで4種類のテストがある
- ユーザ受け入れテスト：ユーザがシステムを受け入れる
- 運用受け入れテスト：システム運用部署がシステムを受け入れる
- 契約受け入れテスト、規定受け入れテスト：システム開発を依頼した側が契約に基づいてシステムを受け入れる
- アルファテスト、ベータテスト：テストケースを定義することなく自由に使ってもらい、テストカバレッジでカバーしていない範囲やテストできなかった非機能要求を評価する。
アルファテスト：開発組織の場所で実施されるが開発チームによって実施されない
ベータテスト：顧客あるいは潜在顧客の場所で彼ら自身がテストする
■テストフェーズ
・テストフェーズ：要求定義フェーズ、設計フェーズ、実装フェーズなどと同様にあくまで開発プロジェクトのフェーズである
・シーケンシャル開発モデルを採用しているプロジェクト：統合テストフェーズ、システムテストフェーズ、受け入れテストフェーズといったようにテストレベルとテストフェーズが1対1に対応することもある
・イテレーティブ-インクリメンタル開発も照すを採用しているプロジェクト：テストフェーズとテストレベルは対応していない
■テストタイプ
・テストタイプ：テストすべき要求の種類やソフトウェアの構造などでテストを分類したもの
・機能テスト：ブラックボックステスト。セキュリティテストや相互運用性テストは機能テストの一種
・非機能テスト：性能テスト、ロードテスト、ストレステスト、使用性テスト、保守性テスト、信頼性テスト、移植性テストがある
・構造テスト：テストアイテム内部の構造に着目して内部動作をテストする。ホワイトボックステスト。実際にテストアイテムを実行してテストするので先に機能テストを実施したほうがよい
・再テスト：確認テストと同義。判明した欠陥が正しく修正されたかを確認するテスト。
・回帰テスト：欠陥の修正によってその修正で新たな欠陥が生まれたり、顕在化していなかったほかの欠陥を検証するためにテストケースやテストスイートを繰り返し実行するテストのこと
----追加要素---
■コンポーネントテストの説明
性能テストなどの非機能テストを実施する
■統合テストの説明
テスト担当者は統合計画の構造や影響を理解すべき
■統合テストで用いるテストベース
■システムテストの説明
システムテストのスコープは、マスターテスト計画およびレベルテスト計画で定義される
■受け入れテストの説明
法律や安全基準などに合致しているかを検証するテストがある
■構造テスト
制御フローグラフを用いて、テスト設計を行う。このテストは構造テストの目的の為に行う
