অনুশীলনে কীভাবে অবিচ্ছিন্ন বিতরণ কাজ করতে পারে?

Question

অবিচ্ছিন্ন ডেলিভারিটি ভাল শোনাচ্ছে তবে আমার বছরের কয়েক বছর ধরে সফ্টওয়্যার বিকাশের অভিজ্ঞতা থেকে বোঝা যায় যে বাস্তবে এটি কাজ করতে পারে না।

(সম্পাদনা: এটি পরিষ্কার করার জন্য, আমার সর্বদা প্রচুর পরীক্ষা স্বয়ংক্রিয়ভাবে চলতে থাকে My আমার প্রশ্নটি প্রতিটি চেকিনে সরবরাহ করার আত্মবিশ্বাস কীভাবে পাওয়া যায় সে সম্পর্কে, যা আমি বুঝতে পেরেছি যে সিডির সম্পূর্ণ ফর্ম The বিকল্পটি বছরব্যাপী চক্র নয় এটি প্রতি সপ্তাহে পুনরাবৃত্তি হয় (যা কিছু সঠিকভাবে করা হলেও এখনও সিডি বিবেচনা করতে পারে), দুই সপ্তাহ বা মাস; প্রতিটি একের শেষে একটি পুরানো ফ্যাশনযুক্ত QA সহ, স্বয়ংক্রিয় পরীক্ষাগুলির পরিপূরক)

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

Comments

এটি Etsy slideshare.net/ORelilOSCON/… জন্য খুব সূক্ষ্ম কাজ করে !

— YoTsumi

অবিচ্ছিন্ন বিতরণ পরীক্ষা করার প্রয়োজন হয় না (তবে এটি সাহায্য করে)। এটি এই বিষয়টিকে নির্দেশ করে যে আপনি নিয়মিত ভিত্তিতে যে জিনিসগুলি তৈরি করেন তা প্রয়োজনে গ্রাহকের কাছে প্রেরণ করা উচিত।

এটি আকর্ষণীয় যে ক্রমাগত বিতরণ করার বিষয়ে আপনার আপত্তিগুলি সিডির উপাদান হিসাবে পরীক্ষার দিকে অত্যধিকভাবে ফোকাস করে। যাইহোক, ধাঁধার এটিই একটি অংশ: আপনার পক্ষে দক্ষ অভ্যন্তরীণ সরঞ্জামদান, কঠোর মানের তদন্তের জন্য প্রতিশ্রুতিবদ্ধ বিকাশকারীদের, আপনার স্বয়ংক্রিয় পরীক্ষায় একটি প্রশস্ততা-গভীরতার অগ্রাধিকার পদ্ধতির প্রয়োজন, দৃ strong় সাংগঠনিক সমর্থন উল্লেখ না করার জন্য। এটি করা যেতে পারে তবে কারণটি প্রতিশ্রুতিবদ্ধ করতে অনেক লোক লাগে takes

— স্টিফেন গ্রস

@ স্টিফেন হ্যাঁ, আমি পরীক্ষার দিকে মনোনিবেশ করছি, কারণ আমি অন্যান্য সমস্ত বিষয়েই একমত। আমিও পরীক্ষার পক্ষে। আমি কেবল দেখতে পাই না যে আপনি কীভাবে প্রতিটি চেকিন মোতায়েন করার মতো যথেষ্ট আত্মবিশ্বাস রাখতে পারেন।

— জোশুয়া ফক্স

@ থরবজর্ন রাভন অ্যান্ডারসন। অবশ্যই, সিডি পরীক্ষার প্রয়োজন বলে মনে হচ্ছে। আপনি কীভাবে আত্মবিশ্বাস রাখতে পারেন তা ছাড়া প্রতিটি চেকইন স্বয়ংক্রিয়ভাবে চালিত করার।

— জোশুয়া ফক্স

Answer 1

আমার সফ্টওয়্যার বিকাশের অভিজ্ঞতার বছরগুলি পরামর্শ দেয় যে বাস্তবে এটি কাজ করতে পারে না।

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

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

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

অবশ্যই পুরো পরীক্ষার কভারেজ অসম্ভব, তবে বিকল্পটি কী: শূন্য পরীক্ষার কভারেজ? একটি বাণিজ্য বন্ধ আছে। এর মাঝে কোথাও আপনার প্রকল্পের সঠিক উত্তর। আমরা দেখতে পেলাম যে সাধারণভাবে স্বয়ংক্রিয় পরীক্ষাগুলি তৈরি বা রক্ষণাবেক্ষণের জন্য আপনার প্রায় 50% সময় ব্যয় করা উচিত। আপনি বিস্তৃত ম্যানুয়াল পরীক্ষার ব্যয় এবং ব্যবহারকারীদের কাছে যে বাগগুলি খুঁজে পেয়েছেন তা স্থির করে নেওয়া পর্যন্ত এটি ব্যয়বহুল মনে হতে পারে।

কিছু জিনিস স্বয়ংক্রিয়ভাবে পরীক্ষা করা শক্ত। যেমন জিইউআই। এমনকি আপনার জিইউআই দুর্বল কিনা তা সেলেনিয়াম আপনাকে জানায় না।

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

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

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

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

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

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

আমি যে পণ্যগুলিতে কাজ করতাম তার মধ্যে একটিতে 3,500 এন্ড-টু-এন্ড গ্রহণযোগ্যতা পরীক্ষা রয়েছে যা চালাতে 18 ঘন্টা লাগে। আমরা এটি 70 টি বাক্সের গ্রিডে সমান্তরালে চালাই এবং 45 মিটারে প্রতিক্রিয়া পাই। আদর্শের চেয়ে এখনও বেশি দীর্ঘতর, যার কারণেই ইউনিট পরীক্ষাগুলি কয়েক মিনিটের মধ্যে চলে যাওয়ার পরে আমরা পাইপলাইনে এটি দ্বিতীয় পর্যায়ে হিসাবে চালাচ্ছি যাতে আমরা আমাদের উত্সগুলিকে এমন কোনও বিল্ডে নষ্ট করি না যে আমাদের কোনও মৌলিক স্তর নেই build আত্ববিশ্বাসী.

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

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

বাগের মাঠের প্রতিবেদনগুলি কোডের সুনির্দিষ্ট মাইক্রো-সংস্করণের সাথে সহজেই মিলে যায় না।

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

Comments

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

— জোশুয়া ফক্স

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

— জেজ বিনীত

সম্পর্কিত "ডেটাবেস অ্যাক্সেস আপনার শেষ-থেকে-শেষ দৃশ্যের ভিত্তিতে কার্যকরী স্বীকৃতি পরীক্ষার দ্বারা নিখুঁতভাবে পরীক্ষা করা হয়" " মূল সমস্যাটি হ'ল এটি অন্তর্নিহিত । লোকেরা এতে সন্তুষ্ট বলে মনে হয়, তবে এটি একটি খুব সময় নষ্টের পদ্ধতির; সমস্যাটি বলার পরিবর্তে "এটি আমি ডিবি থেকে প্রত্যাশা করেছিলাম এবং এর পরিবর্তে এটি পেয়েছিলাম", এতে বলা হয়েছে "100 স্তরগুলির মধ্যে একটিতে কিছু ভেঙে গেছে"।

— atoth

Answer 2

প্রথমত, সিডি একটি বড় মানসিক সামঞ্জস্য গ্রহণ করে - আপনাকে স্বীকার করতে হবে যে আপনি যা কিছু করেন না কেন কখনও কখনও জিনিসগুলি ভেঙে যায়। দিন শেষে, আপনি একটি নেতিবাচক প্রমাণ করতে পারবেন না।

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

Comments

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

— জোশুয়া ফক্স

তবে এগুলি এখনও খুঁজে পাওয়া এবং ঠিক করা সহজ যা জোরের বেশি পয়েন্ট।

— ওয়াট বার্নেট

Answer 3

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

Comments

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

— জোশুয়া ফক্স

Answer 4

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

আপনার ১০০% কভারেজের দরকার নেই, আপনার সিস্টেমে আত্মবিশ্বাসের জন্য আপনার পর্যাপ্ত পরিমাণ প্রয়োজন, যে এক জায়গায় পরিবর্তনের ফলে আপনি পূর্বে কাজ প্রমাণিত জিনিসগুলি ভাঙবে না।

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

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

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

তাহলে আপনার অনেক ফাংশন / ক্লাস খুব বড়। সেগুলি পরীক্ষাযোগ্য হওয়ার জন্য লেখা উচিত।

মক অবজেক্ট তৈরিতে আপনি প্রচুর সময় ব্যয় করতে পারেন যা বাস্তব বাস্তবায়নের সাথে সামঞ্জস্য নাও হতে পারে।

মক অবজেক্টের I / O এর সাথে মিল থাকা উচিত যা প্রত্যাশিত। এর ভিতরে কী ঘটে যায় তা গুরুত্বহীন।

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

এগুলি সর্বদা চালানো উচিত নয়। যেমন প্রয়োজন তেমন

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

তারপরে আপনার কোডটি খুব শক্তভাবে মিলিত হয়েছে এবং আপনার পরীক্ষাগুলি খুব কম লেখা আছে।

বাগের মাঠের প্রতিবেদনগুলি কোডের সুনির্দিষ্ট মাইক্রো-সংস্করণের সাথে সহজেই মিলে যায় না।

আপনি এখানে কি পাচ্ছেন তা নিশ্চিত নন? যদি কোনও বাগ থাকে তবে এর অস্তিত্ব দেখাতে একটি পরীক্ষা লিখুন, তবে এটি ঠিক করুন।

Comments

"মক অবজেক্টের I / O প্রত্যাশার সাথে মিলে যায়"। "একটি ইন্টারফেস-স্পেস পুরোপুরি কার্যকর করে এমন এমও বিল্ডিং সময় সাপেক্ষ। আরও খারাপভাবে, একটি অবশ্যই তাদের নিয়মিত আপডেট করতে হবে, যাতে কোনও কার্যকরভাবে দু'বার কার্যকরভাবে লিখছেন (একবার উত্পাদনের জন্য এবং একবার এমওদের জন্য)

— জোশুয়া ফক্স

Answer 5

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

Answer 6

সত্যি কথা বলতে কি, সমস্ত সফ্টওয়্যার ক্রমাগত বিতরণে রয়েছে! সবচেয়ে গুরুত্বপূর্ণ বিষয়টি এটি দরজা থেকে সরিয়ে দেওয়া! আপনার ব্যবহারকারীদের এটি ব্যবহার করুন এবং এর পরে বৈশিষ্ট্যটির অনুরোধ এবং বাগ স্কোয়াশিংকে অগ্রাধিকার দিন।

"রিয়েল আর্টস শিপ"
- স্টিভ জবস।

Comments

সিডির বিকল্পটি বছরব্যাপী চক্র নয়। এটি প্রতি সপ্তাহে, দুই সপ্তাহ বা মাসে পুনরাবৃত্তি হয়।

— জোশুয়া ফক্স