テスト環境のつくり方とは？構築の手順やポイントをわかりやすく解説

テスト環境とは、Webサイトやシステムを本番公開する前に、動作や表示を確認するための検証用の環境のことです。本番環境とは分離された環境として構築され、実際の利用者に影響を与えることなく変更や検証を行うことができます。

企業のWebサイトやシステムは、デザイン変更・機能追加・セキュリティ更新など、さまざまな理由で定期的に更新されます。しかし、本番サイトを直接変更すると、誤った設定や不具合がそのまま公開されてしまうリスクがあります。たとえば、ページが表示されなくなったり、問い合わせフォームが動かなくなったりすると、企業の信用や売上に悪影響を及ぼすでしょう。

そこで重要になるのが、テスト環境での事前検証です。テスト環境では、本番と同じデータや構成を再現しながら、更新内容の確認や不具合のチェックを行います。近年はクラウド環境の利用が一般的であり、本番環境と同等の構成をクラウド上の別インスタンスや別環境として用意し、検証を行う運用が主流です。問題がないことを確認してから本番環境に反映することで、トラブルの発生を防ぐことができます。

テスト環境は、目的や開発プロセスによってさまざまな呼び方があります。代表的なものには以下があります。

・開発環境
開発者が機能を作成・修正するための環境です。試験的なコード変更や機能追加が頻繁に行われます。

・ローカル環境
開発者のPC内に構築する環境です。インターネット上のサーバーを使わず、個人のPC上で開発や検証を行います。

・検証環境
機能や動作に問題がないかを確認するための環境です。テスト担当者や関係者がチェックを行うために使用します。

・ステージング環境
本番環境とほぼ同じ構成でつくられた最終確認用の環境です。近年では、このステージング環境を本番切り替えの対象としてそのまま利用する構成も多く採用されています。本番公開直前の確認を目的として使われることが多いです。

このように、テスト環境は開発から公開までの品質管理を支える重要な仕組みです。特に企業サイトでは、マーケティング部門・広報部門・開発部門など複数の関係者が関わるため、事前検証の環境を整えることは安定したサイト運用の基盤になります。

テスト環境と本番環境は、目的だけでなく、構成や公開方法にも違いがあります。主な違いは次の3つの視点で整理できます。

■URL（住所）
まず大きな違いは、サイトのURLです。本番環境では、企業の公式ドメインが使われます。例えば次のようなURLです。
「https://example.com」

一方、テスト環境では、本番と区別できるURLが使われます。代表的な例としては次のような形式があります。
・サブドメイン
「https://test.example.com」

・サブディレクトリ
「https://example.com/test/」

・別ドメイン
「https://example-test.com」

・ローカル環境
「https://service.shiftinc.jp」

このようにURLを分けることで、本番サイトとテストサイトを明確に区別することができます。

■設置場所
次に、サイトを設置する場所の違いがあります。テスト環境は、必ずしも本番サーバーと同じ場所に設置されるとは限りません。主に次のような方法があります。

・別サーバーに設置する
本番とは完全に独立したサーバーを用意します。最も安全な方法で、大規模なサイトや企業システムでよく採用されます。

・同一サーバー内の別領域に設置する
同じサーバーのなかに、別フォルダやサブドメインとしてテスト環境をつくります。コストを抑えながら運用できる方法です。

・PC内に設置する（ローカル環境）
開発者のPCに環境をつくる方法です。外部からアクセスできないため、安全に開発や検証ができます。

企業サイトでは、サーバー上のテスト環境とローカル環境を組み合わせて使うケースも多く見られます。また、近年は本番がクラウド環境で運用されていることが多く、テスト環境もクラウド上に別環境として構築するケースが一般的です。オンプレミス環境を採用している場合でも、開発・検証用の環境をクラウド上に用意することがあります。

■公開設定
テスト環境は、本番サイトとは異なり、一般公開しない設定にする必要があります。誤って公開されると、検索エンジンに登録されたり、未完成のサイトが閲覧されてしまったりする可能性があるためです。

そのため、次のようなアクセス制御が行われます。

・Basic認証
IDとパスワードを入力しないとサイトが見られない仕組みです。
Basic認証についてはこちらもご覧ください。
＞＞Basic認証とは？仕組みやメリット・デメリット、設定方法について解説のページへ

・IP制限
特定のIPアドレスからしかアクセスできないようにする方法です。社内や開発会社のみ閲覧可能にできます。

・ユーザー認証
ログインしたユーザーだけが閲覧できるように設定します。

・検索エンジン除外
Googleなどの検索結果に表示されないように設定します。

こうした設定を行うことで、テスト環境を安全に運用することができます。

企業サイトでは、デザイン変更や機能追加、セキュリティ更新など、さまざまな更新作業が発生します。これらを本番環境で直接行うと、予期しない不具合が発生し、サイト停止や問い合わせ機能の不具合など、事業活動に影響を及ぼす可能性があります。

テスト環境を整備しておくことで、変更内容を事前に確認でき、問題がない状態で本番環境へ反映できます。その結果、サイト運用の安全性と品質を高められるのです。

ここでは、企業サイト運用において特に重要な4つのメリットを紹介します。

Webサイトやシステムのデザイン修正や機能追加などを行う際には、変更内容が必ずしも既存の機能と完全に互換性があるとは限らず、作業の失敗やバグの混入などのリスクもあります。

たとえば、次のようなトラブルが発生することがあります。

・修正後にページが表示されなくなる
・デザイン変更によってスマートフォン表示が崩れる
・システムが正常に動作しなくなる

本番環境で直接作業を行うと、このような不具合がそのまま公開されてしまいますが、テスト環境であれば、本番環境を再現した状態で安全に試すことができます。

また、問題が発生しても利用者に影響はなく、原因の調査や修正も落ち着いて行えるため、企業サイトやシステムの安定運用において重要な役割を果たします。

Webサイトやシステムのリニューアルや新機能の追加では、見た目や操作性を細かく調整する必要があります。

たとえば、次のような検証が必要になります。

・スマートフォンとPCでの表示確認
・複数ブラウザでの表示確認
・ページ読み込み速度の確認
・デザインの細かなレイアウト調整
・ボタンやリンクの動作確認

本番環境でこれらの調整を行うと、作業中の状態がそのまま公開されてしまう可能性があります。特に企業サイトでは、ブランドイメージやユーザー体験に影響するため注意が必要です。

テスト環境を使えば、公開前に関係者で確認しながら改善できます。マーケティング担当者や広報担当者が実際の画面を見ながら調整できるため、より完成度の高いサイトに仕上げることが可能です。

企業サイトやシステムでは、次のような作業が定期的に発生します。

・サーバー移行
・CMSのバージョンアップ
・データベース更新
・バックアップからの復元

これらの作業は、手順を誤るとサイトが表示されなくなるなどの重大なトラブルにつながる可能性があります。

テスト環境があれば、本番と同じ手順を事前に試すことが可能です。特にクラウド環境では、構成変更や切り替え手順、コンテナやインフラ設定の再現なども含めて事前に検証しやすくなります。

企業のWebサイトやシステムには、開発担当者だけでなくさまざまな関係者が関わって運用されています。

たとえば、次のような部門が関与することがあります。

・経営層
・マーケティング部門
・広報・PR部門
・営業部門
・開発会社

サイトのリニューアルや機能追加では、これらの関係者が公開前に内容を確認する必要があります。

テスト環境があれば、公開前のサイトを関係者に共有でき、次のような確認ができます。

・デザインがブランド方針に合っているか
・コンテンツの内容に問題がないか
・導線や問い合わせフローが適切か

また、実際のサイトに近い状態で確認できるため、文章だけのレビューよりも正確な判断ができます。その結果、公開後の修正を減らすことができ、サイト運用の効率も向上します。

WordPressサイトのテスト環境は、本番サイトをコピーして別の場所に再現することで構築します。企業サイトでは、デザイン変更やプラグイン更新、機能追加などを安全に検証するために、このようなテスト環境を用意することが一般的です。

ここでは、企業サイト運用の現場でも使われている標準的な手順を順番に解説します。

テスト環境をつくる前に、まずどのような目的でテストを行うのかを整理することが重要です。目的が曖昧なまま環境を構築すると、必要な検証が漏れてしまう可能性があります。テスト計画では、主に次の項目を整理します。

・目的
「サイトリニューアルの最終確認」、「WordPressやプラグイン更新の検証」、「サーバー移行の事前確認」など、テストの目的を明らかにします。

・対象ページ・対象機能
テスト対象のページがどこなのか、テスト対象が問い合わせフォームなのか会員機能なのか、などを具体的に明示します。

・チェック項目
テストでチェックする項目が何なのか、たとえば「表示崩れの有無」、「スマートフォン表示」、「ページ読み込み速度」、「SEO設定」、「管理画面の動作」などを具体的に指定します。

・担当者
テスト担当者、クロスチェック担当者、最終確認者などを明らかにします。

・期限
テスト開始日、修正期限、本番公開予定日などを決めます。

また、企業サイトでは完了条件を明確にすることも重要です。たとえば「主要ページの表示確認が完了」「フォーム送信テストが成功」など、具体的な条件を設定します。

さらに、テスト計画では「やらないこと」も決めておくと作業がスムーズになります。たとえば「コンテンツ文章の修正は今回のテスト対象外」など、範囲を明確にすることで、作業の混乱を防ぐことが可能です。

テスト環境を作る際には、まず本番サイトのデータをバックアップします。WordPressサイトは主に次の2種類のデータで構成されています。

■ファイルデータ
このなかには以下のようなデータが含まれています。

・テーマファイル
・プラグイン
・画像や動画などのメディアファイル
・アップロードデータ

■データベース（DB）
WordPressの投稿記事、固定ページ、設定情報、ユーザー情報などはデータベースに保存されています。テスト環境をつくるためには、ファイルとデータベースの両方をコピーする必要があります。また、大規模サイトの場合には次の点にも注意が必要です。

・画像データが多い場合は容量が大きくなる
・サーバーのアップロード制限に引っかかる可能性がある
・バックアップに時間がかかる場合がある

ただし、現在はローカルへ個別に圧縮・ダウンロードして移行する方法だけでなく、クラウド上でバックアップやスナップショットを取得し、別環境へ複製する方法も広く使われています。

企業サイトでは個人情報の扱いにも注意が必要です。問い合わせデータや会員情報が含まれる場合は、テスト環境での取り扱いルールを事前に決めておくことが望ましいでしょう。

次に、テスト環境を設置するためのサーバーとURLを準備します。

テスト環境のサーバーは、本番とできるだけ近い構成にすることが重要です。具体的には、次のような設定を本番に合わせます。

・PHPのバージョン
・MySQLのバージョン
・Webサーバー設定
・メモリ設定

環境の違いが大きいと、本番では発生しない不具合がテスト環境で発生する可能性があります。そのため、本番環境に近い構成でテスト環境を構築することが基本です。

また、URLの命名にも注意が必要です。本番サイトと区別しやすい名前をつけることで、作業ミスを防ぐことができます。

テスト用サーバーの準備ができたら、WordPressを設置します。

基本的な手順は次の通りです。

1.テスト環境用のデータベースを作成する
2.WordPressをインストールする
3.WordPressをデータベースと連携させる

既存サイトをコピーする場合は、次の点に注意する必要があります。

・テーブル接頭辞
WordPressのデータベースには「wp_」などの接頭辞が付いています。複数サイトを管理する場合、接頭辞の設定が異なることがあります。

・文字コード
データベースの文字コード設定が異なると、日本語が文字化けする場合があります。

・権限設定
ファイルの権限設定が正しくないと、WordPressが正常に動作しないことがあります。

また、環境の再現性を高めるために、Dockerなどのコンテナ技術を活用して構築する方法も広く利用されています。

インストール後は、管理画面にログインできるかどうかを確認します。ここまで問題がなければ、WordPressの基本設定は完了です。

次に、本番サイトのデータをテスト環境へ移行します。

データ移行後は、次の簡易チェックを行います。

・サイトが正常に表示されるか
・管理画面にログインできるか
・画像が表示されるか
・メニューやリンクが動作するか

問題がなければ、テスト環境として基本的な準備は完了です。なおクラウド運用では、テスト環境で検証した構成やデータをもとに、その環境自体を本番へ切り替える方式が採用されることもあります。

最後に、テスト環境が外部に公開されないように設定します。

テスト環境は本来、社内関係者や開発者のみが閲覧するものです。誤って一般公開されると、未完成のページが検索エンジンに登録されてしまう可能性があります。

具体的には、『本番環境との違い』でご説明した、「公開設定」の設定を行います。

テスト環境を構築した後は、実際にサイトやシステムが正しく動作するかを確認します。ここで重要なのは、単にページが表示されるかを見るだけではなく、利用者の視点と運用者の視点の両方から確認することです。

ここでは、一般的なWebサイト運用で行われるテスト手順を4つのステップで解説します。

サイトの基本的な動作を確認します。ここでは、実際の利用者がサイトを閲覧・操作することを想定してチェックを行います。主な確認項目は次のとおりです。

■表示確認
・トップページや主要ページが正常に表示されるか
・スマートフォンとPCで表示が崩れていないか
・主要ブラウザ（Chrome・Edge・Safariなど）で問題がないか
など

■機能確認
・問い合わせフォームが送信できるか
・ログイン機能が正常に動作するか
・検索機能が正しく動くか
・会員機能や決済機能が問題なく動くか
など

■管理機能の確認
運用担当者が利用する管理機能もチェックします。
・投稿やページ更新ができるか
・管理者・編集者などの権限設定が正しいか
・プラグイン同士の競合が起きていないか

WordPressサイトでは、プラグインの組み合わせによって不具合が発生することもあるため注意が必要です。

■SEO関連の確認
検索エンジン対策の設定も確認します。

・タイトルタグ
・メタディスクリプション
・URL構造
・サイトマップ
など

■速度・安定性
・ページ読み込み速度
・大きな画像による表示遅延
・エラーの発生有無
など

テストが完了したら、次は本番環境へ反映する計画（リリース計画）を立てます。サイトの規模や更新内容によって、反映方法は異なります。主な方法には次のようなものがあります。

・全上書き方式
テスト環境のデータをそのまま本番環境にコピーする方法です。サイトリニューアルなど、大規模変更でよく使われます。

・差分反映
変更があったファイルや設定のみを本番へ反映します。軽微な更新に適しています。

・手動反映
デザインや設定を手作業で変更する方法です。小規模な変更で使われます。

・環境切り替え方式
検証済みのステージング環境や別インスタンスを、そのまま本番環境として切り替える方法です。クラウド環境で広く使われています。

また、リリース計画では次のような項目も決めておきます。

・作業日時（夜間や休日など）
・作業担当者
・作業手順
・問題発生時の対応方法
・作業時間の目安

企業サイトでは、公開作業中にサイトが一時停止する場合もあります。そのため、必要に応じてメンテナンス時間を設定することもあります。

さらに重要なのが、戻し手順（ロールバック）を準備することです。万が一問題が発生した場合、すぐに元の状態に戻せるようにバックアップを用意しておきます。

また、公開作業当日は本番環境での更新作業を停止するなどのルールを決めておくと、安全にリリース作業を進めることができます。

公開直前には、最終的な設定確認を行います。ここでのチェックは、本番サイトとして公開する準備が整っているかを確認するための重要な工程です。主な確認項目は次のとおりです。

・本番URLの設定
テスト環境のURLではなく、本番ドメインが設定されているかを確認します。

・SSL設定
HTTPS通信が正常に動作するかを確認します。SSL設定が正しくないと、ブラウザで警告が表示されることがあります。

・キャッシュ設定
キャッシュ機能が正しく設定されているかを確認します。キャッシュ設定は表示速度に大きく影響します。

・監視・ログ確認
公開後のトラブルに備えて、ログや監視ツールが正常に動作するか確認します。

この段階で問題が見つかった場合は、公開を急がず、テスト環境で再確認することが重要です。

サイト公開後も、必ず最終チェックを行います。公開直後は設定ミスや予期しない不具合が発生することがあるためです。主な確認項目は次の通りです。

・主要導線の確認
トップページ、問い合わせページ、商品ページ、重要なリンクなど、ユーザーがよく利用するページを中心に確認します。

・フォーム送信確認
問い合わせフォームなど、重要な機能が正常に動作するか確認します。

・エラー確認
404エラー（ページが見つからない）、コンソールエラー、JavaScriptエラーなどが発生していないかを確認します。

・速度確認
公開後に表示速度が大きく低下していないか確認します。

・検索エンジン設定
公開サイトでは、検索エンジンに登録される必要がありますが、正しく設定されているかを確認しましょう。この設定を誤ると、検索結果に表示されない、またはテストサイトが検索結果に表示されるなどの問題が発生します。

公開後のチェックまで完了すれば、サイト更新作業は一通り完了です。

テスト環境とは、本番環境とは切り離してWebサイトやシステムの動作を確認するための検証用環境です。企業サイトでは、デザイン変更や機能追加、プラグイン更新、サーバー移行など、さまざまな更新作業が発生します。その際に本番環境で直接作業を行うと、不具合がそのまま公開されるリスクがあります。

テスト環境を用意することで、安全に更新作業を試すことができ、新機能やデザインの検証、バックアップ復元のリハーサル、関係者レビューなどをスムーズに進められます。また近年は、クラウドを前提に本番環境と同等の構成を別環境として用意し、検証後に切り替える運用や、Dockerなどで環境を再現する手法も広く使われています。特に企業サイトでは、公開後のトラブルを防ぎ、安定した運用をつづけるための重要な仕組みとなります。

テスト環境を整備することは、単なる技術的な作業ではなく、企業のWeb運用リスクを減らし、安心してサイト改善を進めるための重要な取り組みといえるでしょう。

「自社開発のテスト品質がなかなかあがらない」、「開発に手いっぱいでテスト要員が不足している」など、テストに関してお悩みなら、SHIFTにお任せください。

SHIFTの「ソフトウェアテスト・第三者検証」をご利用いただければ、SHIFT独自のテストノウハウによりテストプロセスを徹底的に分解、標準化することで、ひとつ上のテスト品質を担保いたします。テストケースをきめ細かく可視化して生産性を向上、網羅性に優れたテストで高い品質を担保、さらに、「売れるサービスづくり」までを見据えた改善提案もいたします。自社開発のテスト品質にお悩みの場合には、お気軽にご相談ください。

＞＞お問い合わせページへ
＞＞料金についてページへ

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座

・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数

――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――