इस पेज पर बताया गया है कि Tradefed में टेस्ट लिखते समय, टेस्ट के नतीजों के साथ-साथ मेट्रिक की रिपोर्ट कैसे करें.
Tradefed पाइपलाइन के ज़रिए लॉग इन करने का फ़ायदा यह है कि आपको अपने फ़ंक्शनल नतीजों के साथ-साथ अपनी मेट्रिक भी मिल जाती हैं. टेस्ट के दौरान मेट्रिक को बहुत आसानी से लॉग किया जा सकता है. इससे टेस्ट लिखने वालों को ज़्यादा इंस्ट्रुमेंटेशन जोड़ने में आसानी होती है.
DeviceTestCase - JUnit3 स्टाइल
अगर आपका टेस्ट, JUnit3-स्टाइल के टेस्ट में DeviceTestCase को बढ़ाता है, तो किसी मेट्रिक की जानकारी देने के लिए, किसी भी टेस्ट केस के अंदर से addTestMetric(String key, String value) तरीके को कॉल किया जा सकता है. इस फ़ंक्शन को कई बार कॉल किया जा सकता है, बशर्ते कि कुंजी यूनीक हो.
उदाहरण:
public static class TestMetricTestCase extends DeviceTestCase {
public void testPass() {
addTestMetric("key1", "metric1");
}
public void testPass2() {
addTestMetric("key2", "metric2");
}
}
अगर आपको किसी फ़ाइल को result_reporters में उपलब्ध कराने के लिए लॉग करना है, तो लॉग करने के लिए किसी फ़ाइल की रिपोर्ट करने के लिए, किसी भी टेस्ट केस के अंदर से addTestLog(String dataName, LogDataType dataType, InputStreamSource dataStream) तरीके को कॉल किया जा सकता है.
उदाहरण:
public static class TestLogTestCase extends DeviceTestCase {
public void testPass() {
try (InputStreamSource source = getDevice().getScreenshot()) {
addTestLog("screenshot", LogDataType.PNG, source);
}
}
}
TestCase - regular JUnit3 test
अगर आपको किसी सामान्य JUnit3 TestCase क्लास से Tradefed में मेट्रिक की रिपोर्ट करनी है, तो उसे MetricTestCase में बदलना होगा. यह ठीक वैसी ही क्लास है जिसमें एक अतिरिक्त तरीका है: addTestMetric(String key, String value)
DeviceJUnit4ClassRunner - JUnit4 स्टाइल
अगर आपका JUnit4 स्टाइल टेस्ट, DeviceJUnit4ClassRunner के साथ चल रहा है, तो Tradefed की ओर से रिपोर्ट की जाने वाली मेट्रिक को टेस्ट केस (inside @Test) में भी लॉग किया जा सकता है. आपको अपनी मेट्रिक की रिपोर्ट करने के लिए, TestMetrics नियमों का इस्तेमाल करना होगा.
उदाहरण:
@RunWith(DeviceJUnit4ClassRunner.class)
public static class Junit4TestClass {
@Rule
public TestMetrics metrics = new TestMetrics();
@Test
public void testPass5() {
// test log through the rule.
metrics.addTestMetric("key", "value");
}
@Test
public void testPass6() {
metrics.addTestMetric("key2", "value2");
}
}
फ़ाइलों की शिकायत करने के लिए, आपको TestLogData नियम का इस्तेमाल करना होगा.
उदाहरण:
@RunWith(DeviceJUnit4ClassRunner.class)
public static class Junit4TestClass {
@Rule
public TestLogData logs = new TestLogData();
@Test
public void testPass5() {
// test log through the rule.
try (InputStreamSource source = getDevice().getScreenshot()) {
logs.addTestLog("screenshot", LogDataType.PNG, source);
}
}
}
IRemoteTest - pure Tradefed Test
अगर आपको अपनी Tradefed टेस्ट क्लास या रनर लिखना है, तो आपको IRemoteTest लागू करना होगा. साथ ही, run() तरीके से ITestInvocationListener मिलेगा. इस लिसनर का इस्तेमाल, मेट्रिक को इस तरह लॉग करने के लिए किया जा सकता है:
listener.testLog(String dataName, LogDataType type of data, InputStreamSource data);
Tradefed मेट्रिक कलेक्टर
Tradefed, टेस्ट के साथ-साथ मेट्रिक इकट्ठा करने के लिए एक खास metrics_collector ऑब्जेक्ट उपलब्ध कराता है.
होस्ट के लिए
BaseDeviceMetricCollector को लागू करके, होस्ट-साइड से कोई भी मेट्रिक इकट्ठा की जा सकती है. साथ ही, उन्हें टेस्ट इनवोकेशन के हिस्से के तौर पर रिपोर्ट किया जा सकता है. इस्तेमाल के अलग-अलग उदाहरणों के लिए, कई सामान्य कलेक्टर पहले से ही उपलब्ध हैं. हालांकि, हम हमेशा नए योगदानों का स्वागत करते हैं.
Tradefed इनवोकेशन में इस्तेमाल किए जाने वाले कलेक्टर को तय करने के लिए, आपको बस अपने Tradefed XML कॉन्फ़िगरेशन में ऑब्जेक्ट जोड़ना होगा:
उदाहरण:
<metrics_collector class="com.android.tradefed.device.metric.AtraceCollector">
<option name="categories" value="freq"/>
</metrics_collector>
फ़िलहाल मौजूद कुछ कलेक्टर: * TemperatureCollector यह टेस्ट रन के दौरान समय-समय पर तापमान इकट्ठा करता है. * AtraceCollector जो हर टेस्ट केस के लिए, 'atrace' का इस्तेमाल करके डेटा इकट्ठा करता है.
डिवाइस पर
डिवाइस-साइड टेस्ट (इंस्ट्रूमेंटेशन, UIAutomator टेस्ट वगैरह) चलाते समय, होस्ट-साइड पर एसिंक्रोनस तरीके से डेटा इकट्ठा करने वाला कोई कलेक्टर होना सही नहीं हो सकता. उदाहरण के लिए, एसिंक्रोनस तरीके से लिए गए स्क्रीनशॉट में, हो सकता है कि आपको जिस स्क्रीन का स्क्रीनशॉट चाहिए वह न दिखे. ऐसे में, वह स्क्रीनशॉट आपके किसी काम का नहीं होगा.
इन इस्तेमाल के उदाहरणों को पूरा करने के लिए, हमारे कलेक्टर का डिवाइस-साइड वर्शन मौजूद है. इसका इस्तेमाल किसी भी 'AndroidJUnitRunner' इंस्ट्रुमेंटेशन में किया जा सकता है. BaseMetricListener को लागू किया जा सकता है, ताकि Tradefed रिपोर्टिंग पाइपलाइन के साथ पूरी तरह से काम करने वाली मेट्रिक अपने-आप रिपोर्ट हो जाएं.
अगर Tradefed के 'AndroidJUnitTest' रनर का इस्तेमाल किया जा रहा है, तो अपने टेस्ट के साथ कलेक्टर को चलाने के लिए, यहां दिए गए कमांड लाइन विकल्प का इस्तेमाल करें:
--device-listeners android.device.collectors.ScreenshotListener
चेतावनी: कलेक्टर क्लास को रनटाइम पर हल करने के लिए, आपके इंस्ट्रुमेंटेशन APK को उन्हें स्टैटिक तौर पर शामिल करना होगा. इसके लिए, आपको अपनी मेकफ़ाइल में यह जोड़ना होगा:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
डिवाइस-साइड कलेक्टर में योगदान देने का भी स्वागत है.
सुइट के लिए खास बातें
CTS जैसे सुइट के लिए, टॉप-लेवल कॉन्फ़िगरेशन में कुछ मॉड्यूल कॉन्फ़िगरेशन चल रहे होते हैं. ऐसे में, हर मॉड्यूल कॉन्फ़िगरेशन (AndroidTest.xml) में metrics_collector को शामिल करने की ज़रूरत नहीं होती. ऐसा करना मना है.
यह पक्का करने के लिए कि मेट्रिक कलेक्शन, हर मॉड्यूल पर एक जैसा लागू हो, सिर्फ़ टॉप-लेवल कॉन्फ़िगरेशन (उदाहरण के लिए, cts.xml) में metrics_collector को तय किया जा सकता है. इसके बारे में ऊपर बताया गया है. ये कलेक्टर, सुइट के हर मॉड्यूल पर लागू किए जाएंगे और उनके हिसाब से काम करेंगे.
किसी मॉड्यूल से डिवाइस की लॉग फ़ाइलें इकट्ठा करना
डिवाइस साइड टेस्ट के लिए सेटअप उपलब्ध है, ताकि यह सूचना दी जा सके कि कुछ फ़ाइलें इकट्ठा की जानी चाहिए.
AndroidTest.xml एक कलेक्टर तय कर सकता है, जो डिवाइस पर फ़ाइल खोजेगा और उन्हें इकट्ठा करेगा.
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<!-- repeatable: Pattern of key of a FILE we listen on that should be pulled -->
<option name = "pull-pattern-keys" value = "ScreenshotListener_.*" />
<!-- repeatable: The key of the DIRECTORY to pull -->
<option name = "directory-keys" value = "<example-key: /sdcard/atrace_logs>" />
</metrics_collector>
इन पैटर्न और कुंजी को तय करने पर, अगर कलेक्टर को कुंजी दिखती है, तो वह उससे जुड़ी फ़ाइल को पुल और लॉग करने की कोशिश करेगा.
इन कुंजियों को जनरेट करने के लिए, डिवाइस-साइड टेस्ट (इंस्ट्रूमेंटेशन) को उस फ़ाइल के बारे में बताना चाहिए जिसे लॉग किया जाना है. इसे होस्ट-साइड (ऊपर बताया गया है) की तरह ही किया जाता है.
- मेक फ़ाइलों में, अपने टेस्ट APK में
collector-device-libजोड़ें:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
- हम लॉग फ़ाइलों के लिए @rule उपलब्ध कराते हैं. इसका इस्तेमाल करें:
@RunWith(AndroidJUnit4.class)
public static class Junit4TestClass {
@Rule
public TestLogData logs = new TestLogData();
@Test
public void testPass5() {
// test log through the rule.
File logFile = new File("whatever");
logs.addTestLog("KEY", logFile);
}
}
ऊपर दिए गए उदाहरण में, KEY वह नाम है जिसके तहत फ़ाइल की शिकायत की जाएगी. यह वह नाम है जिसे आपको FilePullerDeviceMetricCollector में मौजूद नाम से मैच करना चाहिए, ताकि यह अपने-आप पुल हो जाए. यह एक यूनीक नाम होना चाहिए.
ध्यान दें: फ़ाइल को खींचने के बाद, FilePullerDeviceMetricCollector उसे डिवाइस से अपने-आप मिटा देता है.
मुझे मेट्रिक कहां दिखेंगी?
यह आपके एक्सएमएल कॉन्फ़िगरेशन में तय किए गए result_reporter पर निर्भर करता है.