13

新しいコードを手作りしています。私は石を裏返さないようにしたいと思います。

コード コントラクトを指定して Pex をガイドし、数値集約型のコードを適切にカバーできるようにする以外に、具体的にできることはありますか?

背景情報については、 http://research.microsoft.com/en-us/projects/pex/pexconcepts.pdfでキーワード「float」を検索してみてください。

浮動小数点数に対する算術制約は、有理数への変換によって近似され、浮動小数点制約の近似解を見つけるために、Z3 の外部でヒューリスティック検索手法が使用されます。

...そしてまた...

シンボリック推論。Pex は、自動制約ソルバーを使用して、テストとテスト対象のコードに関連する値を決定します。ただし、制約ソルバーの機能は常に制限されています。特に、Z3 は浮動小数点演算について正確に判断できません。

または、.NET で数値異常を見つけるタスクにより適した .NET のツールを知っていますか? http://fscheck.codeplex.com/は認識していますが、シンボリックな推論は実行されません。

4

1 に答える 1

0

あなたが望むものは良いカバレッジですか？コードのすべての分岐を実行するテストを行ったからといって、実際にそれが正しいとは限りません。多くの場合、それはコーナー ケースに関するものであり、開発者はこれらのコーナー ケースが何であるかを知るのに最適な立場にあります。また、「これは興味深い入力の組み合わせです」と言うだけで機能するように聞こえますが、見たいシステムの動作を指定することはおそらく必要です-そもそもコードを間違って書いた場合、興味深い入力は、正しいコードとはまったく関係がない場合があります。

これはあなたが探している答えではないかもしれませんが、これを行う最善の方法は手作業です! コーディングを開始する前に仕様を書き留めて、クラス/サブシステムの API を作成していることがわかったときに、それを多数のテスト ケースに変換します。

API の入力/コードの記述を開始すると、実行する必要がある追加のビットとピースを拾う可能性が高く、難しいビットが何であるかを見つけることができます。条件などがある場合は、誰かがコードをリファクタリングしていると感じます。間違っている可能性がある場合は、それらをカバーするテスト ケースを作成します。これらのポイントで意図的に間違ったコードを記述し、失敗したテストを取得してから修正して、テストがコードの正しいパスをチェックしていることを確認することがあります。

次に、カバーしていない可能性のある奇妙な値を考えてみてください-負の入力、nullなど。多くの場合、これらは無効であり、対応したくない/考えなければならない場合です-これらの場合、通常、いくつかのテストを記述します例外をスローする必要があると言う-これは、適切に/無効なデータについて考えていない場合に、人々がコードを誤用するのを基本的に止めます。

これのもう1つの利点は、新しい要件を満たすためにアルゴリズムを大幅に書き直す必要があることに気付いた場合、新しいテストケースを追加してから書き直し/リファクタリングするだけでよいことです。テストがアルゴリズムの詳細を見て、外界への影響を想定しているだけなら、アルゴリズムが現在の動作にどのように影響するか、どの部分が正しく、どの部分が正しくないかを理解しようとして、かなりの頭痛の種になるでしょう。単体テストの負荷を新しい API/アルゴリズムに移行します。

于 2012-07-17T08:48:57.853 に答える