टेस्ट मैपिंग

यह टेस्ट मैपिंग का एक संक्षिप्त परिचय है और एंड्रॉइड ओपन सोर्स प्रोजेक्ट (एओएसपी) में आसानी से परीक्षण कॉन्फ़िगर करना शुरू करने का एक स्पष्टीकरण है।

टेस्ट मैपिंग क्या है?

टेस्ट मैपिंग एक गेरिट-आधारित दृष्टिकोण है जो डेवलपर्स को सीधे एंड्रॉइड सोर्स ट्री में प्री- और पोस्ट-सबमिट टेस्ट नियम बनाने की अनुमति देता है और परीक्षण के बुनियादी ढांचे के लिए शाखाओं और उपकरणों के निर्णयों को छोड़ देता है। टेस्ट मैपिंग परिभाषाएँ TEST_MAPPING नाम की JSON फ़ाइलें हैं जिन्हें किसी भी स्रोत निर्देशिका में रखा जा सकता है।

Atest जुड़े निर्देशिका में presubmit परीक्षण चलाने के लिए TEST_MAPPING फ़ाइलों का उपयोग कर सकते हैं। टेस्ट मैपिंग के साथ, आप एंड्रॉइड सोर्स ट्री के अंदर एक साधारण बदलाव के साथ चेक सबमिट करने के लिए परीक्षणों का एक ही सेट जोड़ सकते हैं।

ये उदाहरण देखें:

services.core के लिए TEST_MAPPING में प्री-सबमिट टेस्ट जोड़ें

आयात का उपयोग करने वाले टूल/डेक्सटर के लिए TEST_MAPPING में पूर्व-सबमिट परीक्षण जोड़ें

टेस्ट मानचित्रण पर निर्भर करता है ट्रेड फेडरेशन (TF) टेस्ट हार्नेस परीक्षण निष्पादन और परिणाम रिपोर्ट करने के लिए।

परीक्षण समूहों को परिभाषित करना

टेस्ट का मिलान समूहों परीक्षण समूह के माध्यम से परीक्षण करती है। एक परीक्षण समूह का नाम कोई भी स्ट्रिंग हो सकता है। उदाहरण के लिए, presubmit परीक्षण के एक समूह जब परिवर्तनों को सत्यापित करने को चलाने के लिए हो सकता है। और postsubmit परीक्षण बनाता है के बाद परिवर्तन विलय कर रहे हैं मान्य करने के लिए इस्तेमाल किया जा सकता।

पैकेजिंग बिल्ड स्क्रिप्ट नियम

के लिए आदेश में ट्रेड फेडरेशन टेस्ट हार्नेस किसी दिए गए निर्माण के लिए टेस्ट मैपिंग के परीक्षण मॉड्यूल को चलाने के लिए, इन मॉड्यूल के लिए test_suite सेट होना चाहिए सूंग इन दो सुइट्स में से एक के लिए आप के लिए या LOCAL_COMPATIBILITY_SUITE सेट:

  • सामान्य परीक्षण - परीक्षण उस पर उपकरण-विशिष्ट सुविधाओं निर्भर नहीं है। अधिकांश परीक्षण सामान्य-परीक्षण सूट में होने चाहिए, क्योंकि उन्हें test_suites लक्ष्य पर बनाया जा सकता है जिसमें सभी समर्थित ABI (32 बनाम 64) पर बायनेरिज़ (मूल परीक्षणों के लिए) शामिल हैं।
  • डिवाइस-परीक्षण - परीक्षण पर उपकरण-विशिष्ट सुविधाओं निर्भर करती है, निश्चित डिवाइस ठिकानों पर केवल runnable, या केवल केवल कुछ डिवाइस लक्ष्य पर बनाया जा सकता है। यह सच है कि परीक्षण एक देशी परीक्षण है या जुनीट परीक्षण।

उदाहरण:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

परीक्षण सूट में चलाने के लिए परीक्षण कॉन्फ़िगर करना

एक परीक्षण सूट के अंदर चलाने के लिए एक परीक्षण के लिए, परीक्षण:

  • कोई बिल्ड प्रदाता नहीं होना चाहिए।
  • इसे समाप्त होने के बाद साफ करना चाहिए, उदाहरण के लिए, परीक्षण के दौरान उत्पन्न किसी भी अस्थायी फाइल को हटाकर।
  • सिस्टम सेटिंग्स को डिफ़ॉल्ट या मूल मान में बदलें।

  • एक निश्चित स्थिति में एक उपकरण नहीं मानना ​​चाहिए, जैसे, रूट तैयार। अधिकांश परीक्षणों को चलाने के लिए रूट विशेषाधिकार की आवश्यकता नहीं होती है। यदि किसी परीक्षण को रूट की आवश्यकता होती है, तो उसे यह निर्दिष्ट करना चाहिए कि रूटटार्गेटप्रेपरर के साथ, उदाहरण के लिए:

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

टेस्ट मैपिंग फाइल बनाना

परीक्षण कवरेज की आवश्यकता वाली निर्देशिका के लिए, बस नीचे दिए गए उदाहरण के समान एक TEST_MAPPING JSON फ़ाइल जोड़ें। ये नियम सुनिश्चित करेंगे कि परीक्षण पूर्व-सबमिट जांच में चलाए जाएं जब उस निर्देशिका या इसकी किसी उपनिर्देशिका में किसी भी फाइल को छुआ जाए।

एक उदाहरण के बाद

यहां एक नमूना है TEST_MAPPING फ़ाइल (यह JSON प्रारूप में लेकिन समर्थित टिप्पणी के साथ है):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side native test with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side native test.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

विशेषताएँ सेट करना

उपरोक्त उदाहरण में, presubmit और postsubmit प्रत्येक परीक्षा समूह के नाम हैं। देखें परीक्षण समूहों को परिभाषित करना परीक्षण समूहों के बारे में अधिक जानकारी के लिए।

परीक्षण मॉड्यूल या ट्रेड फेडरेशन एकीकरण परीक्षण का नाम (परीक्षण एक्सएमएल फ़ाइल के लिए संसाधन पथ, जैसे, के नाम uiautomator / uiautomator-डेमो ) के मूल्य में सेट किया जा सकता name विशेषता। नोट नाम फ़ील्ड वर्ग उपयोग नहीं कर सकते name या परीक्षा पद्धति name । चलाने के लिए परीक्षण को कम करने के लिए, आप इस तरह के रूप विकल्पों का उपयोग कर सकते हैं include-filter यहाँ। देखें ( शामिल फिल्टर नमूना उपयोग )।

एक परीक्षण के मेजबान सेटिंग इंगित करता है कि परीक्षण एक deviceless मेजबान या नहीं पर चल रहे परीक्षण है। डिफ़ॉल्ट मान असत्य, परीक्षण अर्थ चलाने के लिए एक उपकरण की आवश्यकता है। समर्थित परीक्षण प्रकार के होते हैं HostGTest देशी परीक्षण और के लिए HostTest JUnit परीक्षण के लिए।

File_patterns विशेषता आप किसी भी स्रोत कोड फ़ाइल के रिश्तेदार पथ (निर्देशिका TEST_MAPPING फ़ाइल वाले के सापेक्ष) मिलान के लिए regex स्ट्रिंग की एक सूची सेट करने के लिए अनुमति देता है। उपरोक्त उदाहरण में, परीक्षण CtsWindowManagerDeviceTestCases presubmit में चलेंगे तभी होता है जब जो TEST_MAPPING फ़ाइल या उसके उप निर्देशिका में से किसी का एक ही निर्देशिका में मौजूद है खिड़की या गतिविधि के साथ किसी भी जावा फ़ाइल शुरू होता है, बदल जाता है। बैकस्लैश \ से बचने की जरूरत है क्योंकि वे JSON फ़ाइल में हैं।

आयात विशेषता आप सामग्री को कॉपी किए बिना अन्य TEST_MAPPING फाइलों में परीक्षण शामिल करने के लिए अनुमति देता है। ध्यान दें कि आयातित पथ की मूल निर्देशिका में TEST_MAPPING फ़ाइलें भी शामिल की जाएंगी। टेस्ट मैपिंग नेस्टेड आयात की अनुमति देता है; इसका मतलब है कि दो TEST_MAPPING फ़ाइलें एक दूसरे को आयात कर सकती हैं, और टेस्ट मैपिंग शामिल परीक्षणों को ठीक से मर्ज करने में सक्षम है।

विकल्प विशेषता अतिरिक्त TradeFed कमांड लाइन विकल्प होते हैं।

किसी दिए गए परीक्षण के लिए उपलब्ध विकल्पों की पूरी सूची प्राप्त करने के लिए, दौड़ें:

tradefed.sh run commandAndExit [test_module] --help

का संदर्भ लें TradeFed विकल्प हैंडलिंग कैसे विकल्प काम के बारे में अधिक जानकारी के लिए।

Atest . के साथ चल रहे परीक्षण

स्थानीय रूप से पूर्व सबमिट परीक्षण नियमों को निष्पादित करने के लिए:

  1. TEST_MAPPING फ़ाइल वाली निर्देशिका पर जाएँ।
  2. कमांड चलाएँ:
atest

वर्तमान निर्देशिका और इसकी मूल निर्देशिका की TEST_MAPPING फ़ाइलों में कॉन्फ़िगर किए गए सभी पूर्व-सबमिट परीक्षण चलाए जाते हैं। एटेस्ट प्रीसबमिट (ए और बी) के लिए दो परीक्षणों का पता लगाएगा और चलाएगा।

वर्तमान कार्यशील निर्देशिका (सीडब्ल्यूडी) और मूल निर्देशिकाओं में TEST_MAPPING फ़ाइलों में पूर्व सबमिट परीक्षण चलाने का यह सबसे आसान तरीका है। Atest CWD और उसकी सभी मूल निर्देशिकाओं में TEST_MAPPING फ़ाइल का पता लगाएगा और उसका उपयोग करेगा।

संरचना स्रोत कोड

निम्न उदाहरण दिखाता है कि TEST_MAPPING फ़ाइलों को स्रोत ट्री में कैसे कॉन्फ़िगर किया जा सकता है।

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

की सामग्री src/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

की सामग्री src/project_1/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

की सामग्री src/project_2/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

लक्ष्य निर्देशिका निर्दिष्ट करना

आप उस निर्देशिका में TEST_MAPPING फ़ाइलों में परीक्षण चलाने के लिए एक लक्ष्य निर्देशिका निर्दिष्ट कर सकते हैं। निम्न आदेश दो परीक्षण चलाएगा (ए, बी)।

atest --test-mapping src/project_1

रनिंग पोस्टसबमिट परीक्षण नियम

तुम भी postsubmit परीक्षण नियमों में TEST_MAPPING में परिभाषित चलाने के लिए इस आदेश का उपयोग कर सकते हैं src_path (CWD को डिफ़ॉल्ट) और उसकी मूल निर्देशिका:

atest [--test-mapping] [src_path]:postsubmit

केवल ऐसे परीक्षण चलाना जिनके लिए किसी उपकरण की आवश्यकता नहीं है

आप मेजबान है कि कोई उपकरण की आवश्यकता के खिलाफ कॉन्फ़िगर किया गया केवल चलाने के परीक्षण के लिए atest के लिए विकल्प --host उपयोग कर सकते हैं। इस विकल्प के बिना, Atest दोनों परीक्षण चलाएगा, जिनके लिए डिवाइस की आवश्यकता होती है और वे जो होस्ट पर चल रहे होते हैं और जिनके लिए किसी डिवाइस की आवश्यकता नहीं होती है। परीक्षण दो अलग-अलग सुइट्स में चलाए जाएंगे।

atest [--test-mapping] --host

परीक्षण समूहों की पहचान

आप एटेस्ट कमांड में परीक्षण समूह निर्दिष्ट कर सकते हैं। निम्न आदेश निर्देशिका src / project_1 है, जो केवल एक परीक्षण (सी) में शामिल है में फ़ाइलों से संबंधित सभी postsubmit परीक्षण चलेंगे।

या आप उपयोग कर सकते हैं: सभी समूह की परवाह किए बिना सभी परीक्षण चलाने के लिए। निम्न आदेश चार परीक्षण चलाता है (ए, बी, सी, एक्स):

atest --test-mapping src/project_1:all

उपनिर्देशिका सहित

डिफ़ॉल्ट रूप से, Atest के साथ TEST_MAPPING में चल रहे परीक्षण केवल CWD (या दी गई निर्देशिका) और इसकी मूल निर्देशिकाओं में TEST_MAPPING फ़ाइल में कॉन्फ़िगर किए गए पूर्व-सबमिट परीक्षण चलाएंगे। आप उप-निर्देशिका में सभी TEST_MAPPING फाइलों में परीक्षण चलाने के लिए चाहते हैं, विकल्प का उपयोग --include-subdir उन परीक्षण भी शामिल करने के लिए मजबूर करने के लिए atest।

atest --include-subdir

बिना --include-subdir विकल्प, atest के साथ ही परीक्षण ए चलेंगे --include-subdir विकल्प, atest दो टेस्ट (ए, बी) चलेंगे।

लाइन-स्तरीय टिप्पणी समर्थित है

आप एक लाइन-लेवल जोड़ सकते हैं // सेटिंग है, जो इस प्रकार है के विवरण के साथ TEST_MAPPING फ़ाइल बाहर मांस के लिए -format टिप्पणी। Atest और ट्रेड फेडरेशन टिप्पणियों के बिना एक मान्य JSON प्रारूप करने के लिए TEST_MAPPING preprocess होगा। JSON फ़ाइल स्वच्छ और पढ़ने में आसान रखने के लिए, केवल लाइन-लेवल // -format टिप्पणी समर्थित है।

उदाहरण:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}