বৈজ্ঞানিক সফ্টওয়্যার জন্য অবিচ্ছিন্ন একীকরণ


22

আমি কোনও সফটওয়্যার ইঞ্জিনিয়ার নই। আমি ভূ-বিজ্ঞানের ক্ষেত্রে পিএইচডি শিক্ষার্থী।

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

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

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

আমার কয়েকটি প্রশ্ন রয়েছে যেখানে আমি কিছু পরামর্শ পেতে চাই:

সফ্টওয়্যারটি কীভাবে কাজ করে তার একটি সংক্ষিপ্ত ব্যাখ্যা প্রথমে:

  • সফ্টওয়্যারটি সমস্ত প্রয়োজনীয় সেটিংসযুক্ত এক .xML ফাইল দ্বারা নিয়ন্ত্রিত হয়। আপনি সফ্টওয়্যারটি কেবল ইনপুট আর্গুমেন্ট হিসাবে .xML ফাইলের পাথ দিয়েই শুরু করেন এবং এটি ফলাফল সহ কয়েকটি ফাইল চালায় এবং তৈরি করে। একটি একক রান ~ 30 সেকেন্ড সময় নিতে পারে।

  • এটি একটি বৈজ্ঞানিক সফ্টওয়্যার। প্রায় সমস্ত কার্যক্রমে একাধিক ইনপুট প্যারামিটার থাকে, যার প্রকারগুলি বেশিরভাগ ক্লাস যা বেশ জটিল। আমার কাছে বড় ক্যাটালগ সহ একাধিক .txt ফাইল রয়েছে যা এই শ্রেণীর উদাহরণ তৈরি করতে ব্যবহৃত হয়।

এখন আমার প্রশ্নে আসা যাক:

  1. ইউনিট পরীক্ষা, ইন্টিগ্রেশন পরীক্ষা, শেষ থেকে শেষের পরীক্ষা? : আমার সফ্টওয়্যারটি এখন প্রায় 30.000 লাইনের কোডের শত শত ফাংশন এবং ~ 80 ক্লাসের সাথে। ইতিমধ্যে বাস্তবায়িত শত শত ফাংশনগুলির জন্য ইউনিট পরীক্ষা লিখতে শুরু করা আমার কাছে একরকম অদ্ভুত মনে হয়। সুতরাং আমি কেবল কিছু পরীক্ষার কেস তৈরি করার কথা ভেবেছিলাম। 10-20 বিভিন্ন .xML ফাইল প্রস্তুত করুন এবং সফ্টওয়্যারটি চালিত হতে দিন। আমার ধারণা এটিকেই শেষ-থেকে-শেষের পরীক্ষা বলা হয়? আমি প্রায়শই পড়েছি যে আপনার এটি করা উচিত নয়, তবে আপনার যদি ইতিমধ্যে একটি ওয়ার্কিং সফ্টওয়্যার থাকে তবে এটি শুরু হিসাবে ঠিক হতে পারে? অথবা এটি ইতিমধ্যে ইতিমধ্যে कार्यरत সফ্টওয়্যারটিতে সিআই যুক্ত করার চেষ্টা করার জন্য কেবল বোবা ধারণা।

  2. ফাংশন প্যারামিটারগুলি তৈরি করা কঠিন হলে আপনি ইউনিট পরীক্ষা কীভাবে লিখবেন? ধরুন আমার একটি ফাংশন রয়েছে double fun(vector<Class_A> a, vector<Class_B>)এবং সাধারণত, টাইপ Class_Aএবং এর অবজেক্ট তৈরি করতে আমার প্রথমে একাধিক পাঠ্য ফাইলগুলিতে পড়তে হবে Class_B। আমি এমন কিছু ডামি ফাংশন তৈরির কথা ভেবেছিলাম যেমন Class_A create_dummy_object()পাঠ্য ফাইলগুলিতে না পড়ে। আমি এক ধরণের সিরিয়ালাইজেশন বাস্তবায়ন সম্পর্কেও ভেবেছিলাম । (ক্লাস অবজেক্টগুলি কেবলমাত্র একাধিক পাঠ্য ফাইলের উপর নির্ভর করে সেগুলি পরীক্ষা করার পরিকল্পনা আমি করি না)

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

সিআইয়ের সাথে অন্য কোনও পরামর্শের প্রশংসা করা হয়।



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

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

উত্তর:


23

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

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

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

ইন্টিগ্রেশন টেস্ট পুরোপুরি ঠিক আছে। আপনার সফ্টওয়্যারটির বিভিন্ন অংশ সঠিকভাবে খেলছে এবং কংক্রিটের দৃশ্যপটের জন্য এটি যাচাই করতে তারা ভাল good

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

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

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

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

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


7

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

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

ফাংশন প্যারামিটারগুলি তৈরি করা কঠিন হলে আপনি ইউনিট পরীক্ষা কীভাবে লিখবেন?

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

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

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

ফলাফলগুলি অত্যন্ত পরিবর্তনশীল হলে কীভাবে পরীক্ষা লিখতে হয়?

কয়েকটি টিপস:

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

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

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

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

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

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

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

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

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

আছে HTH।


2
  1. পরীক্ষার প্রকার

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

      এটিকে অন্যভাবে ভাবুন: বেশ কয়েকটি ফাংশন স্পর্শকারী কোনও প্যাচ যদি আপনার শেষ-শেষের কোনও পরীক্ষাগুলি ভেঙে দেয় তবে আপনি কীভাবে সমস্যাটি নির্ধারণ করবেন?

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

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

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

    • হ্যাঁ, বিদ্যমান সফ্টওয়্যারটিতে সিআই যুক্ত করা বুদ্ধিমান এবং সাধারণ।

  2. কিভাবে ইউনিট পরীক্ষা লিখতে হয়

    যদি আপনার জিনিসগুলি সত্যই ব্যয়বহুল এবং / অথবা জটিল হয় তবে মক লিখুন। পলিমারফিজম ব্যবহার না করে আপনি সত্যিকারের বস্তুগুলি ব্যবহার করে পরীক্ষাগুলি থেকে পৃথক করে মক ব্যবহার করে পরীক্ষাগুলি লিঙ্ক করতে পারেন।

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

  3. পরিবর্তনশীল ফলাফল

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

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


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

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

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

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

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

কিছু টিপস:

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

1

সকালের আগে একটি উত্তরে ইতিমধ্যে কয়েকটি খুব গুরুত্বপূর্ণ বিষয় উল্লেখ করা হয়েছে। আমাকে আরও কিছু যোগ করুন:

1. বৈজ্ঞানিক সফ্টওয়্যার এবং বাণিজ্যিক সফ্টওয়্যার বিকাশের মধ্যে পার্থক্য

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

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

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

আপনি যদি আপনার প্রকল্পটি বাণিজ্যিক সফ্টওয়্যার অনুরূপ একটি সফ্টওয়্যার রূপান্তর করতে চান, আপনার নিম্নলিখিত পরীক্ষা করা উচিত:

  • আপনার কাছে সময় এবং সংস্থান আছে ডু?
  • সফটওয়্যারটির দীর্ঘমেয়াদী দৃষ্টিভঙ্গি কী? আপনি যখন নিজের কাজ শেষ করে বিশ্ববিদ্যালয় ছেড়ে যাবেন তখন সফ্টওয়্যারটির কী হবে?

2. শেষ থেকে শেষ পরীক্ষা

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

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

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

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

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

3. অবিচ্ছিন্ন একীকরণ

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

সুতরাং আমি মনে করি তাত্ত্বিক পটভূমি এবং সংখ্যাসূচক পদ্ধতিগুলি, যত্নবান পরীক্ষা ইত্যাদির বিষয়ে আলোচনা করার পরে সুসংজ্ঞায়িত পদ্ধতিতে ইন্টিগ্রেশনটি আরও ভাল করা ভাল think

আমি মনে করি না যে ক্রমাগত সংহতকরণের জন্য এক ধরণের স্বয়ংক্রিয়তা থাকা ভাল ধারণা।

যাইহোক, আপনি একটি সংস্করণ নিয়ন্ত্রণ সিস্টেম ব্যবহার করছেন?

৪. আপনার সংখ্যার অ্যালগোরিদম পরীক্ষা করা

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

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

আপনি এই পরীক্ষার কোডগুলিতে সেই পরীক্ষাগুলি করতে এবং আপনার উত্পাদন কোডের জন্য দ্রুততম অ্যালগরিদম ব্যবহার করতে পারেন।


0

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

যা বলেছিল, যা মূল্যবান তা হ'ল:

  • অ্যালগরিদমের ক্ষেত্রে এটি কি সেই সময়ের সেরা পদ্ধতি?
  • বিভিন্ন গণনা প্ল্যাটফর্মগুলিতে (বিভিন্ন এইচপিসি পরিবেশ, ওএস স্বাদ ইত্যাদি) পোর্ট করা কত সহজ to
  • দৃust়তা - এটি আমার ডেটাसेटে চালিত হয়?

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

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