Androidテスト勉強会 9月8日(土) #atest_hack に行ってきた
Androidテスト勉強会 9月8日(土) #atest_hack on Zusaar
に行って来たのでその時のメモなど。
全体的にAndroidだからこうテスト書こう、よりもテストは何のためにやるのか、テストの種類とは、みたいな一般化したお話が多かった印象。
あとGroovy使いが多かった。Gradle興味あるので触ってみようかなぁ
スライド内でも紹介されていたけど、Androidのテストについては
連載インデックス「Androidアプリ開発テスト入門」 - ＠IT
こちらを見るといいと思う。
以下会場で取ったメモ。後半あんまり取れてない…。
ソフトウェアテストな人同士で合わせておきたい5つの概念
@snskさん（しんすくさん(Androidテスト部)）
品質とは
品質それ単体では何もいってないよね
品質モデル
PQM Lite
機能実装度合い
セキュリティ、プライバシー
信頼性
覚えやすさと気持ちよさ
時間と資源のパフォーマンス
変更のしやすさ ←これがデベロッパテストで担保すべき場所
スケーラビリティ
テスト技術とプロセス品質技術
テスト技術→成果物を知るための技術
プロセス品質技術→プロセス自体の成熟度を知る技術
プロセス自体です。設計レビューの時間とか
テストレベル
Vモデル
要求 : 受け入れテスト
基本設計 : シナリオテスト
詳細設計 : 結合テスト
実装 : コンポーネントテスト
NativeDriverいちおし
自動化ツール
受け入れ、シナリオテストの話！
自動化で削減出来るもの
→実行工数のみ
初期の投資コストは手動より高くつくよね
メンテコストは手動とほぼ同様だよね
コスト的に手動＜自動となるのは、3回以上実行するもの
コンポーネントテストは自動化普通だよね？
誰がためのテストか
仕事として？
顧客のため？
自分(将来)のため？
将来作っていくことを考える場合
変更のしやすさが超重要！！
→分厚いドキュメントをかく()
→Unittestをかく
テストは知る技術 →技術がいる
既知のものを調べるのはチェック
Sue445 Style TDD
@sue445 さん (AZusaar!の中の人。TDDクラスタ（他多数）代表)
Junit実践入門にAndroidのテストもかかれてるよ！ テストの種類 QA testing セキュリティ、バグとか Developer testing 開発促進(TDD)はここ customer testing 使いやすさとか？ //todo あとでみる TDDは設計だよ！ 1.テストファースト 2.Redにする 3.実装する 4.Greenにする 5.テストが動くままでリファクタリング 黄金の回転！ Clean Codeの Martinいわく TDD三原則 テストファースト 失敗するテストを書くまでは次のテストは書かない 失敗するテストがある限り次のプロダクトコードは書かない テストファーストの重要性 テストを書くには何が必要なのか 入力 出力 クラス、メソッドの責務。パターンわけなど →これって設計だよね 作りたいものを明確にしてからじゃないといけない あやふやな仕様を明確にする→テストファーストによって 赤→緑になるときもちいいよね！ TDDのための一般的な理由 和田さんのスライドをみましょう 健康のため 素早くフィードバックをえる テストコードのリファクタリングは？ 同じテストコードが複数出てきたらし始める感じ
ソフトウェアテスト入門
@sassy_watson さん (Androidテスト部)
テスト初心者Androiderのためのソフトウェアテスト入門
テーマ
テストの種類について
テスト技法について
何をテストしたいかを把握するためのテストの種類を明確にする
V字モデルに基づいて
要件定義
やりたいことを明確にする
基本設計
画面などの基本的な設計
詳細設計
実装のための設計(シーケンス図とかクラス図とか)
実装
実装
ざっくり分類
プログラムで確認するテスト
・単体テスト
JUnitとかで確認するよ
細かい単位でテスト
直流の電球回路で1個ずつテストしたらつなげてもつくことがわかるよね
他のモジュールに依存するユニットテストをするには
他モジュールが何を返すのかわからん→Mockを使いましょう！
android.test.mockパッケージのクラスを使ってテストできる
overrideしないと基本的にExceptionをはく
android-mockというフレームワークもある
・結合テスト
androidだとユニットテストと結合テストの境界が曖昧
他のActivityに依存したりが多いから
Androidだとユニットテストしづらいから結合テストでがんばるのもアリ
実機で確認するテスト
システムテスト
仕様通りに動くかどうかのテスト
仕様書からテストケースを抽出する必要があり
機能だけでなくて、Performance、Securityとかの非機能要件も考慮する必要があるよ
受け入れテスト
主にお客様が自分たちの要求を満たしているかを確認するテスト
テスト技法について
テストを効率的にするにはどうすればいいのか
→テスト技法を用いてテストしよう！
よりよりテストとは
多くのバグを発見
少ない時間で発見
代表的なもの
同値分割
類似値をグルーピングしてそれらが同じ値がかえるか
→1とか3とか5とかの値を入れても同じ値が返ってくる
→グループの代表値のみ入れてテストの数を減らす
境界値分析
同値分割(グルーピング)した境界値に注目
境界値はバグが出やすい
255文字入力出来るEditTextの場合:
→0とか−1とか1とか255とか256とか
デシジョンテーブルテスト
入力と出力の関係表を元にしたテスト
他のテスト技法
状態遷移テスト
原因結果テストなど…
テスト技法ポジションマップ
テスト技法について、これはどのへんに効果的だよとかの図。よさそう
マインドマップからはじめるソフトウェアテスト
上層の話になるかも
テスト設計の勉強に
ソフトウェアテスト技法ドリル
テスト技法をドリル形式で
テスト設計の勉強に
Androidならテスト部の記事を！
テストはあくまでもバグを出すための手段であり、
テスト=目的となってはいけない
品質/コスト/納期とかのバランスを考えよう
GroovyなAndroidテスト
@alterakey さん (埼玉支部・デ部 「炎のAndroid開発道場」の著者の一人 android-runner開発者)
標準のAndroid testing frameworkは遅い そこでGroovy！ privateメソッド呼べるし Androidだと簡単に使えない Discobotとか実績あり？ JVMのテストならOK! JVMでテストとは Robolectric AndroidアプリをJVMでテストするためのフレームワーク Android ant runner antのみ現在は EclipseとかIDEとかは・・・ Unix限定 そもそもテストとは テストとは設計手段である Robolectricはパラメタライズドテストが使えない Robolectricを使わなければパラメタライズドテストできるけど //詳しくはスライドを見る。内容濃い
実務に近いテストコードを書いてみる
@kimukou2628 さん (Androidテスト部)
Try_to_writecode_practicaltest #atest_hack
テストってググり駆動できないよね 昔はWebページの広告枠をかう→いまはアプリの枠を買う Mediationが注目 端末ごとのハマりポイントなど //スライドにまとまっている。いい内容。あとGalaxy Nexus安定
iPhoneでのunit test
Twitter4jとテスト (タイトル変更された模様)
@yusuke さん (Twitter4J開発者。「Twitter APIポケットリファレンス」著者)
Twitte4jの開発、テスト環境について 環境 IDEA/maven/jenkins/jira/github/sonatype Android環境の自動テスト Android Emulator Plugin Twitter4jとテスト まずAPIとの疎通確認 アナウンス無しに仕様変更になる場合がある →テストが必要(CI) Twitte4jを使うアプリケーションでは Twitter4jがやってくれることはテストしないよ パラメータ、レスポンスの型 APIコール失敗時のリトライ ビジネスロジックは必要 正常系はあまり問題ない 異常系 ↓が同じ状況を作り出すのが面倒 twitterが落ちてるとか レートリミットに到達した場合のテスト メトリクス分析から見るソフトウェア品質の本 データ指向のソフトウェア品質マネジメント テストは動的な品質向上・担保の手段 静的な手段としては コンパイラ 静的解析 コードメトリクス 外部APIとかと接続する箇所は仕様に頼り過ぎない →Twitter API1.1で廃止予定のメソッドが今は呼べたり、OAuth無しでいけたり →ドキュメントが追いついていないとか テストケースの失敗について たまたま失敗しているのか→そのままでいいよね 継続的に失敗しているのか→対策しないとやばい jenkinsでテストしている場合はテストごとのageで何回連続でテスト失敗しているかが分かる jenkinsのテスト結果を待って次の作業は効率悪いので、テスト中に別のことをやり始める 異常系テストはMockを使う
