যে বাগগুলি তিরস্কার না করে তাদের কী করবেন?


22

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

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

আপনি এই জাতীয় পরিস্থিতিতে কি করবেন?


"কমপ্যাক্ট ফ্রেমওয়ার্ক এবং কোনও লাইন নম্বর নেই" হু? এই কি ভাষা?
TheLQ

1
@TheLQ - C # (ভিজ্যুয়াল স্টুডিও ২০০)) দুঃখজনকভাবে কমপ্যাক্ট ফ্রেমওয়ার্কের কোনও স্ট্যাকের চিহ্নগুলিতে লাইন নম্বর নেই। (আরও তথ্যের জন্য এই প্রশ্ন দেখতে পাবেন stackoverflow.com/questions/3507545/...
Vaccano

7
সময় ব্যয় করার প্রথম জিনিসটি হ'ল প্রোগ্রামটি দরকারী স্ট্যাকের ট্রেস তৈরি করা।

2
ছবিগুলি, বা এটি ঘটেনি। : পি
ক্যামেরন ম্যাকফারল্যান্ড

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

উত্তর:


51

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

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


19

শেষ পর্যন্ত যদি বিকাশকারী বা পরীক্ষক কেউ বাগটি পুনরুত্পাদন করতে না পারে তবে এটি বন্ধ করে দেওয়া উচিত তবে এটি চিহ্নিত করা উচিত।

তবে আপনাকে এই মুহুর্তে পৌঁছাতে কতক্ষণ সময় লাগে তা বিতর্কযোগ্য।

কিছু লোক যুক্তি দেখান যে এটি যদি তাৎক্ষণিকভাবে পুনরুত্পাদনযোগ্য না হয় তবে তা সঙ্গে সঙ্গে এটি বন্ধ করা উচিত।

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

একটি ফাইনাল চিন্তার - হিসাবে "নো-repro" বন্ধ করে না নির্দিষ্ট মানে। যদি সত্যিকারের সমস্যা থাকে তবে তা তাড়াতাড়ি বা পরে প্রকাশ পাবে এবং অবশেষে সমস্যাটি পুনরুত্পাদন করতে পারলে সমস্ত তথ্য আপনি সহায়তা করতে পারবেন।


16

আরও কয়েকটি পরামর্শ:

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

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

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


4

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

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

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


3

এখানে দুটি ধরণের বাগ রয়েছে যা পুনরায় উত্পাদনযোগ্য নয়:

1) যাঁরা পরীক্ষক (বা ব্যবহারকারী) একবার দেখেছেন কিন্তু তারা পুনরুত্পাদন করার চেষ্টা করতে পারেন নি বা হয় নি।

এই পরিস্থিতিতে আপনার উচিত:

  • খুব সংক্ষেপে ক্রিয়াকলাপগুলির মৌলিক কোর্সটি পরীক্ষা করুন যা এটি পুনরায় উত্পাদনযোগ্য নয় তা নিশ্চিত করার জন্য ত্রুটি দেখিয়েছিল।

  • পরীক্ষক / ব্যবহারকারীর সাথে কথা বলুন যাতে অন্য কোনও তথ্য রয়েছে যা সাহায্য করতে পারে তা দেখতে।

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

  • যদি আপনার এখনও চালিয়ে যাওয়ার পর্যাপ্ত পরিমাণ না থাকে তবে আপনাকে ব্যবহারকারী / পরীক্ষককে বোঝাতে হবে যে আপনার পর্যাপ্ত তথ্য নেই। পর্যাপ্ত তথ্যের মতো দেখতে এবং কেন এটি প্রয়োজন তা বিনয়ের সাথে তাদেরকে জানিয়ে দিন।

২) যেখানে তারা নির্ভরযোগ্যভাবে পুনরুত্পাদন করা যায় না, তবুও যথেষ্ট প্রমাণ রয়েছে (পুনরাবৃত্ত ঘটনার পরিপ্রেক্ষিতে) যে ত্রুটি রয়েছে তার প্রস্তাব দেওয়ার জন্য, তখন আমি দেখতে পাই যে এগুলি বিকাশকারী সমস্যা এবং বিকাশকারী - পরীক্ষক দ্বারা সমর্থিত / ব্যবহারকারী - তদন্ত করা প্রয়োজন।

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


2

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

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

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


1

সাধারণত আমি নোট করি যে এটি পুনরুত্পাদনযোগ্য নয়, তবে পরীক্ষার বা পুনরাবৃত্তির ব্যাচটি সম্পূর্ণ না হওয়া পর্যন্ত এটি খোলা রাখুন।

যদি সেই বিন্দুটির দ্বারা এটি পুনরুত্পাদন না করা হয় তবে এটি বন্ধ রয়েছে, তবে যদি আবার মুখোমুখি হয় তবে এটি পুনরায় খোলা যেতে পারে।


1

এই পরীক্ষকের ওয়ার্কস্টেশনে একটি কীলগার আটকে দিন!


2
আপনি যদি সত্যিই ভাগ্যবান হন তবে কীবোর্ড লগার এমন কোনও পার্শ্ব-প্রতিক্রিয়া তৈরি করতে পারে যা বাগটিকে machine মেশিনে পুনরুত্পাদন করা অসম্ভব করে তোলে। printfকোডের মধ্যে অতিরিক্ত রাখার ফলে বাগটি অদৃশ্য হয়ে যাওয়ার মতো পরিস্থিতি কখনও কখনও ছিল ? :)
স্কট হুইটলক

3
কোনও ভিডিও ক্যামেরার উপস্থিতিও কি ত্রুটি সৃষ্টি করতে পারে?
কাজ

1
ভিডিও ক্যামেরা - না, তবে
জিং

1

ঠিক আছে, প্রথম কাজটি একটি পুনরুত্পাদনযোগ্য টেস্ট সিস্টেম থাকা। আপনার পরীক্ষকের অবশ্যই একটি সংজ্ঞায়িত প্রক্রিয়া থাকতে হবে - যদি সম্ভব হয় তবে স্বয়ংক্রিয়ভাবে automatic

এই তিনটি শর্ত রয়েছে:

  • একই বাইনারি
  • একই পদক্ষেপ
  • একই মেশিন

উপরের 3 টি শর্তের সাথে যদি বাগটি ছড়িয়ে ছিটিয়ে থাকে তবে আরও বিচ্ছিন্ন করা শুরু করুন। সিস্টেম স্ট্যাকের প্রতিটি স্তর এবং এর কনফিগারেশন বিবেচনা করুন।

মেমরি পরিচালনা ত্রুটিগুলি সনাক্ত করার একটি উপায় হ'ল একাধিক সংকলক সহ একাধিক ওএসে প্রোগ্রামটি চালানো। ভালগ্রাইন্ডও সাহায্য করতে পারে।

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


0

প্রথমত, আপনার কঠোর পরীক্ষার পদ্ধতি থাকা উচিত (তবে আমি আপনাকে বুঝতে পারি, আমার সংস্থায় আপনি যা বর্ণনা করেছেন তা ঘন ঘন ঘটে)।

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

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