مفاهیم اعلان اشکال bug reporting و معرفی چند سیستم مربوط

از آنجا که نرم افزارهای آزاد متن باز نسبت به نمونه های تجاری و اختصاصی, بسیار سریع تر, به روز می شوند و این به روزرسانی را افراد علاقه مند و برنامه نویسان مختلفی در سراسر دنیا انجام می دهند, از اینرو اکثر نگارش های این برنامه ها اشکالهایی دارند این اشکالها باید به طریقی اعلان شوند

● مقدمه

از آنجا که نرم‌افزارهای آزاد/متن‌باز نسبت به نمونه‌های تجاری و اختصاصی، بسیار سریع‌تر، به‌روز می‌شوند و این به‌روزرسانی را افراد علاقه‌مند و برنامه‌نویسان مختلفی در سراسر دنیا انجام می‌دهند، از اینرو اکثر نگارش‌های این برنامه‌ها اشکالهایی دارند. این اشکالها باید به طریقی اعلان شوند تا در نگارشهای بعدی تا حد ممکن برطرف شوند. سیستم‌های اعلان اشکال به همین منظور ایجاد شده‌اند.

کلمه‌ی Bug در لغت به معنی حشره، و معمولاً منظور یک حشره‌ی مزاحم، می‌باشد. در سیستمهای کامپیوتری و نرم‌افزارها، Bug به هرگونه خطا و اشکالی که در طول کار با برنامه رخ دهد، گفته می‌شود. موضوع نسبتاً ناخوشایند، اما واقعی که وجود دارد این است که همه‌ی نرم‌افزارها bug دارند. هنگامی‌که حجم پروژه زیاد شود، نگه‌داشتن اشکالها بسیار پیچیده خواهد شد. بنابراین راهی برای کنترل و مدیریت این اشکالها نیاز خواهد بود. راه معمول استفاده از سیستم‌های ردیابی اشکال می‌باشد. این سیستمها به افراد و گروههای تولیدکننده‌ی نرم‌افزار امکان کنترل و مدیریت اشکالهای یک سیستم را می‌دهد.

● راهنمای نوشتن "اعلان اشکال"[۱]

برای نوشتن ‌یک اعلان اشکال همواره باید سه اصل پایه را به خاطر داشت:

۱) چه کاری انجام شده است؟

۲) چه نتیجه‌ای انتظار می‌رود؟

۳) واقعاً چه نتیجه‌ای دریافت شده است؟

این سؤالات عناصر اصلی یک اعلان اشکال را تشکیل می‌دهند. حال چطور باید یک اعلان اشکال مفید و کاربردی نوشت؟ اعلان اشکالی مفید است که در نهایت منجر به رفع اشکال شود. این گزارشها معمولاً دو ویژگی دارند:

▪ قابل تولید مجدد[۲]: اگر یک مهندس نتواند از روی گزارش موجود، وجود یک اشکال را ثابت کند، به آن علامت Invalid می‌زند، ازآن گذشته و سراغ اشکال بعدی می‌رود. از این رو هرگونه جزییاتی که امکان دارد، باید در گزارش اشکال فراهم شود.

▪ مشخص[۳]: یک مهندس، در یک ناحیه و فضای مشخص، خیلی سریعتر می‌تواند یک اشکال را از بقیه مجزا کرده و بر حسب نیاز آنرا رفع نماید. پس برنامه‌نویس یا آزمونگر را نباید مجبور به کشف و شناخت اشکال نمود.

برای روشن‌تر شدن موضوع، نحوه‌ی اعلان اشکال را در bugzilla بررسی می‌کنیم:

پیش از اینکه گزارش اشکال وارد شود، ابتدا باید به صفحه‌ی جستجو رفت و مطمین شد که اشکال مورد نظر، قبلاً گزارش نشده باشد. در این صورت اگر کاربر به اشکال جدیدی، حین کار با محصولات جدید برخورد کرد، می‌تواند آنرا به صورت زیر به bugzilla گزارش دهد:

۱) از صفحه‌ی اصلی bugzilla، گزینه‌ی "Enter a new bug" انتخاب شود.

۲) محصولی که اشکال در آن پیدا شده، انتخاب شود.

۳) آدرس email و رمز عبور باید وارد شوند و دکمه login فشار داده شود. اگر کاربر هنوز رمز عبور ندارد، این فیلد را باید خالی بگذارد. در عوض دکمه "Email me a password" را فشار داده، فوراً یک پیغام با رمز عبور دریافت خواهد کرد. اکنون می‌تواند فرم را پر کند.

فیلدهایی باید پر شوند:

● اشکال کار کجا پیدا شده است؟

▪ محصول[۴]: در کدام محصول، اشکال کشف شده است؟ اندکی پیش این مورد، در بالا، مشخص شد و در اینجا نمی‌توان آنرا ویرایش کرد.

▪ نگارش[۵]: در کدام نگارش قابل اجرای محصول، اشکال پیدا شده است؟

▪ مؤلفه[۶]: اشکال در کدام مؤلفه وجود دارد؟ bugzilla نیاز به دانستن این مؤلفه دارد. اگر کاربر مطمین نیست کدام را انتخاب کند، روی مؤلفه کلیک کند، توصیفی از هر مؤلفه خواهد دید که برای انتخاب بهتر به او کمک خواهد کرد.

▪ سیستم عامل[۷]: در کدام سیستم عامل این اشکال پیدا شده است؟ (Linux، Win۲۰۰۰،Mac OS۹.). اگر کاربرمطمین است که اشکال در تمام سیستم عاملها رخ می‌دهد، باید گزینه ۰۳۹;all۰۳۹; را انتخاب کند. در غیر اینصورت، سیستم عاملی که اشکال در آن پیدا نموده انتخاب کرده، اگر در لیست وجود ندارد گزینه "other" را انتخاب کند.

● اهمیت اشکال چقدر است؟

▪ شدت یا سختی[۸]: این فیلد قابلیت میزان خرابی و خسارت رساندن اشکال به برنامه مورد نظر را مشخص می‌کند. این گزینه به طور پیش‌فرض ۰۳۹;normal۰۳۹; است. اگر کاربر در مورد شدت این خسارت مطمین نیست، روی لینک severity کلیک کرده، توصیفی از میزان شدت هر اشکال خواهد دید.

چه کسی عهده‌دار پیگیری اشکال خواهد بود؟

▪ محول کردن به[۹]: کدام مهندس باید، مسؤول رفع این اشکال باشد؟ Bugzillaبه طور خودکار bug را به محض اعلان به یک مهندس پیش‌فرض محول خواهد نمود. اگر کاربر ترجیح می‌دهد که مستقیماً اشکال را به شخص دیگری محول کند، باید آدرس mailاش را دراین فیلد وارد کند. برای دیدن فهرست مهندسین پیش‌فرض برای هر مؤلفه، می‌توان روی لینک مولفه کلیک کرد.

▪ Cc: چه شخص دیگری باید email را دریافت کند؟ آدرسemail تمامی افرادی که باید به محض هرگونه تغییری دراشکال، emailی دریافت کنند، دراینجا فهرست می‌شود. Emailهای بسیار زیادی می‌توان وارد کرد که باید با فاصله یا کاما از هم جدا شوند.

▪ خلاصه[۱۰]: اشکال باید در این قسمت، تقریباً در ۶۰ کاراکتر یا کمتر توصیف شود. این خلاصه باید کامل، جامع و منحصر بفرد باشد و مهندس بتواند با مروری اجمالی روی اشکالهای مختلف، اشکال جدید را تشخیص دهد.

▪ توصیفات[۱۱]: در این فیلد باید یک گزارش جزء‌به‌جزء و تفصیلی از مسأله ارایه شود. در این قسمت، در مقایسه با قسمت خلاصه، توصیفات و جزییات بیشتری از اشکال نیاز است.

خلاصه، هرگونه اطلاعاتی که برای اشکال‌زدایی و برطرف شدن اشکال لازم است، باید ثبت شود. سپس روی ۰۳۹;commit۰۳۹; کلیک کرده، در نهایت گزارش اعلان کاربر، در پایگاه داده‌ی Bugzilla خواهد بود.

ساختار گزارش باید صریح و روشن باشد تا گزارش به راحتی توسط دیگران قابل استفاده باشد. کاربران اغلب نیاز به دسترسی فوری به بخشهای خاصی از اعلان اشکال دارند. از اینرو یک خلاصه‌ی جامع و یک ساختار گزارش مناسب، کمک مؤثری به این کاربران می‌کند. اگر به کار بردن جذابیتها در گزارش هزینه دارد باید از گنجاندن آنها اجتناب کرد.

در هر گزارش فقط یک اشکال عنوان شود. اگر دو اشکال ارتباط خاصی با هم ندارند، باید اعلان‌اشکالهای جداگانه‌ای برای هریک ایجاد شود. این موضوع، به افراد مختلف در مواجهه با اشکالهای متفاوت کمک می‌کند. همچنین اولویت‌بندی اشکالها برحسب اهمیت آنها، از این طریق امکان‌پذیر خواهد بود. کاربر باید هرگونه اشکال جزیی و کم‌اهمیت را جدی بگیرد. مشکلات نرم‌افزاری جدی، خود را می‌توانند به طرق ظاهراً جزیی نشان دهند. به هر جهت باید ثبت شوند.

عناوین مناسبی برای اشکال انتخاب شود. همچنین خلاصه‌ی خوبی تهیه شود. چون افراد معمولاً روی عناوین یا خلاصه‌ اشکالها، جسنجوی خود را انجام می‌دهند. از اینرو کلمات کلیدی مناسبی باید به‌کار برده شود.

● اعلان اشکال درMySQL

مکان معمول برای اعلان اشکالها، آدرس http://bugs.mysql.com/ است، که پایگاه‌داده‌ی اشکالهای کاربران را اداره می‌کند. این پایگاه‌داده عمومی بوده و هر کسی امکان جستجو در آن را دارد. هر فردی که در سیستم خود login نماید، قادر به وارد کردن یک گزارش جدید خواهد بود.

Mysqlbug را در نسخه‌ی Source، در شاخه‌ی Scripts و در نسخه‌ی binary، در شاخه‌ی bin می‌توان پیدا کرد. قبل از فرستادن گزارش، ابتدا باید آنرا با استفاده از آخرین محصول یا نگارش تولید شده‌ی کارگزار mysql تست کرد. همه‌ی اشکالهایی که به پایگاه داده‌ی اشکالهای MySQL فرستاده می‌شوند، در نگارش بعدی MySQL تصحیح و یا مستند خواهند شد.

محصولات MySQL کاربران زیادی دارد. پس احتمال زیادی وجود دارد که مسأله‌ای که به تازگی کشف شده، قبلاً توسط شخص دیگری کشف شده باشد. اگر کمی زمان صرف اطمینان از عدم تکراری بودن اشکال شود و در نهایت بایگانی شود، مسؤولیت فردی که در برطرف کردن اشکالها کمک می‌کند، کمتر خواهد شد. اگر کاربر نمی‌داند، نباید یک پیغام خطا را به عنوان یک bug گزارش دهد. منابع زیادی برای کمک در این زمینه وجود دارد. (مثال: http://www.mysql.com/support)

MySQL و مجموعه‌ی تولیدکنندگانش، گروهی بزرگ را در نقاط مختلف جهان تشکیل می‌دهند که هر کدام زبان خاص خود را دارند. برای یکپارچگی بیشتر از زبان انگلیسی برای اعلان اشکال استفاده می‌شود. هنگام فرستادن یک اشکال حتماً نوع سیستم عامل و نگارش مورد استفاده قید شود. بدون دانستن این دو مورد برطرف کردن اشکال غیر ممکن است. در ضمن هر اشکالی که در کامپایلر پیدا می‌شود، فوراً تصور نشود که مربوط به MySQL است. برای اینکه مشخص شود مشکل مربوط به کامپایلر است یا نه، باید کامپایلر مورد استفاده را ذکر کرد. اگر برنامه‌ای پیغام خطایی ایجاد کرد، حتماً متن کامل و دقیق پیغام درگزارش باید ذکر شود. سازنده و مدل ماشینی که برنامه روی آن تست شده، نام سیستم‌عامل و نگارش آن، و همچنین نگارش MySQL در گزارش قید شود. نگارش را با اجرای MySQL admin version می‌توان فهمید. MySQL admin در شاخه‌‌‌ی ‘bin’ قرر دارد. اگر با سیستم‌عامل ویندوز کار می‌شود، نگارش سیستم را با دو بار کلیک روی My computer و رفتن به منوی help/About windows و اگر با سیستم‌های مشابه Unix کار می‌شود، این اطلاعات با اجرای دستور uname –a پیدا خواهند شد. برخی اوقات مشکل به مقدار حافظه (مجازی یا حقیقی) نیز بستگی دارد. اگر کاربر در این مورد نیز شک دارد، در گزارش خود باید ذکر نماید. اگر از نسخه‌ی Source نرم‌افزار MySQL استفاده می‌شود، نام و نگارش کامپایلر و اگر از نسخه‌ی binary استفاده می‌شود، نام نسخه در گزارش مورد نیاز است.

● نکاتی در مورد اعلان اشکال در Apple

برای واردشدن به سیستم اعلان اشکال apple باید عضو مجموعه‌ی تولیدکنندگان درآدرس http://developer.apple.com/ بود. در سیستم اعلان apple، java script باید فعال باشد و cookieها نیز پذیرفته شوند. Apple در این گزارش از یک رمزگذاری ۱۲۸ بیتی استفاده می‌کند. از اینرو باید دید که جستجوگر این ویژگی را پشتیبانی می‌کند یا نه؟ زمان Idle برای قطع ارتباط با سیستم‌های اعلان اشکال ۶۰ دقیقه است.

● اعلان اشکال در Debian

تمامی اصول نگارش یک اعلان اشکال که قبلاً گفته شد در اینجا نیز باید رعایت شوند. در Debian اعلان اشکالها را می‌توان با استفاده از یک ابزار خودکار فرستاد. برنامه‌ی report bug به بایگانی و ثبت اشکالها و راهنمایی کاربر در تمامی مراحل فرآیند اعلان اشکال، سهولت می‌بخشد. ابزار querybts، موجود در پکیج ذکر شده در آدرس http://packages.debian.org/stable/utils/reportbug، یک واسط مبتنی بر متن برای سیستم‌های ردیابی اشکال[۱۲] فراهم می‌آورد. Debian یک سیستم مبتنی بر email است و یک مولد گزارش مبتنی بر وب دارد. کاربران emacs نیز می‌توانند از دستور debian-bug که بوسیله پکیج debugs-el آماده شده است، استفاده کنند.

▪ فرستادن اعلان اشکال از طریق email

Email را باید به آدرس [e-mail] به شرطی که گفته می‌شود، فرستاد. مشابه هر emailی، email کاربر باید شامل یک خط موضوع[۱۳] واضح و توصیفی در سرآیند mail باشد. موضوعی که ذکر می‌شود، بجای عنوان اشکال اصلی در سیستم ردیابی استفاده می‌شود، از اینرو باید حاوی اطلاعات مفیدی باشد. در بدنه پیغام باید یک شبه‌سرآیند[۱۴] گنجانده شود. به این معنی که اولین خط بدنه پیغام باید به این صورت باشد:

Package : <Something>

<something> با نام پکیجی که حاوی اشکال است، باید جایگزین شود. در دومین خط پیغام:

version : <something>

<something> با نگارش پکیج جایگزین خواهد شد. سطوح سختی[۱۵] اشکالها را، همچنان که گزارش می‌شوند، می‌توان تنظیم کرد. این کار ضرورت ندارد. چون به‌هر حال، تولیدکنندگان، در صورت عدم تنظیم از ناحیه کاربر‌، یک سطح سختی برای گزارش، اختصاص خواهند داد. برای نسبت دادن سطح سختی، دستور زیر باید در شبه‌سرآیند درج شود:

Severity : <severity>

<severity> با یکی از سطوح موجود جایگزین می‌شود. اطلاعات بیشتر در مورد سطوح سختی را می‌توان در آدرس http://www.debian.org/bugs/developer#severities پیدا نمود.

همچنانکه گزارش اشکال تنظیم می‌شود، می‌توان یک برچسب[۱۶] نیز به آن اختصاص داد. هر چند این مورد نیز مشابه severity ضروت ندارد. از دستور زیر برای نسبت دادن برچسب استفاده می‌شود:

Tags : <tags>

برای اطلاعات بیشتر به سایت http://www.debian.org/bugs/developer#tags می‌توان رجوع کرد.

▪ تأییدیه‌ها[۱۷]

معمولاً هنگامی‌که اشکال جدیدی گزارش می‌شود یا اطلاعات اضافی برای یک اشکال موجود پیشنهاد می‌شود، سیستم ردیاب خطا، از طریق email یک ack برمی‌گرداند. اگر کاربر نمی‌خواهد این ack را دریافت کند، در email خود باید سرآیند X-Debbugs-No-Ack را بگنجاند. اگر یک اشکال به این طریق گزارش شود کاربر، خودش، باید واسط وب را برای پیداکردن شماره‌ی اشکال چک کند. هر اعلان اشکالی، ۲۸ روز بعد از آخرین پیغام مرتبط با آن بایگانی می‌شود؛ و بعد از آن صرفاً امکان دیدن و نه تغییر آن وجود دارد. آرشیو اعلان اشکالها را در سایت debian می‌توان با انتخاب “archived bugs‿ دید.

● GNATS

GNATS مجموعه ابزارهایی برای ردیابی اعلان اشکالها، از طریق کاربران در یک سایت مرکزی، می‌باشد که توسط کمپانی GNU[۱۸] کنترل و پشتیبانی می‌شود. این نرم‌افزار مدیریت گزارشهای مشکلات موجود و ایجادشده و نیز ارتباط با کاربران را از طریق ابزارهای گوناگون ممکن می‌سازد. ابزارهای GNATS، تمام اطلاعات گزارشهای یک مسأله را در پایگاه‌داده‌ی خود ذخیره نموده و ابزارهایی برای پرس و جو، ویرایش کردن و نگهداری پایگاه‌داده فراهم می‌آورد.

GNATS محدود به یک واسط کاربری نیست. بلکه از طریق خط فرمان EmailEmacs یا یک daemon شبکه نیز می‌تواند استفاده شود. این واقعیت که تمامی پایگاه‌داده‌ها و پیکربندیها در GNATS را می‌توان در فایلهای متن ساده‌ای ذخیره کرد، امکان کاربردهای ساده و قابلیت انعطاف‌پذیری فوق‌العاده‌ای را برای کاربران فراهم می‌آورد. اگر GNATS تمام ابزارهای مورد نیاز را نداشته باشد، می‌توان با استفاده از ابزارهای استاندارد GNU، نیازها را برطرف نمود.

کارگزار GNATS روی Unix اجرا می‌شود. Clientها می‌توانند با استفاده از یک واسط وب، روی مجموعه‌ی بزرگی از بستر[۱۹]ها، اجرا شوند.

GNATS قابلیتهایی دارد. کار با آن راحت است. ابزارهای مختلفی دارد که برای کارهای گوناگون استفاده می‌شود. این برنامه تفریباً تمامی قابلیتهای خوب GNU را به ارث برده است؛ قابل توسعه و انعطاف‌پذیر است؛ دسترسی‌ها به آن از طریق mail و وب راحت و ساده است؛ نرم‌افزارهای freebsd و Apache نیز از GNATS استفاده می‌کنند

[۱] Bug report

[۲] Reproducible

[۳] Specific

[۴] Product

[۵] Version

[۶] Component

[۷] OS:Operating system

[۸] Severity

[۹] Assign to

[۱۰] Summary

[۱۱] Description

[۱۲] BTS

[۱۳] Subject

[۱۴] Pseudo header

[۱۵] Severity

[۱۶] Tag

[۱۷] Acknowledgments

[۱۸] http://www.gnu.org/software/gnats

[۱۹] Platform

منابع:

http://testingfaqs.org/t-track.html#GNATS

http://bugs.gentoo.org/query.cgi?GoAheadAndLogIn=۱

http://www.debian.org/

http://www.mysql.com/

http://www.apple.com/

http://www.mozilla.org/quality/bug-writing-guidelines.html

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

https://bugs.eclipse.org/bugs/bugwritinghelp.html

http://www.itcdevelopment.org/bugzilla/bugwritinghelp.html

ترجمه: زهرا احمدی

Email: [e-mail]