| E）開発・単体テスト　成果物作成要領

E）開発・単体テスト　成果物作成要領

Home » エンタープライズアプリケーション開発 » E）開発・単体テスト　成果物作成要領

開発・単体テスト工程の成果物作成要領を記す。

#	成果物名	作成要領	ｻﾝﾌﾟﾙ
1	ソースコード／設定ファイル	プログラミングの基本については別ページの参考サイトを参照。・事前準備　・用語／コーディング規約を確認する。用語は基本設計書で確認し、　　コーディング規約も確認する。以下に特に主だった点を記載する。　　・用語（クラス、メソッド、変数）は意味のあるものにする　　　・クラス名：役割が分かるもの　　　・メソッド名：機能が分かるもの　　　・変数：内容の意味が分かるもの　　・用語（クラス、メソッド、変数）を統一する　　　・同じ役割を持ったクラス名・メソッド名は同じ名前にする。　　　　例えば共通関数として用意された登録処理を使う２つのメソッドが　　　　registerAAAとsetBBBのように、二つの異なる命名をしていると、　　　　同じ機能であることが分かりにくい。このような混乱の元になる因子は　　　　極力取り除くために、用語は統一することが望ましい。　　　・コーディング規約のチェックに静的解析ツールを利用する　　　ソースコードの品質を上げるためにレビューをすることは重要なことだが、　　　形式的なミスを直すためにレビューアの負荷が高まることは望ましいこと　　　ではない。　　　（もとよりそのような作業は開発者が好き好んでやる作業ではない）　　　静的解析ツール（Checkstyle等）はコードの可読性に関する問題を検知　　　することに向いたツールであり、導入した方が良い。　　　＜静的解析ツールが検知することが得意な問題＞　　　・命名規約違反　　　・インデントなど書式の問題　　　・エラーが発生しやすいパターン　　　・構成管理のルールを確認する　　・プロジェクト毎に構成管理ツール（Subversion等）の利用方法を決めて、　　　デグレードが発生しないように運用方法を開発者間でルールについて　　　話し合い、同じ手順で作業を実施しているか確認する。　　　特に、新規参加の開発者がいる場合は、開発チームのリーダーが　　　直接開発者本人が実施している手順を確認することも重要。　　・ソースコードへのコメントの残し方に気を配る　　　・コメントアウトしたソースコードをむやみにコメント行内に残さないように　　　　する。　　　　可読性が下がり、レビュー者の負担を増すことにつながるため。　　　・開発中に発生したバグの改修に関するコメントをソースコード内に残さずに、　　　　構成管理ツールへのコミット時にコメントを残す形で管理することを　　　　検討する。　　　　これは、ソースコードに直接書くよりも、改修履歴の管理がしやすくなる　　　　ため。　・コーディング（先行開発・プロトタイピング）　　アプリケーションの開発が円滑に進むようにするためには、アーキテクチャ　　（アプリケーション構造）の実装や共通機能の開発は、アプリケーションの　　本開発に先だって実施する必要がある。　　　　・プロトタイピングのポイント　　　・アプリケーションの基本的な構造（アーキテクチャ）をプロトタイピングの　　　　中で固める。　　　・共通機能もプロトタイピングとして他の機能より先行して実装する。　　　・プロトタイピングを通じて、ものづくりの型を決めてアプリケーション機能の　　　　量産の準備を整える。　　　・安全かつ効率的にプロトタイピングを進めるためには、社内外の過去の開発の　　　　経験・ナレッジから流用可能なものは取り込むことは有効。　　　　既知のパターンでは対応しきれないものは、新規の技法で対応することを　　　　検討する。　　　・フレームワークや自動生成ツールを検証する。　　　　プロトタイピングを通して、アプリケーションフレームワークや　　　　自動生成ツールの特徴を押さえる。　　　　・フレームワークの基本的な動作を確認する。　　　　　永続化（O/Rマッピング、任意のSQLの使用方法）、セッション管理、　　　　　トランザクション管理、アプリケーション外部からのアクセス／動作、等の　　　　　基本的な要素は全て確認することが望ましい。　　　　・フレームワークの制約が共通機能の実装を制約しないか確認する。　　　　　例：SpringFrameworkは、interfaceで定義したメソッドしか、AOPの対象に　　　　　　　できない。　　　　　　　　→interfaceにメソッドをあらかじめ用意しておく必要がある。　　　　・自動生成ツールの制約がプロジェクトで作成した命名規約や　　　　　コーディング規約と整合性が取れているか。　　　・プロトタイピングで実装した機能をカタログ化する。　　　　アーキテクチャ、共通機能開発がクラス図やシーケンス図等の形で　　　　デザインパターン化したら、それらの情報を整理してカタログ化し、　　　　あわせてサンプルプログラムを用意する。　　　　　・開発者への周知　　　・上記にてこれまでに記載した、用語・規約の統一、構成管理のルール順守、　　　　プロトタイピングの結果（カタログ資料）を開発者へ周知する。　　　　開発規模が大きくなる場合は、勉強会を開催して全メンバーに共有する。　　　・周知後に、共通関数等にアプリケーション開発者から変更や追加対応の　　　　依頼が来ることを見越して、それらの申請手続きを取り決めておくことも　　　　必要。　　　・コーディング（アプリケーション本開発）　・実装　　・設計書の記載にしたがってコーディングを実施し、コンパイルエラーを　　　取り除く。　　・オブジェクト解放の処理が漏れていてメモリリークの元になるようなことが　　　ないか確認する。　　・コーディング規約に違反していないかプログラマー自身で確認を行う。　　　（この作業を効率的に行うために、静的解析ツールの導入が役に立つ）　　・ファイルの文字コードがプロジェクトで規定した規格になっているか確認する。　　・ソースコードレビュー　　・ソースコードの可読性をチェックする　　　まず、ソースコードが用語の統一、その他のコーディング規約に即しているか　　　をチェックする。　　　用語の統一に関しては、一部はツールが機械的にチェックできるが　　　（Camel形式のチェック等）、業務用語に即した名前になっているか等は　　　開発者の言葉の知識やセンスを駆使する必要がある。　　・設計書通りに実装できているかチェックする。　　　正常系／異常系の処理が正しく実装されているか確認する。　　・（プロジェクトで決められた）デザインパターンを守ってプログラムが　　　かかれているかチェックする。　　・フレームワークやクラスライブラリを正しく使っているかチェックする。	–
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	単体テストエビデンス	・エビデンスを取得する　単体テストのエビデンス取得は自動化を推奨する。　エビデンスを取得してもプロジェクトやシステムの品質を直接高めることは　出来ないが、エビデンスを取得する目的は、以下のようなものである。　・テスト担当者が単体テストを行ったことを証明する　・レビュー担当者が単体テストの結果をチェックする際に使用する　・結合テスト等の後続工程で不具合が発生した際の分析に使用する　　エビデンスが品質を直接高めることがないとはいえ、必要ないとも言えない。　　そのため、エビデンスの取得は自動化した方が良い。　　＜エビデンス取得自動化の例＞　　　・テスト結果を自動でファイルに出力するテストツールを作成する。　　　・xUnit系のツールであれば、テスト結果を用意に再現できるので　　　　エビデンスは不要とする。・単体テストのエビデンスはレビュー者が見てわかる記述にする　上記の通り、エビデンスはレビュー者やその後の分析用に作成するものであり、　開発／単体テスト実施者自身が内容を分かれば良いというものではなく、　レビュー者やその他の確認者が見てわかるものでなければ必要十分とは言えない。　例えば、テスト結果に「false」という記載があるが、実は「false」が正しい結果　なのであれば、「falseであるがテスト結果としては正しい」という記載が必要。	–