galife

個別テスト計画書のサンプル

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

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

テスト計画

表紙

文書識別番号
変更履歴

テスト内容

テスト対象機能
テスト観点
テストトレーサビリティマトリクス（テスト追跡表）
前提と制約
中断基準と再開基準
例外
成果物一覧

テスト環境

テストデータ要件
テスト環境/設備/備品要件

スケジュール

マイルストーン

テストタスク

テストタスク一覧、工数見積もり
役割、責任

品質

メトリクス
カバレッジ基準
合否判定基準
テスト完了基準

メンバー

必要な人員、期間
必要なスキルセット
体制図
調達の必要性
トレーニングの必要性

ステークホルダー

組織図

コミュニケーション

内部の定例、報告（どのタイミング、どのような方法…相互、プッシュ、プル）
外部の定例、報告（対ステークホルダー向け）

リスク

リスク一覧（リスク、影響度、発生確率）
リスク対応計画

一般

用語集
参考資料

表紙

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

文書識別番号

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

文書識別番号のサンプル

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

変更履歴

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

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

テスト内容

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

テスト対象機能

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

テスト観点

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

テスト観点のサンプル

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

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

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

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

要件ID	ユースケースID	テストケース				…
要件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 テスト計画 (Level Test Plan)

IEEE29119 テスト計画 (Test Plan)

IEEE829 テスト全体計画（Master Test Plan）

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

テスト全体計画 (Master Test Plan)

概要
全体テスト計画詳細
一般
1. 用語集
2. 改訂履歴

概要

文書識別番号

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

対象範囲

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

参考資料

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

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

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

システム概要

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

テスト概要

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

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

推進体制

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

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

テスト日程

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

完全性レベル

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

リソース

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

責任

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

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

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

全体テスト計画詳細

テストプロセスの定義

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

タスクリスト

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

タスク定義のひな形

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

テスト文書要件

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

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

テスト管理要件

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

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

テスト報告要件

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

一般

用語集

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

変更履歴

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

Node.js で Shift-JIS ファイルを読み書きする方法

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

iconv-lite とは
Shift-JIS ファイルを読み込む
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 を渡して書き込むことで、指定のエンコードで書き込みができます。

参考記事

Node.js でテキストファイルを一行ずつ読み込む方法

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 の使い方

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

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() メソッドがあるので、これを利用することでイベントへコールバックをアタッチできます。

参考記事

Node.js で再帰的にディレクトリを作成する方法

npm にあがっているソースが Promise に対応していなかったので、 Promise 対応版を作ってみました。こういうのは本当は pull request するものなんでしょうが… 名前がいろいろ被っていてアップロード難しかったのでこのままここに貼り付けておきます。

ソースコード（mkdir-r）
APIドキュメント
使い方

ソースコード（mkdir-r）

ソースコードは以下に記載のものですべてなので、以下のコードをコピペすれば使えます。

mkdir-r.js

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

/**
 * Make specified directory recursively.
 * @param {string} url Directory or file path.
 * @param {number} [mode] Accessibility.
 */
var makeDirectoryRecursivelySync = function (url, mode) {
  var dir = "";
  var list = path.normalize(url).split(path.sep);
  var max = list.length - 1;

  dir = list.slice(0, max).join(path.sep);
  try {
    fs.mkdirSync(dir, mode);
  } catch (error) {
    if (error.code === "ENOENT") {
      makeDirectoryRecursivelySync(list.slice(0, max - 1).join(path.sep) + path.sep, mode);
      fs.mkdirSync(dir, mode);
    } else {
      throw error;
    }
  }
};

/**
 * Asyncronouse make specified directory recursively.
 * @param {string} url Directory or file path.
 * @param {number} [mode] Accesibility.
 * @param {function} callback Callback function which called when directories creation is completed.
 */
var makeDirectoryRecursivelyAsync = function (url, mode, callback) {
  var main = function (url, mode, callback) {
    if (typeof (mode) === "function") {
      callback = mode;
      mode = undefined;
    }

    var dir = "";
    var list = path.normalize(url).split(path.sep);
    var max = list.length - 1;

    dir = list.slice(0, max).join(path.sep);
    fs.mkdir(dir, mode, (error) => {
      if (error) {
        if (error.code === "ENOENT") {
          makeDirectoryRecursivelyAsync(list.slice(0, max - 1).join(path.sep) + path.sep, mode, (error) => {
            fs.mkdir(dir, mode, callback);
          });
        } else {
          throw error;
        }
      } else {
        callback && callback(null);
      }
    });
  };

  if (callback) {
    main(url, mode, callback);
  } else {
    return new Promise((resolve, reject) => {
      main(url, mode, (error) => {
        if (error) {
          reject(error);
        } else {
          resolve(null);
        }
      })
    });
  }
};

module.exports = makeDirectoryRecursivelyAsync;
module.exports.sync = makeDirectoryRecursivelySync;
module.exports.async = makeDirectoryRecursivelyAsync;

API ドキュメント

mkdir-r(url, mode, callback)

非同期で指定されたディレクトリまで再帰的に作成します。

引数

url: 再帰的に作成したいディレクトリパスを指定します。最後のセパレータ / までをディレクトリとして認識します。例えば "/a/b/c" であれば c はファイルとして認識するので、作成されるディレクトリは a および b になります。
mode: 作成するディレクトリのアクセス権を設定します。
callback(error): 作成が完了したとき呼び出されます。引数はエラーオブジェクト error のみです。

戻り値

Promise: コールバックが設定された Promise オブジェクトを戻します。

使い方

単純に作成するだけであれば以下のようなコードになります。

var mkdir = require("./mkdir-r2.js");

mkdir("/data/write1/hoge/foo/bar.txt");

作成した後に何かしたい場合はコールバックを指定します。

var mkdir = require("./mkdir-r2.js");

mkdir("/data/write1/hoge/foo/bar.txt", (error) => {
  if (error) {
    console.log(error.message);
    return;
  }
  console.log("complete");
});

ファイル / ディレクトリの存在確認

ファイル / フォルダの存在確認を行うには fs.stat() または fs.access() を利用します。詳細は後に記載しますが、フォルダを確認した後にファイル読み書きを行うのであれば fs.access() でアクセス権含めて確認するのが良さそうです。

ということで、ここでは fs.access() でのフォルダ存在確認のサンプルコードを載せます。

サンプルコード

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

var filepath = "./data/message.txt";

var dirname = path.dirname(filepath);

fs.access(dirname, fs.constants.R_OK | fs.constants.W_OK, (error) => {
  if (error) {
    if (error.code === "ENOENT") {
      fs.mkdirSync(dirname);
    } else {
      return;
    }
  }

  fs.writeFile(filepath, "Hello World !", "utf8", (error) => { });
});

解説

第1引数にアクセス可能か確認したいフォルダまたはファイルへのパスを指定し、第2引数に確認したいアクセス権を指定します。確認が終わると第3引数で指定されたコールバックが呼ばれます。第3引数のコールバックはエラーオブジェクト error のみを引数とするメソッドです。指定したファイルまたはフォルダに対して指定されたアクセス権がある場合はエラーオブジェクトが設定されず、それ以外の場合にエラーオブジェクトが設定されます。

第2引数で指定できるアクセス権種別は以下の通りです。

種別	説明
`fs.constants.F_OK`	ファイルが存在しているかどうかを判定します。ファイルに対するアクセス権は考慮しません。第2引数のアクセス権に関する設定を省略した場合のデフォルトは `fs.constants.F_OK` になります。
`fs.constants.R_OK`	実行プロセスから読み取り権限があるかどうか。
`fs.constants.W_OK`	実行プロセスから書き込み権限があるかどうか。
`fs.constants.X_OK`	実行プロセスから実行権限があるかどうか。

ファイルまたはフォルダへアクセスした際に想定される代表的なエラーは以下の通りです。

error.code	説明
`"ENOENT"`	該当するファイルまたはフォルダがありません。
`"EPERM"`	操作する権限がありません。
`"EBUSY"`	リソースが処理中またはロックされています。

fs.stat() vs fs.access()

Node.js の APIドキュメントを読んでいると、フォルダの存在確認を行うには fs.stat() または fs.access() を利用するよう書かれています。それぞれのメソッドでできることは次の通りです。

fs.stat(): 指定されたファイルやフォルダの情報（ステータス）を取得するメソッド
fs.access(): 指定されたファイルやフォルダへ実行ユーザーがアクセス可能かどうかを確認するメソッド

このことから考えると、一般的にファイルやフォルダの存在チェックは fs.access() を使うのが良さそうです。

ファイル読み書き前の存在確認

Node.js APIドキュメントでは次のようなことも記述されています（原文は英語ですが、以下は原文の英語を日本語訳したもの）。

fs.open() 、 fs.readFile() 、 fs.writeFile() を呼び出す前に fs.access() を使ってファイルへのアクセス権を確認することは推奨されません。 2つの処理の間（「アクセス権の確認」と「ファイル実処理」の間）で他のプロセスがファイルの状態を変更する可能性があるため、前述のような実装を行うとレースコンディションを引き起こします。代わりに、ファイルの open / read / write を直接行い、ファイルアクセスできなかった場合に発生する例外を処理する必要があります。

Node.js API Document - fs.access()

つまり「アクセスできるか確認してからアクセスする」ではなく「とりあえずアクセスしてダメだったら例外処理する」という考え方で実装を行うことが推奨されているようです。これを具体的に実装してみると以下のようになります。

サンプルコード (ファイル読み込み)

var fs = require("fs");

fs.readFile("./data/test.json", "utf8", (error, data) => {
  if (error) {
    console.log(error.message);
    throw error;
  }
  console.log(data);
});

サンプルコード (ファイル書き込み)

var fs = require("fs");

fs.mkdir("./data/", (error) => {
  if (error && error.code !== "EEXIST") {
    console.log(error.message);
    throw error;
  }
  fs.writeFile("./data/message.json", data, "utf8", (error) => {
    if (error) {
      console.log(error.message);
      throw error;
    }
  });
});

今回の記事は参考になったでしょうか？ファイル / フォルダの存在確認のポイントは以下のようになります。

基本的にはいきなり open / read / write を行う実装が推奨
どうしてもチェックしたいなら fs.access() を使う

参考記事

Node.js Documentation - File System

Node.js でファイルに書き込む方法

テキストファイルの書き込み

ファイル書き込みには fs.writeFile() を利用します。詳細は以下の API DOC に記載しますが、まずはとりあえず動かすためのサンプルコードを載せます。

サンプルコード

var fs = require("fs");

var data = JSON.parse({
  message: "Hello World !"
});

fs.writeFile("./data/write/test.json", data, "utf8", (error) => {
  if (error) {
    console.log(JSON.stringify(error));
  }
});

解説

第1引数には書き込みたいファイルへのパス、第2引数に書き込みたいデータ、第3引数にファイルのエンコード種別を指定します。ファイル書き込みが終わると第4引数で指定されたコールバックが呼び出されます。

ファイルが存在しない場合は新規作成を行い、存在する場合は上書きを行います。ファイルを保存する先までのディレクトリが存在しない場合はエラーとなって書き込みできません。書き込みたいフォルダへアクセスできるかどうかの確認は fs.stat() または fs.access() を利用します。

fs.writeFile(file, data[, options], callback)

ファイルの書き込みを非同期に行います。このメソッドでは引数で指定したデータの書き込みを一度に行います。

path

第1引数に指定する「ファイルパス」は実行している JavaScript ファイルからの相対パスまたは絶対パスで指定します。

data

第2引数に書き込みたいデータを指定します。

[options]

第3引数に指定できるエンコード種別は以下のものから選択します。引数を指定しない場合、UTF-8 で書き込みます。

エンコード種別	説明
`"ascii"`	7ビット ASCII データのみからなる文字列。このエンコーディングは高速で設定されていれば上位ビットが取り除かれます。
`"utf8"`	マルチバイトエンコードされたUnicode文字列。多くの Webページおよび文書フォーマットで UTF-8 を利用されています。
`"utf16le"`	2バイトまたは 4バイトのリトルエンディアンエンコードされた Unicode 文字列。サロゲートペア文字 (U+10000 から U+10FFFF) がサポートされます。
`"ucs2"`	`"utf16le"` のエイリアス。
`"base64"`	Base64 エンコード。このエンコーディングで文字列から `Buffer` を生成すると、RFC4648 5章で定義されている "URL とファイル名で使える安全なアルファベット" を満たします。
`"latin1"`	`Buffer` を 1バイト文字列にエンコーディングします。
`"binary"`	`"latin1"` のエイリアス。
`"hex"`	各バイトを2つの16進数で表現した文字列。

callback(error)

第4引数のコールバックはエラーオブジェクト error を受け取ります。書き込みたいファイルまでのディレクトリが存在しなかったり ( error.code = "ENOENT" )、アクセスできなかった場合 (error.code = "EPERM" または error.code = "EBUSY") にエラーとなります。

参考記事

Node.js でファイルを読み込む方法

テキストファイルの読み込み

ファイル読み込みには fs.readFile() を利用します。詳細は以下の API DOC に記載しますが、まずはとりあえず動かすためのサンプルコードを載せます。

サンプルコード

var fs = require("fs");

fs.readFile("./data/test.json", "utf8", (error, data) => {
  if (error) {
    return;
  }
  console.log(data);
});

解説

ファイルは fs.readFile() で読み込むことができます。第1引数には読み込みたいファイルへのパス、第2引数にファイルのエンコード種別を指定します。ファイル読み込みが終わると第3引数で指定されたコールバックが呼び出されます。

通常、ファイル読み込み前にファイルの存在チェックを行いますが… Node.js では推奨されていないようです。（少なからずファイル存在確認するメソッド fs.stat() の説明には存在チェックは推奨しないと記載されていました。）第3引数のコールバックに引き渡される error が設定されているかどうかを確認するようにします。

fs.readFile(path[, options], callback)

ファイルの読み込みを非同期に行います。読み込みはファイル全体を一度に読み込みます。

path

第1引数に指定する「ファイルパス」は実行している JavaScript ファイルからの相対パスまたは絶対パスで指定します。

[options]

第2引数に指定できるエンコード種別は以下のものから選択します。引数を指定しない場合、第3引数のコールバックに引き渡される読み込みデータは RAWデータ (Buffer) が返却されます。

エンコード種別	説明
`"ascii"`	7ビット ASCII データのみからなる文字列。このエンコーディングは高速で設定されていれば上位ビットが取り除かれます。
`"utf8"`	マルチバイトエンコードされたUnicode文字列。多くの Webページおよび文書フォーマットで UTF-8 を利用されています。
`"utf16le"`	2バイトまたは 4バイトのリトルエンディアンエンコードされた Unicode 文字列。サロゲートペア文字 (U+10000 から U+10FFFF) がサポートされます。
`"ucs2"`	`"utf16le"` のエイリアス。
`"base64"`	Base64 エンコード。このエンコーディングで文字列から `Buffer` を生成すると、RFC4648 5章で定義されている "URL とファイル名で使える安全なアルファベット" を満たします。
`"latin1"`	`Buffer` を 1バイト文字列にエンコーディングします。
`"binary"`	`"latin1"` のエイリアス。
`"hex"`	各バイトを2つの16進数で表現した文字列。

callback(error, data)

第3引数のコールバックはエラーオブジェクト error と読み取りデータ data のどちらかを受け取ります。ファイルが存在しなかったり読めなかった場合はエラーオブジェクト error が設定され、きちんと読めた場合は読み取りデータ data が設定されます。ファイル存在チェックは事前に行わなくてもエラーオブジェクト error の確認を行うことで同じことが実現できます。

参考記事

Node.js でコマンドライン引数を取得する方法

バッチを作成しようとルすると、コマンド引数で動作変更したいことがあります。今回は Node.js でコマンド引数の受け取り方および解析を行う方法についてまとめました。コマンド引数解析は自作すると面倒なので commander モジュールを利用した方法を載せています。

基本
応用

基本

Node.js においてコマンドライン引数は process.argv で受け取れます。

コマンド引数の保存先

process.argv

インデックス 0 は node へのパス
インデックス 1 は実行 JavaScript のパス
インデックス 2 以降にコマンド引数が与えられます。

実際のソースコード、実行、結果の関係をサンプルコードとしてみると以下のようになります。

ソース(index.js)

for (let i = 0; i < process.argv.length; i++) {
  console.log(`argv[${i}] = ${process.argv[i]}`);
}

実行

> node index.js aaa bbb ccc

結果

argv[0] = C:\Program Files\nodejs\node.exe
argv[1] = C:\work\cmdargs\index.js
argv[2] = aaa
argv[3] = bbb
argv[4] = ccc

応用

上記の基本で見た通り process.argv は単純な配列なので、よく使うコマンド引数のような実装を行うには一工夫が必要です。今回はそんなコマンド引数を簡単に実現してくれる commander モジュールを利用して実現してみます。

commander モジュールの詳細は別記事に書きますが、大まかな記述方法は以下のようになります。

var program = require("commander");

program
  .option("-f, --flag", "On/Off flag.")
  .option("-m, --message <s>", "Show message.", "Hello World.")
  .option("-i, --integer <n>", "Numeric value.", parseInt, 10)
  .option("-l, --list <items>", "Listed value.", (value) => { return (value || []).split(","); }, [])
  .option("-s, --size <size>", "Selected size.", /^(large|medium|small)$/i, "medium")
  .option("-o, --option [value]", "Option value.")
  .option("-v, --variadic [items...]", "Variadic value.")
  .parse(process.argv);

if (process.argv.length < 3) {
  program.help();
}

console.log(program.message);

オンオフ引数 (例： -f --flag)

program
  .option("-f, --flag", "On/Off flag.")
  .parse(process.argv);

文字列をとる引数 (例： -m --message <s>)

program
  .option("-m, --message <s>", "Show message.", "Hello World.")
  .parse(process.argv);

空白を含む文字列を指定したい場合は利用する際に文字列をダブルクォート (") で囲んで指定します。

> node index.js -m "Say Hello !"
Say Hello !

数値をとる引数 (例： -i --integer <n>)

program
  .option("-i, --integer <n>", "Numeric value.", parseInt, 10)
  .parse(process.argv);

第3引数に parseInt 、第4引数にデフォルト値を指定します。第3引数に parseFloat を指定すれば、浮動小数として値を受け取れます。

リストをとる引数 (例： -l --list <items>)

program
  .option("-l, --list <items>", "Listed value.", (value) => { return (value || []).split(","); }, [])
  .parse(process.argv);

引数指定されるリストがカンマ区切りである前提として、受け取った値をカンマ "," で split() します。実装からなんとなくわかると思いますが…カンマ区切りの値を指定するとき空白を含んでいると受け取り時に失敗するので、空白を含むリストを指定したい場合はダブルクォート (") で囲んで指定します。

列挙型をとる引数 (例： -s --size <size>)

program
  .option("-s, --size ", "Selected size.", /^(large|medium|small)$/i, "medium")
  .parse(process.argv);

第3引数に正規表現を指定すると列挙体指定が可能になります。

オプションな値をとる引数 (例： -o --option [value])

program
  .option("-o, --option [value]", "Option value.")
  .parse(process.argv);

引数の値を [] で表現すると、その値が指定されなくてもよいとするオプション扱いにできます。

可変長な値をとる引数 (例： -v --variadic [items...])

program
  .option("-v, --variadic [items...]", "Variadic value.", [])
  .parse(process.argv);

最後に指定するオプションの値において ... を付与すると可変長な値とすることができます。値が指定されなかった時のことを考えて、デフォルト値（ここでは第3引数）に [] を指定しておくと良いでしょう。

参考記事

Node.js で FTP / FTPS 通信を行う方法

外部連携を行う際、HTTP / HTTPS の次に使いそうなのが FTP / FTPS 通信と思います。今回は Node.js で FTP / FTPS 通信を行うサンプルコードを作成しました。素のまま使うとコードが面倒になるので ftp モジュールを使った通信方法をまとめています。

ftp モジュールインストール
サンプルコード
- ファイルダウンロード
  - FTP ダウンロード
  - FTPS ダウンロード
- ファイルアップロード
  - FTP アップロード
  - FTPS アップロード
ftp モジュール API

ftp モジュールインストール

とりあえず、利用にあたって ftp モジュールのインストールを行っておきます。

npm install ftp --save

サンプルコード

ファイルダウンロード

FTPでダウンロード

ftp://192.168.86.135:21/test/sample.txt をダウンロードするサンプルコードを以下に載せます。

var fs = require("fs");
var Client = require("ftp");
var client = new Client();

client.connect({
  host: "192.168.86.135",
  port: 21,
  user: "ftpuser",
  password: "ftpuser"
});

client.on("ready", () => {
  client.get("test/sample.txt", (error, stream) => {
    if (error) {
      throw error;
    }
    stream.once('close', function () { client.end(); });
    stream.pipe(fs.createWriteStream(`./recieved/sample.local-copy_${(new Date()).getTime()}.txt`));
  });
});

L5-10
接続先のサーバー、ユーザー、パスワードを設定します。

L12
接続確立すると ready イベントが発生するので、後続操作は ready イベントのコールバックに指定します。

L13
必要なファイルを client.get(filename, callback) にてダウンロードします。ディレクトリ変更が必要であれば client.cwd() を利用して移動しておきます。

FTPSでダウンロード

上記とほぼコードは同じです。差分があるところをハイライトしました。

process.env["NODE_TLS_REJECT_UNAUTHORIZED"] = "0";

var fs = require("fs");
var Client = require("ftp");
var client = new Client();

client.connect({
  host: "192.168.86.135",
  port: 21,
  secure: true,
  user: "ftpuser",
  password: "ftpuser"
});

client.on("ready", () => {
  client.get("test/sample.txt", (error, stream) => {
    if (error) {
      throw error;
    }
    stream.once('close', function () { client.end(); });
    stream.pipe(fs.createWriteStream(`./recieved/sample.local-copy_${(new Date()).getTime()}.txt`));
  });
});

L1
FTPサーバーがオレオレ証明書を利用している場合、証明書エラーが発生します。こうした場合はエラーを無視するオプション NODE_TLS_REJECT_UNAUTHORIZED を設定しておきます。

L10
FTPSアクセスする場合は secure 属性を指定します。

ファイルのアップロード

コードはダウンロードとほぼ変わりません。アップロード時は put を使う点が異なります。

FTPでアップロード

var fs = require("fs");
var Client = require("ftp");
var client = new Client();

client.connect({
  host: "192.168.86.135",
  port: 21,
  user: "ftpuser",
  password: "ftpuser"
});

client.on("ready", () => {
  client.put("src.txt", "dist.txt", (error) => {
    if (error) {
      throw error;
    }
    client.end();
  });
});

FTPSでアップロード

process.env["NODE_TLS_REJECT_UNAUTHORIZED"] = "0";

var fs = require("fs");
var Client = require("ftp");
var client = new Client();

client.connect({
  host: "192.168.86.135",
  port: 21,
  secure: true,
  user: "ftpuser",
  password: "ftpuser"
});

client.on("ready", () => {
  client.put("src.txt", "dist.txt", (error) => {
    if (error) {
      throw error;
    }
    client.end();
  });
});

ftp モジュール API

readyイベント

接続と認証が終わったとき呼び出されます。

ftp.connect( config )

FTPサーバーへ接続します。

config

Type: object

サーバー接続に必要な設定を指定します。指定できる設定プロパティは以下の通りです。

プロパティ名	型	デフォルト	説明
host	string	"localhost"	FTPサーバーのホスト名またはIPアドレスを指定します。
port	integer	21	FTPサーバーのポート番号を指定します。
secure	boolean / "control" / "implicit"	false	暗号化通信の設定を行います。 true 制御通信およびデータ通信の両方で暗号化通信を行います。 "control" 制御通信のみ暗号化通信を行います。 "implicit" 暗黙的暗号化制御接続を行います。(通常 990 ポートを利用します。最近ではあまり利用されません。)
secureOptions	object	(none)	`tls.connect()` メソッドに渡すオプションを指定します。
user	string	"anonymous"	認証に使うユーザー名を指定します。
password	string	"anonymous@"	認証に使うパスワードを指定します。
connTimeout	integer	10000	制御接続確立まで何ミリ秒まで待つかを指定します。
pasvTimeout	integer	10000	PASVデータ接続で何ミリ秒まで待つかを指定します。
keepalive	integer	10000	接続維持のために"dummy"(NOOP)コマンドを送信する間隔(ミリ秒)を指定します。

ftp.cwd( path, callback )

カレントディレクトリを path に変更します。

path

Type: string

移動先のパスをバックスラッシュ "/" 区切りで指定します。

callback

Type: function(Error error , string currentDir)

currentDir はサーバー応答に含まれている場合に設定されます。

ftp.get( path, callback )

サーバーから指定したパスにあるデータを受信します。

path

Type: string

移動先のパスをバックスラッシュ "/" 区切りで指定します。

callback

Type: function(Error error , ReadableStream stream)

stream は受信したファイルのストリームが渡されます。

ftp.put( src, dis, callback )

サーバーからファイルを取得します。

src

Type: ReadableStream / Buffer / string

送信したいファイルのストリームまたはローカルファイルパスを指定します。

dist

Type: string

送信先のパスをバックスラッシュ "/" 区切りで指定します。

callback

Type: function ( Error error )

送信完了したら呼び出されます。

今回の記事は参考になったでしょうか？ Node.js で FTP/FTPS通信を行うポイントは以下になります。今回の記事も参考になれば幸いです。

FTP/FTPS には ftp モジュールを利用する
接続は client.connect()
ディレクトリ変更は client.cwd()
ファイルダウンロードは client.get()
ファイルアップロードは client.put()
FTPS を利用する場合は client.connect() で secure: true を指定する
オレオレ証明書を利用する場合は process.env["NODE_TLS_REJECT_UNAUTHORIZED"] = "0"; を記述する

参考記事

Node.js で HTTP/HTTPS リクエストを行う方法

Node.js で HTTP / HTTPS の GETリクエストや POSTリクエストをする方法をまとめます。 Node.js 標準機能で実装もできますが…無駄なコードが多くなってしまうので request モジュールを利用して実装するのが簡単です。今回は request モジュールを利用して GETリクエストまたは POSTリクエストを行うサンプルコードを載せます。

サンプルコード
- GET リクエスト
- POST リクエスト
API仕様
- request(option, callback)

サンプルコード

GETリクエスト、POSTリクエストを行う簡単なサンプルコードを以下に記載します。

GETリクエスト

リクエストで http://localhost:3000/api/test?testkey=testvalue&hoge=hoge を行う例です。 https へアクセスする場合はそのまま URL を https で記載すれば動作します。

var webclient = require("request");

webclient.get({
  url: "http://localhost:3000/api/test",
  qs: {
    testkey: "testvalue",
    hoge: "hoge"
  }
}, function (error, response, body) {
  console.log(body);
});

POSTリクエスト

リクエストで http://localhost:3000/api/test に POST を行い、そのリクエストボディーに JSON文字列を指定する例です。

var webclient = require("request");

webclient.post({
  url: "http://localhost:3000/api/test",
  headers: {
    "content-type": "application/json"
  },
  body: JSON.stringify({foo: "bar"})
}, function (error, response, body){
  console.log(body);
});

API仕様

request(option, callback)

HTTPリクエストまたは HTTPSリクエストを行います。

option

Type: object

HTTP/HTTPSリクエストの設定を行います。よく使いそうな設定項目だけを以下に取り上げます。

パラメーター	型	説明
uri \|\| url	string	必須。リクエスト先のURLを指定します。
method	string	リクエストメソッドを指定します。デフォルト `"GET"`。
headers	object	リクエストヘッダーを指定します。
qs	object	リクエスト先のURLへ付与するクエリ文字列を指定します。
body	Buffer, String, ReadStream	リクエストボディーを指定します。JSONを指定する場合は文字列化して指定します。
form	object	値が設定された場合、`content-type: application/x-www-form-urlencoded` でリクエストを行います。
formData	object	値が設定された場合、 `content-type: multipart/form-data` でリクエストを行います。
multipart	array	値が設定された場合、 `multipart/related` でリクエストを行います。
preambleCRLF	boolean	`multipart/form-data` リクエストの境界の手前に CRLF改行を挿入します。
postambleCRLF	boolean	`multipart/form-data` リクエストの境界の後ろに CRLF改行を挿入します。
json	boolean	`body` に JSON文字列を指定している場合、リクエストヘッダーに `content-type: application/json` を付与します。また、レスポンスボディーは JSONオブジェクトとしてパースを行います。

callback

Type: Function(Error error, http.IncomingMessage response, string / Buffer body)

レスポンスを受け取った際に呼び出されます。

参考記事

npm - request

C# & JavaScript

表紙

文書識別番号

変更履歴

テスト内容

テスト対象機能

テスト観点

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

前提と制約

中断基準と再開基準

例外

成果物一覧

テスト環境

テストデータ要件

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

スケジュール

マイルストーン

テストタスク

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

役割、責任

品質

メトリクス

カバレッジ基準

合否判定基準

テスト完了基準

メンバー

必要な人員、期間

必要なスキルセット

体制図

調達の必要性

トレーニングの必要性

ステークホルダー

組織図

コミュニケーション

内部の定例、報告

外部の定例、報告

リスク

リスク一覧

リスク対応計画

一般

用語集

参考資料

表紙

文書識別番号

変更履歴

システム概要

システム全体像

重要機能

テスト概要

サブプロセス定義

テスト観点

テスト項目選定優先度

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

リソースサマリ

体制、ステークホルダー

コミュニケーション

責任

メトリクス

不具合管理

リスク管理

自動化、ツール

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

開始基準、完了基準

テスト観点

テスト環境

ドキュメント

収集メトリクス

回帰テスト

一般

用語集

参考資料

イントロダクション

文書識別番号

対象範囲

参考資料

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

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

テスト計画詳細

テスト項目と識別番号

テスト追跡表