2

これは、テストを通じてバグとして明らかにする方法がわからない微妙なエラーを説明するための C の非常に単純な例です。

検討：

#include <stdio.h>

int main() 
{
  int a;
  int b;
  int input;

  printf("Enter 1 or 2: ");
  scanf("%d", &input);

  switch(input) {
  case 1:
    a = 10;
    /* ERROR HERE, I FORGOT A BREAK! */
  case 2:
    b = 20;
    break;
  default:
    printf("You didn't listen!\n");
    return 1;
    break;
  }

  if(input == 1) {
    b = 30;
    printf("%d, %d\n", a, b);
  } else {
    printf("%d\n",b);
  }

  return 0;
}

コードに示されているように、abreakが欠落しているため、1 を入力すると、ケース 2 に移行します。1 の出力は、b後で上書きされるため、これを反映していません。したがって、たとえばセットから数値を入力することによって設計できるすべてのテストは、{1, 2, 10}すべて正しい出力になります。

実際には、 内の割り当てはswitch非常にコストがかかる可能性があるため、このバグは非常に高くつく可能性があります。しかし、初日からこのように書かれたと仮定すると、コストが予想よりも高いことを確認するベンチマークはありません。

では、この種のエラーを洗い流すにはどうすればよいでしょうか? 実稼働ソフトウェアで公開するテスト ケースを設計する方法はありますか?

編集 だから私は完全に明確ではなかったと思います-発生した問題の種類を説明するためにCで書きましたが、実際にはCに固有のものではありません.私が作ろうとしているポイントは、コードがセクションに入るということです入るつもりはありませんでした（この場合はbreak、要点を説明するのを忘れたためです）。私の実際のケースは、700,000 行の Fortran コードであり、言語の観点からは正当であるが非常に高価になる可能性がある不十分な if/switch 設計のために、意図したことのない分岐に入ります。

テストを設計したり、あるべきではないブランチに入ることを教えてくれるツールからのデータを調べたりすることは可能ですか? 「私はここにいるべきではない！」と印刷して間違いを見つけました。すべてのケースの中でそれが印刷されているのを見たので、無作為にそれを見て印刷ステートメントを入れるよりも良い方法があるはずです.

4

5 に答える 5

1

なぜこれが私が尋ねるバグなのですか？あらゆる種類のブラックボックステストを使用すると、コードが機能します。したがって、コードが機能することが唯一の要件である場合、バグはありません。

しかし、コードには欠陥があります。その欠落breakにより、コードが理解しにくくなり、保守が難しくなります。

コーディング規約は、コードの外観に関する規則です。コーディング規則の順守は、コンパイルされたプログラムをテストすることによって行うことはできません。ソースコードで行う必要があります。

コーディング規約のテストは、コード検査（自動または手動）によって行われます。

編集：

パフォーマンスが心配な場合は、インストルメンテーションツールを使用して「ホットスポット」を見つけてください。実行時間のほとんどは、おそらくほんの数個のモジュールに費やされていることがわかります。それらのモジュールとそれらへのすべての呼び出しを確認してください。10〜30000行のコードを確認するだけでよいことがわかります。レビューの範囲が限られているため、レビューには1〜3週間かかります。

結論：微妙なバグを見つけることに関しては、コードレビューはテストよりもはるかに優れています。

于 2012-12-03T09:55:40.410 に答える
1

各分岐が特別な状態を課すように、switch ステートメントのコーディング規則を定義できます。まさにケースの値が割り当てられる変数のように。例えば：

switch (v) {
case 1: 
    vcheck = 1;
    ...
    break;
case 2:
    vcheck = 2;
    ...
    break;
}

そしてvcheck、テスト ケースでテストします。

それ以外に、MISRA ルールの検証の静的コード分析を実行するツールを使用して、それらをビルド プロセスに組み込むことができます。彼らは心の一部を誘発します... :-)

最後に、(私のお気に入り) そのようなケースをチェックして再度警告するスクリプトを作成できます。

于 2012-12-03T06:11:20.367 に答える
1

ケース 1 の正しい状態は、b が設定されないことです。

b が設定されているかどうかを確認します。

後で b を設定する場合は、コードを小さなセグメントに分割してこれをテストする必要があるかもしれませんが、それは優れたモジュール性です。

「テストできないコードをテストするにはどうすればよいですか?」と尋ねているようです。答えは、テスト可能なコードを書くにはスキルと計画が必要であり、単なる後付けではないということです。

Web 上には、テスト可能なコードを作成するのに役立つ情報がたくさんあります。

https://www.google.com/search?q=writing+testable+code

于 2012-12-03T06:22:01.223 に答える