ট্রেড ফেডারেশন (সংক্ষেপে Tradefed বা TF) হল একটি কন্টিনিউয়াস টেস্ট ফ্রেমওয়ার্ক যা Android ডিভাইসে টেস্ট চালানোর জন্য ডিজাইন করা হয়েছে। যেমন, Tradefed-এর সাহায্যে কম্প্যাটিবিলিটি টেস্ট স্যুট (CTS) এবং ভেন্ডর টেস্ট স্যুট (VTS) চালানো হয়।
Trade Federation হল একটি Java অ্যাপ্লিকেশন যা হোস্ট কম্পিউটারে চলে এবং adb-এর মাধ্যমে ddmlib (DDMS-এর পেছনের লাইব্রেরি) ব্যবহার করে এক বা একাধিক Android ডিভাইসের সাথে যোগাযোগ করে।
আমরা নিচে TF-এর কিছু প্রধান ফিচার তালিকাভুক্ত করেছি, সাথে কিছু স্যাম্পেল ব্যবহারিক উদাহরণও দেওয়া হয়েছে। তবে, আপনি যদি সরাসরি শুরু করতে চান, তাহলে এখান থেকে শুরু করুন পৃষ্ঠায় যান।
ফিচার
- মডিউলার, ফ্লেক্সিবল, স্কেলেবল ডিজাইন
- এতে বিভিন্ন ধরনের Android টেস্ট চালানোর জন্য বিল্ট-ইন সহায়তা আছে: ইনস্ট্রুমেন্টেশন, uiautomator, নেটিভ/gtest, হোস্ট-ভিত্তিক JUnit ইত্যাদি
- adb-এর উপরে নির্ভরযোগ্যতা ও রিকভারি মেকানিজম প্রদান করে
- একাধিক ডিভাইসে সমান্তরালভাবে টেস্ট শিডিউল ও রান করার সুবিধা দেয়
আপনার আগে থেকে থাকা পরীক্ষা কীভাবে চালাবেন সেই সম্পর্কে সবচেয়ে আপ-টু-ডেট তথ্য পেতে, TF-এর মাধ্যমে পরীক্ষা করা দেখুন, যেমন ইনস্ট্রুমেন্টেশন।
উদাহরণ
ট্রেড ফেডারেশনের মডুলারিটি এটিকে বিদ্যমান বিল্ড, টেস্ট এবং রিপোর্টিং পরিকাঠামো সহ এনভায়রনমেন্টে স্লট করা সহজ করে তোলে। নিচে আমরা কিছু ডেমোনস্ট্রেটিভ ইউজকেস তালিকাভুক্ত করেছি যেখানে Tradefed কার্যকর, স্কেলেবল টেস্ট প্র্যাক্টিস চালু করতে পারে।
প্রথমত, প্রশ্নের ভিত্তিতে সম্ভাব্য ব্যবহারের ক্ষেত্র বিবেচনা করা দরকার "কোন অংশগুলি পরিবর্তন করা যায় এবং কোন অংশগুলি অপরিবর্তনীয়?" যেমন, কোনও ডিভাইস OEM ফ্রেমওয়ার্ক, সিস্টেম ও হার্ডওয়্যার পরিবর্তন করতে পারে, কিন্তু আগে থেকে থাকা অ্যাপ্লিকেশনের উপর এর প্রভাব খুব কম বা একেবারেই থাকে না। অন্যদিকে, অ্যাপ্লিকেশন ডেভেলপার অ্যাপটি পরিবর্তন করতে পারেন, তবে সিস্টেম বা ফ্রেমওয়ার্কের বেশিরভাগ দিকগুলির উপর তার নিয়ন্ত্রণ কম থাকে।
এর ফলে, প্রতিটি ব্যবহারের ক্ষেত্রে কোনও এন্টিটির আলাদা আলাদা টেস্টিং গোল থাকবে এবং টেস্ট ব্যর্থ হলে আলাদা আলাদা বিকল্প থাকবে। এইসব পার্থক্য থাকা সত্ত্বেও, Trade Federation তাদের প্রতিটি টেস্ট প্রসেসকে আরও দক্ষ, নমনীয় এবং স্কেলেবল করে তুলতে সাহায্য করতে পারে।
ডিভাইস OEM
ডিভাইস OEM হার্ডওয়্যার তৈরি করে এবং প্রায়শই Android সিস্টেম ও ফ্রেমওয়ার্ককে টুইক করে যাতে সেই হার্ডওয়্যারে তা ভালভাবে কাজ করে। OEM সেইসব লক্ষ্য পূরণ করার চেষ্টা করতে পারে, তবে হার্ডওয়্যার ও সিস্টেম লেভেলে স্টেবিলিটি ও পারফর্ম্যান্স বজায় রেখে এবং ফ্রেমওয়ার্কের পরিবর্তন যাতে আগে থেকে থাকা অ্যাপ্লিকেশনের সাথে মানানসই হয় তা নিশ্চিত করে।
OEM একটি ডিভাইস ফ্ল্যাশিং মডিউল প্রয়োগ করতে পারে যা লাইফসাইকেল-এর টার্গেট সেট-আপ স্টেজে চালানো হবে। এই মডিউলটি এক্সিকিউশন চলাকালীন ডিভাইসের উপর সম্পূর্ণ কন্ট্রোল পাবে, যা এটিকে সম্ভাব্যভাবে বুটলোডার, ফ্ল্যাশ করতে এবং তারপরে ডিভাইসটিকে রিবুট করে ইউজারস্পেস মোডে ফিরিয়ে আনতে বাধ্য করতে পারবে। একটি অবিচ্ছিন্ন বিল্ড সিস্টেমের সাথে যুক্ত একটি মডিউল সহ, এটি OEM-কে সিস্টেম-লেভেল ফার্মওয়্যার এবং জাভা-লেভেল ফ্রেমওয়ার্কে পরিবর্তন করার সাথে সাথে তাদের ডিভাইসে পরীক্ষা চালানোর অনুমতি দেবে।
ডিভাইস সম্পূর্ণ বুট হয়ে গেলে, OEM আগে থেকে থাকা JUnit-ভিত্তিক পরীক্ষা ব্যবহার করতে পারবে অথবা নতুন পরীক্ষা লিখতে পারবে, যাতে আগ্রহের বিষয়গুলির কার্যকারিতা যাচাই করা যায়। অবশেষে, তারা আগে থেকে থাকা পরীক্ষার ফলাফল সংক্রান্ত রিপোজিটরিকে সংযুক্ত করতে অথবা ফলাফল সরাসরি (যেমন, ইমেলের মাধ্যমে) রিপোর্ট করতে এক বা একাধিক ফলাফল রিপোর্টিং মডিউল লিখতে পারে।
অ্যাপ ডেভেলপার
অ্যাপ্লিকেশন ডেভেলপার এমন একটি অ্যাপ তৈরি করেন যা বিভিন্ন প্ল্যাটফর্ম ভার্সন ও বিভিন্ন ডিভাইসে ভালভাবে চলতে হবে। কোনও নির্দিষ্ট প্ল্যাটফর্ম ভার্সন এবং/অথবা ডিভাইসে কোনও সমস্যা হলে, একমাত্র সমাধান হল একটি ওয়ার্কঅ্যারাউন্ড যোগ করা এবং এগিয়ে যাওয়া। বড় ডেভেলপারদের ক্ষেত্রে, টেস্ট প্রসেসকে একটানা বিল্ড সিকোয়েন্সে অন্তর্ভুক্ত করা হতে পারে। ছোট ডেভেলপারদের ক্ষেত্রে, এটি সময়ের সাথে সাথে বা ম্যানুয়ালি বন্ধ করা হতে পারে।
বেশিরভাগ অ্যাপ ডেভেলপাররা TF-এ আগে থেকেই থাকা apk টেস্ট ইনস্টলেশন মডিউল ব্যবহার করেন। এমন একটি ভার্সন আছে যা লোকাল ফাইলসিস্টেম থেকে ইনস্টল হয়, পাশাপাশি এমন একটি ভার্সনও আছে যা বিল্ড পরিষেবা থেকে ডাউনলোড করা এপিকে ইনস্টল করতে পারে। এটি মনে রাখা গুরুত্বপূর্ণ যে পরের ভার্সনটি একই হোস্ট মেশিনে নির্বিচারে অনেক TF ইনস্ট্যান্সের সাথে সঠিকভাবে কাজ করা চালিয়ে যাবে।
TF একাধিক ডিভাইস নিয়ে কাজ করতে পারদর্শী হওয়ায়, যে ডিভাইসের মাধ্যমে পরীক্ষাটি করা হয়েছে সেটির ধরন অনুযায়ী প্রতিটি পরীক্ষার ফলাফলকে শ্রেণীবদ্ধ করা সহজ হবে। এইভাবে, TF, অ্যাপ্লিকেশনের প্রতিটি বিল্ডের জন্য সম্ভাব্যভাবে একটি ২-ডাইমেনশনাল (বা মাল্টি-ডাইমেনশনাল) কম্প্যাটিবিলিটি ম্যাট্রিক্স জেনারেট করতে পারে।
পরীক্ষা পরিষেবা
যেমন, কোনও টেস্ট পরিষেবা অ্যাপ ডেভেলপারদের অ্যাপ জমা দিতে এবং অ্যাপের জন্য পাওয়ার ব্যবহার নির্ধারণ করতে, পাওয়ার-মেজারমেন্ট টুল দিয়ে ইনস্ট্রুমেন্ট করা ডিভাইসে টেস্ট চালানোর অনুমতি দিতে পারে। এটি আগের দুটি ব্যবহারের ক্ষেত্র থেকে আলাদা, কারণ পরিষেবা বিল্ডার ডিভাইস বা চলমান অ্যাপ্লিকেশন নিয়ন্ত্রণ করে না।
যেহেতু Trade Federation এমন যেকোনও Java ক্লাস রান করতে পারে যা সাধারণ
IRemoteTest ইন্টারফেস প্রয়োগ করে, তাই
ডিভাইসে রান করা টেস্ট কেসের সাথে কিছু এক্সটার্নাল হার্ডওয়্যার কোঅর্ডিনেট করতে পারে এমন ড্রাইভার লেখা
খুবই সহজ। ড্রাইভার নিজেই থ্রেড স্পন করতে, অন্যান্য সার্ভারে অনুরোধ পাঠাতে
অথবা তার প্রয়োজন মতো অন্য কিছু করতে পারে। এছাড়াও,
ফলাফল রিপোর্টিং ইন্টারফেসের
ITestInvocationListener সরলতা ও বহুমুখিতা থেকে বোঝা যায় যে,
স্ট্যান্ডার্ড ফলাফল রিপোর্টিং পাইপলাইনে
যথেচ্ছ পরীক্ষার ফলাফল (যেমন, সংখ্যাগত পাওয়ার মেট্রিক) দেখানোও একইভাবে সহজ।