Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Stac2014 石川

26,154 views

Published on

http://connpass.com/event/9618/
で話た内容です。

Published in: Software
  • Be the first to comment

Stac2014 石川

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

×