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

1. 皮を剥く

2. 自己紹介
石川達也
株式会社Codeer代表取締役
Microsoft MVP for C#
Windowsアプリテスト自動化歴9年
Windowsアプリ操作用ライブラリFriendlyの開発者

3. Windowsアプリ用の皮むき器です。
*詳細は後で
Friendly紹介
http://www.codeer.co.jp/
Friendly 自動化で検索！

4. Friendly紹介
無料です！

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

6. Friendly紹介
アメリカでも大好評でした！
亀岡的プログラマ日記
http://posaune.hatenablog.com/entry/2014/11/16/173446

7. アジェンダ
1.なぜ剥くのか？
2.剥き方
3.新たな皮をかぶせる

8. 1.なぜ剥くのか？
1.Why do you peel
it?

9. もっと自由に自動化したい！
1.Why do you peel
it?

10. これプログラムから操作しようと思うでしょ？
1.Why do you peel
it?
アプリケーションとして起動してる画面ね

11. いやいや、どうやんの？
このコントロールは、
UIオートメーション対応してんのね。
あれ、こいつ動かん。
キー、マウスエミュレートやるかー。
あかん、タイミング依存。
あれ？このウィンドウどれへん。
モーダルダイアログでかたまったー。
この画面、OSによって
デザインかわっとるやんけ！
1.Why do you peel
it?

12. むずかしわ！
1.Why do you peel
it?

13. システムテスト自動化のボトルネック
（あくまで私の経験）
そのほとんどは
「操作技術」
1.Why do you peel
it?
だって、簡単に操作できたら
手動でやってるスクリプトは
全部自動化するよね？

14. でもおかしな話ですよね？
僕らは、このシステムを作ったはずです。
その時は、APIを駆使して
自在にシステムを操ったはずなのですよ。
なんで、こんなことに？
1.Why do you peel
it?

15. それはね、こう見ているからですよ。
アプリケーションとして起動すると
もはやプログラムとしてみてないんですね。
別プロセスのGUIって得体がしれないもの。
1.Why do you peel
it?

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. いつもと同じ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. いやいや、何言ってんの？
それができたら簡単だけど。
別プロセスですよ？
そんなのできるわけないじゃん

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. 対象ごとに、皮むき器が必要になってくるんですけどね。
1.Why do you peel
it?
WindowsアプリならFriendly！

21. なぜ剥くのか？
僕自身が
自在にテスト自動化コードを書くために
この考えを採用したのです。
だって、こうしたら
普通のプログラムと同じノリで拡張できるし。
操作上のボトルネックを外すこともできる！
テスタビリティーも好きに向上できるじゃん！
1.Why do you peel
it?
Freedom！

22. それから・・・
システムテスト自動化って、つまりは
プロダクトプロセスとテストプロセスを協調動作させる
マルチプロセスプログラミング。
安定して動作させるためには
こういった、内部を見る視点が必要不可欠！
1.Why do you peel
it?
なぜ剥くのか？
アクロバティック！

23. 皮の剥き方
2.How to peel

24. それを、説明にするにあたってこれをみてください。
アプリってね、こうじゃないんですよ。
いや、こうなんだけど・・・
2.How to peel

25. こうなんですよー
ものによっては
サーバーとか外部機器と通信する
奥行があるのです！
2.How to peel

26. この結合したシステムを
効率よくテストしたいのです
GUIの詳細をテストが目的ではない。
システムをテストすることが目的なのだ！
2.How to peel

27. さあ、剥くぞー！
2.How to peel

28. 操作するということを考えて、ちょっと図を変えると
OS層
2.How to peel

29. まずは、一番不安定で、かつ自動化する価値が低いとこ
2.How to peel
OS

30. ここだ！
2.How to peel
OS

31. キーマウスエミュレートは・・・
OS層に送って、長い道のりを経て
目的のコードにたどり着く
安定したテストを書くのは困難（僕には無理
あと、低レベルな指令に頼ると
メンテナンス性が低いんですよねー
2.How to peel
一旦OSに送って
そこからアクティブな
プロセスに送信される
OS

32. よし、剥がそう
GUI
コントロール
（3rdパーティー）
2.How to peel

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. 備考:実はUIオートメーションも、この層は剥いでいる
GUI
コントロール
（3rdパーティー）
で、GUIコントロールとだけ
通信できるような仕組みを用意している
まあ、自由度はないけど
2.How to peel

35. 備考：Friendlyなら
GUI
コントロール
（3rdパーティー）
Netならフルアクセス、
ネイティブはDLL公開関数を操作できる
2.How to peel
自由すぎる！

36. 時には、もっと剥いでみよう！
2.How to peel

37. こんな感じ
2.How to peel
ユーザーロジック
ここまで剥いたら
全部知ってるよね

38. 結局のところ、テストしたい対象って、ここで十分だったりする
それに、扱いやすいよね！
もちろん、システムテストなんで
できるだけ上位から叩けた方が良いいけど。
テストの本質的な対象でない部分がボトルネックになって
自動化を諦めるのってホントにもったいない！
2.How to peel
バグのほとんどは
ここにあるでしょ？
あと、データ取得とかで使いますね。

39. 例えばこんなとき
//ここの結合は不安が少ない
void Event(object sender, EventArgs e)
{
EventCore(PointToClient(Control. MousePosition));
}
//これを呼び出す
void EventCore(Point mousePosClient)
{
//ここから先なら簡単に操作可能
//テストとしても問題がない
}
自動化可能に！ こういうの苦手・・・
・キー、マウス直接参照
・D&D
・OS提供のGUI
2.How to peel

40. あ、念のため単体テストとは違いますよ。
あくまで、操作開始トリガを変えてるだけです。
テストスクリプト
・・・・
結合したシステムに処理を実行させている
2.How to peel
単体テストは結合前の部品のテスト
これはこれで、やらなきゃね。

41. 裏ワザ
2.How to peel

42. 結合状態で特定のメソッドをテスト
テストスクリプト
・・・・
まったく、セオリーに反した手法ですが
場合によっては非常に費用対効果高い場合があります。
レガシーコードで
単体テスト不可とかね・・・
2.How to peel

43. 例えば、どんなとき？
はいはい、実際にあったんですよー
2.How to peel

44. すっげー深いネストで、
それぞれもすごく入り組んでて、
static変数ありまくりで、
初期化は意味わからんタイミングで、
おまじないのように書き込まれている
神関数スタート！
static変数の
状態によって複雑に
処理が変わるよ
実行したら
何処かのstatic変数の
状態が変わるよ
関数ツリー
クリスマスバージョン
2.How to peel

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

46. 仕様がわからんから、
仕様化テストをやりたい。
テストケースは総当たり15万ケース
結合状態でやんないといけない。
各static変数には
GUIが結びついてて
それで、状態を変えたり
取得したりできるのだけど
1ケース2秒・・・
83時間かかるやんけ
2.How to peel

47. GUIすっ飛ばして、
static変数書き換えて
関数呼び出し。
結果のstatic変数を全ダンプ。
2.How to peel
種類実行平均時間合計
手動30秒1250時間
自動GUI操作2秒83時間
自動内部メソッド10ミリ秒24分
24分でできた。
これなら機能追加期間に
頻繁に実行できるね。
ローカルPCでもね。

48. 剥く皮の厚さは
テスト対象ごとの性質を考えて
決定してね。
最初は薄皮一枚剥がすのがおすすめ
普通のGUI操作とほぼ同じ
プログラムから操作しやすいだけ
GUI
コントロール

49. 注意事項
2.How to peel
皮もおいしくいただきましょう
三浦さん（仮）は
失敗していましたが

50. 大事なのは、どこを自動化で抑えたかを把握すること。
それによって、手動テストを削れる部分と
やっぱりやっておくべき部分を明確にする。
自動化できたケース手動で実施するケース
A B C F
C
D E
E
自動化
一部手動
手動
＊毎日実行される
こちらに入れることが重要
2.How to peel

51. ちなみに、既存の捉え方だと、ボトルネックがあると
大きく自動化の範囲がそがれる場合がある。
自動化できたケース手動で実施するケース
2.How to peel
もったいない！
A B C
F
C
E
D
E
自動化
一部手動
手動
＊毎日実行される
こちらに入れることが重要

52. 皮を剥くことによって
ボトルネックのあるケースでも、
いくらかは自動化できる。
自動化できたケース手動で実施するケース
A B C F
でも、その分
管理しないと
いけないけどね
C
D E
E
自動化
一部手動
手動
＊毎日実行される
こちらに入れることが重要
2.How to peel

53. 3.新たな皮をかぶせる
3.Wrap to eat

54. OK！
あんたがHappyなのはわかった。
でも、これってホワイトボックスすぎて
内部知っている開発者しか書けなくない？
3.Wrap to eat

55. はい、ごもっとも。
それにテストシナリオに内部仕様の言葉使いたくないですよね。
テストシナリオ
・・・・
生で触ってはだめ！
3.Wrap to eat

56. そこで、アプリケーションドライバですよ。
←参照
3.Wrap to eat

57. 操作の層とテストシナリオの層を明確に分離
テストシナリオ
・・・・
3.Wrap to eat

58. アプリケーションドライバは、
プロダクト作るときに開発チームで作っておく
内部仕様の知識を使って
確実に正確に動作させる
こっちは
外部仕様の言葉
で理解できる
インターフェイス
Friendlyとその上位ライブラリ使えば
簡単に作れるよ
3.Wrap to eat

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. テストシナリオは、テストチームで書く
テストシナリオ
・・・・
簡単な操作手段が
（インテリセンスで片が付く）
公開されていれば
テストシナリオは
テストチームで書いた方が
効率が良い
技術的な部分は隠蔽
3.Wrap to eat

61. これによって、チームが一丸となって
自動化に取り組めるわけです。
そして、チーム全体で見て
コストダウンに繋げれるのです。
3.Wrap to eat

62. まとめ
・システムをプログラムとして見る
・操作上のボトルネックを取り除く
・剥いだ皮に注意
→薄皮なのか、厚い皮なのか。
・メンバーそれぞれの特性を生かせる設計にしよう
ご清聴ありがとうございました！
【Picture】
Dawn Huczek