AS400保守の単体テストとは？RPG/CL修正後に確認すべき観点を現場目線で解説

AS400（IBM i）でRPGやCLを修正した後、コンパイルが通っただけで安心してはいけません。次に必要なのが単体テストです。

単体テストは、修正したプログラムが仕様通りに動くかを確認する作業です。基本的な動き、入力値、作成されるデータ、帳票、外部に出ていくデータまで、修正範囲に応じて確認します。

この記事では、販売管理システムの保守に25年以上関わってきた現場目線で、AS400保守の単体テストで何を見るべきかを整理します。

単体テストで最初に確認すること

RPGやCLを修正した後、単体テストで最初に確認するのは、仕様通りに動作するかです。まずは基本的な動きが正しいかを見ます。

たとえば、入力した内容が正しく処理されるか、予定したファイルにデータが作成されるか、帳票や外部連携データが想定通りに出るかを確認します。

ここで大事なのは、いきなり細かい異常系ばかり見ないことです。まず正常な入力で、性善説の動きが正しく成立するかを確認します。その後に、異常系や境界値の確認へ進みます。

確認順	見る内容	現場での目的
1	基本動作	仕様通りに処理が流れるか確認する
2	入力結果	画面入力やパラメータが正しく処理されるか見る
3	DB更新	作成・更新・削除されるデータが正しいか確認する
4	帳票・外部出力	外に出る情報が正しいか確認する
5	ジョブログ	実行時エラーや警告が残っていないか見る

フル桁入力は必ず見る

単体テストで見落とすと危ない確認のひとつが、フル桁入力です。

通常の短い値では問題なく動いても、項目の最大桁数まで入力した時に、表示崩れ、桁あふれ、編集エラー、帳票の文字切れ、外部連携データの不整合が出ることがあります。

AS400の販売管理システムでは、商品コード、得意先コード、数量、単価、金額、伝票番号、外部連携キーなど、桁数が重要な項目が多いです。ここを軽く見ると、後工程で面倒な不具合になります。

項目例	フル桁で見る理由
商品コード	検索、帳票、外部連携キーで使われやすい
得意先コード	請求、出荷、売上計上に影響する
数量	桁あふれや計算結果の不整合を見つけやすい
単価・金額	端数、税込計算、合計金額のズレが出やすい
伝票番号	帳票、照会、外部I/Fの参照キーになりやすい

販売管理システムで重点的に見るデータ

販売管理システムの単体テストでは、基本的に全部見ます。特に入力系、データ作成系は重点的にチェックします。

画面上の結果だけで判断すると危ないです。裏側で作成されるファイル、更新されるレコード、外部に出ていく帳票や連携データまで確認します。

販売管理では、受注、出荷、在庫引当、売上計上、請求、店舗連携、物流連携などがつながっています。ひとつの修正が後続処理に影響することがあります。

分類	単体テストで見ること
入力系	入力値、必須チェック、桁数、コード存在チェック
データ作成系	追加レコード、更新レコード、キー項目、ステータス
帳票	出力内容、改ページ、文字切れ、金額、明細順
外部I/F	CSV、送受信ファイル、連携キー、データ形式
後続処理	次のバッチや照会画面で正しく使えるか

データ件数を増やした確認も必要

基本動作が確認できたら、データ件数を増やして確認します。件数が少ない時だけ動くプログラムは、現場では使い物になりません。

件数を増やすと、処理時間、配列数、ページング、帳票の改ページ、ファイルアクセスの負荷などが見えてきます。

特にRPGでは、配列の件数不足が後になって問題になることがあります。普段は少ない件数で動いていても、いつか配列数を超えるデータが入った時にアベンドすることがあります。

件数を増やして見る例
・明細1件
・明細10件
・明細100件
・帳票の改ページが発生する件数
・配列の上限に近い件数
・外部I/Fで大きめのCSVを出す件数

テストデータの作り方

テスト環境にある程度データが揃っていれば、既存データを使います。既存データを使うと、実際の業務に近い状態で確認できます。

データが無い場合は、DFUで作ることもあります。最近はCodexにテストデータを作らせることも増えています。

Codexを使うと、入力データのパターン出しが楽です。正常系、フル桁、件数増加、外部連携用CSVなど、テスト観点に沿ってデータ案を出してもらえます。ただし、本番データや顧客情報をそのまま渡してはいけません。

作り方	向いている場面	注意点
既存テストデータ	テスト環境に業務データがある時	古い状態や前提条件を確認する
DFU	少量のデータを直接作る時	入力ミスに注意する
SQL	複数件をまとめて作る時	ライブラリ名と更新先を確認する
Codex	パターンを洗い出したい時	機密情報を渡さず、匿名化した前提で使う

正常系を先に見る理由

正常系と異常系のどちらを重視するかと聞かれたら、私はまず正常系を重視します。

理由は、通常の業務フローが仕様通りに動かない状態で、異常系だけ細かく見ても意味が薄いからです。まずは通常の入力、通常のデータ、通常の処理順で正しく動くことを確認します。

正常系が通ったら、次に異常系を見ます。未入力、桁あふれ、存在しないコード、想定外の件数、ファイルロック、権限不足などを確認します。

1. 正常な入力で基本動作を見る
2. 作成・更新されたDBを確認する
3. 帳票や外部出力を確認する
4. フル桁入力や件数増加を確認する
5. 異常系、境界値、エラー時の動きを確認する

単体テスト後のエビデンス

単体テスト後のエビデンスは、画面スクショを残すことが多いです。DB更新が絡む場合は、Excelに更新内容を貼り付けます。

エビデンスは、ただ残せばよいわけではありません。あとで見た時に、何を入力して、何が更新されて、何が正しいと判断したのかが分かるようにします。

エビデンス	残す理由
画面スクショ	入力値や表示結果を確認できる
DB更新前後	どのレコードがどう変わったか分かる
帳票・スプール	外部に出る情報を確認できる
ジョブログ	実行時のエラーや警告を追える
Excel	テストケースと結果を整理しやすい

スプールやジョブログの確認は、WRKJOBとDSPJOBLOGの使い方も参考にしてください。

Codexに単体テストを手伝わせるなら

Codexに単体テストを手伝わせるなら、インプットデータの作成、プログラムの実行、アウトプットデータの検証まで、一連の動作確認を任せたいです。

たとえば、テスト観点を渡して、入力データのパターンを作らせる。実行後に出力データやCSVを比較させる。DB更新前後の差分を整理させる。こういう作業は相性が良いです。

Codexに依頼する例
TEST001Rの単体テスト観点を作ってください。
確認対象は以下です。
・正常系
・フル桁入力
・データ件数増加
・DB更新前後の比較
・帳票出力
・外部I/F用CSV
・ジョブログ確認
・エビデンスに残す項目

ただし、最終判断は人間です。Codexが作ったテストデータや検証結果でも、業務仕様に合っているか、販売管理の流れに合っているかは人間が確認します。Codexの活用方針は、AS400保守でCodexはどこまで使えるのかでも整理しています。

若手に伝えたいこと

若手に単体テストでこれだけは守れと言うなら、単体テストは手を抜くなです。

ここで見落としがあって、システムテスト段階で単体レベルの不具合が出ると、かなりみっともないです。何をやっていたんだ、という話になります。

単体テストは地味ですが、品質の土台です。コンパイルが通った、画面が出た、だけで終わらせず、入力、DB、帳票、外部I/F、ジョブログ、エビデンスまで見ます。

次に読む記事

• AS400のコンパイルリストの読み方
• AS400のWRKJOBとDSPJOBLOGの使い方
• AS400のジョブログ確認手順
• AS400のデータリカバリーで焦らないための確認手順
• AS400の本番対応で初心者がやってはいけないこと

単体テストのエビデンスで見る画面

単体テストでは、画面の動きだけでなく、DB更新結果やスプール出力も確認します。DSPPFMでデータを見て、WRKSPLFで帳票やジョブログを確認すると、エビデンスとして残しやすくなります。

単体テストで使う画面を深掘りする

単体テストでは、DB更新結果を見るDSPPFMと、帳票・ジョブログ・コンパイルリストを見るWRKSPLFがよく出てきます。画面ごとの詳しい見方は、DSPFFDとDSPPFMの使い分け、WRKSPLFの基本を参考にしてください。

単体テストの合格ラインは「設計書どおりに動くこと」

RPGやCLを修正した後の単体テストで、最低限ここまで見ればよいと考える合格ラインは、詳細設計書に書いてある仕様どおりに動くことです。画面入力、DB更新、帳票出力、後続処理に渡すデータなど、修正対象に関係するパターンを実行し、期待した結果になっていれば合格と判断します。

逆に、コンパイルが通っただけでは単体テスト完了とは言えません。AS400の保守では、コンパイルエラーがなくても、入力値の組み合わせ、既存データの状態、後続処理とのつながりで不具合が出ることがあります。特に販売管理システムでは、入力系の処理が後続の出荷、在庫引当、売上計上、請求などの元ネタになるため、入力時点の確認を軽く見ると影響が大きくなります。

フル桁入力は数量・金額・名称で必ず見る

単体テストで見落としやすいのが、フル桁入力です。数字項目であれば数量や金額に最大桁数の値を入れます。文字項目であれば名称や摘要のような項目に最大桁数の文字を入れます。普段の短い値では正常に見えても、最大桁数で表示崩れ、編集エラー、帳票の桁あふれ、DB更新時の不整合が出ることがあります。

確認する項目	テスト観点	現場で見る理由
数量	最大桁数、ゼロ、境界値	在庫引当や出荷数に影響するため
金額	最大桁数、丸め、編集表示	売上、請求、帳票に影響するため
名称	最大桁数、全角文字、表示切れ	画面、帳票、外部連携で崩れやすいため
コード	最大桁数、存在しない値、先頭ゼロ	マスタ参照や後続処理の分岐に影響するため

既存テストデータは便利だが、ゴミデータに注意する

テスト環境に既存データがある場合、そのまま使えることも多いです。ただし、変な動きをしたときに調査すると、過去の不具合で発生したゴミデータが原因だった、ということもあります。本来は定期的に不要データを整理した方がよいですが、現場では日々の作業に追われて、そこまで手が回っていないことも多いです。

既存データを使う場合は、「このデータは今回の仕様確認に使ってよいデータなのか」を意識します。過去のテストで中途半端に残ったデータを使うと、プログラムの不具合なのか、データの不整合なのかが分かりにくくなります。単体テストで時間を失わないためにも、入力前の状態と実行後の状態を分けて確認することが大事です。

Codexにテストデータを作らせる時は、指示を明確にする

Codexにテストデータ作成を手伝わせる場合は、曖昧な依頼ではなく、明確な条件を渡すことが重要です。人間相手なら雰囲気で伝わることもありますが、AI相手では、対象ファイル、項目、桁数、正常系、異常系、フル桁、件数、期待結果を具体的に伝えた方が精度が上がります。

TESTLIBの受注明細ファイルを想定して、単体テスト用データを作ってください。
確認したい観点は、正常系、数量最大桁、金額最大桁、名称最大桁、存在しない商品コード、ゼロ数量です。
各パターンについて、入力値、期待する処理結果、確認するDB項目を表にしてください。

大事なのは、AIが作ったテストデータをそのまま正解にしないことです。最終的に見るのは人間です。AS400の環境、ライブラリ、ファイル定義、業務仕様に合っているかを確認してから使います。

エビデンスより、修正後の再テストが大事

単体テストでは、教科書どおりに言えばエビデンスを残すことが大事です。画面スクショ、DB更新結果、帳票、ジョブログなどを残すことで、後から確認しやすくなります。ただし、現場では都合のよいエビデンスだけを作って「OK」にしてしまう人もいます。だからこそ、最後は実際に動作確認して、結果が仕様どおりかを見ることが重要です。

特に危ないのは、エビデンスを取った後にプログラムを修正して、そのまま再テストしないことです。過去に、エビデンスどおりに動かないため調査したところ、エビデンス取得後に勝手にプログラム修正が入っていた、というケースがありました。プログラムを直したら、必ず再テストし、必要なエビデンスも取り直すべきです。

危ない行動	なぜ危ないか	守ること
コンパイル後に動かさない	仕様どおり動く保証がない	正常系から実行して確認する
短い値だけで確認する	桁あふれや表示崩れを見落とす	数量、金額、名称はフル桁も見る
エビデンス取得後に修正する	証跡と実プログラムが一致しない	修正したら再テストする
既存データを疑わない	ゴミデータで原因調査がぶれる	入力前後の状態を確認する

若手に伝えたいこと：単体テストは手を抜くな

若手に一番伝えたいのは、単体テストは手を抜くな、ということです。単体テストで見落とした不具合がシステムテスト段階で出ると、かなりみっともないです。「何を確認していたのか」という話になります。特にAS400の販売管理システムでは、入力系の不具合が後続処理に広がるため、小さな確認漏れが大きな手戻りになります。

単体テストは、ただチェックリストを埋める作業ではありません。修正した処理が仕様どおりに動き、後続処理に正しいデータを渡し、本番に出しても恥ずかしくない状態にするための作業です。Codexを使ってテストデータ作成や観点整理を効率化するのは有効ですが、最後に責任を持って判断するのは人間です。

まとめ

AS400保守の単体テストでは、まず仕様通りに基本動作するかを確認します。そのうえで、フル桁入力、データ件数増加、DB更新、帳票、外部I/F、ジョブログ、エビデンスを確認します。

販売管理システムでは、入力系とデータ作成系が特に重要です。外部に出ていく帳票や連携データも、画面と同じくらい大事です。

Codexは、テストデータ作成や検証観点の洗い出しに役立ちます。ただし、最終的に責任を持つのは人間です。単体テストは手を抜かず、後工程に恥ずかしくない状態で渡しましょう。