परीक्षण मानचित्रण

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

परीक्षण मानचित्रण के बारे में

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

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

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

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

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

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

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

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

पैकेज निर्माण स्क्रिप्ट नियम

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

  • सामान्य-परीक्षण - परीक्षण जो डिवाइस-विशिष्ट कार्यक्षमता पर निर्भर नहीं होते हैं (जैसे कि विक्रेता-विशिष्ट हार्डवेयर जो अधिकांश उपकरणों में नहीं होता है)। अधिकांश परीक्षण सामान्य-परीक्षण सुइट में होने चाहिए, भले ही वे एक ABI या बिटनेस या HWASan जैसी हार्डवेयर सुविधाओं के लिए विशिष्ट हों (प्रत्येक ABI के लिए एक अलग test_suites लक्ष्य है), और भले ही उन्हें एक डिवाइस पर चलाना हो।
  • डिवाइस-परीक्षण - परीक्षण जो डिवाइस-विशिष्ट कार्यक्षमता पर निर्भर करते हैं। आमतौर पर ये परीक्षण vendor/ के अंतर्गत पाए जाएंगे। क्योंकि "डिवाइस-विशिष्ट" एबीआई या एसओसी कार्यक्षमता को संदर्भित नहीं करता है जो अन्य उपकरणों में हो सकती है या नहीं हो सकती है, लेकिन केवल उस कार्यक्षमता के लिए जो एक डिवाइस के लिए अद्वितीय है, यह जेयूनिट परीक्षणों पर उतना ही लागू होता है जितना कि जीटेस्ट मूल परीक्षणों पर (जो आमतौर पर होना चाहिए) general-tests हों, भले ही वे एबीआई-विशिष्ट हों)।

उदाहरण:

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

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

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

  • कोई भी निर्माण प्रदाता नहीं होना चाहिए.
  • इसे समाप्त होने के बाद साफ़ करना होगा, उदाहरण के लिए, परीक्षण के दौरान उत्पन्न किसी भी अस्थायी फ़ाइल को हटाकर।
  • सिस्टम सेटिंग्स को डिफ़ॉल्ट या मूल मान में बदलें।
  • किसी डिवाइस को किसी निश्चित स्थिति में नहीं मानना ​​चाहिए, उदाहरण के लिए, रूट रेडी। अधिकांश परीक्षणों को चलाने के लिए रूट विशेषाधिकार की आवश्यकता नहीं होती है। यदि किसी परीक्षण के लिए रूट की आवश्यकता होती है, तो उसे अपने AndroidTest.xml में RootTargetPreparer के साथ निर्दिष्ट करना चाहिए, जैसा कि निम्नलिखित उदाहरण में है:
<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 GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

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

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

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

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

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

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

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

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

tradefed.sh run commandAndExit [test_module] --help

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

एटेस्ट के साथ परीक्षण चलाएँ

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

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

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

वर्तमान कार्यशील निर्देशिका (सीडब्ल्यूडी) और मूल निर्देशिकाओं में TEST_MAPPING फ़ाइलों में प्रीसबमिट परीक्षण चलाने का यह सबसे सरल तरीका है। एटेस्ट 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

पोस्टसबमिट परीक्षण नियम चलाएँ

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

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

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

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

atest [--test-mapping] --host

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

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

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

atest --test-mapping src/project_1:all

उपनिर्देशिकाएँ शामिल करें

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

atest --include-subdir

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

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

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

उदाहरण:

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