স্বয়ংক্রিয় ইউনিট পরীক্ষা, সংহতকরণ পরীক্ষা বা গ্রহণযোগ্যতা পরীক্ষা [বন্ধ]


29

এই মুহুর্তে টিডিডি এবং ইউনিট টেস্টিংয়ের বিষয়টি মনে হয় বড় র্যাভ। তবে স্বয়ংক্রিয় পরীক্ষার অন্যান্য ফর্মের সাথে তুলনা করা কি আসলেই দরকারী?

স্বজ্ঞাতভাবে আমি অনুমান করব যে স্বয়ংক্রিয় ইন্টিগ্রেশন পরীক্ষা ইউনিট পরীক্ষার চেয়ে আরও কার্যকর useful আমার অভিজ্ঞতায় সর্বাধিক বাগগুলি মডিউলগুলির মধ্যে মিথস্ক্রিয়ায় দেখা গেছে এবং প্রতিটি ইউনিটের প্রকৃত (স্বাভাবিক সীমিত) যুক্তি এতটা নয়। এছাড়াও মডিউলগুলির মধ্যে ইন্টারফেস পরিবর্তন করার কারণে (এবং প্রাক এবং পূর্ববর্তী অবস্থার পরিবর্তন হয়েছে reg

আমি কি কিছু ভুল বুঝছি, বা ইউনিট টেস্টিং কেন ইন্টিগ্রেশন পরীক্ষার তুলনায় এত বেশি ফোকাস পাচ্ছে? এটি কেবলমাত্র কারণেই অনুমান করা হয় যে ইন্টিগ্রেশন টেস্টিং আপনার কাছে রয়েছে এবং ইউনিট টেস্টিং পরবর্তী বিষয় যা আমাদের বিকাশকারী হিসাবে প্রয়োগ করা শিখতে হবে?

অথবা সম্ভবত ইউনিট টেস্টিং এটিকে স্বয়ংক্রিয় করার জটিলতার তুলনায় কেবল সর্বোচ্চ লাভ দেয়?

স্বয়ংক্রিয় ইউনিট টেস্টিং, স্বয়ংক্রিয় ইন্টিগ্রেশন টেস্টিং, এবং স্বয়ংক্রিয় স্বীকৃতি পরীক্ষার সাথে আপনার কী অভিজ্ঞতা রয়েছে এবং আপনার অভিজ্ঞতায় কোনটি সর্বোচ্চ আরওআই পেয়েছে? এবং কেন?

আপনার যদি আপনার পরবর্তী প্রকল্পে স্বয়ংক্রিয় হওয়ার জন্য পরীক্ষার মাত্র একটি ফর্ম বেছে নিতে হয়, তবে তা কোনটি হবে?

আগাম ধন্যবাদ.


আমি ঠিক জেবি রেইনসবার্গারের ইন্টিগ্রেশন টেস্টস হ'ল একটি কেলেঙ্কারীতে একটি বিলিড লিঙ্ক যুক্ত করতে চাই । এটি ইন্টিগ্রেশন টেস্টগুলি একটি মিথ্যা অর্থনীতির অনেক কারণ হাইলাইট করে ights
টিম

1
: নিম্নলিখিত আপেক্ষিক লিঙ্ক চেক করুন stackoverflow.com/questions/437897/... stackoverflow.com/questions/520064/... stackoverflow.com/questions/4904096/...
CodyChan

6
এটি তিন বছর আগে যখন জিজ্ঞাসা করা হয়েছিল তখন এই সাইটটিতে পুরোপুরি সূক্ষ্ম প্রশ্নটি বন্ধ করার আরও একটি উদাহরণ এটি! এমন কোনও সম্প্রদায়কে অবদান রাখতে সত্যিই বিরক্তিকর হয় যেখানে নিয়মগুলি পরিবর্তন হয় এবং আপনি কেবল সমস্ত পুরানো জিনিস ফেলে দেন!
বজার্ক ফ্রুন্ড-হ্যানসেন

উত্তর:


34

ইউনিট পরীক্ষাগুলি অত্যন্ত কার্যকর করে তোলে এমন একটি গুরুত্বপূর্ণ বিষয় দ্রুত প্রতিক্রিয়া

আপনার অ্যাপটি সম্পূর্ণরূপে ইন্টিগ্রেশন / সিস্টেম / ফাংশনাল টেস্টের সাথে আচ্ছাদিত হলে কী ঘটে যায় তা বিবেচনা করুন (যা ইতিমধ্যে বেশিরভাগ বিকাশের দোকানগুলিতে বাস্তবতা থেকে দূরে একটি আদর্শ পরিস্থিতি)। এগুলি প্রায়শই একটি নিবেদিত পরীক্ষামূলক দল দ্বারা চালিত হয়।

  • আপনি এসসিএম রেপোতে একটি পরিবর্তন প্রতিশ্রুতিবদ্ধ,
  • কিছু সময় (সম্ভবত দিনগুলি) পরে পরীক্ষার ছেলেরা একটি নতুন অভ্যন্তরীণ প্রকাশ পায় এবং এটি পরীক্ষা শুরু করে,
  • তারা একটি বাগ খুঁজে পায় এবং একটি বাগ রিপোর্ট ফাইল করে,
  • (আদর্শ ক্ষেত্রে) কেউ আপনাকে বাগ রিপোর্টটি ফিরিয়ে দেয়।

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

যেখানে ইউনিট টেস্টিং (টিডিডি)

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

কয়েক মিনিটের মধ্যেই এটি ঘটে যায় ।

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

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

স্বয়ংক্রিয় ইউনিট টেস্টিং, স্বয়ংক্রিয় ইন্টিগ্রেশন টেস্টিং, এবং স্বয়ংক্রিয় স্বীকৃতি পরীক্ষার সাথে আপনার কী অভিজ্ঞতা রয়েছে এবং আপনার অভিজ্ঞতায় কোনটি সর্বোচ্চ আরওআই পেয়েছে? এবং কেন?

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

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

আপনি যদি আপনার পরের প্রকল্পে স্বয়ংক্রিয়ভাবে পরীক্ষার জন্য কেবল একটি ফর্ম বেছে নিতে পারেন তবে এটি কোনটি হবে?

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


2
ইউনিট পরীক্ষার জন্য "দ্রুত প্রতিক্রিয়া" এর জন্য +1। এছাড়াও, অবিচ্ছিন্ন ইন্টিগ্রেশন সার্ভারে পোস্ট-কমিট হিসাবে চালানোর জন্য খুব সহজ।
ফ্রাঙ্ক শায়ারার

1
"ভাল এসডাব্লু ইঞ্জিনিয়ারের টুলবাক্সে সমস্ত ধরণের পরীক্ষার ব্যবহার রয়েছে এবং এগুলির সবগুলিরই এমন দৃশ্য রয়েছে যেখানে সেগুলি অপরিবর্তনীয়।" - আমি আশা করি আমি তার জন্য কয়েকবার ভোট দিতে পারি! যে লোকেরা মনে করে যে তারা কেবল একটি আদর্শ পরীক্ষার সরঞ্জাম / পদ্ধতি খুঁজে পেতে পারে এবং সর্বত্র এটি প্রয়োগ করতে পারে তারা আমাকে নিচে ফেলে।
পিটিএক্স

8

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

আমরা যা করি পরীক্ষার ধরণ / উপকারটি এখানে:

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

Butচ্ছিক কিন্তু প্রস্তাবিত পরীক্ষা:

  • ব্যবহারকারীর অভিজ্ঞতা পরীক্ষার: যদিও আমরা সিস্টেম টেস্টিং থেকে শালীন প্রতিক্রিয়া পেয়েছি, ক্লায়েন্টের পূর্বরূপ থেকে কিছু লোককে প্রাক-রিলিজ করা সত্যই নির্ধারণ করতে সহায়তা করতে পারে যে জিনিসগুলি খুব দেরী হওয়ার আগে আমাদের পরিবর্তন করতে হবে কিনা determine

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

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


"সিস্টেম টেস্টিং - সিস্টেম প্রয়োজনীয়তা / বিশেষ উল্লেখগুলি পূরণ করে তা নিশ্চিত করে সাধারণত লোকেরা এই ধরণের টেস্টিং করে"। সিস্টেম / ওরফে ফাংশনাল / ওরফে "শেষ থেকে শেষ" / ওরফে উচ্চ-স্তরের ইন্টিগ্রেশন পরীক্ষা অটোমেশনের জন্যও ভাল।
মিফ্রেজিম এসও-স্টপ অশুভ হওয়া

3

এগুলি বিভিন্ন লক্ষ্য সহ বিভিন্ন সরঞ্জাম:

  • ইউনিট টেস্টিং হ'ল একটি ডিজাইনের সরঞ্জাম (টিডিডি), এবং রিফ্যাক্টরিংয়ের জন্য প্রায় পূর্বশর্ত।

  • প্রকল্পের অগ্রগতি কল্পনা করতে ইন্টিগ্রেশন টেস্ট দুর্দান্ত এবং রিগ্রেশন বাগগুলি এড়াতে দুর্দান্ত।

মনে রাখার বিষয়টি হ'ল আপনি ইন্টিগ্রেশন টেস্টগুলির সাথে সত্যই ডিজাইন করতে পারবেন না এবং ইউনিট পরীক্ষাগুলির সাথে আপনি রিগ্রেশনগুলি খুঁজে পাবেন না।


@ আপনি সত্যই ইন্টিগ্রেশন টেস্টগুলির সাথে ডিজাইন করতে পারবেন না এবং আপনি ইউনিট পরীক্ষার সাথে সংবিধানগুলি খুঁজে পাবেন না। একদম ঠিক!
চানকি পাঠক

ইউনিট পরীক্ষাগুলি রিফ্যাক্টরিংয়ের কারণে তৈরি হওয়া প্রতিক্রিয়াগুলি খুঁজে পেতে পারে, উদাহরণস্বরূপ পরিবর্তিত ভাগ করা সহায়িকার পদ্ধতি। যদিও এটির জন্য ইন্টিগ্রেশন টেস্টগুলি আরও ভাল।
স্টুপারউজার

ইন্টিগ্রেশন টেস্ট সম্পর্কে দ্বিতীয় দফায় "সিস্টেম / ফাংশনাল" (ওরফে "শেষ থেকে শেষ") পরীক্ষা অন্তর্ভুক্ত রয়েছে
মিফ্রেজিম এসও-স্টপ অশুভ হওয়া

সম্পূর্ণ সম্মত; স্টিভ স্যান্ডারসন কয়েক বছর আগে একটি অনুরূপ পয়েন্ট তৈরি করেছিলেন। আপনার নিজের জন্য কিছুটা পরিপূরক চিন্তার জন্য 2009. ব্লগ.স্টেভেনস্যান্ডারসন . com/ 2009/ 08/24/… এ তার ব্লগ পোস্টে "লক্ষ্য - সবচেয়ে শক্তিশালী কৌশল" সারণীটি দেখুন ।
মার্ক এ

1

স্যানিটি পরীক্ষার জন্য আমি সেলেনিয়াম ব্যাপকভাবে ব্যবহার করেছি ।

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

সেলেনিয়াম সম্পর্কে দুর্দান্ত জিনিসটি আপনি এটি XUnit, TestNG বা MSTest এর মতো ইউনিট টেস্টিং ফ্রেমওয়ার্কের সাথে বেঁধে রাখতে পারেন।

আমার অভিজ্ঞতায় এটি অত্যন্ত মূল্যবান হয়েছে, তবে এর মতো কোনও কিছুর সেটআপ আপনার প্রকল্প এবং আপনার দলের উপর নির্ভর করে, তাই আরওআই অবশ্যই আলাদা হবে।


1

সেরা আরওআই হ'ল সাধারনতম টেস্টিং যা এই ধরণের বাগটি খুঁজে পেতে পারে।

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

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

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

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

একটি বিষয় মনে রাখবেন যে এটি মূলত বিকাশকারীদের জন্য একটি ফোরাম, পরীক্ষকগণ নয়। ইন্টিগ্রেশন টেস্টিং প্রাথমিকভাবে পরীক্ষকগণ প্রয়োগ করেন। ইউনিট টেস্টিং ডেভেলপাররা প্রয়োগ করেন। স্বাভাবিকভাবেই, বিকাশকারীরা অন্যান্য ধরণের পরীক্ষার চেয়ে ইউনিট পরীক্ষার বিষয়ে বেশি কথা বলেন। এর অর্থ এই নয় যে তারা ভাবেন না যে অন্যান্য পরীক্ষা গুরুত্বপূর্ণ don't এটা ঠিক তারা আসলে না মানে কি এটা (অথবা এটা কম ঘন ঘন)।


বিশেষত সেই শেষ প্যারাটির জন্য ধন্যবাদ, আমি এটি ভেবে দেখিনি।
বার্জারে ফ্রেন্ড-হানসেন

এফওয়াইআই, আপনি উত্তরটি পড়ার পর থেকে আমি উত্তর আপডেট করেছি - বুঝতে পেরেছি যে আমি আসল প্রশ্নটি খুব কাছাকাছিভাবে পড়িনি
এথেল ইভান্স

@ এথেল ইভান্স, ইউনিট পরীক্ষার অগ্রাধিকারগুলি সম্পর্কে আপনার কারণগুলি নতুন প্রকল্পগুলির জন্য সঠিক। লিগ্যাসি প্রকল্পগুলির জন্য, যা টেস্টিং কভারেজকে মাথায় না রেখে স্বয়ংক্রিয়ভাবে লেখা হয়েছিল, সিস্টেম / ওরফে ফাংশনাল / ওরফে উচ্চ-স্তরের ইন্টিগ্রেশন পরীক্ষাগুলি সবচেয়ে গুরুত্বপূর্ণ। প্রোগ্রামারগুলির শেষ অংশটি দেখুন changestackexchange.com/a/39370/31574 উত্তর।
মিফ্রেজিম এসও-স্টপ অশুভ হওয়া

@ মিশেলফ্রিজেম, এটি শেষ পর্যন্ত ইন্টারফেসগুলি কতটা স্থিতিশীল তা নির্ভর করে। উচ্চ-স্তরের পরীক্ষাগুলি স্বয়ংক্রিয়ভাবে নিষিদ্ধ রক্ষণাবেক্ষণের জন্য ব্যয় করতে পারে যদি তারা দ্রুত পুরানো হয়- এই ক্ষেত্রে, স্থিতিশীলতা তৈরিতে সহায়তা করতে এবং E2E এবং ইন্টিগ্রেশন পরীক্ষার জন্য অযৌক্তিক অটোমেশন রক্ষণাবেক্ষণ ব্যয় এড়াতে অনুসন্ধানের পরীক্ষার (সম্ভবত সেশন- বা চেকলিস্ট ভিত্তিক) ব্যবহার করতে সহায়তা করতে কম স্বয়ংক্রিয় করুন। সমস্ত লিগ্যাসি প্রকল্পগুলির স্থিতিশীল ইন্টারফেস থাকে না, যদিও - বিশেষত যদি সেগুলি রিফেক্টর হয় বা আক্রমণাত্মকভাবে পুনরায় আর্কিটেক্ট করা হয়।
এথেল ইভান্স

1

আমি মনে করি গ্রহণযোগ্যতা পরীক্ষাগুলি এই দৃশ্যে রাজা।

যদি কোনও প্রতিশ্রুতি গ্রহণযোগ্যতা পরীক্ষাগুলি বিরতি দেয় তবে তা বাছাই করা দরকার।

স্বীকৃতি পরীক্ষা আপনাকে জানায় যে আপনার সফ্টওয়্যারটি কোথায়, ইউনিট পরীক্ষাগুলি করে না।

সুতরাং ইউনিট পরীক্ষাগুলি সুরক্ষার খুব ভ্রান্ত ধারণা প্রদান করতে পারে।


0

কী আরও বেশি গুরুত্বপূর্ণ তা প্রশ্নটি নয়, কী কী স্বয়ংক্রিয়ভাবে চালানো যায় এবং দ্রুত চালানো যায়।

ইউনিট পরীক্ষাগুলি দেখায় যে একটি ছোট উপাদান কোনও নির্দিষ্ট উপায়ে উদ্দেশ্যে উপযুক্ত এবং সাধারণত ছোট এবং দ্রুত চালানো হয় কিনা are ছোট হওয়ায় এগুলি সাধারণত স্বয়ংক্রিয়ভাবে সহজ হয়'re

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

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

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