C# & JavaScript

テスト全体計画といっても何を書いてよいかわからないので、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、バージョン番号、変更内容、変更理由、変更日付、変更者、承認日、承認者などを含めます。

Node.js は 基本的に UTF-8 で利用するものなので、他のエンコードを使おうと思うと少し工夫が必要になります。 今回は Shift-JIS を例に他のエンコードを利用する方法についてまとめました。

iconv-lite とは

iconv-lite は Node.js で 文字エンコード変換 を行ってくれるモジュールです。 iconv-lite を使えば Node.js はデフォルトのエンコード以外にも以下のようなエンコードに対応できます。

iconv-lite 対応 エンコーディング (抜粋)

• Node.js デフォルト
  • "ascii"
  • "utf8"
  • "utf16le"
  • "ucs2"
  • "base64"
  • "latin1"
  • "binary"
  • "hex"
• Unicode
  • "UTF-16BE"
  • "UTF-16" (with BOM)
• シングルバイト
  • "cp1252"
• マルチバイト
  • "Shift_JIS"
  • "Windows-31j"
  • "Windows932"
  • "EUC-JP"

Shift-JIS ファイル を 読み込む

サンプルコード

var iconv = require("iconv-lite");
var fs = require("fs");

var buffer = "";

var reader = fs.createReadStream("./data/sample-sjis.txt")
               .pipe(iconv.decodeStream("Shift_JIS"));
reader.on("data", (chunk) => {
  buffer += chunk;
});
reader.on("readable", () => {
  console.log(buffer);
});

解説

iconv.decode() を使う方法もありますが、使い勝手を考えると上記のように .pipe() へ iconv.decodeStream() を渡す方法が便利です。

fs.createReadStream() ではエンコードを指定せず、Bufer で取得する用にします。 Buffer で読み込んだら .pipe() で iconv.decodeSrream() に引き渡します。 戻り値は通常の ReadableStream なので、data イベント を拾えば読み取ったデータを指定したエンコードで変換されたものが取得できます。

Shift-JIS ファイル に 書き込む

サンプルコード

var iconv = require("iconv-lite");
var fs = require("fs");

var buffer = "この文字列を書き込む。";

var writer = fs.createWriteStream("./data/sample-sjis.txt");
writer.write(iconv.encode(buffer, "Shift_JIS"));
writer.end();

解説

.pipe() に引き渡して変換できるとラクなのですが…、書き込みの場合は処理順の都合でうまくいきません。 .write() へ iconv.encode() で変換した Buffer を渡して書き込むことで、指定のエンコードで書き込みができます。

参考記事

• GitHub - ashtuchkin /iconv-lite
• Node.js API Document - Stream
• Node.js API Document - File System

Node.js で テキストファイルを 1行ごと に読み取るサンプルコードを以下に記載、まとめてみます。 いろいろ実装しようかとも思いましたが…実は Node.js のデフォルト機能 readline があったのでそれを使って実装してみます。

サンプルコード

var fs = require("fs");
var readline = require("readline");

var stream = fs.createReadStream("./data/sample.txt", "utf8");

var reader = readline.createInterface({ input: stream });
reader.on("line", (data) => {
  console.log(data);
});

解説

readline を利用すると一行ずつ読み取る機能が使えるようになります。 単独では使えず ReadStream と組み合わせて使います。

L.4
readline は引数に ReadStream を取るので、あらかじめ読み取りたいファイルの ReadStream を生成しておきます。

L.6
readline.createInterface() を使って Readline を作成します。

L.7
作成された Readline インスタンス の line イベントが行を読み取るたびに呼び出されます。 行ごとの処理はこの line イベントで行います。

参考記事

• Node.js API Document - Readline

Node.js で イベント処理の実装を行う場合、 EventEmitter を利用します。 今回はその EventEmitter の使い方として実装方法と利用方法をまとめました。

Node.js におけるイベント処理

一般的に MVCパターン や イベント駆動 プログラム を実装する場合、 observerパターンを利用します。

observerパターン

Node.js ではよく非同期処理を実装しますが、非同期処理でよくイベント駆動パターンが実装されます。 イベント処理はいわゆる先述した observer パターン で実装されますが、Node.js における具体的な実装は EventEmitter になります。

EventEmitterを使った実装例

イベント処理したいクラスは EventEmitter を継承することで基本的なイベント処理が可能になります。 イベントを発行する場合は EventEmitter.emit() を利用して呼び出し、イベントにアタッチするときは EventEmitter.on() でアタッチします。

以下では具体的なサンプルコードを掲載して実装方法と利用方法を見ていきます。

EventEmitter を継承した モジュール の作成

sample.js

var EventEmitter = require("events").EventEmitter;
var util = require("util");

var SampleClass = function () {
};
util.inherits(SampleClass, EventEmitter);

SampleClass.prototype.say = function (message) {
  process.nextTick(()=>{
    this.emit("executed", null, message);
  })
};

module.exports = SampleClass;

L.6
EventEmitter の継承には util.inherits() を利用します。 独自クラスを宣言した後、 util.inherits(子クラス, 親クラス) で指定します。

L.10
EventEmitter を継承すると .emit() メソッドが利用できるようになります。 .emit() メソッドを呼び出すと指定したイベント名のイベントが発行されます。

EventEmitter を継承した モジュール の利用

index.js

var SampleClass = require("./sample");

var obj = new SampleClass();
obj.on("executed", (error, message) => {
  console.log(message);
});

obj.say("Hello World !");

L.3
EventEmitter を継承したクラスはインスタンス生成して利用します。

L.4
生成したインスタンスメソッドに EventEmitter から継承される .on() メソッドがあるので、これを利用することでイベントへコールバックをアタッチできます。

参考記事

• Qiita - EventEmitterの継承方法 (ES5,ES6)
• Node.js API Document - Events