【SQiP2014】システム操作インターフェイス最適化によるテスト自動化ROI向上
•Download as PPTX, PDF•
11 likes•10,375 views
SQiP2014で発表したスライドです。 GUI以外のインターフェイスを使うことによって、削減できるコスト、得ることのできる利益について説明しています。GUI以外のインターフェイスを使う方法にはWindowsではFriendlyがあります。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 【SQiP2014】システム操作インターフェイス最適化によるテスト自動化ROI向上
Similar to 【SQiP2014】システム操作インターフェイス最適化によるテスト自動化ROI向上 (20)
More from Tatsuya Ishikawa
More from Tatsuya Ishikawa (14)
【SQiP2014】システム操作インターフェイス最適化によるテスト自動化ROI向上
- 1. システム操作インターフェイス最適化による テスト自動化ROI向上 株式会社Codeer 石川達也 http://www.codeer.co.jp/
- 2. 自己紹介 石川達也 株式会社Codeer代表取締役 Microsoft MVP for C# Windowsアプリテスト自動化歴9年 Windowsアプリ操作用ライブラリFriendlyの開発者
- 3. ご相談を受けた企業様の悩みで多いもの システムテスト自動化 やったことあるんだけど、 効果が出なくて・・・
- 4. 4 課題抽出
- 5. エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作業とROI要素 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行
- 6. エラー！ 成功 仕様変更等でメンテ 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行 テスト起因のエラー。 解析工数は運用コスト。
- 7. 課題① 自動実行不安定 ほぼ毎日、 いずれかのテストが タイミング依存で失敗。 ランニングコスト化。 想定外の運用コストとなっている。 エラー！ テスト不安定によるエラー発生数 （A社） 成功 仕様変更等でメンテ 15 10 5 0 作成 指定のケースではデグレがない という情報を取得できた！ BugFix Before 実行 テスト起因のエラー。 解析工数は運用コスト。 モチベーション低下 自動化に対する不信感
- 8. 作業とROI要素もう一つ エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行
- 9. エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作成 BugFix 実行 指定のケースではデグレがない という情報を取得できた！
- 10. 課題② 自動化されたテストケースが少ない 3000 この情報の価値が低い。 成功？だから何？ 作成 指定のケースではデグレがない という情報を取得できた！ でも・・・ エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ BugFix A社自動化ケース数 実行 成功しても安心できないし、 手動テストも、ほとんど減ってない。 2500 2000 1500 1000 500 0 Before パラメタライズ込でこの件数なので 自動化としては少なめ。 箇所としても、自動化容易性が優先されている。
- 11. 作成 エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ BugFix 実行 不安定なテスト 増やさないで・・・ 成功しても安心できないし、 手動テストも、ほとんど減ってない。 →じゃあ、そんなに工数出せないよ。 工数足りない。 作れないよ・・・ 少ない工数で作った スクリプトだから メンテがつらい。 悪循環 ケース少ないと 価値が低い。
- 12. 12 課題①②の共通問題 ・・・
- 14. 課題①②の共通問題 ＊その前に注意書き 実際には、これらの課題は ・テストケースの見直し ・管理の改善 ・CI環境の改善 ・単体テストへの移行 など、複合的に対応されました。 しかし、ここでは主題 「システム操作インターフェイス最適化」 に沿った改善のみにフォーカスして説明します。
- 16. 課題①②の共通問題 テスト以前に対象アプリの操作が上手くいっていない。 ココ だから・・・ ・タイミング依存でテストが失敗する ・テスト作成工数が増える →見積もり時点で自動化対象から省かれる。
- 17. 課題①②の共通問題 ココ Why? キー、マウス エミュレートは 不安定 マルチプロセス プログラミング そもそも GUIって人間用 UIAutomation？ キャプチャ リプレイ？ OSからユーザ コードまでの BlackBox
- 18. GUIアプリを「外側から」「プログラムから」「安定して」 操作するのは難しい！ キー、マウス エミュレートは 不安定 マルチプロセス プログラミング 課題①②の共通問題 そもそも GUIって人間用 UIAutomation？ キャプチャ リプレイ？ OSからユーザ コードまでの BlackBox ココ ここまでのまとめ！
- 19. 19 対応 アプリ操作インターフェイス最適化 ～内部APIを使う～
- 20. 20 【備考】 内部APIとは
- 21. 21 内部APIとは？ 本稿では、 普通にプログラムで使う（作る）APIを指す。 つまり、普段書いているプログラムの クラス、メソッド、フィールド、プロパティーなど。
- 22. 22 GUI層例えばグリッド操作
- 23. 23 GUI層例えばグリッド操作 人間ならキー、マウス。 自動化なら、そのエミュレート もしくはUIAutomation・・・
- 24. 24 GUI層例えばグリッド操作 内側にはプログラム実装用の 簡単で高機能なAPIが公開されている //WinFormsのDataGridViewの場合 bool BeginEdit(bool selectAll); bool EndEdit(); Control EditingControl { get; } DataGridViewRowCollection Rows { get; } ・・・ これを使えば、 プログラム作成時同様、 自由に安定した操作が可能！
- 26. 26 アプリ実装層例えば右クリック以降の処理 一般的には マウスエミュレートしか選択肢がない。 座標計算して、タイミング合わせて・・・
- 27. 27 アプリ実装層例えば右クリック以降の処理 内部では、 プログラム(API)として実装しているので・・・ //ボタンを押したイベント Void OnMouseClick(object sender, MouseEventArgs e) { ・・・ MouseRightClickCore(row, col); } //このAPIは比較的プログラムから扱いやすい Void MouseRightClickCore(int row, int col) { ・・・ FunctionA(); } Void FunctionA() { ・・・ FunctionB(); } 最も操作しやすいAPIを呼び出せる。 どうしても操作できない場合は、 コードの変更も可能。つまり、 テスタビリティーを向上することが可能。
- 28. 28 単体テストとの違いは？ 単体テストは、部品単位。 システム（アプリ）は 組みあがっていない。 内部APIを使ったシステム操作は アクセス方法が違うだけで 結合状態のシステムを操作している。 あくまでシステムテスト。
- 29. 注意点１ 使用する内部APIによっては、人間の操作との差分が生じる。 テスト対象外になった部分を手動テストにフィードバックする。 GUI層のAPIで操作した場合は、手動とほぼ等価。 （あくまで、操作としての話） アプリ実装の層のAPIを使う場合は、 どれくらい削ったかを確実にフィードバック。
- 30. 注意点２ 内部APIだが、テストから呼び出した時点で テスト用の公開API扱いとなる。 void Function() { ・・・ } テストで使うことになったよ。 変えたら教えてね。
- 31. 参考 以下の書籍にGUI以外のインターフェイスを 使ってシステムテストを実施する手法が紹介されている GUI以外の公開APIを使って テストを自動化する方法が紹介されている。 DSLのスクリプトで GUI以外のインターフェイスを使って 受け入れテストを自動化する手法が 紹介されている。
- 32. Windowsアプリでこれを実現するライブラリ 無料 Nugetから string Func(int value){} Friendly //テストプロセス public void Test() { //呼び出し string ret = form.Func(3); //Dllインジェクション! WindowsAppExpander. LoadAssembly(app,GetType().Assembly); } public class MainForm : Form { string Func(int value) { ・・・ } } http://www.codeer.co.jp/AutoTest プロセスの壁を突破できる！
- 33. Windowsアプリでこれを実現するライブラリ 全部無料 使用頻度の高いGUI層の操作は ラップした上位ライブラリもある 記述性UP Win32 WinForms WPF PinInterface 基本 内部メソッド操作、DLLインジェクション Friendly.Windows.NativeStandardControls Friendly.FormsStandardControls Friendly.WPFStandardControls Friendly.PinInterface
- 34. 34 具体的な対応 アプリ操作インターフェイス最適化 ～内部APIを使う～
- 35. 35 具体的な対応 アプリ操作インターフェイス最適化 ～内部APIを使う～ ・課題①②の根本原因は同じなので、 どの対応も両方の課題に効果が出ております。 （つまり安定して操作できる範囲が拡大したということ）
- 36. GUI操作を内部APIベースに変更 datepicker.SelectedDate = new DateTime(2014, 9, 11); ・テストの主目的はOSと各GUIライブラリの結合ではない ・安定性、実装容易性を重視 ・サードパーティー、自作のGUIも操作可能 上位ライブラリの使用で、さらに工数カット
- 37. 自動化困難で効果の低い部分の分離 //ここの結合は不安が少ない void Event(object sender, EventArgs e) { EventCore(PointToClient(Control. MousePosition)); } //これを呼び出す void EventCore(Point mousePosClient) { //ここから先なら簡単に操作可能 //テストとしても問題がない } 自動化可能に！ こういうの苦手・・・ ・キー、マウス直接参照 ・D&D ・OS提供のGUI
- 38. 実装工数が大きいものはGUI操作を省略 例） システムテスト自動化を実施したいが、 GUI操作で、実行するには困難で諦めていた。 サーバーと通信
- 39. 実装工数が大きいものはGUI操作を省略 例） システムテスト自動化を実施したいが、 GUI操作で、実行するには困難で諦めていた。 重要な処理 分析の結果、 この範囲のテストを 自動化できたら 十分効果アリと判断。 サーバーと通信 分析の結果、品質を確認したい部分は GUIではなかったので、内部メソッドを利用。 約5千ケースが自動化された。
- 40. 例） 文字列のパースをする処理があり、 それはアプリの様々な設定により結果が変わる。 しかも、レガシーコード。（単体化が困難） 求められるテストケースは15万ケース。 設定A 設定C 設定B 入力 実行時間が大きいものはGUI操作を省略 種類実行平均時間合計 手動30秒1250時間 自動GUI操作2秒83時間
- 41. 実行時間が大きいものはGUI操作を省略 例） 文字列のパースをする処理があり、 それはアプリの様々な設定により結果が変わる。 しかも、レガシーコード。（単体化が困難） 求められるテストケースは15万ケース。 設定A 設定C 設定B 入力 種類実行平均時間合計 手動30秒1250時間 自動GUI操作2秒83時間 自動内部メソッド10ミリ秒24分→Dailyで回帰化可能な時間に！
- 42. 実行時間が大きいものはGUI操作を省略 例） 文字列のパースをする処理があり、 それはアプリの様々な設定により結果が変わる。 しかも、レガシーコード。（単体化が困難） 求められるテストケースは15万ケース。 設定A 設定C 設定B 入力 種類実行平均時間合計 手動30秒1250時間 自動GUI操作2秒83時間 自動内部メソッド10ミリ秒24分→Dailyで回帰化可能な時間に！ 時間がかかりすぎるとDailyの回帰環境に組み込めない。 分散させることも可能。実際そうしたケースもある。 ただ、分散には大がかりな仕組みが必要になる。 シンプルに速くなれば開発者のローカルPCでも実行可能。
- 43. 43 気づきGUI省略 パラメタライズが求めらるテストケースは GUIが重要でないことが多い。 //同一のテストシナリオを複数のパラメータで実行 [TestMethod] [DataSource(...)] public void TestScenario() { ... } とは言え、単体テストで済ませられるなら それに越したことはない・・・。
- 44. 不安定なテストが発見されたらすぐに対応 アプリ実装起因で不安定になることがある 原因対応 タイミング依存の不具合不具合修正 タイマ、非同期処理、 描画イベントを利用した実装 確実に同期がとれる情報を参照する テスト時は同期にする
- 45. 不安定なテストが発見されたらすぐに対応 アプリ実装起因で不安定になることがある 原因対応 タイミング依存の不具合不具合修正 タイマ、非同期処理、 描画イベントを利用した実装 確実に同期がとれる情報を参照する テスト時は同期にする とにかく、安定するテストでなければ許容しない。 優先的に対応！ 安定させられる手段(内部API)があればこそ！
- 46. 不安定なテストが発見されたらすぐに対応 アプリ実装起因で不安定になることがある 原因対応 タイミング依存の不具合不具合修正 タイマ、非同期処理、 描画イベントを利用した実装 確実に同期がとれる情報を参照する テスト時は同期にする 例) 不安定な処理の周辺のテストを86ケース投入してから安定するまで 6 5 4 3 2 1 0 備考として、個々では成功することを確認してからCI環境に投入している。 1日目にプロダクトの不具合を突き止め修正 テストにも問題があり、3日目に気づいて修正 4日目以降は運用コストは発生していない 1 2 3 4 5 6 7 8 9 10 11 12 13 14 エラー数 ランニングコスト化は絶対避ける！
- 47. 47 はい
- 50. 50 新たな課題
- 51. 作業とROI要素新たな課題 エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行
- 52. エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行
- 53. 課題③ 作成、メンテに内部仕様の知識が必要 class InputWindow : Window { TextBox _name; DatePicker _founding; DataGrid _member; Button _ok; public Data GetData() { ・・・} } エラー！ 成功 しかも、テストシナリオにばら撒かれる・・・ テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行 //変数名を知っている必要がある var _name = new WPFTextBox(window._name); var _founding = new WPFDatePicker(window._founding); var _member = new WPFDataGrid(window._ member); var _ok = new WPFButtonBase(window._ok); //内部メソッドを知っている必要がある var data = Window.GetData();
- 54. テストシナリオから使うインターフェイス最適化 54 対応 ～アプリケーションドライバの導入～
- 56. アプリケーションドライバとは？ テストシナリオ.dll テストプロセス ① アプリケーション② ドライバ.dll アプリ操作の詳細と テストシナリオを 分離して記述する設計手法。 内部APIを使うときは必須！
- 57. アプリケーションドライバとは？ テストシナリオ.dll テストプロセス ① アプリケーション② ドライバ.dll 「継続的デリバリー」で紹介されている。 詳細はこちらを参照。
- 58. 58 具体的な対応 テストシナリオから使うインターフェイス最適化 ～アプリケーションドライバの導入～
- 59. 59 実装例 →ほとんど書籍通りなので省略。 興味がある方は是非読んでください！
- 60. 今回、実装したことと、必要だった知識 記述したこと実装に必要な知識 アプリケーション ドライバ ・WindowDriver ・内部仕様に依存する処理 ・汎用的な処理 内部仕様 C# 基本的なプログラム設計能力 テストシナリオ・テストケース （できるだけシンプルに） 外部仕様 基本的なC#の知識 テストシナリオは簡単に書けるように アプリケーションドライバの設計を頑張った！
- 61. 61 作業分担できた。 アプリケーション ドライバ.dll 開発チーム テストシナリオ１ テストシナリオ２ テストシナリオ３ 評価チーム 当然共通化にもなり、コード量が行数で約35%減。 また、共通処理を使うことでテスト作成効率もUP。
- 62. 62 成果
- 63. エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作業とROI要素 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行
- 64. 課題① 自動実行不安定 エラー！ 成功 仕様変更等でメンテ 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行 テスト起因のエラー。 解析工数は運用コスト。
- 65. 解決① 自動実行不安定 エラー！ 成功 仕様変更等でメンテ 15 10 5 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 朝来てAllGreen実っ行 て気持ちいい！ テストに対する信頼も高いから Redの時は本腰入れて調査できる！ テスト起因のエラー。 解析工数は運用コスト。 0 Before After 改善前は、ほぼ毎日結果を解析して、プ ロダクトに問題がないことを確認する必要 があった。（半自動）改善後は、不安定 なテストが混入することはあるが即座に対 応して安定化させることができた。 テスト不安定によるエラー発生数 (異なる期間で3カ月集計) ←無駄なコストは たまに出るだけ A社
- 66. 課題② 自動化されたテストケースが少ない エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作成 BugFix 実行 指定のケースではデグレがない という情報を取得できた！ でも→価値が低い。
- 67. 解決② 自動化されたテストケースが少ない 広範囲にわたり、 ソースを改修した直後に 「上手く作成された、多くのテストケースをパスした」 という情報を得れるのは非常に価値がある。 作成 エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 多い！ BugFix 実行 自動化ケース数 200000 150000 100000 50000 0 Before After 部分的にリリース、リファクタリング実行の判断材料 に使うことができるようになった。 最終に実施する手動テスト数も減らすことに成功。 A社 デグレ検出数も増えてはいる。ただ、 の方が主目的。
- 68. 課題③ 作成、メンテに内部仕様の知識が必要 エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行
- 69. 解決③ 作成、メンテに内部仕様の知識が必要 テストシナリオ作成だけなら不 エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行 負荷分散！
- 70. 解決③ 作成、メンテに内部仕様の知識が必要 テストシナリオ作成だけなら不 実は！ エラー！ テストシナリオの品質UPは 全てのROI要素に好影響を与えた！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行
- 71. 解決③ 作成、メンテに内部仕様の知識が必要 テストシナリオ作成だけなら不 簡単になったから、 多くのシナリオを作成、メンテできた！ 実は！ エラー！ テストシナリオの品質UPは 全てのROI要素に好影響を与えた！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行 共通化により 安定した処理を使いまわせた！
- 72. エラー！ 成功 テスト起因のエラー。 解析工数は運用コスト。 仕様変更等でメンテ 作成 指定のケースではデグレがない という情報を取得できた！ BugFix 実行 つまり・・・
- 73. エラー！ 成功 仕様変更等でメンテ 作成 BugFix 実行 コストダウン！ ROI向上！ 利益UP！
- 74. まとめ ・アプリ操作インターフェイス 内部APIを有効に使うことで、 低コストで安定した操作を実現できた。 ・テストシナリオから使うインターフェイス テストプログラムも設計が重要！ テストプログラムの品質は すべてのROI要素に関わってくる。 特に内部APIを使うときはアプリケーションドライバは必須！ システム操作インターフェイス最適化による テスト自動化ROI向上！
- 75. 75 ご清聴ありがとうございました。 【Picture】 Dawn Huczek vectorvaco.com エラー！ 成功 Specail Thanks .reviewrc(資料レビュー) めとべや(WPFStandardControls) VSハッカソン倶楽部(PinInterface)