stac2014 石川

62
皮を剥く

Upload: tatsuya-ishikawa

Post on 21-Jul-2015

6.860 views

Category:

Software


0 download

TRANSCRIPT

Page 1: Stac2014 石川

皮を剥く

Page 2: Stac2014 石川

石川達也

株式会社Codeer代表取締役

Microsoft MVP for C#

Windowsアプリテスト自動化歴9年

Windowsアプリ操作用ライブラリFriendlyの開発者

自己紹介

Page 3: Stac2014 石川

Windowsアプリ用の皮むき器です。

*詳細は後で

Friendly紹介

http://www.codeer.co.jp/

Friendly 自動化 で検索!

Page 4: Stac2014 石川

Friendly紹介

無料です!

Page 5: Stac2014 石川

Friendly紹介

じわじわ来てます。一部上場企業様でも続々と採用中

Page 6: Stac2014 石川

http://posaune.hatenablog.com/entry/2014/11/16/173446

亀岡的プログラマ日記

Friendly紹介

アメリカでも大好評でした!

Page 7: Stac2014 石川

1.なぜ剥くのか?

2.剥き方

3.新たな皮をかぶせる

アジェンダ

Page 8: Stac2014 石川

1.なぜ剥くのか?

1.Why do you peel it?

Page 9: Stac2014 石川

もっと自由に自動化したい!

1.Why do you peel it?

Page 10: Stac2014 石川

これプログラムから操作しようと思うでしょ?

1.Why do you peel it?

アプリケーションとして起動してる画面ね

Page 11: Stac2014 石川

いやいや、どうやんの?

このコントロールは、UIオートメーション対応してんのね。

あれ、こいつ動かん。

キー、マウスエミュレートやるかー。

あかん、タイミング依存。

あれ?このウィンドウどれへん。

モーダルダイアログでかたまったー。

この画面、OSによってデザインかわっとるやんけ!

1.Why do you peel it?

Page 12: Stac2014 石川

むずかしわ!

1.Why do you peel it?

Page 13: Stac2014 石川

システムテスト自動化のボトルネック(あくまで私の経験)

そのほとんどは「操作技術」

1.Why do you peel it?

だって、簡単に操作できたら手動でやってるスクリプトは全部自動化するよね?

Page 14: Stac2014 石川

1.Why do you peel it?

でもおかしな話ですよね?

僕らは、このシステムを作ったはずです。

その時は、APIを駆使して自在にシステムを操ったはずなのですよ。

なんで、こんなことに?

Page 15: Stac2014 石川

それはね、こう見ているからですよ。

アプリケーションとして起動するともはやプログラムとしてみてないんですね。別プロセスのGUIって得体がしれないもの。

1.Why do you peel it?

Page 16: Stac2014 石川

こう見るのだ!

つまり、プログラムとして見るのですね

1.Why do you peel it?

public partial class InputForm : Form{ DataGridView _dataGridView;TextBox _textBoxName;DateTimePicker _dateTime;Button _buttonOK;

void buttonOK_Click(object s, EventArgs e) {

・・・}

}

Page 17: Stac2014 石川

form._textBoxName.Text = “abc”;

form._dateTime.Value = new DateTime(2014, 11, 1);

Form._buttonOK.PerformClick();

いつもと同じAPIが使える!(とすると

public partial class InputForm : Form{ DataGridView _dataGridView;TextBox _textBoxName;DateTimePicker _dateTime;Button _buttonOK;

void buttonOK_Click(object s, EventArgs e) {

・・・}

}

1.Why do you peel it?

思い通りにプログラムできる!Happy!

Page 18: Stac2014 石川

いやいや、何言ってんの?それができたら簡単だけど。

別プロセスですよ?そんなのできるわけないじゃん

Page 19: Stac2014 石川

そこでFriendlyですよ

Is a magical library!

It break through

the walls of processes.デモ!

https://www.youtube.com/watch?v=CK327YuI-bk

https://www.youtube.com/watch?v=xy7BvrrF8oE

Page 20: Stac2014 石川

1.Why do you peel it?

対象ごとに、皮むき器が必要になってくるんですけどね。

WindowsアプリならFriendly!

Page 21: Stac2014 石川

僕自身が自在にテスト自動化コードを書くためにこの考えを採用したのです。

だって、こうしたら普通のプログラムと同じノリで拡張できるし。操作上のボトルネックを外すこともできる!テスタビリティーも好きに向上できるじゃん!

1.Why do you peel it?

Freedom!

なぜ剥くのか?

Page 22: Stac2014 石川

それから・・・システムテスト自動化って、つまりはプロダクトプロセスとテストプロセスを協調動作させるマルチプロセスプログラミング。

安定して動作させるためにはこういった、内部を見る視点が必要不可欠!

1.Why do you peel it?

なぜ剥くのか?

アクロバティック!

Page 23: Stac2014 石川

皮の剥き方

2.How to peel

Page 24: Stac2014 石川

それを、説明にするにあたってこれをみてください。

アプリってね、こうじゃないんですよ。いや、こうなんだけど・・・

2.How to peel

Page 25: Stac2014 石川

こうなんですよー

ものによってはサーバーとか外部機器と通信する

奥行があるのです!2.How to peel

Page 26: Stac2014 石川

この結合したシステムを効率よくテストしたいのです

GUIの詳細をテストが目的ではない。システムをテストすることが目的なのだ!

2.How to peel

Page 27: Stac2014 石川

さあ、剥くぞー!

2.How to peel

Page 28: Stac2014 石川

操作するということを考えて、ちょっと図を変えると

OS層

2.How to peel

Page 29: Stac2014 石川

まずは、一番不安定で、かつ自動化する価値が低いとこ

2.How to peel

OS

Page 30: Stac2014 石川

ここだ!

2.How to peel

OS

Page 31: Stac2014 石川

キーマウスエミュレートは・・・

OS層に送って、長い道のりを経て目的のコードにたどり着く安定したテストを書くのは困難(僕には無理

2.How to peel

あと、低レベルな指令に頼るとメンテナンス性が低いんですよねー

一旦OSに送ってそこからアクティブなプロセスに送信される

OS

Page 32: Stac2014 石川

GUIコントロール(3rdパーティー)

よし、剥がそう

2.How to peel

Page 33: Stac2014 石川

GUIコントロールを操作する分には、多くの場合は手動と同等と考えられる

GUIコントロール(3rdパーティー)

→差異のあるものもある

form._textBoxName.Text = “abc”;

form._dateTime.Value = new DateTime(2014, 11, 1);

form._buttonOK.PerformClick();

大体はこれでOK一般的に望まれるシステムテスト自動化とほぼ同等の効果単にプログラムから扱いやすいだけ

2.How to peel

Page 34: Stac2014 石川

備考:実はUIオートメーションも、この層は剥いでいる

GUIコントロール(3rdパーティー)

で、GUIコントロールとだけ通信できるような仕組みを用意しているまあ、自由度はないけど

2.How to peel

Page 35: Stac2014 石川

Netならフルアクセス、ネイティブはDLL公開関数を操作できる

GUIコントロール(3rdパーティー)

備考:Friendlyなら

2.How to peel

自由すぎる!

Page 36: Stac2014 石川

時には、もっと剥いでみよう!

2.How to peel

Page 37: Stac2014 石川

こんな感じ

2.How to peel

ユーザーロジック

ここまで剥いたら全部知ってるよね

Page 38: Stac2014 石川

結局のところ、テストしたい対象って、ここで十分だったりする

もちろん、システムテストなんでできるだけ上位から叩けた方が良いいけど。テストの本質的な対象でない部分がボトルネックになって自動化を諦めるのってホントにもったいない!

それに、扱いやすいよね!

2.How to peel

バグのほとんどはここにあるでしょ?

あと、データ取得とかで使いますね。

Page 39: Stac2014 石川

//ここの結合は不安が少ないvoid Event(object sender, EventArgs e){

EventCore(PointToClient(Control. MousePosition));}

//これを呼び出すvoid EventCore(Point mousePosClient){//ここから先なら簡単に操作可能//テストとしても問題がない

}

自動化可能に!こういうの苦手・・・

・キー、マウス直接参照・D&D・OS提供のGUI

2.How to peel

例えばこんなとき

Page 40: Stac2014 石川

あ、念のため単体テストとは違いますよ。あくまで、操作開始トリガを変えてるだけです。

テストスクリプト

・・・・

結合したシステムに処理を実行させている

2.How to peel

単体テストは結合前の部品のテストこれはこれで、やらなきゃね。

Page 41: Stac2014 石川

裏ワザ

2.How to peel

Page 42: Stac2014 石川

結合状態で特定のメソッドをテスト

まったく、セオリーに反した手法ですが場合によっては非常に費用対効果高い場合があります。

テストスクリプト

・・・・

レガシーコードで単体テスト不可とかね・・・

2.How to peel

Page 43: Stac2014 石川

例えば、どんなとき?

はいはい、実際にあったんですよー

2.How to peel

Page 44: Stac2014 石川

すっげー深いネストで、それぞれもすごく入り組んでて、static変数ありまくりで、初期化は意味わからんタイミングで、おまじないのように書き込まれている

神関数スタート!static変数の状態によって複雑に処理が変わるよ

実行したら何処かのstatic変数の状態が変わるよ

関数ツリークリスマスバージョン

2.How to peel

Page 45: Stac2014 石川

既存の動きは全く変えずに機能追加してください。あ、既存に不具合あっても直しちゃダメよ。

そんなアホな

Page 46: Stac2014 石川

仕様がわからんから、仕様化テストをやりたい。テストケースは総当たり15万ケース結合状態でやんないといけない。

各static変数にはGUIが結びついててそれで、状態を変えたり取得したりできるのだけど

1ケース2秒・・・83時間かかるやんけ

2.How to peel

Page 47: Stac2014 石川

GUIすっ飛ばして、static変数書き換えて関数呼び出し。結果のstatic変数を全ダンプ。

2.How to peel

種類 実行平均時間 合計

手動 30秒 1250時間

自動GUI操作 2秒 83時間

自動内部メソッド 10ミリ秒 24分

24分でできた。これなら機能追加期間に頻繁に実行できるね。ローカルPCでもね。

Page 48: Stac2014 石川

剥く皮の厚さはテスト対象ごとの性質を考えて決定してね。

最初は薄皮一枚剥がすのがおすすめ普通のGUI操作とほぼ同じプログラムから操作しやすいだけ

GUIコントロール

Page 49: Stac2014 石川

注意事項

2.How to peel

三浦さん(仮)は失敗していましたが

皮もおいしくいただきましょう

Page 50: Stac2014 石川

大事なのは、どこを自動化で抑えたかを把握すること。それによって、手動テストを削れる部分とやっぱりやっておくべき部分を明確にする。

A B C FC

自動化できたケース 手動で実施するケース

EDE

自動化

一部手動

手動

2.How to peel

*毎日実行されるこちらに入れることが重要

Page 51: Stac2014 石川

ちなみに、既存の捉え方だと、ボトルネックがあると大きく自動化の範囲がそがれる場合がある。

2.How to peel

もったいない!

A B CF

C

自動化できたケース 手動で実施するケース

ED

E

自動化

一部手動

手動

*毎日実行されるこちらに入れることが重要

Page 52: Stac2014 石川

皮を剥くことによってボトルネックのあるケースでも、いくらかは自動化できる。

でも、その分管理しないといけないけどね

A B C FC

自動化できたケース 手動で実施するケース

EDE

自動化

一部手動

手動

*毎日実行されるこちらに入れることが重要

2.How to peel

Page 53: Stac2014 石川

3.新たな皮をかぶせる

3.Wrap to eat

Page 54: Stac2014 石川

OK!

あんたがHappyなのはわかった。

でも、これってホワイトボックスすぎて内部知っている開発者しか書けなくない?

3.Wrap to eat

Page 55: Stac2014 石川

はい、ごもっとも。それにテストシナリオに内部仕様の言葉使いたくないですよね。

テストシナリオ

・・・・生で触ってはだめ!

3.Wrap to eat

Page 56: Stac2014 石川

そこで、アプリケーションドライバですよ。

←参照

3.Wrap to eat

Page 57: Stac2014 石川

テストシナリオ

・・・・

操作の層とテストシナリオの層を明確に分離

3.Wrap to eat

Page 58: Stac2014 石川

アプリケーションドライバは、プロダクト作るときに開発チームで作っておく

Friendlyとその上位ライブラリ使えば簡単に作れるよ

内部仕様の知識を使って確実に正確に動作させる

こっちは外部仕様の言葉で理解できるインターフェイス

3.Wrap to eat

Page 59: Stac2014 石川

Friendlyの上位ライブラリは一般的なコントロールの皮を剥いた後にかぶせるラッパーそれを使うとローコストにAppDriverを作れます!

Win32,WinForms,WPFそろってます。

3.Add New Interface

http://www.codeer.co.jp/AutoTest/api-reference/codeer-friendly-windows-nativestandardcontrols-dll

http://www.codeer.co.jp/AutoTest/api-reference/ong-friendly-formsstandardcontrols-dll

https://github.com/Roommetro/Friendly.WPFStandardControls/

Page 60: Stac2014 石川

テストシナリオ

・・・・

テストシナリオは、テストチームで書く

簡単な操作手段が(インテリセンスで片が付く)公開されていればテストシナリオはテストチームで書いた方が効率が良い

技術的な部分は隠蔽

3.Wrap to eat

Page 61: Stac2014 石川

これによって、チームが一丸となって自動化に取り組めるわけです。

そして、チーム全体で見てコストダウンに繋げれるのです。

3.Wrap to eat

Page 62: Stac2014 石川

・システムをプログラムとして見る

・操作上のボトルネックを取り除く

・剥いだ皮に注意→薄皮なのか、厚い皮なのか。

・メンバーそれぞれの特性を生かせる設計にしよう

まとめ

ご清聴ありがとうございました!

【Picture】Dawn Huczek