JaSST 16 Tokyo テクノロジーセッション AUTOSAR Acceptance Test の自動化の取り組み 株式会社ベリサーブ オートモーティブ検証サービス開発部 須原秀敏 1
自己紹介 項目 所属 内容 株式会社ベリサーブ 名前須原秀敏 ( すはらひでとし ) 経歴 車載電子機器 ( 以後 ECU) のシステムテストを 6 年 活動 SNS WACATE STAC JaSST SQiP TEF 東海 etc... に参加 講演経験はなし Twitter:@suhahide http://www.automotivespice.com/fileadmin/softwaredownload/automotive_spice_pam_30.pdf より 2
アジェンダ 1. AUTOSARとは? 2. AUTOSAR Acceptance 3. ATの自動化 3
アジェンダ 1. AUTOSARとは? 2. AUTOSAR Acceptance 3. ATの自動化 4
AUTOSAR とは 項目正式名称略称いつ誰が対象どの部分なぜどうする 説明 AUTomotive Open System ARchitecture AUTOSAR 2003 年発足 現在 Release4.2.2 OEMやサプライヤ ツールベンダなどのグローバルパートナーシップ ECU ソフトウエアアーキテクチャ ECUの開発コストを下げ 品質を確保非競争領域は共通化 競争領域は再利用と再配置 5
AUTOSAR のソフトウエアアーキテクチャ (1) Layer 略称 説明 Application Layer APP ECUの機能を実現 一つ以上のSWCから構成される Runtime Environment RTE Application Layerへの実行環境提供 通信 IFの提供 Basic Software BSW どんなECUにも共通である土台部分の基本ソフトウエア http://www.autosar.org/fileadmin/files/releases/4-2/softwarearchitecture/general/auxiliary/autosar_exp_layeredsoftwarearchitecture.pdf より 6
AUTOSAR のソフトウエアアーキテクチャ (2) BSW の構成モジュール http://www.autosar.org/fileadmin/files/releases/4-2/softwarearchitecture/general/auxiliary/autosar_exp_layeredsoftwarearchitecture.pdf より 7
AUTOSAR のメリット (1) No メリット理由 1 車両の特性を越えて Application Layer の再利用ができる RTE により API 抽象化がなされる また 外部からの設定により特性が吸収できる 車両 A 車両 B 8
AUTOSAR のメリット (2) No メリット理由 2 安定した品質のプラットフォームを使用できる BSW にはすべての ECU に共通のモジュールが含まれている AUTOSAR でない AUTOSAR マイコン部分除きゼロから開発 Application Layer+ 設定での開発 9
AUTOSAR 対応の製品のテストのニーズ AUTOSAR のコンセプト上 AUTOSAR 対応 BSW+ RTE を外から持ってきて 製品に組み込むことが多い この場合 持ってきた製品の受け入れテストを実施したいというニーズが発生する APP 外部から 受け入れテスト 10
ちなみに :AUTOSAR と JaSST いつ どこで題名概要 JaSST 10 Tokai JaSST 12 Tokyo JaSST 16 Tokyo AUTOSAR を適用した車両システム開発環境の構築 AUTOSAR_OS に対するテストケースおよびテストプログラムの自動生成 AUTOSAR Acceptance Test の自動化の取り組み 開発プロセスとツールチェーンの整備 PictMaster による単体テスト設計 実装の自動化 システムテスト実行の自動化 JaSST 16 Tokyo JaSST 10 Tokai JaSST 12 Tokyo 11
アジェンダ 1. AUTOSARとは? 2. AUTOSAR Acceptance 3. ATの自動化 12
AUTOSAR の Acceptance Test とは? 項目正式名称略称いつ誰が対象どの部分なぜどうする 説明 AUTOSAR Acceptance Test AT 2014 年リリース 現在 Release1.1 AUTOSAR AUTOSARの提供する 機能 受け入れテストテスト実施の苦労とコストを削減共通の受け入れテストを定義 13
AT の目的と制限 分類内容説明 目的共通化共通のテスト開発とメンテナンス 個別にテストを作る必要がない 方向付け 結果の流用 メソドロジー 拡張性を提供 カバレッジ外のテストを作る際に方向性が決まる テスト実施結果の流用 サプライヤと OEM 両方でテスト実施する必要がない 制限カバレッジ限定された機能のみを含めている 対応要否 製品固有 OPTIONAL プロジェクト固有の設定についてはテストしない http://www.autosar.org/fileadmin/files/releases/tc-1-1/autosar_exp_acceptancetestsoverview.pdf より 14
AT の使い方の例 シチュエーション例 受け入れテスト実施 回帰テスト 使い方 AT で定義されているテストケースに加え AT 内に存在する機能内での深掘り AT 内に存在しない機能への横展開 AT で定義されているテストケース +α を毎回リリース時 毎回ビルド時に実施する AT の範囲 存在しない機能への横展開 存在する機能内での深掘り 機能 1 機能 2 機能 3 機能 4 機能 5 機能 6 15
AT のテストアーキテクチャ 番号 1 2 説明 Upper Tester と呼ばれ テスト対象の API 部分の IF Lower Tester と呼ばれ テスト対象のバス部分の IF CAN LIN DIO ADC などが含まれる Test System Test Bench (Lower Tester) Test Coordination Process SUT SWC (Upper Tester) 1 Runtime Environment(RTE) Basic Software(BSW) 2 BUS Microcontroller 16
AT のテストケースのサンプル テスト手順が記載されている 本事例では API コールのみ 期待結果が記載されている 本事例では BUS 出力の確認のみ http://www.autosar.org/fileadmin/files/releases/tc-1-1/specifications_auxiliary/autosar_ats_communicationcan.pdf より 17
AT の特性まとめ No 特性 1 基本的な機能確認のテスト 2 手順が明確に定義されている 3 再実施されやすい 18
アジェンダ 1. AUTOSARとは? 2. AUTOSAR Acceptance 3. ATの自動化 19
一般的な自動テストのメリットと今回のゴール 対象品質コストデリバリ 説明テスト実行品質の向上 手動ではできないデータ量やタイミングなど再実施のコスト削減 デグレード削減によるコスト削減開発ライフサイクルの加速 コスト デリバリ 品質 今回はコスト削減をゴールに自動化の導入を考えた 20
AT と自動テストの相性 ゴール : コスト削減したい そのためには 同じテストを複数回実施する AT で考えると AT は共通部分に対するテストであるため 複数の ECU に対してひとつのテストで実施できる ゆえに 共通 AT AT の特性と自動テストの目的が一致 APP1 APP2 APP3 21
実現系 :AT の自動テストの実装 項目 実装戦略 Test Bench 側ツール 対象 AT 説明 後述 National Instruments 社の VeriStand+LabVIEW Release1.1 全件 (200 件強 ) http://www.autosar.org/fileadmin/files/releases/tc-1-1/autosar_exp_acceptancetestsoverview.pdf より 22
一般論 : 自動テストアーキテクチャ 名称 説明 名称 説明 Schedule テスト管理 Control テスト対象制御 Setup/ Teardown Drive 前後処理テスト手順進行 Monitor Judge テスト対象からの入力監視期待値との比較 Schedule Testware Setup/ Teardown Drive Control Monitor Judge Report IF 1 IF 2 IF 3 IF N テスト対象 http://www.slideshare.net/no riyukimizuno/et-west を参考 23
一般論 :ISTQB の gtaa との比較 Test ware Rep ort Schedule Setup/ Tear down Drive Contr ol Moni tor Judge expert_level_syllabus_-_test_automation_-_engineering.pdf より 24
一般論 :AT のテストアーキテクチャ ( 再掲 ) 番号 1 2 説明 Upper Tester と呼ばれ テスト対象の API 部分の IF Lower Tester と呼ばれ テスト対象のバス部分の IF CAN LIN DIO ADC などが含まれる Test System Test Bench (Lower Tester) Test Coordination Process SUT SWC (Upper Tester) 1 Runtime Environment(RTE) Basic Software(BSW) 2 Bus Microcontroller 25
実現案 :AT の自動テストアーキテクチャの評価観点 項目 スクリプト数 TCP の複雑さ 説明 TestBench 側 SWC 側合わせてどのぐらいのテストスクリプトを作成する必要があるか ( 今回は 100 件のテストケースを想定 ) TCP にどの程度の量の情報を流す必要があるか 機能性 TestBench 側が十分に Schedule を行うことができるための情報を得られるか また 実施したいテストが実現できるか ( タイミングなどの観点 ) 26
実現案 :IF1(1) 項目 説明 コンセプト 全て SWC 側に配置する 内容 最初のトリガのみ Test Bench 側から与え その後のテスト手順は全て SWC 側で実施する Test Bench 側は Judge の判定結果のみ受け取り Report する Test Bench Schedule Drive SWC Drive スクリプト数 200 件 Control TCP の複雑さ 単純 Monitor 機能性 不足 ( ロギングに問題がある ) Judge 27
実現案 :IF1(2) 項目 説明 コンセプト 内容 簡易判定のみ Test Bench に持たせる 制御としてはトリガのみ Test Bench 側から与え その後のテスト手順は SWC 側で実施する Test Bench 側は Judge を一部実施する + Judge の判定結果を受け取り Report する Test Bench Schedule Drive SWC Control スクリプト数 200 件 Monitor TCP の複雑さ 単純 Judge Judge 機能性 最低限 28
実現案 :IF1(3) 項目 説明 コンセプト 内容 スクリプト数 TCP の複雑さ 機能性 全結果判定を Test Bench に持たせる 制御としてはトリガのみ Test Bench 側から与え その後のテスト手順は SWC 側で実施する Test Bench 側は Judge をすべて実施し Report する 200 件 少し複雑 十分 Test Bench Schedule Drive Monitor Judge SWC Control Monitor 29
実現案 :IF1(4) 項目 説明 コンセプト 内容 制御含めて全て Test Bench に持たせる SWC 側は土管として存在し 全ての制御 判定を Test Bench 側が持つ Test Bench Schedule SWC スクリプト数 100 件 +1 件 Drive TCP の複雑さ 複雑 Control 機能性 完全 Monitor Judge 30
実現案 :IF1 実現案まとめ 番号 コンセプト スクリプト数 TCPの 複雑さ 機能性 (1) 全てSWC 3 点数 (2) 簡易判定を Test Bench に (3) 全判定を Test Bench に (4) 全て Test Bench 4 3 35 一旦無視 31
参考 :IF2 項目 説明 コンセプト Test Bench 側に持たせざるを得ない Test Bench SWC Schedule Drive Control Monitor Judge 32
実現系 : 自動テスト実装の戦略 ( 自動テストアーキテクチャ以外 ) システムテスト自動化標準ガイドを参考に 戦略を一般的に評価した 項目章番号戦略 スクリプティングの技法 比較タイミング 比較の複雑さ テストの感度 前後処理の自動化 3.2 構造化スクリプト 共有スクリプト 件数が多くないのでキーワード駆動はしていない また パラメータ振りなどもないためデータ駆動もしていない 今後検討 4.3/4.4 動的比較 リアルタイムに比較ができるシステムを採用したため 実施後比較が必要になったら検討するという位置付け 4.5/4.6 複雑な比較 完全一致ではなく 比較すべきデータを抽出し 比較を行っているため 4.7 センシティブな比較 AT の規定が細かいため センシティブになっている 目的がスモークテストなどになれば 判定を減らしてロバストにすることも検討可 6 テスト実行そのものの前提条件作成などは自動化済み 33
アジェンダ 1. AUTOSARとは? 2. AUTOSAR Acceptance 3. ATの自動化 34
考察 項目 AT の自動化そのもの 自動テストアーキテクチャ 実装戦略 ( 自動テストアーキテクチャ除く ) 考察内容 複数回実施する という意味ではどんな実装方法でもメリットが出そう ROI の計測は必要 現状規定の AT のみ ということであれば 2. 簡易判定を Test Bench に の戦略で問題なし ただし 今回無視したスクリプト数を外すと 4. 全て Test Bench という戦略が選ばれる可能性がある ( 次ページに再掲 ) 汎用性を高めなくてよかったため キーワード駆動を使用しない また センシティブな比較を採用 とした ターゲットが変わるとここの戦略も変化する 35
AT のアーキテクチャまとめ ( 再掲 ) 番号 コンセプト スクリプト数 TCPの 複雑さ 機能性 1 全て SWC 3 点数 2 簡易判定を Test Bench に 3 全判定を Test Bench に 4 全て Test Bench 4 3 5 36
今後の課題 項目 AT の拡張 AT 外の自動テスト ECU としての自動テスト テスト設計 実装の自動化 課題内容 AT のコンセプトに従い 機能深掘り 機能横展開が実施される際に 保守性が重要 今回は AT として実装したが その他のテストレベルにも使用可能 その場合 アーキテクチャ 戦略の再考が必要 今回は IF として SWC+Test Bench として実装したが Test Bench のみ切り出すことで ECU としての自動テストにも同じアーキテクチャが使用できる想定 テストケースの生成 ( テスト設計 ) や テストウエアの生成 ( テスト実装 ) の自動化を検討 37
ご清聴ありがとうございました 38