stac2014 石川
Post on 21-Jul-2015
6.860 Views
Preview:
TRANSCRIPT
皮を剥く
石川達也
株式会社Codeer代表取締役
Microsoft MVP for C#
Windowsアプリテスト自動化歴9年
Windowsアプリ操作用ライブラリFriendlyの開発者
自己紹介
Windowsアプリ用の皮むき器です。
*詳細は後で
Friendly紹介
http://www.codeer.co.jp/
Friendly 自動化 で検索！
Friendly紹介
無料です！
Friendly紹介
じわじわ来てます。一部上場企業様でも続々と採用中
http://posaune.hatenablog.com/entry/2014/11/16/173446
亀岡的プログラマ日記
Friendly紹介
アメリカでも大好評でした！
1.なぜ剥くのか？
2.剥き方
3.新たな皮をかぶせる
アジェンダ
1.なぜ剥くのか？
1.Why do you peel it?
もっと自由に自動化したい！
1.Why do you peel it?
これプログラムから操作しようと思うでしょ？
1.Why do you peel it?
アプリケーションとして起動してる画面ね
いやいや、どうやんの？
このコントロールは、UIオートメーション対応してんのね。
あれ、こいつ動かん。
キー、マウスエミュレートやるかー。
あかん、タイミング依存。
あれ？このウィンドウどれへん。
モーダルダイアログでかたまったー。
この画面、OSによってデザインかわっとるやんけ！
1.Why do you peel it?
むずかしわ！
1.Why do you peel it?
システムテスト自動化のボトルネック（あくまで私の経験）
そのほとんどは「操作技術」
1.Why do you peel it?
だって、簡単に操作できたら手動でやってるスクリプトは全部自動化するよね？
1.Why do you peel it?
でもおかしな話ですよね？
僕らは、このシステムを作ったはずです。
その時は、APIを駆使して自在にシステムを操ったはずなのですよ。
なんで、こんなことに？
それはね、こう見ているからですよ。
アプリケーションとして起動するともはやプログラムとしてみてないんですね。別プロセスのGUIって得体がしれないもの。
1.Why do you peel it?
こう見るのだ！
つまり、プログラムとして見るのですね
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) {
・・・}
}
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!
いやいや、何言ってんの？それができたら簡単だけど。
別プロセスですよ？そんなのできるわけないじゃん
そこで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
1.Why do you peel it?
対象ごとに、皮むき器が必要になってくるんですけどね。
WindowsアプリならFriendly！
僕自身が自在にテスト自動化コードを書くためにこの考えを採用したのです。
だって、こうしたら普通のプログラムと同じノリで拡張できるし。操作上のボトルネックを外すこともできる！テスタビリティーも好きに向上できるじゃん！
1.Why do you peel it?
Freedom！
なぜ剥くのか？
それから・・・システムテスト自動化って、つまりはプロダクトプロセスとテストプロセスを協調動作させるマルチプロセスプログラミング。
安定して動作させるためにはこういった、内部を見る視点が必要不可欠！
1.Why do you peel it?
なぜ剥くのか？
アクロバティック！
皮の剥き方
2.How to peel
それを、説明にするにあたってこれをみてください。
アプリってね、こうじゃないんですよ。いや、こうなんだけど・・・
2.How to peel
こうなんですよー
ものによってはサーバーとか外部機器と通信する
奥行があるのです！2.How to peel
この結合したシステムを効率よくテストしたいのです
GUIの詳細をテストが目的ではない。システムをテストすることが目的なのだ！
2.How to peel
さあ、剥くぞー！
2.How to peel
操作するということを考えて、ちょっと図を変えると
OS層
2.How to peel
まずは、一番不安定で、かつ自動化する価値が低いとこ
2.How to peel
OS
ここだ！
2.How to peel
OS
キーマウスエミュレートは・・・
OS層に送って、長い道のりを経て目的のコードにたどり着く安定したテストを書くのは困難（僕には無理
2.How to peel
あと、低レベルな指令に頼るとメンテナンス性が低いんですよねー
一旦OSに送ってそこからアクティブなプロセスに送信される
OS
GUIコントロール（3rdパーティー）
よし、剥がそう
2.How to peel
GUIコントロールを操作する分には、多くの場合は手動と同等と考えられる
GUIコントロール（3rdパーティー）
→差異のあるものもある
form._textBoxName.Text = “abc”;
form._dateTime.Value = new DateTime(2014, 11, 1);
form._buttonOK.PerformClick();
大体はこれでOK一般的に望まれるシステムテスト自動化とほぼ同等の効果単にプログラムから扱いやすいだけ
2.How to peel
備考:実はUIオートメーションも、この層は剥いでいる
GUIコントロール（3rdパーティー）
で、GUIコントロールとだけ通信できるような仕組みを用意しているまあ、自由度はないけど
2.How to peel
Netならフルアクセス、ネイティブはDLL公開関数を操作できる
GUIコントロール（3rdパーティー）
備考：Friendlyなら
2.How to peel
自由すぎる！
時には、もっと剥いでみよう！
2.How to peel
こんな感じ
2.How to peel
ユーザーロジック
ここまで剥いたら全部知ってるよね
結局のところ、テストしたい対象って、ここで十分だったりする
もちろん、システムテストなんでできるだけ上位から叩けた方が良いいけど。テストの本質的な対象でない部分がボトルネックになって自動化を諦めるのってホントにもったいない！
それに、扱いやすいよね！
2.How to peel
バグのほとんどはここにあるでしょ？
あと、データ取得とかで使いますね。
//ここの結合は不安が少ないvoid Event(object sender, EventArgs e){
EventCore(PointToClient(Control. MousePosition));}
//これを呼び出すvoid EventCore(Point mousePosClient){//ここから先なら簡単に操作可能//テストとしても問題がない
}
自動化可能に！こういうの苦手・・・
・キー、マウス直接参照・D&D・OS提供のGUI
2.How to peel
例えばこんなとき
あ、念のため単体テストとは違いますよ。あくまで、操作開始トリガを変えてるだけです。
テストスクリプト
・・・・
結合したシステムに処理を実行させている
2.How to peel
単体テストは結合前の部品のテストこれはこれで、やらなきゃね。
裏ワザ
2.How to peel
結合状態で特定のメソッドをテスト
まったく、セオリーに反した手法ですが場合によっては非常に費用対効果高い場合があります。
テストスクリプト
・・・・
レガシーコードで単体テスト不可とかね・・・
2.How to peel
例えば、どんなとき？
はいはい、実際にあったんですよー
2.How to peel
すっげー深いネストで、それぞれもすごく入り組んでて、static変数ありまくりで、初期化は意味わからんタイミングで、おまじないのように書き込まれている
神関数スタート！static変数の状態によって複雑に処理が変わるよ
実行したら何処かのstatic変数の状態が変わるよ
関数ツリークリスマスバージョン
2.How to peel
既存の動きは全く変えずに機能追加してください。あ、既存に不具合あっても直しちゃダメよ。
そんなアホな
仕様がわからんから、仕様化テストをやりたい。テストケースは総当たり15万ケース結合状態でやんないといけない。
各static変数にはGUIが結びついててそれで、状態を変えたり取得したりできるのだけど
1ケース2秒・・・83時間かかるやんけ
2.How to peel
GUIすっ飛ばして、static変数書き換えて関数呼び出し。結果のstatic変数を全ダンプ。
2.How to peel
種類 実行平均時間 合計
手動 30秒 1250時間
自動GUI操作 2秒 83時間
自動内部メソッド 10ミリ秒 24分
24分でできた。これなら機能追加期間に頻繁に実行できるね。ローカルPCでもね。
剥く皮の厚さはテスト対象ごとの性質を考えて決定してね。
最初は薄皮一枚剥がすのがおすすめ普通のGUI操作とほぼ同じプログラムから操作しやすいだけ
GUIコントロール
注意事項
2.How to peel
三浦さん（仮）は失敗していましたが
皮もおいしくいただきましょう
大事なのは、どこを自動化で抑えたかを把握すること。それによって、手動テストを削れる部分とやっぱりやっておくべき部分を明確にする。
A B C FC
自動化できたケース 手動で実施するケース
EDE
自動化
一部手動
手動
2.How to peel
＊毎日実行されるこちらに入れることが重要
ちなみに、既存の捉え方だと、ボトルネックがあると大きく自動化の範囲がそがれる場合がある。
2.How to peel
もったいない！
A B CF
C
自動化できたケース 手動で実施するケース
ED
E
自動化
一部手動
手動
＊毎日実行されるこちらに入れることが重要
皮を剥くことによってボトルネックのあるケースでも、いくらかは自動化できる。
でも、その分管理しないといけないけどね
A B C FC
自動化できたケース 手動で実施するケース
EDE
自動化
一部手動
手動
＊毎日実行されるこちらに入れることが重要
2.How to peel
3.新たな皮をかぶせる
3.Wrap to eat
OK！
あんたがHappyなのはわかった。
でも、これってホワイトボックスすぎて内部知っている開発者しか書けなくない？
3.Wrap to eat
はい、ごもっとも。それにテストシナリオに内部仕様の言葉使いたくないですよね。
テストシナリオ
・・・・生で触ってはだめ！
3.Wrap to eat
そこで、アプリケーションドライバですよ。
←参照
3.Wrap to eat
テストシナリオ
・・・・
操作の層とテストシナリオの層を明確に分離
3.Wrap to eat
アプリケーションドライバは、プロダクト作るときに開発チームで作っておく
Friendlyとその上位ライブラリ使えば簡単に作れるよ
内部仕様の知識を使って確実に正確に動作させる
こっちは外部仕様の言葉で理解できるインターフェイス
3.Wrap to eat
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/
テストシナリオ
・・・・
テストシナリオは、テストチームで書く
簡単な操作手段が（インテリセンスで片が付く）公開されていればテストシナリオはテストチームで書いた方が効率が良い
技術的な部分は隠蔽
3.Wrap to eat
これによって、チームが一丸となって自動化に取り組めるわけです。
そして、チーム全体で見てコストダウンに繋げれるのです。
3.Wrap to eat
・システムをプログラムとして見る
・操作上のボトルネックを取り除く
・剥いだ皮に注意→薄皮なのか、厚い皮なのか。
・メンバーそれぞれの特性を生かせる設計にしよう
まとめ
ご清聴ありがとうございました！
【Picture】Dawn Huczek
top related