プログラミングルール

プログラミング系の仕事を頂いた際の基本ルール。
若干コーディングルールと被るところもあります。

コーディング

コーディングルールについては、こちらをご確認ください

ソース仕様書

ソース仕様書(クラスの仕様書)は基本的にはコーディング側から自動作成させます。
指定がない限りはJavadoc形式です。

主に使用するJavadocタグ

@author 制作者
@version バージョン
@param 引数名 説明
@return 戻り値
@exception 例外クラス名 説明(発生条件等)
@deprecated 『推奨されない』ものであることに追加する説明
@see 関連項目(メソッドの指定でき、タグも使用可能)
@since 導入されたバージョン

デバッグ

  1. バグか否か見極め(入力間違いの場合もある)
  2. 原因特定する(入力値等操作・仕様上のミス・最近変更された場所等、発生条件)
  3. 修正する(問題と対象の処理の内容を理解は必要)
  4. 修正が正しいか検査
  5. 同じようなバグがないか確認

テスト

  • バグを見つける
  • 動作が正しいことを確認
  • 品質を評価する

テストとレビューの違い

テスト レビュー

メリット

  • 実際の処理結果が確認可能
  • 関係ハード/ソフトなどの関係を確認可能
  • 考え違いによる見落としがない
  • 設計の考慮もれを検出可能

デメリット

  • テスト条件作成が手間
  • バグがあろうと処理結果が正しく出る場合がある

メリット

  • バグ検出が経済的に可能
  • プログラム構造の良し悪しチェック
  • 冗長、無駄なロジックを検出
  • 同じ処理する箇所との比較が可能
  • 規約通りに作成か(使い方等)

デメリット

  • 意識しない機能漏れは検出しにくい
  • 見落としの可能性があり最終的な検証手段ではない

テスト種類

文章量が増えたので、詳細は分けました。

単体テスト(ユニットテスト)

モジュールまたはプログラム(単体)までのテスト。
モジュール間の結合テストを含む。
『ホワイトボックステスト』と『ブラックボックステスト』がある。

結合テスト

単体テストが終了したプログラムについて、プログラムを結合し、プロセス(利用者用処理)単位までのテスト。
このプロセスが外部システムとのインターフェイスを持つ場合は、プロセス間のインターフェイスのテスト含む。

システムテスト

実機上でシステム全体(性能・信頼性・運用性・セキュリティ等)のテスト・検証。

単体テストや結合テストでは補いきれない、使う側からの問題がある。

  • ソフトウェア導入時の問題
  • 機能の不足/欠落
  • 出力メッセージの不備
  • マニュアル

システムテストの観点

  • 機能性・運用性
  • 性能
  • 信頼性
    • 異常
    • 負荷
    • 耐久性
  • 操作性
  • 整合性・構成
  • 互換性
  • 保守性

テスト結果の評価

テスト終了判断を的確に行うために必要不可欠なテスト結果の評価方法。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です