ITエンジニアにとってのシステムテストの観点をまとめます。
観点としては以下です。
- 基本
- 運用・保守
- 例外
- 障害
- 多重・競合
- 境界
- データ保全
- 性能
- 負荷
- 無害
- 連続動作
システムテスト
イト屋です。
システムテストは単体テストの後にやるべきテストです。
「組み合わせテスト」「統合テスト」「ＱAテスト」などと2つや3つに分かれていたりします。
システムテストでどのくらいのテストを実施するかについては、どのくらいの品質を担保するかに依存します。不良があるとどのくらい損害がでるかによって求められる品質が異なります。
不良があると社会に多大な影響を与えるシステムや人命が脅かされるシステムは、最大限の品質を確保しますが、お客さんへのデモを行うようなPoCでは最低限動作するような品質しか求められません。
従って、ここにあげるものから、プロジェクトごとに取捨選択するのが通常かと思います。
開発項目と以下の観点を縦と横にして、表を作ってシステムテストの観点を作ると抜けがなくてよいと思います。
- 基本
- 運用・保守
- 例外
- 障害
- 多重・競合
- 境界
- データ保全
- 性能
- 負荷
- 無害
- 連続動作
基本
普通の基本項目です。通常の機能確認と考えてよいと思います。
製品ごとの機能ですから、この項目には多くの項目が上がると思います。
- 基本的なフローがちゃんと動く
- データが格納される
- 画面遷移
などを確認します。あまりに多いと基本を分割してください。
運用・保守
保守員という役目の人がいればやるべきことです。
以下のようなテストをやります。
- インストール、アップデート、アンインストール
- 機器交換
- ログ収集
マニュアルがあれば、それに沿ってチェックします。マニュアルの記述をチェックしましょう。設計者はその世界に浸かりきっているので、一般エンジニアが分かるような言葉遣いができなくなっています。
SSLの証明書の更新も保守員の人の仕事かもしれません。保守の人がその場で何か対処するような感じであれば、トラブルシューティングも見ておきます。また、定期的にログを消すようなジョブ、タスクが動かくかを確認します。
- 証明書の更新
- トラブルシューティング
- 定期ジョブ（定期タスク）
例外
例外とか準正常とか言ったりしますが、壊れるんではなくて変な操作を外からされることの確認です。
例外テストは2種類あります。
- インタフェースの例外テスト
- 画面の例外テスト
インタフェースの例外テスト
インタフェース上、使用してはならないとされている行為をやってみます。
変数に範囲があるときは範囲外の数を入れてみる、数字指定なのに文字列を入れてみる、などをやってみます。
仕様通りに「エラーを返す」などになるかを確認します。
外からつついて「変な動作をし始める」「プロセスが落ちる」とか最弱システムの誹りを受けます。
最優先で刈り取りましょう。
画面の例外テスト
人間ができることをいろいろやってみます。
- 全てのボタンを触ってみる
- 文字を入れるところに、記号などを入力する
- ボタンを連打する
- Tab, Enter, Spaceを押してみる
- 何度も画面を更新する
現在においては、GUIをスクラッチから作ることはないと思いますので、動かしてみないと分からないことも多いです。
不幸にもフレームワークの不良を見つけてしまうこともあります。フレームワークにパッチを当てることのできる立場であればいいですが、そうでないと、使用するコマンドを変えたりと、変な雰囲気になります。
障害
単純に落としてみることを考えます。機器そのもの、ネットワーク、データベースを落とした時のテストです。
稼働していない時、稼働中などを組み合わせます。
機器を落とすたりするのは最初は怖いです。ハード的に壊れないかな、OSが上がってこなかったらどうしよう、ディスクが壊れたりしないか、と心配になります。慣れると、一日に数十回サーバを落とすなど、平気でやれるようになりますよ。
多重・競合
機能ひとつがいくつも起動するのが多重起動、複数の機能が同時に起動するのが競合です。
仕様で起こりうる事態で最大のものをテストします。
かなり面倒なことが多いテストです。多重・競合をやるためだけにツールを作ったりしますね。
境界
最大値、最小値があるものをテストしていきます。
システムテストで触れないようなものは単体テストで代用する部分があっても可です。
何となく以下のようなテストも境界かもしれません。
- 証明書の期限切れ
- 時計を10年後にしてみる
- 日跨ぎ、月跨ぎ、年跨ぎ、うるう年
データ保全
データを貯めるようなシステムは、データが格納されているということを確認します。
どういう感じで確認するかは、システムによりけりです。
ヒートランをやって全てのデータが格納されたことを確認する、とか確認するためのツールが必要な場合もあります。
性能
各部位の性能、全体的な性能の計測を行います。
多重で動作するのであれば最大多重で動作させて以下を確認します。
- ちゃんと機能すること
- 性能が仕様通りであること
- だんだん遅くならないこと
負荷
CPU、メモリ、ディスク、ネットワークなどに負荷をかけてちゃんと動作するかどうかをみます。
性能は落ちるけど動くよ、か、異常な動作をしだすのか。
負荷がかかると警報を発するシステムであれば、ちゃんと警報が発報されるかも確認します。
過負荷テストなどと言って仕様以上の負荷を与えることもあります。例えば最大100アクセスが仕様となっている場合、200にしたらどうなるか、などの確認をしたりもします。
無害
いわゆるレグレッションテストです。新規開発では必要ないです。
機能追加したとき、新機能だけをテストするのではなく、従来機能もちゃんと動くということを確かめます。
自動テストにしてあると流すだけですが、そうでないなら新規開発時のシステムテストから抜粋してやります。
連続動作
連続動作はヒートランなどと呼ばれます。
一晩動かしても大丈夫、とか確認します。プロジェクトによっては、「起動・停止のヒートラン」「通常運用のヒートラン」「負荷運用のヒートラン」など複数やることもあります。
少なくとも以下を最低限確認します。グラフを書いたりするのは1日仕事ですね。
- リソースがリークするようなことがないこと
- ディスクを圧迫していかないこと
まとめ
システムテストの観点をまとめました。作っているシステムに合わせて取捨選択してください。
工程のまとめは以下です。
>>> 【ITエンジニア】工程ごとの分類
コメント