আমাদের কি 64৪-বিট উইন্ডোতে 32-বিট সফ্টওয়্যার পরীক্ষা করা দরকার?


31

আমি সফটওয়্যার বিকাশকারী হিসাবে একটি সফটওয়্যার বিকাশ দলে কাজ করছি। আমি তিন বছর ধরে একই প্রকল্পে কাজ করছি। সফটওয়্যারটি। নেট 4 এ 32-বিট ডেস্কটপ ভিত্তিক সি # অ্যাপ্লিকেশন, উইন্ডোজ 7-এ আমাদের টার্গেট প্ল্যাটফর্ম (আমাদের গত বছর পর্যন্ত উইন্ডোজ এক্সপি সমর্থন করতে হবে)। সফ্টওয়্যারটি বিভিন্ন কাস্টম হার্ডওয়ারের সাথে যোগাযোগ করে যার জন্য কাস্টম ড্রাইভারগুলি লেখা হয়। হার্ডওয়্যার উত্পাদন এবং ড্রাইভার সফ্টওয়্যার আমাদের ক্লায়েন্ট দ্বারা রচিত। অবশ্যই 32-বিট এবং 64-বিট উইন্ডোজটির জন্য আলাদা ড্রাইভার রয়েছে।

আমাদের সিস্টেম টেস্টিংয়ের সময়, আমরা 32 / বিট এবং 64৪-বিট উইন্ডোজ both. উভয় ক্ষেত্রে সমস্ত / সর্বাধিক পরীক্ষার কেস কার্যকর করি I আমি স্মরণ করতে পারি না যে আমাদের সফ্টওয়্যারটিতে কোনও বাগ আছে যা উইন্ডোজের শুধুমাত্র একটি গন্ধে বিদ্যমান। এই অভিজ্ঞতাটি নিয়ে আমি ভাবতে শুরু করেছি, আমাদের কি সত্যিই 64-বিট উইন্ডোতে 32-বিট সফ্টওয়্যার পরীক্ষা করা দরকার?

শিল্পের মান কী?


1
আপনার .NET অ্যাপ্লিকেশনটির নেটিভ ডিএলএলগুলির উপর কোনও নির্ভরতা রয়েছে? আমি কেবলমাত্র এক প্ল্যাটফর্মে কয়েকবার পরীক্ষার দংশন করেছি যার কারণ আমি আমার সফ্টওয়্যারটির সাথে x64 নেটিভ ডিএলএলকে প্যাকেজ করতে ভুলে গেছি x64 ডিএলএল সহ। আপনি যদি নতুন কোনও তৃতীয় পক্ষের লাইব্রেরিটি ব্যবহার শুরু করেন তবে সেই লাইব্রেরিটি নেপথ্যে নেটিভ ডিএলএলগুলি পর্দার আড়ালে লোড করার চেষ্টা করতে পারে এবং এটি কোনও x86 পিসিতে ক্রাশ না হওয়া পর্যন্ত আপনি লক্ষ্য করবেন না। আমার .NET অ্যাপ্লিকেশনটি -৪-বিট মোডে চলছে কি না তার উপর ভিত্তি করে কোন ডিএলএল ব্যবহার করবে তা বেছে নেওয়ার জন্য আমার কোডও লিখতে হয়েছিল এবং সেই কোডটিও পরীক্ষা করা দরকার।
ফিলি

@ ফিল: পয়েন্টটি উল্লেখ করা হয়েছে। ডিএলএল প্রচুর বাহ্যিক গ্রন্থাগার ব্যবহার করে। আমি বিশ্বাস করি যে এই সমস্ত ডিএলএলগুলি x86 এর জন্য সংকলিত। অ্যাপ্লিকেশনটির নিজস্ব নেটিভ ডিএলএলগুলির উপর কোনও নির্ভরতা নেই, তবে এটি নেটিভ উইন 32 এপিআই কল করে।
ডোনোটালো

উত্তর:


31

64৪-বিট উইন্ডোতে 32-বিট সফ্টওয়্যার চালানোর সাথে আমরা বেশিরভাগ বাগের সফ্টওয়্যারটির অবস্থানের Program Files (x86)পরিবর্তে ( পরিবর্তে Program Files), রেজিস্ট্রি কীগুলির অবস্থানগুলি (কিছু Wow6432 নোডে পাওয়া গিয়েছিল) এর সাথে করতে হয়েছিল। আমাদের এই সমস্যাগুলি বেশিরভাগ কারণে ছিল কারণ আমাদের অন্যান্য সফ্টওয়্যার (এছাড়াও 32-বিট) এর সাথে যোগাযোগের প্রয়োজন ছিল, এবং তাই আমাদের সফ্টওয়্যারটি 32-বিট এবং 64-বিট উভয়েরই পরীক্ষা করা দরকার ...

যখন আপনার এই সমস্যাগুলি ছিল না, আমি বিশ্বাস করি যে আপনি 32-বিট মোডে স্পষ্টভাবে সংকলন করার সময় উভয় প্ল্যাটফর্মে পরীক্ষা না করা বেশ নিরাপদ। 32-বিটে সংকলিত হয়ে গেলে .NET রানটাইম 32-বিট মোডে সমস্ত কিছু চালাবে এবং এটি 32-বিট প্ল্যাটফর্মের 32-বিট মোডের মতোই কাজ করা উচিত।

মতে 64-বিট অ্যাপ্লিকেশন ( দুটিই MSDN ), 32-বিট অ্যাপ্লিকেশনের Wow64 মোডে চালান করা হয় এবং চলমান 32 বিট অ্যাপ্লিকেশন (দুটিই MSDN) আরো বিস্তারিত এই মোডে ব্যাখ্যা করে।


আপনি কি বলছেন যে 32 বিট সফটওয়্যার যদি 64 বিট ওএসে চলে, তবে ওএসের .NET 32 বিট মোডে সফটওয়্যারটি চালাবে - যা নেট। 32 নেট বিট ওএসে সফ্টওয়্যারটি চালানোর সমান? কোন ডকুমেন্টেশন আছে?
ডোনোটালো

4
@ দোনোটালো: আপনার নিজের ভিজ্যুয়াল স্টুডিও কনফিগারেশন ম্যানেজারের (বা প্রতিটি প্রকল্পের সংকলন সেটিংস) "প্ল্যাটফর্ম" নামে "x86", "x64" এবং "যে কোনও সিপিইউ" বিকল্পের সাথে নিজেকে জানাতে হবে। আপনি যখন এই স্যুইচটি পেয়েছেন, এফ 1 সম্ভবত আপনার বন্ধু।
ডক ব্রাউন 8

আমার উত্তরে ডকুমেন্টেশন যুক্ত করা হয়েছে
ডেভিড পারফার্স

1
আমাদের সবচেয়ে বড় সমস্যাটি ছিল অন্যান্য 32 বিট লাইব্রেরিগুলির সাথে চলমান .৪-বিট মেশিনে চালানোর সময় নেটগুলি সেগুলি লোড করতে ব্যর্থ হয়।
gbjbaanb

1
@gbjbaanb: আপনি অবশ্যই বোঝাতে চেয়েছিলেন, যখন আপনি প্ল্যাটফর্ম হিসাবে "x86" ব্যবহার করতে ভুলে গিয়েছিলেন।
ডক ব্রাউন

23

হার্ডওয়্যার উত্পাদন এবং ড্রাইভার সফ্টওয়্যার আমাদের ক্লায়েন্ট দ্বারা রচিত। অবশ্যই 32 বিট এবং bit৪ বিটের উইন্ডোজের জন্য আলাদা ড্রাইভার রয়েছে।

সুতরাং 32 বিট উইন্ডোতে, আপনার সফ্টওয়্যারটি একটি ড্রাইভারের সাথে কথা বলে, এবং bit৪ বিট উইন্ডোজে, এটি অন্যর সাথে কথা বলে? আসুন ধরে নেওয়া যাক সময়ে সময়ে এই ড্রাইভারগুলির নতুন সংস্করণ রয়েছে। সুতরাং আপনি যখন কেবলমাত্র 32 বিট উইন্ডোতে আপনার সফ্টওয়্যারটি পরীক্ষা করেন আপনি নিশ্চিত হতে পারবেন না যে 64 বিট ড্রাইভারের মধ্যে কিছু পার্থক্য থাকবে না যা আপনার সফ্টওয়্যার + 64 বিট ড্রাইভারের সংমিশ্রণটি ব্যর্থ করে দেবে। এবং আপনার ব্যবহারকারীর দৃষ্টিকোণ থেকে, কে দোষ দেবেন তা বিবেচ্য নয় (আপনি বা ড্রাইভারের লেখক), তারা যা দেখছেন তারা একটি অ-কার্যক্ষম সিস্টেম। সুতরাং আপনার কোডটি ত্রুটিমুক্ত থাকা সত্ত্বেও , পরীক্ষাটি bit৪ বিট ড্রাইভারের মধ্যে একটি বাগটি প্রকাশ করতে পারে এবং এইরূপ বাগ খুঁজে পাওয়া আপনাকে সঠিক ব্যবস্থা গ্রহণে সহায়তা করতে পারে (যেমন ড্রাইভারের লেখককে বাগ রিপোর্ট পাঠানো)।

অবশ্যই, আপনি যখন এই দুটি ড্রাইভার বছরের পর বছর ধরে ব্যবহার করেছেন এবং আপনি অত্যন্ত আত্মবিশ্বাসী যে আচরণটি হুবহু একইরকম, আপনি @ ডেভিড শিষ্যের উত্তরের যুক্তি অনুসরণ করে একটি প্ল্যাটফর্মের জন্য পরীক্ষাগুলি এড়িয়ে যেতে পারেন। আপস হিসাবে, আপনি যখনই নতুন ড্রাইভার সংস্করণ উপলব্ধ তখনই আপনি bit৪ বিট উইন্ডোতে পরীক্ষা চালাতে পারেন। প্রকৃতপক্ষে, এটি ড্রাইভারগুলির জটিলতা, তাদের সাথে আপনার অভিজ্ঞতা এবং তাদের মধ্যে আস্থার উপর নির্ভর করে।

কিছু অতিরিক্ত বিষয় বিবেচনা করুন:

  • আপনার ব্যবহারকারীর বেসটি সবচেয়ে বেশি কী ব্যবহার করছে? 32 বিট বা 64 বিট উইন্ডোজ? আপনি যদি কেবল একটি প্ল্যাটফর্মে পরীক্ষা করার সিদ্ধান্ত নেন, আপনার ব্যবহারকারীরা প্রায়শই ব্যবহার করেন এমন একটি চয়ন করুন।
  • যখন সফ্টওয়্যারটির নতুন প্রকাশটি কম ঘন ঘন ব্যবহৃত প্ল্যাটফর্মটিতে কাজ করবে না তখন তা কতটা তীব্র? উদাহরণস্বরূপ, আপনার গ্রাহকরা তাত্ক্ষণিক পিছনে ফিরে যেতে পারেন এবং পূর্ববর্তী কার্যের রিলিজ ইনস্টল করতে পারেন? এটির দ্বারা কি তাদের কেবল কিছু অসুবিধা বা আসল আর্থিক ক্ষতি হয়? যদি এটি প্রাক্তন হয় তবে কেবলমাত্র একটি প্ল্যাটফর্মে পরীক্ষা করা ভাল হতে পারে, যদি এটি পরে হয় তবে স্পষ্টতই তা নয়।

16

আলোকিত QA চেনাশোনাগুলির ডিফল্ট অনুমান "যদি আপনি এটি পরীক্ষা না করে থাকেন তবে এটি কার্যকর হয় না"।

একটি ব্যবহারিক বিষয় হিসাবে যা সাধারণত অদম্য লক্ষ্য হিসাবে চেষ্টা করা যায় ঠিক তেমনভাবে অ্যাপ্লিকেশন ইঞ্জিনিয়াররা সমস্ত কিছুর জন্য ইউনিট-পরীক্ষা করতে পছন্দ করতে পারেন; তবে তারা বিশ্বাস করে না যে তারা কখনই এটি পৌঁছে যাবে এবং নির্ধারিত সময়ে প্রকাশ করবে।

তবে আপনার প্রশ্নের উত্তর কেবল বিক্রয় বা বিপণনের সাথেই দেওয়া যেতে পারে। আপনি তাদের পরীক্ষা করার জন্য একটি ব্যয় সরবরাহ করেন এবং তারা বাজার উপকারের বিশ্লেষণ সরবরাহ করে। যদি উভয় পক্ষের অনুমানগুলি যথেষ্ট সঠিক হয় তবে উত্তরটি সহজ হবে

if B > C:
    test_32bit_version()

আমার অভিজ্ঞতায়, প্রত্যেকের ব্যয়ের অনুমান সঠিক। সমীকরণের অপর দিক পর্যন্ত, দিলবার্ট একবার "আমি কেবল আমার বিড়ালকে, মিটেনসকে জিজ্ঞাসা করেছি" দিয়ে সেখানে সিদ্ধান্ত গ্রহণ করেছিলেন। আরও ভাল করার জন্য তাদের নৃতাত্ত্বিক ক্ষেত্র পদ্ধতিগুলির প্রশিক্ষণ প্রয়োজন।


আলোকিত QA চেনাশোনাগুলির ডিফল্ট অনুমান "যদি আপনি এটি পরীক্ষা না করে থাকেন তবে এটি কার্যকর হয় না"। - এবং অপারেশন চেনাশোনাগুলিতে ডিফল্ট অনুমান "যদি আপনি এটি পরীক্ষা না করে থাকেন তবে রাগান্বিত সিসাদমিনদের দ্বারা হস্তক্ষেপ করার মতো প্রস্তুত হতে প্রস্তুত থাকুন"। সমস্ত পরিস্থিতিতে পরীক্ষা করা শক্ত কিন্তু সমস্ত যুক্তিসঙ্গত বিষয়গুলির পরীক্ষা করার জন্য কঠোর চেষ্টা করা ভাল ধারণা। এটি খুব বিরল যে কোনও প্রকল্পের পোস্ট মর্টেম শেষ করে সিদ্ধান্ত নিচ্ছে যে কোনও সিস্টেমের সঠিকভাবে পরীক্ষা করতে ব্যয় করা সময় নষ্ট হয়।
রব মোয়ার

6

উইন্ডোজ and এবং তারও বেশি সমস্ত উইন্ডোজের ?৯% ইনস্টলেশন এবং ভিস্তার একটি ভাল অংশ 64৪ বিট, আপনি কেন এই প্ল্যাটফর্মের জন্য পরীক্ষার বিষয়টি বিবেচনা করবেন না?
এটি কেবলমাত্র কোনও মস্তিষ্কের, যদি না আপনি নির্দিষ্ট পরিমাণ সীমিত ব্যবহারকারীদের জন্য নির্দিষ্ট করে থাকেন তবে আপনি জানেন যে 32 বিট উইন্ডোজ ব্যবহার করছেন এবং আপনার পণ্যটির জীবনযাত্রায় এটি চালিয়ে যাবেন।

হ্যাঁ, 64 বিট সমস্যার জন্য পরীক্ষা করুন। প্রকৃতপক্ষে bit৪ বিট প্ল্যাটফর্মগুলিতে বিকাশ করুন এবং সম্ভবত 6-৪ বিট সংকলিত সংস্করণ সহ version৪ বিট সংস্করণ সরবরাহ করুন এমন কয়েকটি গ্রাহক যারা গত 6--৮ বছরে বা নতুন কম্পিউটারে ওএসে আপগ্রেড করেননি তাদের বিকল্প হিসাবে একটি বিকল্প হিসাবে 32 বিট সংকলিত সংস্করণ সরবরাহ করুন ।


1
আমি বেশিরভাগ ক্ষেত্রে সম্মতি জানাই, তবে 32 এবং 64 বিট উভয় সংস্করণ সরবরাহ করা জটিলতা যুক্ত করে এবং সম্ভবত সম্পাদন বা কার্যকারিতার উপর ভিত্তি করে কোনও ভাল যুক্তি ছাড়াই করা উচিত নয়।

4
আমি 32 বিট বাইনারি সরবরাহ করার প্রয়োজনীয়তাটি বুঝতে পারি। আমি কেবল জানি না যে তাকে কোনও বাধ্যতামূলক কারণ ছাড়াই দেশীয় bit৪ বিট সরবরাহ করতে বিরক্ত করা উচিত কিনা।

1
আমি যদি 2014 এ এখানে ডেস্কটপ সফ্টওয়্যার প্রকাশ করছিলাম তবে আমি সম্ভবত কেবলমাত্র 64 বিট বাইনারি প্রকাশ করতাম। 90 এর দশকে মনে রাখবেন যখন লোকেরা ডস থেকে উইন্ডোজ 95 এ রূপান্তর করছিল? আমাদের তখন একটি অনুরূপ যুক্তি ছিল - এবং স্পষ্টতই ডসটি ধূলিকণায় ছেড়ে যায়, ঠিক এখন 32 বিট যেমন রয়েছে (কমপক্ষে ডেস্কটপে, এমবেডেড বা মোবাইল নয়)।

4
আমি অবশ্যই @ জেন্টিং জিজ্ঞাসা করব। আপনি এটি কোথায় পেয়েছেন যে এটি 99%? আপনি কি উন্নত করতে পারেন এবং উত্স পোস্ট করতে পারেন?
মালভোস

1
হ্যাঁ, আমি মোটেও 99% বিশ্বাস করি না। ব্যবসা বিশ্বের এখনও একটি হয়েছে অনেক অসামঞ্জস্যপূর্ণ ভয়ে সেখানে আউট 32 বিট উইন্ডোজ ইনস্টলেশনের, পুরাতন মেশিনের মধ্যে আপডেট করা (প্রথম দিন থেকে Win7 চলমান) অথবা বাইরে। "সংখ্যাগরিষ্ঠ" সম্ভবত bit৪ বিট, তবে খুব ভাল প্রমাণ ছাড়াই খুব উচ্চ শতাংশে বিশ্বাস করার আমি খুব সম্ভাবনা পাব।
জো

2

আমার অভিজ্ঞতা থেকে যতটা সম্ভব বিভিন্ন উইন্ডোজ সেটআপগুলিতে যেকোন ইনস্টলারকে পরীক্ষা করে দেখব ইনস্টলাররা বিভিন্ন সিস্টেমে ব্যর্থ হওয়ার সম্ভাবনা বেশি থাকে।

অন্যথায়, যেমন আপনি প্রদত্ত সফ্টওয়্যারটি দিয়ে আপনার অভিজ্ঞতা থেকে জানেন , ত্রুটিগুলি কেবল 32-বিট বা 64৪-বিটের উপরে প্রদর্শিত হবে না এবং আপনি কিছু গণনা ঝুঁকি নিতে পারেন।

প্রথমত, আপনি শিপিংয়ের কাছাকাছি আসার সাথে সাথে পরবর্তী চক্রগুলির মধ্যে খুব অল্প কোড পরিবর্তনের সাথে আপনার অনেক পরীক্ষা চক্র হওয়া উচিত। যে কোনও সময় আপনি সংরক্ষণ করতে পারেন, আপনি আরও পরীক্ষার কেস তৈরি করতে এবং / অথবা আরও (এবং তাই আরও ছোট) চক্রকে অনুমতি দিতে ব্যবহার করতে পারেন, যাতে দ্রুত প্রতিক্রিয়া জানানো হয়। (এক্স পরীক্ষায় সময় ব্যয় করার ঝুঁকি ওয়াই পরীক্ষা না করার ঝুঁকির চেয়ে বেশি হতে পারে, কারণ আপনি এক্সকে খুব বেশি পরীক্ষা করছেন))

অতএব

  • অগ্রসরমান পরীক্ষা চক্রের জন্য আপনি কী ব্যবহার করেছেন তা "অন্যান্য সাক্ষ্য" পরীক্ষা করার চেষ্টা করুন।
  • আপনি যদি আপনার বিকাশকারী "বেনসেন্ট" ব্যবহার করেন তা জানেন, তবে অন্য একটিতে পরীক্ষা শুরু করুন।
  • প্রতিটি ক্ষেত্রে কভারেজ দেওয়ার জন্য পরীক্ষার কেসগুলিকে "বেনসেন্ট" এর মধ্যে ভাগ করুন
  • তবে এগুলি প্রতিটি পরীক্ষার চক্রের "বাইনস" এর মধ্যে বদলান।

2

নাঃ। তেমনিভাবে, যখন এফডিএ ইঁদুর এবং ইঁদুরগুলিতে নতুন ওষুধের পরীক্ষা করা হয়, তখন তারা বানরদের উপর পরীক্ষা চালিয়ে যায় এবং কেবল এটি মানুষের ব্যবহারের জন্য বিক্রি করে।

</ বিদ্রূপ>

হ্যাঁ, হ্যাঁ হ্যাঁ হ্যাঁ, হ্যাঁ। আপনি যতটা সম্ভব প্ল্যাটফর্ম পরীক্ষা না করেন তবে আপনার সফ্টওয়্যারটির জন্য সঞ্চয় করার জন্য দুঃখ ছাড়া আর কিছুই নেই। বিষয়গুলি সর্বদা পৃথক থাকে এবং প্রকল্পের সময় ডিজাইনার / কোডারের মাথায় অনুমানগুলি কেবলমাত্র বাস্তব জীবনের মডেলিংয়ের কাছাকাছি চলে আসে। সুতরাং দয়া করে, আপনার সফ্টওয়্যার পরীক্ষা করুন। অনুগ্রহ.

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.