ソフトウェアテスト自動化ドキュメント
ソフトウェアテストの自動化を説明するときに使用できるドキュメントの種類（任意の段階で、自動化計画、テスト設計、実装、レポート）？標準的なタイプのドキュメントはありますか？誰かがさまざまなタイプのドキュメントの例とテンプレートを提供できるか？手動テストのドキュメントと自動化の違いは何ですか？
これが私が提案するものです：
1。テスト戦略文書：
これは、すべてのテスト目標、存在するテスト目標、およびユニットテスト、コンポーネントテスト、システムテスト、統合テストのすべてのレベルをリンクして実行されるテスト全体の概要です。これは標準的なものではありませんが、 this sort のようなものになる可能性があります。
2。テストスーツ：
これは、各ケースをいつどのように実行する必要があるかに関するテストケースと条件のコレクションです。各要素に対する入力、手順、および予想される出力動作の各セット。成功と失敗だけではなく、これについてさらに分析が行われる場合があります。
3。テスト環境/セットアップと手順
テストプロセスを完全または部分的に自動化している場合、テスト（のさまざまな要素）がどの程度正確に実行されるかを文書化することは価値があります。ここで実行されたテストが正しい方法であるかどうかは、議論され、検証される必要があります。開発者と関連するQAは、一連のツールの操作方法と実行する手順を知っている必要があります。
4。トレーサビリティマトリックス：
これは、各機能ポイントが安定していることを保証するためにどのテストケースのセットが関連しているかを識別する明確に定義されたマトリックスです。 詳細はこちら またはこれ wiki リンク。新しいバグが発見されたとき、または新しい機能が要求されたときはいつでも、トレーサビリティマトリックスを更新して、これらの変更をキャプチャする必要があります。
5。試験結果
自動で生成されたものでも手動で実行されたものでも、結果（詳細と要約）をテスト実行シートに記録する必要があります。注意すべき最も重要なことは、結論を検証できるように、元の観察（ログ、アプリケーションの実際の出力など）を関連としてキャプチャする必要があります。 b。ドキュメントは、これらのテストが実行されたビルドをキャプチャする必要があります。異なるビルドは、同じテストに対して同じ動作を生成しない場合があります。
手順とフォーマットは必要に応じて開発できます。最も重要なことは、私の個人的な経験から、いくつかの形式に厳密に準拠する代わりに、実行中の日記のようにこれを文書化して、必須事項を少なくし、より多くの情報を自由に注ぐことができるということです。テストは決して静的ではありません（少なくともかなり複雑なプロジェクトの場合）。これらのテンプレートは常に進化し続ける必要があります。多くの場合、次のステップごとに最後のステップから大きく離れることがあります。テンプレートが古くなっている場合、またはテンプレートが厳格すぎて人々がそれに従わない場合、最終的にはテスト手順による関連知識の多くが正しく反映されません。
答えは、ソフトウェアの機能、ソフトウェアの設計方法、およびソフトウェアが使用される業界に大きく依存します。一部の業界では、テストの文書化と検証に関する非常に広範な規制要件があります。たとえば、製薬およびバイオテクノロジーのFDA CFR 21 Part 11産業。
また、組織がドキュメントをテストするために関連するすべてのIEEE標準に忠実に従う場合でも、次のことを考慮してください。
- IEEE 829：ソフトウェアテストのドキュメント
- IEEE 1008：単体テスト
- IEEE 1012：ソフトウェアの検証と検証
- IEEE 1028：ソフトウェア検査
- IEEE 1044：ソフトウェア異常の分類
次のように、直接および間接的に関連するドキュメントや標準を定義して使用する必要があります。
- IEEE 830：システム要件仕様
- IEEE 730：ソフトウェア品質保証計画
- IEEE 1061：ソフトウェア品質指標と方法論
- IEEE 12207：ソフトウェアライフサイクルプロセスとライフサイクルデータ
これらのIE3標準のすべてが乗り越えられないように見える場合、特に小規模の組織やチームの場合は、「科学的」ではなく簡潔な Software Engineering Body of Knowledge を参照してください。
最後に、正式なドキュメントの代わりにテストの電子記録を保持する [〜＃〜] alm [〜＃〜] ツールを使用することは、次のことを定義する手順がある限り、完全に有効な代替手段です標準化された使用。
IEEE 829-1998、Standard for Software Test Documentation を見ましたか？私の会社では、この標準のテストドキュメントを使用して、テスト戦略全体を説明しています。たとえば、マスターテスト計画では、実際にテストの自動化に関する情報がアプローチセクションに含まれます。
私のプロジェクトでは、自動化テストは基本的に手動テストと同じ手段を使用して文書化されています。他のすべての情報に加えて、コード内のテストケースも示します。
私たちは、チーム全体が実行方法を知っている自動化スイートを維持しています。これらの両方の情報により、チームのメンバーはテストケースを特定し、実行できます。
また、量産コードと同様に、自動テストケースのバージョン管理と確認も行います。これらは、テストのコード表現の生きたドキュメントとして機能します。
したがって、ある方法では、手動テストのドキュメント化方法と自動テストの製品コードを再利用しています。