私はネットワーク関係の仕事をしている者です。
今回は、職場で行っているネットワーク機器のテストの自動化について簡単に紹介します。
ネットワーク機器の品質を考えるうえで、重要なことは、
仕様通りの動作をすること、またその仕様に妥当性があることです。
しかし、全ての動作仕様を把握することはベンダー側でも難しく、
多彩な機能を搭載していても一般的に使用する機能は限られています。
RFC*に準拠していることがある程度の前提となりますが、ユーザーの環境によって、期待動作は変わってくるので、動作の妥当性の判断は非常に難しいです。
*RFC(Request for Comments):
インターネットに関して言えば、技術的な仕様についての
情報を公開するための管理されている文書。
そこで、私の職場では、機器のOSバージョンやアプライアンスを問わず、比較的多くのユーザーが使用する、基本的な機能が正常に動作しているかという観点でテストを一部自動化しています。
ネットワーク機器の操作はCLI**で行うことが一般的であると思われますので、例えばOSのバージョンがver10.2からver10.4にアップデートしたとしてもエンハンスであるとか、コマンドの変更などの大きな仕様変更が無ければ、基本的には同じコマンドを流し込むだけで、同じ結果が得られるはずです。
**CLI(Command Line Interface):
キーボードを用いてコマンドなどの文字によって入力を行い、
文字によって出力を得る様式のユーザーインターフェース。
GUI(Graphical User Interface)の対義語。CUIとも呼ばれる。
つまり、物理的な結線を除けば、OSのバージョンが変わっても、同じテストケースを反復して実行することで、最低限の動作の担保は取れるということになります。
上記で述べた自動化は読者の皆様が期待されている自動化とはやや異なるものかと思いますが、簡潔な流れを紹介させていただきます。
テストにはSpirent社のiTestというツールを使用します。
iTestは先述のCLIから行うテストの自動実行を実現します。
乱暴に言えば、機器のマネジメントIPにアクセスし、(複数の)ターミナルでコマンドを勝手に叩いて、ログも採取してくれるツールです。
また、最低限必要な環境は、下記の通りです。
・クライアント(仮想)
・サーバー(仮想)
・L3スイッチ(仮想でも可)
・L2スイッチ
・L4-7スイッチ ←テスト対象装置
・iTest ←テスト自動化支援ツール(GUIで操作)
(各装置の物理的な結線に加え、iTestから各装置にコマンドを流せるネットワークも必要です)
これらの各装置にiTestからコマンドを自動で入力し、試験を行います。
自動化している試験の一例をあげると、
クライアント－サーバー間のトラフィックの疎通やその間の処理、
access-listでpermit,deny確認、NAT(Network Address Translation)
出来ているか等、数百項目ありますが、全て基本的なものです。
また、テストケースの作成方法について簡潔に述べますと、
あらかじめ、各装置に投入するコンフィグを作成します。
そのコンフィグをベースとして、試験項目ごとにコンフィグの追加、削除を指定し、判定基準(if文)によってOK,FAILの結果を設定します。
判定の例として単純なものは、クライアントAからサーバAへの
リクエストを送信すると、HTTPレスポンスコード200が返ってくるはずなのに、
レスポンスコード503が帰ってきたらFAILと判定する、などがあります。
上記で作成したテストケースを実行し、数時間待つと、
テスト結果が出力されているという流れです。
それらのテストの際に、ターミナルソフトの操作ログも取得できるので、
fail時の動作の再現やエビデンスとしての活用も可能です。
手動でテストを行う際にはコマンドミスや、ログの取り忘れなどによって、
エビデンスの取り直しの必要が生じることもあります。
そういったヒューマンエラーもなくなる上、帰宅前にテストケースを実行し、
翌日朝に結果を確認、エラーの原因を特定し、ベンダに問い合わせるといったことも可能です。
本来であれば、より様々な試験ができるものらしいですが、
QA部隊ではないので、基本的な試験での利用に留まっています。
ただ、前述の通り、一度テストケースを作ってしまえば転用が効くものなので、
ベースとなるコンフィグが正しい前提ですが、
「L3の設定変更、サーバの設定変更、L4-7装置の設定変更、、、L3の設定変更したっけ？」
といったヒューマンエラーからは解放されるのではないでしょうか。
以上です。
Tweet