この記事は、 「ネットワーク中級編｜構築・検証・障害切り分けを身につける」 の第46回です。
前回の「ネットワーク変更作業の事前確認」で整理した作業前確認を踏まえ、 今回は変更後に「正しく設定できた」「業務通信として使える」と判断するための試験を学びます。
単体試験・結合試験の考え方｜ネットワーク試験項目の作り方を実務目線で解説
ネットワーク構築では、設定を投入して通信できたら完了ではありません。 機器単体の設定・状態が正しいことを確認する「単体試験」と、複数機器・サーバー・端末を組み合わせて 実際の通信が成立することを確認する「結合試験」を分けて考えることで、試験漏れを減らせます。 この記事では、試験観点、期待結果、エビデンス、正常系・異常系まで具体例で整理します。
現場でよくある失敗は、「pingが通ったので試験OK」と判断してしまうことです。 pingで確認できるのは、ある条件下でICMP通信が成立したことだけです。
実際には、インターフェース、VLAN、ルーティング、冗長化、ACL、NAT、DNS、監視、業務ポートなど、 設計した機能ごとに「何をもって正常とするか」を決める必要があります。
この記事を読み終えるとできること
- 単体試験と結合試験の目的を説明できる
- 設定値から試験観点を洗い出せる
- 正常系と異常系を分けて考えられる
- 期待結果を曖昧にせず記述できる
- 試験エビデンスとして残す情報を判断できる
- ネットワーク変更後の試験順序を組み立てられる
ネットワーク試験は何を確認するものか
試験とは、設計・設定・通信が「想定した条件で、想定した結果になる」ことを、 客観的な確認結果で示す作業です。
ネットワーク機器へ設定を投入できても、その設定が設計どおりに動作しているとは限りません。 また、各機器が正常でも、機器同士を組み合わせた通信が成立しないこともあります。
試験項目は「何となく通信確認する」のではなく、設計内容から逆算して作ります。
設計書・パラメータシート・構成図に書かれた内容が、試験観点の元になります。
単体試験と結合試験の違い
単体試験と結合試験は、現場やプロジェクトによって名称や境界が多少異なることがあります。 大切なのは名称を暗記することではなく、「どの範囲を、何の目的で確認するか」を明確にすることです。
| 観点 | 単体試験 | 結合試験 |
|---|---|---|
| 主な目的 | 機器・機能・設定が個別に正しいことを確認 | 複数機器やシステムを組み合わせた通信を確認 |
| 見る範囲 | 1台の機器、1機能、1設定単位 | 端末からサーバーまでなど、通信経路全体 |
| 代表例 | IF状態、VLAN、ルート、冗長状態、ACL設定 | 業務通信、DNS、NAT、経路冗長、障害時切替 |
| 主な確認手段 | showコマンド、設定表示、ログ、状態確認 | ping、traceroute、アプリ接続、パケット、ログ |
| NG時の考え方 | 対象機器・設定に原因を絞りやすい | 経路上の複数要素を切り分ける必要がある |
単体試験と結合試験のイメージ
結合試験：PCからServerまで一連の通信として確認
試験範囲を決める考え方
試験項目をいきなりExcelへ書き始めると、重複や漏れが起きやすくなります。 まず、今回の作業で何が変わるのかを分解します。
試験範囲は「変更箇所だけ」ではない
たとえばスタティックルートを1行追加する変更でも、その経路を使う通信、戻り経路、ACL、NAT、監視への影響まで確認が必要になる場合があります。 変更対象そのものと、変更によって影響を受ける周辺機能を分けて洗い出します。
試験範囲を決めるときは「変更点」「影響範囲」「既存機能」の3つを見る。
新しい通信が通ることだけでなく、既存通信を壊していないことも重要な試験観点です。
単体試験で確認する代表項目
単体試験では、まず対象機器が設計どおりの状態になっていることを確認します。 コマンドはベンダーや機種で異なりますが、見る観点は共通化できます。
物理・IF
リンク状態、速度、Duplex、エラー、光レベルなど。
L2
VLAN、Trunk、STP、LAG、MAC学習状態など。
L3
IP、ルート、OSPFネイバー、経路選択など。
運用・制御
ACL、NAT、NTP、Syslog、SNMP、監視設定など。
| 試験観点 | 確認例 | 期待結果の例 |
|---|---|---|
| インターフェース | 管理状態／リンク状態／エラー | 対象IFがup/up、異常カウンタ増加なし |
| VLAN | VLAN存在、ポート所属 | 設計値のVLANに対象ポートが所属 |
| Trunk | Native VLAN、許可VLAN | 設計したVLANのみ通過可能 |
| STP | Root、Port Role、State | 想定SWがRoot、想定ポートがFWD/BLK |
| Routing | ルーティングテーブル | 対象宛先が想定Next Hopへ向く |
| OSPF | Neighbor、Route | ネイバーがFULL、想定経路を学習 |
| ACL/FW | ルール内容、ヒット状況 | 許可・拒否条件が設計どおり |
| NAT | 変換ルール、変換テーブル | 対象通信が想定アドレスへ変換 |
| 監視 | SNMP/Syslog/NTP | 監視・ログ・時刻同期が正常 |
設定が存在することと、機能していることは別です。
たとえばOSPF設定がrunning-configに存在しても、NeighborがFULLでなければ動的経路交換は成立していません。
結合試験で確認する代表項目
結合試験では、複数の機器やサービスを組み合わせ、利用者の通信として成立するかを確認します。 「機器Aは正常」「機器Bも正常」だけではなく、AとBをつないだときに目的の通信ができるかを見ます。
許可される通信が成功する
- 端末からデフォルトゲートウェイへ到達
- DNS名前解決が成功
- 業務サーバーのTCPポートへ接続
- 拠点間通信が想定経路で成立
- NAT後に外部サービスへ接続
許可されない通信が失敗する
- 禁止セグメント間の通信を拒否
- 管理ポートへ一般端末から接続不可
- 不要な外向きポートを遮断
- ACL対象外通信が誤って許可されない
- 不要経路へトラフィックが流れない
「pingが通る」だけでは不足する理由
Webシステムの利用確認で必要なのがHTTPSであれば、ICMPだけでなくTCP/443や実際のアプリケーション接続を確認します。 FirewallではICMPとTCPで別ルールになっている場合があるため、業務要件に合ったプロトコルで試験することが重要です。
結合試験の主語は「機器」よりも「通信」です。
「PC-AからServer-BのHTTPSへ接続できる」のように、送信元・宛先・プロトコルを具体化すると試験が明確になります。
正常系・異常系の考え方
正常系は「通常利用時に期待する動作」、異常系は「障害や制御条件が発生したときに期待する動作」です。 ネットワークでは、冗長化やセキュリティ機能を確認する場合に異常系が特に重要です。
| 機能 | 正常系 | 異常系 |
|---|---|---|
| 冗長回線 | 主回線を利用して通信できる | 主回線断で副回線へ切り替わる |
| STP | 通常時にループせず通信できる | リンク断後に代替経路がForwardingになる |
| FW | 許可ポートが通信できる | 禁止ポートが遮断される |
| DHCP | 正しいアドレスを取得できる | 異なるVLANのスコープから取得しない |
| 監視 | 正常状態を監視できる | リンク断時にアラートを検知できる |
異常系試験は、本番環境で安易に障害を発生させないでください。
影響範囲、実施可否、切り戻し方法、監視抑止、関係者合意を確認し、必要に応じて検証環境やメンテナンス時間で実施します。
試験項目の作り方
試験項目は、「確認する」「正常であること」のような曖昧な書き方ではなく、 誰が実施しても同じ判定になりやすい形へ分解します。
- 試験対象を決める対象機器、機能、通信、設定変更点を特定します。
- 試験観点を決めるIF、VLAN、Route、FW、NAT、冗長化、監視などに分解します。
- 試験条件を決める送信元、宛先、ポート、経路、接続状態などを明記します。
- 操作・確認方法を書く実行コマンド、GUI操作、ケーブル抜線などの手順を記載します。
- 期待結果を書く数値・状態・経路・成否を、判定可能な形で記載します。
- エビデンスを決めるコマンド出力、画面、ログ、パケットなど何を残すか決めます。
- 試験ID
- IT-RT-01
- 試験区分
- 結合試験
- 確認内容
- PC-Aから業務WebサーバーへのHTTPS通信
- 条件
- PC-A：192.168.10.10／Server：192.168.100.20／TCP 443
- 実施方法
- PC-Aのブラウザで業務URLへアクセスする
- 期待結果
- ログイン画面が表示され、FWログでTCP/443が許可されていること
- エビデンス
- ブラウザ画面＋FW通信ログ
期待結果の書き方
試験項目で最も重要な要素の1つが期待結果です。 「問題ないこと」「正常であること」では、実施者によって判定が変わってしまいます。
| 曖昧な期待結果 | 改善例 |
|---|---|
| インターフェースが正常であること | Gi1/0/1がadministratively up、line protocol upであること |
| OSPFが正常であること | Neighbor 10.0.0.2のStateがFULLであること |
| 経路が正しいこと | 192.168.100.0/24のNext Hopが10.0.0.2であること |
| Webへ接続できること | PC-Aから対象FQDNへHTTPS接続し、ログイン画面が表示されること |
| 切替できること | 主回線断後、副回線経由で対象通信が再開すること |
期待結果は「見れば○か×か判断できる」粒度まで具体化します。
特に状態名、IPアドレス、Next Hop、VLAN ID、ポート番号など、設計値があるものは明記すると判定しやすくなります。
エビデンスの残し方
エビデンスは、「試験を実施した証拠」だけではなく、後から結果を確認し、NG時に原因を調査するための資料でもあります。
CLI出力
showコマンド、ping、tracerouteなど。プロンプトと対象機器が分かる形にします。
GUI画面
FWポリシー、監視画面、Web接続結果など。対象名と時刻が分かると便利です。
ログ
FW、Syslog、認証ログなど。試験時刻と突き合わせられる形にします。
パケット
通信成立や拒否理由を詳細確認する場合に、必要範囲だけ取得します。
エビデンスで残したい情報
- どの機器・端末で実施したか
- いつ実施したか
- どの試験項目に対応するか
- 実行したコマンドや操作
- 期待結果を判断できる出力部分
- NGの場合はエラー内容やログ
エビデンスは「大量に残す」より「判定根拠が分かるように残す」ことが重要です。
数百行の出力を貼るだけではなく、試験項目と対応付けて整理します。
変更作業後の試験順序
作業後は、いきなり業務アプリの試験から始めるより、下位レイヤーから順番に確認すると問題発生時の切り分けがしやすくなります。
- 物理状態リンク、電源、SFP、ポートエラーを確認します。
- L2状態VLAN、Trunk、STP、EtherChannelなどを確認します。
- L3状態IP、ルート、OSPF、デフォルトゲートウェイを確認します。
- 制御機能ACL、FW、NAT、VPNなどを確認します。
- 基本疎通必要に応じてpingやtracerouteで経路を確認します。
- 業務通信DNS、HTTPS、RDPなど実際の利用通信を確認します。
- 冗長・監視許可された範囲で切替、アラート、ログを確認します。
- 既存通信変更前から利用している重要通信に影響がないか確認します。
下位レイヤーから確認する理由は、NG時の原因範囲を狭めやすいからです。
たとえばリンクがdownなのにHTTPS試験を繰り返しても、原因切り分けは進みません。
よくある試験設計の失敗
設定確認だけで終わる
running-configが設計値と一致していても、Neighbor、経路、セッションなど実動作が成立しているとは限りません。
pingだけで結合試験を終える
実際に必要なTCP/UDPポート、名前解決、アプリケーション通信を確認できていません。
成功する通信だけを確認する
FWやACLでは、許可通信だけでなく禁止通信が正しく拒否されることも重要です。
期待結果が曖昧
「正常」「問題なし」だけでは、別の担当者が同じ基準で判定できません。
既存通信を確認しない
新しい通信は成功しても、既存ルートやACLへの影響で別通信を壊している可能性があります。
試験できない項目を放置する
本番で実施できない異常系は、未実施理由と代替確認方法を明確にします。
試験NG時の整理方法
試験でNGが出たときは、すぐに設定変更を繰り返すのではなく、試験条件と結果を整理します。 変更を重ねるほど、どの操作で状態が変わったのか分からなくなるためです。
- 試験ID
- IT-RT-01
- 事象
- PC-Aから業務サーバーTCP/443へ接続できない
- 期待結果
- HTTPSログイン画面が表示される
- 実結果
- ブラウザで接続タイムアウト
- 確認済み
- PC-A→GW ping成功、対象Routeあり、DNS解決成功
- 未確認
- FWセッション／ポリシーヒット、Server側待受
- 次の確認
- FWログでTCP/443の許可・拒否を確認
「NGだった」ではなく、「どこまで正常だったか」を残すと切り分けが速くなります。
理解度チェック
記事の内容を確認するため、5問に答えてみましょう。
問題1．単体試験の説明として最も適切なものはどれですか。
- 利用者が業務システムを使えるかだけを確認する
- 機器や機能の設定・状態を個別に確認する
- 障害報告書を作成する
- 必ず本番障害を発生させて確認する
解答を見る
単体試験では、対象機器や機能が設計どおりに設定・動作しているかを個別に確認します。
問題2．結合試験で、PCからWebサーバーへの業務通信を確認します。ping成功だけで十分でしょうか。
解答を見る
業務要件がHTTPSなら、TCP/443や実際のWebアクセスまで確認する必要があります。
問題3．FWの試験で「許可通信が成功する」ことだけ確認した場合、何が不足していますか。
解答を見る
セキュリティ制御ではAllowとDenyの両方を試験観点にします。
問題4．「OSPFが正常であること」という期待結果の問題点は何ですか。
解答を見る
NeighborがFULL、対象経路を学習している、Next Hopが設計値など、判定可能な状態へ具体化します。
問題5．変更後の試験で既存通信も確認する理由を説明してください。
解答を見る
新規設定により、既存ルート、ACL、NAT、STPなどへ意図しない影響を与えていないことを確認するためです。
実践演習：VLAN追加作業の試験項目を作ろう
次の変更作業を実施したとします。
演習構成
変更内容
- Access SWへVLAN 30を追加
- PC接続ポートをAccess VLAN 30へ変更
- SW間TrunkへVLAN 30を追加
- L3 SWへVLAN 30のSVIを追加
- VLAN 30からServerへのTCP/443を許可するACLを追加
- その他のVLAN 30発通信は拒否する
課題1．単体試験を5項目以上挙げてください
解答例を見る
- Access SWにVLAN 30が存在すること
- PC接続ポートがAccess VLAN 30であること
- SW間TrunkでVLAN 30が許可されていること
- L3 SWのVLAN 30 SVIがup/upであること
- SVIのIPアドレスが192.168.30.1/24であること
- ACLにVLAN 30→Server TCP/443の許可ルールがあること
- ACLが想定インターフェース・方向へ適用されていること
課題2．結合試験を3項目以上挙げてください
解答例を見る
- PC-Aから192.168.30.1へ基本疎通できること
- PC-AからServer 192.168.100.20のTCP/443へ接続できること
- PC-AからServerの許可されていないポートへ接続できないこと
- PC-Aから他の禁止セグメントへ通信できないこと
- 変更前から存在する既存VLANの主要通信が継続できること
課題3．次の期待結果を書き直してください
悪い例：「VLAN 30の通信が正常であること」
解答例を見る
「PC-A（192.168.30.10）からServer（192.168.100.20）のTCP/443へ接続し、HTTPSログイン画面が表示されること。また、FW/ACL上で当該通信が許可されていること。」
自分の言葉で説明する課題
後輩から「単体試験と結合試験って、何が違うんですか？」と聞かれました。30秒程度で説明してください。
説明例を見る
単体試験は、各ネットワーク機器や機能が設計どおりに設定・動作しているかを個別に確認する試験です。結合試験は、それらの機器やサービスを組み合わせ、端末からサーバーまでの実際の通信が要件どおり成立するかを確認する試験です。
まとめ
- 試験は「設計した内容が想定条件で想定結果になること」を確認する
- 単体試験では、機器・機能・設定を個別に確認する
- 結合試験では、複数機器を通る実際の通信として確認する
- 試験範囲は、変更点だけでなく影響範囲と既存機能まで考える
- FWや冗長化では、正常系だけでなく異常系・拒否系も重要
- 期待結果は「正常」ではなく、状態・値・通信成否を具体的に書く
- エビデンスは、後から判定根拠が分かる形で残す
- 作業後は、物理→L2→L3→制御→業務通信の順で確認すると切り分けやすい
良い試験項目は、設定内容を知っている人だけが分かるものではなく、別の担当者でも同じ基準で合否判定できるものです。
コメント