CDUT方針 - hide003184/pubtest-dev GitHub Wiki

テスト選定基準

• コードカバレッジ（網羅性）は分岐網羅（C1）とする。但し、コード変更が発生しない単純ポーティングの場合、命令網羅（C0）とする。
• 単純ポーティングでもLinux化や64bitモード化に伴い、内部処理が変わるものについては分岐網羅（C1）とする。
• テスト実施方法は、以下の2パターンより選択する。
  • gdbデバッガによるホワイトボックステストの実施
  • ユニットテスティングフレームワーク（googletest）によるブラックボックステストの実施

gdbデバッガによる実施

• テスト対象コードに対して、ステップ実行を行い、処理通過前後での値の遷移確認を行う。
• テスト中の変数値を強制変更することでしかテスト対象処理の実現が困難な場合や、テストコードを整備することによる費用対効果が見込まれない場合等で利用する。

ユニットテスティングフレームワーク（googletest）による実施

• テスト対象関数に対して、その関数の振る舞いのパターンを網羅するテストケースを作成し、関数のインプットから想定しうるアウトプットを確認する。
• 関数の動作が内部設計の仕様と相違ないことを確認する。
• テストケースを全て実行することにより関数内の全ての処理を網羅することを確認する。命令網羅（C0）、分岐網羅（C1）を確認するための手段として、gccコンパイラのカバレッジ取得機能によりコードカバレッジを取得することでエビデンスとする。

開発環境

• 各担当者がそれぞれ構築したRHEL仮想マシン環境を利用し、開発を行う。
• gccコンパイラのメジャーバージョンはVer.8を使用する。

コーディングチェック

• 新規実装コードはコーディングルールに準拠していることを確認する。
• ワーニングリストから対応必須のワーニングが全て解消されていることを確認する。

CDウォークスルーレビュー

• コーディングチェック完了および、疎通検証によるコードカバレッジが30%以上（ウォークスルー依頼が出せるレベルのもの）であることを確認し、レビュアーに依頼する。
• 実装仕様に関する情報、ソースコード、疎通検証によるカバレッジ情報、課題懸案事項があれば確認ポイントを整理の上、ウォークスルーレビューを行う。
• ウォークスルーレビューでの指摘事項や課題懸案事項は、ExcelやBoxNotes等に記録し、他メンバーも参照可能な場所に配置する。

CDUTレビュー

• UT完了後、必要となる成果物を確認し、GitHubのPullRequestでレビュアーに依頼する。
• レビュアーは成果物を確認し、GitHubのレビュー機能で、承認（Approved）／非承認（Request Changes）／コメントのみ（Comment）の何れかを返す。

分類	成果物
CD	ビルド時に必要となる資材一式
CD	新旧DIFF結果
CD	ビルド結果ログ
CD	コンパイラバージョン確認ログ
CD	静的解析ツール結果
UT(googletest)	テストコード資材一式（スタブやドライバ等含む）
UT(googletest)	テストコード実行結果ログ
UT(googletest)	カバレッジ計測結果
UT(gdb)	端末操作ログ
UT(gdb)	IN/OUTデータ（環境変数や外部ファイル等）
UT(gdb)	カバレッジ計測結果