4.2Mのテストコードが実行される
2年間、テスト結果は保持しておく

関係しているテストを見つける

regression test selection => scheduler => build enqueuer => build queue
=> Massively parallel test backend => build failure retrier => build enqueuer ….
=> test results(マインスイーパのような形でgreen/redを表現)

• 84% of transition from Pass -> Fail are from “Flaky” tests
• only 1.23% of tests ever found a breakage
• 3 or mote developers changes a file is more likely to cause a breakage

• Almost 16% of our 4.2M tests have some some level of flakiness

• flaky tests lead…
  • delay project release
  • consume developer time investigating
  • waste compute resources re=running to confirm

• Test case factors
  • sleep()
  • UI tests
  • and something…
• Code
• execution

• continual rate of 1.5% of test executions reporting a flakiness

• conclution

• re-run failure transitions(10x) to verify flakiness
  • 確認する

• Bazel internal version
  • OSS bazel is removed

• plant系の人

• I18N

  • 1 time(development phase)

• L10N

  • 16 times(for each language)

1. Extracting all texts from resource files
2. Translation by translation service
3. Adjust keyboard shortcuts
4. Include required fonts
5. Generate resource files
6. Perform localization Testing
   • repetitive manual testing by test team and/or local exparts
   • これ系のテストは往々にしてリリースを遅らせたりする。手動だしね。

test script => traversing GUI => Ripping GUI => analysis Rip-Data => generate report => report

What is the “test”?

• approach
  • take screenshots
• observations
  • 何を要素として取るか?
  • large amount of hidden elements

• side by side comparison of screenshots
• list of GUI elements with extracted information <= これ、モバイルアプリに対してできるかな。
  • Webだとtext要素のここは…という感じ
  • mobileだと、例えばAppiumの page で取得される要素を参考に何かできるかな

• ローカライズされていないテキストをハイライトする
• Layout issueも

• performing OCR for extracting texts from screens not reliable
• find scaling problems on high resolution (2k-4k) monitors

http://fmv.jku.at/modbat/ とApache ZooKeeperを使っている

モデルとして、複数の状態を定義(API)し、それに対してテストを実行する。
既存のJUnitベースのApache ZooKeeperのテストコードと比較している。

synchronous, asynchronousの両方を考えている、と。

http://dl.acm.org/citation.cfm?id=2803187&dl=ACM&coll=DL&CFID=911367600&CFTOKEN=38222553

User scenarios + Domain mode + data => Test Cases

• http://www.cc.gatech.edu/~orso/software/barista

• Goal
  • a high likelihood of fault injection
• The Fitness Function for the Job: Search-Based Generation of Test Suites that Detect Real Faults
  Gregory Gay.
  • web屋さんの発表ぽい
• 学習させ、精製したテストがどれだけの類似faultを見つけることに役立つか
  • より効率的な(少ないテストケース数で高いカバレッジを取得する、とか)

• fitness founction
  • 適応度関数

• search based testingの説明とか

• Adithya Nagarajan
  • Apple
  • fuzzing areaとかが主なところ
  • research area
    • AB testing
• Murat Ozturk
  • optimization for development processes
  • flaky testと戦う
  • infrastructure
  • Scale is very important to optimize development processes
  • 世界全体で見ると、どのようにテストすれば良いかわからない(車とか)。だから色々とやる。
• John
• Bao Nguyen