ปรับขนาดการทดสอบด้วยอุปกรณ์ที่จัดการโดยการสร้าง

อุปกรณ์ที่สร้างและจัดการเองช่วยปรับปรุงความสอดคล้อง ประสิทธิภาพ และความน่าเชื่อถือสำหรับการทดสอบที่วัดผลอัตโนมัติ ฟีเจอร์นี้พร้อมใช้งานสำหรับ API ระดับ 27 ขึ้นไป และช่วยให้คุณกำหนดค่าอุปกรณ์ทดสอบเสมือนหรืออุปกรณ์ทดสอบจริงระยะไกลในไฟล์ Gradle ของโปรเจ็กต์ได้ ปลั๊กอิน Android Gradle ใช้การกำหนดค่าเพื่อจัดการอุปกรณ์เหล่านั้นอย่างเต็มรูปแบบ กล่าวคือ สร้าง ทำให้ใช้งานได้ และหยุดทำงาน เมื่อเรียกใช้การทดสอบอัตโนมัติ

ฟีเจอร์นี้ช่วยให้ปลั๊กอิน Android Gradle มองเห็นได้ไม่เพียงแค่การทดสอบที่คุณเรียกใช้ แต่ยังรวมถึงวงจรของอุปกรณ์ด้วย ซึ่งจะช่วยปรับปรุงคุณภาพของประสบการณ์การทดสอบในลักษณะต่อไปนี้

  • จัดการปัญหาเกี่ยวกับอุปกรณ์เพื่อให้แน่ใจว่าการทดสอบจะดำเนินการได้
  • สำหรับอุปกรณ์เสมือน ให้ใช้สแนปชอตของโปรแกรมจำลองเพื่อปรับปรุงเวลาเริ่มต้นของอุปกรณ์ และการใช้งานหน่วยความจำ รวมถึงคืนค่าอุปกรณ์ให้อยู่ในสถานะเริ่มต้นระหว่างการทดสอบ
  • แคชผลการทดสอบและเรียกใช้การทดสอบซ้ำเฉพาะการทดสอบที่มีแนวโน้มที่จะให้ผลลัพธ์ที่แตกต่างกัน
  • จัดเตรียมสภาพแวดล้อมที่สอดคล้องกันสำหรับการเรียกใช้การทดสอบระหว่างการทดสอบในเครื่องและการทดสอบระยะไกล

สร้างอุปกรณ์เสมือนที่สร้างขึ้นและมีการจัดการ

คุณสามารถระบุอุปกรณ์เสมือนที่ต้องการใช้ทดสอบแอปในไฟล์บิลด์ระดับโมดูลได้ ตัวอย่างโค้ดต่อไปนี้สร้าง Pixel 2 ที่ใช้ API ระดับ 30 เป็นอุปกรณ์ที่จัดการโดยการสร้าง

Kotlin

android {
  testOptions {
    managedDevices {
      localDevices {
        create("pixel2api30") {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // Use only API levels 27 and higher.
          apiLevel = 30
          // To include Google services, use "google".
          systemImageSource = "aosp"
        }
      }
    }
  }
}

Groovy

android {
  testOptions {
    managedDevices {
      localDevices {
        pixel2api30 {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // Use only API levels 27 and higher.
          apiLevel = 30
          // To include Google services, use "google".
          systemImageSource = "aosp"
        }
      }
    }
  }
}

กำหนดกลุ่มอุปกรณ์

คุณสามารถกำหนดอุปกรณ์ที่มีการจัดการบิลด์หลายเครื่องและเพิ่มลงในกลุ่มที่มีชื่อเพื่อช่วยให้คุณปรับขนาดการทดสอบในอุปกรณ์หลายการกำหนดค่า เช่น ระดับ API และรูปแบบที่แตกต่างกัน จากนั้นปลั๊กอิน Android Gradle จะ เรียกใช้การทดสอบในอุปกรณ์ทั้งหมดในกลุ่มแบบขนานได้

ตัวอย่างด้านล่างแสดงอุปกรณ์ 2 เครื่องที่เพิ่มลงในกลุ่มอุปกรณ์ชื่อ phoneAndTablet

Kotlin

testOptions {
  managedDevices {
    localDevices {
      create("pixel2api29") { ... }
      create("nexus9api30") { ... }
    }
    groups {
      create("phoneAndTablet") {
        targetDevices.add(devices["pixel2api29"])
        targetDevices.add(devices["nexus9api30"])
      }
    }
  }
}

Groovy

testOptions {
  managedDevices {
    localDevices {
      pixel2api29 { ... }
      nexus9api30 { ... }
    }
    groups {
      phoneAndTablet {
        targetDevices.add(devices.pixel2api29)
        targetDevices.add(devices.nexus9api30)
      }
    }
  }
}

ทำการทดสอบ

หากต้องการเรียกใช้การทดสอบโดยใช้อุปกรณ์ที่สร้างขึ้นซึ่งคุณกำหนดค่าไว้ ให้ใช้คำสั่งต่อไปนี้ device-name คือชื่อของอุปกรณ์ที่คุณกำหนดค่าไว้ใน สคริปต์ Gradle Build (เช่น pixel2api30) และ BuildVariant คือ ตัวแปรบิลด์ของแอปที่คุณต้องการทดสอบ เช่น Debug

Linux และ macOS

./gradlew device-nameBuildVariantAndroidTest

Windows

gradlew device-nameBuildVariantAndroidTest

หากต้องการเรียกใช้การทดสอบในกลุ่มอุปกรณ์ที่จัดการโดยการสร้าง ให้ใช้คำสั่งต่อไปนี้

Linux และ macOS

./gradlew group-nameGroupBuildVariantAndroidTest

./gradlew group-nameGroupBuildVariantAndroidTest

Windows

gradlew group-nameGroupBuildVariantAndroidTest

เอาต์พุตการทดสอบจะมีเส้นทางไปยังไฟล์ HTML ที่มีรายงานการทดสอบ นอกจากนี้ คุณยังนำเข้าผลการทดสอบไปยัง Android Studio เพื่อวิเคราะห์เพิ่มเติมได้โดยคลิกเรียกใช้ > ประวัติการทดสอบใน IDE

เปิดใช้การแบ่งพาร์ติชันการทดสอบ

อุปกรณ์ที่สร้างโดย Build รองรับการแบ่งการทดสอบ ซึ่งช่วยให้คุณแยกชุดการทดสอบ ออกเป็นอินสแตนซ์อุปกรณ์เสมือนที่เหมือนกันหลายอินสแตนซ์ที่เรียกว่าชาร์ด ซึ่งทำงานแบบขนาน การใช้การแบ่งการทดสอบออกเป็นส่วนๆ จะช่วยลดเวลาในการดำเนินการทดสอบโดยรวมได้ โดยต้องใช้ทรัพยากรการคำนวณเพิ่มเติม

หากต้องการกำหนดจำนวน Shard ที่ต้องการใช้ในการทดสอบที่กำหนด ให้ตั้งค่า ต่อไปนี้ในไฟล์ gradle.properties

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

เมื่อทำการทดสอบโดยใช้ตัวเลือกนี้ อุปกรณ์ที่จัดการโดยบิลด์จะจัดสรร จำนวน Shard ที่คุณระบุสำหรับโปรไฟล์อุปกรณ์แต่ละรายการในการทดสอบ ดังนั้น ตัวอย่างเช่น หากคุณทดสอบในกลุ่มอุปกรณ์ที่มีอุปกรณ์ 3 เครื่องและตั้งค่า numManagedDeviceShards เป็น 2 อุปกรณ์ที่มีการจัดการบิลด์จะจัดสรรอุปกรณ์เสมือนทั้งหมด 6 เครื่องสำหรับการทดสอบ

เมื่อการทดสอบเสร็จสมบูรณ์ Gradle จะแสดงผลการทดสอบในไฟล์ .proto สำหรับแต่ละ Shard ที่ใช้ในการทดสอบ

ใช้อุปกรณ์ทดสอบอัตโนมัติ

อุปกรณ์ที่สร้างและจัดการรองรับอุปกรณ์จำลองประเภทหนึ่งที่เรียกว่าอุปกรณ์ทดสอบอัตโนมัติ (ATD) ซึ่งได้รับการเพิ่มประสิทธิภาพเพื่อลดทรัพยากร CPU และหน่วยความจำเมื่อเรียกใช้การทดสอบที่วัดประสิทธิภาพ ATD ช่วยปรับปรุงประสิทธิภาพขณะรันไทม์ได้หลายวิธี ดังนี้

  • นำแอปที่ติดตั้งไว้ล่วงหน้าซึ่งมักจะไม่มีประโยชน์ในการทดสอบแอปออก
  • ปิดใช้บริการในเบื้องหลังบางอย่างซึ่งโดยปกติแล้วจะไม่มีประโยชน์ต่อ การทดสอบแอป
  • ปิดใช้การแสดงผลฮาร์ดแวร์

ก่อนเริ่มต้นใช้งาน โปรดอัปเดตโปรแกรมจำลอง Android เป็นเวอร์ชันล่าสุด ที่พร้อมใช้งาน จากนั้นระบุรูปภาพ "-atd" เมื่อกำหนดอุปกรณ์ที่บิลด์จัดการ ในไฟล์บิลด์ระดับโมดูล ดังที่แสดงด้านล่าง

Kotlin

android {
  testOptions {
    managedDevices {
      localDevices {
        create("pixel2api30") {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // ATDs currently support only API level 30.
          apiLevel = 30
          // You can also specify "google-atd" if you require Google Play Services.
          systemImageSource = "aosp-atd"
        }
      }
    }
  }
}

Groovy

android {
  testOptions {
    managedDevices {
      localDevices {
        pixel2api30 {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // ATDs currently support only API level 30.
          apiLevel = 30
          // You can also specify "google-atd" if you require Google Play Services.
          systemImageSource = "aosp-atd"
        }
      }
    }
  }
}

นอกจากนี้ คุณยังสร้างกลุ่มอุปกรณ์ได้เช่นเดียวกับอุปกรณ์อื่นๆ ที่มีการจัดการที่สร้างขึ้นเอง นอกจากนี้ คุณยังใช้ ATD กับการแบ่งการทดสอบเพื่อลดเวลาการดำเนินการทดสอบทั้งหมดของชุดการทดสอบได้ด้วย เพื่อใช้ประโยชน์จากการปรับปรุงประสิทธิภาพให้ดียิ่งขึ้น

ระบบนำอะไรออกจากรูปภาพ ATD

นอกจากจะทำงานในโหมดไม่มีส่วนหัวแล้ว ATD ยังเพิ่มประสิทธิภาพด้วยการ นำออกหรือปิดใช้แอปและบริการที่ไม่จำเป็นสำหรับการ ทดสอบโค้ดของแอป ตารางด้านล่างแสดงภาพรวมของคอมโพเนนต์ ที่เรานำออกหรือปิดใช้ในรูปภาพ ATD และคำอธิบายว่าเหตุใดคอมโพเนนต์เหล่านั้นจึงอาจไม่ มีประโยชน์

สิ่งที่ถูกนำออกในรูปภาพ ATD เหตุผลที่คุณอาจไม่จำเป็นต้องใช้เมื่อเรียกใช้การทดสอบอัตโนมัติ
แอปผลิตภัณฑ์ของ Google
  • อีเมล
  • แผนที่
  • Chrome
  • ข้อความ
  • Play Store และอื่นๆ
 การทดสอบอัตโนมัติควรเน้นที่ตรรกะของแอปของคุณเองโดยตั้งสมมติฐาน ว่าแอปอื่นๆ หรือแพลตฟอร์มจะทำงานได้อย่างถูกต้อง

Espresso-Intents ช่วยให้คุณจับคู่และตรวจสอบ Intent ขาออก หรือแม้แต่ระบุการตอบกลับแบบ Stub แทนการตอบกลับ Intent จริงได้

การตั้งค่าแอปและบริการ
  • CarrierConfig
  • EmergencyInfo
  • OneTimeInitializer
  • PhotoTable (ภาพพักหน้าจอ)
  • จัดเตรียม
  • แอปการตั้งค่า
  • StorageManager
  • การกำหนดค่า APN ของโทรศัพท์
  • WallpaperCropper
  • WallpaperPicker
 แอปเหล่านี้มี GUI สำหรับผู้ใช้ปลายทางเพื่อเปลี่ยนการตั้งค่าแพลตฟอร์ม ตั้งค่าอุปกรณ์ หรือจัดการพื้นที่เก็บข้อมูลของอุปกรณ์ โดยปกติแล้วจะอยู่นอกขอบเขตของการทดสอบอัตโนมัติระดับแอป


หมายเหตุ: ผู้ให้บริการการตั้งค่า ยังคงมีอยู่ในรูปภาพ ATD

อินเทอร์เฟซผู้ใช้ของระบบ การทดสอบอัตโนมัติควรเน้นที่ตรรกะของแอปของคุณเองโดยตั้งสมมติฐาน ว่าแอปอื่นๆ หรือแพลตฟอร์มจะทำงานได้อย่างถูกต้อง
แอปและบริการ AOSP:
  • Browser2
  • ปฏิทิน
  • Camera2
  • รายชื่อติดต่อ
  • Dialer
  • DeskClock
  • แกลเลอรี 2
  • LatinIME
  • Launcher3QuickStep
  • ดนตรี
  • QuickSearchBox
  • SettingsIntelligence
 โดยปกติแล้ว แอปและบริการเหล่านี้จะอยู่นอกขอบเขตของการทดสอบอัตโนมัติสำหรับโค้ดของแอป

ใช้อุปกรณ์ Firebase Test Lab

คุณสามารถเรียกใช้การทดสอบเครื่องมืออัตโนมัติได้ในอุปกรณ์ Firebase Test Lab เมื่อใช้อุปกรณ์ที่สร้างขึ้น Test Lab ช่วยให้คุณเรียกใช้การทดสอบพร้อมกันในอุปกรณ์ Android หลากหลายประเภท ทั้งอุปกรณ์จริงและอุปกรณ์เสมือน การทดสอบเหล่านี้จะทำงานในศูนย์ข้อมูลของ Google ที่อยู่ระยะไกล ด้วยการรองรับจากอุปกรณ์ที่สร้างและจัดการแล้ว ระบบบิลด์จะจัดการการทดสอบที่เรียกใช้กับอุปกรณ์ Test Lab เหล่านี้ได้อย่างเต็มที่ตามการกำหนดค่าของคุณ

เริ่มต้นใช้งาน

ขั้นตอนต่อไปนี้จะอธิบายวิธีเริ่มใช้อุปกรณ์ Firebase Test Lab กับ อุปกรณ์ที่จัดการโดยบิลด์ ขั้นตอนเหล่านี้ใช้ gcloud CLI เพื่อระบุข้อมูลเข้าสู่ระบบของผู้ใช้ ซึ่งอาจใช้ไม่ได้กับสภาพแวดล้อมการพัฒนาบางอย่าง ดูข้อมูลเพิ่มเติมเกี่ยวกับกระบวนการตรวจสอบสิทธิ์ที่ควรใช้สำหรับความต้องการของคุณได้ที่วิธี การทำงานของข้อมูลรับรองเริ่มต้นของแอปพลิเคชัน

  1. หากต้องการสร้างโปรเจ็กต์ Firebase ให้ไปที่คอนโซล Firebase คลิกเพิ่มโปรเจ็กต์ แล้วทำตามข้อความแจ้งบนหน้าจอเพื่อสร้างโปรเจ็กต์ จดรหัสโปรเจ็กต์ของคุณ

  2. หากต้องการติดตั้ง Google Cloud CLI ให้ทำตามขั้นตอนที่ ติดตั้ง gcloud CLI

  3. กำหนดค่าสภาพแวดล้อมในเครื่อง

    1. ลิงก์กับโปรเจ็กต์ Firebase ใน gcloud โดยทำดังนี้

      gcloud config set project FIREBASE_PROJECT_ID

    2. ให้สิทธิ์การใช้ข้อมูลเข้าสู่ระบบของผู้ใช้สำหรับการเข้าถึง API เราขอแนะนำให้ ให้สิทธิ์โดยส่งไฟล์ JSON ของบัญชีบริการไปยัง Gradle โดยใช้ DSL ในสคริปต์บิลด์ระดับโมดูล ดังนี้

      Kotlin

      firebaseTestLab {
  ...
  serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE))
}

      Groovy

      firebaseTestLab {
  ...
  serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE)
}

      หรือคุณจะให้สิทธิ์ด้วยตนเองโดยใช้คำสั่งต่อไปนี้ในเทอร์มินัลก็ได้ 

      gcloud auth application-default login

    3. ไม่บังคับ: เพิ่มโปรเจ็กต์ Firebase เป็นโปรเจ็กต์โควต้า ขั้นตอนนี้จำเป็นเฉพาะในกรณีที่คุณใช้โควต้าแบบไม่มีค่าใช้จ่ายสำหรับ Test Lab เกิน

      gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID

  4. เปิดใช้ API ที่จำเป็น

    ในหน้าคลัง API ของ Google Developers Console ให้เปิดใช้ Cloud Testing API และ Cloud Tool Results API โดยพิมพ์ชื่อ API เหล่านี้ลงในช่องค้นหาที่ด้านบนของคอนโซล แล้วคลิกเปิดใช้ API ในหน้าภาพรวมของ API แต่ละรายการ

  5. กำหนดค่าโปรเจ็กต์ Android

    1. เพิ่มปลั๊กอิน Firebase Test Lab ในสคริปต์บิลด์ระดับบนสุด

      Kotlin

      plugins {
  ...
  id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false
}

      Groovy

      plugins {
  ...
  id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false
}

    2. เปิดใช้ประเภทอุปกรณ์ที่กำหนดเองในไฟล์ gradle.properties ดังนี้

      android.experimental.testOptions.managedDevices.customDevice=true

    3. เพิ่มปลั๊กอิน Firebase Test Lab ในสคริปต์บิลด์ระดับโมดูล

      Kotlin

      plugins {
 ...
 id "com.google.firebase.testlab"
}

      Groovy

      plugins {
 ...
 id 'com.google.firebase.testlab'
}

ระบุอุปกรณ์ในห้องทดสอบ

คุณระบุอุปกรณ์ Firebase Test Lab ให้ Gradle ใช้ทดสอบแอปในสคริปต์บิลด์ระดับโมดูลได้ ตัวอย่างโค้ดต่อไปนี้สร้าง Pixel 3 ที่ใช้ API ระดับ 30 เป็นอุปกรณ์ Test Lab ที่มีการจัดการบิลด์ชื่อ ftlDevice บล็อก firebaseTestLab {} จะพร้อมใช้งานเมื่อคุณใช้ปลั๊กอิน com.google.firebase.testlab กับโมดูล

Kotlin

firebaseTestLab {
  managedDevices {
    create("ftlDevice") {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

Groovy

firebaseTestLab {
  managedDevices {
    ftlDevice {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

หากต้องการกำหนดกลุ่มอุปกรณ์ที่สร้างและจัดการ รวมถึงอุปกรณ์ Firebase Test Lab โปรดดูกำหนดกลุ่มอุปกรณ์

หากต้องการเรียกใช้การทดสอบ ให้ใช้คำสั่งเดียวกันกับที่ใช้เรียกใช้อุปกรณ์อื่นๆ ที่มีการจัดการบิลด์ โปรดทราบว่า Gradle ไม่ได้เรียกใช้การทดสอบแบบขนานหรือรองรับ การกำหนดค่า Google Cloud CLI อื่นๆ สำหรับอุปกรณ์ Test Lab

เพิ่มประสิทธิภาพการทดสอบด้วยการแบ่งพาร์ติชันอัจฉริยะ

การทดสอบในอุปกรณ์ Test Lab ที่มีการจัดการบิลด์รองรับการแบ่งกลุ่มอัจฉริยะ การแบ่งพาร์ติชันอัจฉริยะ จะกระจายการทดสอบไปยังพาร์ติชันต่างๆ โดยอัตโนมัติเพื่อให้แต่ละพาร์ติชัน ทำงานในเวลาที่ใกล้เคียงกัน ซึ่งจะช่วยลดความพยายามในการจัดสรรด้วยตนเองและ ระยะเวลาการทดสอบโดยรวม การแบ่งกลุ่มอัจฉริยะจะใช้ประวัติการทดสอบหรือข้อมูล เกี่ยวกับระยะเวลาที่ใช้ในการทดสอบก่อนหน้านี้เพื่อกระจายการทดสอบใน วิธีที่เหมาะสมที่สุด โปรดทราบว่าคุณต้องใช้ปลั๊กอิน Gradle เวอร์ชัน 0.0.1-alpha05 สำหรับ Firebase Test Lab เพื่อใช้การแบ่งกลุ่มอัจฉริยะ

หากต้องการเปิดใช้การแบ่งชาร์ดอัจฉริยะ ให้ระบุระยะเวลาที่การทดสอบภายในแต่ละชาร์ด ควรใช้ คุณควรกำหนดระยะเวลาของชาร์ดเป้าหมายให้น้อยกว่า timeoutMinutes อย่างน้อย 5 นาทีเพื่อหลีกเลี่ยงสถานการณ์ที่ชาร์ดถูกยกเลิกก่อนที่การทดสอบจะเสร็จสิ้น

firebaseTestLab {
  ...
  testOptions {
    targetedShardDurationMinutes = 2
  }
}

ดูข้อมูลเพิ่มเติมได้ที่หัวข้อเกี่ยวกับ ตัวเลือก DSL ของอุปกรณ์ Firebase Test Lab

อัปเดต DSL สำหรับอุปกรณ์ Test Lab

นอกจากนี้ ยังมีตัวเลือก DSL อื่นๆ ที่คุณกำหนดค่าได้เพื่อช่วยปรับแต่งการทดสอบหรือ ย้ายข้อมูลจากโซลูชันอื่นๆ ที่คุณอาจใช้อยู่แล้ว ดูตัวเลือกบางส่วนเหล่านี้ ตามที่อธิบายไว้ในข้อมูลโค้ดต่อไปนี้

firebaseTestLab {
  ...

  /**
   * A path to a JSON file that contains service account credentials to access to
   * a Firebase Test Lab project.
   */
  serviceAccountCredentials.set(file("your_service_account_credentials.json"))


  testOptions {
    fixture {
      /**
       * Whether to grant permissions on the device before tests begin.
       * Available options are "all" or "none".
       *
       * Default value is "all".
       */
      grantedPermissions = "all"

      /**
       * Map of files to push to the device before starting the test.
       *
       * The key is the location on the device.
       * The value is the location of the file, either local or in Google Cloud.
       */
      extraDeviceFiles["/sdcard/dir1/file1.txt"] = "local/file.txt"
      extraDeviceFiles["/sdcard/dir2/file2.txt"] = "gs://bucket/file.jpg"

      /**
       * The name of the network traffic profile.
       *
       * Specifies network conditions to emulate when running tests.
       *
       * Default value is empty.
       */
      networkProfile = "LTE"
    }

    execution {
      /**
       * The maximum time to run the test execution before cancellation,
       * measured in minutes. Does not include the setup or teardown of device,
       * and is handled server-side.
       *
       * The maximum possible testing time is 45 minutes on physical devices
       * and 60 minutes on virtual devices.
       *
       * Defaults to 15 minutes.
       */
       timeoutMinutes = 30

      /**
       * Number of times the test should be rerun if tests fail.
       * The number of times a test execution should be retried if one
       * or more of its test cases fail.
       *
       * The max number of times is 10.
       *
       * The default number of times is 0.
       */
      maxTestReruns = 2

      /**
       * Ensures only a single attempt is made for each execution if
       * an infrastructure issue occurs. This doesn't affect `maxTestReruns`.
       * Normally, two or more attempts are made by Firebase Test Lab if a
       * potential infrastructure issue is detected. This is best enabled for
       * latency sensitive workloads. The number of execution failures might be
       * significantly greater with `failFast` enabled.
       *
       * Defaults to false.
       */
      failFast = false

      /**
       * The number of shards to split the tests across.
       *
       * Default to 0 for no sharding.
       */
      numUniformShards = 20
    }

    /**
     * For smart sharding, the target length of time each shard should takes in
     * minutes. Maxes out at 50 shards for physical devices and 100 shards for
     * virtual devices.
     *
     * Only one of numUniformShards or targetedShardDurationMinutes can be set.
     *
     * Defaults to 0 for no smart sharding.
     */
     targetedShardDurationMinutes = 15
    }

    results {
      /**
       * The name of the Google storage bucket to store the test results in.
       *
       * If left unspecified, the default bucket is used.
       *
       * Please refer to Firebase Test Lab permissions for required permissions
       * for using the bucket.
       */
      cloudStorageBucket = "bucketLocationName"

      /**
       * Name of test results for the Firebase console history list.
       * All tests results with the same history name are grouped
       * together in the Firebase console in a time-ordered test history list.
       *
       * Defaults to the application label in the APK manifest.
       */
      resultsHistoryName = "application-history"

      /**
       * List of paths to copy from the test device's storage to the test
       * results folder. These must be absolute paths under /sdcard or
       * /data/local/tmp.
       */
      directoriesToPull.addAll(
        "/sdcard/path/to/something"
      )

      /**
       * Whether to enable video recording during the test.
       *
       * Disabled by default.
       */
      recordVideo = false

      /**
       * Whether to enable performance metrics. If enabled, monitors and records
       * performance metrics such as CPU, memory, and network usage.
       *
       * Defaults to false.
       */
      performanceMetrics = true
  }
}