4

私は通常、適切に定義された適度に小さい一連の入力が与えられた場合に、正しい動作を簡単に定義できるコードに対して単体テストを使用しようとします。これはバグをキャッチするのに非常にうまく機能し、私はジェネリック関数の個人的なライブラリで常にこれを行っています。

ただし、私が書くコードの多くは、基本的に大規模なデータセットで重要なパターンを探すデータ マイニング コードです。この場合の正しい動作は、しばしば明確に定義されておらず、人間が予測するのが容易ではない方法で多くの異なる入力に依存しています (つまり、数学は手動で合理的に行うことができないため、私は最初に問題を解決するためにコンピューターを使用します)。これらの入力は非常に複雑になる可能性があり、妥当なテスト ケースを作成することはほぼ不可能です。テストする価値のあるエッジ ケースを特定することは非常に困難です。アルゴリズムが決定論的でない場合もあります。

通常、サニティ チェックに assert を使用し、既知のパターンを使用して小さなおもちゃのテスト ケースを作成し、その答えが客観的に正しいとは限りませんが、少なくとも「妥当に見える」かどうかを非公式に確認することで、できる限りのことを行います。この種のケースをテストするより良い方法はありますか?

4

6 に答える 6

0

これはトリッキーです。これは、テキスト検索エンジンに関するテストを作成することに似ています。苦労し続けると、次のことがわかります。

  • 小さく単純化された、しかし適度に代表的なデータ サンプルから始め、これを実行して基本的な動作をテストします。
  • 出力が正確に何らかの答えであると断言するよりも、出力の何が重要かを理解する方が良い場合があります。たとえば、私たちの検索エンジンでは、3 つの重要なドキュメントが結果の最初のページにある限り、ドキュメントがリストされる正確な順序はあまり気にしませんでした。
  • 小さな段階的な変更を行うときは、その本質が何であるかを理解し、そのためのテストを作成します。全体的な計算には多くの入力が必要ですが、コードベースへの個々の変更は分離可能でなければなりません。たとえば、一部のキーワードにハイフンが含まれているために、特定のドキュメントが表示されていないことがわかりました。これが期待どおりに動作していることをテストするテストを作成しました。
  • Fitness のようなツールを見てください。コードの一部に多数のデータセットを投入し、結果についてアサートすることができます。これは、従来の単体テストよりも理解しやすいかもしれません。
  • 私は製品所有者に「これがどのように機能するのか理解できません。それが正しいかどうかはどうやってわかりますか?」と言いました。あいまいに定義された問題の本質を明確にすることができるかもしれません。これは私にとって何度も非常にうまく機能しており、説明できないという理由で、機能について人々に話していませんでした。
  • クリエイティブに！
于 2010-05-18T04:19:41.663 に答える
0

実際、ここでの課題は次のとおりです。アプリケーションはファジーで非決定論的な種類のタスクをスマートな方法で実行することを意図しているため、達成したいまさにその目標は、アプリケーションが人間よりもこれらのパターンを見つける能力が優れていることです。それは素晴らしく、パワフルで、クールです...しかし、それをやってのけると、「この場合、答えはXでなければならない」と言うのは人間にとって非常に困難になります。

実際、理想的には、コンピューターが「そうではない。そう考える理由はわかるが、ここにある 4.2 テラバイトの情報を考えてみてください。もう読んだことがありますか? それらに基づいて、答えは Z であるべきだと主張します. "

そして、最初の目標に本当に成功した場合、エンド ユーザーは時々、「Zowie、その通りです。その方が良い答えです。あなたは私たちにお金を稼げるパターンを見つけました! (またはお金を節約するか、またはなんでもいい）。"

そのようなことが絶対に起こらないのなら、そもそもなぜこの種のパターンを検出するようにコンピューターに要求するのでしょうか?

したがって、私が考える最善の方法は、テスト シナリオのリストを作成するのに実際の生活を役立てることです。過去に発見された、価値のあるパターンがあった場合は、同様のデータが与えられたときにシステムがそれを発見するかどうかを確認する「単体テスト」を行います。統合テストに似ているかもしれないので引用符で「単体テスト」と言いますが、NUnit、VS.Net、RSpec、または使用している単体テストツールを使用することを選択できます。

これらのテストのいくつかでは、何らかの方法で 4.2 テラバイトのデータを「モック」しようとするかもしれません (データを実際にモックするわけではありませんが、より高いレベルでは、そのデータから到達した結論の一部をモックすることになります)。他の人にとっては、いくつかのデータを含む「テストデータベース」があり、そこから一連のパターンが検出されることを期待しているかもしれません。

また、それができれば、システムが検出したパターンの背後にある「推論を記述する」ことができれば素晴らしいことです。これにより、ビジネス ユーザーは、アプリケーションが正しいかどうかについて熟考することができます。

于 2009-03-20T03:23:18.977 に答える