কোনও বৈশিষ্ট্য পরীক্ষা না করা কি কখনও ঠিক আছে?


12

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

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

এছাড়াও, ধরে নেওয়া যাক যে সবকিছু ব্যাক আপ হয়েছে, তাই, সবচেয়ে খারাপ পরিস্থিতি, কিছু চেষ্টা করে ডেটা পুনরুদ্ধার করা যেতে পারে।

কেউ কি এটিকে সমাধান করার জন্য নির্দিষ্ট, বিশেষজ্ঞের অভিজ্ঞতার কথা উল্লেখ করতে পারেন? যথাযথ / সম্ভব যেখানে উল্লেখ উল্লেখ অন্তর্ভুক্ত করুন।

উত্তর:


10

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

এর কিছুটা ভাঙ্গার মাধ্যমে শুরু করা যাক।

আপগ্রেড

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

এসকিউএল সার্ভার আপগ্রেড করার সময় কিছু প্রয়োজনীয় পাঠ্যও রয়েছে । মূলত আপনি Backward Compatibilityনতুন সংস্করণটির জন্য এন্ট্রিটি পড়তে চান ( এখানে 2014 আছে ) এবং নিশ্চিত হয়ে নিন যে তালিকার কোনও তালিকায় আপনার কিছু নেই (ব্রেকিং পরিবর্তন, আচরণের পরিবর্তন ইত্যাদি)।

আবেদন কোড

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

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

বৈশিষ্ট্য / কনফিগারেশন

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

অ্যাডহক ক্যোয়ারী যা ব্যবহার করে ডেটা রেফারেন্স / প্রভাবিত করে

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

উদাহরণস্বরূপ আপনাকে প্রতি ত্রৈমাসিকের অ্যাডলিস্ট টেবিল থেকে এক বা একাধিক বিজ্ঞাপন মুছতে হবে।

DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')

এই মুহুর্তে আপনি ইতিমধ্যে কোডটি পরীক্ষা করেছেন (আপনি কেবলমাত্র স্থির স্ট্রিংগুলি পরিবর্তন করছেন) এবং সম্ভবত কোডটি চালানো মোটামুটি নিরাপদ আছেন (ধরে নিচ্ছেন আপনার ক্ষেত্রে ঠিক ভাল ব্যাকআপ রয়েছে)।

এটিকে পরীক্ষা করার একটি সহজ উপায় DELETE, UPDATEবা INSERTসেলেক্ট করে সেলেক্ট করে তাদের চালনা করা, তারপরে নিশ্চিত করুন যে সারিগুলির সংখ্যা এবং ধরণের প্রত্যাশাগুলি প্রত্যাবর্তিত হয়েছে তা নিশ্চিত করুন।

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

অ্যাডহক ক্যোয়ারী যা সিস্টেমের ডেটাগুলিকে রেফারেন্স / প্রভাবিত করে

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

সারসংক্ষেপ

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

স্বয়ংক্রিয় ইউনিট পরীক্ষা এখানে আপনার বন্ধু। আবির্ভাব সঙ্গে DevOpsএবং Continuous Integrationআপনি আরো এবং আরো অ্যাপ্লিকেশন এবং দ্রুত এবং সহজেই আপনার কোড পরীক্ষা পদ্ধতি দেখতে হবে। অবশ্যই এটির সাথে যেতে ভাল পরীক্ষার পরিবেশ এবং ডেটা থাকা দরকার তবে এটি সম্পূর্ণ ভিন্ন আলোচনা different


4

আমি জানি আপনি কি অনুভব করছেন, আমার 3 বছর মাইএসকিউএল এর সাথে কাজ করছে এবং আমার ক্ষেত্রে আমি সর্বদা ডিএমএল অনুসন্ধানগুলি পরীক্ষা করি যা প্রতিটি টেবিল / ডাটাবেস / স্লেভ-রেপ্লিকেশনের কোনও তথ্য সংশোধন করতে বা ভাঙ্গতে পারে।

আপনার ক্যোয়ারি চালানোর আগে এটি পরীক্ষা করা সর্বদা নিরাপদ উপায়।

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

উপর DELETE, UPDATE, INSERT, আপনি সবসময় ব্যবহার করতে চেষ্টা করা উচিত SELECTপ্রথম আপনি যদি নিশ্চিত না তথ্য যে আপনি পরিবর্তন করতে যাচ্ছেন না। বাছাই করা অবস্থায়, কলামের ডেটাটাইপ যেমন শর্ত হিসাবে সর্বদা একই ডাটা টাইপ ব্যবহার করার চেষ্টা করুন, কিছু ক্ষেত্রে EXPLAINঅপ্টিমাইজেশনের জন্য ব্যবহার করুন।

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