不具合調査とTest

2024/12/12 Android Test Night #10 の発表「不具合調査とTest」で使用したスライドです
https://testnight.connpass.com/event/338079/

参考文献へのリンク
Testing Strategies https://developer.android.com/training/testing/fundamentals/strategies
Android Vitals https://developer.android.com/topic/performance/vitals

Transcript

1. 不具合調査とTest Kazuki Chigita (chigichan24) 2024/12/12 Android Test Night
2. $whoami 名前: Kazuki Chigita (@chigichan24) お仕事: Androidアプリ開発者
3. 不具合のタイムライン
4. 不具合のタイムライン ↑ バグの発生！
5. 不具合のタイムライン ↑ 誰かが見つける
6. 不具合のタイムライン ↑ 修正する
7. 不具合のタイムライン １: 不具合を修正して正常にしたい
8. 不具合のタイムライン ２: 修正までを短くしたい →不具合の検知を早くしたい
9. 不具合のタイムライン ３: 類似の不具合の発生を防ぎたい
10. 不具合に関するトピック 1. 不具合を修正して正常にしたい 2. 修正までを短くしたい 3. 類似の不具合の発生を防ぎたい
11. 不具合に関するトピック 1. 不具合を修正して正常にしたい 2. 修正までを短くしたい 3. 類似の不具合の発生を防ぎたい
12. １: 不具合を修正して正常にしたい • 正常な状態に修正する 🏎 Quick Fix 🛠 Fundamental Fix 🕰 Revert
13. １: 不具合を修正して正常にしたい • 正常な状態に修正する ◦ workaroundパッチをあてる (quick fix) ◦ 根本的な問題から修正する (fundamental fix) ◦ 問題が発生しているcommitをrevertする (revert)
14. [🏎] Workaroundパッチを当てる • 必ず TODO コメントと後でfoundamental fixを行うための GitHub issues / チケット等を作成する
15. [🏎] Workaroundパッチを当てる • 必ず TODO コメントと後でfoundamental fixを行うための GitHub issues / チケット等を作成する • テストが不足しているならこのタイミングでも追加する ◦ foundamental fix を行う際に修正が適当であることを、 テストをもって保証する。
16. [🛠] 根本の問題を修正する • 調査して見つかった問題を根本から修正する ◦ テストで変更の妥当性を評価する
17. [🛠] 根本の問題を修正する • 調査して見つかった問題を根本から修正する ◦ テストで変更の妥当性を評価する どうやって調査する？
18. [🛠] 根本の問題を修正する • 調査して見つかった問題を根本から修正する ◦ テストで変更の妥当性を評価する ◦ E2Eテストやマニュアルテストに頼りすぎない どうやって調査する？ 統計情報とユーザシナリオに着目
19. [🛠] 根本の問題を修正する • 統計情報 ◦ 例1: 特定のOSバージョンで発生している ◦ 例2: 特定のバージョンで発生している ◦ 例3: 特定の条件で発生ている
20. [🛠] 根本の問題を修正する • 統計情報 ◦ 例1: 特定のOSバージョンで発生している ◦ 例2: 特定のバージョンで発生している ◦ 例3: 特定の条件で発生ている • ユーザシナリオ ◦ (私の経験的に)コードから追うよりも、ユースケースから 考える方が根本の原因に辿り着きやすく、本質的な 改修に繋がりやすい ◦ ログなどからユーザの動作を追って再現させるのも効果的
21. [🛠] 根本の問題を修正する • 統計情報 ◦ 例1: 特定のOSバージョンで発生している ◦ 例2: 特定のバージョンで発生している ◦ 例3: 特定の条件で発生ている • ユーザシナリオ ◦ (私の経験的に)コードから追うよりも、ユースケースから 考える方が根本の原因に辿り着きやすく、本質的な 改修に繋がりやすい ◦ ログなどからユーザの動作を追って再現させるのも効果的 よっしゃ原因特定！
22. [🛠] 根本の問題を修正する • 統計情報 ◦ 例1: 特定のOSバージョンで発生している ◦ 例2: 特定のバージョンで発生している ◦ 例3: 特定の条件で発生ている • ユーザシナリオ ◦ (私の経験的に)コードから追うよりも、ユースケースから 考える方が根本の原因に辿り着きやすく、本質的な 改修に繋がりやすい ◦ ログなどからユーザの動作を追って再現させるのも効果的 修正とテストはセット
23. [🛠] 根本の問題を修正する • 統計情報 ◦ 例1: 特定のOSバージョンで発生している ◦ 例2: 特定のバージョンで発生している ◦ 例3: 特定の条件で発生ている • ユーザシナリオ ◦ (私の経験的に)コードから追うよりも、ユースケースから 考える方が根本の原因に辿り着きやすく、本質的な 改修に繋がりやすい ◦ ログなどからユーザの動作を追って再現させるのも効果的
24. [🛠] 根本の問題を修正する • 統計情報 ◦ 例1: 特定のOSバージョンで発生している ◦ 例2: 特定のバージョンで発生している ◦ 例3: 特定の条件で発生ている • ユーザシナリオ ◦ (私の経験的に)コードから追うよりも、ユースケースから 考える方が根本の原因に辿り着きやすく、本質的な 改修に繋がりやすい ◦ ログなどからユーザの動作を追って再現させるのも効果的 Unit Testに追加しやすい
25. [🛠] 根本の問題を修正する • 統計情報 ◦ 例1: 特定のOSバージョンで発生している ◦ 例2: 特定のバージョンで発生している ◦ 例3: 特定の条件で発生ている • ユーザシナリオ ◦ (私の経験的に)コードから追うよりも、ユースケースから 考える方が根本の原因に辿り着きやすく、本質的な 改修に繋がりやすい ◦ ログなどからユーザの動作を追って再現させるのも効果的 Unit Testに追加しやすい Feature Testに追加しやすい
26. [FYI] Androidにおけるテストピラミッド https://developer.android.com/training/testing/fundamentals/strategies
27. [🕰] 問題をrevertする • 問題が発生したcommitはどこ？ ◦ GitHubのtag間の変更/直近のPRを眺める ◦ 差分が巨大な場合には git bisect コマンドを活用する
28. [🕰] 問題をrevertする • git bisect ◦ 二分探索を用いながら、問題が発生したcommitを見つける ◦ https://git-scm.com/docs/git-bisect ◦ git bisect run ./bisect.sh ▪ bisect.sh で、問題を検知できるテストを実行させる ▪ 問題が混入した commit が特定できる
29. [tips] testのコマンドをコピーする • bisect.sh を作成する時にはCLIを使用する
30. [tips] testのコマンドをコピーする • bisect.sh を作成する時にはCLIを使用する $ ./gradlew :app:testDebugUnitTest --tests "com.example.sample.ExampleUnitTest" BUILD SUCCESSFUL in 1s
31. 不具合に関するトピック 1. 不具合を修正して正常にしたい 2. 修正までを短くしたい 3. 類似の不具合の発生を防ぎたい
32. 2: 不具合の検知を早くしたい • anti-pattern ◦ UnitTest、Feature Test、Release Candidate Test等 全てのテストを全てのPRのCIで走らせる
33. 2: 不具合の検知を早くしたい • anti-pattern ◦ UnitTest、Feature Test、Release Candidate Test等 全てのテストを全てのPRのCIで走らせる ◦ マージ/機能リリースまでのリードタイムが長くなる
34. 2: 不具合の検知を早くしたい • anti-pattern ◦ UnitTest、Feature Test、Release Candidate Test等 全てのテストを全てのPRのCIで走らせる ◦ マージ/機能リリースまでのリードタイムが長くなる • 適切なフェーズで適切なテストを行う！
35. [再掲] Androidにおけるテストピラミッド https://developer.android.com/training/testing/fundamentals/strategies
36. 2: 不具合の検知を早くしたい • それぞれのテストでフォーカスするべきこと
37. 2: 不具合の検知を早くしたい • それぞれのテストでフォーカスするべきこと
38. 2: 不具合の検知を早くしたい • それぞれのテストを実施するタイミング・デバイス
39. 2: 不具合の検知を早くしたい • Unit Test で実装漏れを assert できるようにする
40. [tips] [example] UnitTestで実装漏れを検知する • ある enum class に新しい要素が追加されたことを検知する enum class FooKey { A, B, C } val SPECIFIC_PURPOSE_SET: Set<FooKey> = setOf(FooKey.A, FooKey.B)
41. [tips] [example] UnitTestで実装漏れを検知する • ある enum class に新しい要素が追加されたことを検知する enum class FooKey { A, B, C, D } val SPECIFIC_PURPOSE_SET: Set<FooKey> = setOf(FooKey.A, FooKey.B)
42. @Test fun testKeyCompleteness() { val definedKeys = SPECIFIC_PURPOSE_SET + KEYS_NOT_TO_SPECIFIC_PURPOSE_SET FooKey.entries.forEach { assertTrue(it in definedKeys) } } @Test fun testNoDuplicatedKeys() { assertEquals( SPECIFIC_PURPOSE_SET.size + KEYS_NOT_TO_SPECIFIC_PURPOSE_SET.size, FooKey.entries.size ) } companion object { private val KEYS_NOT_TO_SPECIFIC_PURPOSE_SET = setOf( FooKey.C ) }
43. [tips] [example] UnitTestで実装漏れを検知する • (補足) 集合 S を S_1、S_2、...、S_nに分割するときに 素集合となる条件は以下2つを満たすことだから ∀ s ∈ S, ∃ i ( s ∈ S_i ) ∀ i, j, s ∈ S_i ( i ≠ j ⇒ s ∉ S_j )
44. [tips] [example] UnitTestで実装漏れを検知する • (補足) 集合 S を S_1、S_2、...、S_nに分割するときに 素集合となる条件は以下2つを満たすことだから ∀ s ∈ S, ∃ i ( s ∈ S_i ) ∀ i, j, s ∈ S_i ( i ≠ j ⇒ s ∉ S_j ) testKeyCompletenessに対応 testNoDuplicateKeysに対応
45. 不具合に関するトピック 1. 不具合を修正して正常にしたい 2. 修正までを短くしたい 3. 類似の不具合の発生を防ぎたい
46. 3: 類似の問題の発生を防ぐ • 地道にテストピラミッドを充実させていくしかない ◦ これまで紹介した不具合修正とテストの追加を 継続して続ける ◦ 可視化は効果的 • クラッシュ・ANR・アプリサイズなどのAndroid Vitals トレンドを継続的に追う ◦ テストをすり抜けてしまった問題についてもケアする ◦ 修正の際はテストを追加する
47. まとめ • 不具合調査もテストドリブンにできる ◦ 細かなテクニックや分類分けがある • 日々のテスト資産が、不具合発生から修正までの リードタイムを短くする • Testing strategiesのページは必読 ◦ https://developer.android.com/training/testing/fundamentals/strategies • 細かな話は省いているので、ぜひ後ほど
48. 参考 • Testing Strategies https://developer.android.com/training/testing/fundame ntals/strategies • Android Vitals https://developer.android.com/topic/performance/vitals
49. 不具合調査とTest Thank you