テスト結果を管理するためのベストプラクティスは何ですか
ソースコードの管理にはGitHubを使用し、ワークフローや問題の管理にはワッフルボードを使用しています。
現在、カスタムのテストケースを使用してシステムをテストすると、CSVファイルが生成されます。これらのテスト結果の記録を保持できるようにしたいので、戻って同じ入力で同じテストを再度実行して結果を検証したり、結果を関係者と共有したりできます。
これらのテスト結果を管理する最良の戦略は何ですか？
Results.csvをプロジェクトと同じGithubリポジトリで公開する必要がありますか？ （面倒になるので避けたい）
結果をWaffleboardで公開してみましたが、Githubの問題は結果を添付するためのファイルアップロードをサポートしていません（画像ファイルのみアップロードできます）
私たちが見る唯一の選択肢は、内部のWebサイトに結果を公開することです。これはこれを行う最善の方法ですか？
説明を編集：
システムはレガシーシステムを置き換えます。テストケースは毎日変更されます。
テストスクリプトは、レガシーシステムと新しいシステムからデータを取得し、それらが一致するかどうかを比較します。
テスト結果は同じgitリポジトリで管理する必要があります。すべての実行の結果を保存する必要はなく、1回の実行の結果を保存するだけで済みます。他のすべての実行は、この「ゴールデン」バージョンのデータと比較する必要があります。テストが異なる結果を生成する場合、テストは失敗します。
言い換えると、この.csvファイルはテスト出力ではなく、テストinputです。一度生成すると、テストではこれを使用して、現在のシステムが期待どおりに動作しているかどうかを検証します。これは入力なので、他のテストアセットと同様にバージョン管理する必要があります。
テストを実行すると、失敗のみを示す日次レポートを作成できます。特定のテストが失敗または合格する頻度について分析を行う必要がない限り、これをアーカイブする必要はありません。
あなたの質問から：
これらのテスト結果の記録を保持できるようにしたいので、戻って同じ入力で同じテストを再度実行し、結果を確認できます– @ user3711455
あなたのコメントから：
.CSVは毎日変更されます。テストスクリプトの入力は、レガシーシステムの出力です。それはそれを取り、新しいシステムから同等のデータを取得してから、両者が一致するかどうかを比較します。次のようなCSVの結果：レガシーシステム結果、新しいシステム結果の合計差異：– @ user3711455
これらは同じテストではありません。同じコードに対して同じテストを同じ入力で実行することは、冗長な練習になるはずです。それでも常に同じ結果が得られるとは限らない場合は、システムに魔法をかけたことになります。
これは、不思議なことが起こっていないことを確認する場合にのみ役立ちます。より一般的には、これらのテストを再実行して、1つだけ変更されたことを確認します。通常はコードをリファクタリングします。そうすれば、テストが失敗したときに何が原因であるかがわかります。
2つのシステムを並べて実行して、比較のために作業を複製することは、テストではありません。それは投票システムです。彼らが同意しない場合は、誰を信じるかを決める必要があります。レガシーシステムは、何年もの間そのベルトの下にある完璧なものであると信頼されるべきではありません。実際、古いほど、間違いがよく知られている可能性が高いので、誰もがそれを無視しているだけなので、それらは予期されており、誰もが知っているので、新しい人にそれを知らなかったかもしれません。新しいシステムが運用に移行する準備ができていることを証明することで、いくつかの価値を得ることができますが、これらは古いシステムが存在する必要があるため、テストではありません。
ただし、古いシステムに入力をフィードして出力を記録すると、ベースライン出力が得られます。しかし、その入力のためだけに、そしてレガシーシステムのそのバージョンのためだけに。うまくいけば、それ自体はバグがありません。それから、新しいシステムのテストを構築できます。しかし、入力がすべてのユースケースとすべてのコードを実行しない場合は、運が良ければいいだけです。
もしかしたら、あなたのcustom written test casesテストケースをchange dailyは、両方のシステムが同じ操作入力のフィードから機能するようにしているだけです。コードが適切にカバーされているとはあまり確信がありません。
ただし、入力がコードのさまざまな部分を実行するように手動で調整されている場合、それらの入力とそれらのテストを自動化し、それらの出力を比較するコードは、テストするコードと構造的に類似した方法で整理する必要があります。簡単に移動できます。それを実行し、すべてのバージョンを管理しておくと、Nice開発システムができます。
別の質問に答えますが、静的解析の結果の保存に関する質問への私の回答 がここでも役立つと思います 。
テストケースとテスト入力をバージョン管理する必要があります。ソフトウェアバージョンを指定すると、その時点で実行したテストとそれに関連する入力データを正確に再現できるはずです。ただし、古いコードで新しいテストを実行できるようにすることもできます。テスト（テストコード、テスト入力データ、テスト手順）をバージョン管理システムに保持し、タグ付けすることが不可欠です。
ソフトウェアのスナップショットで同じデータを使用してまったく同じテストをいつでも再実行できるようになれば、すべてのテスト結果を保持する必要はないと思います。
いくつかのデータを利用可能にする必要があると思われる場合は、正式なリリースの一部としてテスト結果をパッケージ化できます。テスト結果を含める場合は、パッケージ化する方法を確認できます。すべてのテスト出力と結果を含めるか、テスト結果を説明する要約レポートを作成します。
ベストプラクティスにより、開発者は外部の依存関係なしに新しい作業コピーからテストスイートを実行できます。
あなたのシナリオは、すでに典型的なテストシナリオから逸脱しているようです。しかし、それがおそらくあなたにとって意味することは、「ターゲット」の結果をリポジトリに格納することです。テストツールは、その直接の結果をどこにも保存しないでください。検証のために、即時の結果を「ターゲット」の結果と比較し、個々の障害を報告する必要があります。
そこから、単一の障害が発生した場合、開発者にバグの修正または要件の変更を検証し、コミットする前に「ターゲット」データを適宜調整します。
3種類のテストを使用します。
- セレン
- NUnit
- Soap UI
これらはすべて結果ファイル（XML）を生成します。 Seleniumテストの場合、これらは高レベルのフローであるため、10未満であるため結果を表示できるグループにメールを送信します。これらは、かなり技術的なチェックアウトスタイルのテスト（スモークテスト）です。 XMLはHTMLに変換され、電子メールにプッシュされます。
NUnitおよびSOAP UIテストの場合、1000ではなく100があります。これらのテストはどちらも、nUnitテスト結果フォーマットのXMLファイルを生成します。そこから、これらの結果を単純なWebページにフィードします（レポートユニット）XMLを変換し、結果をWebページに配置します。
過去の結果は関係ありませんが、各「実行」をレビューのためにアーカイブフォルダーにプッシュできますが、数日前の結果も私たちの観点からは古く、多くのコードがある場合は無効になる可能性があります変更。これらの結果はモニター（TV）に送信されるため、チーム全体がテストの正常性を確認できます。赤くなったテストは調査され、解決されます。
結果を生成するメカニズムはソース管理下にありますが、実際の結果自体はソース管理されていません。