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

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

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

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

สร้างอุปกรณ์เสมือนที่จัดการโดย Gradle

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

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"
        }
      }
    }
  }
}

ดึงดูด

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 และรูปแบบของอุปกรณ์ที่แตกต่างกัน คุณสามารถกำหนดระดับการจัดการด้วย Gradle ได้หลายรายการ อุปกรณ์และเพิ่มลงในกลุ่มที่ตั้งชื่อแล้ว จากนั้น Gradle จะ ทำการทดสอบผ่าน อุปกรณ์ทั้งหมดในกลุ่มพร้อมกัน

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

Kotlin

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

ดึงดูด

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

ทำการทดสอบ

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

บน Windows:

gradlew device-nameBuildVariantAndroidTest

ใน Linux หรือ macOS ให้ทำดังนี้

./gradlew device-nameBuildVariantAndroidTest

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

บน Windows:

gradlew group-nameGroupBuildVariantAndroidTest

ใน Linux หรือ macOS ให้ทำดังนี้

./gradlew group-nameGroupBuildVariantAndroidTest

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

เปิดใช้ทดสอบชาร์ดดิ้ง

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

ในการตั้งค่าจำนวนชาร์ดที่คุณต้องการใช้ในการทดสอบหนึ่งๆ ให้ตั้งค่าพารามิเตอร์ รายการต่อไปนี้ในไฟล์ gradle.properties ของคุณ

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

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

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

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

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

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

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

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"
        }
      }
    }
  }
}

ดึงดูด

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"
        }
      }
    }
  }
}

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

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

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

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

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

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


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

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

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

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

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

ขั้นตอนต่อไปนี้อธิบายวิธีเริ่มใช้อุปกรณ์ Firebase Test Lab ด้วย อุปกรณ์ที่จัดการโดย Gradle โปรดทราบว่าขั้นตอนเหล่านี้ใช้ 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))
}

      ดึงดูด

      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 ที่จำเป็น

    ใน หน้าไลบรารี Google Developers Console API เปิดใช้ 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
}

      ดึงดูด

      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"
}

      ดึงดูด

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

ระบุอุปกรณ์ Test Lab

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

Kotlin

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

ดึงดูด

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

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

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

การทดสอบ Optimize ทำงานด้วยชาร์ดดิ้งอัจฉริยะ

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

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

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 in Flank/Fladle.
       */
      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
  }
}