در دنیای کامپیوتر، باگ یک خطای کدنویسی در یک برنامه کامپیوتری است. فرآیند یافتن این باگ ها (قبل از اینکه کاربران پیداشون کنند) دیباگ (debug) نام دارد.
دیباگ یا دیباگینیگ یا اشکال زدایی پس از نوشتن کد شروع می شود.
کد با دیگر قسمت های برنامه نویسی ترکیب می شود تا در نهایت یک محصول نرم افزاری مانند سیستم عامل یا اپپلیکیشن را تشکیل دهند. و دیباگینگ تا انتهال تمام این فرآیندها ادامه دارد.
اشکالات اغلب پس از انتشار یک محصول یا در طول آزمایش عمومی بتا کشف می شوند.
برای حل این مورد کاربران باید راهی برای جلوگیری از استفاده از کد باگ دار پیدا کنند یا یک بسته از توسعه دهندگان نرم افزار دریافت و نصب کنند.
باگ تنها یک نوع مشکل است که یک برنامه می تواند داشته باشد.
برنامه ها می توانند بدون باگ اجرا شوند و همچنان استفاده از آنها مشکل باشد یا در برخی از اهداف اصلی شکست بخورند.
سنجش این نوع ضعف ها سخت تر است.
یک برنامه خوب به گونه ای طراحی شده که با استفاده از یک فرآیند به خوبی کنترل شده، توسعه یافته است و به ازای هزاران خط کد، باگ های کمتری را به همراه دارد.
به همین دلیل مهم است که قابلیت استفاده را در آزمایش لحاظ کنید.
انواع باگ های نرم افزاری
باگ های مختلفی باعث می‌شوند که کامپیوتر‌ها به‌درستی عمل نکنند. تعدادی از باگ های کامپیوتری عبارتند از:
محاسباتی(Arithmetic)
گاهی تحت عنوان خطاهای محاسباتی نامیده می‌شوند، باگهای محاسباتی، خطاهای ریاضی در کدنویسی هستند که منجر به عدم عملکرد آن می‌شوند.
تعامل(Interface)
خطای تعامل وقتی اتفاق می‌افتد که سیستم‌های ناسازگار به کامپیوتر متصل می‌شوند. مشکل میتواند قطعه‌ای از سخت‌افزار یا نرم‌افزار باشد. رابط برنامه نویسی اپلیکیشن میتواند مثالی از باگ تعاملی باشد.
منطق (Logic)
این خطاها وقتی رخ می‌دهند که منطق اسکریپت باعث می‌شود برنامه اطلاعات اشتباهی را خروجی دهد یا گیر کند و خروجی ارائه نکند. مثالی از خطای منطقی حلقه نامتناهی است که در آن یک توالی از کد به صورت مداوم تکرار می شود.
سینتکس (Syntax)
این باگ ها ناشی از برنامه‌ای که با کدهای نادرست نوشته شده اند، است. زبان‌های برنامه‌نویسی مختلف، سینتکس های متفاوتی دارند، بنابراین استفاده از سینتکس از جایی در برنامه دیگر منجر به خطا می‌شود.
کار تیمی (Teamwork)
این خطا از ارتباط نادرست بین برنامه‌نویسان ناشی می‌شود. برای مثال زمانی است که تفاوت‌هایی بین مستندات محصول و خود محصول وجود دارد. مثال دیگر زمانی است که کامنت ها بطورنادرست کد برنامه را شرح می‌دهند.
یکی دیگر از راه های ساده برای دسته بندی باگ ها از دیدگاه کاربر است. انواع این باگ ها شامل :
دیداری(Visual)
کاربر می تواند عملی که انتخاب کرده است را کامل کند. اما چیزی در کاربرد اشتباه به نظر می رسد. این ممکن است مشکلی با طراحی پاسخی برای آن کاربرد باشد.
عملکردی(Functional)
خطای عملکردی به این معنا است که برنامه آن‌طور که در نظر داشتیم کار نمی کند.
برای مثال، کاربر دکمه ذخیره کردن را فشار میدهد اما داده ذخیره نمی شود.
همچنین باگ ها میتوانند براساس درجه سختی ای که برای کاربر ایجاد میکنند دسته بندی شوند :
خطاهای کم اثر
خطاهای کم اثر، حداقل اثر را روی تجربه کاربر دارد.
باگ های پر اثر
این باگ ها بر سطحی از عملکرد اثر میگذارند، اما برنامه هنوز قابل استفاده قابل استفاده است.
باگ های بحرانی
باگ های بحرانی، مانع از عملکرد اصلی برنامه می‌شوند.
رویکرد دیگر برای طبقه بندی باگ این است که ببینیم کجا اتفاق می‌افتند :
باگ های واحدی، باگ های نرم‌افزاری ساده ای هستند که داخل یک واحد از کد قرار دارند.
آنها معمولاً به سبب خطاهای محاسباتی یا منطقی ایجاد می‌شوند و با یک قسمت از نرم‌افزار ارتباط دارند. و معمولاً به راحتی رفع می‌شوند.
باگ های در سطح سیستم خطاهای پیچیده‌تری هستند که توسط قسمت‌های گوناگون نرم‌افزار ایجاد شده اند و به شیوه‌ای عمل میکنند که باعث مشکلات می‌شوند.
خطاهای خارج از محدوده، زمانی رخ می‌دهند که کاربر به شیوه ای غیرمنتظره کارمی‌کند.
برای مثال، این مورد زمانی اتفاق می‌افتد که کاربر پارامتری را در یک فرم وارد می‌کند که برنامه برای کنترل آن طراحی نشده‌است. خطاهای خارج از محدوده میتوانند برای استثمار نرم‌افزار استفاده شوند.
برای مثال، تهدیدکنندگان از آسیب پذیری infra:halt استفاده میکنند تا انجام حملات مسموم کننده حافظه پنهان سیستم نام دامنه را روی فناوری عملیاتی پیاده سازی کنند.
چگونه از به وجود آمدن باگ ها جلوگیری کنیم؟
روش‌های متعددی برای یافتن باگ ها وجود دارد. که به نوع باگ، مکان و زمانی که پیدا می‌شوند بستگی دارد.
فرآیند توسعه
بهترین روش یافتن باگ های برنامه نویسی از طریق پیشگیری است.
استفاده از یک فرآیند توسعه نرم‌افزار سالم مانند متدلوژی های Agile و DevOps میتوانند از وقوع باگ ها جلوگیری کند. آزمایش کیفیت درون این متدلوژی های توسعه تعبیه شده است.
چنین شیوه توسعه ای، توسعه آزمایش‌محور است. آزمایش‌ها باید قبل از اینکه یک ویژگی کدنویسی شود، انجام گیرند تا تا استانداردی برای برنامه نویسی آن ارائه شود.
بهترین روش دیگر استفاده از توسعه مبتنی بر رفتار است که توسعه‌دهندگان را به کدنویسی یک اپلیکیشن و مستندسازی فرآیند براساس تعامل انتظار رفته از کاربر با آن تشویق می‌کند.
تست نرم افزار
آزمایش کردن یا تست کردن، روشی برای کشف باگ ها در نرم‌افزار است. سه نوع آزمایش نرم‌افزاری به شرح زیر می باشد :
1- آزمایش عملکردی شامل آزمایش نمودن قسمت‌های عملکردی مرکزی از یک برنامه به دنبال خطاهای نرم‌افزار است قبل از اینکه به مرحله بعدی آزمایش انتقال یابد.
این بخش از آزمایش تایید می‌کند که همه قسمت‌ها عمل میکنند. آزمایش عملکردی همچنین آزمایش دودی( اصطلاحی عامیانه برای بررسی خرابی برنامه کامپیوتری) نامیده می‌شود.
2- آزمایش اکتشافی شامل روش‌هایی است که مسیرهایی از نرم‌افزار را که کم‌تر رایج است آزمایش می‌کند یا آنهایی که یک آزمایش عملکردی معمولی ممکن است از دست بدهد.
برای مثال، یک نوع آزمایش اکتشافی، آزمایش پوشش است که بررسی می‌کند آیا یک برنامه در دستگاه ها، مرورگرها و یا سیستم عامل‌های مختلف عمل می‌کند یا خیر.
3- آزمایش پس رفت به این منظور طراحی شده‌است تا تغییرات اولیه ای که روی کد انجام گرفته و منجر به مشکل غیرعمدی شده است را تشخیص دهد. آزمایش بازگشتی شامل انواع زیر است :
- آزمایش واحدی (unit testing)
- آزمایش یکپارچگی (integration testing)
- آزمایش سیستمی (system testing)
- آزمایش مقبولیت (acceptance testing)
طراحان و توسعه دهندگان میتوانند از رسیدن باگ ها به کاربران با آزمایش اولیه و مکرر جلوگیری کنند.
حین آزمایش نرم افزاری همکاری با دیگر توسعه دهندگان ، توسه دهنده ارشد یا گروه تضمین کیفیت میتواند مفید باشد.
معیارسنجی
معیارسنجی یا آزمایش معیار، عملکرد استاندارد نرم‌افزار را تحت انواع حجم کاری پیش‌بینی می‌کند. آزمایش‌های معیارسنجی میتوانند ثبات، پاسخگویی، سرعت و کارایی نرم‌افزار را ارزیابی کنند.
خطاهایی که ممکن است تحت مجموعه شرایطی باعث تاخیر شوند، مشکل جدی در شرایط دیگر ایجاد میکنند. آزمایش معیارسنجی میتواند به تشخیص چنین خطاهایی کمک کند.
انواع مختلف معیارسنجی را در ادامه بخوانید :
- معیار سنجی بارگذاری، سیستم‌های نرم‌افزاری را تحت بارگذاری خاصی را ارزیابی می‌کند که اغلب مقدار رایج از انتقال مورد انتظار برای برنامه کاربردی است.
- معیارسنجی افزایش عملکرد، عملکرد نرم‌افزار را با افزایش ناگهانی در حجم کار ارزیابی می‌کند.
- معیارسنجی نقطه انفصال، به قسمتی از نرم‌افزار فشار وارد می‌کند تا بررسی کند که چه میزان استرسی را قبل از خراب شدن میتواند تحمل کند.
چطور باگ‌ها را برطرف کنیم؟
اگر باگی در نرم‌افزار پیدا شود، باید رفع شود. برطرف نمودن باگ شامل سه مرحله زیر است :
- جدا کردن باگ
- تعیین علت اصلی
- رفع مشکل
برای برنامه‌نویسانی که قسمتی از کد را می نویسند سخت است که مراحل را دوباره دنبال کنند و به تمام خطوط پیچیده و متراکم کد برنامه نویسی نگاه کنند.
برنامه‌ای پر از باگ راهی برای برون‌سپاری جهت رفع باگ است.
با برون‌سپاری، به محققان امنیتی نرم‌افزار و هکرهای دارای اخلاق حرفه‌ای برای یافتن مشکلات و فراهم نمودن گزارش‌های مربوط به باگ پاداش داده می‌شود که آسیب‌پذیری را تکرار و سپس برطرف میکنند.
پیشرفت مداوم
سازمان‌ها انتظار دارند با حداقل نمودن باگهای نرم‌افزاری، سطح پیشروی و پس‌روی نرم‌افزاری که منتشر میکنند، متعادل شود.
با این کار، آنها مطمئن می‌شوند که فرآیند دیباگ سر راه برنامه انتشار نرم افزار قرار نمی‌گیرد. سازمان‌هایی که در محیط توسعه Agile کار میکنند، این کار را انجام می‌دهند.
با وجود اینکه بعضی باگ‌ها این کار را برای محصول انتشار یافته، انجام می‌دهند.
تیم‌های توسعه میتوانند انتشاری را به‌عنوان قسمتی از فرآیند رفع باگ انجام دهند درحالی که بازخورد آن را بررسی کرده، به‌سرعت ازبین برده و اصلاحش میکنند.
تیمی یا شخصی در تیم ممکن است برنامه ریزی کند که در زمان مشخصی هر روز، باگهای نرم‌افزار را بیابد.
با این روش، جمع‌آوری دادههای باگ و فرآیند رفع آن قسمتی از برنامه روزانه می‌شود. یک تیم میتواند از داده های فرآیند دیباگ استفاده کند تا زمان رفع باگ ها را محاسبه کند و کارهایشان را برآن اساس نظم دهی کند.
رفع همزمان همه باگ‌ها غیرممکن است و جمع‌آوری دادههای موردنیاز برای ارزیابی دقیق باگ‌ها زمان می‌برد.
سطح مهارت و توانایی برنامه‌نویسان متفاوت است. همچنین ارزیابی‌ها برای رفع باگ ممکن است میان برنامه‌نویسانی که در کشورهای مختلف کار میکنند، متفاوت باشد.
در طول زمان، یک تیم میتواند معیاری را گسترش دهد که تخمین بزند چند باگ را میتواند در یک ماه برطرف کند.
برطرف نمودن باگ هیچ‌گاه بطور کامل انجام نمی‌شود و همیشه باگهای جدید ظاهر می‌شوند.
تیم‌های توسعه باید راه های مؤثری برای یافتن باگ‌ها داشته باشند. و ارزش خالص مثبت را به سرمایه‌گذاران با انتشار هر نرم‌افزار تحویل بدهند.
تاریخچه باگ های نرم افزاری
کلمه باگ از مهندسی نشأت می‌گیرد. استفاده از این اصطلاح در رشته کامپیوتر به برنامه نویس پیشگام (گریس هاپر) نسبت داده می‌شود.
در سال ۱۱۹۴، هاپر، افسر ذخیره نیروی دریایی بود که روی کامپیوتر Mark I در هاروارد کار می‌کرد.
سپس هاپر رویدادی را توصیف کرد که گفته می‌شود در آن یک دستیار مهندس باگ مهمی(moth) را پیدا کرد. که درواقع حاصل دو انتقال الکتریکی در کامپیوتر Mark II بوده است.
نیروی دریایی آن باگ (moth) را سال ها در معرض نمایش قرار داد. اکنون مؤسسه Smithsonian از آن نگهداری می‌کند.
دیگر مثال ها :
مقاله‌ای درباره سیم‌کشی در سال ۲۰۰۵ درباره ۱۰ مورد از بدترین باگهای نرم‌افزاری تاریخ را گزارش کرد.
این باگ ها که باعث انفجارات عمده شده بودند، کاوشگرهای فضایی را از کار انداختند و منجر به کشته شدن مردم شدند.
برای مثال در سال ۱۹۸۲ : سیستمی که توسط آژانس هوش مرکزی تعبیه شده بود و لوله‌کشی گاز به طرف روسیه را کنترل می‌کرد باعث بزرگترین انفجار غیرهسته‌ای در تاریخ شد.
همچنین در این مقاله گفته شده بین سال‌های ۱۹۸۵ و ۱۹۸۷، باگی که race condition نامیده می‌شود، در وسیله پرتودرمانی ایجاد شد هنگامی که دوزهای مخرب پرتو را دریافت می‌کرد، پنج نفر را کشت و به بقیه هم صدمه زد.
Race Condition : حالت نامعینی درعملکرد همزمان دستورالعمل‌های دو کامپیوتر و اینکه کدام ابتدا تمام خواهند شد معلوم نیست
در سال ۲۰۰۵، شرکت Toyota ،۱۶۰۰۰۰ ماشین Priuses را یادآوری می‌کند چون یک خطا باعث شد چراغ‌های هشدار زودتر روشن شوند و موتور بدون دلیل از کار بیفتد.
حادثه عجیب دیگری در ارتباط با باگ در سال ۲۰۱۶ اتفاق افتاد، وقتی ویژگی خودران Tesla به‌درستی عمل نکرد.
در حالی که از بزرگراه عبور می‌کرد تراکتوربزرگ سفیدرنگ را مقابل آسمان روشن تشخیص نداد و با آن ماشین تصادف کرد و منجر به مرگ و میر شد.
بدانید که چطور مکانیزه کردن QA (تضمین کیفیت)، میتواند سرعت آزمایش و برطرف کردن باگ را افزایش دهد.
منبع : سایت techtarget
ممنون از اینکه تا انتهای این مقاله با ما همراه بودید.
نظرات خودتون رو حتما با ما به اشتراک بگذارید.
اسپیکر