মডিউল কনফিগারেশনের সামগ্রিক কাঠামো নিয়মিত ট্রেডফেড এক্সএমএল কনফিগারেশনের অনুরূপ প্যাটার্ন অনুসরণ করে কিন্তু কিছু বিধিনিষেধের কারণে তারা একটি স্যুটের অংশ হিসেবে চলে।
অনুমোদিত ট্যাগের তালিকা
AndroidTest.xml বা আরও বিস্তৃতভাবে মডিউল কনফিগারেশনে শুধুমাত্র নিম্নলিখিত XML ট্যাগ থাকতে পারে: target_preparer , multi_target_preparer , test এবং metrics_collector ।
যদিও সেই তালিকাটি সীমাবদ্ধ দেখায়, এটি আপনাকে পরীক্ষা মডিউল সেটআপের প্রয়োজনীয়তা এবং পরীক্ষা চালানোর জন্য সঠিকভাবে সংজ্ঞায়িত করতে দেয়।
দ্রষ্টব্য: আপনার যদি বিভিন্ন ট্যাগে রিফ্রেশারের প্রয়োজন হয় তবে ট্রেডফেড এক্সএমএল কনফিগারেশন দেখুন।
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.xml ) এটি একবার করে এবং প্রতিটি মডিউল অনুরোধ করলে সেই তথ্যটি গ্রহণ করবে৷
একটি মডিউলে থাকা বস্তুগুলিকে বিল্ড তথ্য পাওয়ার জন্য, তাদের নিয়মিত ট্রেডফেড কনফিগারেশনের মতো একই কাজ করতে হবে: IBuildInfo প্রাপ্ত করার জন্য IBuildReceiver ইন্টারফেস প্রয়োগ করুন। আরো বিস্তারিত জানার জন্য ডিভাইসের সাথে পরীক্ষা দেখুন।
মেটাডেটা ক্ষেত্র
বিপুল সংখ্যক পরীক্ষা মডিউলে কিছু 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 উপাদানের সাথে টীকাকৃত পরীক্ষা মডিউল চালায়।
প্যারামিটার
parameter মেটাডেটা তথ্যপূর্ণ এবং পরীক্ষা সম্পাদনকে প্রভাবিত করে। পরীক্ষা মডিউলটি কোন Android মোডে প্রযোজ্য তা নির্দিষ্ট করে। এই ক্ষেত্রে, মোডগুলি উচ্চ স্তরের অ্যান্ড্রয়েড মোডগুলিতে সীমাবদ্ধ, যেমন instant apps , secondary users বা different abis ।
স্যুট চালানোর সময়, যদি মোডটি পরীক্ষার জন্য প্রযোজ্য হয়, মোডের উপর ভিত্তি করে পরীক্ষার মডিউলের বিভিন্ন পরিবর্তন তৈরি করা হয়। প্রতিটি বৈচিত্র একই রকম পরীক্ষা চালায় কিন্তু বিভিন্ন মোডের অধীনে।
-
instant_app: তাত্ক্ষণিক অ্যাপ হিসাবে APK ইনস্টল করার পরীক্ষাগুলির একটি বৈচিত্র তৈরি করুন৷ -
multi_abi: ডিভাইস দ্বারা সমর্থিত প্রতিটি ABI-এর জন্য পরীক্ষার একটি ভিন্নতা তৈরি করুন। -
secondary_user: পরীক্ষার একটি ভিন্নতা তৈরি করুন যা APK ইনস্টল করে এবং সেকেন্ডারি ব্যবহারকারী হিসেবে পরীক্ষা চালায়।
কর্মক্ষমতা পরীক্ষার মডিউলগুলির জন্য মেট্রিক সংগ্রহ এবং পোস্ট-প্রসেসিং
পারফরম্যান্স পরীক্ষার মডিউলগুলির জন্য, মডিউল-স্তরের metrics_collector এবং metric_post_processor অনুমোদিত কারণ তারা কার্যক্ষমতা পরীক্ষার জন্য অপরিহার্য। মডিউল-স্তরের মেট্রিক সংগ্রাহক এবং পোস্ট-প্রসেসর মডিউল নির্দিষ্ট হতে পারে। শীর্ষ-স্তর এবং মডিউল-স্তর উভয়েই পোস্ট-প্রসেসর নির্দিষ্ট করার সুপারিশ করা হয় না।
একটি পারফরম্যান্স টেস্ট মডিউল কনফিগারেশনে অবশ্যই মান performance সহ test-type মেটাডেটা অন্তর্ভুক্ত করতে হবে, যেমন: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> এটি ছাড়া, যদি একটি পরীক্ষা config-এ 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>
মডিউল কনফিগারেশনের সামগ্রিক কাঠামো নিয়মিত ট্রেডফেড এক্সএমএল কনফিগারেশনের অনুরূপ প্যাটার্ন অনুসরণ করে কিন্তু কিছু বিধিনিষেধের কারণে তারা একটি স্যুটের অংশ হিসেবে চলে।
অনুমোদিত ট্যাগের তালিকা
AndroidTest.xml বা আরও বিস্তৃতভাবে মডিউল কনফিগারেশনে শুধুমাত্র নিম্নলিখিত XML ট্যাগ থাকতে পারে: target_preparer , multi_target_preparer , test এবং metrics_collector ।
যদিও সেই তালিকাটি সীমাবদ্ধ দেখায়, এটি আপনাকে পরীক্ষা মডিউল সেটআপের প্রয়োজনীয়তা এবং পরীক্ষা চালানোর জন্য সঠিকভাবে সংজ্ঞায়িত করতে দেয়।
দ্রষ্টব্য: আপনার যদি বিভিন্ন ট্যাগে রিফ্রেশারের প্রয়োজন হয় তবে ট্রেডফেড এক্সএমএল কনফিগারেশন দেখুন।
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.xml ) এটি একবার করে এবং প্রতিটি মডিউল অনুরোধ করলে সেই তথ্যটি গ্রহণ করবে৷
একটি মডিউলে থাকা বস্তুগুলিকে বিল্ড তথ্য পাওয়ার জন্য, তাদের নিয়মিত ট্রেডফেড কনফিগারেশনের মতো একই কাজ করতে হবে: IBuildInfo প্রাপ্ত করার জন্য IBuildReceiver ইন্টারফেস প্রয়োগ করুন। আরো বিস্তারিত জানার জন্য ডিভাইসের সাথে পরীক্ষা দেখুন।
মেটাডেটা ক্ষেত্র
বিপুল সংখ্যক পরীক্ষা মডিউলে কিছু 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 উপাদানের সাথে টীকাকৃত পরীক্ষা মডিউল চালায়।
প্যারামিটার
parameter মেটাডেটা তথ্যপূর্ণ এবং পরীক্ষা সম্পাদনকে প্রভাবিত করে। পরীক্ষা মডিউলটি কোন Android মোডে প্রযোজ্য তা নির্দিষ্ট করে। এই ক্ষেত্রে, মোডগুলি উচ্চ স্তরের অ্যান্ড্রয়েড মোডগুলিতে সীমাবদ্ধ, যেমন instant apps , secondary users বা different abis ।
স্যুট চালানোর সময়, যদি মোডটি পরীক্ষার জন্য প্রযোজ্য হয়, মোডের উপর ভিত্তি করে পরীক্ষার মডিউলের বিভিন্ন পরিবর্তন তৈরি করা হয়। প্রতিটি বৈচিত্র একই রকম পরীক্ষা চালায় কিন্তু বিভিন্ন মোডের অধীনে।
-
instant_app: তাত্ক্ষণিক অ্যাপ হিসাবে APK ইনস্টল করার পরীক্ষাগুলির একটি বৈচিত্র তৈরি করুন৷ -
multi_abi: ডিভাইস দ্বারা সমর্থিত প্রতিটি ABI-এর জন্য পরীক্ষার একটি ভিন্নতা তৈরি করুন। -
secondary_user: পরীক্ষার একটি ভিন্নতা তৈরি করুন যা APK ইনস্টল করে এবং সেকেন্ডারি ব্যবহারকারী হিসেবে পরীক্ষা চালায়।
কর্মক্ষমতা পরীক্ষার মডিউলগুলির জন্য মেট্রিক সংগ্রহ এবং পোস্ট-প্রসেসিং
পারফরম্যান্স পরীক্ষার মডিউলগুলির জন্য, মডিউল-স্তরের metrics_collector এবং metric_post_processor অনুমোদিত কারণ তারা কার্যক্ষমতা পরীক্ষার জন্য অপরিহার্য। মডিউল-স্তরের মেট্রিক সংগ্রাহক এবং পোস্ট-প্রসেসর মডিউল নির্দিষ্ট হতে পারে। শীর্ষ-স্তর এবং মডিউল-স্তর উভয়েই পোস্ট-প্রসেসর নির্দিষ্ট করার সুপারিশ করা হয় না।
একটি পারফরম্যান্স টেস্ট মডিউল কনফিগারেশনে অবশ্যই মান performance সহ test-type মেটাডেটা অন্তর্ভুক্ত করতে হবে, যেমন: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> এটি ছাড়া, যদি একটি পরীক্ষা config-এ 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>