Tomorrow's software testing for embedded systems ～明日にでも訪れてしまう組込みシステムのテストの姿～
9 likes3,736 views
明日にでも訪れてしまう組込みシステムのテストの姿についての解説です。「手動テストを自動化する」から「自動テストできないところを手動でやる」にパラダイムシフトし、QA/テストアーキテクチャを構築することで、シフトレフトやシフトライトを行い部品/製品の品質保証状況を ダイナミックに把握し予測し品質リスクを最小化する仕組み（QualiTrax）を構築できます。
Tomorrow's software testing for embedded systems ～明日にでも訪れてしまう組込みシステムのテストの姿～
- 1. Tomorrow’s Software Testing for Embedded Systems ～ 明日にでも訪れてしまう組込みシステムのテストの姿 ～ 2019/10/23（水） ASTER 組込みCI研究会 東京地区勉強会 西 康晴 電気通信大学 大学院情報理工学研究科 情報学専攻 経営・社会情報学プログラム @YasuharuNishi / Yasuharu.Nishi@uec.ac.jp Also Read: https://www.slideshare.net/YasuharuNishi/line-developer-meetup-in-tokyo-39-presentation-modified https://www.slideshare.net/YasuharuNishi/ tomorrows-software-testing-for-embedded-systems -japanese
- 2. Profile • Assistant professor: – The University of Electro-Communications, Tokyo, Japan • President: – Association of Software Test Engineering, Japan - Nonprofit organization (ASTER) • President: – Japan Software Testing Qualifications Board (JSTQB) • National delegate: – ISO/IEC JTC1/SC7/WG26 Software testing (ISO/IEC(/IEEE) 29119, 33063, 20246) • Founder: – Japan Symposium on Software Testing (JaSST) • Founder: – Testing Engineers’ Forum (TEF: Japanese community on software testing) • Judgement Panel Chair / member: – Test Design Contest Japan, Test Design Competition Malaysia (TDC) • Vice chair: – Software Quality Committee of JUSE (SQiP) • Vice chair: – Society of Embedded Software Skill Acquisition for Managers and Engineers (SESSAME) • Steering Committee Chair – QA4AI Consortium • Advisor: – Software Testing Automation Research group (STAR) © NISHI, Yasuharup.2
- 7. 明日にでも訪れてしまう組込みシステムのテストの姿 既に実現しておくべき技術 • QA/テストアーキテクチャの構築 • テスト観点によるテスト設計 • TDD+狭義のCI • E2Eテスト自動化+KDT+MBT • シフトレフト/フロントローディング 明日の技術 • 機器内クラウド化と分散開発化 • フルMBD化とアジャイル化 • テスト自動生成からのフルCI • AIによる開発支援情報生成 • シフトライト（運用中テスト） © NISHI, Yasuharu OTAオープンソース /COTS/機械学習
- 8. 明日の技術 (1) – 機器内クラウド化と分散開発化 © NISHI, Yasuharup.8 ECU仮想化 機器内クラウド化 と分散開発化 現在 Unit A Unit B Unit C Cloud Platform Application Dev. Team
- 9. 明日の技術 (2) – フルMBD化とアジャイル化 © NISHI, Yasuharup.9 エッジクラウドディスパッチの バランスの最適化 フルMBD化 非同期開発化 （アジャイル化）
- 10. 明日の技術 (3) – テスト自動生成からのフルCI © NISHI, Yasuharup.10 膨大な人力テストによる 開発遅延を引き起こす 同期型一発勝負的品質保証 フルCI（全ての検証の自動化によるCI）による 短いリリースサイクルでも成功しやすい 非同期型継続的漸進的品質保証 テスト自動生成
- 11. 既に実現しておくべき技術 (1) – QAアーキテクチャの構築 © NISHI, Yasuharup.11 色々やってるが 実はバラバラで 全体像が 把握できないQA 整理されており 全体像が 把握しやすいQA 「我々は全体として 何を保証しているのだろう？」
- 12. 既に実現しておくべき技術 (1) – QAアーキテクチャの構築 © NISHI, Yasuharup.12 バラバラなQA観点 整理されたQA観点 ハードウェアにおける QC工程表や QAネットワーク にあたるものを 構築する必要がある
- 13. 既に実現しておくべき技術 (1) – テストアーキテクチャの構築 © NISHI, Yasuharup.13 テストコンテナ テスト観点 Test architecture design in Daimler Systematic Test Platform Selection - Reducing Costs for Testing Software-based Automotive E/E Systems C. Schwarzl and J. Herrmann in ICST 2018 Industry session ・テスト観点 ダイムラーによる テスとアーキテクチャ構築の取り組み テストコンテナ
- 14. 既に実現しておくべき技術 (2) – テスト観点によるテスト設計 © NISHI, Yasuharup.14 Kind of OS OS Platform Environment - Win10 - Win8 - Win7 テスト値 ボトムテスト観点 ＝パラメータ テスト観点 テスト観点 テスト観点 マインドマップを用いた テスト観点モデル シンプルなテストフレームの例 複雑なテストフレームの例
- 15. 既に実現しておくべき技術(3) – TDD+狭義のCI © NISHI, Yasuharup.15 “Test Yourself” by Takuto Wada @ JaSST Hokkaido 2014 https://cloud.google.com/solutions/continuous-integration/ 「狭義のCI」とは ビルドより前に 開発者によって書かれた 自動テストコードによる ＣＩ（継続的インテグレーション） である
- 16. 既に実現しておくべき技術 (4) – E2Eテスト自動化+KDT+MBT © NISHI, Yasuharup.16 ISO/IEC/IEEE 29119-5:2016 Quality Commander https://www.jnovel.co.jp/service/qc/product/ “It is great that we automate our tests, but why are they so bad?” by Jeff Offutt @ ICST 2018 テストの自動化を進めると 仕様や設計のモデル化も進むし テスタビリティ（テスト容易性）設計 も進むので そもそものソフトの品質が向上する ハードも含めたE2Eテスト自動化は 当然行われるべき技術になった KDT（キーワード駆動テスト）を適用して 自動化しやすいテストケースを設計する 仕様や設計を可能な限りモデル化すると MBT（モデルベーステスト）で テストケースを自動生成できる
- 17. 既に実現しておくべき技術(5) – シフトレフト/フロントローディング © NISHI, Yasuharup.17 分析してパターン化して 再利用して 開発を成長させる 開発やバグの 情報 使い捨てなので 開発は成長しない 開発やバグの情報 フロントローディングをしない組織 フロントローディングが根付いた組織
- 18. 明日の技術 (4) – AIによる開発支援情報生成 © NISHI, Yasuharup.18 デジタル化された 開発やバグの情報 機械学習によって AIが開発支援情報 を生成してくれる 開発やバグの 情報 使い捨てなので 開発は成長しない フロントローディングをしない組織 フロントローディングが根付き デジタルトランスフォーメーションが できている組織
- 19. 明日の技術 (5) – シフトライト（運用中テスト） © NISHI, Yasuharup.19 時代遅れの フェーズゲート型 （しかし本当は終わってことにしているだけの） QA フルCI シフトライト型QA （運用中にもテストを行い 品質を監視することで 常に品質を保証し続ける） OTA オープンソース /COTS/機械学習
- 20. QualiTrax: 明日にでも訪れてしまう組込みシステムのテストの姿 © NISHI, Yasuharu OTAオープンソース /COTS/機械学習 既に実現しておくべき技術 • QA/テストアーキテクチャの構築 • テスト観点によるテスト設計 • TDD+狭義のCI • E2Eテスト自動化+KDT+MBT • シフトレフト/フロントローディング 明日の技術 • 機器内クラウド化と分散開発化 • フルMBD化とアジャイル化 • テスト自動生成からのフルCI • AIによる開発支援情報生成 • シフトライト（運用中テスト）
- 22. 知ってますよね？ • KomTrax – できること • どこで動いてどこで壊れるか、が分かる – やり取りされる情報 • ハードウェアの寿命情報、位置情報 • InterNavi – できること • どこで動いてどこでどう使われるか、が分かる – やり取りされる情報 • 位置情報、（疑似）機能利用情報 © NISHI, Yasuharup.22
- 23. QualiTrax構想 • QualiTraxとは – 部品/製品の品質保証状況を ダイナミックに把握し予測し品質リスクを最小化する仕組み • フェーズゲート方式のように静的な把握・予測ではなく 常にテストなどを行い動的な把握・予測を行う – OTAによってOSSやCOTS、MLなどが動的に変化しても、 常に最新の品質保証状況を非同期に得ることができる » そのために「手動テストを自動化する」から「自動テストできないところを手動でやる」にパラダイムシフトする • 開発中だけでなく稼働中であっても把握し予測する – 開発中からの品質保証状況が全てデジタル化され構造化され記録されているため、 稼働中の不具合検知に対する原因究明が最速で可能になる » そのためにテスト容易性設計とQAアーキテクチャの構築が必要になる – 「終わったことになっている」テストを許さず、 デプロイ前には品質リスクの高いテストを行って運用中には品質リスクの低いテストを行うなど スピードと品質リスクのバランスを取ることができるようになる » アジャイル化に対応したQAを行うことができるようになる • 構成や稼働環境などの異なる全ての部品/製品について把握し予測する – 様々な構成や稼働環境の違いを次期部品/製品に反映できるだけでなく、 構成や環境によってデプロイする機能や制約を動的に変えることによって 品質リスクを最小化することが可能になる – 未テストの部品/製品の品質リスクを、よく似た構成のテスト済みの部品/製品から推測することで ピンポイントにバグを見つけるテストを設計することができる © NISHI, Yasuharup.23
- 24. QualiTrax構想 • QualiTraxで可能になる世界 – OTAによるダイナミックコンフィグレーション • ECU待機時間での運用中テスト • ECU高性能化・冗長化による継続的障害発生／縮退動作テスト – OTAに伴うカナリア環境 • 受動的A/Bテスト（択一選択による現プロダクトの最適化） • 能動的A/Bテスト（運用中の高速実験による次期プロダクトのための好みの把握） → 能動的InterNavi • OTAによるデグレードやハードウェア故障への即時対応 → ハード・ソフト統合型KomTrax – 仮想化による車内クラウド • エッジクラウドディスパッチの3層化による計算資源の最適化 • 疑似余剰ECUによるテスト対象ECUの運用中テスト・継続的障害発生／縮退動作テスト – デジタルツインのキャリブレーション • モデルベース／シミュレーション環境における ハードウェア・実世界のモデル精度のためのフィードバック – （機械学習による）欠陥流入点の動的予測 • デジタル化された開発情報と 膨大なコンフィグレーションからの動作情報や運用中テスト結果とを元にした 欠陥が入り込んだタイミングとモジュールの予測 © NISHI, Yasuharup.24
- 25. QualiTrax構想 • プラットフォームを制するものが勝つ世界になる – OEM-QualiTrax • 自社製品に標準搭載し、自社出荷台数をベースとして規模を高め、 単一のQualiTraxマネジメントシステムを構築する – Tier0.5-QualiTrax • QualiTrax対応ユニットでキモを押さえ、システムとしての販売を行い、 OEMごとのQualiTraxマネジメントシステムのインスタンスを構築する – 複数のOEMに展開できる – QualiTraxそのものの開発費用は単一で済む – QualiTraxの運用も受注でき、自社の開発改善につなげることができるようになる – (Test)Vendor-QualiTrax • QualiTraxの規格をオープン化し、OEMやサプライヤに導入を促し、 自社でQualiTraxマネジメントシステムを構築し、そのインスタンスを提供する – 複数のOEM、複数のサプライヤ、複数の業種に展開できる – QualiTraxの規格策定において主導的役割を担い、存在感を盤石にする – QualiTraxマネジメントシステムそのものの開発費用は単一で済む – QualiTraxの運用も受注でき、顧客の開発改善のコンサルティングが可能になる • QualiTraxコンポーネントのアドオンを開発し販売する手もあるが、これはオープンにした方が筋がよい © NISHI, Yasuharup.25