40
42

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

新卒2年目のインフラエンジニアがインフラ案件を紹介してみた④【最終回】

Posted at

目次

1.はじめに
2.テストフェーズ
2-1.単体テスト
2-2.結合テスト
2-3.総合テスト
3.移行フェーズ
4.まとめ

1.はじめに

こちらの記事は、「1〜2年目のインフラエンジニア」の方や
「インフラ案件を初めてやるよ!」という方向けの記事です!
今回がインフラ案件紹介してみたシリーズラストです!

過去の記事はこちら↓
①全体概要・要件定義編(記事掲載の目的と背景、自己紹介等も記載しています)
https://qiita.com/takuya_tsurumi/items/bebde1ab1fa1987bfcd0

②基本設計・詳細設計編
https://qiita.com/takuya_tsurumi/items/dff89606784b866a108a

③構築編(WIndows Server 2016)
https://qiita.com/takuya_tsurumi/items/d3aef7cd0e24ead8a8a8

今回は、テスト・移行フェーズ編です!

2.テストフェーズ

まずは、テスト自体なんでやるの?という話から。
私が考える、テストの目的は、「システムの品質を担保するため」です。
具体的に言うと、人的ミスを見つけて直したり、使用しているソフトウェアに何らかのバグがあれば修正等して、要望通りのシステム品質を担保するために実施します。

そしてこのテストにはいくつかの工程があります。
ここで思い出していただきたいのが、以下のウォーターフォールモデルの図です。

68747470733a2f2f71696974612d696d6167652d73746f72652e73332e616d617a6f6e6177732e636f6d2f302f3332393534342f35333635663335662d666433612d363330302d323634642d3235353533336165336164322e6a706567.jpeg
図.2.1.ウォーターフォールモデル

右側の赤枠の部分がテストの工程です。
単体テスト(UT)→結合テスト(IT)→総合テスト(ST)の順に進んでいきます。
そして、それぞれ左側にあるもの(単体テストなら詳細設計、結合テストなら基本設計、総合テストなら要件定義)で定めた部分に対応して確認します。

場合によっては、性能テスト、負荷テストを実施する場合もありますが、
ライフサイクル対応の場合、既に動いているサーバのスペック以上にしておけば問題ないでしょう。
(ベンダー推奨のスペック以上であることを前提としています。)

負荷テストについてとても参考になった記事がありましたので、リンクを貼っておきます!
https://qiita.com/jun2014/items/121f2dcb2de4c4e77421

それでは、それぞれのテストで具体的にどんなことをやるのか、書いていきます。

###2-1.単体テスト
単体テストでは、詳細設計書と構築したシステムの設定値が同じであることを確認します。
指定した通りのIPアドレス・DNSの設定が投入されているか、指定したドメインに参加しているか、指定したホスト名になっているか等々、全てのパラメータと設定値を確認します。

間違えているところがあれば修正し、再度間違いがないことを確認しましょう。
問題がなければ次の結合テストに進みます。

###2-2.結合テスト
結合テストでは、構築したものの各コンポーネントの動作が正しく行われているかどうかを確認します。
(このあたりは定義がまちまちかと思いますが、私はこのように定義しています。)

OSへのリモート接続ができるか、
バックアップを自動化していれば、指定した時間にバックアップはされるかどうか、
監視設定をしていればしっかり監視できているか等々、
基本設計で定めた点がしっかり動作することを確認しましょう。

こちらも問題があれば修正し再テスト、問題なければ次の総合テストへ進みましょう。

###2-3.総合テスト
総合テストでは、実運用業務の流れに沿って構築したシステムを操作し、
正常な動作をすることを確認します。
要件定義で定めた機能要件・非機能要件の通り、
やりたいことが実現できていることを確認していきます。

また運用していく上で障害発生時にどう対応していくのか等も
しっかり意識してテストを実施しましょう。

上記の説明でイメージしが沸かない方むけに、テストはどのように進んでいくか、
例え話をしたいと思います。(少しめちゃくちゃな設定です。笑)

####「マジメ君、プラモデルを完璧に作る の巻」

登場人物
①マジメ君:めちゃくちゃ手先が器用で几帳面。とっても細かいところまで気になってしまう性格。
②友人A:とっても不器用。2歳の息子を溺愛中。マジメ君の同期。

とある日のこと,,,

マジメ君は会社の帰り道に友人Aから声をかけられました。

友人A「ねぇマジメ君、ちょっとお願いがあって…!
息子にロボットのプラモデルを作ってあげたくて。でも俺不器用で明日までに作れそうにないんだ…。俺の代わりに作ってきてくれないか?息子が遊んでも壊れないくらいにしっかり頼むよ!!お礼はするからさ!!」

マジメ君は友人Aの要求を受け入れ早速家に帰り、説明書(設計書)を見ながらプラモデルを作った(構築した)。

mokei_puramo.jpeg

人に依頼されたものでもあるので、マジメ君は、しっかり作れたのかどうかの確認(テスト)を始めた。

まずマジメ君が最初に確認したのは、説明書(設計書)通りに組み立てることができているかどうか。
部品の余りや、ネジの止め忘れ等がないことを確認した。(単体テスト)

setsumeisyo_manual.jpeg

その後、腕、足は動くか、首は回るのか、プラモデルのそれぞれの機能が予想通りに行われることを確認した。(結合テスト)

最後にマジメ君は、童心に戻ったかのようにプラモデルで遊び始めた。
子どもがやりそうなアクション全てを実施し、プラモデルが壊れず、楽しく遊べることを確認した。(総合テスト)

omocha_asobu_man.jpg

次の日、マジメ君はしっかりテストしたので、自信を持って
友人Aにプラモデルをプレゼントできましたとさ。

マジメ君がプラモデル作成後、友人Aのためにプラモデルの動作を確認したように、
システム構築後に動作を確認するのがテストフェーズです。

3.移行フェーズ

移行フェーズでは、事前に決めておいたスケジュールで構築したシステムを本番リリースする作業をします。
もし、失敗してしまった場合の切り戻し手段もしっかり考えておきましょう!

無事システムの移行が完了し、実運用を問題なく進めることができれば、移行フェーズは完了です。

4.まとめ

今回は、テスト・移行フェーズについて紹介しました。
テストや移行フェーズでは単純な作業が増えてきますが、テスト無くして品質を担保できる超人はいないので、とても重要なフェーズだと、私は思っています。
また、テスト自動化用のツール等も諸々あるようなので、これからテストも自動化して行けるようになりたいです!!

そして、今ままでインフラ案件の全体を通して紹介してきました。
この記事が初心者を含めた様々な方々の役に立つことを願っています。

最後までお付き合いくださり、ありがとうございました!

40
42
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
40
42

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?