見出し画像

9.1 システムのテスト

uenohara0924

　静的なWebサイトの動作検証というと、各Webページがワイヤフレーム/デザインで規定した内容通りにできていること、支給された文面・画像などがWebページに正しく正確に含まれていること、Webページのタイトル・メタタグなどが正しく設定されていること程度であることも多いかと思います。
　システムによって動的にWebページの表示内容が変わったり、登録ボタンなどをクリックした際のアクション/処理が変化したりする場合には、さまざまな条件/状況によって期待される動作が変わりますので、動作検証すべきパターンも多くなります。
 
a. 単体テスト/結合テスト/総合テスト/受入テストなどの各種テスト
　そのため、システムのテストでは、ひとりの担当者、あるいは一回の動作検証で確認完了とはせずに、複数の担当者が複数の工程で、それぞれ異なる観点で動作検証を行うことがよく行われます。
 
[単体テスト]
システムの開発担当が発注元企業や開発指示を行うディレクタ/プロデューサに開発したシステムを提示する前に行うテストです。プログラムの実装担当者が各実装について (関数ごと等)、その狭い範囲の実装 (関数等)単位で期待通りに動作するか動作検証するレベルのものから、マルチベンダーで開発しているプロジェクトにて、各開発担当企業が各社のシステムを結合する前にそれぞれの企業が担当したサブシステムについてテストケースを組んで動作検証を行うレベルのものまであります。
　単体テストは結合テストや総合テストを行う前に、それぞれの機能がそれなりには動作することを事前確認しておくという意味合いのものでもありますが、総合テストでは確認をしにくい動作確認を実装レベルでの単体テストで行うという部分もあります。その代表的なものが、エラー処理です。サーバ/DB/ファイルシステムがダウンしている/ネットワーク障害を起こしているなどの障害時のエラー処理をはじめ、システムが正常に動作していれば起き得ない状況ではあるものの、万が一システム障害等によりそのような状況が起きた場合のエラー処理が期待通りに動作することの確認などは単体テストで行うことが多いかと思います。なお、SaaSやノーコードツールなどを利用して実装する場合には単体テストは行いません。SaaSやノーコードツールではそれぞれのサービス/ツールがきちんと動作することは事前にそれぞれの事業者が検証しているためです。ただし、基本的にはSaaSでシステムを実現していても、機能補強するためにAPIを開発していたりする場合には、そのAPIについては単体テストを行う必要があります。
 
[結合テスト]
複数のサブシステムから構成されるシステムの場合に、各サブシステムごとの単体テストを行った後に、お互いのサブシステム間のI/Fが期待通りに動作するか確認するテストです。相手のサブシステムのAPIをこちらのサブシステムで呼んだときに期待通りに処理されて期待通りのレスポンスが戻ってくるかという側面で各I/Fの動作確認を行うものから、複数のサブシステムを結合した状態で期待通りに全体システムが動作するか確認するという総合テストのような内容のものを結合テストと呼ぶこともあります。
ひとつの開発担当がひとかたまりのシステムを開発している場合や、複数のサブシステムから構成されるシステムでも、今回の開発においてはひとつのサブシステム内の改修に限定される場合などでは結合テストは行わないことが多いかと思います。
 
[総合テスト]
開発対象全体が要件を満たすことを動作検証するテストです。単体テストは全体システムの中の一部だけを、ほかのサブシステムとのI/Fは仮の方法で実現して動作検証するものですが、総合テストでは、全体システムが動作する状態にして、実際に想定されるユーザ操作により開発要件を満たすことを動作検証します。
　全体システムの全機能を動作検証していくという総合テストもありますが、単体テストや結合テストをきちんと行っていることを前提に、実際のシステムの想定利用シーン/業務フローに従った操作手順での動作を検証する「シナリオテスト」のみを行う場合もあります。
　なお、単体テストにしても総合テストにしても、動作検証する開発要件の中には、各Webページのデザイン/レイアウト、支給された文面や画像などがきちんとWebページに含まれて表示されることも当然含まれます。
 
[非機能要件テスト]
　上述の総合テストまでのテストは、必要な機能が期待通りに動作するかどうか動作検証する機能テストですが、システムが実際の運用される場合に問題なく動作し続けられるためには、機能テスト以外のテストも行っておく必要がある場合があります。
　代表的な非機能要件テストは、負荷テストです。大量のアクセスが開発対象のWebにきたときに正常に動作しないということが起きずに、規定した同時アクセス数までは正常に動作することを確認するテストです。要求される同時アクセスの大きさにもよりますが、負荷テストを行うような場合は、通常は開発関係者による人手でのアクセスでは実現できないレベルの同時アクセスを実現する必要がありますので、負荷アクセスをかける手段の用意も事前に行う必要があります。よく利用される方法は、JMETERというオープンソースのツールを用いて、多数の同時アクセスを実現する方法です。JMETERはテスト計画を設定することもできますので、複数のWebページに対して所定の手順でアクセスしていくようなシナリオも設定することができます。


Webディレクタとして次のステップをさがしている方たちへ

これからのWeb構築・Webディレクションとして、業務にまで踏み込んでディレクション/プロデュースすること、それが近年のバズワードであるDXにもつながること、そしてWebの進化とともにWeb構築の各種ツール/サービスやSaaSが広がってきていることにしたがって、業務とシステムの両面からWeb構築・運用していく人間が求められていくこと、そのためにどのような知識や能力を身に着けていくとよいかについて解説している「マガジン」です。