আমরা কী সফ্টওয়্যার পরীক্ষার সময় ধরে ধরে নিতে পারি যে কোনও ব্যবহারকারী সফ্টওয়্যারে এই জাতীয় নির্বোধ কাজ করবেন না?

Question

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

সাধারণভাবে, ওয়েব অ্যাপ্লিকেশনটির ব্যবহারকারী হিসাবে আমরা ক্ষেত্রগুলিতে আসলে এলোমেলো মান প্রবেশ করি না।

সুতরাং এই সমস্ত টেস্টকেসগুলি সংযুক্ত করে কী ব্যবহার করতে হবে যা / যা বাগের দিকে পরিচালিত করতে পারে না, যখন উত্পাদনে এই ধরণের সমস্যাগুলি উপস্থিত হওয়ার সম্ভাবনাটি কম হয়?

দ্রষ্টব্য: উপরের উদাহরণটি কেবল একটি নমুনা ক্ষেত্রে; এই জাতীয় সমস্যাগুলি যে কোনও ধরণের বৈশিষ্ট্য / মডিউলে ঘটতে পারে।

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

Comments

হয়তো প্রাসঙ্গিক: বানর পরীক্ষামূলক , আগপাছ সঙ্গে

— ক্রিস্টোফ

Answer 1

আপনি কোনও ওয়েব অ্যাপ্লিকেশনের ক্ষেত্রগুলিতে এলোমেলো মান প্রবেশ করতে পারেন না, তবে অবশ্যই সেখানে লোকেরা যা কেবল এটি করে।

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

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

Comments

এবং তারপর বিষয় আছে যা হয় না মানুষ যে এটা করতে। 👽

— kojiro

অথবা তারা তাদের প্রকৃত আইনী নাম যেমন "ও'ম্যালি", "姓名" বা "রবার্ট ') প্রবেশ করার চেষ্টা করতে পারে ; টেবিল ছাত্রদের ড্রপ; - " ।

— l0b0

অথবা প্রকৃত সংস্থার নাম হতে পারে ; টেবিল ড্রপ "সংস্থাগুলি"; - LTD ।

— বেন

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

— ফিহাগ

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

— লুয়ান

Answer 2

কখনই কিছু অনুমান করবেন না

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

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

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

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

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

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

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

Comments

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

— শান বার্টন

আমাদের একটি বক্তব্য রয়েছে: "ইডিয়ট-প্রুফ সফ্টওয়্যার লেখা এত কঠিন কারণ ইডিয়টস এমন চালাক লোক"। সুতরাং, "ননসেন্স" ইনপুটগুলির জন্য পরীক্ষা করুন!

— রাল্ফ ক্লেবারহফ

For example, a user may enter a malicious input which wipes the entire database - if you haven't explicitly protected against and tested for this scenario, then there's no way you can be sure whether or not this can happen.এই এক্সকেসিডি কমিক থেকে ছোট ববি টেবিলের মতো ? ;)

— নিক 012000

"কখনই কিছু ধরে নিও না।" আমি ধরে নিলাম এটি ভাল পরামর্শ।

— candied_orange

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

— এভসুনউবার্ড

Answer 3

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

বিকাশকারী হিসাবে, আপনি সম্ভবত বিবেচনা করছেন যে গ্রহণযোগ্য মানগুলি [0, 1, 2, 3, ⋯ 99, 100], এবং সমস্ত কিছু নির্বোধ। দেখা যাক কেন ব্যবহারকারীরা এখনও এই "নির্বোধ" মানগুলিতে প্রবেশ করতে পারছিলেন।

টাইপস

%^

ব্যবহারকারী ৫ 56 টি মান প্রবেশ করছিল, তবে Shiftসেগুলি প্রবেশের সময় ভুল করে টিপুন (উদাহরণস্বরূপ কারণ ফরাসি কীবোর্ডে আপনাকে Shiftঅঙ্কগুলি প্রবেশ করতে চাপতে হবে, এবং ব্যবহারকারী ক্রমাগত একটি ফরাসী কীবোর্ড এবং একটি QWERTY এর মধ্যে স্যুইচ করছিলেন)।

একইভাবে, আপনি এর আগে বা তার আগে বা এর মধ্যে কিছু সহ একটি নম্বর পেতে পারেন:

56q

এখানে, ব্যবহারকারী সম্ভবত অঙ্কগুলি প্রবেশ করছিলেন, তারপরে একটি ট্যাব পরবর্তী ফিল্ডে যাওয়ার জন্য। চাপ দেওয়ার পরিবর্তে   ⇆  ব্যবহারকারী প্রতিবেশী কীটি টিপলেন।

ভুল বোঝাবুঝি এবং ভুল ব্যাখ্যা

একটি খালি ইনপুট সম্ভবত সবচেয়ে সাধারণ। ব্যবহারকারী কল্পনা করেছিলেন যে ক্ষেত্রটি alচ্ছিক, বা এই ক্ষেত্রে কী স্থাপন করবেন তা জানেন না।

56.5

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

none

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

150

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

[____] % of disk space (2 TB)

যখন ব্যবহারকারী টাইপ করা শুরু করবেন, তখন উড়ে যাওয়ার পাঠ্যটি এটি হয়ে উঠবে:

[5___] % of disk space (102.4 GB of 2 TB)

উপস্থাপনা

ভাসমান পয়েন্ট সহ বড় সংখ্যা বা সংখ্যা পৃথকভাবে উপস্থাপন করা যেতে পারে। উদাহরণস্বরূপ, একটি সংখ্যা 1234,56 যে ভালো লেখা যেতে পারে: 1,234.56। সংস্কৃতির উপর নির্ভর করে একই সংখ্যার পাঠ্য উপস্থাপনা পৃথক হবে। ফরাসি একই নম্বর এই মত লেখা হবে: 1 234,56। দেখুন, এমন একটি কমা যা আপনি আশা করবেন না যেখানে একটি স্থান এবং একটি স্থান।

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

মানব বনাম কম্পিউটার

Twenty-four

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

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

অ্যালান কুপারের বইটিতে আমাকে কেবল যুক্ত করতেই হ'ল অনেক ক্ষেত্রে, সংখ্যাগুলি ভুল করে অঙ্কে লেখা হয় । কম্পিউটারগুলি তাদের ব্যবহারকারীদের ভুল করার প্রত্যাশা করে (এবং সঠিকভাবে লেখেন এমন ব্যবহারকারীকে সহ্য করবে না) এটি বিরক্তিকর।

ইউনিকোড

5𝟨

ইউনিকোড নিজস্ব বিস্ময় সংরক্ষণ করে: যে বর্ণগুলি একই দেখাতে পারে একই রকম নয়। বিশ্বাস হচ্ছে না? "5𝟨" === "56"আপনার ব্রাউজারের বিকাশকারী সরঞ্জামগুলিতে অনুলিপি করুন এবং টিপুন Enter।

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

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

উপসংহার

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

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

Comments

আহ, ইউ + 1 ডি 7 ই 8: ম্যাথমেটিকাল স্যানস-সিরিফ ডিজিট সিক্স।

— Andreas Rejbrand

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

— জানু

একই হোমোগ্লিফ ইস্যু সম্পর্কিত আপনার 5𝟨 বিভাগটি দেখার আগে, আমি আসলে একটি 1 234,56স্ট্রিং (U + 00A0 NO-BREAK স্পেস ব্যবহার করে U + 0020 স্পেসের পরিবর্তে) প্রত্যাশা করছিলাম, যা সেই নম্বর চিহ্নিতকারীকে কোডিং করার উপযুক্ত উপায় (বা U + 202F সহ) ন্যারো নং-BREAK স্পেস, পেরোহ্যাপস)। ব্যবহারকারীর সামনে উপস্থাপন করার আগে লোকাল অনুসারে নম্বরগুলি বিন্যাস করে এমন কোনও অ্যাপ্লিকেশন থেকে মানটি অনুলিপি করা খুব সহজেই তা তৈরি করতে পারে।

— আঞ্জেল

কপি-পেস্ট করা অনেক বড় সমস্যা trouble পেস্ট স্পেস, লাইন ব্রেক, অদৃশ্য অক্ষরগুলি অনুলিপি করা সাধারণ ...

— সুলতান

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

— রোজি এফ

Answer 4

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

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

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

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

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

Comments

কোনও অ্যাপলিকেশনের একটি সাধারণ উদাহরণ যা একটি নির্দিষ্ট অর্ডার প্রত্যাশা করে একটি "টিয়ারডাউন" ফাংশন যা হ্যান্ডলগুলি প্রকাশ করে যা কখনই সংরক্ষিত ছিল না।

— wizzwizz4

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

— ব্রেন্ডন

@ ব্রেন্ডন: কেবলমাত্র একটি বার্তা প্রয়োজন: "এটি অবশ্যই 1 এবং 100 এর মধ্যে একটি সংখ্যা হতে হবে" " স্ট্রিংটি কী, বা "অসমর্থিত অক্ষর" এর অর্থ ব্যবহারকারী জানেন না (এবং এটি জানার দরকার নেই) । এগুলি হ'ল প্রোগ্রামার প্রভাব, না ব্যবহারকারী সাহায্য।

— রবার্ট হার্ভে

@ রবার্টহারভে আমি সম্ভবত "অঙ্কের সমন্বয়ে গঠিত" এর পংক্তিতে সেই বিবৃতিতে কিছু যুক্ত করব। কারণ "সত্তর-নাইন" ইনপুটটি 1 থেকে 100 এর মধ্যে একটি সংখ্যা, তবে বেশিরভাগ প্রোগ্রাম কাজ করতে পারে এমন কোনও ইনপুট নয়।

— বিতরণ করুন

@ ডেলিওথ: আপনি বোকা ঠিক করতে পারবেন না।

— রবার্ট হার্ভে

Answer 5

সাধারণত 'এলোমেলো' মানগুলি এলোমেলো নয়। আপনি কিনারা নেওয়ার চেষ্টা করছেন, "অজানা" cases

উদাহরণস্বরূপ বলুন # অক্ষরটি আপনাকে অ্যাপ্লিকেশান করবে। আপনি এটি আগে থেকে জানেন না এবং প্রতিটি সম্ভাব্য ইনপুটটির জন্য পরীক্ষার কেসগুলি লেখা অসম্ভব। তবে আমরা এর জন্য একটি পরীক্ষা লিখতে পারি "¬!"£$%^&*()_+-=[]{};'#:@~,./<>?|\"এবং এটি ভঙ্গ হয় কিনা তা দেখতে পারি

Comments

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

— ল্যান

ESP। এখন যে মোবাইল কীবোর্ডগুলির সকলের ইমোটিকন রয়েছে

— ইওয়ান

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

— জেমস স্নেল

Answer 6

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

এর পরে আমি একটি পদ্ধতির অনুসরণ করি: if "a very specific use case" do, else show error

যদি আমার বেশ কয়েকটি ব্যবহারের মামলা থাকে তবে আমি সেগুলি কঠোরভাবে সংজ্ঞায়িত করি এবং উপরের শৃঙ্খলাবদ্ধ।

Comments

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

— গুরান

Answer 7

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

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

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

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

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

---

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

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

Comments

এবং একই ধরণের কাজগুলি করার জন্য দ্রুত চেক পরীক্ষার সরঞ্জাম রয়েছে

— আইসিসি ৯7

Answer 8

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

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

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

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

Comments

test every possible type of input that a user will be physically able to submit.- সমস্যাটির জায়গাটি মূলত অসীম এবং আপনি এটি পরীক্ষা করার চেষ্টা করে আপনার সময় নষ্ট করছেন। নেতিবাচক ইনপুটগুলির জন্য অনুসন্ধান করা একটি একক দ্বিখণ্ডন; এটি কেবল বোধগম্য নয়, সক্ষম বিকাশকারীদের কাছ থেকেও প্রত্যাশিত। এই জাতীয় বৈধতা কার্যকর করে তা প্রমাণ করার জন্য আপনাকে প্রতিটি নেতিবাচক নম্বর পরীক্ষা করতে হবে না।

— রবার্ট হার্ভে

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

— আরকানন

Answer 9

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

হ্যাঁ. এটি এক ধরণের পরীক্ষা তবে এটি কার্যকরী পরীক্ষা নয় । এটিকে বলা হয় স্ট্রেস টেস্টিং । কোনও সিস্টেম এটি পরিচালনা করতে পারে কিনা তা দেখার জন্য এটি চাপ প্রয়োগ করার কাজ।

সুতরাং এই সমস্ত টেস্টকেসগুলি সংযুক্ত করে কী ব্যবহার করতে হবে যা / যা বাগের দিকে পরিচালিত করতে পারে না, যখন উত্পাদনে এই ধরণের সমস্যাগুলি উপস্থিত হওয়ার সম্ভাবনাটি কম হয়?

আপনি যখন সফ্টওয়্যারটির স্ট্রেস টেস্টিং করছেন তখন আপনি সফ্টওয়্যারটির সীমাবদ্ধতাগুলির সীমানা আবিষ্কার করার চেষ্টা করছেন।

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

আপনার সমস্ত কার্যকরী পরীক্ষাগুলি পাস হতে পারে তবে স্ট্রেস পরীক্ষায় ব্যর্থ ।

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

হ্যাঁ, এটি একটি স্ট্যান্ডার্ড অনুশীলন।

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

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

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

আমার অর্থ হ'ল প্রতিবার আপনি নিজের সফ্টওয়্যারের একটি নতুন সংস্করণ স্থাপন করার সময় আপনি কেবল স্ট্রেস টেস্টিং চালাতে পারবেন না এবং ধরে নিন এর অর্থ সমস্ত কিছু পরে স্ট্রেস পরীক্ষায় উত্তীর্ণ হবে।