এই পৃষ্ঠাটি সমস্যা সমাধানে সহায়তা প্রদান করে এবং Firebase Test Lab সাথে পরীক্ষা চালানোর বিষয়ে প্রায়শই জিজ্ঞাসিত প্রশ্নের উত্তর দেয়। পরিচিত সমস্যাগুলিও নথিভুক্ত। আপনি যা খুঁজছেন তা খুঁজে না পেলে বা অতিরিক্ত সাহায্যের প্রয়োজন হলে, Firebase Slack-এ #test-lab চ্যানেলে যোগ দিন বা Firebase সহায়তার সাথে যোগাযোগ করুন।
সমস্যা সমাধান
আপনি Test Lab ক্যাটালগে উচ্চ ক্ষমতা সম্পন্ন একটি ডিভাইস নির্বাচন করলে, পরীক্ষাগুলি দ্রুত শুরু হতে পারে। যখন একটি ডিভাইসের ক্ষমতা কম থাকে, তখন পরীক্ষা চালানোর জন্য বেশি সময় লাগতে পারে। যদি আমন্ত্রিত পরীক্ষার সংখ্যা নির্বাচিত ডিভাইসের ক্ষমতার চেয়ে অনেক বেশি হয়, তাহলে পরীক্ষাগুলি শেষ হতে আরও বেশি সময় লাগতে পারে।
যেকোনো স্তরের ডিভাইসের ক্ষমতা স্তরে চলমান পরীক্ষাগুলি নিম্নলিখিত কারণগুলির কারণে বেশি সময় নিতে পারে:
- ট্র্যাফিক, যা ডিভাইসের প্রাপ্যতা এবং পরীক্ষার গতিকে প্রভাবিত করে।
- ডিভাইস বা অবকাঠামো ব্যর্থতা, যে কোনো সময় ঘটতে পারে. Test Lab জন্য রিপোর্ট করা পরিকাঠামো আছে কিনা তা পরীক্ষা করতে, ফায়ারবেস স্ট্যাটাস ড্যাশবোর্ড দেখুন।
Test Lab ডিভাইসের ক্ষমতা সম্পর্কে আরও জানতে, Android এবং iOS এর জন্য ডিভাইসের ক্ষমতার তথ্য দেখুন।
অনিয়ন্ত্রিত পরীক্ষার ফলাফলগুলি সাধারণত বাতিল পরীক্ষা চালানো বা পরিকাঠামোগত ত্রুটির কারণে ঘটে।
পরিকাঠামোগত ত্রুটিগুলি অভ্যন্তরীণ Test Lab সমস্যার কারণে হয়, যেমন নেটওয়ার্ক ত্রুটি বা ডিভাইসের অপ্রত্যাশিত আচরণ৷ Test Lab অভ্যন্তরীণভাবে পরীক্ষা চালানোর অবসর নেয় যা একটি অনিয়মিত ফলাফলের প্রতিবেদন করার আগে একাধিকবার পরিকাঠামোগত ত্রুটি তৈরি করে; যাইহোক, আপনি failFast ব্যবহার করে এই পুনঃপ্রচারগুলি নিষ্ক্রিয় করতে পারেন।
ত্রুটির কারণ নির্ধারণ করতে, এই পদক্ষেপগুলি অনুসরণ করুন:
- Firebase স্ট্যাটাস ড্যাশবোর্ডে পরিচিত বিভ্রাটের জন্য পরীক্ষা করুন।
এটি পুনরুত্পাদনযোগ্য কিনা তা যাচাই করতে Test Lab পরীক্ষাটি পুনরায় চেষ্টা করুন।
প্রযোজ্য হলে একটি ভিন্ন ডিভাইস বা ডিভাইসের প্রকারে পরীক্ষা চালানোর চেষ্টা করুন।
সমস্যাটি অব্যাহত থাকলে, Firebase Slack-এ #test-lab চ্যানেলে Test Lab টিমের সাথে যোগাযোগ করুন।
যখন আপনার নির্দিষ্ট করা শার্ডের সংখ্যা Test Lab ব্যবহারের জন্য উপলব্ধ ডিভাইসের সংখ্যা ছাড়িয়ে যায় তখন শার্ডিংয়ের কারণে আপনার পরীক্ষাগুলি দীর্ঘতর হতে পারে৷ এই পরিস্থিতি এড়াতে, একটি ভিন্ন ডিভাইসে স্যুইচ করার চেষ্টা করুন। একটি ভিন্ন ডিভাইস নির্বাচন সম্পর্কে আরো তথ্যের জন্য, দেখুনডিভাইসের ক্ষমতা ।
আপনি যখন একটি পরীক্ষার অনুরোধ জমা দেন, আপনার অ্যাপটি প্রথমে যাচাই করা হয়, পুনরায় স্বাক্ষর করা হয়, ইত্যাদি একটি ডিভাইসে পরীক্ষা চালানোর প্রস্তুতির জন্য। সাধারণত, এই প্রক্রিয়াটি কয়েক সেকেন্ডেরও কম সময়ের মধ্যে সম্পন্ন হয়, তবে এটি আপনার অ্যাপের আকারের মতো বিষয়গুলির দ্বারা প্রভাবিত হতে পারে।
আপনার অ্যাপ প্রস্তুত হওয়ার পরে, পরীক্ষা সম্পাদনের সময়সূচী করা হয় এবং একটি সারিতে থাকে যতক্ষণ না একটি ডিভাইস এটি চালানোর জন্য প্রস্তুত হয়। যতক্ষণ না সমস্ত পরীক্ষা কার্যকর করা শেষ হয়, ততক্ষণ ম্যাট্রিক্স স্ট্যাটাস "পেন্ডিং" থাকবে (পরীক্ষা সম্পাদনগুলি সারিতে থাকুক বা সক্রিয়ভাবে চলমান থাকুক না কেন)।
পরীক্ষা সম্পাদন শেষ হওয়ার পরে, পরীক্ষা নিদর্শনগুলি ডিভাইস থেকে ডাউনলোড করা হয়, প্রক্রিয়া করা হয় এবং Cloud Storage আপলোড করা হয়। এই ধাপের সময়কাল নিদর্শনগুলির পরিমাণ এবং আকার দ্বারা প্রভাবিত হতে পারে।
টেস্ট এক্সিকিউশন আর্টিফ্যাক্ট (যেমন স্ক্রিনশট এবং লগ ফাইল) Google Cloud Storage সংরক্ষণ করা হয় এবং সরাসরি Firebase কনসোলে রেন্ডার করা হয়। যদি আপনার পরীক্ষাটি গত 90 দিনের মধ্যে সঞ্চালিত হয়, তবে আপনি প্রকল্প স্তরের ভূমিকা (প্রকল্প মালিক, প্রকল্প সম্পাদক, বা প্রকল্প দর্শক) বরাদ্দ করেছেন কিনা তা পরীক্ষা করুন৷ অনুগ্রহ করে নিশ্চিত করুন যে ক্লাউড অডিট লগিং আপনার প্রকল্প বা আপনার সংস্থার জন্য সক্ষম নয়৷
যদি মৃত্যুদন্ড 90 দিনের বেশি আগে সঞ্চালিত হয়, তাহলে সম্ভবত পরীক্ষার আর্টিফ্যাক্টগুলি স্বয়ংক্রিয়ভাবে মুছে ফেলা হয়েছে। আপনি Test Lab ড্যাশবোর্ডে পরীক্ষার ফলাফল ট্যাবে ক্লিক করে ফলাফল বালতি কনফিগারেশন পরীক্ষা করতে পারেন। ডিফল্ট ফলাফল বালতি 90 দিনের জন্য বস্তু ধরে রাখার জন্য কনফিগার করা হয়.
আপনার পরীক্ষার আর্টিফ্যাক্টগুলিকে দীর্ঘক্ষণ ধরে রাখতে, ফ্ল্যাগ --results-bucket সহ gcloud firebase test android run কমান্ডটি চালান এবং ফলাফলের বালতির নামে পাস করুন৷ আরও তথ্যের জন্য, gcloud firebase test android run রেফারেন্স ডকুমেন্টেশন দেখুন।
আপনি যখন ইন্সট্রুমেন্টেশন পরীক্ষা চালান, তখন আপনি পরীক্ষার ত্রুটিগুলি দেখতে পাবেন যা আংশিক ফলাফলগুলি নির্দেশ করে যাতে Test run failed to complete. Expected x tests, received y (যেখানে y x এর চেয়ে কম)। এই ত্রুটির মানে হল যে Test Lab টেস্ট কেস শুরু বা শেষ মার্কারগুলির জন্য লগক্যাট পার্স করতে পারেনি যা সাধারণত AndroidJUnitRunner দ্বারা তৈরি হয়।
নিম্নলিখিত এই সমস্যার সাধারণ কারণ:
| সমস্যার বিবরণ | সম্ভাব্য রেজোলিউশন |
|---|---|
| সময়সীমার কারণে টেস্ট কেস চালানো হয়নি। যদি পরীক্ষার মোট সময়কাল আপনার নির্দিষ্ট সময়সীমার চেয়ে বেশি হয় বা সর্বোচ্চ টাইমআউটের চেয়ে বেশি হয়, Test Lab বাকি পরীক্ষার ক্ষেত্রে বাতিল করে দেয়। |
|
| পরীক্ষার কেসটি সম্পূর্ণ করতে ব্যর্থ হয়েছে কারণ এটি অকালে প্রস্থান করেছে বা আটকে গেছে। পরীক্ষার কেসটি অসময়ে প্রস্থান করতে পারে কারণ একটি অঘোষিত ব্যতিক্রম বা দাবী ত্রুটির কারণে। টেস্ট কেসগুলি একটি অসীম লুপে আটকে যেতে পারে বা এগোতে অক্ষম হতে পারে, উদাহরণস্বরূপ, যদি অ্যাপটি সঠিক ভিউ না দেখায় এবং টেস্ট কেস UI-তে ক্রিয়া সম্পাদন করতে না পারে। | পরীক্ষা কোথায় থামল তা তদন্ত করতে ভিডিও এবং logcat দেখুন। |
একটি কাস্টম টেস্ট রানার (এন্ড্রয়েডজুনিটরানার সম্প্রসারণ সহ) অপ্রত্যাশিতভাবে ক্র্যাশ হয়েছে বা logcat অপ্রত্যাশিত টেস্ট কেস স্টার্ট বা এন্ড মার্কার লিখেছেন৷ | আপনার পরীক্ষার রানার কোড পরীক্ষা করুন. |
logcat এ অত্যধিক লগ লেখা হয়েছে, যা বাফারকে অভিভূত করেছে বা logcat প্রক্রিয়াটি ক্র্যাশ করেছে। | logcat লেখা কমিয়ে দিন। |
| পরীক্ষার অধীনে অ্যাপটি ক্র্যাশ হয়েছে। | আপনার অ্যাপ ডিবাগ করুন। |
প্রায়শই জিজ্ঞাসিত প্রশ্ন
Firebase Test Lab ডিভাইসে পরীক্ষা করার জন্য এবং ক্লাউড API ব্যবহার করার জন্য বিনা খরচে কোটা অফার করে। মনে রাখবেন টেস্টিং কোটা স্ট্যান্ডার্ড ফায়ারবেস প্রাইসিং প্ল্যান ব্যবহার করে, যখন ক্লাউড API কোটা ব্যবহার করে না।
পরীক্ষার কোটা
টেস্টিং কোটা পরীক্ষা চালানোর জন্য ব্যবহৃত ডিভাইসের সংখ্যা দ্বারা নির্ধারিত হয়। ফায়ারবেস স্পার্ক প্ল্যানে ব্যবহারকারীদের জন্য কোনো খরচ ছাড়াই একটি নির্দিষ্ট পরীক্ষার কোটা রয়েছে। ব্লেজ প্ল্যানের জন্য, সময়ের সাথে সাথে আপনার Google ক্লাউডের ব্যবহার বাড়লে আপনার কোটা বাড়তে পারে। আপনি যদি আপনার টেস্টিং কোটায় পৌঁছে যান, তাহলে পরের দিন পর্যন্ত অপেক্ষা করুন বা আপনি যদি বর্তমানে স্পার্ক প্ল্যানে থাকেন তাহলে Blaze প্ল্যানে আপগ্রেড করুন। আপনি যদি ইতিমধ্যেই ব্লেজ প্ল্যানে থাকেন, আপনি কোটা বৃদ্ধির জন্য অনুরোধ করতে পারেন। আরও তথ্যের জন্য, পরীক্ষা কোটা দেখুন।
আপনি Google Cloud কনসোলে আপনার পরীক্ষার কোটা ব্যবহার নিরীক্ষণ করতে পারেন৷
ক্লাউড টেস্টিং API কোটা
ক্লাউড টেস্টিং এপিআই দুটি কোটা সীমা সহ আসে: প্রতি প্রকল্প প্রতি দিন অনুরোধ, এবং প্রতি প্রকল্প প্রতি 100 সেকেন্ড প্রতি অনুরোধ। আপনি Google Cloud কনসোলে আপনার ব্যবহার নিরীক্ষণ করতে পারেন।
ক্লাউড টুল ফলাফল API কোটা
ক্লাউড টুল রেজাল্ট এপিআই দুটি কোটা সীমার সাথে আসে: প্রতি প্রোজেক্ট প্রতি দিন ক্যোয়ারী, এবং প্রতি প্রোজেক্ট প্রতি 100 সেকেন্ড প্রতি ক্যোয়ারী। আপনি Google Cloud কনসোলে আপনার ব্যবহার নিরীক্ষণ করতে পারেন।
API সীমা সম্পর্কে আরও তথ্যের জন্য Test Lab জন্য ক্লাউড API কোটা পড়ুন। আপনি যদি একটি API কোটায় পৌঁছে থাকেন:
Google Cloud কনসোলে সরাসরি আপনার কোটা সম্পাদনা করে উচ্চতর কোটার জন্য একটি অনুরোধ জমা দিন (মনে রাখবেন যে বেশিরভাগ সীমা ডিফল্টরূপে সর্বাধিক সেট করা থাকে), অথবা
Google Cloud কনসোলে একটি অনুরোধ ফর্ম পূরণ করে বা Firebase সহায়তার সাথে যোগাযোগ করে উচ্চতর API কোটার অনুরোধ করুন।
আপনার ব্যাকএন্ড থেকে, আপনি আমাদের আইপি রেঞ্জের বিপরীতে সোর্স আইপি অ্যাড্রেস চেক করে Firebase-হোস্ট করা টেস্ট ডিভাইস থেকে ট্রাফিক আসছে কিনা তা নির্ধারণ করতে পারেন।
Test Lab VPC-SC-এর সাথে কাজ করে না, যা Test Lab অভ্যন্তরীণ সঞ্চয়স্থান এবং ব্যবহারকারীদের ফলাফলের বালতিগুলির মধ্যে অ্যাপ এবং অন্যান্য পরীক্ষার নিদর্শনগুলির অনুলিপি ব্লক করে।
আপনার পরীক্ষায় অস্পষ্ট আচরণ সনাক্ত করতে, আমরা ব্যবহার করার পরামর্শ দিই--সংখ্যা-ফ্ল্যাকি-পরীক্ষা-প্রচেষ্টাবিকল্প ডিফ্লেক পুনঃরানগুলিকে আপনার দৈনিক কোটার জন্য বিল করা হয় বা গণনা করা হয় সাধারণ পরীক্ষা সম্পাদনের মতোই।
নিম্নলিখিত মনে রাখবেন:
- একটি ব্যর্থতা সনাক্ত করা হলে সম্পূর্ণ পরীক্ষা সম্পাদন আবার সঞ্চালিত হয়। শুধুমাত্র ব্যর্থ পরীক্ষার ক্ষেত্রে পুনরায় চেষ্টা করার জন্য কোন সমর্থন নেই।
- Deflake পুনরায় চেষ্টা চালানো একই সময়ে চালানোর জন্য নির্ধারিত হয়, কিন্তু সমান্তরালভাবে চালানোর নিশ্চয়তা দেওয়া হয় না, উদাহরণস্বরূপ, যখন ট্র্যাফিক উপলব্ধ ডিভাইসের সংখ্যা অতিক্রম করে।
হ্যাঁ! Test Lab গুগল পিক্সেল ওয়াচ সমর্থন করে। আপনি এখন Google Pixel ঘড়িতে আপনার স্বতন্ত্র পরিধান অ্যাপে পরীক্ষা চালাতে পারেন। Test Lab ডিভাইস সম্পর্কে আরও জানতে, উপলব্ধ ডিভাইসে পরীক্ষা দেখুন।
হ্যাঁ! Test Lab গুগল পিক্সেল ট্যাবলেট এবং গুগল পিক্সেল ফোল্ড সমর্থন করে। আপনি আপনার স্বতন্ত্র শারীরিক ডিভাইসে আপনার পরীক্ষা চালাতে পারেন। Test Lab ডিভাইস সম্পর্কে আরও জানতে, উপলব্ধ ডিভাইসে পরীক্ষা দেখুন।
আপনি যদি Firebase-এ আপনার অ্যাপ পরীক্ষা করছেন বা প্লে কনসোলে প্রি-লঞ্চ রিপোর্টের জন্য পরীক্ষা চালাচ্ছেন, তাহলে আপনি firebase.test.lab এ সিস্টেম প্রপার্টি পরীক্ষা করে একটি Firebase-হোস্ট করা ডিভাইসে পরীক্ষা চালানো হচ্ছে কিনা তা শনাক্ত করতে পারেন আপনার MainActivity ফাইল। তারপর আপনি testLabSetting জন্য বুলিয়ান মানের উপর ভিত্তি করে অতিরিক্ত বিবৃতি কার্যকর করতে পারেন। আরও তথ্যের জন্য, পরিবর্তিত পরীক্ষার আচরণ দেখুন।
যদিও এই আইটেমগুলির কিছু আমাদের রোডম্যাপে রয়েছে, আমরা বর্তমানে এই টেস্টিং এবং অ্যাপ ডেভেলপমেন্ট প্ল্যাটফর্মগুলিকে সমর্থন করার প্রতিশ্রুতি প্রদান করতে অক্ষম। যাইহোক, যদি আপনি Espresso সমর্থন করে এমন একটি ফ্রেমওয়ার্ক দিয়ে আপনার অ্যাপ তৈরি করেন (উদাহরণস্বরূপ, Flutter), আপনি Espresso ব্যবহার করে একটি ইন্সট্রুমেন্টেশন পরীক্ষা লিখতে পারেন এবং তারপর Test Lab পরীক্ষা চালাতে পারেন।
Test Lab স্পষ্টভাবে অস্পষ্টতা বা ডিঅফসকেশনের জন্য সমর্থন করে না। অ্যাপটি চালানোর সময়, যেকোন অস্পষ্ট অ্যাপ ডেটা, যেমন স্ট্যাক ট্রেস, লগগুলিতে অস্পষ্ট হিসাবে প্রদর্শিত হবে।
হ্যাঁ! আপনি আপনার ভাঁজযোগ্য ডিভাইসটি ভাঁজযোগ্য অবস্থায় এবং ভঙ্গিতে পরীক্ষা করতে পারেন।
ভাঁজযোগ্য ডিভাইসগুলি বিভিন্ন ভাঁজ অবস্থায় থাকতে পারে, যেমন FLAT (সম্পূর্ণ খোলা) বা HALF_OPENED (সম্পূর্ণ খোলা এবং সম্পূর্ণ বন্ধের মধ্যে)।
অন্যদিকে, ভঙ্গিগুলি নির্দিষ্ট ডিভাইসের অভিযোজন এবং ভাঁজযোগ্য অবস্থা নিয়ে গঠিত। উদাহরণস্বরূপ, ট্যাবলেটপ ভঙ্গি, যা অনুভূমিক অভিযোজনে একটি HALF_OPENED অবস্থা, বা বুক ভঙ্গি, যা উল্লম্ব অভিযোজনে একটি HALF_OPENED অবস্থা।
আপনি যদি ইন্সট্রুমেন্টেশন পরীক্ষা চালাচ্ছেন, আপনি Jetpack WindowManager লাইব্রেরি ব্যবহার করতে পারেন এবং বিভিন্ন অবস্থা এবং ভঙ্গিতে পরীক্ষা করার জন্য আপনার অ্যাপকে ফোল্ডেবল ডকুমেন্টেশনে পরীক্ষা করতে পারেন।
বিকল্পভাবে, উপলব্ধ অবস্থাগুলি ডিভাইস-নির্দিষ্ট এবং adb shell command cmd device_state ব্যবহার করে ইন্টারঅ্যাক্ট করা যেতে পারে।
- বর্তমান অবস্থার তালিকা করতে,
adb shell cmd device_state stateচালান। - বর্তমান অবস্থা সেট করতে বা ওভাররাইড করতে,
adb shell cmd device_state state <IDENTIFIER>চালান। - স্টেট রিসেট করতে,
adb shell cmd device_state state resetচালান। - উপলব্ধ অবস্থাগুলি পরীক্ষা করতে, ভাঁজযোগ্য ডিভাইসে
adb shell cmd device_state print-statesকমান্ডটি চালান।
গুগল পিক্সেল ফোল্ড (মডেল আইডি felix )
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSED', app_accessible=true}, DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true}, DeviceState{identifier=2, name='OPENED', app_accessible=true}, DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true}, ]
Samsung Galaxy Z Fold4 (মডেল আইডি q4q )
$ adb shell cmd device_state print-states Supported states: [ DeviceState{identifier=0, name='CLOSE', app_accessible=true}, DeviceState{identifier=1, name='TENT', app_accessible=true}, DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true}, DeviceState{identifier=3, name='OPEN', app_accessible=true}, ]
অন্যান্য ফায়ারবেস পণ্যের বিপরীতে, Test Lab ব্যবহার করার জন্য আপনাকে একটি Firebase SDK যোগ করতে হবে না। যদি আপনার কাছে ইতিমধ্যেই কোনো অ্যাপ না থাকে, তাহলে আপনি অনলাইনে একটি APK ডাউনলোড করতে পারেন বা AndroidX GitHub সংগ্রহস্থলের একটি নমুনা থেকে একটি অ্যাপ এবং একটি পরীক্ষামূলক APK তৈরি করতে পারেন। মনে রাখবেন যে একটি রোবো পরীক্ষা চালানোর জন্য আপনার শুধুমাত্র আপনার অ্যাপের APK ফাইলের প্রয়োজন, যখন একটি ইন্সট্রুমেন্টেশন টেস্টের জন্য একটি অ্যাপ এবং একটি পরীক্ষা APK উভয়ই প্রয়োজন যা সোর্স কোড থেকে তৈরি। আরও তথ্যের জন্য, ইনস্ট্রুমেন্টেড পরীক্ষা সম্পর্কে পড়ুন।
Test Lab বৈশিষ্ট্যগুলি সম্পর্কে আরও জানতে, Firebase Test Lab সাথে Android এর জন্য পরীক্ষা শুরু করুন দেখুন৷
স্ক্রিনশট-ডিফ টেস্টিং যেখানে প্রত্যাশিত আচরণের প্রতিনিধিত্বকারী সোনালী চিত্রগুলির সাথে একটি পরীক্ষা চালানোর সময় প্রাপ্ত স্ক্রীন চিত্রগুলির তুলনা করার উপর ভিত্তি করে পরীক্ষার দাবি করা হয়। এই ধরনের পরীক্ষাগুলি অন্যদের তুলনায় কিছু ডিভাইসের প্রকারে আরও ভঙ্গুর হতে পারে। আমরা এই ধরনের পরীক্ষার জন্য Arm ( *.arm ) এমুলেটর ডিভাইসগুলিকে লক্ষ্য করার পরামর্শ দিই। আর্ম এমুলেটর ডিভাইসগুলি এমন ছবি ব্যবহার করে যা অ্যান্ড্রয়েড স্টুডিও 'জেনারিক' এমুলেটরগুলির সাথে খুব মিল বা অভিন্ন।
আমরা আপনাকে পরীক্ষা লাইব্রেরিগুলি তদন্ত করার পরামর্শ দিই যা প্রত্যাশিত পরিবর্তনের উপস্থিতিতে স্ক্রিনশট পরীক্ষাগুলিকে আরও শক্তিশালী করতে সহায়তা করতে পারে।
হ্যাঁ! নিম্নলিখিত পরিবর্তনগুলি করা হলে ভার্চুয়াল ডিভাইসগুলি আপডেট করা হয়:
- বিদ্যমান ইমেজ আপডেট
- আগের API স্তরের অবচয়
- নতুন অ্যান্ড্রয়েড API স্তর যোগ করা হয়
কভারেজ রিপোর্ট সক্রিয় করতে, coverage=true এ environmentVariables ফিল্ড যোগ করুন। আপনি যদি অ্যান্ড্রয়েড টেস্ট অর্কেস্ট্রেটর ব্যবহার করেন, তাহলে কভারেজের ফলাফল সংরক্ষণ করার জন্য আপনাকে একটি ডিরেক্টরি প্রদান করতে হবে:
--environment-variables coverage=true,coverageFilePath=/sdcard/Download/
আপনি অর্কেস্ট্রেটর ব্যবহার না করলে, আপনি একটি ফাইল পাথ নির্দিষ্ট করতে পারেন:
--environment-variables coverage=true,coverageFile=/sdcard/Download/coverage.ec
বিস্তারিত ডিভাইস তথ্য API এর মাধ্যমে উপলব্ধ এবং বর্ণনা কমান্ড ব্যবহার করে gcloud ক্লায়েন্ট থেকে অ্যাক্সেস করা যেতে পারে:
gcloud firebase test android models describe MODEL
পরিচিত সমস্যা
Robo পরীক্ষা সাইন-ইন স্ক্রীনগুলিকে বাইপাস করতে পারে না যেগুলিতে সাইন ইন করার জন্য শংসাপত্রগুলি প্রবেশের বাইরে অতিরিক্ত ব্যবহারকারীর পদক্ষেপের প্রয়োজন হয়, উদাহরণস্বরূপ, একটি ক্যাপচা সম্পূর্ণ করা।
Android UI ফ্রেমওয়ার্ক ( View , ViewGroup এবং WebView অবজেক্ট সহ) থেকে UI উপাদানগুলি ব্যবহার করে এমন অ্যাপগুলির সাথে রোবো পরীক্ষা সবচেয়ে ভাল কাজ করে। ইউনিটি গেম ইঞ্জিন ব্যবহার করে এমন অ্যাপ সহ অন্যান্য UI ফ্রেমওয়ার্ক ব্যবহার করে এমন অ্যাপ ব্যবহার করতে আপনি যদি রোবো টেস্ট ব্যবহার করেন, তাহলে প্রথম স্ক্রীনের বাইরে অন্বেষণ না করেই পরীক্ষাটি বেরিয়ে যেতে পারে।