Et west テスト自動化_公開版

組み込み開発でのソフトウェアテスト自動化のライフサイクル

関西検証コレクション（#検これ）

水野昇幸 (@NoriyukiMizuno)

徳隆宏（@tokutaka）

自己紹介

•関西検証コレクションとは •大阪・兵庫・滋賀・京都近辺で、Web/組み込み問わず、V&V全般の情報を集めてフリーディスカッションするコミュニティ。

•2014/8/2最終回

•水野昇幸

•メーカー系のシステム開発・マネジメント

•徳隆宏 •メーカー系組み込みソフトウェア開発リーダー

2014/6/28 Asian Automation Aliance

本日のお持ち帰り事項

■目的・得られる利点の理解

•テスト自動化の目的と周辺知識

■知見としてのパターン

•テスト自動化のパターン

■組み込み特有の課題

•組み込み・Webを比較した Testing Model


テスト自動化の目的と周辺知識

世の中での自動化と、テストの自動化


むかしの自動化の目的

•単位時間あたりの生産量向上

•人の手間の削減

•ヒューマンエラーの削減


最近の自動化の目的は？

•A Guide to the Automation Body of Knowledge (2006年出版）

• 自動化の利益とプロジェクトの正当化

• など


近代の自動化の目的 (Automation Body of Knowledgeより）

•工場の品質向上 •安全性の向上 •製造の柔軟性向上 •運用の信頼性向上 •意思決定の改善 •コンプライアンス •生産性改善 •製造量の増大 •製造コストの削減


メトリクスをもとに改善検討（Automation Body Of Knowledgeより）

•修復・組み換えに必要なコスト・期間

•稼働率

•導入に必要なコストと期間（人件費・調達費・構築）

•動かすために必要な人件費

•問題が日々生じる確率

•生産量・歩留まり


テスト自動化の目的（誤解あり）

•人手では難しいテストの実現

•手動のテストを不要にする

•誤りなきテスト再現

•一度自動化すればメンテフリー


テスト自動化の目的は？

•Test Automation Body Of Knowledge (TABOK) より

•2011年出版


近代のテスト自動化の目的

•人手では難しいテストの実現

•テストの再現性の向上

•テスト対象の信頼性確保を容易に

•メトリクスを収集する

•（うまくできれば） •費用を減らし、効率を上げ、品質を向上する


テスト自動化のパターン

テスト自動化に取り組んでいる人たちの経験をアクセスしやすい形で共有


２つのテスト自動化パターン

•Test Automation Pattern（英語） • By Seretta Gamba, Dorothy Graham, Mark Fewster

• http://testautomationpatterns.wikispaces.com/

•テスト自動化パターンランゲージ（日本語） • By 関西検証コレクション。Creative Commons

• https://github.com/KenColle/AutomationPatternLanguage


Test Automation Pattern

4つのIssueとPattern

Process/Management/Design/Execution

Diagnostic(診断)をすることも可能です。


テスト自動化パターンランゲージ全体


導入のパターン初期実装のパターン普及・もしくは

終焉

グッドパターン

アンチパターン

テスト自動化パターンランゲージ前半


導入のパターン初期実装のパターン

普及・もしくは終焉

グッドパターンアンチパターン

テスト自動化パターンランゲージ後半




験担ぎ：問題編

•文脈 •テストは自動実施されているが「このエラーは問題無い」と運用されている

•問題 •実施が定められているので動かすが、明らかなエラーが検出されたとき以外は結果を誰も確認しない。テスト資産が形骸化・陳腐化している

•フォース •仕様変更などでテスト資産を変化に対して追従させる必要があるが、自動化環境はなぜか無視される

•担当者が異動になった場合に多い(たこつぼ化)



験担ぎ：解決編

•解決 • エラーを現場でもみ消せないようにプロセス整備 • テスト資産を追従させ、エラーが出ない環境を作り、チームの規律を構築する。 {自動化奉行}

•結果 • SUTに適した自動化環境が整備され、変化に追従されている。

• 意味のないテスト自動化環境が無くなっている。



験担ぎ：解決編

•解決 • エラーを現場でもみ消せないようにプロセス整備 • テスト資産を追従させ、エラーが出ない環境を作り、チームの規律を構築する。 {自動化奉行}

•改善コストがあわないなら、そんな自動化やめちまえ。

•結果 • SUTに適した自動化環境が整備され、変化に追従されている。

• 意味のないテスト自動化環境が無くなっている。



テスト自動化パターンランゲージ前半（再掲）


導入のパターン初期実装のパターン



3分クッキング：問題編

•文脈 •自動化は組織にとって殆ど初めての経験であり、知見などはほとんど蓄積されていない。識者も「自分だけ」という状況である。

•問題 •自動化ツールのハードルが高く、どうやって導入すればいいか分からない

•フォース •開発の中で、うまくいくかわからないものに時間を割くことが難しいことが多い

•仮に苦しんで自動化ツールを導入できたとしても、時間あまりインパクトを与えられない。



3分クッキング：問題編

•解決 •事前に自分の環境で、ある程度の構築をしておき、ツールなどを紹介すると同時に一気に運用までもっていけるよう紹介した。

•結果 •まず第一関門を突破。これ以降、[クラウドトーク（もやもやした会話）]に陥らないようコミュニケーションを取りながら、まず[全体像を描き][全体像を描く]、堅実に進めていくことが重要である。



いったんまとめ

•自動化全般およびテスト自動化の知識体系がある • Automation Body of Knowledge

• Test Automation Body of Knowledge

•知識体系だけでなく課題解決のパターンがある • TestAutomationPattern

• テスト自動化パターンランゲージ


そうはいうても・・・組み込みは・・・

•そもそもテスト対象一式（HW・FW etc)がそろわない。

•リアルタイム動作のため観測困難

•正常動作確認には治具導入など必要。

•自動化環境を構築するまでに手間がかかる。手間をかけるよりも次の開発へ。

•テストツールでうまく解決できるかわからない

•テストツールのライセンス費・教育費が、効果に対して見合うかやってみないとわからない


テスト自動化の知見

「テスト自動化」として

これらの知見は役立ちます。

つまりはエンタープライズ、

Web、モバイルなどなど。


組込みでは違うのだよ？

「テスト自動化」として

これらの知見は役立ちます。

つまりはエンタープライズ、

Web、モバイルなどなど。

ただ、「組込みは違う」と

思われる方もいるかも

しれません。


XXとは…

違うの

です！

組込では違うのだよ ->何が違うのでしょう？

•違う部分を考えてみましょう。

※テストレベルでの違い


Requirement Analysis

High Level Design

System Testing

Coding

Integration Testing

Low Level Design

Unit Testing

この辺の領域は別途 Unit Testを中心に学ぼう

この領域で、組込み特有なものがある

組込では違うのだよ ->何が違うのでしょう？

•違う部分を考えてみましょう。

※テストプロセスから違いを考える。


System Testing 分析設計実装実行

テストプロセス

この部分について、違いを考えてみましょう

テスト実施での違い


Webの自動化

デモ紹介します♪

Powered by…



単純に

安くしたい

組込みは難しいのだよ

余分なインタフェース

追加は小型化による

省スペース化や、

コスト起因で制約有

自動化を含め一般的

ツールは組込み向け

特殊用途では

用意されていない

余分なメモリ、CPUの

リソースは無い

もしくはギリギリ

制御実施や結果確認の

インタフェースが

無い場合が多い

事前に用意されない

また、追加も難しい

開発対象（SUT）の

リソース制約が

テスタビリティ向上を

困難にする

組込み開発では

特有のHWや

特別なインタフェース

を作ることが多い

特殊な治具が必要な

場合も多い

そもそもマニュアルでも

テスト実施コストが高い

テストの

仕組みを作る

コストが高い

空いたリソースがないと

テストのための機能を

入れるのが困難 or 不可能

テストの制御実施や

結果確認用ツールが

無い、もしくは高い

HWとSWの

開発部門が別の

場合、システムや

SWのテストが

考慮されづらい

HW開発では途中段階

の変更コストが高い

開発時には「間にあわないモンスター」のような強制力が発生してしまう。

設計段階では

テスタビリティが


量産では1円でも

安くなるよう

部品を減らす

小型化の

要求も

発生する



単純に

安くしたい








特殊用途では













困難にする


特有のHWや




場合も多い



テストの

仕組みを作る

コストが高い







HWとSWの



SWのテストが





設計段階では




安くなるよう

部品を減らす

小型化の

要求も

発生する

一旦こちらに着目して

比較

テスト実装・実行のモデル


テストケースデータ要素

手順期待結果


手順期待結果


手順期待結果


手順期待結果

Control（テスト対象制御）

Behavior（対象のふるまい）

Report（結果収集、報告）

Judge（テスト結果判定）

Monitor（テスト結果監視）

Test ScenarioScheduler

テストデータ

結果及びデータ

テスト成績

テスト成績

テスト成績

テスト成績

異常通知

異常、NG発生時

Drive（テスト駆動）

自動テストシナリオTest Scenario

SUT Layer

Tool Layer

テストケース仕様書※システムテストの時

テスト成績書

Generate（データ生成）

Data Layer




手順期待結果


手順期待結果


手順期待結果


手順期待結果







テストデータ


テスト成績

テスト成績

テスト成績

テスト成績

異常通知




SUT Layer

Tool Layer


テスト成績書


Data Layer

Generate データを用意する

Drive テストケースの手順を動かす

Control SUTへの入力制御を実施する

Behavior SUTのテスト実行時の動作

Monitor SUTの動作の結果を監視もしくは獲得する

Judge 動作結果のOK/NGを判定する

Report 判定NG結果を通知する、成績へ反映する

Webの自動化と

比較します

モデルの説明


Control （テスト対象制御）

Judge （テスト結果判定）

Monitor （テスト結果監視）

Drive （テスト駆動）

Behavior （対象のふるまい）

Generate （データ生成）

Report （結果収集・報告）

OR

Mail

orz…

宿泊日：7/29 宿泊数：1泊人数：1名名前：みうみう

モデルの説明









OR

Mail

HTML上で実現

自動化ツール（Selenium）

上で実現

モデルの説明









OR

Mail

HTML上で実現








SUT Layer

Tool Layer

Control/Monitorが SUTに実装されている

自動化ツール（Selenium）

上で実現

比較してみましょう

画面系自動化であれば、WebのSelenium、WinアプリでのFriendlyなどの自動化ツールが存在します。

「Control」「Monitor」を作る場合もありますが、ツールとの組合せで比較的自動化が実現しやすい状況になっております。


Windowsアプリ自動化ツール：Friendly


•Web系のパターンと比較してみると…


ツール（Drive）

対象

対象

対象

対象

ツール（Judge）

Mail

ツール（Report）

orz… 対象（Control）

対象（Monitor）




ツール？（Drive）

ツール？（Control）

ツール？（Judge）

ツール？（Monitor）

おいくら

万円？




ツール？（Drive）

ツール？（Judge）

ツール？（Control）

ツール？（Monitor）






SUT Layer

Tool Layer

Control/Monitorも Toolで用意する必要がある






SUT Layer

Tool Layer






SUT Layer

Tool Layer



Web系：HTML上で実現されるコトが多い

組込み系：テスト対象に用意されない場合がある


Control/Monitor範囲が目立って違う




手順期待結果


手順期待結果


手順期待結果


手順期待結果







テストデータ


テスト成績

テスト成績

テスト成績

テスト成績

異常通知




SUT Layer

Tool Layer


テスト成績書


Data Layer

特に違うのは「Control」「Monitor」部分

「Control」「Monitor」に引っ張られて、Drive/Judgeのツールもない

それでは何が必要？

•主に「Control/Monitor」についての仕組みをシステムとして考える必要あり。

•これではだめですね…


おいくら

万円？


•主に「Control/Monitor」についての仕組みをシステムとして考える必要あり。

•実現可能な範囲で、テストを実施するための仕組みづくりが必要です。




話題沸騰モニタ

85 ℃

沸騰中

ON ヒータ

•「システムで考える」コトが必要。 ※試験の構成を含めて全体を考えましょう

ツール（Control）

ツール（Monitor）

対象（Control）

対象（Monitor）

Friendly


•仕組みを含めシステムとして考える事で、自動化の恩恵を受けることが出来ます。

•組込み/システムの設計者は十分考える能力があるはずです。※製品開発で考えている

•ただし、実現のコストは組込みでは比較的高価になってしまうので、効果や目的と照らし合わせて考えてみましょう。


実際に構築した例

•制御実施を行うシミュレータ

•データを獲得する仕組みを構築

•その上でDrive/Judgeする仕組みを構築。


制御シミュレータ（Control）

ツール（Monitor）

Win GUI 自動化ツール

Friendly



Windows 環境テスト対象

テスト対象（Control） (Behavior)

テスト実施の課題


単純に

安くしたい








特殊用途では













困難にする


特有のHWや




場合も多い



テストの

仕組みを作る

コストが高い







HWとSWの



SWのテストが





設計段階では




安くなるよう

部品を減らす

小型化の

要求も

発生する

今回はこちらを中心に紹介～

目指す方向性（一例）


単純に

安くしたい








特殊用途では













困難にする


特有のHWや




場合も多い



テストの

仕組みを作る

コストが高い







HWとSWの



SWのテストが




設計段階では




安くなるよう

部品を減らす

小型化の

要求も

発生する

効果のあるテスト自動化、テストの仕組みを構築することが出来ている

テスト実施のための


用意されている

コストに似合ったテストの仕組みを作ることが出来る

設計段階からテスタビリティを考えることが出来る

テスト自動化に向けたツールと特殊部分を分けて効果的に活用できている

テスト自動化の既存ツール・技術を活用する技術がある

テスト自動化の目的や効果が明確である

目的に似合うコスト検討が

出来る

コストとのトレードオフが出来ている

そのための知識がある



組込特有の課題（Control/Monitor）システムとして考える

知見としてのパターン（ツールの知識）

自動化の目的・利点・人手では難しいテスト実現・テストの生産性向上・テスト再現性向上・テスト対象の信頼性確保・メトリクスを収集する（うまくできれば）費用を減らし効率を上げ品質を向上する

ありがとうございました！

参考文献

•検これパターン https://github.com/KenColle/AutomationPatternLanguage

http://www.slideshare.net/Posaune/ss-36420230

•Test Automation Patterns Wiki http://testautomationpatterns.wikispaces.com/

•ABOK A Guide to the Automation Body of Knowledge

•TABOK Test Automation Body Of Knowledge


https://github.com/KenColle/AutomationPatternLanguage








http://testautomationpatterns.wikispaces.com/



Software

Et west テスト自動化_公開版