একটি হোমওয়ার্ক প্রশ্নের মত গন্ধ।
সফ্টওয়্যার ক্ষেত্রে পরীক্ষা করা প্রয়োজন?
হ্যাঁ। একেবারে। সব স্তরে কয়েকটি বিশেষায়িত ডোমেনের বাইরে, আমরা এখনও এমন পর্যায়ে নেই যেখানে আমরা গাণিতিকভাবে আমাদের কোডগুলি নির্দিষ্ট বাগগুলির তুলনায় সঠিকভাবে প্রমাণ করতে পারি (কমপক্ষে কোনও যুক্তিসঙ্গত সময় ফ্রেমে নয়), তাই আমাদের এটির জন্য পাথর নিক্ষেপ করতে হবে কিনা তা দেখার জন্য এবং যেখানে এটি বিরতি।
যদি আমরা খুব যত্ন সহ একটি সফ্টওয়্যার তৈরি করি, তবে আমাদের কেন পরীক্ষা করা উচিত?
পরীক্ষা করা কেবল কোডিং ত্রুটিগুলি সন্ধান করার জন্য নয়। এটি নিশ্চিত করার বিষয়েও যে আপনি আপনার সমস্ত প্রয়োজনীয়তা পূরণ করেছেন এবং সামগ্রিক সিস্টেমটি প্রত্যাশা অনুযায়ী সম্পাদন করে। আমার যদি এই প্রয়োজন থাকে যে একটি ব্যর্থ লেনদেনের জন্য অবশ্যই একটি নির্দিষ্ট ত্রুটি কোডটি ফেরত আসতে হবে, তবে কার্যকারিতা বিদ্যমান এবং এটি সঠিকভাবে কাজ করে তা উভয়ই যাচাই করার জন্য আমার একটি পরীক্ষা লিখতে হবে।
এবং এটি সমস্তই অনুমান করে যে স্পেসিফিকেশন এবং নকশা সম্পূর্ণ, সঠিক এবং অভ্যন্তরীণভাবে সুসংগত, যা প্রায়শই ক্ষেত্রে হয় না। এমনকি যদি আপনি চিঠির স্পেসিফিকেশনটি পূরণ করেন এবং নকশাটি শেষ বিন্দু এবং সেমিকোলন অনুসারে অনুসরণ করেন, যদি চশমা বা নকশাটি খারাপ হয়, তবে সংহতকরণের সময় সমস্যা হতে পারে। প্রায়শই সিস্টেম বা ইন্টিগ্রেশন টেস্টিং হয় যখন আপনি জানতে পারেন যে স্পেসিফিকেশনটি নিজেই বগি এবং এটি সংশোধন করা দরকার (নীচে যুদ্ধের গল্পটি দেখুন)।
পরীক্ষার পরে আমরা কি নিশ্চিত হতে পারি যে আমরা এই লক্ষ্যটি অর্জন করেছি (পণ্য / সফ্টওয়্যার ইচ্ছানুসারে কাজ করে) কারণ আমরা এর জন্য পরীক্ষা করেছি? এটা কি সম্ভব?
না, 100% না। আমরা সহজ কোড ব্যতীত অন্য কোনও ইনপুট বা কার্যকরকরণের পাথের প্রতিটি অনুমেয় সংমিশ্রণটি পরীক্ষা করতে পারি না। আমরা সমস্ত পরিবেশগত কারণের জন্য অ্যাকাউন্ট করতে পারি না। আমরা সম্ভাব্য সমস্ত ব্যর্থতার পদ্ধতিগুলি কল্পনা করতে পারি না।
আমরা এমন এক পর্যায়ে পরীক্ষা করতে পারি যেখানে আমরা যুক্তিযুক্তভাবে নিশ্চিত যে কোনও বড় সমস্যা নেই n't আবার, এ কারণেই আমাদের সকল স্তরের পরীক্ষা করা দরকার। আপনার কোড প্রান্ত শর্তগুলি সঠিকভাবে পরিচালনা করছে তা নিশ্চিত করার জন্য পরীক্ষার একটি স্যুট লিখুন (খারাপ ইনপুট, অপ্রত্যাশিত ফলাফল, ব্যতিক্রম ইত্যাদি)। আপনার কোডটির প্রয়োজনীয়তা মেলে তা যাচাই করতে ইউনিট পরীক্ষা। প্রান্ত থেকে শেষ প্রক্রিয়াকরণ যাচাই করতে সিস্টেম পরীক্ষা। সমস্ত উপাদান একে অপরের সাথে সঠিকভাবে কথা বলে তা যাচাই করার জন্য সংহতকরণ পরীক্ষা। গ্রাহকরা আপনাকে গুলি করতে না চান যাতে পুরো জিনিসটি এমনভাবে কাজ করে তা নিশ্চিত করার জন্য ব্যবহারযোগ্যতা পরীক্ষা করুন।
রিয়েল-ওয়ার্ল্ডের পরিস্থিতি - আমি এমন একটি ব্যাক-এন্ড সিস্টেমে কাজ করছিলাম যা মাঝে মাঝে স্ক্রিনের একটি টেবিলের জন্য জিইউআই পরিষেবাতে আপডেটগুলি প্রেরণ করে। প্রকল্পের সময়, প্রদর্শনে ফিল্টারিং যুক্ত করার জন্য একটি প্রয়োজনীয়তা যুক্ত করা হয়েছিল (উদাহরণস্বরূপ, অপারেটরটি টেবিলের এন্ট্রিগুলির একটি উপসেট প্রদর্শন করতে পারেন)। ডিজাইনের ভুল # 1 - ফিলিটিংটি জিইউআই সার্ভিস দ্বারা করা উচিত ছিল (আমার কাছে এই অতুলনীয়, প্রাচীন ধারণাটি রয়েছে যে প্রদর্শন পরিচালনার কাজগুলি ডিসপ্লে ম্যানেজমেন্ট সফটওয়্যারটির দায়িত্ব হওয়া উচিত), কিন্তু রাজনীতি এবং সমস্যা হওয়ার আগে আমার অক্ষমতার কারণে সমস্যা , যে প্রয়োজনীয়তা ব্যাক-এন্ড পরিষেবাতে রাখা হয়েছিল। ভাল, ঠিক আছে, কোন সমস্যা নেই, আমি এটি করতে পারি। ফিল্টার অবস্থায় পরিবর্তন হয়, আমি একটি বার্তা পাই এবং তারপরে আমি একটি তৈরি বা বার্তা মুছে ফেলিটেবিলের প্রতিটি সারি , কারণ ইন্টারফেসটি কীভাবে এটি কাজ করে (ডিজাইনের ভুল # 2 - একক বার্তায় একাধিক সারিতে আপডেটগুলি প্রেরণের কোনও উপায় নেই; আমরা সাফ করতে কোনও "ক্লিয়ার" বা "মোছা" বার্তাও পাঠাতে পারি নি) পুরো টেবিল)।
ঠিক আছে, উন্নয়নের সময় সদাচরণের কাজ করে; ইউনিট, সিস্টেম এবং সংহতকরণ পরীক্ষা দেখায় যে আমি সঠিক তথ্য প্রেরণ করেছি এবং ফিল্টার পরিবর্তনগুলি সঠিকভাবে পরিচালনা করি। তারপর আমরা ব্যবহারযোগ্যতা টেস্টিং পেতে, এবং পুরো জিনিস নিচে পড়ে কঠিন , কারণ ডাটা ভলিউম অভিভূত ড। আমার ব্যাকএন্ড পরিষেবা এবং জিইউআইয়ের মধ্যে নেটওয়ার্ক ল্যাটেন্সিটি .15 থেকে .25 সেকেন্ডের অর্ডারে ছিল। আপনার যদি কেবলমাত্র এক ডজন সারি বা তার জন্য আপডেটগুলি প্রেরণ করতে হয় তবে খারাপ নয়। মারাত্মক যখন আপনাকে কয়েকশ'র জন্য আপডেট পাঠাতে হয়। আমরা বাগের রিপোর্ট পেতে শুরু করি যে ফিল্টারের অবস্থা পরিবর্তন করার পরে জিইউআই জমাট বাঁধছে; ঠিক আছে, না, যা ঘটছিল তা হ'ল এটি কয়েক মিনিটের ক্রম বয়ে চলেছিল ডিসপ্লে আপডেট করার জন্য কারণ হাড়ের মাথার আপডেট-সময়ে-এক-সারি-সময়ে-বার্তা প্রোটোকলটি বাস্তব-জগতের পরিস্থিতি পরিচালনা করতে পারে না।
মনে রাখবেন যে এর আগেও যদি আমরা এমনকি সবচেয়ে মৌলিক বিশ্লেষণ করতে বিরক্ত করে থাকি তবে প্রাইম ঠিকাদারের কাছ থেকে শুরু করে ছোট্ট বৃদ্ধের কাছে সমস্তই প্রত্যেকে অনুমান করা উচিত ছিল। আমি একমাত্র প্রতিরক্ষা প্রস্তাব দিচ্ছি যে আমরা ছয় মাসের একটি প্রকল্পের দ্বিতীয় বর্ষটি বন্ধ করে যাচ্ছিলাম যা প্রসবের প্রায় অবিলম্বে জোঙ্ক করা হবে, এবং আমরা সকলেই এর পেছনটি দেখতে মরিয়া হয়েছি।
যা আমাদের পরীক্ষার চূড়ান্ত কারণ নিয়ে আসে - সিওয়াইএ। রিয়েল-ওয়ার্ল্ড প্রকল্পগুলি বিভিন্ন কারণে ব্যর্থ হয়, যার মধ্যে অনেকগুলি রাজনৈতিক এবং পরিস্থিতি ভুল হয়ে গেলে সকলেই সৎ বিশ্বাসের সাথে কাজ করে না। আঙ্গুলগুলি নির্দেশিত হয়ে যায়, অভিযোগ উত্থাপিত হয় এবং দিনের শেষে আপনাকে কোনও রেকর্ডে নির্দেশ করতে সক্ষম হতে হবে যা দেখায় যে কমপক্ষে আপনার স্টাফগুলি যেমন অনুমিত হয়েছিল তেমনই কাজ করেছে।
If we create a software with care in during its development period then why should we go for Test?- কারণ যাই হোক না কেন, এমনকি সবচেয়ে দক্ষ প্রোগ্রামার ভুল করে।