（）：データの流れを確認するテスト 変数が正しく定義、利用、（）されているか確認する

メトリクスの測定 メトリクス：（） 例）ソースコードだと、行数、分岐数、など （）：コードの複雑さの指標の一つ 制御フローから求められる

レビュー技術について レビューの目的 レビューに参加するメンバによってレビュー対象の（）を検出すること 長所例）対象がコードに限定されない 短所例）厳密な網羅的な確認には不向き

実装で作成されるものの例

サイクロマティック複雑度は 矢印の数　− （）　+ 2 で求めることができる つまり（）やループが多いほど複雑なソースコードになる

検証と妥当性確認の違いについて 検証：（）の確認 妥当性確認：（）が開発目的に合っているか確認

テストは段階的に行われている ①受け入れテスト-（）が主な目的となる ②システムテスト-（）をテストする -機能仕様や、（）を満たすか確認する ③統合テスト-単体テストを通過した対象に対して実際に（）テストをする ④単体テスト-（）をテストする テスト対象の外についての代替が必要 （）：テスト対象を呼び出す部分 （）：テスト対象から呼び出される部分 これは④から①に向かって行われる

バージョン管理について プログラムのについて（）に戻したくなる場合がある 複数人で編集する場合には（）が衝突することがある

ホワイトボックステストについて（構造テスト） システムの内部構造を見て（）面・（）面の確認を行うテスト

デグレードとは何か

バージョン管理 バージョンの重要性について ①デグレードからの回復：（）で比較して、原因を分析できる ②派生開発：特定のバージョンから、別の進化をさせることができる ③ファイルの紛失防止：Gitのような仕組みならば誤削除から復旧できる

成果物の確認技術 二つ答えよ

継続的インテグレーションについて プログラム作成 ⇩ （） ⇩ デプロイ ⇩ テストでまだプログラム作成に戻る これを（）するツールが存在する

動作が同様とみなされる入力値集合

ブランチについて あるバージョンをもとにした時の（）の事 マージについて ブランチで分かれて開発していたバージョンを（）する事 マージ時に重複する修正がある場合は（）と呼ばれる

バージョン管理について 様々なバージョンの（）が作られている （機能拡張・（）・類似した製品群など） 一旦作られたソフトウェアは（）な形で管理する

コーディング規約遵守の確認 （）を定める 読みやすさや、（）を効率化し、（）の混入を低減できる

制御フローテストについて （）に基づき、カバレッジ基準に従ってテスト設計する カバレッジ基準-テストで（）したいアイテム要素のこと カバレッジを100%にすることが目標

デバッグのコツは ①状況を的確に（）する （）やトレースを読んで理解を試みる ②状況を把握する（）を作る 変数や、（）を取り出す仕組みを作る ③問題の簡略化 大量のデータ、（）だと、原因を探す難易度が上がる （）などデータを徐々に小さくするなど問題範囲を絞り込む 作業のどの時点で問題が（）発生したかをおもいだす

ソフトウェアの欠陥について 欠陥：要求された機能などが果たせなくなるような（）またはシステム中の不備 フォールト：欠陥とほぼ同義だが、（）のみを指すことがある （）：間違った結果をもたらす人間の行為 故障：コンポーネントやシステムが、期待した機能，（），結果を提供できないこと

妥当性確認とは （）や目的に対する要求が達成されているかどうかを、（）を用意して確認する事

成果物確認の技術 （）：ツールなどを用いて、成果物を実行せずに解析する方法 （）：数理論理学に基づいて検証を行うための方法の総称

オープンソースソフトウェアについて （）条件で公開されたソフトウェアのこと 勝手にコピー・（）できないあくまで著作権に守られている 無償だが品質が低いとも限らない

リリースしたソフトウェアの通し番号

ソフトウェアと実行環境について ⑤（）-PCでプログラムを書いてコンパイルし、ターゲット上で動かす （）ではOSも含めてビルドし、書き込むことがある

テスト技術について テストの目的は、実際に動作させて（）を発見 テストケースはテストのために作られた（）、実行条件、期待される出力値の組みのこと （）はテストケースをまとめたもの

デバッグとは何か プログラム中の（）を検出して、（）を特定し、修正する作業

検証とは 開発のあるフェーズで作られた（）がそのフェーズの開発当初の（）や（）を満たしているかどうかを評価する活動

実装に関わる技術 プログラミング支援について コーディングを行う、エディタが（）になってきている 例）キーボードの自動補完 （）-エディタだけでなく、ビルドや（）も機能として提供

境界値分析について 同値クラスの（）に基づいて（）する方法 （）の条件式の誤りに気がつくために有効

複合条件網羅 全ての条件式の（）を網羅すると100%になる

実装に関わる作業 実行可能なソフトウェアの構築 プログラミングの場合は コンパイル・リンクを行い、（）を得る 実行環境の設定と配置 設定はハードウェア・OS・ミドルウェア・フレームネットワークを設定 配置は（）する

構造の解析 制御フロー解析について ①プログラム中の命令の（） ②（）の呼び出し順序 データフロー解析について 変数がどのような命令で変更されるかなど（）を確認する

ブラックボックステスト（機能テスト）について システムの（）を見ずに、機能面・非機能面の確認を行うテスト 例）同値分割法

機械的な作業の例として （）がかかる上に間違いが混入することもある このような時、（）して、特定のディレクトリに置く。そして、（）して、一コマンドで（）する

同値分割法について 入力値を（①）に分割し、（）ごとの代表値を最低一回与える （）で正しければ同じ（①）は全て正しく動作する前提

静的解析技術について （）がないか、望ましい（）になっているか、望ましい（）になっているか、修正や拡張に適した形か レビュー前に静的解析をすると、（）出なければならないことに注力できる

ソフトウェアと実行環境について ①基本的な形態は （）をコンパイルし、実行する 例）計算機上で実行形式ファイルを動かす ②アプリケーションフレームワークの利用は よく使われる（）や、（）などがあらかじめ用意されている ゼロから作らなくていいため、効率がいい

ビルド作業と依存関係について たくさん実行しまくるとキリがなくて大変なので、 （）や依存関係（必要なファイルの関係）を定義しておき、（）する 例）makeコマンドなどで自動的に（）できる

実装に関わる課題で プログラムの作成では （）を正しく解釈し、実装技術を理解している必要がある

デバッグの作業について 不具合の発見・ソフトウェアが期待した動作をしないことで不具合の発言が疑われる 不具合の再現・（）条件を特定する 原因の特定・条件をもとに（）を見つける 原因の解決・（）を行う 確認・（）の解決を確認し、副作用を確認する

テストタイプについて ・機能テスト 機能が仕様通りに（）されているか確認 ・非機能テスト （）、負荷テスト、信頼性など ・構造テスト テストの（）を図る ・変更に伴うテスト 変更によって（）が除去されているか （）を起こしていないか

レビューの種類について （）：管理者がレビューする 技術レビュー：（）をできるメンバーで実施する （）：仕様や標準からの逸脱などの欠陥を検出する （）：設計者やプログラマが成果物を説明し、参加者が質疑・コメントを実施する

依存関係の管理 プログラムで言えば、（）が必要なファイルを把握する必要があるこれは（）が発生することがある このようなことを防ぐためには、（）するべき

命令網羅について（Ｃ0カバレッジ） 全ての（）を網羅するとカバレッジは100%になる 処理の手順は（）のようになる 分岐網羅（C 1カバレッジ）について 全ての（）を網羅するとカバレッジは100%になる 全ての（）を通ればいいので、どう通るのかは重要ではない

テストの特性 何を全て確認することはできないか テストで（）が見つからなかったとはいえ、（）がないとは言い切れない

他のブラックボックステストについて （）-決定表と呼ばれる条件と期待される結果のくみに基づくテスト手法 （）-状態遷移モデルで定義された状態遷移が実現されてるかどうか （）-ユースケース記述に基づきテストする

バージョン管理-ソフトウェアは（）に基づいて開発されることが多い バージョン管理は（）で表される

実装について 設計の結果をもとに、実際に（）なソフトウェアを構築し、このソフトウェアの（）を設定する作業

検証と妥当性について 成果物の確認は（）と（）からなる （）と（）をなんというか

ソフトウェアと実行環境について ③分散システム （）に（）できるように構築しなければならない、（）する先が増えるため、複雑になる ④仮想化環境・クラウドについて 仮想化は、（）などがCPUコア数やメモリのリソースが充実した計算機が存在する前提 -１つの計算機の中に仮想的な計算機を作る -１つでやると大変、 （）-仮想化は、自身でサーバを組むイメージ -（）は状況によって、CPUやメモリなどのリソースを柔軟かつ迅速に提供できる