テスト駆動開発による組み込みプログラミング　第5章

1. 第五章
(pp85-100)
組み込みTDD戦略

2. いままで
●
LEDドライバを例にとったTDD
●
テストケースを書く
●
テストを失敗させる
●
実装する
●
テストが通る
●
リファクタリング

3. ホストシステムでのテストの価値
今までホストシステム上でのテストをしてきた
●
それらのテストの利点，
価値とはどういうものなのか
●
なぜ組み込みでTDDを用いるのか

4. ハードウェアボトルネック
●
組み込みシステムを開発する上で必要なもの
●
●
●
ソフトウェア（ハードウェア駆動（制御）システ
ム）
ハードウェアボトルネックとは？
●
●
●
ハードウェア（モータ，センサ．etc)
ハードウェアが足かせになってしまうこと
ソフトウェアの開発がハードウェアによって，
制限されてしまうこと
どのように開発していくのが効率的か？

5. ハードウェアボトルネック
●
テスト駆動開発を用いない開発
●
●
ハードウェアが（完成し）ないとソフトウェアのデバッグ
ができない
ハードウェアとソフトウェアを結合したときに多くのバグ
が生じる可能性がある
です
ダメ
進捗
統合後にバグが発生しやすい
開発期間が長くなってしまう（時間を無駄にする）
それに伴い開発コストもかかる

6. ハードウェアボトルネック
●
テスト駆動開発を用いた開発
●
●
ハードウェアの完成を待たずにソフトウェアのデバッ
グができる
ソフトウェアのバグを出来るだけ消しておくことで，
ハードウェアとの統合時に生じるバグを小さくするこ
とができる
!!
です
OK
捗
進
統合後に起こるバグが比較的少ない
開発期間の短縮化
開発コストの削減

7. ハードウェアボトルネック
●
結果的にテスト駆動開発を用いることで，
ハードウェアボトルネックを回避することができる
●
●
ハードウェア作ってる間にソフトウェアのデバッグを
ほとんど終わらせておけば，統合後が楽！
我々はブロックされない
●
ターゲットハードウェアによってソフトウェアの開発が
左右されない

8. デュアルターゲット
●
デュアルターゲットとは…
●
最終的に駆動するハードウェアシステムと
ホストシステム（ここでは開発用PCを意味する
と思う）
で駆動できるように設計すること
●
前回までのLEDドライバなら，本来はマイコン
ボードなどで駆動すると思われるものを，PCで
テストしてきた
→デュアルターゲット

9. デュアルターゲット
●
ハードウェアにもバグがある！
●
●
●
私達はソフトウェアを開発しているが，ハードウェ
アにもバグが有ることを忘れてはいけない
テスト対象のソフトウェアをハードウェアから
完全に切り離してテストすることにより，
ハードウェア，ソフトウェア双方の効率のよい
開発につながる
「ソフトにバグがあると思ってたのにこれLEDのハ
ンダ不良じゃああああああああん」
「あ，マイコンのピンアサイン間違えてた...」
が無くなる

10. デュアルターゲット
●
デュアルターゲットの利点
●
ハードウェアが準備できる前にコードがテストできる
●
ハードウェアボトルネックを避けることができる
●
ソフトウェアとハードウェアを切り離して開発することがで
きる
→ハードウェアのバグの影響を受けない
→ソフトウェア的には，ハードウェア依存の
少ない設計ができる
→将来的なプラットフォーム（駆動対象）の変化に対応でき
る

11. デュアルターゲット
●
デュアルターゲットのリスク
●
ホストシステムとターゲット側の言語機能の違い
●
それぞれのコンパイラにバグがあるかもしれない
→ホストで動いたからといってターゲットでも同
じ動作をするとは限らない
●
ライブラリの違い
●
データ型のサイズの違い→2byte int と4byte int など

12. デュアルターゲット
●
まとめ
●
デュアルターゲットはハードウェアボトルネック
の回避に役立つ
●
ハードウェアとソフトウェアをできるだけ切り離
した開発ができる
●
将来的なプラットフォームの変化に対応できる
●
それぞれのコンパイラ，システムの変化に注意

13. 組み込みTDDサイクル
●
組み込みTDDサイクルとは
●
1.4 TDDのマイクロサイクルの拡張版
●
マイクロサイクルだけやっててもダメ．
●
目的はターゲットシステム上で動かすこと
→ターゲットシステム上で動かすために
TDDを用いて行う開発サイクルのこと

14. 組み込みTDDサイクル
●
ステージ1 [TDDのマイクロサイクル]
●
前回までやってきたLEDドライバのテスト駆動開
発のようなものの繰り返し
●
サイクルの中で最も頻繁に行う
●
プラットフォームに依存しないコードを書く
テストコードを書く
→コードを書く
→テストの成功させる
→リファクタリング

15. 組み込みTDDサイクル
●
ステージ2 [コンパイラの互換性チェック]
●
●
●
●
テストしてきたコードを実際のターゲット向けに
コンパイルする
言語機能，ヘッダ，ライブラリにおけるバグに対応
新しくしようする言語機能，ライブラリ，ヘッダの
使用時にやっておくとよい
ターゲット向けコンパイルが通るかチェック
→実際にターゲットで動くかはわからない
●
ビルドに時間がかかるが，ターゲットにダウンロードす
る時間はかからない

16. 組み込みTDDサイクル
●
ステージ3 [評価ボード上でのユニットテスト]
●
●
●
●
ホストシステムでのコードの実行結果と
ターゲット上での結果をチェックする
ターゲットシステム上でも，ホストシステムで予期し
た振る舞いをするか？
ターゲットハードウェアが使えるのであればそちらを
使ってもよい[ステージ4]，がそのハードが本当に信頼
できるかが問題
先に評価ボードで動いていれば，ターゲットで振る舞
いが変わった時にハードのバグだとすぐわかる

17. 組み込みTDDサイクル
●
ステージ4 [ターゲットハード上でのユニットテスト]
●
●
●
目的はステージ3と同じ
ステージ3とは違い，実際のターゲットハードウェアを使っ
てユニットテストを行う．
ターゲットハードウェア固有のテストもできる
→評価ボードは汎用性を高めてあるので
できないテストもある
●
ターゲット上のメモリの容量によってすべてのテストができ
ないかもしれない
→複数のテストスイート（関連するテストケースのセット）
に分割して行う

18. 組み込みTDDサイクル
●
ステージ5 [ターゲット上での受け入れテスト]
●
ターゲット上で自動，及び手動の受け入れテストをする
●
製品機能がきちんと動いているか確認
●
●
自動ではうまくいかないハードウェアに依存するテストは手動でテス
トする
受け入れテスト
●
●
開発したシステムが，要求機能や性能を備えているかどうかを確認す
るテスト
なんで受け入れ？
[クライアント|ユーザ|カスタマー]の指定した要求に答えてるか，その
製品を受け入れることができるかのチェックだから

19. 組み込みTDDサイクル
●
まとめ
●
●
基本的にステージの少ないものをこまめにやっ
て，ある程度やったら次のステージのテスト
をする．コレを繰り返す
もしかしたら評価基板やターゲットが準備出来て
いないかもしれない
→仕方がないのでステージ3までを繰り返す
→臨機応変に，状況を把握しながらやる
●
基本的にステージ1でテストされているので，
コード自体の問題はそこでおおむね解決される

20. 5.5 デュアルターゲットの非互換性
●
プロダクトコードをテストするために
●
●
ホストシステムとターゲットでテストするため
には，2つの環境で同じように動くコードが必要
ランタイムライブラリにおけるバグ
●
ホストシステム上で動いたテストが失敗するの
にターゲット上だと失敗する…とか
→ランタイムライブラリにはバグが有ること
があるということを頭のなかに入れておく必要
が有る

21. 5.5 デュアルターゲットの非互換性
●
strstrの例
●
●
●
引数1の文字列の中から引数2の文字列を検索する
空の文字列は，どんな文字列にも含まれるべき
if (strlen(other) == 0) もし検索する文字列が空(長さが0)なら
return TRUE; それは含まれる
else if (strlen(s) == 0) もし検索される文字列が空で，検索する文字列が
return FALSE; 空でないならそれは含まれない（空の文字列に空
else
の文字列以外は含まれない）
return strstr(s, other) !=NULL;
それ以外はこのライブラリの
strstrで対処できる

22. 5.5 デュアルターゲットの非互換性
●
互換性のないヘッダファイル
●
●
ヘッダファイルのシグネチャ，関数名，定義の違い
条件コンパイルをしない
●
●
●
プリプロセッサで対処もできるが…
プラットフォームごとにディレクトリを作成し，そこに
プラットフォーム固有のコードを入れるとよい
プリプロセッサの代わりにコンパイラとリンカを使う

23. ハードウェアを使ったテスト
●
いままで
●
●
●
ホストシステム上でのテストのみ
組み込みTDDサイクルの3-5ステージのテストは？
→実際にどうやってハードウェア上でテストするの
か？
自動ハードウェアテスト
●
ハードウェアの動作を必要としないテスト
●
テストコードを動かすだけでできるテスト

24. ハードウェアを使ったテスト
●
部分的自動ハードウェアテスト
●
●
LEDDriverでは，コードを”だまして”いた(virtual leds)
ソフトウェアをテストしているのではない．
組み込みテストをテストする
→ハードウェア依存のバグもテストする
じゃあ・・・？
●
●
テスタに対してマニュアル（手動）でシステムをテ
ストする
ハードウェア依存のコードを少なくすると，
このプロセスでのコードの変更が少ない

25. ハードウェアを使ったテスト
●
外部装置を使ったテスト
●
●
マニュアルテストまでもを自動化する
手作業を自動化することで，時間の短縮，
作業の効率化を図る

26. 急がば回れ
●
●
●
TDD通した自動テストは，開発していく上
でのセーフティネットになる！
セーフティネットがあれば機能の追加を心
置きなくできる！
TDDは”めんどくさい”けどその価値は確実に
ある
●
1つ1つのプロセスをテストしているのだから
信頼性は確実にある

27. ま と め
●
ハードウェアに縛られない！ハードとソフトの分離
●
TDDでソフトウェアを思う存分開発！
●
ターゲットの変化にも対応できる！
●
ハードとの統合時のバグを減らす！明確化できる！
●
●
デュアルターゲット時にはリスクもある．
→どのようなことが起こりうるのか頭に入れて開発する
リスクをどう減らすか
→組み込みTDDをサイクルと
ハードウェアテストを用いることで減らせる！