http://sigstj.connpass.com/event/16033/ の資料です。

1. Web and App Testing
ICST 2015 まるわかりDay!
松尾和昭 (@Kazu_cocoa)

2. 全体
• Behind an Application Firewall,Are We Safe from
SQL Injection Attacks ?
• Using Multi-Locators to Increase the Robustness
of Web Test Cases
• Understanding the Test Automation Culture of App
Developers
• Detecting Display Energy Hotspots in Android Apps

3. Behind an Application Firewall,
Are We Safe from SQL Injection Attacks ?
以下の論文を参照しています
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7102581

4. 概要
• Web Application Firewallにより、SQL Injectionを防
ぐ重要性が高まっている
• 攻撃者と防御者はいたちごっこ
• 効果的に数をこなして、より多くのSQL Injectionを事
前に検出し、攻撃を防いで行きたい

5. 導入
• Web Application firewallsはオンラインシステムを攻撃から守るためには
欠くことのできないもの
• 新しい攻撃方法、それを防ぐ方法がイタチごっこのように早く表れている
• この研究では、Web Application FirewallとSQL Injection攻撃に焦点を
当てている
• 機械学習を用いてSQL Injection攻撃を仕掛け、穴を見つける
• ML-Drivenと呼ばれる手法が提案手法
• ModSecutiryに対して提案手法を試し、有効性を確認している
• https://github.com/SpiderLabs/ModSecurity

6. 用語
• SQL Injection Vulnerabilities
• 不正にSQL文を実行する攻撃
• Web Application Firewall
• OSI参照モデルでいうApplication層におけるFirewall
• network層のものではない
• 文字列パターンのブラックリスト形式でブロックすること
が多い

7. 方法• ML-Driven
• 主に、BOOLEAN、UNION、PIGGY(SQLのunion query
family)を対象に文法を定義
• 部分的に文法を変異させていくことで、テストケースとなる
SQL文を生成していく
• 攻撃が通ったもの、通ってないものにラベルをつけ、学習し
ながらSQL文の生成
• search-base auto genrationなどの論文を参考にしていた

8. 実験環境
ModSecurity
Attack
SOA based web app
java/servlet
customer
relationship
web app
HotelRS
Cyclos
SugerCRM

9. 結果:性能
B and D
変異させる度合い
B: 10
D: 100

10. 結果:生成されるテストケース

11. まとめ1
• この論文では、機械学習を取り入れたテストによりSQL
Injectionの脆弱性を発見する方法を提案している
• テストケースの自動生成含む
• 攻撃が成功/失敗したところから、異なる攻撃が成功
するまでのテストケースの変異も取り入れているとこ
ろが特にユニーク

12. まとめ2
• ML-Driven
• SQL Injectionの特定を効率的に行っている
• テストケースをML-Drivenなしでランダムで作成する
ときに比べ、より良い性能を発揮している
• 数多く実施することで、より多くの成功するSQL
Injectionを特定できることが期待されるため、それらを
修正することができるようになる

13. Using Multi-Locators to Increase the Robustness
of Web Test Cases
以下の論文を参照しています
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=7102611

14. 概要
• Webテストのテストスクリプトでは、Web locatorを使っ
て描画されている要素を特定するが、locatorは変更に
弱い
• 壊れた場合、人手で修正する必要がある
• multi-locatorを使うという、壊れにくい、人手による
修正が小さな労力で済む方法を提案する
• 保守性の向上

15. 導入
• Webテストのためのテストスクリプトでは、GUI要素を特
定するためにWeb locatorを使うことが多い
• Web locatorは大事だが、開発する上で壊れたら
locatorを修正しなければいけない
• この研究では、”multi locator”と呼ぶlocatorを提案
する
• 複数のlocatorの中から、どのlocatorが正しいの
か、を投票によって決める

16. Web locatorについて
• Web elementの特定手段
• HTMLのDOMに付随する付加情報をもとに識別する
• attributes、テキスト、XPathなど
• この研究では、XPathをもとにしたlocatorsを考える
• FirePath、Selenium IDE、ROBULA+など複数の
アルゴリズムで取得することができる

17. XPath locators

18. Broken XPath locators

19. multi-locator
• single locator(1つの要素のみ)
• 1つのWeb elementに1つのlocatorを含ませる
• multi-locator
• 異なるアルゴリズムにより生成されたlocatorの集合を1つの
Web elementとみなす
• automatic repairを持つ
• broken locatorとなったlocatorに対して、voteされた値
を設定しなおす

20. multi-locator

21. 結果:
アルゴリズムごとのlocatorの壊れ具合

22. 結果: locatorの壊れ具合

23. まとめ
• Web elementを取得して、Webのテストスクリプトを書くことでテスト自
動化を図ることが多い
• locatorが壊れたら手動で修正する必要がある
• locatorを取得するアルゴリズムは、それぞれが異なる利点/欠点を持つ
• multi-locatorを提案し、変更に強い、locatorを用いたテストスクリプ
トを実装できるようにしたい
• 保守性向上
• 研究における結果では、multi locatorはsingle locator(ROBULA+)と
比べて29.5%も壊れにくくなったという結果がでた

24. Understanding the Test Automation Culture
of App Developers
以下の論文を参照しています
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=7102609

25. 概要
• スマートフォン向けアプリケーション開発において、開発者
の間におけるテスト自動化の文化を理解したい
• 文化を理解し、どのような問題に直面しているか知りたい
• Android開発者コミュニティが主な対象で、Windows開発
者コミュニティと比較しながら違いを分析する
• 将来、開発者支援ツールの開発に役立たせたい

26. 導入
• 近年、スマーフトフォン向けアプリケーションの開発・利用が拡がっ
ている
• その開発はWebベースのアプリケーションと大きく異なる
• 開発環境、ツールなど
• 何かスマートフォン向けアプリケーション開発に対してテスト自動化
などの方面で貢献したいが、何が問題か研究しているものがない
• Android開発者に焦点を当て、現状を知るための研究・調査が今
まで無かった

27. 研究内容の概要
• F-Droidから600以上のアプリを得、その開発者にテス
トに関するアンケートをとる
• Android開発者。127名から回答があった。
• Windows開発者に対して同様のアンケートをとる
• コミュニティ間の違いを知る
• 考察
※F-Droid: Free/OSSなAndroidアプリを配布するサービス

28. Android Community

29. テストケースの量

30. アプリのコード数とテスト

31. アプリとアプリ開発者数

34. Windows Community

35. テスト自動化ツールの使い道

36. テストするにあたって直面している課題
(Android開発者との比較)

37. まとめ
• Android開発者における、テスト自動化への取り組みと課題を
Microsoft開発者と比較することで知ることができた
• 対象となったAndroidアプリのうち、全体の14%がテストコー
ドを持ち、そのさらに9%のみがカバレッジ40%を超える状態
だった
• Android開発者の多くはJUnitなど様々なツールを使っている
が、マニュアルテストがそれ以上に主力になっている
• 組織的なサポート、ドキュメントなど、テストツールに不足して
いる点が挙がった

38. Detecting Display Energy Hotspots
in Android Apps
以下の論文を参照しています
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7102585

39. 概要
• モバイルアプリにおける電池の消費を下げるために、ア
プリの画面単位で電池消費の大きなDEH(Display
Energy Hotspot)を検出する方法を考えた
• まだα版だが、dLens という名前でライブラリを開発
• この方法自体は自動化できるため、ソフトウェアエンジ
ニアを必要としないで実施可能

40. 導入
• モバイルアプリにおける電池の重要性は高い
• ディスプレイや、通信にかかる消費電力が大きい
• ディスプレイ技術は発達し、基板としてはより省電力になってきている
が、どんな色を表示するか？というアプリ側制御によってもディスプレイ
の消費電力は左右される
• この問題に対して、任意のアプリを使っているときの、ディスプレイの消費
電力の最も消費の大きなDEHを見つけ出してアプリを修正することで、結
果としてディスプレイの消費電力を下げる方法を研究する
• 398のAndroid marktに存在するアプリに対して提案した手法を適用する
ことで、DEHをいくつか見つけ出すことができた

41. 全体像

42. • 画面単位でスクリンショットを取得する
• 取得したスクリーンショットからCTS(Color
Transformation Scheme)を生成する
• Web Applicationとして電力消費が効率的になる色合い
• DEP(Display Energy Profile)とCTSを掛け合わせた画像
と、もとのスクリーンショットを比較して消費電力の差分を
求める
• 消費電力の大きなスクリーンショットから順にランク付けされ
たUIの結果を出力する

43. テスト対象の一例と作業時間

44. 作業中の消費電力

45. デバイス間の差異

46. Galaxy S2の結果
Tc: CTS生成にかかった時間
Te: 画像比較にかかった時間
Overall: Tc + Te
Per UI: 1スクリーンショットごとに要した時間

47. 398個のアプリのうち、
DEHsが大きかったもの

48. まとめ
• アプリの色合いを調整することで、アプリ利用時の消費
電力を抑制する方法を提案
• dLensという名前でツールを実装し、398アプリに対し
て実際に適用、DEHsを計測した
• 効果がありそうなことを確認

49. 終わり