ইউনিট পরীক্ষাগুলি সিটি গ্রুপকে এই ব্যয়বহুল ভুল এড়াতে সহায়তা করবে?


86

আমি এই স্নাফু সম্পর্কে পড়েছি: 15 বছর ধরে পরীক্ষার ডেটার জন্য ভুল লেনদেনের ভুল হওয়ার পরে প্রোগ্রামিং বাগের জন্য সিটি গ্রুপটি $ 7m খরচ করে

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

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

(আমি মনে করি এটি চিত্রিত করে যে কোনও স্পষ্ট-বহির্ভূত ডেটা সূচক ব্যবহার করা ... সাব-অপটিমল। শব্দার্থিকভাবে স্পষ্ট Branch.IsLiveসম্পত্তি ব্যবহার করা এবং ব্যবহার করা আরও ভাল )

এদিকে, আমার প্রথম প্রতিক্রিয়া ছিল "ইউনিট পরীক্ষাগুলি এখানে সহায়তা করত" ... তবে তারা কি করবে?

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



17
দেখে মনে হচ্ছে তারা একটি সংহত পরীক্ষাও মিস করেছে যা এসইসিতে রফতানির পরিমাণ পরীক্ষা করেছে। আপনি যদি রফতানি বৈশিষ্ট্যটি তৈরি করেন তবে তা যুক্তিসঙ্গত চেক হবে।
লুক ফ্রাঙ্কেন

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

25
@gnat আমি বাহ্যিক লিঙ্কটি পড়িনি, এবং আমি এখনও এই প্রশ্নটি অর্থবহ পেয়েছি
জুটনার্গ

23
এটির মূল্য কী, তার জন্য আমি "কেন বেশিরভাগ ইউনিট টেস্টিং বর্জ্য" "এর সবকিছুর সাথে একমত নই। আমি একটি খণ্ডন লিখতে চাই, তবে এই মার্জিনটি এটি ধারণ করতে খুব কম।
রবার্ট হার্ভে

উত্তর:


19

আপনি কি সত্যিই জিজ্ঞাসা করছেন, "ইউনিট টেস্টগুলি এখানে সহায়তা করত?", বা আপনি জিজ্ঞাসা করছেন, "কোনও ধরণের পরীক্ষা সম্ভবত এখানে সহায়তা করতে পারে?"।

পরীক্ষার সর্বাধিক সুস্পষ্ট রূপ যা সাহায্য করতে পারে, তা কোডের মধ্যেই একটি পূর্ব শর্ত হ'ল একটি শাখা শনাক্তকারী কেবলমাত্র সংখ্যার সমন্বিত থাকে (মনে করুন যে কোডটি কোডার দ্বারা কোডার দ্বারা নির্ভর করা এই ধারণাটি)।

এটি তখন একরকম একীকরণ পরীক্ষায় ব্যর্থ হতে পারে এবং নতুন আলফা-সংখ্যাসূচক শাখা আইডির সাথে সাথেই উত্সাহটি প্রকাশিত হবে। তবে এটি কোনও ইউনিট পরীক্ষা নয়।

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

আমি জড়িত ইন্টারফেসগুলির কোনও সংজ্ঞা বা ডকুমেন্টেশন দেখতে পাচ্ছি না, তবে ইউনিট পরীক্ষাগুলি সম্ভবত ত্রুটিটি সনাক্ত করতে পারে না কারণ ইউনিট ত্রুটিযুক্ত ছিল না । ইউনিটটিকে যদি ধরে নিতে অনুমতি দেওয়া হয় যে শাখার শনাক্তকারী কেবলমাত্র সংখ্যার সমন্বয়ে গঠিত হয়, এবং বিকাশকারীরা কখনই সিদ্ধান্ত নেন না যে কোডটি না করায় কী করা উচিত, তবে তাদের উচিত নয়অ-সংখ্যা শনাক্তকারীদের ক্ষেত্রে বিশেষ আচরণ প্রয়োগের জন্য একটি ইউনিট পরীক্ষা লিখুন কারণ পরীক্ষাটি সেই ইউনিটের একটি অনুমানযোগ্য বৈধ বাস্তবায়ন প্রত্যাখ্যান করে যেগুলি বর্ণানুক্রমিক শাখা শনাক্তকারীদের সঠিকভাবে পরিচালনা করে এবং আপনি সাধারণত একটি ইউনিট পরীক্ষা লিখতে চান না যা বৈধ প্রতিরোধ করে ভবিষ্যতের বাস্তবায়ন এবং এক্সটেনশনগুলি। অথবা 40 বছর আগে লিখিত একটি দলিল সুস্পষ্টভাবে সংজ্ঞায়িত করা হয়েছে (কাঁচা ইবিসিডিআইসি-তে কিছু মনস্তাত্ত্বিক কোলিশন নিয়মের পরিবর্তে কিছু কথিতাত্ত্বিক পরিসরের মাধ্যমে) যে 10 বি একটি পরীক্ষার শনাক্তকারী কারণ এটি 089 এবং 100 এর মধ্যে পড়ে তবে বাস্তবে পড়ে যায় But 15 বছর আগে কেউ এটিকে সত্য সনাক্তকারী হিসাবে ব্যবহার করার সিদ্ধান্ত নিয়েছে, সুতরাং "দোষ" ইউনিটে পড়ে না যা সঠিক সংজ্ঞাটি সঠিকভাবে প্রয়োগ করে: এটি প্রক্রিয়াটির মধ্যে রয়েছে যা লক্ষ্য করতে ব্যর্থ হয়েছে যে 10 বি পরীক্ষার সনাক্তকারী হিসাবে সংজ্ঞায়িত হয়েছে এবং তাই কোনও শাখায় বরাদ্দ করা উচিত নয়। ASCII তে একই ঘটবে যদি আপনি 089 - 100 কে একটি পরীক্ষার পরিসীমা হিসাবে সংজ্ঞায়িত করেন এবং তারপরে একটি সনাক্তকারী 10 $ বা 1.0 প্রকাশ করেন। এটি ঠিক ঘটে যে EBCDIC তে অঙ্কগুলি অক্ষরের পরে আসে।

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

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

আমি অবশ্যই একমত যে ইউনিটটি যদি "মজার আকৃতির" ইনপুট দিয়ে প্রথম স্থানে সংজ্ঞায়িত না করা হত, তবে পরীক্ষার মতো কিছুই থাকত না। অদ্ভুতভাবে নেমস্পেস বিভাগগুলি সঠিকভাবে পরীক্ষা করা শক্ত হতে পারে কারণ আপনার মজার সংজ্ঞাটি বাস্তবায়নে অসুবিধা নেই, এটি নিশ্চিত করার মধ্যে রয়েছে যে প্রত্যেকে আপনার মজার সংজ্ঞা বোঝে এবং শ্রদ্ধা করে। এটি একটি কোড ইউনিটের স্থানীয় সম্পত্তি নয়। তদ্ব্যতীত, "অঙ্কের একটি স্ট্রিং" থেকে "বর্ণের একটি স্ট্রিং" তে কিছু ডেটা টাইপ পরিবর্তন করা ASCII- ভিত্তিক প্রোগ্রাম হ্যান্ডেল ইউনিকোড তৈরি করার অনুরূপ: আপনার কোডটি মূল সংজ্ঞাটির সাথে ভারীভাবে মিলিত হলে এবং কখন সহজ হবে না when প্রোগ্রামটি যা করে তার জন্য ডেটা টাইপটি মৌলিক, তবে এটি প্রায়শই ভারীভাবে মিলিত হয়।

এটি বেশিরভাগ প্রচেষ্টা নষ্ট করে মনে করে কিছুটা ঝামেলা করছে

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


জোর দেওয়া ভাল!

3
@ নোকমপ্রেডে: যেমন রেগান ছিল, "বিশ্বাস, তবে যাচাই করুন"।
স্টিভ জেসোপ

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

2
"সমস্ত পরীক্ষা পাস হচ্ছে তবে কিছু পরীক্ষা অন্যের চেয়ে বেশি পাস করছে!"
গ্রাহাম

1
পরীক্ষা একটি লাল উত্তেজনা হয়। এই ছেলেরা কীভাবে "শাখা কোড" সংজ্ঞায়িত হয়েছিল তা জানত না। এটি মার্কিন ডাকঘরটির মতো হবে না জেনেও যে এটি জিপ কোডের সংজ্ঞা পরিবর্তন করছে যখন এটি 4 টি সংখ্যা যুক্ত করেছিল।
রডারবব

120

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

অন্যদিকে, উত্পন্ন প্রতিবেদনের স্পট চেকগুলি প্রমাণ করতে পারে যে ব্রাঞ্চ করা 10 বি এবং 10 সি ত্রুটিটি 15 বছর বয়সের তুলনায় তত্ক্ষণাত্ রিপোর্ট থেকে অনুপস্থিত ছিল যে ত্রুটিটি উপস্থিত থাকার অনুমতি দেওয়া হয়েছিল।

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


80
+1 ইউনিট পরীক্ষাগুলি কখনই দুর্বল নকশার সিদ্ধান্তগুলির জন্য ক্ষতিপূরণ দিতে পারে না (যেমন পরীক্ষার পরীক্ষা এবং বাস্তব ডেটা মিশ্রণ)
জুটনার্গ

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

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

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

12
@ জিমি জেমস স্বাস্থ্যসেবাতে যথাসম্ভব বাস্তবের কাছাকাছি থাকা তথ্যের উপর পরীক্ষার জন্য পরীক্ষার পরিবেশে পর্যায়ক্রমে উত্পাদন ডাটাবেস অনুলিপি করা সাধারণ; আমি মনে করি কোনও ব্যাংকও এটি করতে পারে।
ডিজে 18

75

সফ্টওয়্যারটির নির্দিষ্ট ব্যবসায়ের নিয়মগুলি পরিচালনা করতে হয়েছিল। যদি ইউনিট পরীক্ষা করা হত, ইউনিট পরীক্ষাগুলি পরীক্ষা করে দেখতে পারে যে সফ্টওয়্যারটি ব্যবসায়ের নিয়মগুলি সঠিকভাবে পরিচালনা করেছিল।

ব্যবসায়ের নিয়ম বদলেছে।

স্পষ্টতই কেউ বুঝতে পারেনি যে ব্যবসায়ের নিয়মগুলি পরিবর্তিত হয়েছে, এবং কেউ নতুন ব্যবসায়িক বিধি প্রয়োগের জন্য সফ্টওয়্যার পরিবর্তন করেনি। যদি ইউনিট পরীক্ষা করা হত, তবে সেই ইউনিট পরীক্ষাগুলি পরিবর্তন করতে হবে, তবে কেউ তা করতে পারত না কারণ কেউ বুঝতে পারেনি যে ব্যবসায়ের নিয়মগুলি পরিবর্তিত হয়েছে।

সুতরাং না, ইউনিট পরীক্ষাগুলি এটি ধরতে পারত না।

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

অবশ্যই একই ক্ষেত্রে যদি কেবল সফ্টওয়্যার পরিবর্তন করা হয় এবং ইউনিট পরীক্ষা না করে তবে ইউনিট পরীক্ষাগুলিও ব্যর্থ হবে। যখনই কোনও ইউনিট পরীক্ষা ব্যর্থ হয়, এর অর্থ সফ্টওয়্যারটি ভুল নয়, এর অর্থ সফ্টওয়্যার বা ইউনিট পরীক্ষা (কখনও কখনও উভয়ই) ভুল।


2
একটিতে কোড এবং অন্যটি "ইউনিট" টেস্টে কাজ করছে এমন বিভিন্ন দল থাকা কি সম্ভব? এটি কীভাবে সম্ভব? ... আমি আমার কোডটি সারাক্ষণ রিফ্যাক্টর করছি।
সার্জিও

2
@ সার্জিওকে এক দৃষ্টিকোণ থেকে, আচরণ সংরক্ষণের সময় অভ্যন্তরীণ পরিবর্তনগুলি পরিবর্তন করে - সুতরাং যদি পরীক্ষাটি এমনভাবে লেখা হয় যাতে অভ্যন্তরীণদের উপর নির্ভর না করে আচরণের পরীক্ষা করা হয়, তবে এটি আপডেট করার দরকার নেই doesn't
দেনিথ

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

42
"ব্যবসায়ের নিয়ম পরিবর্তন হয়েছে" এটি সমালোচনা পর্যবেক্ষণ। ইউনিট পরীক্ষাগুলি যাচাই করে যে আপনি যে যুক্তিটি প্রয়োগ করেছেন বলে মনে করেছিলেন আপনি প্রয়োগ করেছেন , তা নয় যে আপনার যুক্তি সঠিক ছিল ।
রায়ান কাভানফ

5
আমি যদি ঘটেছিল সে সম্পর্কে সঠিক হয়ে থাকি তবে এটি ধরার পক্ষে ইউনিট পরীক্ষাগুলি লেখা সম্ভব নয়। পরীক্ষাগুলি বাছাই করার মূল নীতিটি হ'ল কিছু "ভাল" কেস, কিছু "খারাপ" কেস এবং কোনও সীমানা বন্ধনকারী কেসগুলি পরীক্ষা করা। এই ক্ষেত্রে, আপনি "099", "100" এবং "101" পরীক্ষা করেছেন। যেহেতু "10 বি" পুরানো সিস্টেমের অধীনে "অ-সংখ্যাগুলি প্রত্যাখ্যান করুন" পরীক্ষাগুলি দ্বারা আচ্ছাদিত ছিল এবং এটি 101 টিরও বেশি (এবং এটি পরীক্ষা করে আওতায় পড়েছে) নতুন সিস্টেমের অধীনে, এটি পরীক্ষা করার কোনও কারণ নেই - এটি বাদে EBCDIC, "10B" "099" এবং "100" এর মধ্যে বাছাই করে।
চিহ্নিত করুন

29

না। ইউনিট পরীক্ষার ক্ষেত্রে এটি অন্যতম বৃহৎ সমস্যা: তারা আপনাকে সুরক্ষার ভ্রান্ত ধারনা থেকে সরিয়ে দেয়।

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


17
আমার বাবা আমাকে জিজ্ঞাসা করতেন: আপনি যে জিনিসটি ভাবেননি তা কেন ভাবেননি? (কেবলমাত্র তিনি "যদি আপনি না জানেন, জিজ্ঞাসা করুন !" বলে বিভ্রান্তি তৈরি করতেন ) তবে আমি কীভাবে জানি যে আমি জানি না?

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

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

5
স্বভাবতই, যে বিকাশকারীদের ভ্রান্ত বিশ্বাস রয়েছে তারা ইউনিট পরীক্ষার পুরোপুরি ব্যর্থ হলে হতাশ হতে চলেছে, তবে এটি বিকাশকারীর দোষ, ইউনিট পরীক্ষার নয়, এবং এটি ইউনিট পরীক্ষার যে প্রকৃত মান দেয় তা অকার্যকর করে না।
রবার্ট হার্ভে

5
o_O @ আপনার প্রথম বাক্য। স্টিয়ারিং হুইলে হাত রাখা যেমন ড্রাইভিংয়ের সময় সুরক্ষার একটি মিথ্যা অনুভূতি দেয় এমন কোডিংয়ের সময় ইউনিট পরীক্ষাগুলি আপনাকে সুরক্ষার একটি মিথ্যা অনুভূতি দেয়।
djechlin

10

না, অগত্যা নয়।

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

তারপরে, প্রয়োজনীয়তাটি পরিবর্তিত হয়ে কোডগুলি আপডেট হয়ে যেত, তবে এর অর্থ ইউনিট টেস্ট কোড যা খারাপ ডেটা সরবরাহ করে (এটি এখন ভাল ডেটা) সংশোধন করতে হবে।

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

ইউনিট টেস্টিং মূল বিকাশের জন্য ভাল তবে সিস্টেম পরীক্ষার জন্য নয়, বিশেষত প্রয়োজনীয়তাগুলি দীর্ঘকাল ভুলে যাওয়ার পরে 15 বছর নয়।

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


চিহ্নিত করা. এবং ইউনিট টেস্টগুলির সাথে মূল (কেবল?) সমস্যা। আমি আমার নিজের উত্তরটি বাক্য সংরক্ষণ করেছিলাম, যেমন আমি ঠিক একই জিনিসটি বলেছি (তবে সম্ভবত আরও খারাপ!) :)
অরবিট-এ

8

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

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

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

অবশ্যই, কুইকচেকটি প্রথম 1999 সালে বিকাশিত হয়েছিল, তাই এই সমস্যাটি ধরতে ইতিমধ্যে খুব দেরি হয়েছিল।


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

5

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

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

আপনি কেবল যুক্তি দিয়ে এই সমস্যাটি সনাক্ত করতে পারেন:

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

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


2

রান-টাইমে অন্তর্নির্মিত একটি দৃ helped়তা সাহায্য করতে পারে; উদাহরণ স্বরূপ:

  1. মত একটি ফাংশন তৈরি করুন bool isTestOnly(string branchCode) { ... }
  2. কোন প্রতিবেদনগুলি ফিল্টার করে তা স্থির করতে এই ফাংশনটি ব্যবহার করুন
  3. এই ধরণের শাখা কোড ব্যবহার করে একটি শাখা তৈরি করা যায় না (তা তৈরি করা যায় না) যাচাই বা তা নিশ্চিত করার জন্য, শাখা-তৈরি কোডে একটি যুক্তিতে এই ফাংশনটি পুনরায় ব্যবহার করুন‼
  4. এই দাবীটি বাস্তব রান-টাইমে সক্ষম করা হয়েছে (এবং "কোডের ডিবাগ-কেবল বিকাশকারী সংস্করণ ব্যতীত" অপ্টিমাইজড নয় ")‼

আরো দেখুন:


2

এ থেকে অবতরণ দ্রুত ব্যর্থ হয়

আমাদের কোড নেই, না আমাদের কাছে উপসর্গের অনেকগুলি উদাহরণ রয়েছে যা কোড অনুসারে শাখার উপসর্গগুলি হয় বা হয় না। আমাদের যা কিছু আছে তা হ'ল:

  • 089 - 100 => পরীক্ষা শাখা
  • 10 বি, 10 সি => পরীক্ষা শাখা
  • <088 => সম্ভবত আসল শাখা
  • > 100 => সম্ভবত আসল শাখা

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

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

bool IsTest(string strPrefix) {
    int iPrefix;
    if(int.TryParse(strPrefix, out iPrefix))
        return iPrefix >= 89 && iPrefix <= 100;
    return true; //here is the problem
}

ইংরাজীতে, যদি স্ট্রিংটি একটি সংখ্যা হয় এবং 89 এবং 100 এর মধ্যে হয় তবে এটি একটি পরীক্ষা। এটি যদি নম্বর না হয় তবে এটি একটি পরীক্ষা। অন্যথায় এটি পরীক্ষা নয়।

কোডটি যদি এই প্যাটার্নটি অনুসরণ করে, কোড স্থাপনের সময় কোনও ইউনিট পরীক্ষা এটি ধরতে পারত না। এখানে ইউনিট পরীক্ষার কয়েকটি উদাহরণ রয়েছে:

assert.isFalse(IsTest("088"))
assert.isTrue(IsTest("089"))
assert.isTrue(IsTest("095"))
assert.isTrue(IsTest("100"))
assert.isFalse(IsTest("101"))
assert.isTrue(IsTest("10B")) // <--- business rule change

ইউনিট পরীক্ষা দেখায় যে "10 বি" একটি পরীক্ষা শাখা হিসাবে বিবেচনা করা উচিত। উপরের ব্যবহারকারী @ gnasher729 বলেছেন যে ব্যবসায়ের নিয়মগুলি পরিবর্তিত হয়েছে এবং এটি শেষের উপরের দৃser় প্রতিবেদনটি দেখায়। এমন এক পর্যায়ে যে দৃsert়তাটি একটিতে পরিবর্তন হওয়া উচিত ছিল isFalse, তবে তা ঘটেনি। ইউনিট পরীক্ষাগুলি বিকাশ- এবং বিল্ড-টাইমে চালিত হয় তবে তার পরে আর কোনও পর্যায়ে আসে না।


এখানে পাঠ কি? কোডটি সিগন্যাল করার কিছু উপায় দরকার যা এটি অপ্রত্যাশিত ইনপুট পেয়েছে। এই কোডটি লেখার একটি বিকল্প উপায় এখানে এটি জোর দেয় যে এটি উপসর্গটি একটি সংখ্যার প্রত্যাশা করে:

// Alternative A
bool TryGetIsTest(string strPrefix, out bool isTest) {
    int iPrefix;
    if(int.TryParse(strPrefix, out iPrefix)) {
        isTest = iPrefix >= 89 && iPrefix <= 100;
        return true;
    }
    isTest = true; //this is just some value that won't be read
    return false;
}

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

আপনি যদি ব্যতিক্রমগুলির সাথে ঠিক থাকেন তবে পরিবর্তে আপনি এটি করতে পারেন:

// Alternative B
bool IsTest(string strPrefix) {
    int iPrefix = int.Parse(strPrefix);
    return iPrefix >= 89 && iPrefix <= 100;
}

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


1

এতগুলি উত্তর এমনকি একটি ডিজকস্ট্রার উদ্ধৃতিও নয়:

পরীক্ষাগুলি উপস্থিতি দেখায়, বাগগুলির অনুপস্থিতি নয়।

সুতরাং, এটি নির্ভর করে। কোডটি সঠিকভাবে পরীক্ষা করা হলে সম্ভবত এই বাগের অস্তিত্ব থাকবে না।


-1

আমি মনে করি যে এখানে একটি ইউনিট পরীক্ষা নিশ্চিত করেছিল যে সমস্যাটি প্রথম স্থানে কখনও থাকবে না।

বিবেচনা করুন, আপনি bool IsTestData(string branchCode)ফাংশন লিখেছেন ।

আপনার লেখা প্রথম ইউনিট পরীক্ষাটি নাল এবং ফাঁকা স্ট্রিংয়ের জন্য হওয়া উচিত। তারপরে ভুল দৈর্ঘ্যের স্ট্রিংগুলির জন্য নন ইন্টিজার স্ট্রিংগুলির জন্য।

এই সমস্ত পরীক্ষা পাস করার জন্য আপনাকে ফাংশনে প্যারামিটার চেক যোগ করতে হবে।

এমনকি যদি আপনি কেবল 'ভাল' ডেটা পরীক্ষা করেন 001 -> 999 10A সম্ভাবনার কথা চিন্তা না করে প্যারামিটার চেকিং আপনাকে ফাংশনটি পুনরায় লিখতে বাধ্য করবে যখন আপনি অক্ষরগুলি বাদ দেবেন তা এড়াতে অক্ষরগুলি ব্যবহার করতে শুরু করবেন


1
এটি সাহায্য করবে না - ফাংশন পরিবর্তন করা হয়নি, এবং একই পরীক্ষার ডেটা দিয়ে পরীক্ষা ব্যর্থ হওয়া শুরু করবে না। এটি ব্যর্থ হওয়ার জন্য কাউকে পরীক্ষাটি পরিবর্তনের বিষয়ে ভাবতে হবে, তবে তারা যদি এটি ভেবে থাকে তবে তারা সম্ভবত ফাংশনটি পরিবর্তন করার কথা ভাবতেন।
হাল্ক

(অথবা সম্ভবত আমি কিছু মিস করছি, কারণ "প্যারামিটার চেকিং" বলতে আপনার অর্থ কী তা আমি নিশ্চিত নই)
হাল্ক

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

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

1
যদি চেকটি ইসভালিডকোডে থাকে, যাতে ফাংশনটি তার নিজস্ব স্পষ্ট চেক ছাড়াই পাস করে, তবে হ্যাঁ এটি মিস করা সম্ভব, তবে আমাদের কাছে আরও কিছু পরীক্ষা, মক ভ্যালিডেটর ইত্যাদির আরও একটি অতিরিক্ত সংস্থান থাকবে নির্দিষ্ট "এগুলি হ'ল আরও সম্ভাবনা পরীক্ষার নম্বর "
ইওয়ান
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.