Friendlyによる 内部APIを使ったシステムテスト自動化 · 石川達也...
Transcript of Friendlyによる 内部APIを使ったシステムテスト自動化 · 石川達也...
Friendlyによる 内部APIを使ったシステムテスト自動化
株式会社Codeer 石川達也 http://www.codeer.co.jp/
~組み込み機器テスト自動化での活用方法~
石川達也 株式会社Codeer代表取締役 Microsoft MVP for .Net Windowsアプリテスト自動化歴10年 Windowsアプリ操作用ライブラリFriendlyの開発者
自己紹介
http://www.codeer.co.jp/
Friendly紹介
じわじわ来てます。 一部上場企業様でも続々と採用中
アメリカでも大好評でした!
By Friendly.
Friendly紹介
Microsoft MVP Showcase 2位!
http://blogs.msdn.com/b/mvpawardprogram/archive/2014/11/04/mvp-showcase-winners.aspx
5
アジェンダ
1.テスト自動化について 2.自動化手法 ~なぜ内部APIを使うのか?~ 3.Friendly 4.組み込み機器テスト
6
1.テスト自動化について
7
テスト自動化
膨大なコストが必要とされる テスト作業の 「何割か」 を自動化することです。
全てを置き換えるものではありません。
1.About test automation
8
とは言え、手動でも
必要とされるテストの 「何割か」 しかできていません。
1.About test automation
自動化しておけば、テストは繰り返し実行可能です。
【品質状況の把握】 日々、指定のテストケースに関しては、リスクが排除されていることが、分かります。 つまり、品質の状況を把握できるのです。これは自動化した最大のメリットです。
デグレードのリスク回避
1.About test automation
手動テストのコスト、リスク
テスト量 リスク
開発者は頻繁に手動で周辺をテストしている。 つまり、確認コストは発生している。 (見えづらいコスト) しかし、多くの場合計画的とは言えず、 リスクは消しきれない。
【リリース時】
緊急であるので、想定外のコストとなる。 場合によっては、必要なテスト工数を捻出できず、リスク込でリリースされることもある。
【通常開発時】
計画的リリースの場合はテスト工数は膨大に投入される。一時的にリスクは下げられる。しかし、確認中に不具合発覚→修正があると、テスト工数は上乗せされる。
【緊急リリース時】
1.About test automation
テスト自動化によるリスクとコストの削減
テストの蓄積と、テスト実行作業の負荷分散
通常開発フェーズでも 前に実装した機能を壊していないことを確認しながらプロジェクトを進めることができる
リリース時でも蓄積されたテストケースがあるので、負荷が集中しない。
緊急リリースがあっても蓄積されたテストがあるので耐えられる。
テストは日々実行される
1.About test automation
リファクタリング
テスト自動化があるからこその品質向上
リリース速度向上、 ユーザー満足度Up
1.About test automation
13
さあ、自動化しよう!
1.About test automation
こんなにメリットのあること やらないなんて考えられない!
14
どうやって?
15
2.自動化手法 ~なぜ内部APIを使うのか?~
どうやって自動化していいか分からない!
座標合わせてクリック。 フォーカス入ったらキー入力。 出力を目視で確認。 無意識ですけどね。
テストスクリプト
--- --- ---
??? プログラムでは どうやって書けばいいか 分からないんですけど….
2.Why internal api?
人間なら
プログラムでは?
17
適したインターフェイスが異なる
人間ならGUIベースでキーマウスでの操作が直感的。 (CUIより使いやすいですよね?)
object GetValue(); void SetValue(object obj);
プログラムでは、もっと具体的な APIが直感的。 (座標とか言われてもプログラムから指定しづらい)
2.Why internal api?
18
テストスクリプト
--- --- ---
つまり対象を操作するための APIセットが必要なのです。
2.Why internal api?
テストスクリプト
--- ---
Library
・コントロールの操作に特化している。 ・可能なことはLibraryに実装されている操作。
テストスクリプト
--- --- ---
・入力ストリームに命令を挿入する。(直接アプリに届くわけではない。) ・座標、キーコード、タイミングはプログラムから扱いづらい。
入力ストリーム
【キーマウスエミュレート】
【一般的なUI操作ライブラリ】
一般的にも操作APIのセットは存在しますが・・・
自由度が低く扱いづらい
2.Why internal api?
【提案】 内部APIを使いましょう!
内部APIは、ここでは通常の実装時に使用、 作成するAPIを指します。 非常に強力です。 確実に動作します。
2.Why internal api?
21
実際、組み込みのプロジェクトでは テストモジュールをプロダクトに組み込んで テストを走らせることもあります。 内部APIを使ってテストを実行するのは 昔からある手法なのです。
ただ、この場合はテスト内容を変えるたびに製品のコンパイルが必要で手間が大きいですが。
2.Why internal api?
内部API
内部APIを使います
・慣れ親しんだAPIで ・自由度が高く ・高速に ・安定実行する 自動テストを記述できます。
2.Why internal api?
これしかない!
23
3.Friendly
24
Windowsアプリ操作系最強!
Is a magical library!
It break through
the walls of processes.
Win32、WinForms、WPF
3.Friendly
Friendlyは仕込みなしで 別プロセスの内部APIを呼べます。
・内部APIの呼び出し (.Netのフィールド、プロパティー、メソッド、ネイティブのDLL公開関数) ・DLLインジェクション
対象プロセスに仕込みが不要! 外部からアタッチして 内部APIを操作することができます。
3.Friendly
26
デモ
3.Friendly
27
幅広い操作性 安定した操作 結果にコミット!
3.Friendly
28
4.組み込み機器テスト
29
組み込み機器って 大抵の場合、付属のWindowsアプリついてますよね? それを使ってテストを実施しました。
テストスクリプト
--- ---
現時点での適用事例
4. Embedded device
30
組み込み機器への展望
実行モジュールを挿入しておけば、 操作可能になる。 ご興味のある方いらっしゃれば 是非一緒にトライしましょう!
テストスクリプト
--- ---
Windowsアプリの場合は 動的に挿入しています。 (事前の仕込みはいらない)
4. Embedded device
31
ご清聴ありがとうございました!
【Picture】 Dawn Huczek