Auf dieser Seite wird beschrieben, was mithilfe von Fragmentierung für ein Suite-Modul (AndroidTest.xml) optimiert werden kann, um bei der kontinuierlichen Ausführung im Lab die beste Geschwindigkeit zu erzielen. Wir versuchen, die Optionen allgemein und mit einer Begründung für ihre Verwendung zu beschreiben.
Wenn eine Suite im Lab kontinuierlich ausgeführt wird, wird sie in der Regel auf mehrere Geräte verteilt, um die Gesamtzeit bis zum Abschluss zu verkürzen. Der Harness versucht in der Regel, die Ausführungszeit jedes Shards auszugleichen, um die Gesamtausführungszeit (wenn der letzte Shard fertig ist) zu minimieren. Aufgrund der Art einiger Tests haben wir jedoch nicht immer genügend Informationen und müssen den Modulinhaber bitten, einige Verhaltensweisen anzupassen.
Fragmentierbar oder nicht fragmentierbar?
Sie können ein Modul (AndroidTest.xml) mit <option name="not-shardable" value="true" /> taggen, um den Harness darüber zu informieren, dass es nicht geShardet werden soll.
Bei einem typischen Modul ist es am besten, das Modul vom Harness schardern zu lassen (Standardverhalten). In einigen Fällen möchten Sie dieses Verhalten jedoch überschreiben:
- Wenn die Einrichtung Ihres Moduls teuer ist:
Wenn Sie ein Modul in Shards aufteilen, wird die Vorbereitung (APK installieren, Datei pushen usw.) möglicherweise einmal pro beteiligtem Gerät ausgeführt. Wenn die Moduleinrichtung lang und teuer ist und sich im Vergleich zur Laufzeit des Tests nicht lohnt, sollten Sie das Modul als nicht shardbar taggen.
- Wenn die Anzahl der Tests in Ihrem Modul gering ist:
Wenn Sie ein Modul in Shards aufteilen, werden alle Testfälle möglicherweise unabhängig voneinander auf verschiedenen Geräten ausgeführt. Das hängt mit dem ersten Punkt zusammen: Wenn die Anzahl der Tests gering ist, kann es sein, dass in einigen Shards nur ein Test oder gar kein Test ausgeführt wird. Das würde jeden Vorbereitungsschritt ziemlich teuer machen. Die Installation eines APKs für einen einzelnen Testfall lohnt sich beispielsweise in der Regel nicht.
Instrumentation tests: Max number of shards?
Bei einem Instrumentierungstest, der über AndroidJUnitTest ausgeführt wird, kann das Test-Harnisch erst feststellen, wie viele Tests zur Instrumentierung gehören, bis das APK tatsächlich installiert und ausgeführt wird. Diese Vorgänge sind kostspielig und können nicht zum Zeitpunkt des Shardings für alle Module der Suite ausgeführt werden.
Der Instrumentierungstest könnte den Instrumentierungstest überfrachten und am Ende einige leere Shards zur Folge haben. Ein Fragmentierungstest mit fünf Tests in sechs Shards ergibt fünf Shards mit einem Test und einem Shard ohne Tests. Für jeden dieser Shards wäre eine kostspielige APK-Installation erforderlich.
Wenn die Anzahl der Tests im Instrumentierungstest-APK also niedrig ist, kann das Modul mit <option name="not-shardable" value="true" /> getaggt werden, damit das Harness weiß, dass das Sharding dieses Moduls nicht sinnvoll ist.
Der AndroidJUnitTest-Ausführer hat eine spezielle Option, mit der die maximale Anzahl von Shards angegeben werden kann, in die er gesplittet werden darf: <option name="ajur-max-shard" value="5" />.
Damit können Sie angeben, wie oft die Instrumentierung maximal fragmentiert werden kann, unabhängig von der Anzahl der auf Aufrufebene angeforderten Shards. Standardmäßig wird die Instrumentierung in die Anzahl der für die Aufrufe angeforderten Shards aufgeteilt.
Wenn Ihr Instrumentierungstest-APK beispielsweise nur zwei Testfälle enthält, Sie es aber trotzdem in Shards aufteilen möchten, können Sie mit einem ajur-max-shard-Wert von 2 verhindern, dass leere Shards erstellt werden.