組み込み開発でのシステムテスト自動化の一つの考え方（STAC）
•
18 likes•34,954 views
STAC2013/Lightning Automated Testing Demo
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 組み込み開発でのシステムテスト自動化の一つの考え方（STAC）
Similar to 組み込み開発でのシステムテスト自動化の一つの考え方（STAC） (20)
Recently uploaded
Recently uploaded (10)
組み込み開発でのシステムテスト自動化の一つの考え方（STAC）
- 1. 組み込み開発での システムテスト自動化の 一つの考え方 井芹 洋輝(STAR) システムテスト自動化カンファレンス2013 2013/12/1 @オラクル青山センター
- 2. 今回の発表について • 組み込み開発での上位テストの自動化の考え方の 一例を紹介します • 伝えたいこと – 組み込み開発ではシステムテスト・統合テストのテスト自 動化は重要です – それらのテスト自動化ではテストレベルに閉じこまらず、 責務や負荷を分散しましょう • 自己紹介 – 組み込み開発・テストのコンサル・エンジニア STAR、WACATE実行委員、TDDBC所属等 – 最近は車載のテスト自動化やシステムテスト支援に従事
- 3. 組み込み開発での システムテストの実行自動化は有効です ありがちな 組み込み開発の制約 ありがちな テストで対応すべき課題 テスト自動化の活用の余地 テスト条件の スケーラビリティの向上 （組み合わせや タイミング） リアルタイム性要求 複雑なタイミング設計 タイミング依存・順序依 存のバグ 現実世界との物理的な インターフェース 環境起因のデグレード ハードウェアのバグ 自動化による回帰 テストの効率化 頻繁に変わる実行環境 ソフトウェア以外の影響 の高さ 検出しにくい内部バグ 制御や観測の選択 肢の拡充 内部観測性の低さ
- 4. 組み込み開発での システムテストの実行自動化は有効です ありがちな 組み込み開発の制約 ありがちな テストで対応すべき課題 テスト自動化の活用の余地 組み合わせや、実施タイミング・同 時処理の条件パターンなどを増や リアルタイム性要求 タイミング依存・順序依 複雑なタイミング設計 して、タイミング依存バグを網羅的 存のバグ にカバー テスト条件の スケーラビリティの向上 （組み合わせや タイミング） 環境起因のデグレード ハードウェアや構成変更時 ハードウェアのバグ の軽快なチェック 自動化による回帰 テストの効率化 検出しにくい内部バグ 内部観測性の補強 自動化の幅を広げる 制御や観測の選択 肢の拡充 現実世界との物理的な インターフェース 頻繁に変わる実行環境 ソフトウェア以外の影響 の高さ 内部観測性の低さ
- 5. 組み込みでの システムテストの実行自動化 一般的な手段の例： 種類 手段 外部インターフェースを介し た自動化 ・操作ロボット ・外部の冶具ツール ・画像・映像解析 評価環境を用いた自動化 ・評価ボード上での実行 ・OSやフレームワークの組み換え 仮想・半仮想環境による自 動化 ・エミュレータやその他シミュレーションツール、ICE での自動化 コンポーネントの置換やテ スト用機能の組み込み ・MockオブジェクトやFakeオブジェクトの導入 ・自動操作機能、自己検証機能などの組み込み ●全体の傾向として コストや手間がかかる/環境や条件にカスタマイズが必要/ 本番環境と異なる/完全自動化が難しい場合が多い
- 6. システムテスト実行自動化では、テストの責 務と負荷の分散・軽減を推進しましょう • システムテストに閉じず、本来の品質やテストの 目的に立ち戻って制約に対応しましょう • テストや環境面は多方面で育て、多方面で活用 しましょう – コストパフォーマンスや恩恵が高まって、大きな効果 を得られるようになります
- 7. テストの責務を分散しましょう • システムテストに制約がある場合、そもそもテストの目 的に立ち戻りましょう • 統合テストや、半自動化、その他品質確認手段でしばし ばサポートできます 例 品質エンジニアリング 品質の目標や要求 テスト要求 テスト目的 テスト システムがフリーズしないこと： 機能Aでメモリリークがないこと 機能Aの想定される実行領域で メモリリークが発生しないこと 機能Aの想定条件化でメモリリークが 発生しないことを確認する ロボットでのロング ランテスト
- 8. テストの責務を分散しましょう • システムテストに制約がある場合、そもそもテストの目 的に立ち戻りましょう • 統合テストや、半自動化、その他品質確認手段でしばし ばサポートできます 例 品質エンジニアリング 品質の目標や要求 テスト要求 テスト目的 テスト システムがフリーズしないこと： 機能Aでメモリリークがないこと 機能Aの想定される実行領域で メモリリークが発生しないこと 機能Aの想定条件化でメモリリークが 発生しないことを確認する ロボットでのロング ランテスト Valgrind+gcov+テストインプット生 成コンポーネントによる自動結合 テスト
- 9. テストの責務を分散しましょう • システムテストに制約がある場合、そもそもテストの目 的に立ち戻りましょう • 統合テストや、半自動化、その他品質確認手段でしばし ばサポートできます 例 品質エンジニアリング 品質の目標や要求 テスト要求 テスト目的 テスト システムがフリーズしないこと： 機能Aでメモリリークがないこと コストパフォーマンスや バグ検出力の工場 機能Aの想定される実行領域で メモリリークが発生しないこと 機能Aの想定条件化でメモリリークが 網羅的な 最終チェック 発生しないことを確認する バグ出し ロボットでのロング ランテスト Valgrind+gcov+テストインプット生 成コンポーネントによる自動結合 テスト
- 10. テスト自動化の負荷を分散しましょう • 開発ライフサイクルを多方面に支えるインフラを構築し ましょう • 自動化のためのテスタビリティを前倒しで確保していき ましょう ●上位テストの実行自動化インフラ ・観測点/制御点インターフェース ログ出力、接合部、Dependency InjecIon、 Dependency Lookup、JTAG等・・ ・テスト用内部コンポーネント テストデータ生成機能、自己チェック機能、自動操 作機能等・・ ・Test Double Test Stub、Fakeオブジェクト、Mockオブジェクトな ど等・・ ・外部コンポーネント 評価ボード、操作ロボット、デバッガ、ICE等・・
- 11. テスト自動化の負荷を分散しましょう • 開発ライフサイクルを多方面に支えるインフラを構築し ましょう • 自動化のためのテスタビリティを前倒しで確保していき ましょう ●上位テストの実行自動化インフラ ・観測点/制御点インターフェース ログ出力、接合部、Dependency InjecIon、 Dependency Lookup、JTAG等・・ ・テスト用内部コンポーネント テストデータ生成機能、自己チェック機能、自動操 作機能等・・ ・Test Double Test Stub、Fakeオブジェクト、Mockオブジェクトな ど等・・ ・外部コンポーネント 評価ボード、操作ロボット、デバッガ、ICE等・・ 製品開発の中で 開発可能 開発者テスト・ ユニットテスト・統合 テストと共有して活 用可能
- 12. テスト自動化の負荷を分散しましょう • 例）自動化されたユニットテストの用途 – 開発中のCIでのテスト • 変更やリファクタリングの支援 • バグ混入の即時検出 • テストの保守 – 統合テストでの自動化手段 • テストコードやテスト用コンポーネントの流用 • 作りこまれたテスタビリティやテスト機能の活用 – システムテストでの自動化手段 • 作りこまれたテスタビリティやテスト機能の活用
- 13. テスト自動化の負荷を分散しましょう • 例）自動化されたユニットテストの用途 – 開発中のCIでのテスト • 変更やリファクタリングの支援 • バグ混入の即時検出 • テストの保守 – 統合テストでの自動化手段 • テストコードやテスト用コンポーネントの流用 • 作りこまれたテスタビリティやテスト機能の活用 – システムテストでの自動化手段 多方面で構築でき多方面で活用できる • 作りこまれたテスタビリティやテスト機能の活用 コストパフォーマンスやテストの効果が増大し、 選択肢が広がる
- 14. テストの負荷と責務の分散を支える ユニットテスト ・統合テスト 工程 開発 TDDによるユニッ トテスト・テスタビ リティの構築 CIによるテスト環 境の維持 テスト コード・ テスト のイン フラ テストの 整理 システム テストの 担保 システムテスト工程 テスト のイン フラ・ テストの 実施 自動化実現のインフラや制約の抽出 ●全体の目的や方針に対応するアプローチや手法をとる 全体テスト分析・計画の充実/テスト上流設計の整備/リスクマネジメント等の独立プロセ ス等 ●全体を支えるインフラを構築する CI/汎用的なTest Double/フレームワーク等
- 15. デモ
- 17. 組み込み開発での 継続的な自動テストの実行 • 構成 ターゲットマ ネージャ (独自スクリプ ト＋uno) CI (Jenkins) 開発環境 (CppUTest) 生成 ターゲットでの テスト ロード・実行 ログ取得 Junit形式 テスト レポート push Repository Hostのテスト 環境 (CppUTest) ホスト でのテスト （個人レベル） CIサーバ ホストでのテスト ターゲット 環境 (Arduino)
- 19. 組み込み開発での 継続的な自動テストの実行 • 構成 ホスト上のテスト と実機上のテス トを継続実行 CI (Jenkins) イテレーションご となど定期的な タイミングでテス トをまとめあげ 開発環境 (CppUTest) TDDを中心にプ ログラミング中に テストを構築 実機へのロード と実行結果の受 信 ターゲットマ ネージャ (独自スクリプ ト＋uno) 生成 Junit形式 テスト レポート push Repository たまった資産を 規模の大きい統 合テストやシステ ムテストで活用 Hostのテスト 環境 (CppUTest) ロード・実行 ログ取得 ターゲット 環境 (Arduino)