यह टेस्ट मैपिंग का एक संक्षिप्त परिचय है और एंड्रॉइड ओपन सोर्स प्रोजेक्ट (एओएसपी) में आसानी से परीक्षण कॉन्फ़िगर करना शुरू करने का एक स्पष्टीकरण है।
टेस्ट मैपिंग क्या है?
टेस्ट मैपिंग एक गेरिट-आधारित दृष्टिकोण है जो डेवलपर्स को सीधे एंड्रॉइड सोर्स ट्री में प्री- और पोस्ट-सबमिट टेस्ट नियम बनाने की अनुमति देता है और परीक्षण के बुनियादी ढांचे के लिए शाखाओं और उपकरणों के निर्णयों को छोड़ देता है। टेस्ट मैपिंग परिभाषाएँ TEST_MAPPING नाम की JSON फ़ाइलें हैं जिन्हें किसी भी स्रोत निर्देशिका में रखा जा सकता है।
Atest संबंधित निर्देशिकाओं में पूर्व सबमिट परीक्षण चलाने के लिए 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 प्रत्येक परीक्षण समूह के नाम हैं। परीक्षण समूहों के बारे में अधिक जानकारी के लिए परीक्षण समूहों को परिभाषित करना देखें।
परीक्षण मॉड्यूल का नाम या ट्रेड फेडरेशन एकीकरण परीक्षण नाम (परीक्षण एक्सएमएल फ़ाइल के लिए संसाधन पथ, उदाहरण के लिए, uiautomator/uiautomator-demo ) name विशेषता के मान में सेट किया जा सकता है। ध्यान दें कि नाम फ़ील्ड वर्ग name या परीक्षण विधि name का उपयोग नहीं कर सकता है। चलाने के लिए परीक्षणों को कम करने के लिए, आप यहां include-filter जैसे विकल्पों का उपयोग कर सकते हैं। देखें ( शामिल-फ़िल्टर नमूना उपयोग )।
एक परीक्षण की मेजबान सेटिंग इंगित करती है कि परीक्षण एक उपकरण रहित परीक्षण है जो मेजबान पर चल रहा है या नहीं। डिफ़ॉल्ट मान गलत है, जिसका अर्थ है कि परीक्षण को चलाने के लिए एक उपकरण की आवश्यकता होती है। समर्थित परीक्षण प्रकार GTest बायनेरिज़ के लिए HostGTest और JUnit परीक्षणों के लिए HostTest हैं।
file_patterns विशेषता आपको किसी भी स्रोत कोड फ़ाइल (TEST_MAPPING फ़ाइल वाली निर्देशिका के सापेक्ष) के सापेक्ष पथ से मेल खाने के लिए रेगेक्स स्ट्रिंग्स की एक सूची सेट करने की अनुमति देती है। उपरोक्त उदाहरण में, परीक्षण CtsWindowManagerDeviceTestCases प्रीसबमिट में तभी चलेगा जब कोई जावा फ़ाइल विंडो या गतिविधि से शुरू होती है, जो TEST_MAPPING फ़ाइल या उसकी किसी भी उप निर्देशिका की एक ही निर्देशिका में मौजूद है, बदल जाती है। बैकस्लैश \ से बचने की जरूरत है क्योंकि वे JSON फ़ाइल में हैं।
आयात विशेषता आपको सामग्री की प्रतिलिपि किए बिना अन्य TEST_MAPPING फ़ाइलों में परीक्षण शामिल करने की अनुमति देती है। ध्यान दें कि आयातित पथ की मूल निर्देशिका में TEST_MAPPING फ़ाइलें भी शामिल की जाएंगी। टेस्ट मैपिंग नेस्टेड आयात की अनुमति देता है; इसका मतलब है कि दो TEST_MAPPING फ़ाइलें एक दूसरे को आयात कर सकती हैं, और टेस्ट मैपिंग शामिल परीक्षणों को ठीक से मर्ज करने में सक्षम है।
विकल्प विशेषता में अतिरिक्त ट्रेडफेड कमांड लाइन विकल्प हैं।
किसी दिए गए परीक्षण के लिए उपलब्ध विकल्पों की पूरी सूची प्राप्त करने के लिए, दौड़ें:
tradefed.sh run commandAndExit [test_module] --help
विकल्प कैसे काम करते हैं, इसके बारे में अधिक जानकारी के लिए ट्रेडफेड ऑप्शन हैंडलिंग देखें।
Atest के साथ चल रहे परीक्षण
स्थानीय रूप से पूर्व सबमिट परीक्षण नियमों को निष्पादित करने के लिए:
- TEST_MAPPING फ़ाइल वाली निर्देशिका पर जाएँ।
- कमांड चलाएँ:
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
रनिंग पोस्टसबमिट परीक्षण नियम
आप इस आदेश का उपयोग src_path (सीडब्ल्यूडी के लिए डिफ़ॉल्ट) और इसकी मूल निर्देशिकाओं में TEST_MAPPING में परिभाषित पोस्टसबमिट परीक्षण नियमों को चलाने के लिए भी कर सकते हैं:
atest [--test-mapping] [src_path]:postsubmit
केवल ऐसे परीक्षण चलाना जिनके लिए किसी उपकरण की आवश्यकता नहीं है
आप एटेस्ट के लिए विकल्प --host का उपयोग केवल उस होस्ट के विरुद्ध कॉन्फ़िगर किए गए परीक्षण चलाने के लिए कर सकते हैं जिसके लिए किसी डिवाइस की आवश्यकता नहीं है। इस विकल्प के बिना, Atest दोनों परीक्षण चलाएगा, जिनके लिए डिवाइस की आवश्यकता होती है और वे जो होस्ट पर चल रहे होते हैं और जिनके लिए किसी डिवाइस की आवश्यकता नहीं होती है। परीक्षण दो अलग-अलग सुइट्स में चलाए जाएंगे।
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 फ़ाइल को बाहर निकालने के लिए एक पंक्ति-स्तर // -format टिप्पणी जोड़ सकते हैं। एटेस्ट और ट्रेड फेडरेशन टिप्पणियों के बिना TEST_MAPPING को वैध JSON प्रारूप में प्रीप्रोसेस करेगा। JSON फ़ाइल को साफ़ और पढ़ने में आसान रखने के लिए, केवल लाइन-लेवल // -format टिप्पणी समर्थित है।
उदाहरण:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}