目次 前

---

テストはスマートに

　システムやプログラムを作成した場合、必ずテストが
　必要になります。

　テストが必須なら、コンピュータを駆使して
　スマートに裁いて、時間短縮を考えるべき。

　関数、サブルーチンのテストの場合、入力と出力を
　書き出して、出力の期待値と実際の値を比較します。

　比較に、アプリケーションソフトのひとつである
　spreadsheetを使います。

　テストする関数、サブルーチン名を書いて、入力、出力の
　期待値、実際の出力値、副作用で発生する内容をセル中に
　書込んで、比較と検証をします。



　テストで使った値を書いておくと、NGの再現が
　簡単になります。

　具体的な数値を使えば、範囲外の入力を与えたのか
　不適切な内部処理なのかを判断可能です。

　入力→加工→出力を実行するのが、関数、サブルーチンの
　基本処理なので、それに従って加工が設計通りかを確認。

　ファームウエアの開発では、次の２つを多用します。

driver
stub

　driverは、下位の関数、サブルーチンをテストする
　ときに使う、仮の上位ブロック。

　stubは、上位から呼出される、仮の関数、仮のサブルーチン。

　ファームウエアの構造は、次のようになっていれば
　mainとfunctionの関係が、driver、stubの関係です。



　Cでファームウエアを作成するときに、自分はmainとfunctionを
　次のように骨格だけを作成します。

void main(void)
{
  /* initialize */
  usr_init();
  /* set interrupt */
  set_int();
  /* endless loop */
  while ( ON ) {
    /* command interpreter */
    if ( sflag == ON ) {
      /* clear flag */
      sflag = OFF ;
      /* get command */
      cmd = *(sbuf+0) ;
      /* help */
      if ( cmd == '?' ) { show_help(); }
      /* activate */
      if ( cmd == 'A' ) { set_aflag(); }
      /* disable */
      if ( cmd == 'D' ) { clear_aflag(); }
    }
    /* LED handling */
    led_handling();
  }
}

void usr_init(void)
{
  puts("usr_init");
}

void set_int(void)
{
  puts("set_init");
}

void show_help(void)
{
  puts("usr_init");
}

void set_aflag(void)
{
  aflag = ON ;
  puts("set_aflag");
}

void clear_aflag(void)
{
  aflag = OFF ;
  puts("clear_aflag");
}

　上のコードでは、mainが使っている、各関数はstubになり
　論理動作が正しいのかをテストしていると言えます。

　driverは、CUIを利用してファームウエアを動かすマイコン
　ではなく、Personal Computerを使ってテストすればOK。
　その内容は、以下。

void main(void)
{
  /* help */
  show_help();
}

void show_help(void)
{
  puts("? help");
  puts("A set aflag");
  puts("D clear aflag");
}

　テストに関係する話題を扱うのに、ファームウエアの
　開発を説明していますが、この手法はテスト駆動開発
　(test-driven development)と呼ばれ、広く普及して
　います。

　テスト駆動開発は、テストが容易になるように関数や
　サブルーチンを定義して、効率向上とバグ侵入を防止
　することが主眼。

　開発時間が短いファームウエア作成では、マスター
　しておくべきだと考えます。

　ファームウエアは、マイコンに内蔵されるのでGPIOの
　入出力指定と内蔵モジュール用ピンの競合がないよう
　注意が必要。

　GPIOとは、General Purpose Inputs and Outputsのことで
　具体的にはマイコンのピンを、デジタル入出力で扱うこと
　と等価です。

　最近のマイコンは、内部にシリアルやタイマーを持つので
　それらのモジュールが使うピンが固定なので、デジタルの
　入出力では使えなくなります。

　ファームウエア開発で、最初に作成するのは、デジタル入出力
　の指定と内蔵モジュールの設定にします。

　最初に、指定と設定を記述したなら、最初にテスト
　する対象です。ここに不具合があると、後の作成が
　崩壊すると理解できるはず。

　入出力指定で注意するのは、論理値の'1'と'0'の使い方。

　'1' = Input  '0' = Output
  '1' = Output '0' = Input  

　という指定の仕方に違いがあります。

　上の指定方式は、単語の頭文字を意識しているのに対し
　下の指定方式は、凹凸を考えています。
　使うマイコンが、どちらを採用しているかはdatasheet
　で確認します。

　WEBサイトの検索で、copy and pasteの方がスマートに
　見えるかも知れませんが、datasheetで確認します。

　datasheetは、マイコンの設計、開発、製造企業が
　公開しているので、GPIOに関しては正確です。
　WEBサイトの情報では、作成者が思い違いをしている
　こともあり得るので、必ずdatasheetで確認します。

　関数、サブルーチンの動作テストには、２種あります。
　black box test、white box testが、その２種。

　black box test

　　入力、出力だけに着目して、内部を見ることは
　　しないで、動作テストします。

　　入力と出力だけに目を向けるので、内部には立入らず
　　プログラム開発者でなくとも、テストドライバだけを
　　作成できれば、テストは可能。

　white box test

　　入力、加工、出力の流れを着目して、内部まで
　　立ち入って、動作テストします。

　　プログラム開発環境にデバッガが備わっていれば
　　break pointを使い、変数値の変化、途中動作を
　　詳細にトレースできます。

　　デバッガの機能が貧弱な場合、変数値の変化、途中動作
　　をトレースするには、Cなら「printf」を利用し、途中
　　経過や変数値を表示させて、テスト可能。

　　デバッガの優れた機能を使えると安心しないで、何を
　　参照するのかを、見極めて、テストに臨まないと余計
　　な作業をすることになるので、注意が必要です。

---

目次 前