17

私は、Test Anything Protocol (TAP) IETF グループに参加している 1 人です(興味がある場合は、気軽にメーリング リストに参加してください)。多くのプログラミング言語は、主要なテスト プロトコルとして TAP を採用し始めており、現在提供されているものよりも多くのことを望んでいます。その結果、xUnit、TestNG、またはその他のテスト フレームワーク/方法論のバックグラウンドを持つ人々からのフィードバックを取得したいと考えています。

基本的に、単純な合格/不合格以外に、テスト ハーネスからどのような情報が必要ですか? いくつかの例を挙げましょう：

  • ファイル名と行番号 (該当する場合)
  • 開始時間と終了時間
  • 得られたものと期待したものとの違いなどの診断出力。

等々 ...

4

10 に答える 10

7

個々のアイテムごとに、リストのすべてのものを間違いなく:

  • ファイル名
  • 行番号
  • 名前空間/クラス/関数名
  • テスト範囲
  • 開始時間と終了時間
  • および/または合計時間 (これは、上位 2 つの項目よりも便利です)
  • 得られたものと期待したものとの違いなどの診断出力。

頭のてっぺんからは、他にはあまり知りませんが、知りたいテストのグループについてです

  • グループ名
  • 合計実行時間
于 2008-09-18T11:10:01.780 に答える
6

タグの任意のセット-たとえば、「統合、UI、管理者」としてテストをマークできます。

（あなたは私がこれを求めるつもりだったことを知っていましたね:-)

于 2008-09-18T22:43:35.717 に答える
6

テストを書くのはとても簡単で、実行するのも同様に簡単でなければなりません。私にとって、これがテスト ハーネスの最も重要な機能です。誰かがテストを書くために GUI を起動したり、たくさんのフープをジャンプしたりしなければならない場合、彼らはそれを使用しません。

于 2008-09-18T11:05:10.810 に答える
4

あなたが言ったことに、私は追加します：

  • メソッド/関数/クラス名
  • カバレッジ カウント ツール (例外あり) (これらのメソッドはカウントしないでください)
  • 利用可能な最後の N 回の実行の結果
  • テスト結果を簡単に解析する方法が存在しなければならないことを義務付ける
于 2008-09-18T11:09:01.800 に答える
4

あらゆる種類の診断出力 -特に障害の場合は重要です。テストが失敗した場合、何が起こったのかを確認するために常にデバッガーでテストを再実行する必要はありません。出力にいくつかの include があるはずです。

また、メモリやハードディスクの空き容量などの重要なシステム変数の前後のスナップショットを確認するのも好きです。これらも重要な手がかりになるからです。

最後に、いずれかのテストにランダム シードを使用している場合は、必要に応じてテストを再現できるように、シードをログ ファイルに書き込みます。

于 2008-09-18T16:56:34.693 に答える
1

個々のテストを識別できるようにする一意の ID (uuid、md5sum)。たとえば、テスト結果をデータベースに挿入したり、バグ トラッカーでそれらを識別して、QA が個々のテストを再実行できるようにする場合に使用します。

これにより、製品の複数のリビジョンのライフサイクル全体を通じて、ビルドからビルドへの個々のテストの動作を追跡することも可能になります。これにより、最終的には、「歴史的な」イベント (新規雇用、製品リリース、ハードウェアのアップグレード) と、そのようなイベントの結果として失敗したテストのプロファイルとの間の大規模な相関関係が可能になる可能性があります。

また、標準出力と混合するのではなく、専用のサイドチャネルを介して TAP を発行する必要があると考えています。これがプロトコル定義の範囲内にあるかどうかはわかりません。

于 2008-12-03T21:16:01.193 に答える
1

TAP ストリームを連結してネストする機能が欲しいです。

于 2008-09-20T17:09:04.560 に答える
0

単純な C++ テスト メソッド セットの出力プロトコルとして TAP を使用していますが、次のような欠点があります。

  • テスト ステップをグループ化することはできません (複数のテスト スクリプトへのグループ化のみがあります。ただし、ソフトウェアですべてのテストを実行するには、少なくとももう 1 レベルのグループ化が必要です。これにより、単一のテスト ステップが「DB 接続」などによって識別されるようになります)。 " -> "再接続テスト" -> "テスト ステップ #3")
  • 予想される出力と実際の出力の違いを確認すると便利です。diff を (コメントとして) stderr に出力するか、実際にグラフィカルな diff ツールを起動します。
  • プロトコルとツールは、本当に言語に依存しない必要があります。たとえば、これまでのところ、Perl スクリプトの実行に限定された、テストを実行するための Perl の「証明」ツールしか知りません。

最終的に、テスト出力は、成功したテストを非常に簡潔にリストし、失敗したテストの詳細な出力を提供し、失敗したテスト行に IDE にすばやくジャンプできるようにする HTML レポート ファイルを簡単に生成するための基礎として適している必要があります。

于 2008-11-19T17:03:31.457 に答える
0

TAP の拡張アイデア:

1..4
ok 1 - yay
not ok 2 - boo
ok 3 - yay #json:{...}
ok 4 - see my json

#json コメントを添付する機能... - 既存のコードでは安全に無視できます - 明確に定義されたタグは testanything.org で簡単に予約できます - 複雑な型を簡単に作成、解析、読み取ることができます - yaml は面倒です

于 2015-01-07T16:31:31.337 に答える
0

  • オプションの ascii カラー出力、緑は正常、黄色は保留中、赤はエラー

  • 物事が保留されているという考え

  • 個々のテストを実行するコマンドのテスト レポートの最後にある概要

  • リスト項目

    • 何かがうまくいかなかった

    • テストの何かが保留中だった

于 2009-12-06T15:54:20.310 に答える