আপনি "শিপযোগ্য" কোডটি সর্বদা চেক করে রেখেছেন তা নিশ্চিত করার জন্য পরীক্ষার সাথে অবিচ্ছিন্ন সংহতকরণ কার্যকর।
তবে, পরীক্ষার একটি বিস্তৃত স্যুট রাখা সত্যিই কঠিন এবং প্রায়শই মনে হয় বিল্ডটি যেভাবেই বগি হতে চলেছে।
আপনার সিআই পাইপলাইন পরীক্ষায় আপনার কতটা পরীক্ষার আত্মবিশ্বাস বোধ করতে হবে? যখন পর্যাপ্ত পরীক্ষা আছে তখন আপনি কি সিদ্ধান্ত নিতে কিছু ধরণের মেট্রিক ব্যবহার করেন?
উত্তর:
আপনার অবিচ্ছিন্ন ইন্টিগ্রেশন পাইপলাইনে আত্মবিশ্বাসী হওয়ার জন্য আপনার কাছে পর্যাপ্ত স্বয়ংক্রিয় পরীক্ষা কখন হবে?
আপনি কী সম্পর্কে আত্মবিশ্বাসী হতে চান সে সম্পর্কে যদি আপনি চিন্তা করেন তবে উত্তরটি সম্ভবত পরিষ্কার হয়ে যাবে। শেষ পর্যন্ত, এটি 1-1 মানচিত্র; প্রতিটি পরীক্ষা আপনাকে যা পরীক্ষা করে তা একটি বিষয়ে আত্মবিশ্বাসী করে তোলে:
আপনি আপনার প্রশ্নটি যেভাবে তৈরি করেছেন সেখান থেকে আপনি সম্ভবত এখনই একটি বড়-চিত্র ব্যবসায়িক অর্থে চিন্তা করছেন, উদাহরণস্বরূপ:
আমি আত্মবিশ্বাসী হতে চাই যে আমার অ্যাপটি এক্স করতে পারে ।
সুতরাং আপনি একটি শেষ-থেকে-শেষের পরীক্ষা লিখুন যা এক্স করার চেষ্টা করে এবং এটি যদি এটি সঠিকভাবে করে তবে তা পরীক্ষা করে।
এগুলি হ'ল খুব স্ব-রেফারেন্সিয়াল, কিন্তু এটি কারণ এটিই নেমে আসে। সেখানে কেবল নয় এটি আরও অনেক কিছু।
উদাহরণস্বরূপ, রান্নার রেসিপিগুলি তৈরি করতে আপনি কোনও অ্যাপ লিখেছেন তা কল্পনা করুন। একটি বৈশিষ্ট্য হ'ল, যদি আপনি বিভিন্ন পরিমাণে বিভিন্ন ধরণের পনির যোগ করেন তবে এটি আপনাকে সঠিক তাপমাত্রা এবং সময় দেয় যাতে সেগুলি সমস্ত গলে যায়।
সুতরাং আপনি CheeseMeltCalculatorএটির জন্য একটি ইউনিট পরীক্ষা লিখতে পারেন যেখানে আপনি এটি 100 গ্রাম গৌদা এবং 200 গ্রাম ইমেন্টাল পনির দেন এবং তারপরে আপনি পরীক্ষা করে দেখুন যে তাপমাত্রা এবং সময়টি সঠিকভাবে পরিণত হয়েছে। এর অর্থ আপনি এখন আত্মবিশ্বাসী হতে পারেন যে CheeseMeltCalculator100 গ্রাম গৌদা এবং 200 গ্রাম পনির জন্য কাজ করে। এখন আপনি যদি 200g এর পরিবর্তে 300g গৌদা দিয়ে এই পরীক্ষার পুনরাবৃত্তি করেন তবে আপনি বেশ আত্মবিশ্বাসী হতে পারেন যে এটি বিভিন্ন মানের জন্য সঠিকভাবে কাজ করে। আপনার জন্য পরীক্ষার যোগ করতে পারেন 0, -1এবং int.MaxValueগৌড় এর ছ আত্মবিশ্বাসী যে কোড লেঙ মারা না হতে (অথবা অভিপ্রেত যেমন সঠিকভাবে আপ ভ্রমণের) অদ্ভুত ইনপুট জন্য।
CheeseMeltCalculatorপুরো খাদ্য তাপমাত্রা এবং সময় গণনা প্রক্রিয়ায় সঠিকভাবে অন্তর্ভুক্ত করা হয়েছে কিনা তা পরীক্ষা করতে আপনি একটি ইন্টিগ্রেশন পরীক্ষা লিখতে পারেন । যদি এটি ভুল হয়ে যায়, তবে CheeseMeltCalculatorউপরের পরীক্ষাগুলি ঠিকঠাক হয়, আপনি আত্মবিশ্বাসের সাথে বিশ্বাস রাখতে পারেন যে বাগটি অন্য ক্যালকুলেটরগুলিতে বা বিভিন্ন ক্যালকুলেটর থেকে ডেটা একত্রিত করার পথে রয়েছে।
এবং পরিশেষে আপনি একটি সম্পূর্ণ রেসিপি তৈরির জন্য একটি শেষ থেকে শেষের জন্য পরীক্ষা লিখতে পারেন, এবং আপনি যা যা যা পরীক্ষা করেন তার মধ্যে একটি হল ফলাফলের তাপমাত্রা এবং সময়। যদি আগের 2 টি স্তরগুলির পরীক্ষাগুলি ভাল হয় তবে এটির জন্য এটি ভুল হয়ে যায় তবে আপনি আবারও আত্মবিশ্বাসের সাথে বলতে পারেন যে সেই অংশগুলি সঠিক এবং ভুলটি কীভাবে তাপমাত্রার গণনা প্রয়োগের সাথে একীভূত হয় সে সম্পর্কে is উদাহরণস্বরূপ, সম্ভবত ব্যবহারকারীর ইনপুটটি সঠিকভাবে স্থানান্তরিত হয়নি।
এবং পরিশেষে , যদি এই সমস্ত পরীক্ষা ভাল হয়, তবে আপনি আত্মবিশ্বাসী হতে পারেন যে " আপনি যদি বিভিন্ন ধরণের বিভিন্ন ধরণের পনির যোগ করেন তবে এটি আপনাকে সঠিক তাপমাত্রা এবং সময় দেয় যাতে সেগুলি সমস্ত গলে যায় "
মুল বক্তব্যটি হচ্ছে আপনি "এটি সঠিকভাবে কাজ করে" একটি পরীক্ষা করতে পারবেন না। আপনি কেবল "যদি আমি এক্স করি, ওয়াই হয়" পরীক্ষা করতে পারেন।
যাইহোক, এটি হ'ল জিনিস যা প্রকল্পের জন্য প্রযুক্তিগত বিবরণে থাকা উচিত। " যদি আপনি বিভিন্ন ধরণের বিভিন্ন ধরণের পনির বিভিন্ন পরিমাণ যুক্ত করেন তবে এটি আপনাকে সঠিক তাপমাত্রা এবং সময় দেয় যাতে সেগুলি সমস্ত দ্রবীভূত হয় " ক্লায়েন্টকে কেবল সমাপ্ত পণ্যটি কী করবে সে সম্পর্কে পরিষ্কার প্রত্যাশা দেয় না, পরিবর্তিত হতে পারে স্বয়ংক্রিয় পরীক্ষায়।
ব্যবহারকারী রিচার্ড একটি সম্পাদনায় এই তথ্যটি যুক্ত করেছেন:
মার্টিন ফওলারের সর্বাধিক সাধারণ কৌশলগুলি সম্পর্কে তার ওয়েবসাইটে খুব সুন্দর সংক্ষিপ্তসার রয়েছে: https://martinfowler.com/articles/microservice-testing/
আমি এটি মুছে ফেলতে চাই না, তবে আমি এটি বলতে চাই: এই উত্তরের তুলনায় এটি একটি "সংক্ষিপ্তসার" নয়, বরং দুর্দান্ত গ্রাফিক্স এবং সমস্ত কিছু সহ আরও গভীরতর ব্যাখ্যা explanation
আমার পরামর্শটি হ'ল: আমার উত্তরটি পড়ার পরে যদি সমস্ত কিছু আপনার কাছে বোঝায় তবে আপনি হয়ে গেছেন। যদি বিষয়গুলি এখনও অস্পষ্ট মনে হয় তবে কিছুটা সময় আলাদা করে রেখে লিঙ্কিত নিবন্ধটি পড়ুন।
এমন কোনও মেট্রিক নেই যা আপনি গণনা করতে পারবেন যা আপনাকে খুঁজছেন এমন আত্মবিশ্বাস দেবে। আত্মবিশ্বাস কিছু করে তৈরি করা হয়, এবং তারপরে এটি সফল হওয়া বা ব্যর্থ হওয়া এবং এ থেকে কিছু শিখতে।
আমি খুঁজে পেয়েছি শুধুমাত্র "মেট্রিক" যা আমাদের পরীক্ষার কভারেজটিতে আমাকে আত্মবিশ্বাস দেয়:
স্বয়ংক্রিয় পরীক্ষাগুলি কোনও রূপালী বুলেট নয়। প্রতিটি প্রকাশের চক্রের সময় আপনাকে কতগুলি উত্পাদন ত্রুটি পাওয়া যায় তার ট্র্যাক রাখতে হবে। এই সংখ্যাটি কমে গেলে আপনি আরও ভাল সফ্টওয়্যার সরবরাহ করছেন। অটোমেটেড পরীক্ষা এবং ক্রমাগত একীকরণ কেবলমাত্র এমন সরঞ্জাম যা আপনি আরও ভাল সফ্টওয়্যার সরবরাহ করতে ব্যবহার করেন।
কেবলমাত্র মেট্রিক যা আপনি সত্যিই পরিমাপ করতে পারবেন তা হ'ল "আপনি কি আরও ভাল সফ্টওয়্যার সরবরাহ করছেন?"
এবং তারপরেও, এটি বিষয়গত হয়।
আপনার অবিচ্ছিন্ন ইন্টিগ্রেশন পাইপলাইনে আত্মবিশ্বাসী হওয়ার জন্য আপনার কাছে পর্যাপ্ত স্বয়ংক্রিয় পরীক্ষা কখন হবে?
বেশিরভাগ অর্থনৈতিক পরিবেশে আপনার কাছে পর্যাপ্ত আত্মবিশ্বাস (> 99%) বাস্তবায়নের জন্য বাজেট থাকবে না তবে আপনাকে সীমাবদ্ধ বাজেট পরিচালনা করতে হবে: এটি ব্যয় / বেনিফিটের অনুপাত সম্পর্কে is
সুতরাং বাস্তবে সহজ / সস্তা / ঝুঁকিপূর্ণ পরীক্ষাগুলি কার্যকর করা হবে যখন ব্যয়বহুল / সম্ভাব্য পরীক্ষাগুলি তা করবে না।
সফটওয়্যার ডেভেলপমেন্টের একটি উপ-লক্ষ্য হ'ল স্বয়ংক্রিয় পরীক্ষণকে সাশ্রয়ী রাখার জন্য আর্কিটেকচার তৈরি করা যা পরীক্ষার পক্ষে সহজ / সস্তা ( টেস্ট-চালিত_ডিভালপমেন্ট প্রয়োগ করে পরীক্ষার জন্য নকশা করা )।
আমি ধরে নিয়েছি যে পেরেটো_সংশ্লিষ্টটি এখানে রক্ষণাবেক্ষণযোগ্য / পরীক্ষামূলক সফ্টওয়্যার এর জন্যও প্রয়োগ করা যেতে পারে: এটি বলছে যে অতিরিক্ত 20% বেশি অর্থ ব্যয় করার সাথে সাথে আপনি 80% অতিরিক্ত সুবিধা পাবেন। বাকি 20% আরও বেনিফিট পৌঁছাতে আপনার অতিরিক্ত 80% অর্থ ব্যয় করতে হবে।
আপনাকে সম্ভাব্য অপরিশোধিত উত্সকোডটি দেখানোর জন্য কোড কভারেজ এবং মিউটেশন কভারেজের মতো টেস্ট মেট্রিকগুলি প্রয়োগ করতে পারেন ।
তবে 100% কভারেজ থাকা সত্ত্বেও আপনি শিউর করতে পারবেন না যে আপনার কোডটি বাগ থেকে মুক্ত।
ম্যানেজমেন্ট কোডমেট্রিক্স পছন্দ করে। যদি "কোড কভারেজ> = 80%" পরিচালনা দ্বারা প্রয়োগ করা হয় যখন বিকাশকারীরা স্বয়ংক্রিয় পরীক্ষার সমর্থন / সমর্থন করে না তবে উচ্চ কভারেজ সহ টেস্টকোড লেখার উপায় রয়েছে যা সুরক্ষার কোনও ভ্রান্ত অনুভূতি দেওয়ার প্রমাণ দেয় না।
এখানে কৌতুক সম্পূর্ণ কভারেজ সম্পর্কে চিন্তা করার জন্য নয় তবে আপনার পরিবর্তনের ঝুঁকি পরিচালনার জন্য man
ধরা যাক আপনি ইতিমধ্যে উত্পাদনের মতো একই সংস্করণটি স্থাপন করতে আপনার পাইপলাইনটি ব্যবহার করছেন - রিগ্রেশন ত্রুটির ঝুঁকি কী? শূন্য (কারণ কোনও পরিবর্তন নেই)।
এখন, আসুন আমি বলি যে আমি কোনও একটি পর্দায় একটি টুকরো টেক্সট পরিবর্তন করতে চাই। পাঠ্যটি এখন সঠিকভাবে প্রদর্শিত হয়েছে কিনা তা যাচাই করার জন্য আমি পরীক্ষাটি যুক্ত করেছি (আসুন যুক্তির খাতিরে ধরে নেওয়া যাক এটি একটি সত্যিকারের গুরুত্বপূর্ণ টুকরো টুকরো)। কোন রিগ্রেশন ত্রুটি আছে তা যাচাই করার জন্য আমার আর কি পরীক্ষার দরকার? বাস্তবিকভাবে কেউ নেই ...
সুতরাং প্রতিটি মুক্তির জন্য লাইভের জন্য প্রয়োজনীয় স্বয়ংক্রিয় পরীক্ষার সংখ্যাটি আপনার অ্যাপ্লিকেশনের আকারের আকার নয়, তবে আপনার পরিবর্তনের আকার। আপনি যদি ছোট, স্বল্প ঝুঁকির পরিবর্তন করে থাকেন তবে ঝুঁকি হ্রাস করার জন্য আপনার আরও অনেক কম পরীক্ষা করা দরকার।
তবে এক মিনিট অপেক্ষা করুন ... এই লাইনের সিআই এবং সিডির বিন্দুটি খুব সুন্দরভাবে আপ হয় না?
হাঁ! আপনার সমস্ত পরিবর্তন এবং ডেল্টাসকে খুব ছোট রেখে আপনি পরীক্ষার চেয়ে প্রক্রিয়াটির মাধ্যমে অনেক রিগ্রেশন ঝুঁকি হ্রাস করছেন। আরও কী, প্রশ্নটি আসলে অটোমেশনে পরিণত হয় না (এটি আমরা কেবলমাত্র সরঞ্জামটি ব্যবহার করব) - এটি কেবল টেস্টিং এবং ঝুঁকি ক্ষুধা বিষয়। সম্পূর্ণরূপে অটোমেশন ভুলে যান, পরিবর্তনটি যে সমস্যাগুলি চালু করেনি তা নিশ্চিত করার জন্য আপনি কোন পরিবর্তনগুলির বিরুদ্ধে কী পরীক্ষা চালাবেন? এই প্রশ্নের উত্তর ম্যানুয়াল পরীক্ষার প্রক্রিয়া থেকে কোনও সিআই সিস্টেমে পরিবর্তিত হয় না - কেবলমাত্র এই সুবিধাটি হ'ল এই রিগ্রেশন টেস্টগুলির অনেকগুলি পূর্ববর্তী কার্যকারিতাতে বিকাশিত হতে পারে এবং সিআই আপনাকে আরও ছোট, নিরাপদ পরিবর্তন করতে উত্সাহিত করে।
TLDR
আপনার পরীক্ষাগুলি পরিবর্তনের ঝুঁকি হ্রাস করতে হবে। শূন্যের একটি ডেল্টা সহ একটি স্থাপনার কোনও ঝুঁকি নেই এবং তাই কোনও ঝুঁকি বহন করে না। আপনার পরিবর্তনগুলি ছোট রাখার মাধ্যমে সেগুলি যাচাই করার জন্য প্রয়োজনীয় পরীক্ষাগুলি সনাক্ত করা অনেক সহজ হয়ে যায় - অটোমেশনের পুনঃব্যবহারযোগ্যতা বোনাস।
আপনি যখন নিজের পণ্যটিকে ম্যানুয়ালি পরীক্ষা করছেন তখন এটি একই মেট্রিক।
ব্যবহারিকভাবে, এই স্বল্প-আত্মবিশ্বাসের অঞ্চলগুলি সনাক্ত করা সহজ: আপনি পণ্যটি শিপিং করছেন বলে ধরে নেওয়া, আমি মনে করি আপনার কাছে পোস্ট-পাইপলাইনের ম্যানুয়াল পদক্ষেপ রয়েছে যা শিপযোগ্য হওয়ার আত্মবিশ্বাসকে উন্নত করে। স্বয়ংক্রিয়ভাবে প্রক্রিয়াতে আত্মবিশ্বাস বাড়ানোর জন্য এগুলি আপনার স্বয়ংক্রিয় হওয়া উচিত।
আপনার অটোমেশন একটি চলমান প্রচেষ্টা। আপনার পণ্যের উন্নতি হওয়ায় এটি বৃদ্ধি এবং উন্নত হয়। ত্রুটি হ'ল সিআইকে আবার সংযুক্ত করার পাশাপাশি আপনার কোডটি পুনর্বিবেচনা করার কারণ reason এবং এখানে রৌদ্রোজ্জ্বল দিকটি হ'ল পণ্যটির প্রতি নিজের আত্মবিশ্বাস যেমন অর্জনযোগ্য - তেমনি অটোমেশনের প্রতি আস্থাও অর্জনযোগ্য।