ফলাফলের পূর্বাভাস দেওয়া কঠিন সহ আপনি কোডের জন্য ইউনিট পরীক্ষা কীভাবে লিখবেন?


124

আমি প্রায়শই খুব সংখ্যাসূচক / গাণিতিক প্রোগ্রামগুলির সাথে কাজ করি, যেখানে কোনও ফাংশনের সঠিক ফলাফল আগে থেকেই অনুমান করা শক্ত।

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

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

ফলাফলগুলির পূর্বাভাস দেওয়া কঠিন সহ কোডের একটি (বাস্তব) উদাহরণ:

এমন একটি ফাংশন weightedTasksOnTimeযা প্রতিদিন workPerDayপরিসীমা (0, 24], বর্তমান সময় initialTime> 0, এবং কাজের তালিকা দেওয়া taskArray; প্রতিটি সম্পত্তি সমাপ্ত করার সময় time> 0, নির্ধারিত তারিখ dueএবং গুরুত্ব মূল্য সহ প্রদত্ত কাজ importance; রিটার্ন দেয় পরিসীমাতে একটি স্বাভাবিক মান [0, 1] যে কার্যগুলির dueতারিখের পূর্বে সম্পূর্ণ করা যেতে পারে এমন কার্যগুলির গুরুত্বের প্রতিনিধিত্ব করে যদি প্রতিটি কার্য সম্পাদন করে দেওয়া আদেশ অনুসারে সম্পন্ন হয় তবে taskArrayশুরু করুন initialTime

এই ফাংশনটি বাস্তবায়নের জন্য অ্যালগরিদম তুলনামূলকভাবে সহজবোধ্য: কার্যগুলিতে পুনরাবৃত্তি taskArray। প্রতিটি কাজের জন্য, যুক্ত timeকরুন initialTime। নতুন সময় <হলে due, importanceএকটি সঞ্চয়ের সাথে যুক্ত করুন। সময়টি বিপরীতমুখী ওয়ার্কপেই দ্বারা সামঞ্জস্য করা হয়। সঞ্চালককে ফেরত দেওয়ার আগে, স্বাভাবিক করার জন্য টাস্ক আমদানির যোগফলকে ভাগ করুন।

function weightedTasksOnTime(workPerDay, initialTime, taskArray) {
    let simulatedTime = initialTime
    let accumulator = 0;
    for (task in taskArray) {
        simulatedTime += task.time * (24 / workPerDay)
        if (simulatedTime < task.due) {
            accumulator += task.importance
        }
    }
    return accumulator / totalImportance(taskArray)
}

আমি বিশ্বাস করি যে উপরের সমস্যাটি সরল করা যায়, এর মূলটি বজায় রেখে মুছে ফেলা workPerDayএবং সাধারণীকরণের প্রয়োজনীয়তা দিয়ে:

function weightedTasksOnTime(initialTime, taskArray) {
    let simulatedTime = initialTime
    let accumulator = 0;
    for (task in taskArray) {
        simulatedTime += task.time
        if (simulatedTime < task.due) {
            accumulator += task.importance
        }
    }
    return accumulator
}

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


4
আপনি কি এমন কোনও ফাংশনটির সহজ উদাহরণ প্রদান করতে পারেন যার ফলাফল অনুমান করা শক্ত?
রবার্ট হার্ভে

62
FWIW আপনি অ্যালগরিদম পরীক্ষা করছেন না। সম্ভবত এটি সঠিক। আপনি বাস্তবায়ন পরীক্ষা করছেন। এএ সমান্তরাল নির্মাণ হিসাবে হাত দিয়ে কাজ করা প্রায়শই সূক্ষ্ম হয়।
ক্রিশ্চিয়ান এইচ


7
এমন পরিস্থিতি রয়েছে যেখানে একটি অ্যালগরিদম যুক্তিসঙ্গতভাবে ইউনিট পরীক্ষা করা যায় না - উদাহরণস্বরূপ যদি এর কার্যকরকরণের সময় একাধিক দিন / মাস হয়। এনপি সমস্যা সমাধানের সময় এটি ঘটতে পারে। এই ক্ষেত্রে, কোডটি সঠিক কিনা তা একটি প্রথাগত প্রমাণ দেওয়া আরও সম্ভাব্য হতে পারে ।
হাল্ক

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

উত্তর:


251

কঠিন-পরীক্ষার কোডে আপনি দুটি জিনিস পরীক্ষা করতে পারেন। প্রথমত, অধঃপতনের মামলাগুলি। যদি আপনার টাস্ক অ্যারেতে কোনও উপাদান না থাকে, বা কেবল একটি, বা দুটি কিন্তু একটি নির্ধারিত তারিখের অতীত হয় ইত্যাদি thing আপনার আসল সমস্যার তুলনায় সহজ যে কোনও কিছুই, তবে ম্যানুয়ালি গণনা করা এখনও যুক্তিসঙ্গত।

দ্বিতীয়টি হল স্যানিটি চেক। এই উত্তরগুলি সঠিক কিনা তা আপনি জানেন না এমন জায়গাগুলি এই চেকগুলি কিন্তু আপনি ভুল জানেন কিনা তা অবশ্যই জানাবেন । এগুলি এমন বিষয়গুলির মতো যা সময়ের অবশ্যই এগিয়ে যেতে হবে, মানগুলি অবশ্যই যুক্তিসঙ্গত পরিসরে থাকতে হবে, শতাংশ অবশ্যই 100 পর্যন্ত যোগ করতে হবে ইত্যাদি etc.

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


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

21
আরেকটি জিনিস যা কিছু ক্ষেত্রে সহায়ক হতে পারে (যদিও এটি সম্ভবত এটি নয়) হ'ল একটি বিপরীত ফাংশন লিখতে এবং পরীক্ষা করা হয় যে, যখন শৃঙ্খলিত হয় তখন আপনার ইনপুট এবং আউটপুট একই থাকে।
সাইবারস্পার্ক

7
স্যানিটি চেক প্রায়শই কুইকচেক
জে কে এর

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

5
@ iFlo আপনি মজা করছেন কিনা তা নিশ্চিত নন, তবে বিপরীত বিপরীতটি ইতিমধ্যে উপস্থিত রয়েছে। পরীক্ষার ব্যর্থতা বিপরীত কার্যক্রমে সমস্যা হতে পারে তা বুঝতে
পেরেও মূল্যবান

80

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

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


32
রূপক সম্পর্ক সম্পত্তি-ভিত্তিক পরীক্ষার একটি সুনির্দিষ্ট উদাহরণ , যা সাধারণভাবে এই জাতীয় পরিস্থিতির জন্য একটি দরকারী সরঞ্জাম
ড্যান্ন্নো

38

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

এটি সনাক্ত করবে যে অ্যালগরিদম (বা এটির উপর নির্ভর করে ডেটা) পরিবর্তিত হয়েছে কিনা

পরিবর্তনটি যদি কোনও দুর্ঘটনা হয় তবে আপনি কোনও প্রতিশ্রুতি ফিরিয়ে আনতে পারেন। যদি পরিবর্তনটি ইচ্ছাকৃত হয়, আপনার ইউনিট পরীক্ষাটি পুনরায় দেখতে হবে।


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

21

আপনি অন্য যে কোনও ধরণের কোডের জন্য ইউনিট পরীক্ষাগুলি একইভাবে লেখেন:

  1. কিছু প্রতিনিধি পরীক্ষার কেস সন্ধান করুন এবং সেগুলি পরীক্ষা করুন।
  2. প্রান্তের কেসগুলি সন্ধান করুন এবং সেগুলি পরীক্ষা করুন।
  3. ত্রুটির শর্তগুলি সন্ধান করুন এবং সেগুলি পরীক্ষা করুন।

আপনার কোডে কিছু এলোমেলো উপাদান জড়িত না থাকলে বা নির্ণায়ক না হয় (যেমন এটি একই ইনপুট প্রদত্ত একই আউটপুট উত্পাদন করে না), এটি ইউনিট পরীক্ষামূলক।

পার্শ্ব প্রতিক্রিয়া বা বাহ্যিক বাহিনী দ্বারা প্রভাবিত ফাংশন এড়িয়ে চলুন। খাঁটি ফাংশনগুলি পরীক্ষা করা সহজ।


2
অ-নিরোধক অ্যালগরিদমগুলির জন্য আপনি আরএনজির বীজ সংরক্ষণ করতে পারেন বা এটি নির্ধারিত ক্রম বা স্বল্প
তাত্পর্য

14
@ পেন্টিংইনএয়ার যদি অ্যালগরিদমের আউটপুট যাচাই করা অসম্ভব, তবে কি অ্যালগরিদমটিও ভুল হতে পারে ?
ওল্ফগ্যাংগ্রয়েস

5
Unless your code involves some random elementএখানে কৌশলটি আপনার এলোমেলো সংখ্যা জেনারেটরটিকে ইঞ্জেকড নির্ভরতা তৈরি করা, যাতে আপনি এটির পরে কোনও সংখ্যক জেনারেটরের জন্য এটি প্রতিস্থাপন করতে পারেন যা আপনি এটি করতে চান সঠিক ফলাফল দেয়। এটি আপনাকে পুনরায় সঠিকভাবে পরীক্ষা করতে সক্ষম করে - উত্পন্ন সংখ্যাগুলিও ইনপুট প্যারামিটার হিসাবে গণনা করে। not deterministic (i.e. it won't produce the same output given the same input)যেহেতু একটি ইউনিট পরীক্ষা নিয়ন্ত্রিত পরিস্থিতি থেকে শুরু করা উচিত , এটি কেবল অ-নিরস্তকর হতে পারে যদি এটির এলোমেলো উপাদান থাকে - তবে আপনি ইনজেক্ট করতে পারেন। আমি এখানে অন্যান্য সম্ভাবনার কথা ভাবতে পারি না।
ফ্লটার

3
@ পেন্টিংইনএয়ার: হয় বা হয়। আমার মন্তব্য দ্রুত সম্পাদন বা দ্রুত পরীক্ষার লিখন উভয়ের ক্ষেত্রেই প্রযোজ্য। যদি হাতের মাধ্যমে একটি একক উদাহরণ গণনা করতে আপনার যদি তিন দিন সময় লাগে (তাহলে ধরে নেওয়া যাক আপনি কোডটি ব্যবহার করছেন না এমন দ্রুততম পদ্ধতিটি ব্যবহার করছেন) - তবে তিন দিন এটি গ্রহণ করবে। আপনি যদি পরিবর্তে আপনার প্রত্যাশিত পরীক্ষার ফলাফলটিকে আসল কোডের উপর ভিত্তি করে তৈরি করেন তবে পরীক্ষাটি নিজেই আপস করছে। এটি করার মতো if(x == x), এটি অর্থহীন তুলনা। একে অপরের থেকে স্বতন্ত্র হওয়ার জন্য আপনার দুটি ফলাফল ( প্রকৃত : কোড থেকে আসে; প্রত্যাশিত : আপনার বাহ্যিক জ্ঞান থেকে আসে) দরকার independent
8-10

2
এটি এখনও ইউনিট পরীক্ষামূলক এমনকি ডিটারমিনিস্টিক না হলেও সরবরাহ করে এটি নির্দিষ্টকরণের সাথে সম্মতি দেয় এবং সেই সম্মতিটি পরিমাপ করা যায় (উদাঃ বিতরণ এবং এলোমেলোভাবে ছড়িয়ে দেওয়া) অসাধারণতার ঝুঁকি দূর করতে কেবল অনেকগুলি নমুনার প্রয়োজন হতে পারে।
mckenzm

17

পোস্ট করা মন্তব্যের কারণে আপডেট

আসল উত্তরটি ব্রিভিটির পক্ষে মুছে ফেলা হয়েছিল - আপনি সম্পাদনা ইতিহাসে এটি খুঁজে পেতে পারেন।

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

অন্যথায় দীর্ঘ উত্তর এড়াতে প্রথমে একটি টিএল; ডিআর :

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

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

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

আপনি যদি গ্রাহক এবং কুক উভয়ই হন তবে এর মধ্যে এখনও একটি অর্থপূর্ণ পার্থক্য রয়েছে:

  • আমি এই খাবারটি সঠিকভাবে প্রস্তুত করি নি, এটি সুস্বাদু ছিল না (= রান্নার ত্রুটি)। পোড়া স্টেক কখনও ভাল স্বাদ পাবে না, এমনকি আপনি স্টেক পছন্দ করেন।
  • আমি খাবারটি সঠিকভাবে প্রস্তুত করেছি, তবে আমি এটি পছন্দ করি না (= গ্রাহকের ত্রুটি)। আপনি যদি স্টেক পছন্দ করেন না, আপনি কখনও স্টেক খাওয়া পছন্দ করেন না, এমনকি যদি আপনি এটি সিদ্ধতায় রান্না করেন।

এখানে মূল সমস্যাটি হ'ল আপনি গ্রাহক এবং বিকাশকারী (এবং বিশ্লেষক - যদিও সেই ভূমিকাটি একজন বিকাশকারীও প্রতিনিধিত্ব করতে পারেন) এর মধ্যে বিচ্ছেদ তৈরি করছেন না।

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

উদাহরণস্বরূপ, গ্রাহক এটি [এটি] এর মতো কাজ করতে চান । তবে, বিকাশকারী ভুল বুঝে এবং তিনি কোড লিখেছেন যা [যা] করে

বিকাশকারী সুতরাং ইউনিট পরীক্ষা লিখবে যা পরীক্ষার পরীক্ষা করে [ যদি ] প্রত্যাশা অনুযায়ী কাজ করে। যদি তিনি অ্যাপ্লিকেশনটি সঠিকভাবে বিকশিত করেন তবে অ্যাপ্লিকেশনটি [এটি] না করলেও তার ইউনিট পরীক্ষা পাস হবে , যা গ্রাহক আশা করেছিলেন।

আপনি যদি গ্রাহকের প্রত্যাশা (ব্যবসায়ের প্রয়োজনীয়তা) পরীক্ষা করতে চান তবে এটি আলাদা (এবং পরে) পদক্ষেপে করা দরকার।

এই পরীক্ষাগুলি কখন চালানো উচিত তা আপনাকে দেখানোর জন্য একটি সাধারণ বিকাশের ওয়ার্কফ্লো:

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

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

  • ইউনিট পরীক্ষাগুলি একটি বিশেষ সরঞ্জাম যা আপনার বিকাশের পর্যায়ে শেষ হয়েছে কিনা তা যাচাই করতে আপনাকে সহায়তা করে।
  • QA তে পরীক্ষার দ্বারা সম্পন্ন হয় অ্যাপ্লিকেশন ব্যবহার করে

আপনার অ্যালগোরিদম নিজেই সঠিক কিনা তা আপনি যদি পরীক্ষা করতে চান তবে এটি বিকাশকারীদের কাজের অংশ নয় । এটি গ্রাহকের উদ্বেগ, এবং গ্রাহক অ্যাপ্লিকেশনটি ব্যবহার করে এটি পরীক্ষা করবেন ।

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

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

"যদি আপনি নিজেই অ্যালগোরিদম নিয়ে এসেছেন" পরিস্থিতি সম্পর্কে আরও বিস্তৃততা দেখে আমি খুশি হব, কারণ আমি মনে করি যে সমস্যাগুলি সম্ভবত এমন পরিস্থিতি সম্ভবত দেখা দেয়। বিশেষত এমন পরিস্থিতিতে যেখানে "যদি A হয় তবে B, অন্য C" উদাহরণ সরবরাহ করা হয় না। (পিএস আমি ডাউনভোটার নই)
পেইন্টিংইনএয়ার

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

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

4
এই উত্তর ইতিমধ্যে বিশাল। মূল বিষয়বস্তু সংশোধন করার উপায় সন্ধানের জন্য উচ্চ প্রস্তাব দিন যাতে আপনি এটি ফেলে দিতে চান না তবে আপনি কেবল নতুন উত্তরে এটি সংহত করতে পারেন।
jpmc26

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

9

সম্পত্তি পরীক্ষা

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

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

যে আমি দেখা করেছি প্রপার্টি টেস্টিং সেরা ভূমিকা অন্যতম এই এক এফ # হবে। আশা করি সিনট্যাক্সটি কৌশলটির ব্যাখ্যা বুঝতে কোনও বাধা নয়।


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

4

কোডটি লিখতে এবং তারপরে ফলাফলটি "সঠিক দেখাচ্ছে" কিনা তা দেখতে লোভনীয়, তবে আপনি যেমন সঠিকভাবে অন্তর্নিহিত হন, এটি কোনও ভাল ধারণা নয়।

যখন অ্যালগরিদম শক্ত হয় আপনি ফলাফলের ম্যানুয়াল গণনাটি আরও সহজ করতে বেশ কয়েকটি কাজ করতে পারেন।

  1. এক্সেল ব্যবহার করুন। আপনার জন্য গণনার কিছু বা সমস্ত করে এমন একটি স্প্রেডশিট সেট আপ করুন। এটি পর্যাপ্ত সরল রাখুন যাতে আপনি পদক্ষেপগুলি দেখতে পারেন।

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

  3. স্যানিটি-চেক করতে সামগ্রিক বৈশিষ্ট্যগুলি ব্যবহার করুন। উদাহরণস্বরূপ, বলুন আপনার একটি সম্ভাব্য ক্যালকুলেটর রয়েছে; স্বতন্ত্র ফলাফলগুলি কী হওয়া উচিত তা আপনি জানেন না, তবে আপনি জানেন যে তাদের সকলকে 100% পর্যন্ত যোগ করতে হবে।

  4. পাশবিক বল. এমন একটি প্রোগ্রাম লিখুন যা সমস্ত সম্ভাব্য ফলাফল উত্পন্ন করে এবং আপনার অ্যালগরিদম যা উত্পন্ন করে তার চেয়ে ভাল আর কোনও নয় check


3 এর জন্য, এখানে কিছু গোলাকার ত্রুটিগুলির জন্য অনুমতি দিন। এটি সম্ভব যে আপনার মোট পরিমাণ 100,000001% বা একইভাবে নিকট-তবে-সঠিক চিত্র নয়।
ফ্লটার

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

6
@ ফ্লাটার সাধারণত আপনার অন্যান্য প্রয়োজনীয়তা এবং যথাযথতা যা বক্ষ শক্তি পূরণ করে না। যেমন কর্মক্ষমতা।
ইভান

1
@ ফ্ল্যাটার আপনি যদি বিশ্বাস করেন তবে আমি আপনার ধরণের, ছোটতম পথ, দাবা ইঞ্জিন ইত্যাদি ব্যবহার করতে ঘৃণা করব। তবে আইডি সম্পূর্ণরূপে জুয়া
ইওয়ান

3
@ ফ্লাটার আপনি যখন রাজা পদ্মার শেষের খেলায় পৌঁছবেন তখন কি আপনি পদত্যাগ করবেন? কেবলমাত্র পুরো গেমটি জোর করে জবরদস্তি করা মানে না এমন একটি ইন্ডিভিউয়াল পজিশনের ছোঁয়াছুটি। আপনি কোনও নেটওয়ার্কের সঠিক সংক্ষিপ্ততম পাথকে জোর করে দেওয়ার কারণেই আপনি সমস্ত নেটওয়ার্কের সবচেয়ে সংক্ষিপ্ত পথটি জানেন
ইয়ান

2

টি এল; ডিআর

অন্যান্য উত্তরে নয় এমন পরামর্শের জন্য "তুলনামূলক পরীক্ষা" বিভাগে যান Head


সূচনা

অ্যালগরিদম ( workPerDayউদাহরণস্বরূপ শূন্য বা নেতিবাচক ) এবং তুচ্ছ (যেমন খালি tasksঅ্যারে) দ্বারা প্রত্যাখ্যান করা উচিত এমন কেসগুলি পরীক্ষা করে শুরু করুন ।

এর পরে, আপনি প্রথমে সবচেয়ে সহজ কেসগুলি পরীক্ষা করতে চান। ইনপুটটির জন্য tasks, আমাদের বিভিন্ন দৈর্ঘ্য পরীক্ষা করতে হবে; এটি 0, 1 এবং 2 উপাদান পরীক্ষা করার জন্য পর্যাপ্ত হওয়া উচিত (2 এই পরীক্ষার জন্য "অনেক" বিভাগের অন্তর্গত)।

আপনি যদি মানসিকভাবে গণনা করা যায় এমন ইনপুটগুলি খুঁজে পেতে পারেন, এটি একটি ভাল শুরু। আমি যে কৌশলটি মাঝে মাঝে ব্যবহার করি তা হ'ল পছন্দসই ফলাফল থেকে শুরু করে এবং ফলাফলটি তৈরি করা উচিত এমন ইনপুটগুলিতে ফিরে আসার জন্য (বিশেষত) work

তুলনামূলক পরীক্ষা

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

ফলব্যাক

কখনও কখনও আমাকে অনুমানের সাথে সম্পর্কিত পদক্ষেপগুলিতে একটি হ্যান্ড-গণিত ফলাফল দেখানো দীর্ঘ মন্তব্যের অবলম্বন করতে হয়েছিল (এ জাতীয় মন্তব্য সাধারণত পরীক্ষার ক্ষেত্রে দীর্ঘ হয়)। সবচেয়ে খারাপ অবস্থা হ'ল যখন আপনাকে কোনও ভিন্ন ভাষায় বা ভিন্ন পরিবেশের জন্য পূর্বের প্রয়োগের সাথে সামঞ্জস্যতা বজায় রাখতে হয়। কখনও কখনও আপনি যেমন কিছু দিয়ে পরীক্ষা ডেটা লেবেল করতে হবে /* derived from v2.6 implementation on ARM system */। এটি খুব সন্তোষজনক নয়, তবে পোর্টিংয়ের সময় একটি বিশ্বস্ততা পরীক্ষা হিসাবে বা স্বল্প-মেয়াদী ক্রাচ হিসাবে গ্রহণযোগ্য হতে পারে।

অনুস্মারক

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

নির্ভুল ফলাফলের জন্য উপযুক্ত "প্রায় সমতুল্য" ব্যবহার করতে ভুলবেন না (যেমন ভাসমান-পয়েন্ট)।

অতিরিক্ত পরীক্ষা করা এড়ান - কেবলমাত্র একটি পরীক্ষা যুক্ত করুন যদি এটি এমন কিছু (যেমন সীমানা মান) কভার করে যা অন্য পরীক্ষাগুলির দ্বারা পৌঁছায় না।


2

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

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

তারপরে স্পষ্টতই, প্রান্তের কেসগুলি (যেমন আপনার উদাহরণস্বরূপ) কাজের ফাঁকা তালিকা আনুন; যে জিনিস।

আপনার পরীক্ষার স্যুট সম্ভবত এমন কোনও পদ্ধতির মতো দুর্দান্ত হবে না যেখানে আপনি সহজেই ফলাফলের পূর্বাভাস দিতে পারেন; তবে এখনও কোনও পরীক্ষার স্যুটের চেয়ে 100% ভাল (বা কেবল ধূমপান পরীক্ষা)।

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

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


2

অন্যান্য উত্তরগুলি ভাল, তাই আমি এগুলি এখনও সম্মিলিতভাবে মিস করেছি এমন কিছু পয়েন্টগুলিতে আঘাত করার চেষ্টা করব।

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

কয়েকটি টিপস (সাধারণ বৈজ্ঞানিক / সংখ্যাগত পরীক্ষার জন্য):

1) বিপরীতমুখী ব্যবহার করুন। কী fftএর [1,2,3,4,5]? কোন ধারণা নেই. কি ifft(fft([1,2,3,4,5]))? হওয়া উচিত [1,2,3,4,5](বা এটির নিকটে, ভাসমান পয়েন্ট ত্রুটিগুলি উপস্থিত হতে পারে)। একই ক্ষেত্রে 2 ডি মামলায় যায়।

2) জ্ঞাত asserts ব্যবহার করুন। আপনি যদি একটি নির্ধারক ফাংশন লিখেন তবে নির্ধারকটি এলোমেলো 100x100 ম্যাট্রিক্সের কী তা বলা শক্ত। তবে আপনি জানেন যে সনাক্তকরণের ম্যাট্রিক্সের নির্ধারক 1, এমনকি এটি 100x100 হলেও। আপনি এটিও জানেন যে ফাংশনটি 0-এ কোনও অ-পরিবর্তনীয় ম্যাট্রিক্সে ফিরে আসবে (সমস্ত 0s পূর্ণ 100x100 এর মতো)।

3) নির্ভুল asserts পরিবর্তে রুক্ষ asserts ব্যবহার করুন । আমি এসএআর প্রসেস প্রসেসিংয়ের জন্য কিছু কোড লিখেছি যা টাই পয়েন্ট তৈরি করে দুটি চিত্র নিবন্ধভুক্ত করবে যা চিত্রগুলির মধ্যে একটি ম্যাপিং তৈরি করে এবং তারপরে ম্যাচটি তৈরি করার জন্য তাদের মাঝে একটি মোড়ক তৈরি করে। এটি একটি উপ-পিক্সেল স্তরে নিবন্ধন করতে পারে। প্রথমত, দুটি চিত্রের নিবন্ধন কেমন হতে পারে সে সম্পর্কে কিছু বলা শক্ত । আপনি এটি পরীক্ষা করতে পারেন কিভাবে? ভালো জিনিস:

EXPECT_TRUE(register(img1, img2).size() < min(img1.size(), img2.size()))

যেহেতু আপনি কেবল ওভারল্যাপিং অংশগুলিতে নিবন্ধন করতে পারেন, নিবন্ধিত চিত্রটি অবশ্যই আপনার ক্ষুদ্রতম চিত্রের চেয়ে ছোট বা সমান হতে হবে :

scale = 255
EXPECT_PIXEL_EQ_WITH_TOLERANCE(reg(img, img), img, .05*scale)

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

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

৪) আপনার আরএনজির জন্য একটি এলোমেলো সংখ্যার বীজ ব্যবহার করুন বা সঞ্চয় করুন।

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

আপনার বিশেষ কেস

1) পরীক্ষা করুন যে খালি taskArray 0 দেয় (জোর দেওয়া হিসাবে পরিচিত)।

2) র্যান্ডম ইনপুট যেমন যে জেনারেট করুন task.time > 0 , task.due > 0, এবং task.importance > 0 সবার জন্য task S, এবং জাহির ফলাফলের চেয়ে বেশী 0 (রুক্ষ জাহির, র্যান্ডম ইনপুট) । আপনার পাগল হওয়ার এবং এলোমেলো বীজ উত্পন্ন করার দরকার নেই, আপনার অ্যালগরিদম এটির সত্যতা পাওয়ার পক্ষে যথেষ্ট জটিল নয়। এটি পরিশোধের প্রায় 0 টি সুযোগ রয়েছে: পরীক্ষাটি সহজ রাখুন keep

3) পরীক্ষা যদি task.importance == 0 সকলের জন্য হয় task , তবে ফলাফলটি 0 (দৃ as় হিসাবে পরিচিত) হয়

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

আছে HTH।


1

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

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

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


1

এখানে অন্যান্য কয়েকটি উত্তর খুব ভাল:

  • পরীক্ষার বেস, প্রান্ত এবং কোণার কেস
  • স্যানিটি পরীক্ষা করে নিন
  • তুলনামূলক পরীক্ষা করা

... আমি আরও কয়েকটি কৌশল যুক্ত করব:

  • সমস্যাটি দ্রবীভূত করুন।
  • কোডের বাইরে অ্যালগোরিদম প্রমাণ করুন।
  • পরীক্ষা করুন যে [বাহ্যিকভাবে প্রমাণিত] অ্যালগরিদমটি নকশা অনুযায়ী প্রয়োগ করা হয়েছে।

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

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


0

এটি কিছুটা আদর্শবাদী উত্তরের মতো মনে হতে পারে তবে এটি বিভিন্ন ধরণের পরীক্ষার শনাক্ত করতে সহায়তা করে।

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

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

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


0

আমি মনে করি প্রক্রিয়াটি অনুসরণ করার জন্য এটি পুরোপুরি গ্রহণযোগ্য:

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

এটি কোনও পরিস্থিতিতেই যুক্তিসঙ্গত পন্থা যেখানে হাতের মাধ্যমে কোনও উত্তরের সঠিকতা যাচাই করা প্রথম নীতিগুলি থেকে উত্তর দ্বারা হাতে গণনার চেয়ে সহজ।

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

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


0

অন্যান্য উত্তরের উত্তরগুলিতে পরীক্ষার ফাংশনটির বাইরে নির্দিষ্ট ফলাফল নির্ধারণ করা যায় না তখন একটি পরীক্ষা কেমন লাগে তার কৌশলগুলি ইতিমধ্যে রয়েছে ।

আমি অতিরিক্ত যা করি যা অন্য জবাবগুলিতে আমি চিহ্নিত করি নি তা হ'ল কোনওভাবে টেস্টগুলি স্বয়ংক্রিয়ভাবে উত্পন্ন করা:

  1. 'এলোমেলো' ইনপুট
  2. তথ্য ব্যাপ্তি জুড়ে Iteration
  3. সীমানা সেট থেকে পরীক্ষার কেস নির্মাণ
  4. সবার উপরে.

উদাহরণস্বরূপ, যদি ফাংশনটি অনুমোদিত ইনপুট পরিসীমা [-1,1] এর সাথে প্রতিটি তিনটি পরামিতি নেয় তবে প্রতিটি প্যারামিটারের সমস্ত সংমিশ্রণগুলি পরীক্ষা করুন, {-2, -1.01, -1, -0.99, -0.5, -0.01, 0,0.01 0.5 0.5,0.99,1,1.01,2, (-1,1) এ আরও কিছু এলোমেলো}

সংক্ষেপে: কখনও কখনও নিম্ন মানের পরিমাণের সাহায্যে ভর্তুকি দেওয়া যেতে পারে।

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