6

疑似言語で定義された単純な関数があるとしましょう。

List<Numbers> SortNumbers(List<Numbers> unsorted, bool ascending);

ソートされていない数値のリストと、昇順または降順のソート順を指定するブール値を渡します。その見返りに、ソートされた数値のリストを取得します。

私の経験では、境界条件を捉えるのが得意な人もいます。問題は、「テストケースのキャプチャが「完了」したことをどのようにして知るか」です。

今すぐケースのリストを開始できます。賢い人の中には、間違いなく、これまでのどのケースでもカバーされていない「もう1つの」ケースを考える人もいます。

4

5 に答える 5

10

すべての境界条件を考えようとして、あまり時間を無駄にしないでください。テストでは、最初からすべてのバグを検出できるわけではありません。アイデアは、かなり良いテストを行うことです。そして、バグ表面化するたびに、そのバグに特化した新しいテストを作成して、二度とそのバグから連絡がないようにします。

コードカバレッジツールについてもう1つ書きたいことがあります。C#やJavaのように、get / setや同様のメソッドが多数ある言語では、100%のカバレッジを狙うべきではありません。つまり、些細なコードのテストを書くのに多くの時間を浪費しているということです。複雑なビジネスロジックを100%カバーするだけです。完全なコードベースが70〜80%のカバレッジに近い場合、あなたは良い仕事をしています。コードカバレッジツールで複数のカバレッジメトリックが許可されている場合、最適なのは「基本ブロック」のカバレッジを測定する「ブロックカバレッジ」です。他のタイプは、クラスとメソッドのカバレッジ(あまり多くの情報を提供しない)とラインカバレッジ(細かすぎる)です。

于 2008-08-15T18:17:17.387 に答える
6

テストケースのキャプチャが「完了」したことをどのようにして知ることができますか?

最も些細な場合を除いて、100%に到達することはできません。また、(ライン、パス、条件などの)100%のカバレッジは、すべての境界条件に到達したことを示しているわけではありません。

最も重要なことは、テストケースが書き込みと忘れではないということです。バグを見つけるたびに、追加のテストを作成します。元のプログラムで失敗することを確認し、修正されたプログラムで合格することを確認して、テストセットに追加します。

グレンフォードJ.マイヤーズによるソフトウェアテストの芸術からの抜粋:

  1. 入力条件で値の範囲が指定されている場合は、範囲の終わりにテストケースを記述し、終わりを超えた状況に無効入力テストケースを記述します。
  2. 入力条件で値の数が指定されている場合は、値の最小数と最大数、およびこれらの値の上下に1つずつテストケースを記述します。
  3. 出力条件ごとにガイドライン1を使用してください。
  4. 出力条件ごとにガイドライン2を使用してください。
  5. プログラムの入力または出力が順序集合である場合は、集合の最初と最後の要素に注意を向けてください。
  6. さらに、他の境界条件を検索するためにあなたの創意工夫を使用してください

私は著作権上の理由から最低限を貼り付けただけです。

上記のポイント3と4は非常に重要です。人々は出力の境界条件を忘れがちです。5.OKです。6.本当に役に立たない:-)

短期試験

これは見た目よりも難しいです。マイヤーズはこのテストを提供しています:

プログラムは、入力ダイアログから3つの整数値を読み取ります。3つの値は、三角形の辺の長さを表します。プログラムは、三角形が不等辺三角形、二等辺三角形、または正三角形のいずれであるかを示すメッセージを表示します。

不等辺三角形は2つの辺が等しくない三角形であるのに対し、二等辺三角形には2つの等しい辺があり、正三角形には3つの等しい長さの辺があることに注意してください。さらに、二等辺三角形の等しい辺の反対側の角度も等しく(三角形の等しい角度の反対側の辺も等しいということになります)、正三角形のすべての角度が等しくなります。

テストケースを書いてください。いくつ持っていますか?マイヤーズはあなたのテストセットについて14の質問をし、高度な資格を持つ専門家プログラムは可能な14のうち平均7.8であると報告しています。

于 2008-08-16T09:08:23.623 に答える
1

実用的な観点から、承認される前に合格する必要があると思われるテストのリストを作成します。これらをテストし、可能な場合は自動化します。タスクの推定時間または与えられた時間に基づいて、テスト範囲を拡張して、承認前に合格する必要がある項目を含めます。もちろん、must と should の境界線は主観的なものです。その後、バグが発見されるたびに自動テストを更新します。

于 2008-09-26T01:42:25.813 に答える
0

優れたコードカバレッジツールは本当に役立ちます。

100%のカバレッジは、それが確実に適切にテストされていることを意味するわけではありませんが、それは良い指標です。

.Net NCoverは非常に優れていますが、もはやオープンソースではありません。


@Mike Stone-ええ、おそらくそれは「高カバレッジ」であるはずです-私たちは最低80%を目指しており、約95%を超えると、特にベルトの「n」ブレースコードがある場合は通常、収穫逓減になります。

于 2008-08-15T18:18:57.430 に答える
0

@キース

あなたはそれを釘付けにしたと思います。あなたがどれだけ「完了」したかを見たい場合は、コードカバレッジを確認することが重要ですが、100%は少し非現実的な目標だと思います。75〜90%を目指して努力すると、船外に出ることなくかなり良いカバレッジが得られます... 100%を達成するためだけにテストしないでください。その時点では、時間を無駄にしているだけです。

于 2008-08-15T18:33:05.527 に答える