Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TDD for Embedded C -5章-

572 views

Published on

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

Published in: Technology
  • Be the first to comment

TDD for Embedded C -5章-

  1. 1. 第五章 (pp85-100) 組み込みTDD戦略
  2. 2. いままで ● LEDドライバを例にとったTDD ● テストケースを書く ● テストを失敗させる ● 実装する ● テストが通る ● リファクタリング
  3. 3. ホストシステムでのテストの価値 今までホストシステム上でのテストをしてきた ● それらのテストの利点,        価値とはどういうものなのか ● なぜ組み込みでTDDを用いるのか
  4. 4. ハードウェアボトルネック ● 組み込みシステムを開発する上で必要なもの ● ● ● ソフトウェア(ハードウェア駆動(制御)システ ム) ハードウェアボトルネックとは? ● ● ● ハードウェア(モータ,センサ.etc) ハードウェアが足かせになってしまうこと ソフトウェアの開発がハードウェアによって, 制限されてしまうこと どのように開発していくのが効率的か?
  5. 5. ハードウェアボトルネック ● テスト駆動開発を用いない開発 ● ● ハードウェアが(完成し)ないとソフトウェアのデバッグ ができない ハードウェアとソフトウェアを結合したときに多くのバグ が生じる可能性がある です ダメ 進捗     統合後にバグが発生しやすい      開発期間が長くなってしまう(時間を無駄にする)    それに伴い開発コストもかかる    
  6. 6. ハードウェアボトルネック ● テスト駆動開発を用いた開発 ● ● ハードウェアの完成を待たずにソフトウェアのデバッ グができる ソフトウェアのバグを出来るだけ消しておくことで, ハードウェアとの統合時に生じるバグを小さくするこ とができる !! です OK 捗 進 統合後に起こるバグが比較的少ない            開発期間の短縮化       開発コストの削減      
  7. 7. ハードウェアボトルネック ● 結果的にテスト駆動開発を用いることで, ハードウェアボトルネックを回避することができる ● ● ハードウェア作ってる間にソフトウェアのデバッグを ほとんど終わらせておけば,統合後が楽! 我々はブロックされない ● ターゲットハードウェアによってソフトウェアの開発が 左右されない
  8. 8. デュアルターゲット ● デュアルターゲットとは… ● 最終的に駆動するハードウェアシステムと ホストシステム(ここでは開発用PCを意味する と思う) で駆動できるように設計すること ● 前回までのLEDドライバなら,本来はマイコン ボードなどで駆動すると思われるものを,PCで テストしてきた →デュアルターゲット
  9. 9. デュアルターゲット ● ハードウェアにもバグがある! ● ● ● 私達はソフトウェアを開発しているが,ハードウェ アにもバグが有ることを忘れてはいけない テスト対象のソフトウェアをハードウェアから 完全に切り離してテストすることにより, ハードウェア,ソフトウェア双方の効率のよい 開発につながる 「ソフトにバグがあると思ってたのにこれLEDのハ ンダ不良じゃああああああああん」 「あ,マイコンのピンアサイン間違えてた...」 が無くなる
  10. 10. デュアルターゲット ● デュアルターゲットの利点 ● ハードウェアが準備できる前にコードがテストできる ● ハードウェアボトルネックを避けることができる ● ソフトウェアとハードウェアを切り離して開発することがで きる →ハードウェアのバグの影響を受けない →ソフトウェア的には,ハードウェア依存の              少ない設計ができる →将来的なプラットフォーム(駆動対象)の変化に対応でき る
  11. 11. デュアルターゲット ● デュアルターゲットのリスク ● ホストシステムとターゲット側の言語機能の違い ● それぞれのコンパイラにバグがあるかもしれない →ホストで動いたからといってターゲットでも同 じ動作をするとは限らない ● ライブラリの違い ● データ型のサイズの違い→2byte int と4byte int など
  12. 12. デュアルターゲット ● まとめ ● デュアルターゲットはハードウェアボトルネック              の回避に役立つ ● ハードウェアとソフトウェアをできるだけ切り離 した開発ができる ● 将来的なプラットフォームの変化に対応できる ● それぞれのコンパイラ,システムの変化に注意
  13. 13. 組み込みTDDサイクル ● 組み込みTDDサイクルとは ● 1.4 TDDのマイクロサイクルの拡張版 ● マイクロサイクルだけやっててもダメ. ● 目的はターゲットシステム上で動かすこと →ターゲットシステム上で動かすために   TDDを用いて行う開発サイクルのこと
  14. 14. 組み込みTDDサイクル ● ステージ1 [TDDのマイクロサイクル] ● 前回までやってきたLEDドライバのテスト駆動開 発のようなものの繰り返し ● サイクルの中で最も頻繁に行う ● プラットフォームに依存しないコードを書く テストコードを書く →コードを書く →テストの成功させる →リファクタリング
  15. 15. 組み込みTDDサイクル ● ステージ2 [コンパイラの互換性チェック] ● ● ● ● テストしてきたコードを実際のターゲット向けに コンパイルする 言語機能,ヘッダ,ライブラリにおけるバグに対応 新しくしようする言語機能,ライブラリ,ヘッダの 使用時にやっておくとよい ターゲット向けコンパイルが通るかチェック →実際にターゲットで動くかはわからない ● ビルドに時間がかかるが,ターゲットにダウンロードす る時間はかからない
  16. 16. 組み込みTDDサイクル ● ステージ3 [評価ボード上でのユニットテスト] ● ● ● ● ホストシステムでのコードの実行結果と ターゲット上での結果をチェックする ターゲットシステム上でも,ホストシステムで予期し た振る舞いをするか? ターゲットハードウェアが使えるのであればそちらを 使ってもよい[ステージ4],がそのハードが本当に信頼 できるかが問題 先に評価ボードで動いていれば,ターゲットで振る舞 いが変わった時にハードのバグだとすぐわかる
  17. 17. 組み込みTDDサイクル ● ステージ4 [ターゲットハード上でのユニットテスト] ● ● ● 目的はステージ3と同じ ステージ3とは違い,実際のターゲットハードウェアを使っ てユニットテストを行う. ターゲットハードウェア固有のテストもできる →評価ボードは汎用性を高めてあるので できないテストもある ● ターゲット上のメモリの容量によってすべてのテストができ ないかもしれない →複数のテストスイート(関連するテストケースのセット) に分割して行う
  18. 18. 組み込みTDDサイクル ● ステージ5 [ターゲット上での受け入れテスト] ● ターゲット上で自動,及び手動の受け入れテストをする ● 製品機能がきちんと動いているか確認 ● ● 自動ではうまくいかないハードウェアに依存するテストは手動でテス トする 受け入れテスト ● ● 開発したシステムが,要求機能や性能を備えているかどうかを確認す るテスト なんで受け入れ? [クライアント|ユーザ|カスタマー]の指定した要求に答えてるか,その 製品を受け入れることができるかのチェックだから
  19. 19. 組み込みTDDサイクル ● まとめ ● ● 基本的にステージの少ないものをこまめにやっ て,ある程度やったら次のステージのテスト をする.コレを繰り返す もしかしたら評価基板やターゲットが準備出来て いないかもしれない →仕方がないのでステージ3までを繰り返す →臨機応変に,状況を把握しながらやる ● 基本的にステージ1でテストされているので, コード自体の問題はそこでおおむね解決される
  20. 20. 5.5 デュアルターゲットの非互換性 ● プロダクトコードをテストするために ● ● ホストシステムとターゲットでテストするため には,2つの環境で同じように動くコードが必要 ランタイムライブラリにおけるバグ ● ホストシステム上で動いたテストが失敗するの にターゲット上だと失敗する…とか →ランタイムライブラリにはバグが有ること があるということを頭のなかに入れておく必要 が有る
  21. 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. 22. 5.5 デュアルターゲットの非互換性 ● 互換性のないヘッダファイル ● ● ヘッダファイルのシグネチャ,関数名,定義の違い 条件コンパイルをしない ● ● ● プリプロセッサで対処もできるが… プラットフォームごとにディレクトリを作成し,そこに プラットフォーム固有のコードを入れるとよい プリプロセッサの代わりにコンパイラとリンカを使う
  23. 23. ハードウェアを使ったテスト ● いままで ● ● ● ホストシステム上でのテストのみ 組み込みTDDサイクルの3-5ステージのテストは? →実際にどうやってハードウェア上でテストするの か? 自動ハードウェアテスト ● ハードウェアの動作を必要としないテスト ● テストコードを動かすだけでできるテスト
  24. 24. ハードウェアを使ったテスト ● 部分的自動ハードウェアテスト ● ● LEDDriverでは,コードを”だまして”いた(virtual leds) ソフトウェアをテストしているのではない. 組み込みテストをテストする →ハードウェア依存のバグもテストする じゃあ・・・? ● ● テスタに対してマニュアル(手動)でシステムをテ ストする ハードウェア依存のコードを少なくすると, このプロセスでのコードの変更が少ない
  25. 25. ハードウェアを使ったテスト ● 外部装置を使ったテスト ● ● マニュアルテストまでもを自動化する 手作業を自動化することで,時間の短縮, 作業の効率化を図る
  26. 26. 急がば回れ ● ● ● TDD通した自動テストは,開発していく上 でのセーフティネットになる! セーフティネットがあれば機能の追加を心 置きなくできる! TDDは”めんどくさい”けどその価値は確実に ある ● 1つ1つのプロセスをテストしているのだから 信頼性は確実にある
  27. 27. ま と め ● ハードウェアに縛られない!ハードとソフトの分離 ● TDDでソフトウェアを思う存分開発! ● ターゲットの変化にも対応できる! ● ハードとの統合時のバグを減らす!明確化できる! ● ● デュアルターゲット時にはリスクもある. →どのようなことが起こりうるのか頭に入れて開発する リスクをどう減らすか →組み込みTDDをサイクルと ハードウェアテストを用いることで減らせる!

×