開発・単体テスト工程の成果物作成要領を記す。
# | 成果物名 | 作成要領 | サンプル |
---|---|---|---|
1 | ソースコード/ 設定ファイル |
プログラミングの基本については別ページの参考サイトを参照。
・事前準備 ・用語/コーディング規約を確認する。用語は基本設計書で確認し、 ・用語(クラス、メソッド、変数)を統一する <静的解析ツールが検知することが得意な問題> ・コーディング(先行開発・プロトタイピング) |
– |
2 | 単体テスト仕様書 | ・テスト計画に即して、テストケースを作成する。 <テストケース作成の観点> ・ホワイトボックステスト(コードカバレッジ) 費用対効果を考慮して、どのレベルまでカバレッジをあげるかを決定する。 結合テストで全機能をテストできる等、他のテストとの組み合わせでテストの ケース密度を高められるのであれば、ホワイトボックステストにおける カバレッジは高ければ高いほど良いというわけではない。 現実的には、下記のC1網羅が妥当なケースが多いと考えられる。 <制御パステストにおけるテストカバレッジ> ・C0網羅(命令網羅) 処理経路を構成するすべての命令を最低1回実行する ・C1網羅(分岐網羅) すべての条件分岐の真と偽の両方を最低1回テストする ・C2網羅(条件網羅) 条件分岐の真と偽のすべての組み合わせをテストする ・ブラックボックステスト(有効値と無効値) ・同値分割 テストの入力値を有効値の集合と無効値の集合に分けて、それぞれの 集合から代表値を選んでテストする。 設計仕様をもとに、データを意味のあるグループ(同値クラス)に分類し、 各グループから代表値を選ぶテスト技法。 これにより、冗長なテストケースを省くことができる。 例)1から5の製品評価データ(1が最低値、5が最高値) A. 0以下:無効値 B. 1-5 :有効値 C. 6以上:無効値 上記のA. B. C. のそれぞれのグループから1つずつ 代表値を選出してテストする。 ・境界値分析 上記の例で示したA.とC.のグループの間の境界値を選択する。 A.の境界値 0 1 C.の境界値 5 6 このテストの実施により、境界値に関する設計ミスや記載ミスを 早期に検知しやすくなる。 ・オブジェクト解放確認(メモリリーク防止) ・オブジェクト指向プログラムで構造体をnewで生成した後に 解放し忘れていないかチェックする。 ・DBのコネクションをオープンし、トランザクション処理を終えた後に 不用意にコネクションがオープンのまま放置されている処理がないか 確認する。 ・コード単体のパフォーマンステスト ・プログラム内部のループ処理を多重実行しているような場合には プログラムの記述の仕方によって処理速度が大幅に低下することがある。 このような問題を避けるために、例えば、ループ外に記述できる演算を ループの内部に記述していないか、また、if文ではなくswich文で 記述した方が高速化できないか等を確認する。 |
– |
3 | テストデータ | ・単体テストケースに必要なデータを作成する。 ブラックボックステストのデータはできる限り実際の業務データに近い値を 用意した方が良い。そうすることで、後続のテスト工程で不具合が検知され、 上流工程の設計者に単体テストの結果の確認を依頼する場合に、問題点の 発見を早めることにつながる。 実際の業務に近いデータというのは、データを見ただけで何の情報かわかる |
– |
4 | テストツール | ・テスト計画、プロトタイピングで計画/構築したテストツール(xUnit系のツールや カスタムツール)を利用する。 テストツールの導入箇所として考えられるのは下記の3か所 ・テスト準備(テストデータの作成) ・テスト実行 ・テスト検証(整合性判断・エビデンスの作成) |
– |
5 | 単体テストエビデンス | ・エビデンスを取得する 単体テストのエビデンス取得は自動化を推奨する。 エビデンスを取得してもプロジェクトやシステムの品質を直接高めることは エビデンスが品質を直接高めることがないとはいえ、必要ないとも言えない。 ・単体テストのエビデンスはレビュー者が見てわかる記述にする 例えば、テスト結果に「false」という記載があるが、実は「false」が正しい結果 |
– |