テストケースの概算

Question

私は、他のサイトのテストケースが似ていますか？これは、ビジネスワークフローWebサイトの基本的なCRUDです。 3つのユーザーロール、2つの入力ページ、2つの検索ページ、ビジネスルールエンジンなどがあります.50k行の.NETコード（ワークフローと永続性）約10のメインテーブルと約100のサポートテーブル（ルックアップ、ログなど）を持つDB。データを入力するための主なUIは非常に大きく、約100個のデータフィールド、複数のグリッド、約5個のアクション/サブミットボタンがあります。

私はこれがあいまいであることを知っています。私は大きさの数字の序列を望んでいます。また、コードカバレッジタイプのケースではなく、基本的なテストケースについても考えています。しかし、私が25のテストケースを持っていると言ったように、方法が十分ではないと言うだろうと確信しています。だから私は球場の数字を探しています。

TIA

Answer 1

それはシステムへの信頼の高いレベルを確保するのにかかるように私はできるだけ多くのテストケースを持っているでしょう。

テーブル、ルール、コード行などの数は実際には重要ではありません。

ドメインオブジェクトとビジネスルールが正しく実行されるためには、適切な単体テストが必要です。クエリが適切に実行されるようにするためのテストが必要です（これはより困難です）。

ソフトウェアを使用してパスのテストケースを作成することもできます。つまり、ここをクリックしてこのページを取得し、そこをクリックしてフィールドを編集し、ページを保存して戻る...このタイプは、通常テストが記録され、ページが変更されたときに再記録する必要があります。 ：フィールドが追加または削除されます）。

一般的に言えば、のカバレッジについては、テストの数より多いです。あなたのテストでは、アプリケーションの機能の多くがの実現可能性をカバーするようにしたいと考えています。私は可能ではないと言いました。テストケースではアプリケーション全体（100％）をカバーすることができますが、小さな変更、バグ修正などのために、それらのテストを再コードする必要があります。これは、成熟したアプリにとってより望ましいものです。任意のシステムのためにあなたは、彼らはユニットテストの変更/固定時の法外な金額を費やすとして、あなたの開発者やQAチームその方法を骨抜きにしたくない、新しいアプリを...

---

について、あなたは簡単のように過ごすことができシステム自体を行うときに自動化されたテストを開発するのに多くの時間を費やします。いくつかのケースでは、さらに。

私たちのグループでは、単体テストがたくさんある傾向があります。しかし、システムを通るパスをテストするために、特定のエリアが「メンテナンス」タイプのモードに移行したときにのみ、パスをテストします。私たちは、その地域ではかなりの間変化はほとんどないと考えています。パステストは誰もそれを断念しないようにすることだけです。

---

UPDATE：

は少しさらに行く：ここでのコメントは、以下に私を導いたのは、コードの1つの小片を調べてみましょう：それの顔に

Int32 AddNumbers(Int32 a, Int32 b) { 
    return a+b; 
} 

ます単一のテストで逃げることができます：

Int32 result = AddNumbers(1,2); 
Assert.Equals(result, 3); 

しかし、それだけでは不十分です。

Int32 result = AddNumbers(Int32.MaxValue, 1); 
Assert.Equals(result, (Int32.MaxValue+1)); 

ここではエラーが発生しました。別のものがあります：

Int32 result = AddNumbers(Int32.MinValue, -1); 
Assert.Equals(result, (Int32.MinValue-1)); 

したがって、少なくとも3回のテストが必要な非常に簡単な方法があります。任意の結果を与えることができるかどうかを確認するためのイニシャル、次に境界チェックのための2。これは本質的に2行のコード（メソッド定義と1行計算）の3つのテストです。

あなたのコードはより複雑になるにつれて、物事は本当にdicey取得：DIVIDEBYZERO：

Decimal DivideThis(Decimal a, Decimal b) { 
    result = Decimal.Divide(a,b); 
} 

このわずかな変化は境界を越えてさらに別の例外条件を紹介します。これで、2行のコードに対して最大4つのテストが必要になりました。

さて、それを少し単純化してみましょう。ここ

String AppendData(String data, String toAppend) { 
    return String.Format("{0}{1}", data, toAppend); 
} 

当社のテストケースは次のとおりです。

String result = AppendData("Hello", "World"); 
Assert.Equals(result, "HelloWorld"); 

本当に必要がない他の人と、コードブロックのためのただ一つのテストケースだこと。

これは何を意味していますか：まず2行のコードで、1〜4個のテストケースが必要になることがあります。あなたは50k行について言及しました...その論理を使用すると、50,000〜200,000のテストケースが必要になります...

もちろん、人生はそれほど単純ではありません。あなたが持っている50k行のコードでは、入力が非常に制限された大きなコードブロックが存在するでしょう。たとえば、住宅ローン金利計算機は3つのパラメータをとり、1つの値（APR）を返します。コードそのものは100行ほど走っているかもしれません（しばらく私と一緒に働いています）。このためのテストケースの数は、丸め処理を適切に行うことを確実にするための線に沿ったエッジケースによって決定されます。

だから、5つのケースがあるとしましょう。これによって、20行のコード= 1件になります。 50k行を計算すると、2,500テストケースになる可能性があります。明らかに私たちが上で予想したよりもはるかに小さい。

最後に、別のシワをミックスに送ります。一部のテストシステムでは、データファイルからの入力とアサーションを処理できます。私たちが最初に検討したのは、テストしたい各パラメータの組み合わせのための行を持つデータファイルを持つことができるということです。このシナリオでは、3つ（またはそれ以上）の可能な条件をカバーするために1つのテストケースしか必要としません。

テストケースは、（擬似コード）のようになります。その機能により

read input file. 
parse expected result, parameter 1, parameter 2 
run method 
assert method result = parsed result 
repeat for each line of the file 

、我々はダウンあたりシナリオ 1のテストケースにしています。私はメソッドごとに1と言っていますが、実際にはほとんどのメソッドはほとんどスタンドアロンではなく、多数のメソッドが他のメソッドを明示的にテストして暗黙的にテストされる可能性があります。したがって、独自の個別テストは必要ありません。

---

これは、これに私をリード：あなたのコードベースを完全に理解することなく、テストケースの右側数を決定することは不可能です。 UIレベルの5つのケースでは、テストの複雑さによっては完全なカバレッジに十分な場合があります。それは何千もかかるかもしれません。したがって、コードカバレッジに基く方がはるかに優れています。コードの何パーセントと分岐ロジックがテストしていますか？

Answer 2

車の大まかな価格を聞いて、その価格を私に与えると、私はそこに車を買いませんでした。なぜなら、彼は私にいくつかの重要な質問を忘れていたからです。どんな車が好きですか？あなたは車でどんなエクストラをしたいですか？

テストケースの数と同じです。採用マネージャーが私にその質問をすると、私はおそらく彼に次の回答を与えます。

#test＃要件間のケース= * 2と＃の要件は、（いくつかの要件が可能のbollionsにつながることができます）無限*

私もそれは私の経験に基づいて番号が現実的に＃要件* 5だろうと言うでしょう

開始段階：次のエラーマージンは、私がこの見積もりを作っています位相に応じて注意しなければならない（私は新しい、変更および省略機能を備えたプロジェクトのために、初期段階で使用する番号がある）

：エラーマージン= 400％ ... テストフェーズ：あなたはテスト段階を開始する頃には、エラーマージン= 10％

を、詳細な要件/仕様が用意され、要件のvolatillityが安定し、要件のクリープはほぼゼロである、など

ことで、私はまた、より良い見積もりを与えることができるでしょう...