عند كتابة عداء اختبار ، من المهم التفكير في قابلية التوسع. اسأل نفسك ، "إذا اضطر عداء الاختبار الخاص بي إلى إجراء 200 ألف حالة اختبار" ، فما المدة التي سيستغرقها ذلك؟
المشاركة هي إحدى الإجابات المتوفرة في "الاتحاد التجاري". يتطلب تقسيم جميع الاختبارات التي يحتاجها العداء إلى عدة أجزاء يمكن موازنتها.
تصف هذه الصفحة كيفية جعل العداء الخاص بك قابلاً للتجزئة من أجل Tradefed.
واجهة للتنفيذ
الواجهة الوحيدة الأكثر أهمية التي يجب تنفيذها لتكون قابلة للتجزئة بواسطة TF هي IShardableTest ، والتي تحتوي على طريقتين: split(int numShard)
و split()
.
إذا كانت التجزئة الخاصة بك ستعتمد على عدد الأجزاء المطلوبة ، فيجب عليك تنفيذ split(int numShard)
. خلاف ذلك ، قم بتنفيذ split()
.
عند تنفيذ أمر اختبار TF باستخدام معلمات التجزئة --shard-count
و --shard-index
، يتكرر TF عبر جميع IRemoteTest
للبحث عن تلك التي تنفذ IShardableTest
. إذا تم العثور عليه ، فسيتم استدعاء split
للحصول على كائن IRemoteTest
جديد لتشغيل مجموعة فرعية من حالات الاختبار لجزء معين.
ما الذي يجب أن أعرفه عن تطبيق الانقسام؟
- يجوز للعدّاء أن يتشاجر عند بعض الشروط فقط ؛ في هذه الحالة ، يتم إرجاع
null
عندما لا تكون جزءًا. - حاول أن تقسم بقدر ما هو منطقي: قسّم العداء الخاص بك إلى وحدة تنفيذ منطقية بالنسبة له. انها حقا تعتمد على عداء الخاص بك. على سبيل المثال: يتم تجزئة HostTest على مستوى الفصل ، ويتم وضع كل فئة اختبار في جزء منفصل.
- إذا كان ذلك منطقيًا ، أضف بعض الخيارات للتحكم في التجزئة قليلاً. على سبيل المثال: يحتوي AndroidJUnitTest على
ajur-max-shard
لتحديد الحد الأقصى لعدد الأجزاء التي يمكن تقسيمها ، بغض النظر عن العدد المطلوب.
مثال مفصل للتنفيذ
فيما يلي مثال على مقتطف الشفرة الذي يستخدم IShardableTest
الذي يمكنك الرجوع إليه. الكود الكامل متاح على (https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/main/test_framework/com/android/tradefed/testtype/InstalledInstrumentationsTest.java)
/**
* Runs all instrumentation found on current device.
*/
@OptionClass(alias = "installed-instrumentation")
public class InstalledInstrumentationsTest
implements IDeviceTest, IResumableTest, IShardableTest {
...
/** {@inheritDoc} */
@Override
public Collection<IRemoteTest> split(int shardCountHint) {
if (shardCountHint > 1) {
Collection<IRemoteTest> shards = new ArrayList<>(shardCountHint);
for (int index = 0; index < shardCountHint; index++) {
shards.add(getTestShard(shardCountHint, index));
}
return shards;
}
// Nothing to shard
return null;
}
private IRemoteTest getTestShard(int shardCount, int shardIndex) {
InstalledInstrumentationsTest shard = new InstalledInstrumentationsTest();
try {
OptionCopier.copyOptions(this, shard);
} catch (ConfigurationException e) {
CLog.e("failed to copy instrumentation options: %s", e.getMessage());
}
shard.mShardIndex = shardIndex;
shard.mTotalShards = shardCount;
return shard;
}
...
}
يقوم هذا المثال ببساطة بإنشاء مثيل جديد لنفسه وتعيين معلمات جزء له. ومع ذلك ، يمكن أن يكون منطق التقسيم مختلفًا تمامًا من اختبار إلى آخر ؛ وطالما أنها حتمية وتنتج مجموعات فرعية شاملة بشكل جماعي ، فلا بأس بذلك.
استقلال
يجب أن تكون الشظايا مستقلة! يجب ألا يكون للجزءين اللذين تم إنشاؤهما من خلال تطبيقك split
في العداء الخاص بك تبعيات على بعضهما البعض أو مشاركة الموارد.
يجب أن يكون تقسيم الشظايا أمرًا حتميًا! هذا أيضًا إلزامي ، نظرًا لنفس الشروط ، يجب أن تُرجع طريقة split
دائمًا نفس قائمة القطع بالترتيب نفسه.
ملاحظة: نظرًا لأنه يمكن تشغيل كل جزء على مثيلات مختلفة من TF ، فمن الأهمية بمكان التأكد من أن منطق split
ينتج مجموعات فرعية متنافية وشاملة بشكل جماعي بطريقة حتمية.
قم بإجراء اختبار محليًا
لتقسيم اختبار على TF محلي ، يمكنك ببساطة إضافة خيار --shard-count
إلى سطر الأوامر.
tf >run host --class com.android.tradefed.UnitTests --shard-count 3
ثم يقوم TF تلقائيًا بتوليد الأوامر لكل جزء وتشغيلها.
tf >l i
Command Id Exec Time Device State
3 0m:03 [null-device-2] running stub on build 0 (shard 1 of 3)
3 0m:03 [null-device-1] running stub on build 0 (shard 0 of 3)
3 0m:03 [null-device-3] running stub on build 0 (shard 2 of 3)
تجميع نتائج الاختبار
نظرًا لأن فريق العمل لا يقوم بأي تجميع لنتائج الاختبار للاستدعاءات المجزأة ، فأنت بحاجة إلى التأكد من دعم خدمة إعداد التقارير لديك.
وعند كتابة عداء اختبار ، من المهم التفكير في قابلية التوسع. اسأل نفسك ، "إذا اضطر عداء الاختبار الخاص بي إلى إجراء 200 ألف حالة اختبار" ، فما المدة التي سيستغرقها ذلك؟
المشاركة هي إحدى الإجابات المتوفرة في "الاتحاد التجاري". يتطلب تقسيم جميع الاختبارات التي يحتاجها العداء إلى عدة أجزاء يمكن موازنتها.
تصف هذه الصفحة كيفية جعل العداء الخاص بك قابلاً للتجزئة من أجل Tradefed.
واجهة للتنفيذ
الواجهة الوحيدة الأكثر أهمية التي يجب تنفيذها لتكون قابلة للتجزئة بواسطة TF هي IShardableTest ، والتي تحتوي على طريقتين: split(int numShard)
و split()
.
إذا كانت التجزئة الخاصة بك ستعتمد على عدد الأجزاء المطلوبة ، فيجب عليك تنفيذ split(int numShard)
. خلاف ذلك ، قم بتنفيذ split()
.
عند تنفيذ أمر اختبار TF باستخدام معلمات التجزئة --shard-count
و --shard-index
، يتكرر TF عبر جميع IRemoteTest
للبحث عن تلك التي تنفذ IShardableTest
. إذا تم العثور عليه ، فسيتم استدعاء split
للحصول على كائن IRemoteTest
جديد لتشغيل مجموعة فرعية من حالات الاختبار لجزء معين.
ما الذي يجب أن أعرفه عن تطبيق الانقسام؟
- يجوز للعدّاء أن يتشاجر عند بعض الشروط فقط ؛ في هذه الحالة ، يتم إرجاع
null
عندما لا تكون جزءًا. - حاول أن تقسم بقدر ما هو منطقي: قسّم العداء الخاص بك إلى وحدة تنفيذ منطقية بالنسبة له. انها حقا تعتمد على عداء الخاص بك. على سبيل المثال: يتم تجزئة HostTest على مستوى الفصل ، ويتم وضع كل فئة اختبار في جزء منفصل.
- إذا كان ذلك منطقيًا ، أضف بعض الخيارات للتحكم في التجزئة قليلاً. على سبيل المثال: يحتوي AndroidJUnitTest على
ajur-max-shard
لتحديد الحد الأقصى لعدد الأجزاء التي يمكن تقسيمها ، بغض النظر عن العدد المطلوب.
مثال مفصل للتنفيذ
فيما يلي مثال على مقتطف الشفرة الذي يستخدم IShardableTest
الذي يمكنك الرجوع إليه. الكود الكامل متاح على (https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/main/test_framework/com/android/tradefed/testtype/InstalledInstrumentationsTest.java)
/**
* Runs all instrumentation found on current device.
*/
@OptionClass(alias = "installed-instrumentation")
public class InstalledInstrumentationsTest
implements IDeviceTest, IResumableTest, IShardableTest {
...
/** {@inheritDoc} */
@Override
public Collection<IRemoteTest> split(int shardCountHint) {
if (shardCountHint > 1) {
Collection<IRemoteTest> shards = new ArrayList<>(shardCountHint);
for (int index = 0; index < shardCountHint; index++) {
shards.add(getTestShard(shardCountHint, index));
}
return shards;
}
// Nothing to shard
return null;
}
private IRemoteTest getTestShard(int shardCount, int shardIndex) {
InstalledInstrumentationsTest shard = new InstalledInstrumentationsTest();
try {
OptionCopier.copyOptions(this, shard);
} catch (ConfigurationException e) {
CLog.e("failed to copy instrumentation options: %s", e.getMessage());
}
shard.mShardIndex = shardIndex;
shard.mTotalShards = shardCount;
return shard;
}
...
}
يقوم هذا المثال ببساطة بإنشاء مثيل جديد لنفسه وتعيين معلمات جزء له. ومع ذلك ، يمكن أن يكون منطق التقسيم مختلفًا تمامًا من اختبار إلى آخر ؛ وطالما أنها حتمية وتنتج مجموعات فرعية شاملة بشكل جماعي ، فلا بأس بذلك.
استقلال
يجب أن تكون الشظايا مستقلة! يجب ألا يكون للجزءين اللذين تم إنشاؤهما من خلال تطبيقك split
في العداء الخاص بك تبعيات على بعضهما البعض أو مشاركة الموارد.
يجب أن يكون تقسيم الشظايا أمرًا حتميًا! هذا أيضًا إلزامي ، نظرًا لنفس الشروط ، يجب أن تُرجع طريقة split
دائمًا نفس قائمة القطع بالترتيب نفسه.
ملاحظة: نظرًا لأنه يمكن تشغيل كل جزء على مثيلات مختلفة من TF ، فمن الأهمية بمكان التأكد من أن منطق split
ينتج مجموعات فرعية متنافية وشاملة بشكل جماعي بطريقة حتمية.
قم بإجراء اختبار محليًا
لتقسيم اختبار على TF محلي ، يمكنك ببساطة إضافة خيار --shard-count
إلى سطر الأوامر.
tf >run host --class com.android.tradefed.UnitTests --shard-count 3
ثم يقوم TF تلقائيًا بتوليد الأوامر لكل جزء وتشغيلها.
tf >l i
Command Id Exec Time Device State
3 0m:03 [null-device-2] running stub on build 0 (shard 1 of 3)
3 0m:03 [null-device-1] running stub on build 0 (shard 0 of 3)
3 0m:03 [null-device-3] running stub on build 0 (shard 2 of 3)
تجميع نتائج الاختبار
نظرًا لأن فريق العمل لا يقوم بأي تجميع لنتائج الاختبار للاستدعاءات المجزأة ، فأنت بحاجة إلى التأكد من دعم خدمة إعداد التقارير لديك.
وعند كتابة عداء اختبار ، من المهم التفكير في قابلية التوسع. اسأل نفسك ، "إذا اضطر عداء الاختبار الخاص بي إلى إجراء 200 ألف حالة اختبار" ، فما المدة التي سيستغرقها ذلك؟
المشاركة هي إحدى الإجابات المتوفرة في "الاتحاد التجاري". يتطلب تقسيم جميع الاختبارات التي يحتاجها العداء إلى عدة أجزاء يمكن موازنتها.
تصف هذه الصفحة كيفية جعل العداء الخاص بك قابلاً للتجزئة من أجل Tradefed.
واجهة للتنفيذ
الواجهة الوحيدة الأكثر أهمية التي يجب تنفيذها لتكون قابلة للتجزئة بواسطة TF هي IShardableTest ، والتي تحتوي على طريقتين: split(int numShard)
و split()
.
إذا كانت التجزئة الخاصة بك ستعتمد على عدد الأجزاء المطلوبة ، فيجب عليك تنفيذ split(int numShard)
. خلاف ذلك ، قم بتنفيذ split()
.
عند تنفيذ أمر اختبار TF باستخدام معلمات التجزئة --shard-count
و --shard-index
، يتكرر TF عبر جميع IRemoteTest
للبحث عن تلك التي تنفذ IShardableTest
. إذا تم العثور عليه ، فسيتم استدعاء split
للحصول على كائن IRemoteTest
جديد لتشغيل مجموعة فرعية من حالات الاختبار لجزء معين.
ما الذي يجب أن أعرفه عن تطبيق الانقسام؟
- يجوز للعدّاء أن يتشاجر عند بعض الشروط فقط ؛ في هذه الحالة ، يتم إرجاع
null
عندما لا تكون جزءًا. - حاول أن تقسم بقدر ما هو منطقي: قسّم العداء الخاص بك إلى وحدة تنفيذ منطقية بالنسبة له. انها حقا تعتمد على عداء الخاص بك. على سبيل المثال: يتم تجزئة HostTest على مستوى الفصل ، ويتم وضع كل فئة اختبار في جزء منفصل.
- إذا كان ذلك منطقيًا ، أضف بعض الخيارات للتحكم في التجزئة قليلاً. على سبيل المثال: يحتوي AndroidJUnitTest على
ajur-max-shard
لتحديد الحد الأقصى لعدد الأجزاء التي يمكن تقسيمها ، بغض النظر عن العدد المطلوب.
مثال مفصل للتنفيذ
فيما يلي مثال على مقتطف الشفرة الذي يستخدم IShardableTest
الذي يمكنك الرجوع إليه. الكود الكامل متاح على (https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/main/test_framework/com/android/tradefed/testtype/InstalledInstrumentationsTest.java)
/**
* Runs all instrumentation found on current device.
*/
@OptionClass(alias = "installed-instrumentation")
public class InstalledInstrumentationsTest
implements IDeviceTest, IResumableTest, IShardableTest {
...
/** {@inheritDoc} */
@Override
public Collection<IRemoteTest> split(int shardCountHint) {
if (shardCountHint > 1) {
Collection<IRemoteTest> shards = new ArrayList<>(shardCountHint);
for (int index = 0; index < shardCountHint; index++) {
shards.add(getTestShard(shardCountHint, index));
}
return shards;
}
// Nothing to shard
return null;
}
private IRemoteTest getTestShard(int shardCount, int shardIndex) {
InstalledInstrumentationsTest shard = new InstalledInstrumentationsTest();
try {
OptionCopier.copyOptions(this, shard);
} catch (ConfigurationException e) {
CLog.e("failed to copy instrumentation options: %s", e.getMessage());
}
shard.mShardIndex = shardIndex;
shard.mTotalShards = shardCount;
return shard;
}
...
}
يقوم هذا المثال ببساطة بإنشاء مثيل جديد لنفسه وتعيين معلمات جزء له. ومع ذلك ، يمكن أن يكون منطق التقسيم مختلفًا تمامًا من اختبار إلى آخر ؛ وطالما أنها حتمية وتنتج مجموعات فرعية شاملة بشكل جماعي ، فلا بأس بذلك.
استقلال
يجب أن تكون الشظايا مستقلة! يجب ألا يكون للجزءين اللذين تم إنشاؤهما من خلال تطبيقك split
في العداء الخاص بك تبعيات على بعضهما البعض أو مشاركة الموارد.
يجب أن يكون تقسيم الشظايا أمرًا حتميًا! هذا أيضًا إلزامي ، نظرًا لنفس الشروط ، يجب أن تُرجع طريقة split
دائمًا نفس قائمة القطع بالترتيب نفسه.
ملاحظة: نظرًا لأنه يمكن تشغيل كل جزء على مثيلات مختلفة من TF ، فمن الأهمية بمكان التأكد من أن منطق split
ينتج مجموعات فرعية متنافية وشاملة بشكل جماعي بطريقة حتمية.
قم بإجراء اختبار محليًا
لتقسيم اختبار على TF محلي ، يمكنك ببساطة إضافة خيار --shard-count
إلى سطر الأوامر.
tf >run host --class com.android.tradefed.UnitTests --shard-count 3
ثم يقوم TF تلقائيًا بتوليد الأوامر لكل جزء وتشغيلها.
tf >l i
Command Id Exec Time Device State
3 0m:03 [null-device-2] running stub on build 0 (shard 1 of 3)
3 0m:03 [null-device-1] running stub on build 0 (shard 0 of 3)
3 0m:03 [null-device-3] running stub on build 0 (shard 2 of 3)
تجميع نتائج الاختبار
نظرًا لأن فريق العمل لا يقوم بأي تجميع لنتائج الاختبار للاستدعاءات المجزأة ، فأنت بحاجة إلى التأكد من دعم خدمة إعداد التقارير لديك.
وعند كتابة عداء اختبار ، من المهم التفكير في قابلية التوسع. اسأل نفسك ، "إذا اضطر عداء الاختبار الخاص بي إلى إجراء 200 ألف حالة اختبار" ، فما المدة التي سيستغرقها ذلك؟
المشاركة هي إحدى الإجابات المتوفرة في "الاتحاد التجاري". يتطلب تقسيم جميع الاختبارات التي يحتاجها العداء إلى عدة أجزاء يمكن موازنتها.
تصف هذه الصفحة كيفية جعل العداء الخاص بك قابلاً للتجزئة من أجل Tradefed.
واجهة للتنفيذ
الواجهة الوحيدة الأكثر أهمية التي يجب تنفيذها لتكون قابلة للتجزئة بواسطة TF هي IShardableTest ، والتي تحتوي على طريقتين: split(int numShard)
و split()
.
إذا كانت التجزئة الخاصة بك ستعتمد على عدد الأجزاء المطلوبة ، فيجب عليك تنفيذ split(int numShard)
. خلاف ذلك ، قم بتنفيذ split()
.
عند تنفيذ أمر اختبار TF باستخدام معلمات التجزئة --shard-count
و --shard-index
، يتكرر TF عبر جميع IRemoteTest
للبحث عن تلك التي تنفذ IShardableTest
. إذا تم العثور عليه ، فسيتم استدعاء split
للحصول على كائن IRemoteTest
جديد لتشغيل مجموعة فرعية من حالات الاختبار لجزء معين.
ما الذي يجب أن أعرفه عن تطبيق الانقسام؟
- يجوز للعدّاء أن يتشاجر عند بعض الشروط فقط ؛ في هذه الحالة ، يتم إرجاع
null
عندما لا تكون جزءًا. - حاول أن تقسم بقدر ما هو منطقي: قسّم العداء الخاص بك إلى وحدة تنفيذ منطقية بالنسبة له. انها حقا تعتمد على عداء الخاص بك. على سبيل المثال: يتم تجزئة HostTest على مستوى الفصل ، ويتم وضع كل فئة اختبار في جزء منفصل.
- إذا كان ذلك منطقيًا ، أضف بعض الخيارات للتحكم في التجزئة قليلاً. على سبيل المثال: يحتوي AndroidJUnitTest على
ajur-max-shard
لتحديد الحد الأقصى لعدد الأجزاء التي يمكن تقسيمها ، بغض النظر عن العدد المطلوب.
مثال مفصل للتنفيذ
فيما يلي مثال على مقتطف الشفرة الذي يستخدم IShardableTest
الذي يمكنك الرجوع إليه. الكود الكامل متاح على (https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/main/test_framework/com/android/tradefed/testtype/InstalledInstrumentationsTest.java)
/**
* Runs all instrumentation found on current device.
*/
@OptionClass(alias = "installed-instrumentation")
public class InstalledInstrumentationsTest
implements IDeviceTest, IResumableTest, IShardableTest {
...
/** {@inheritDoc} */
@Override
public Collection<IRemoteTest> split(int shardCountHint) {
if (shardCountHint > 1) {
Collection<IRemoteTest> shards = new ArrayList<>(shardCountHint);
for (int index = 0; index < shardCountHint; index++) {
shards.add(getTestShard(shardCountHint, index));
}
return shards;
}
// Nothing to shard
return null;
}
private IRemoteTest getTestShard(int shardCount, int shardIndex) {
InstalledInstrumentationsTest shard = new InstalledInstrumentationsTest();
try {
OptionCopier.copyOptions(this, shard);
} catch (ConfigurationException e) {
CLog.e("failed to copy instrumentation options: %s", e.getMessage());
}
shard.mShardIndex = shardIndex;
shard.mTotalShards = shardCount;
return shard;
}
...
}
يقوم هذا المثال ببساطة بإنشاء مثيل جديد لنفسه وتعيين معلمات جزء له. ومع ذلك ، يمكن أن يكون منطق التقسيم مختلفًا تمامًا من اختبار إلى آخر ؛ وطالما أنها حتمية وتنتج مجموعات فرعية شاملة بشكل جماعي ، فلا بأس بذلك.
استقلال
يجب أن تكون الشظايا مستقلة! يجب ألا يكون للجزءين اللذين تم إنشاؤهما من خلال تطبيقك split
في العداء الخاص بك تبعيات على بعضهما البعض أو مشاركة الموارد.
يجب أن يكون تقسيم الشظايا أمرًا حتميًا! هذا أيضًا إلزامي ، نظرًا لنفس الشروط ، يجب أن تُرجع طريقة split
دائمًا نفس قائمة القطع بالترتيب نفسه.
ملاحظة: نظرًا لأنه يمكن تشغيل كل جزء على مثيلات مختلفة من TF ، فمن الأهمية بمكان التأكد من أن منطق split
ينتج مجموعات فرعية متنافية وشاملة بشكل جماعي بطريقة حتمية.
قم بإجراء اختبار محليًا
لتقسيم اختبار على TF محلي ، يمكنك ببساطة إضافة خيار --shard-count
إلى سطر الأوامر.
tf >run host --class com.android.tradefed.UnitTests --shard-count 3
ثم يقوم TF تلقائيًا بتوليد الأوامر لكل جزء وتشغيلها.
tf >l i
Command Id Exec Time Device State
3 0m:03 [null-device-2] running stub on build 0 (shard 1 of 3)
3 0m:03 [null-device-1] running stub on build 0 (shard 0 of 3)
3 0m:03 [null-device-3] running stub on build 0 (shard 2 of 3)
تجميع نتائج الاختبار
نظرًا لأن فريق العمل لا يقوم بأي تجميع لنتائج الاختبار للاستدعاءات المجزأة ، فأنت بحاجة إلى التأكد من دعم خدمة إعداد التقارير لديك.