Tabok 自己流自動化ふりかえり展開版

2/17(日) TABOK関西勉強会
自己流！
テスト自動化ふりかえり

みずのり＠WARAI
2/17 TABOK関西勉強会 1

関連コミュニティ

■ソフトウェアテスト系
JaSST関西実行委員
WARAI（関西ソフトウェアテスト勉強会）運営
出没：TABOK関西（運営？）/東京、
WACATE、各地区のJaSST
■ETロボコン
ETロボコン関西地区実行委員
■その他
出没：アジャイルとかTOCfEとか適当に興味のある勉強会


持ちネタ（発表、ワークショップ）
■ロジカルシンキング
エンジニアのためのロジカルシンキング（考え方編、伝え方編）
■キャリア論＆スキルを考えるネタ
“自分”を研究する～自己のスキル・動機を見つめなおす
■仕事術、タスク管理
タスクを分解して、タスク設計を考えるお話
■ソフトウェアテスト
テスト設計コンテスト＠2012（2位）、＠2013、テストの段階的詳細化手法（JaSST’13東京論文）
■ETロボコンモデル分析ネタ
■プロセス
PFD（プロセスフローダイアグラム）ワークショップ
■プロジェクト
キックオフ（目標を考える）ワークショップ、ふりかえりワークショップ
■ソフトウェアテスト
テスト技法、テストネタのワークショップ＠WARAI


持ちネタ（デザイン）

■Ultimate Agile Stories

■いろいろアイコン


あれ？

エンジニアですか？⇒ orz…

たまにはエンジニアっぽいネタを紹介したいです。


コンテンツ

以下の流れで説明。
・業務での自動化展開のふりかえり。
・今まで実施してきた考え方のふりかえり。


システム自動化の一例を紹介

デモなし。

「システムテスト」のお話。

単体テストな話は全くありません。
コンポーネント統合システム
テストテストテスト


業務紹介

Systems of System
組込みインフラっぽいもの。
個産なのに24時間365日
海外からの買い物装置、
A社製品、B社製品の組合せ。

装置② 装置②
他社製アプリ②-1 アプリ②-2

プロセスB 装置②
アプリ②-3
装置① プロセスA プロセスC


業務紹介
システムの妥当性確認試験が必要。
複数設定対応。200設定とか。
1設定で運用をするのに複数の
制御が必要。1制御が3分くらい。
合計で1設定10分程度。
⇒マニュアルで付きっきり？
© あずまきよひこ

装置② 装置②

アプリ②-3


業務紹介
システムの妥当性確認試験が必要。
複数設定対応。200設定とか。
1設定で運用をするのに複数の
制御が必要。1制御が3分くらい。
合計で1設定10分程度。
⇒マニュアルで付きっきり？
やってられないので自動化！
装置② 装置②

アプリ②-3


変わり行く状況
Windows自動化ソフト「UWSC」を軸に自動化環境を構築。
http://www.uwsc.info/ ※キャプチャ＆リプレイツールです。

※本日はツール自体の「使い方」は省略します。

■フェーズ①
人が入力していたトリガを決め打ち。
同じ処理を繰返し再生し続ける。

システム


■フェーズ①

UWSC システム


■フェーズ①
■フェーズ②
CSVから設定パターンを変更可能に。 UWSC システム

設定
ファイル
CSV


■フェーズ①
■フェーズ②
■フェーズ③
個別の制御の選択が出来るように。
設定
ファイル
CSV
A B C
バイパス
C’
選択


■フェーズ①
人が入力していたトリガを決め打ち。 PICNIC

■フェーズ② アプリ
■フェーズ③
■フェーズ④ 設定
ファイル
周りの環境も出来る限り制御可能に。 CSV
A B C
バイパス
C’
選択


■フェーズ①

CSVから設定パターンを変更可能に。 UWSC システム自動
判定
■フェーズ③
ファイル
A B C
バイパス
■フェーズ⑤
C’
結果判定がメンドイので、自動判定機能追加。選択


変わり行く状況自動判定表示方法のイメージ
2013/2/17 10:00:00 Config1 Test OK
2013/2/17 10:12:00 Config2 Test OK
2013/2/17 10:25:00 Config3 7Error NG
2013/2/17 10:35:00 Config4 Test OK
■フェーズ①

判定
■フェーズ③
ファイル
A B C
バイパス
■フェーズ⑤
C’


変わり行く状況自動判定表示方法のイメージ
2013/2/17 10:00:00 Config1 Test OK
2013/2/17 10:12:00 Config2 Test OK
2013/2/17 10:25:00 Config3 7Error NG
2013/2/17 10:35:00 Config4 Test OK
■フェーズ①： Level1（Linear）

■フェーズ②： Level2（Data Driven）アプリ
判定
■フェーズ③： Level2（Functional Decomposition）
ファイル
A B C
バイパス
■フェーズ⑤
C’

TABOK：4章でいうとLevel2まで＋使いやすさ優先？

成果的なもの

リリース後に発生していた不具合が1/5くらいに。
※同時に勉強していたテストプロセス系の効果も有ります。

海外購入品へのイチャモンに自動試験環境を持っていったら従った。
⇒そのメーカがいつの間にかウチのツールで試験しやがっていた。

再現しない不具合を指摘されてから、（連続可能な）再現環境構築、
すぐに再現するか？という判断、対応までが圧倒的に早くなった。
時間は感覚的ですが、リードタイム1/5くらいかな？


最近は…？
システム試験に自動化環境前提のテストケースが入るようになっている。

＜効果＞
・信頼性の確認＋安心感
・テスタビリティ、客先出荷後の保守性向上
・システムを考える、システムとして動かす

＜その他＞
本当に 10万回
・（再現しない）不具合再現に活用。大丈夫？試験したよ
・改修後の妥当性を示す。


考え方のふりかえりと整理

自動化環境つくりの考え方を整理してみます。
※多分、（無意識に）出来ている人が多いはず。

今回は自己流で「組込みシステム」における
自動化環境の作り方の考え方を
中心に紹介してみます。


自動化といえば？
いったん、「自動化といえば？」というお題で考えてみました。
やたら発散する感じです。
Sikuliサイコー（≧▽≦）
xUnit使わないなんてありえないよね
シミュレータとか無いと試験できないよ！
上司が全部自動化とか言うんですよ

費用対効果を考えないと！
今から全部自動化なんて出来ないっすよ

自動化って単体テストのことじゃないの？
データ作成も自動化だぜ！

組込みじゃ現実的じゃなさそう
ユーザビリティとかも自動に見るのかな…


自動化といえば？
いったん、「自動化といえば？」というお題で考えてみました。
やたら発散する感じです。
ツール Sikuliサイコー（≧▽≦）
xUnit使わないなんてありえないよね
シミュレータとか無いと試験できないよ！
上司が全部自動化とか言うんですよ ROI
費用対効果を考えないと！

構築アプローチ
今から全部自動化なんて出来ないっすよ

自動化って単体テストのことじゃないの？

プロセス
データ作成も自動化だぜ！

組込みじゃ現実的じゃなさそう
ユーザビリティとかも自動に見るのかな…
テストの考え方

自動化といえば？（アプローチ）

自動化を構築する際のアプローチを紹介。

トップダウンアプローチ：
全体のフェーズを考えて、必要な環境を見込む
「何を見るか？」という大まかな確認する性質（品質特性等）を見込む
必要な（ツール及び開発対象アプリ）要求を特定し、開発計画へ展開

ボトムアップアプローチ：
マニュアル作業を自動化に落とし込む（いろいろ工夫しつつ）
最も使う手順、運用パターンから考える。
繰返し出来るようになった上で、パターン変更可能、使用性を高める
個別に作成した自動化を統合的に動かす


自動化といえば？（プロセス）

自動化？テスト？に関わるプロセスを紹介
※「テストツール丸わかりガイド」より http://aster.or.jp/business/testtool_wg/pdf/Testtool_beginningGuide_Version1.0.0.pdf

テスト分析：テスト対象を理解してテストすべきことを明確にする
要件管理ツール
テスト設計：テスト条件を確認する具体的なパターンを見込む
原因結果グラフツール、組合せテスト支援ツール（直交表、オールペア）、
状態遷移テストツール、動的解析ツール、カバレッジ計測ツール、その他
テスト実装：テストを実行できるための一連の作業
シミュレータ（スタブツール）、ラボイメージ、データジェネレータ、ケース管理ツール
テスト実行：通常「テスト」と呼ばれる作業
ユニットテストツール、キャプチャ/リプレイツール、性能テストツール
セキュリティテストツール、テスト自動実行支援ツール
その他：
コード解析、テストウェア管理、テスト結果管理、インシデント管理

自動化といえば？（プロセス）

自動化？テスト？に関わるプロセスを紹介
※「テストツール丸わかりガイド」より http://aster.or.jp/business/testtool_wg/pdf/Testtool_beginningGuide_Version1.0.0.pdf

テスト分析：テスト対象を理解してテストすべきことを明確にする
まず「自動化といえば…」で
要件管理ツール
考えるべき範囲は
テスト設計：テスト条件を確認する具体的なパターンを見込む
この辺になるかと思います。
原因結果グラフツール、組合せテスト支援ツール（直交表、オールペア）、
状態遷移テストツール、動的解析ツール、カバレッジ計測ツール、その他
テスト実装：テストを実行できるための一連の作業
シミュレータ（スタブツール）、ラボイメージ、データジェネレータ、ケース管理ツール
テスト実行：通常「テスト」と呼ばれる作業
ユニットテストツール、キャプチャ/リプレイツール、性能テストツール
セキュリティテストツール、テスト自動実行支援ツール
その他：
コード解析、テストウェア管理、テスト結果管理、インシデント管理

自動化といえば？（テストの考え）
テストの考え方。いろいろ有りますが、今回紹介するのは
「何を見る？」と「どうやって見る？」の考え方。

何を見る？

どうやって見る？


何を見る？
ぶっちゃけ、皆さんなら勘でOK。
…ですが、一応テストな人の考え方で紹介してみます。
ここは「自動化を対象」した考えではなく、
「テストを対象」した考えで紹介です。ここからは
ポットの
具体例を多数

© SESSAME
http://www.sessame.jp/


何を見る？（テスト対象）
例えば、「テスト対象」≒バグをもつもの、テストで保証する対象。
ターゲットを考えるにはどうしましょう？とあるシステムでは？

装置② 装置②

アプリ②-3



装置② 装置②

アプリ②-3

デ機振
シナリオー能舞
ユースミスユースタい
ケースケースコンポーネント、
クラス
ソースコード、
メソッド



装置② 装置②

アプリ②-3

デ機振
シナリオー能舞
ユースミスユース広さタ
コンポーネント、
い
ケースケース
クラス
「広さ」と「深さ」双方がソースコード、
あるというイメージが深さメソッド
分かりやすいかも。


「ポット」を考えてみると…？
プロダクト
操作
ユーザ

危険性

HW領域
SW
領域
サービス
お湯、ミルク等を介しての
ユーザへの価値提供


「ポット」を考えてみると…？対象を表現する方法は…？
プロダクト
操作
ユーザ SW
ユースケースふ

HW I/F
機る
危険性

HW領域
能ま
い
ミスユースケース/FTA等
設計/クラス・
コンポーネント
サービス
お湯、ミルク等を介してのソースコード
ユーザへの価値提供関数単位

シナリオ


何を見る？（性質）
あとは、「品質特性」やら「テストタイプ（特定のテストの集合体）」…
対象に対して、「何の性質を見る？」を考えるためのモノです。
※Myライブラリからの抜粋適切さ
時間挙動
効率性正確性
資源の活用度機能性
相互運用性

分析のしやすさ
セキュリティ

変更のしやすさ
保守性成熟度
安定性
品質特性（ISO9126）信頼性フォールトレランス
テストのしやすさ
復元力

順応性
理解のしやすさ
インストールのしやすさ
移植性学習のしやすさ
共存力使用性
操作のしやすさ
置換製
魅力


何を見る？（性質）
あとは、「品質特性」やら「テストタイプ（特定のテストの集合体）」…
対象に対して、「何の性質を見る？」を考えるためのモノです。
※Myライブラリからの抜粋引き出しを持っていると便利です。
Facility Testing 機能テスト

互換性/コンパチテスト
Compatibility/conversion Testing
Volume Testing ボリュームテスト

インストーラビリティテスト
Installability Testing
ストレステスト
Stress Testing
信頼性テスト Reliability Testing
ユーザビリティテスト
Usability Testing
リカバリーテスト Recovery Testing
Myersの
Mayersの
システムテストカテゴリ
システムテストカテゴリセキュリティテスト
Security Testing
サービスアビリティテスト
Serviceability Testing
性能/パフォーマンステスト
Performance Testing
ドキュメンテーションテスト Documentation Testing
ストレージテスト
Storage Testing
手続きテスト Procedure Testing
設定/コンフィグテスト
Configuration Testing


何を見る？（対象×性質）
それぞれの対象に対して、何を見るかを考える。
これはテストの狙いどころですが、自動化を考える時も同じでしょう。
データのサイズ（1ファイル、
装置間I/F 機能性。
最大蓄積）、ログローテート
装置間データのボリューム。
瞬間的、平均的な負荷。装置② 装置②

アプリ②-3

デ機振状態遷移
シナリオ
処理レスポンス、ー能舞競合確認
ユーザビリティ確認タい
ユースミスユース機能テスト
手順ミス時の復旧コンポーネント、
ケースケース
繰り返しの信頼性パラメータ組合せクラス
による論理確認ソースコード、
メソッド
※続きは「WARAI」で＾＾単体テスト
境界値
2/17 TABOK関西勉強会パスカバレッジ 37


※ツールとは関連しますが、ツール直接の話はありません。
システムテストの方法を考えてみるというものです。
某SNSK流の自動化の考え方は、以下という話です。
Drive（駆動）、Judge（判断）、Report（報告）

対象

対象




ツール
（Drive）
対象対象

対象




ツール
（Drive）
対象対象

ツール
（Judge）
対象対象




orz…
ツール
（Drive）
対象対象

ツール
Mail （Judge）
ツール
対象（Report）
対象



対象を計算機 or
シミュレータ上から
某SNSK流の自動化の考え方は、以下という話です。直接操作
Drive（駆動）、Judge（判断）、Report（報告）操作に対して
応答、反応がある
orz…
ツール
（Drive）
対象対象

ツール
Mail （Judge）
ツール
対象（Report）
対象



組込みではどうしましょ？



組込みではどうしましょ？

おいくら
万円？



組込みではどうしましょ？ ⇒ 適度な仕組みが必要

ツール
（Drive）

話題沸騰モニタ

ツール 85 ℃
（Judge）沸騰中
ヒータ ON

【センサ状態】温度、水位
【制御状態】ヒータ、ポンプ、温度制御
2/17 TABOK関西勉強会【その他】CPU、メモリ、タスク切替 45


Drive、Control、Monitor、Judge、Reportという感じかなと。
Control 試験のための
機能、テストが必要
ツール ⇒ROIを考えよう！
（Drive）

Monitor
話題沸騰モニタ

ツール 85 ℃
（Judge）沸騰中
ヒータ ON

【センサ状態】温度、水位
【制御状態】ヒータ、ポンプ、温度制御
2/17 TABOK関西勉強会【その他】CPU、メモリ、タスク切替 46

ばらして考えてみよう
Drive どうやってシステムを駆動させるべきか？
結構ツールがあるので、省略（UWSC、WSH、bat、sh、Sikuli…）
Control シミュレータの開発準備や、特別なI/Fを別途用意する必要があるか？
別途H/Wや環境の制御まで考える必要があるか？
Monitor 対象に対して状態通知の仕組みを用意すべきか？外部の環境は？
制御の応答、イベント、ポーリング、画面での判定…
パフォーマンステストなら、時間を測定する仕組みも必要。
Judge 作りこみ、判断が正しいかの妥当性が大事、何を見る？どうやって見る？
Monitorとの連携で、必要な確認項目を抽出して確実に検出
Report 繰返し確認が必要な部分は簡単にしておく
※個産なので？、個人的にはそれほど重要視してません…

ツールツール
Control
（Drive）（Control）
Monitor
ツールツール
（Judge）（Monitor）テスト対象

テストを詳細設計するフェーズ、
Report 実施のフェーズでは間に合わない。
繰返し確認が必要な部分は簡単にしておく
開発段階、初期段階から
仕組みを考える必要がある。
ツールツール
Control
（Drive）（Control）
Monitor
ツールツール

Report 繰返し確認が必要な部分は簡単にしておく
テスト詳細設計～実施の段階で
ツールツール
細かい保守性を含めての
（Drive）（Control）改善を行うことが可能。
Control

ツールツール
現場での施行錯誤が生きる場所
Monitor


仕組みづくり
何を対象に、何を見るか？を考えながら仕組みづくり。

装置② 装置②

アプリ②-3


仕組みづくり
実現のために必要な仕組みを考える。※スケジュール、ROIが絡む

装置② 装置②
シミュレータアプリ②-1 アプリ②-2

アプリ②-3

デ機振
ー能舞
タい
シミュレータ
Controlツール

Controlツール

Driveツールシナリオベース
制御実施
2/17 TABOK関西勉強会
Drive用PC 51

仕組みづくり
システム的な仕組みを考えながら構築する必要があるなど。

装置② 装置②
シミュレータアプリ②-1 アプリ②-2

Monitor機能
アプリ②-3

デ機振 Monitor機能
ー能舞
タい
シミュレータ
データ収集 Monitor
Judge判定データ
Controlツール

Driveツールシナリオベース
制御実施
2/17 TABOK関西勉強会
Drive用PC 52

仕組みづくり：マネジメント
実施内容 2012年11月 2012年12月 2013年1月 2013年2月
妥当性確認、検証
　操作パネル妥当性妥当性検証
　温度制御、ヒータ温度制御系販売開始：
　サーミスタ検証準備検証 2/15(金)
統合/システムテスト
　スモークテストｽﾓｰｸ
　統合テスト①、② 統合テスト①、②
テスト計画、
　システムテスト① 準備システムテスト①
分析
　システムテスト② システムテスト②
ヒータユニットプロトタイプ完成操作パネルの完成！
新規サーミスタ評価版購入

①操作パネル ②温度制御検証 ③操作パネル ④操作パネル完成後
妥当性検証ﾌﾟﾛﾄﾀｲﾌﾟ開発したHWと完成前テスト量産/出荷前確認テスト
シミュレータを用意して、温度制御試験用SWを用意、操作パネルI/F以外の論理確認、（システムテスト）
操作感、ユーザビリティと温度制御の妥当性を確認試験を実施。シミュレータを活用操作パネルを含めた全体確認
状態遷移の妥当性を確認して試験を実施。
温度制御（出荷前確認テスト）
試験用S/W シミュレータを活用して自動化環境
を構築して効率化を狙う
ヒータサーミ
ﾌﾟﾛﾄﾀｲﾌﾟスタ自動
制御
操作パネルシミュレータ温度制御検証環境シミュレータを用いたテスト環境
ﾂｰﾙ


スペシャルサンクス

自動化構築の枠組み
(Drive/Judge/Report)は
@SNSKの検討がベースです。
Special Thanks!


Tabok 自己流自動化ふりかえり展開版

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (10)

Semelhante a Tabok 自己流自動化ふりかえり展開版

Semelhante a Tabok 自己流自動化ふりかえり展開版 (20)

Mais de Noriyuki Mizuno

Mais de Noriyuki Mizuno (14)