C# & JavaScript

第7世代 NUC に VMware ESXi 6.5 をインストールができたので、ここではどのように行えば Intel NUC7i5BNH に VMware ESXi 6.5 がインストールできるかについてまとめます。 本記事の記載手順で行えばきっとうまくいくハズ！！

準備したもの

組み立て方は別記事で記載しているのでそちらを参照ください。 ここでは揃えたものの概要だけ記載します。 ちなみに、ブート用のUSBメモリは必要なものでした。 2TBのHDDのみで環境構築しようとしたのですが…うまく起動しませんでした。。

• 本体
  • Intel NUC7i5BNH (Intel Core i5-7260U Processor (4M Cache, up to 3.40 GHz)) ( 価格.com )
• メモリ
  • Crucial DDR4-S.O.DIMM (PC4-17000) 16GB × 2枚 [CT2K16G4SFD8213] ( 価格.com )
• ストレージ（ブート用）
  • Buffalo USB3.0対応 USBメモリ 16GB [RUF3-PS16G-BK] ( 価格.com )
• ストレージ（データストア用）
  • Seagate 2.5inch HDD 2TB [ST2000LX001] ( 価格.com )

上記以外で必要なものを以下に記載しておきます。

• キーボード
• マウス
• HDMIケーブル
• モニター（テレビでも可。1024 * 768 を表示できるモニターがおススメ）
• USBメモリ（1GB以上のもの。インストールメディアにするため）

インストールメディア の 作成

インストールメディアはCDやDVDではなくUSBメモリになります。 ここではインストールISOイメージを作成し、そのISOイメージをベースにブート可能なUSBメモリを作成する手順を見ていきます。

1. PowerCLI のインストール
   以下のサイトから Power CLI をダウンロードしてインストールします。

   

2. ワークディレクトリの作成
   適当な場所にインストールメディア作成用のワークディレクトリを作成しておきます。
   今回は C:\work を作成します。

3. PowerCLIの起動
   PowerCLI を 普通に起動すると以下のようなエラーが発生すると思います。

   . : このシステムではスクリプトの実行が無効になっているため、ファイル C:\Program Files (x86)\VMware\
   Infrastructure\PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1 を読み込むことができません。詳細
   については、「about_Execution_Policies」(http://go.microsoft.com/fwlink/?LinkID=135170) を参照して
   ください。
   発生場所 行:1 文字:3
   + . "C:\Program Files (x86)\VMware\Infrastructure\PowerCLI\Scripts\Init ...
   +   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       + CategoryInfo          : セキュリティ エラー: (: ) []、PSSecurityException
       + FullyQualifiedErrorId : UnauthorizedAccess
   

   上記エラーを回避するため、初回は管理者で Power CLI を起動して以下のコマンドを実行します。 以下のコマンドを実行後、再度起動しなおすと通常利用可能になっています。

   Set-ExecutionPolicy RemoteSigned
   

4. ワークディレクトリへ移動
   以下のコマンドでディレクトリ移動します。

   cd C:\work
   

5. インストールISOイメージ作成
   PowerCLI 起動して先ほど作成したワークディレクトリへ移動した上で、以下のコマンドを実行します。 まとめてコピー&ペーストで実行可能です。

   Add-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
   Add-EsxSoftwareDepot http://vibsdepot.v-front.de
   New-EsxImageProfile -CloneProfile "ESXi-6.5.0-20170702001-standard" -name "ESXi-6.5.0-20170702001-NUC7" -Vendor "KabyLake" -AcceptanceLevel "CommunitySupported"
   Remove-EsxSoftwarePackage -ImageProfile "ESXi-6.5.0-20170702001-NUC7" -SoftwarePackage "net-e1000e"
   Remove-EsxSoftwarePackage -ImageProfile "ESXi-6.5.0-20170702001-NUC7" -SoftwarePackage "ne1000"
   Add-EsxSoftwarePackage -ImageProfile "ESXi-6.5.0-20170702001-NUC7" -SoftwarePackage "net-e1000e 3.2.2.1-2vmw.600.3.57.5050593"
   Add-EsxSoftwarePackage -ImageProfile "ESXi-6.5.0-20170702001-NUC7" -SoftwarePackage "sata-xahci"
   Export-ESXImageProfile -ImageProfile "ESXi-6.5.0-20170702001-NUC7" -ExportToISO -filepath ESXi-6.5.0-20170702001-NUC7.iso
   

   ※最新の Image Profile を利用したい場合は virten.net - VMware ESXi Image Profiles に記載された Image Profile に読み替えてください。

6. UNetbootin の ダウンロード
   以下のサイトから UNetbootin をダウンロードします。

   OSDN - UNetbootin (Universal Netboot Installer)

   

   ISOイメージからブート可能なUSBメモリを作成するツールはほかにもいくつかあります。 そのうちの１つ Rufus は UNetbootin より書き込みが速いのが特徴のようです。

7. インストールメディア（USBメモリ）作成
   UNetbootin を起動して以下の設定を行い、「OK」を選択します。

   

8. しばらく待つ…

   

9. 完成

   

ESXi の インストール

1. 作成したUSBメモリを本体にさしてから本体を起動

2. F10 キーを押してブートメニューを表示

3. インストールメディアとなっている「USBメモリ」を選択
   通常のものとUEFIと2種類あると思いますがどちらを選択しても問題ありません。（＝たどり着くところは同じなのでどちらを選択しても変わらない）

4. Welcome to VMware ESXi 6.5.0
   Enter を押して「(Enter) Continue」を選択します。

5. End User License Agreement (EULA)
   F11 を押して「(F11) Accept and Continue」を選択します。

6. Select a Disk to Install or Upgrade
   インストール先のUSBメモリを選択して Enter を押下します。

7. Please select a keyboard layout
   キーボードの種類として「Japanease」を選択して Enter を押下します。

8. Enter a root password
   ESXi へログインする際の root パスワードを設定して Enter を押下します。

9. Confirm Install
   F11 を押下してインストールを開始します。

10. Installation Complete
    インストールが完了したらUSBメモリを抜いて Enter を押下します。

起動と終了に関して2点注意事項があります。

• 起動時は F10 のブートメニューからUSBメモリを選択して起動する
  UEFIのUSBメモリを指定して起動するとうまく起動できませんでした。 BIOS設定で起動順の変更とUEFIの無効化を行うとよいはず（試していないので不明…）。
• 終了時に必ずエラーが表示される
  エラー表示はされますが特に問題はなさそうなので気にせず使っています。

初期設定

初期設定では「BIOSの起動順変更」と「ESXiの固定IPアドレス付与」を行います。 本当は「BIOSの起動順変更」をしておきたかったのですが…テレビモニターでは解像度があわずに表示されず設定できなかったのでここでは割愛します。

ESXi の 固定IPアドレス付与

1. ESXi が起動したら F2 を押下して Customize System/View Logs へ遷移

2. ログイン画面ではインストール時に指定したパスワードを入力

   • Login Name： root
   • Password： （インストール時に指定したパスワード）

3. 「Configure Management Netwwork」を選択して Enter

4. 「IP Configuration」を選択して Enter

5. 「Set static IP address and network configuration」を選択して必要な情報を入力

   • IP Address
   • Subnet Mask
   • Default Gateway

6. 「Configure Managemenet Network」で ESC を押下、確認画面で Y を選択して保存

7. 「System Custoization」で ESC を押下してログアウト

参考記事

• virten.net - VMware Homeserver - ESXi on 7th Gen Intel NUC (Kaby Lake)
• kurobako.com - Intel NUC に ESXi 6.5 を入れる

自宅に仮想環境を構築しようと思い立って趣味で作ってみることにしました。 あまり本格的なサーバーは準備できないので NUC の筐体に ESXi をインストールした環境構築を目指します。

まずは筐体となるサーバーPCの組み立てです。

購入したもの

紆余曲折がありましたが…最終的に揃えたものは以下の4つになります。 キーボード、マウス、HDMIケーブル、モニターも必要ですが組合せは重要でなさそうなのでここでは割愛しています。

• Intel NUC7i5BNH ( 価格.com )
• Crucial DDR4-S.O.DIMM (PC4-17000) 16GB × 2枚 [CT2K16G4SFD8213] ( 価格.com )
• Seagate 2.5inch HDD 2TB [ST2000LX001] ( 価格.com )
• Buffalo USB3.0対応 USBメモリ 16GB [RUF3-PS16G-BK] ( 価格.com )

ちなみに、モニターは自宅にあるテレビを利用したのですが… 1024 × 768 の解像度に対応していないために、BIOS設定画面を開くことができませんでした。 できれば 1024 × 768 を表示できるモニターを用意された方が良いと思います。

組み立て

あまり説明することもないくらい簡単に組み立てられます。 以下に簡単な手順と写真を載せるので参考にしていただければと思います。

1. 裏側のねじ4本を外して蓋を開けます。

   

2. HDDを入れるトレーをずらします。 （ケーブルがつながっているので無理に動かさないよう注意）

   

3. メモリーを2枚差し込みます。

   

4. HDDを差し込んでねじ止めします。 （HDDは入る方向が決まっているのでアダプタの形状を確認してから差し込みます）

   

5. 蓋を戻して最初に外した4本のねじを締めれば完成

   

以上で組み立てまでが終わりです。 電源、キーボード、マウス、モニターをつないで電源ボタンを押せば起動します。 次の記事では今回組み立てたPCに ESXi をインストールしていきます。

テスト計画といっても何を書いてよいかわからないので、IEEE829-2008 や IEEE29119-part3 を参考に「テスト計画」へ書き起こすと良さそうな内容をまとめました。

ここで取り上げている「テスト計画」は「個別のテスト計画」に相当するので、「単体テスト計画」「結合テスト計画」「システムテスト計画」といった工程ごとにドキュメントが作成されるものになります。 工程によって必要なもの必要でないものがあると思いますので、必要なものが最低限記載されるよう修正して使っていただければと思います。

表紙

表紙には一般的なものとして「文書識別番号」「変更履歴」を記載しておきます。

文書識別番号

文書を一意に特定できる番号を付与します。 ドキュメント名、日付、バージョンなどを用いて一意に特定できるようにします。

文書識別番号 の サンプル

• 結合テスト計画_20170827_01　（文書名 + 年月日 + 通番)
• 総合テスト計画_1.0.0　（文書名 + バージョン番号）

変更履歴

初版を作成して以降のすべての変更履歴を残します。 変更履歴には主に以下のような項目を残します。

• No.
• 変更箇所
• 変更内容
• 変更日付
• 変更者
• 承認日付
• 承認者
• 備考

テスト内容

作成しているテスト工程のテスト概要についてこの章でまとめます。

テスト対象機能

テスト対象機能を一覧化します。 テスト対象とする機能、テスト対象外とする機能をここで明らかにしておきます。 この次に記載する「テスト観点」とあわせて「機能観点一覧」を作成してもよいと思います。

テスト観点

該当テスト工程においいて前述の機能に対してどのようなテストを行うか明らかにします。 テスト観点なので品質特性を踏まえた記載になっていると良いかと思います。

テスト観点のサンプル

• 機能
  • 正常系
    • 境界値
    • 表示項目
    • 遷移（状態、画面）
    • 設定（保存、変更、反映）
  • 異常系
    • 異常値
    • エラー処理（ネットワーク、ディスクI/O）
    • 異常操作
  • 組合せ
    • 同時操作
    • 割込み動作
    • 排他制御
• 非機能
  • 性能
    • 処理速度
    • 連続動作
    • 通信帯域
    • 大容量
  • セキュリティ
• ユーザビリティ
• 回帰

テストトレーサビリティマトリクス（テスト追跡表）

上位文書との関連付けを行います。 要件、基本設計とテストケースを関連付けます。

トレーサビリティマトリクス の サンプル

要件ID	ユースケースID	テストケース				…
		CS0101	CS0102	CS0103	CS0104	…
REQ0100	UC0101	○	○	○		…
	UC0102		○			…
	UC0103			○		…
REQ0200	UC0201				○	…
…	…	…	…	…	…

前提と制約

テスト実施を行うにあたっての前提条件や制約条件があれば記載します。 例えば、結合テストであれば前工程の単体テストが終わってないと開始できないでしょうし、テスト実施において環境制約（性能試験なので他からのアクセスはNGなど）があれば記載します。

中断基準と再開基準

テストとは言え、障害が多すぎて進まないとか、これ以上無理にテストを行うとテストデータの破損により次回実施に影響が出るなど テスト実施と障害対応のバランスをどのようにとるかも

例外

テスト対象、テスト観点は上位文書に従って作成しますが、個別テスト設計を作成する中で上位文書の方針とは異なる方針をとる場合、その内容と理由について記載しておきます。 時間的な制約、環境的な制約、機能的な制約など…。

成果物一覧

該当テスト工程で作成する成果物を一覧化しておきます。 ここで一覧化したドキュメントの作成および承認完了が該当テスト工程が完了しているかどうかの判定基準の一つになると思います。 以下に作成するドキュメントの一例を載せます。

成果物一覧のサンプル

• 個別テスト計画（本ドキュメント）
• テスト設計
• テストケース
• テスト実施手順
• テストログ
• 不具合報告
• テスト結果報告
• テスト完了報告

テスト環境

テスト実施を行うにあたっての環境面に関する定義を行います。 主な観点として「必要なデータ」と「必要な設備」という2観点で記載します。

テストデータ要件

テストで利用するデータに関する要件を記載します。 テストデータに複数因子があればテスト観点を踏まえてどの因子を対象にパターン作成するか検討します。 因子水準表はテスト設計で作成すればよいので、ここでは因子の特定までにとどめておきます。

会員データ因子のサンプル

• ユーザーID
• ユーザー名
• 性別
• 年齢
• 郵便番号
• 住所１（都道府県）
• 住所２（市区町村）
• 住所３（番地以降）
• 電話番号（固定）
• 電話番号（携帯）
• メールアドレス

テスト環境/設備/備品要件

テスト実施に必要な環境、設備、備品などについて記載します。 テスト工程にもよりますが、結合テストや総合テストであれば同時並行で複数のテスト観点を実施するのでサーバーも複数必要になったりします（機能の組合せテストを同時にやるためには複数環境必要、機能テストと性能テストは同時に実施したければ複数環境必要…など）。 また、Webアプリケーション開発であれば備品として携帯電話やタブレットなどの実機も必要になるかもしれません。

スケジュール

テスト実施に関わるマイルストーンを定義しておきます。 テスト実施は開発プロジェクトの一部となるので、開発プロジェクトにおける納期についてもあわせて記載しておくと良いと思います。

マイルストーン

「開発プロジェクトにおけるマイルストーン」と「テスト実施におけるマイルストーン」の2観点で整理すると良いと思います。 また、マイルストーンは一覧化されても読み取りづらいので、図示すると伝わりやすいと思います。

• 開発に関するマイルストーン
  • 基本設計完了
  • 詳細設計完了
  • コーディング完了
  • 単体テスト完了
  • 結合テスト完了
  • 総合テスト完了
  • 受入テスト完了
• テストに関するマイルストーン
  • テスト計画完了
  • テスト設計完了
  • テストケース作成完了
  • テスト実施完了
  • テスト結果報告完了

テストタスク

テストを完遂するまでに必要なタスクおよび工数、役割について明確化します。 ここで記載する内容は簡易的なWBSを作るイメージになると思います。

テストタスク一覧、工数見積もり

タスク一覧およびそれぞれのタスクについて工数見積もりを行います。 細かく行なわないまでも概算で見積もりを出しておくことで人員がどれくらい必要かの目安を作ります。

• テスト計画
• テスト設計
• テストケース作成
• テスト手順書作成
• テスト実施
• テスト結果報告書作成

役割、責任

前述のタスク以外に必要な作業カテゴリ（例えば、テスト環境の構築（ネットワーク、サーバー、データベースなど）、データ投入など大きな役割ごと）に担当チームを割り当てておきます。

• テスト設計
• テストケース作成
• テスト環境構築（ネットワーク、サーバー、データベース）
• テストデータ投入
• テスト実施

品質

テスト品質についてまとめます。

メトリクス

テスト実施中に収取するメトリクスについて記載します。

カバレッジ基準

テストケースについてどこまでのカバレッジを満たすべきかをここで定義します。 単体テストであれば C0 / C1 / C2 などと呼ばれるものでしょうか。 結合テストや総合テストであれば条件網羅率を定義することになると思います。

• C0 ： 命令網羅
• C1 ： 分岐網羅
• C2 ： 条件網羅

合否判定基準

各テストケースの合否判定基準を記載します。 基本的には「テストケースを満たす前提および結果が得られること」になると思います。 そもそもですが…「テストケースを満たしていることが誰が見ても明らかになるようなテストケース作成をしておくこと」が前提となります。。

テストケース合否判定基準 の サンプル

• テストケース内容を満たしたテスト前提と実施結果のログが得られていること

テスト完了基準

該当のテスト工程を合格と判断する基準を定義しておきます。 基本的な完了条件は以下になると思います。

テスト完了基準 の サンプル

• すべてのテストケースを実施完了していること
• 重大度が低以外の不具合がすべて解消していること

メンバー

「人」に関する情報を整理します。

必要な人員、期間

前述の「テストタスク一覧、工数見積もり」で算出した必要人員および「マイルストーン」で定義された完了期限をベースにどれだけの要員が必要かを算出します。

必要なスキルセット

テスト実施にあたって必要なスキルがあればここでまとめます。 通常の画面操作だけであれば不要かもしれませんが、データベースへデータ投入したり、Seleniumを使ったり、スマートフォンを利用したりなど特筆すべき必要スキルがあれば人員要件として記載します。

• PL/SQL の作成、実行ができる
• Seleniumを利用した自動テストができる

体制図

テスト実施に関する体制図を作成します。 ここではテスト実施に関わる社内（内部）メンバーに限定した体制図を描きます。 社外（外部）メンバー含めた体制はこの後の「ステークホルダー」にて記載します。

調達の必要性

仮に必要人員が満たせない場合、外部からの調達、外部ベンダーへの委託などを検討します。 やるべきことに対して不足分をここでは整理します。

トレーニングの必要性

人員の中に案件初参画者や若手がいる場合、トレーニングの必要性があります。 調達予定の人員のうちだれに対してどのようなトレーニングをどれくらいの期間で行うかを計画しておきます。

ステークホルダー

組織図

単体テストは内部だけで良いかもしれませんが、結合テストや総合テストであれば外部ベンダーも関わることがあるのでそのような場合は外部ベンダー含めて体制図を作成します。 また、同じ社内でも部署が違うようなケース（企画と開発のような関係）もここで記載します。

コミュニケーション

社内外各所とのコミュニケーション頻度や方法についてまとめます。 ここでは内部向けと外部向けで分けて記載しています。

内部の定例、報告

「メンバー」の「体制図」で定義した体制内での定例や進捗報告の内容についてここで定義します。 実働部隊に近い体制での定例は日次～週次での実施になると思います。 定例以外にも不具合報告のフロー、外部ベンダーへの連絡方法についても整理しておきます。

• 進捗定例
• 不具合報告フロー
• 外部ベンダー問合せフロー

外部の定例、報告

「ステークホルダー」の「組織図」で定義した体制間での定例や進捗報告の内容についてここで定義します。 対外的な報告になるので報告フォーマットがが決まっていれば参照を付けておくと良いと思います。 頻度は週次～マイルストーンまで内部の定例よりもやや長い間隔になるかと思います。

• 進捗定例
• テスト実施完了報告

リスク

テスト実施に関するリスクの特定および対策を検討します。

リスク一覧

プロジェクトに関するリスクは別途管理されているハズなので、ここではテスト実施（計画～完了報告）におけるリスクを洗い出し、その評価まで行います。

リスク対応計画

「リスク一覧」で洗い出されたリスクのうち優先度が高いものについて対応計画を検討します。

一般

本章以降は補足情報をまとめます。

用語集

本ドキュメント内で使用した用語、略語についてまとめます。

参考資料

本ドキュメントに関連する資料があれば社内外に関わらず列挙しておきます。

テスト全体計画といっても何を書いてよいかわからないので、IEEE829-2008 や IEEE29119-part3 を参考に「テスト全体計画」へ書き起こすと良さそうな内容をまとめました。 このレベルのドキュメントをどれくらい書く機会があるのか…という疑問もありますが、必要となったとき考えるのでは遅いので、今回のまとめを作成しました。

ここで取り上げている「テスト全体計画」は「プロジェクト全体を通してどのようなテストを行うかを定義するもの」で、１プロジェクトで１計画作成されるイメージのドキュメントになります。

表紙

一般的な表紙を付けておきます。

文書識別番号

文書が一意に特定できる番号を付与します。 基本的な命名規則はより上位の文書（プロジェクトの全体方針的なドキュメント）で定義されているハズなので、それに従って番号を振っていくことになると思います。 会社ルールまたは部署ルールが決まっていたりもするので確認してみると良いと思います。

変更履歴

表紙には一般的な変更履歴を残します。 以下のサンプルには承認者、承認日が含まれていませんが、必要に応じて追加してください。 このあたりの記載項目は他のドキュメントでも同じです。

変更履歴 の サンプル

No.	変更箇所	変更内容	Ver.	変更日	変更者	備考
1	システム概要 テスト観点	性能観点を追加	1.0.1	8/20	田中
…	…	…	…	…	…	…

システム概要

テスト概要へ入る前にテスト対象となるシステムについてまとめておきます。

システム全体像

テスト対象システムの全体像を記載します。

重要機能

先述の「システム全体像」で描いたシステムのうち、重要な機能がどこであるかを記載します。 ここで記載した重要機能はこの後の「テスト項目選定優先度」に反映されます。

何をもって「重要」と定義するかは難しい気もしますが… リスク管理と似たような考え方で「影響度」と「利用頻度」の2軸に分解して考えると良い気がします。 「影響度」がまだ抽象的なのでもう少し分解するとすれば、業務的な観点で「品質」「コスト（金銭的な利益or損失）」「納期」などにどれだけインパクトがあるかを基準にするとよいと思います。

テスト概要

テスト全体に関わる方針をこの章でまとめます。 内容は多岐にわたりますが、基本方針となるので重要な情報が多くあります。

サブプロセス定義

テスト全体計画におけるサブプロセス定義ではどのようなテスト工程を実施するか定義します。 定義されるテスト工程のサンプルをいかに載せます。 「テスト」と言われると「動的テスト（＝実際にアプリを動かして確認するテスト）」をイメージしやすいですが、「静的テスト（＝レビュー）」もテストに含めて考えます。

テスト工程のサンプル

• 要件定義レビュー
• 基本設計レビュー
• 詳細設計レビュー
• ソースコード静的検査、レビュー
• 単体テスト
• 結合テスト
• 総合テスト
• 受入テスト

テスト観点

テスト対象となるシステムまたは機能に対するテスト観点を整理します。 品質特性なども参考にテスト観点を洗い出します。 以下にテスト観点のサンプルを載せます。

テスト観点のサンプル

• 機能
  • 正常系
  • 異常系
  • 組合せ
• 非機能
  • 性能
  • セキュリティ
• ユーザビリティ
• 回帰

テスト項目選定優先度

テスト項目を作り始めると観点や組合せが多いため際限なく膨らみます。 そのようなときに何を基準として選定していくかの優先度をここで定義しておきます。 基本的には前述の「重要機能」で取り上げた箇所を中心に、機能の重要度と利用頻度を観点にテスト対象を選定することになると思います。 優先度の付け方のサンプル図を以下に記載します。

あくまで個人的な意見ですが… 「利用頻度が高く重要度（命に係わる、金銭的な損失に関わる…など）が高い機能」が最も優先度が高いのは明らかですが、 Webアプリケーション開発だと「利用頻度が高く重要度が低い機能」と「利用頻度は低いが重要度が高い機能」でどちらを優先するかというと「利用頻度が高く重要度が低い機能」を優先します。 人の目につきやすい機能が正しく動いていた方が「当たり前品質」を保つことにつながる、つまりユーザー離れを防ぎやすいと思います。

テストスケジュールサマリ

開発全体およびテスト実施に関するマイルストーンを整理します。 開発工程上の開始/完了日付や、設計情報のインプットが必要な日付、テスト実施完了報告を行う日付などがマイルストーンになると思います。 前述のマイルストーンは一覧でも良いですが、時系列に並べた以下のような図を描いた方が分かりやすいと思います。

テストスケジュールのサンプル

リソースサマリ

人、環境（サーバー、クライアント）、データなど必要なリソースを記載します。

人はテスト工程ごとにおおよその工数を見積もります。

環境はテストを並列実行するかどうかを踏まえて必要な環境数を見積もります。 例えば結合テストにおいて機能テスト、性能テスト、脆弱性テストを同時にはできないので3環境ないし実施時期をずらすことを考えます（1環境で時期をずらす場合は環境のバックアップ、リカバリ、構築の時間も忘れずに！）。

データ観点では受入テストで本番相当のデータを持ってくるのであれば個人情報のマスキング、抜き出すことに関する手続きなどを考えておく必要があります。

体制、ステークホルダー

開発、テスト、関係各社をまとめた体制図を描きます。 以下にいくつかパターンを記載します。

体制図 (会社レベルの概要図) サンプル

体制図 (会社をまたぐ内部も含めた概要図) サンプル

体制図 (自社内のみの概要図) サンプル

コミュニケーション

前述の体制図で引かれた線の数だけコミュニケーションが存在します。 それぞれに対して「定例（進捗報告）」、「不具合報告」、「障害対応」、「課題対応」などをどのような方法で対応するか決めておきます。 ちなみにコミュニケーション手段は以下のようなものがあります。 どのメンバーに対してどのような頻度でどのコミュニケーションを取るかを定義します。

コミュニケーション手段の例

• 相互型コミュニケーション
  • 対面打合せ
  • 電話会議
  • テレビ会議
  • チャット
  • BTS (Bug Tracking System)
• プッシュ型コミュニケーション
  • メーリングリスト
• プル型コミュニケーション
  • 掲示板

責任

テストタスクに関する責任の所在を明らかにします。 RACIチャートを作るとわかりやすいと思います。 以下にサンプルを載せます。

テストタスク RACIマトリクス サンプル

	オーナー	マネージャー	リーダー	メンバー
進捗	A	R
品質	A	R
課題		A	R
テスト計画		A	R
テスト設計		I	A	R
テストケース作成		I	A	R
テスト実施手順書作成		I	A	R
テスト環境準備		I	A	R
テストデータ準備		I	A	R
テスト実施		I	A	R
不具合対応		I	A	R
テスト結果報告	A/I	A	R

メトリクス

テスト実施中に収集するメトリクスを定義しておきます。 主には進捗（テスト実施、不具合対応）と品質（アプリ自体の品質、テストケースの品質）になるかと思います。

メトリクス の サンプル

• 進捗（テスト実施）
  • テストケース消化率
  • 累積不具合件数（信頼度成長曲線）
• 進捗（不具合対応）
• 不具合除去率
• 不具合対応日数
• 品質（アプリケーション）
  • 機能別不具合検出累積数
  • 重要度別不具合検出累積数
  • 原因別不具合検出累積数
• 品質（テストケース）
  • 不具合発見率

不具合管理

不具合の発見から解決までのプロセスを定義します。 不具合報告方法はBTSへ起票かエクセルへ起票と言ったところでしょうか。 不具合解決のプロセスサンプルは以下に載せます。 大きなプロジェクトであれば、各プロセスについて具体的な手順（例えば不具合報告を起票するとき書いてほしい内容など）まで書いておいた方が無難かもしれません。

不具合対応フロー の サンプル

リスク管理

テスト実施に関するリスク管理を行います。 リスクの洗い出し、評価（発生確率と影響度の設定）、優先度の確定、対策の検討を行います。

リスク管理 の サンプル

No.	リスク内容	発生率	影響度	優先度	対応内容
1	結合テスト開始時までにモジュールAが完成しない	90%	60%	A	モジュールAに関する結合テスト実施スケジュールを後ろ倒しにしておく。
2	…	…	…	…	…

自動化、ツール

テスト自動化ツールやログ収集ツール（画面キャプチャをとるツール）など、利用するツールがあれば記載します。 以下にいくつか例を載せます。

テスト自動化ツール の 例

• JUnit
• Selenium
• Jmeter
• Jenkins

サブプロセス定義（個別定義）

前述「サブプロセス定義」で定義したプロセス単位に作成します。 内容的に前述の内容と被る部分が多くあります。 開発アプリケーションや要件によって内容が変わってくるので、必要に応じて記載または省略を行ってください。

開始基準、完了基準

テスト開始基準とテスト完了基準を決めておきます。 特に開始基準については前提や制約も考えられるので、それらも踏まえて明記しておきます。 テスト環境構築とデータ投入はテスト実施に含まれそうな気もしますが…以下のサンプルではテスト前提として記載しています。

結合テスト 開始基準/完了基準 の サンプル

• 開始基準
  • テスト対象モジュールすべての単体テストが完了しておりすべての障害が解消していること
  • 機能テスト環境の構築が完了していること
  • テスト実施に必要なデータ投入が終わっていること
• 完了基準
  • 実施予定の結合テストがすべて完了していること
  • 発生した不具合がすべて解消していること

テスト観点

基本は前述の「テスト観点」でも記載しているので、ここでは各テスト工程別に気にする観点があれば記載します。 ここでは前述と内容が被るので詳細は割愛します。

テスト環境

テスト実施環境について記載します。 単体テストは不要かもしれませんが…結合テスト以降については環境定義が必要になってきます。 以下にサンプル図を載せます（本当はIPアドレスも記載しておくと良いかもしれません）。

結合テスト環境 の サンプル

ドキュメント

作成するドキュメントについて定義します。 各テスト工程も似ていると思います。 以下にサンプルを記載します。

ドキュメント の サンプル

• テスト計画
• テスト設計
• テストケース
• テスト実施手順
• テストログ
• 不具合報告
• テストケース実施結果報告
• テスト完了報告

収集メトリクス

前述「メトリクス」とほぼ同等になるかと思います。 ここでは前述と内容が被るので詳細は割愛します。

回帰テスト

新規開発でなく改修案件であれば回帰テストについて考えます。 どの機能のどの範囲をテストするか定義します。 ここでは機能観点一覧を作成すると良いと思います。

一般

以降は補足情報を載せます。

用語集

テスト計画で利用する用語、略語についてまとめます。 以下に用語集のサンプルを載せます。

用語集 の サンプル

用語	説明
LTP	Level Test Plan の略。個別テスト計画書のこと。
不具合	障害（アプリケーションの障害、テストケースの障害）と誤報告の切り分けができていない課題。
…	…

参考資料

内部ドキュメント、外部の参考資料など、テスト全体計画を作成するために必要になった関連資料をまとめておきます。

参考資料 の サンプル

• 内部
  • プロジェクト企画書
  • 品質保証計画
• 外部
  • IEEE 829-2008
  • IEEE 29119 part3

今回はかなり重厚長大なポストとなってしまいました… 分割するわけにもいかなかったので仕方ないのですが、目次を利用して効果的に参照していただければと思います。

IEEE829-2008 個別テスト計画 (Test Plan) について、Webアプリケーション開発をベースにどのようなことを書いたら良いかが見当たらないのでまとめてみました。

イントロダクション

文書識別番号

文書を特定する番号を付与します。 「文書の略号＋バージョン番号」が一般的な付け方でしょうか。 「結合テスト計画」であれば「ITP (Integrated Test Plan)」、 「バージョン番号」は セマンティックバージョニング でつけるなら「v1.0.0」のような感じで あわせると「ITPv1.0.0」と言った感じになるかと思います。

対象範囲

テスト対象の機能やコンポーネントが何かを記載し、それぞれについてどのようなテストを実施するのか記載します。

参考資料

テスト実施にあたって必要となるテスト計画や設計、マニュアルなどへの参照先をまとめます。

テスト全体から見た位置づけ

様々なテスト工程、テスト種別がある中で、本ドキュメントが対象とするテストがどのような位置づけのものかを示します。

テストクラスとテスト条件の全体像

「対象範囲」で記載したテスト内容について詳細化します。 正常系、異常系、境界値、探索的テストなど。

テスト計画詳細

テスト項目と識別番号

具体的なテスト項目を列挙して、各テスト項目に識別番号を付与しておきます。 不具合報告ではこの識別番号を用いて報告を行います。

テスト追跡表

要件とテスト項目の関連付けを行います。 これにより、どこがテストされどこが範囲外かを明らかにします。

テスト対象機能

テスト対象とするコンポーネント、コンポーネントの組合せ、システム機能について記載します。 テスト対象外とする機能についても同様に記載しておきます。

テストアプローチ

前述の「テスト対象機能」に対してどのような「テスト観点」でテストを行っていくかを記載します。 一般的には「テスト対象機能」と「テスト観点」を表にした「テストマトリクス（機能観点一覧）」を作っていきます。

テスト項目の合否基準

各テストの合否基準を定義します。 一般的には重大度別の不具合件数を基準とします。 例えば「重大度高の障害が1件もない」など。

中断基準および再開要件

テスト実施をすべてまたは部分的に中断する基準を決めます。 また、テストを再開する基準についても定義しておきます。

テスト成果物

テスト実施により作成される成果物を定義します。 以下のようなものが想定されると思います。

• テスト計画
• テスト設計
• テストケース
• テスト実施手順
• テストログ
• 不具合報告
• テスト結果報告
• テスト完了報告

テスト管理

計画されたテストタスク

テスト実施に関する前準備や実施、結果報告など、必要なタスクを明確化します。 テスト項目、リソース、期日などの制約を明らかにします。

環境 / 設備

テスト環境および必要なデータについて記載します。 ハードウェア、ツール、データベース、ログイン情報などテスト実施に必要なものを記載します。 また、テスト実施前に準備が必要なこと、テスト実施後に必要なことも記載します。

責任と権限

管理、設計、ケース作成、実行、評価、不具合対応などのテストタスクに対して誰が行うか（誰の責任として実行されるか）を明確にします。

関係者間のコミュニケーション

テスト実施における個人やグループの間のコミュニケーション方法を定義します。 図示するとわかりやすいと思います。

リソース分配

テスト実施に必要なリソースについて記載します。 内部で調整されるのか、外部から調達するのかについても記載します。

トレーニング

スキルレベルに応じたトレーニングの必要性について記載します。 また、そのトレーニング方法（講義形式、e-learning など）についても記載します。

スケジュール、見積もり、コスト

本節ではテスト実施に関わるマイルストーンを含みます。 テストタスク実施に必要な工数を見積もり、リソースがどの期間どの程度必要かを明らかにします。

リスクと対応策

テスト実施にあたってのリスクがあれば明らかにしておきます。 各リスクは影響度と発生確率を求め、それぞれ対応策を検討しておきます。 また、プロジェクト進行状況に応じてステータスを変えていきます。 管理が難しければ外だしして管理してもよいと思います。

一般

品質保証手順

システムが満たすべき品質基準を定義しておきます。 不具合管理や不具合解消状況などへのリンクも含めます。

メトリクス

収集、分析、報告するメトリクスを定義します。 ここで記載するメトリクスは品質保証計画との整合性を保つようにします。

テストカバレッジ

テストカバレッジ要件を定義します。 テストカバレッジはテストケースがどれだけの範囲をカバーしているかを示す指標で、テスト工程ごとに指標は異なります。

用語集

ドキュメント内で利用する単語や略語についてまとめます。

変更履歴

初版が作成されて以降のすべての変更履歴を残します。

今回は IEEE29119 part3 の テスト計画 (Test Plan) をベースにテスト計画に何を書くと良いかについてまとめてみました。 IEEE829-2008 と似ている部分もありますが…微妙に異なるようです。

概要

識別番号

ドキュメントを一意に特定するバージョンを付与します。 バージョンの付け方は セマンティックバージョニング が参考になると思います。

発行団体

テスト計画ドキュメントを発行、責任を持つチームについて記載します。いわゆるドキュメント作成者の名前を書くのが一般的な気がします。

承認権限

いわゆるレビュアー、承認者を記載します。

変更履歴

ドキュメントが発行されてからのすべての履歴を記載します。

イントロダクション

ドキュメントに関する以下のような情報を記載します。

• 範囲
• 参照
• 用語

範囲

ドキュメントが対象とする範囲（含むもの、含まないもの、前提、制限など）を明記します。

参照

システム、ソフトウェア、テストに関するドキュメントの参照先を記載します。 記載する際は社内資料と社外資料を分けて記載します。

用語

ドキュメント中で利用する単語、略語などを列挙します。

テスト条件

サブプロセス

テスト計画に関連するサブプロセスを定義します。

テスト項目

テスト対象とするコンポーネント、モジュールを列挙します。

テスト範囲

上記のテスト項目で対象として取り上げたコンポーネントやモジュールでテストを行う機能を列挙します。 また、テストを行わない機能についても列挙しておきます。

前提と制約

テスト実施を行うにあたっての前提や制約があれば記載します。 時間、コスト、スキル、アクセス権限、ツール、環境など。

ステークホルダー

ステークホルダーの一覧とテストへのかかわり方を記載します。 また、各ステークホルダーとのコミュニケーション方法についても検討します。

コミュニケーション

テスト実施期間中のコミュニケーション方法について記載します。 定例や関係各所への報告のタイミングなど。

リスク登録簿

テスト実施にあたってのリスク洗い出しを行います。 よくあるリスク洗い出しと同様に「インパクト」と「発生確率」でリスク判定を行います。 リスクは「製品」と「プロジェクト」の2観点で洗い出します。

製品リスク

「製品」に関するリスクを洗い出します。 テスト対象製品のデグレ、性能など。

プロジェクトリスク

「プロジェクト」に関するリスクを洗い出します。 リソースやスケジュールなど。

テスト戦略

サブプロセス

テスト実施するための必要なサブプロセスを定義します。 イメージ的には何をやらなければいけないかタスク分割していったツリーを作る感じでしょうか。 タスクについては後の節で記載するのでここでは大枠だけ記載します。

成果物

テスト実施した結果作られる成果物を定義します。 大まかには以下のようなものがあるかと思います。

• テスト計画
• テスト設計
• テストケース
• テスト実施手順
• テストデータ要件
• テスト環境要件
• 不具合報告
• テスト実施結果報告
• テスト完了報告

設計技法

どのようなテスト技法（境界値、デシジョンテーブル、状態遷移など）を適用するか定義します。

完了基準

何をもってテスト完了とするかを定義します。 テストカバレッジが一定以上となっており検出された不具合が一定数以下まで解消している、など。

収集するメトリクス

テスト実施時に収集するメトリクスを定義します。

テストデータ要件

テスト実施するために必要なテストデータ要件を記載します。 ここではサブプロセスで使われるものすべてに対して記載しておきます。

テスト環境要件

テスト実施するために必要なハードウェア、ソフトウェア、ツール、データベース、人材、環境などを記載します。

再テストおよび回帰テスト

どの回帰テストを行うか定義します。

テスト中断および再開条件

テスト毎または全体を通して中断および再開する条件があれば記載します。 人命危害やデータ損失など大きな問題が出そうな場合を想定した条件になると思います。

例外

各テスト計画はプロジェクトのテスト計画や品質保証に従って作成されます。 それらに則らない例外的なものがあればその内容と承認者について記載しておきます。

テストタスクおよび見積もり

テスト実施に必要なすべてのタスクを洗い出します。 また、各タスクの工数も見積もっておきます。

実施メンバー

役割、タスク、責任

テスト実施に関わる各チームのリーダー、サブリーダー（サポート役）について記載します。 また、各テスト項目に対する責任についても割り当てを行います。 各メンバーの必要期間についても記載します。

雇用の必要性

追加のテスト実施要員が必要かどうかを記載します。 いつ必要で、一時的でよいのかパートなのかフルタイムなのか、必要とするスキルは何かなどを明らかにします。

トレーニングの必要性

テスト実施メンバーとして必要なスキルを明らかにし、必要なトレーニングが何であるかを明確にします。

スケジュール

テスト計画上のマイルストーンを定義します。 テスト実施結果を開発チームや関連部署へ報告する期日をまとめておきます。 マイルストーンは利用可能なリソースや制約を踏まえて見積もります。

IEEE829-2008 Standard for Software and System Test Documentation に記載されている内容をベースに、テスト全体計画 (Master Test Plan) でどのようなことを記述すると良いかをまとめてみました。 以下の「目次」は IEEE に従って記載していますが、内容についてはWebアプリケーション開発を前提にかなり内容を仕立て直しています。 オリジナルは IEEE 829-2008 をご参照ください。

概要

文書識別番号

ドキュメントバージョンを一意に特定できる番号を記載します。 日付、連番、ステータス（ドラフト版、レビュー版、修正版、最終版）などを記載するのが一般的でしょうか。 もし連続したバージョン番号を振るのであれば セマンティックバージョニング が参考になるか思います。

対象範囲

ソフトウェアテストの目的、目標および実施範囲について記載します。 実施範囲としては、テスト範囲に含む仕様、含まない仕様、前提、制約についても記載します。

参考資料

必要な参考資料をすべて列挙します。 参考資料とするのは内部資料、外部資料に関わらずすべて列挙します。 以下に外部資料および内部資料の例をあげます。

外部資料の例として以下のようなものがあります。

• 外部資料
  • 法律
  • 規制
  • 標準
• 内部資料
  • プロジェクト計画
  • 品質管理計画
  • 構成管理計画

システム概要

スクラッチ開発（新規のパッケージ開発含む）であれば、テスト対象システムの業務目的、主要な機能について記述します。 パッケージ開発やエンハンス開発であれば、テスト対象（手を加えている箇所）の要件概要も記載しておくのが良いと思います。 別資料がある場合は別資料への参照を記載しておくことで代用もできます。

テスト概要

テスト実施に必要な以下のような内容を記載します。

• 推進体制
• テスト日程
• 完全性レベル
• リソース
• 責任
• ツール、テスト技法、手順、メトリクス

推進体制

テストプロセスにおける開発、プロジェクト管理、品質保証、構成管理など他チームの関わりを記述します。 起票された不具合の解決方法、テスト仕様およびテストプロセスの承認など、テストチームのコミュニケーション方法もここに含みます。

• 体制図
• コミュニケーション方法
• 作業フロー
  • テスト仕様書作成から承認までのフロー
  • テスト実施からレポート作成、承認までのフロー
  • 不具合起票から解決までのフロー

テスト日程

プロジェクトライフサイクル中のマイルストーンについて記載します。 プロジェクトの全体スケジュールを踏まえて、各テストの開始終了、別チーム（品質保証、構成管理など）へのフィードバック期日があればその日程などをマイルストーンとして定義しておくと良いと思われます。

完全性レベル

「完全性レベル」とは、障害発生したときシステムを利用するユーザーに対してどれくらいの影響度があるか（致命的（人命にかかわるレベル）なのか、重大な損害をこうむるレベルなのか…）の定義のようです。 ここで定義するシステムの完全性レベルによって作成するドキュメントの種類を変えます（＝ユーザーへの影響度が大きければ多くのドキュメントを準備して万全の体制を整えますが、あまり影響度が大きくないようであれば割愛することを検討します）。

リソース

リソースと言われると「人」をイメージしてしまいがちですが…実施メンバー以外に、環境（放射線や電磁波を使うようであれば特殊な環境が必要）、機材、ツール、特別な手続き（セキュリティ、アクセス権、ドキュメントなど）についても記載します。

責任

テストタスク毎に主担当と副担当（サポート役）を決めます。 イメージ的にはPMBOKで言うところの RACIチャート を作る感じでしょうか。 この節は概要なのであまり細かく書かずに主だったタスクのみにフォーカスして記載するのが良いと思われます。

ツール、テスト技法、手順、メトリクス

テスト実施をするために必要なドキュメント、ハードウェア、ソフトウェア、テストツール、テスト技法、手順、メトリクスについて記載します。 また、各ツールやテスト技法、手順に関する習得、サポート、必要な資格についても記載します。

全体テスト計画詳細

テストプロセスの定義

WBS (いわゆるガントチャート) の作成と各タスクの定義を行っていきます。 主だったタスクリストのサンプルと各タスクの定義で記載する観点について以下に載せます。

タスクリスト

• 要件定義
  • 受入テスト計画
  • 総合テスト計画
• 設計
  • 受入テスト設計
  • 総合テスト設計
  • 結合テスト計画/設計
  • 単体テスト計画/設計
• 実装
  • 受入テストケース/実施手順
  • 総合テストケース/実施手順
  • 結合テストケース/実施手順
  • 単体テストケース/実施手順/実施/結果報告
  • テスト準備状況の確認
• テスト
  • 結合テスト実施/結果報告
  • 総合テスト実施/結果報告
  • 受入テスト実施/結果報告
• リリース
  • リリース実施手順/実施/結果報告

タスク定義のひな形

項目	説明
タスク名	タスク内容が分かるような名称を定義します。
内容	各タスクの詳しい実施方法、進め方について記載します。 テスト実施結果であれば評価方法についても記載します。
インプット	必要となるインプット（どのタスクのアウトプットを利用するか）について記載します。
アウトプット	タスクのアウトプットを定義します。 タスクのアウトプットは他のタスクのインプットとなります。
スケジュール	各タスクのスケジュールを記載します。開始または完了、必要なインプットの受領、アウトプットの提供といったマイルストーンを組み立てます。 WBSを作成するのであれば、スケジュールはその中に含まれるので個別に記載する必要はなくなります。
リソース	タスク実施に必要なリソース（ツール、設備、機材、事前トレーニングなど）を定義します。
前提と制約	テストタスクを実施する前提条件および制約を記載します。

テスト文書要件

作成するドキュメントの一覧およびそれらテストドキュメントに関する、目的、フォーマット、目次などを記載します。 作成されるドキュメントとしては以下のようなものが考えられます。

• 全体テスト計画
• 個別テスト計画（受入テスト計画、総合テスト計画…など）
• テスト設計
• テストケース
• テスト実施手順
• テストログ
• 不具合報告
• テスト結果報告
• 総合テスト結果報告

テスト管理要件

一口に「管理」といってもいろいろありますが…定義したメトリクス（進捗、品質）の推移、不具合の管理でしょうか。 ここでは、管理対象とするメトリクスとその拾い方、不具合報告および解決のプロセス、例外を許すのであればそのポリシーなどを定義しておきます。

• 不具合の検出から解決までのフロー
• テスト進捗状況の把握（メトリクス）
  • テスト実施進捗（ケース消化率、実施効率など）
  • 不具合発見状況（不具合検出率、不具合収束状況、不具合目標達成率など）
  • 不具合対応状況（不具合対応日数、不具合除去率など）

テスト報告要件

すべてのテスト報告書に関してその目的、目次、フォーマット、受領者、タイミングを明らかにします。 テスト報告には テストログ、不具合報告、中間報告、各レベルテスト報告、 テスト総合報告が含まれます。

一般

用語集

テスト全体計画 (Master Test Plan) で用いられる用語および略語について定義します。

変更履歴

テスト全体計画に対する修正、承認について記載します。 変更履歴には、テスト全体計画 （Master Test Plan） が作成されて以降に発生するすべての変更ログを含めます。 変更履歴はよくある内容なので改めて書くまでもないですが…記載内容としては、ドキュメントID、バージョン番号、変更内容、変更理由、変更日付、変更者、承認日、承認者などを含めます。