মডিউল কনফিগারেশনের সামগ্রিক স্ট্রাকচার, সাধারণ Tradefed XML কনফিগারেশনের মতো একই প্যাটার্ন অনুসরণ করে, তবে কিছু বিধিনিষেধ থাকে কারণ সেগুলি একটি স্যুটের অংশ হিসেবে রান করে।
অনুমতিপ্রাপ্ত ট্যাগগুলির তালিকা
AndroidTest.xml বা আরও সাধারণভাবে মডিউল কনফিগারেশনে শুধুমাত্র নিম্নলিখিত XML ট্যাগ থাকতে পারে: target_preparer, multi_target_preparer, test এবং
metrics_collector.
যদিও তালিকাটি সীমাবদ্ধ বলে মনে হচ্ছে, এটি আপনাকে টেস্ট মডিউল সেট-আপের প্রয়োজনীয়তা এবং চালানোর জন্য টেস্টকে সঠিকভাবে সংজ্ঞায়িত করতে দেয়।
মনে রাখবেন: বিভিন্ন ট্যাগ সম্পর্কে আরও জানতে Tradefed XML কনফিগারেশন দেখুন।
build_provider বা result_reporter-এর মতো অবজেক্ট মডিউল কনফিগারেশনের
ভিতর থেকে চালানোর চেষ্টা করলে
ConfigurationException দেখাবে। মডিউলের মধ্যে থেকে এইসব
অবজেক্ট আসলে কোনও টাস্ক পারফর্ম করবে, এমন প্রত্যাশা এড়ানোর জন্য এটি করা হয়।
মডিউল কনফিগারেশনের উদাহরণ
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
এই কনফিগারেশন এমন একটি টেস্টের বর্ণনা দেয় যার জন্য CtsGestureTestCases.apk ইনস্টল করতে হবে এবং android.gesture.cts প্যাকেজের বিরুদ্ধে একটি ইন্সট্রুমেন্টেশন রান করবে।
অন্তর্ভুক্তির ট্যাগ <include> ও <template-include>
মডিউল কনফিগারেশনে <include> ও <template-include> ব্যবহার করা
উচিত নয়। এগুলি প্রত্যাশা অনুযায়ী কাজ করবে কিনা তার কোনও গ্যারেন্টি নেই।
metrics_collector ট্যাগের জন্য বিশেষ কেস
metrics_collector অনুমোদিত কিন্তু
FilePullerLogCollector
ক্লাসের মধ্যে সীমাবদ্ধ যাতে মডিউলের জন্য কোনও নির্দিষ্ট ফাইল বা ডিরেক্টরি পুল ও লগ করা যায়। আপনি কোনও নির্দিষ্ট লোকেশনে লগ রেখে থাকলে এবং
সেগুলি অটোমেটিক রিস্টোর করতে চাইলে এটি কাজে লাগে।
কনফিগারেশনের উদাহরণ:
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
বিল্ড ইনফো বা ডাউনলোড সম্পর্কে কী বলা যায়?
অনুমোদিত ট্যাগের সংজ্ঞা থেকে ভুল ধারণা হতে পারে যে, মডিউল কোনও বিল্ড তথ্য পাবে না। এটি সত্য নয়।
বিল্ড সংক্রান্ত তথ্য স্যুট-লেভেল সেট-আপ থেকে প্রদান করা হয় এবং স্যুটের সব মডিউল দ্বারা শেয়ার করা হবে। এটি স্যুটের সমস্ত মডিউল অংশ চালানোর জন্য স্যুটের জন্য একটি একক শীর্ষ-স্তরের সেটআপের অনুমতি দেয়।
যেমন, প্রতিটি
কম্প্যাটিবিলিটি টেস্ট স্যুটের (CTS)
মডিউল আলাদা আলাদাভাবে ডিভাইসের তথ্য, ধরন ইত্যাদি কোয়েরি করার পরিবর্তে, CTS
স্যুট-লেভেল সেট-আপ (cts.xml) এটি একবার করে এবং প্রতিটি মডিউল সেই
তথ্য পাবে যদি তারা এটি অনুরোধ করে।
মডিউলের অবজেক্ট যাতে বিল্ড সংক্রান্ত তথ্য পায়, তার জন্য সেগুলিকে সাধারণ Tradefed কনফিগারেশনের মতো একই কাজ করতে হবে: IBuildReceiver ইন্টারফেস প্রয়োগ করে IBuildInfo পেতে হবে। আরও বিবরণের জন্য
ডিভাইস দিয়ে পরীক্ষা করা
দেখুন।
মেটাডেটা ফিল্ড
টেস্ট মডিউলের একটি বড় সংখ্যায় কিছু metadata স্পেসিফিকেশন থাকে,
যার প্রত্যেকটির একটি অনন্য লক্ষ্য থাকে।
উদাহরণ:
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
কম্পোনেন্ট
component মেটাডেটা, মডিউলটি
যে সাধারণ Android কম্পোনেন্ট পরীক্ষা করতে চায় তা বর্ণনা করে। টেস্ট এক্সিকিউশনের উপর এর কোনও সরাসরি প্রভাব নেই; এটি
প্রাথমিকভাবে সাংগঠনিক উদ্দেশ্যে ব্যবহার করা হয়।
CTS-এর জন্য অনুমোদিত কম্পোনেন্টগুলির আপ-টু-ডেট তালিকা CtsConfigLoadingTest-এ উপলভ্য। CTS মডিউলে অস্তিত্ব নেই এমন কম্পোনেন্ট যোগ করা হলে, এই টেস্ট প্রি-সাবমিটে ব্যর্থ হয়।
আপনি কম্পোনেন্ট অনুযায়ী স্যুট রান ফিল্টার করতে পারবেন, এর জন্য
module-metadata-include-filter ও module-metadata-exclude-filter ব্যবহার করুন।
উদাহরণ:
--module-metadata-include-filter component framework
এই উদাহরণটি শুধুমাত্র framework
component দিয়ে টীকা দেওয়া টেস্ট মডিউলটি রান করে।
প্যারামিটার
parameter মেটাডেটা তথ্যমূলক এবং টেস্ট এক্সিকিউশনকে
প্রভাবিত করে। এটি নির্দিষ্ট করে যে টেস্ট মডিউলটি কোন Android মোডে প্রযোজ্য।
এই ক্ষেত্রে, মোড, Android-এর হাই লেভেল মোডের মধ্যে সীমাবদ্ধ থাকে, যেমন
instant apps, secondary users বা different abis।
সুইট রান করার সময়, মোডটি টেস্টের ক্ষেত্রে প্রযোজ্য হলে, মোডের উপর ভিত্তি করে টেস্ট মডিউলের বিভিন্ন ভেরিয়েশন তৈরি করা হয়। প্রতিটি ভেরিয়েন্ট একই ধরনের পরীক্ষা চালায় তবে আলাদা আলাদা মোডে।
instant_app: এমন একটি পরীক্ষার ভেরিয়েশন তৈরি করুন যা ইনস্ট্যান্ট অ্যাপ হিসেবে APK ইনস্টল করে।multi_abi: ডিভাইসে কাজ করে এমন প্রতিটি ABI-এর জন্য টেস্টের একটি করে ভেরিয়েশন তৈরি করুন।secondary_user: APK ইনস্টল করে এবং সেকেন্ডারি ব্যবহারকারী হিসেবে টেস্ট রান করে এমন টেস্টের একটি ভেরিয়েশন তৈরি করুন।
পারফর্ম্যান্স টেস্ট মডিউলের জন্য মেট্রিক সংগ্রহ ও পোস্ট-প্রসেসিং
পারফর্ম্যান্স টেস্ট মডিউলের জন্য, মডিউল-লেভেল metrics_collector এবং
metric_post_processor ব্যবহার করা যায় কারণ সেগুলি পারফর্ম্যান্স টেস্টের জন্য অপরিহার্য।
মডিউল-লেভেল মেট্রিক কালেক্টর ও পোস্ট-প্রসেসর মডিউল-নির্দিষ্ট হতে পারে।
টপ-লেভেল ও মডিউল-লেভেল, এই দু'টি জায়গাতেই পোস্ট-প্রসেসর নির্দিষ্ট করার
সাজেস্ট করা হয় না।
পারফর্ম্যান্স টেস্ট মডিউল কনফিগারেশনে test-type মেটাডেটা
এবং performance ভ্যালু থাকতে হবে, যেমন:
xml
<option name="config-descriptor:metadata" key="test-type" value="performance" />
এটি না থাকলে, টেস্ট কনফিগারেশনে FilePullerLogCollector বা metric_post_processor ছাড়া অন্য কোনও metric_collector থাকলে, টেস্ট
প্রিসাবমিট করার সময় ফেল করে যাবে।
পারফর্ম্যান্স টেস্ট মডিউল কনফিগারেশনের উদাহরণ:
<configuration description="Runs sample performance test.">
<!-- Declare as a performance test module -->
<option name="config-descriptor:metadata" key="test-type" value="performance" />
<option name="test-tag" value="hello-world-performance-test" />
<test class="com.android.tradefed.testtype.HostTest" >
<option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
</test>
<!-- Add module-level post processor MetricFilePostProcessor -->
<metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
<option name="aggregate-similar-tests" value="true" />
<option name="enable-per-test-log" value="false" />
</metric_post_processor>
</configuration>