السليم البرمجي أوالتشخيص أوعلاج الأخطاء البرمجية أوتسليم الأخطاء هوعملية منهجية لإيجاد وتقليل عدد الخطأ البرمجي، أوالعيوب، في برنامج (حاسوب) أوبترة من عتاد الحاسوب الإلكترونية، وبالتالي، جعلها تعمل بالطريقة المتسقطة منها. ويميل تسليم الأخطاء إلي حتىقد يكون أصعب عندما يتم الربط بين أنظمة فرعية متعددة بشكل كبير، بحيث من الممكن تؤدي التغييرات في أحد الأنظمة إلي ظهور أخطاء برمجية في الآخر. وقد تم تأليف الكثير من الخط حول تسليم الخطأ (انظر بأسفل: لمزيد من القراءة)، وذلك لأنه يضم الكثير من الجوانب، بما في ذلك تسليم الأخطاء التفاعلي، التحكم في التدفق، اختبار الترابط، ملفات تسجيل البيانات، المراقبة (التطبيق، والنظام)[، ]طبع محتوى الذاكرة، تحليل البرنامج، مراقبة العملية الإحصائية، وتكتيكات التصميم الخاص من أجل تحسين الاكتشاف مع تبسيط التغييرات.

الأصل

هناك جدل حول أصل مصطلح " تسليم الخطأ"/التنقيح.

ينسب مصطلحي " خطأ " و" تسليم الخطأ " إلي العميد البحري جريس هوبر في الأربعينات. وبينما كانت تعمل على جهاز حاسوب من موديل النسخة الثانية بجامعة هارفارد، اكتشف زملائها فراشة ملصقة بمحرك مؤازر وبالتالي تعوق التشغيل، ومن ثم علقت بأنهم كانوا " يزيلون الخطأ (الحشرة) " من النظام". ومع هذا، فالمصطلح في معنى الخطأ الفني يرجع إلي عام 1878 على الأقل وتوماس إديسون (انظر أيضا خطأ برمجي للمناقشة الكاملة)، يظهر حتى " تسليم الخطأ " قد تم استخدامه في فهم الطيران قبل دخوله عالم الكمبيوتر. وبالعمل، في لقاءة علقت جريس هوبر أنها لم تكن تبتكر المصطلح. فالفراشة قد ناسبت المصطلح الموجود بالعمل، وبالتالي تم تخزينه.

وتدوين قاموس أوكسفورد الإنجليزي لمصطلح " يصحح الخطأ " ينقل مصطلح " تسليم الخطأ" debugging المستخدم في اختبار محرك الطائرة في منطق عام 1945 بمجلة جمعية الطيران الملكي، ووجد حتى خطأ برمجي bug التي نطقتها هوبر قد وجدت في التاسع من سبتمبر فهم 1947. ولم يستخدم مبرمجوالحاسوب هذا المصطلح حتى أوائل الخمسينات. والموضوع الرائد للعالم Gill في عام 1951 هوالمناقشة المتعمقة الأولى لأخطاء البرمجة، إلا أنه لا يستخدم مصطلح " خطأ برمجي" أو" تسليم الخطأ ". وفي المخطة الرقمية رابطة مكائن الحوسبة، كان الاستخدام الأول لمصطلح " تسليم الخطأ " في ثلاث منطقات من الاجتماعات المحلية لرابطة مكائن الحوسبة. اثنان من الثلاثة يستخدم المصطلح بين قوسين. وفي عام 1963، كان مصطلح " تسليم الخطأ " شائعا بدرجة كافية ليتم ذكره والمرور عليه بدون تفسير على الصفحة رقم 1 من مرشد نظام المشاركة الزمنية المتوافقة CTSS. ومنطق Kidwell " Stalking the Elusive Computer Bug" يناقش أصل مصطلح " bug" و" debug " بتفصيل أكبر.

النطاق

ولأن الأنظمة البرمجية والإلكترونية قد أصبحت معقدة بشكل عام، فقد توسعت أساليب تسليم الخطأ الشائعة مع وجود المزيد من الوسائل لاكتشاف الأخطاء، وتقييم التأثير، ووضع جدول زمني لتصليح الأخطاء في البرامج أوالتحديثات الكاملة للنظام. ويمكن استعمال حدثة شذوذ anomaly أوحدثة تباين discrepancy، على أنهما مصطلحات أكثر حيادية، من أجل تجنب حدثات مثل " خطأ error وعيب defect أو" خطأ خفي bug مع مضمون يقول أنه يجب تثبيت حدثات الأخطاء والعيوب، والأخطاء الخفية (مهما كلف الأمر). وبدلا من ذلك، يمكن عمل تقييم للتأثير[ من أجل تحديد ما إذا كانت التغيرات اللازمة لإزالة الشذوذ (أوالتباين) ستكون مكلفة للنظام، أومن الممكن التحرير الجديد المجدول يجعل التغييرات غير لازمة. وليست جميع القضايا هي ]تتوقف عليها الحياة [ أو] تتوقف عليها المهمة[ في النظام. وكذلك، فمن المهم حتى نتجنب الموقف الذي من الممكنقد يكون فيه التغيير أكثر إزعاجا للمستخدمين، وطويل المدى، أكثر من التعايش مع المشكلات المعروفة (حيث من الممكنقد يكون العلاج أسوأ من السقم). فبناء قرارات تقبل بعض من الأخطاء أوالشذوذ يمكن حتى يتجنب ثقافة أمر " انعدام العيوب "، حيث من الممكن يتم إقناع الأشخاص بإنكار وجود المشكلات لكي تبدوالنتيجة هي انعدام العيوب. وبتناول القضايا المرتبطة، مثل تقييم تأثير التكلفة لقاء المنفعة، فسوف تتوسع أساليب تسليم الأخطاء لكي تحدد تكرار الأخطاء أوالشذوذ (عدد مرات حدوث نفس الأخطاء) من أجل المساعدة في تقييم تأثيرها على النظام العام.

الأدوات

يتفاوت تسليم الخطأ من التعقيد إلي تثبيت أخطاء بسيطة من أجل أداء مهام مطولة ومتعبة لجمع البيانات وتحليلها وتحديثات الجدولة الزمنية. ومهارة المبرمج في تسليم الخطأ يمن حتى تكون عاملا رئيسيا في القدرة على تسليم المشكلة، لكن صعوبة تسليم الخطأ البرمجي تفاوت بدرجة كبيرة مع تعقيد النظام، وكذلك تعتمد إلي حد ما على لغة برمجة المستخدمة والأدوات المتاحة، مثل المصحح. والمصحح هي أدوات برمجية تساعد المبرمج على مراقبة تطبيق البرنامج، أوإيقافه أوإعادة تشغيله، ووضع نقطة الانقطاع وتغيير القيم في الذاكرة. ويمكن لمصطلح مصحح debugger إذا يشير إلي الشخص الذي يقوم بتسليم الخطأ.

وبوجه عام، لغة البرمجة عالية المستوى مثل جافا (لغة برمجة) تجعل تسليم الخطأ أسهل، لأن لها خصائص مثل لغة التعامل مع الاستثناء [exception handling التي تجعل المصادر الحقيقية للسلوك الشاذ سهل الاكتشاف. وفي لغات برمجة مثل سي أولغة تجميع من الممكن تسبب الأخطاء مشكلات صامتة مثل إتلاف الذاكرة، وفي الغالبقد يكون من الصعب رؤية المكان الذي حدثت فيه المشكلة الأولى. وفي تلك الحالات، من الممكن تكون هناك حاجة إلي أدوات مصحح ذاكرة.

وفي مواقف معينة، يمكن لأدوات برمجة الأغراض العامة واليت هي لغات في الأصل حتى تصبح مقيدة جدا. فهذه تتخذ شكل أدوات تحليل الكود الثابت. فتبحث هذه الأدوات عن مجموعة محددة جدا من المشكلات المعروفة، بعضها رائج وبعضها نادر، داخل كود المصدر. وكل تلك القضايا التي يتم اكتشافها عن طريق هذه الأدوات نادرا ما يتم التقاطها من خلال المصنف أوالمفسر، وبالتالي فهي ليست مدقق نحوي syntax checkers، بل هي مدقق معاني semantic checkers. وتزعم بعض الأدوات قدرتها على اكتشاف أكثر من 300 معضلة فريدة. وتوجد جميع من الأدوات التجارية والمجانية في لغات متعددة. ويمكن لهذه الأدوات حتى تكون مفيدة بدرجة كبيرة عند مراجعة أشجار المصدر الضخمة جدا source trees، حيثقد يكون من غير العملي تكويد عملية مراجعة التصميم walkthroughs. والمثال النموذجي لمشكلة تم اكتشافها سيكون إسناد مؤشري متغير والذي يحدث قبل تعيين قيمة للمتغير. ومثال أخر سيكون القيام بمراجعة قوية للنمط عندما لا تستلزم اللغة ذلك. وبالتالي، فهي أفضل في تحديد أماكن الأخطاء المحتملة، لقاء الأخطاء العملية. ونتيجة لهذا، فهذه الأدوات لها شهرة من الايجابيات الزائفة. وبرنامج لغة يونكس lint هي مثال مبكر.

وبالنسبة لتسليم الأخطاء في الأجزاء الخارجية الإلكترونية (مثل عتاد الحاسوب) وكذلك البرامج ذات المستوى المنخفض (مثل بيوس ومشغل (برنامج حاسوبي() وبرنامج ثابت، فيتم استخدام أدوات مثل راسم إشارة والمحللات المنطقية[ أو] محاكي الدوائر الداخلية، سواء على حدة أومعا. وربما يؤدي محاكي الدوائر الداخلية الكثير من مهام تسليم أخطاء برمجية نموذجية في برمجية حاسوب منخفضة المستوى وبرنامج ثابت.

عملية التسليم النموذجي للأخطاء

من الطبيعي حتى تكون المستوى الأولي لتسليم الأخطاء هي محاولة إعادة إنتاج المشكلة. وهذا يمكن حتى تكون مهمة دالة، مثلا فيما يخص المعالجة المتوازية أوبعض من الأخطاء البرمجية غير العادية. وكذلك، فبيئة مستخدم معين وتاريخ الاستعمال يمكن حتى يجعل من الصعب إعادة إنتاج المشكلة.

وبعد إذا تتم إعادة إنتاج الخطأ، من الممكن يحتاج إدخال البرنامج إلي التبسيط لكيقد يكون من السهل تصيح الخطأ. مثلا، خطأ في ملف مؤلف يمكن حتى يجعله ] يتوقف فجأة عند تحليل لغوي لبعض ملفات المصدر الضخمة. ومع هذا، فبعد تبسيط الحالة الاختبارية، فخطوط قليلة فقط من ملف المصدر الأصلي يمكن حتى تكون كافية لإعادة إنتاج نفس التوقف المفاجئ. ويمكن عمل ذلك التبسيط يدويا، باستخدام مدخل Divide and conquer algorithm. وسوف يحاول المبرمج إزالة بعض أجزاء الحالة الاختبارية وفحص ما إذا كانت المشكلة لا تزال موجودة. وعندما تسليم الخطأ في قابلة المستخدم الرسومية، فيمكن للمبرمج حتى يحاول تخطي بعض من تفاعل المستخدم من وصف المشكلة الأصلية وفحص ما إذا كانت الأفعال الباقية كافية لظهور الأخطاء.

وبعد ماقد يكون قد تم تبسيط الحالة الاختبارية بشكل كافي، يمكن للمبرمج استخدام أداة المصحح لفحص حالات البرنامج (قيم المتغيرات، مع call stack) ويتتبع أثر أصل المشكلة أوالمشكلات. وبالمثل، يمكن استعمال ] التتبع[. وفي الحالات البسيطة،قد يكون التتبع تعبير عن بيانات طباعة قليلة، والتي تقوم بإنتاج قيم المتغيرات عند نقاط معينة من تطبيق البرنامج.

الأساليب

• تسليم أخطاء طباعة (أوتتبع) هي القيام بمراقبة (حية أومسجلة) لبيانات التتبع، أوبيانات الطباعة، التي تشير إلي تدفق تنفي العملية.
• التسليم عن بعد هي عملية تسليم خطأ برنامج يعمل على نظام مختلف عن المصحح. ولبدء التسليم عن بعد، يتصل المصحح بنظام عن بعد على شبكة الإنترنت. وبعد الاتصال، يمكن للمصحح حتى يتحكم في تطبيق البرنامج عن بعد واستعادة معلومات عن حالته
• تسليم Post-mortem هوتسليم البرنامج بعد حتى تم توقفه فجأة. والأساليب المرتبطة غالبا ما تضم أساليب متعددة للتتبع (مثلا ,) أوتحليل تفريغ الذاكرة (أوcore dump(للعملية المتوقفة. وإفراغ العملية يمكن حتى يحدث بشكل آلي عن طريق النظام (مثلا، عندما تكون العملية قد توقفت بسبب استثناء لم يتم التعامل معه) أوعن طريق تعليمات يضعها المبرمج، أويدويا عن طريق المستخدم التفاعلي.
• تسليم دلتا Delta Debugging – هوأسلوب تبسيط آلي للحالة الاختبارية.

• Saff Squeeze- هوأسلوب عزل الفشل في الاختبار باستخدام الترابط التقدمي لأجزاء الاختبار الفاشل.

تسليم الأنظمة المدمجة

وعلى عكس بيئة تصميم برامج الحاسوب ذات الغرض العام، فخاصية البيئات المدمجة هي الرقم الكبير للبرامج المتنوعة المتاحة للمطورين (هندسة وحدة المعالجة المركزية، بائعين، نظم التشغيل ومتغيراتها). وتعهد الأنظمة المدمجة بأنها تصميمات ليست للغرض العام: فهي مطورة بشكل نموذجي من أجل مهمة واحدة (أومجموعة من المهام الصغيرة)، ويتم اختيار البرنامج بشكل معين من أجل الاستخدام الأمثل لذلك التطبيق. وهذه الحقيقة لا تجعل الحياة ليست فقط صعبة على مطوري الأنظمة المدمجة، بل أيضا تجعل تسليم واختبار هذه الأنظمة أصعب، لأن هناك حاجة إلي أدوات تسليم مختلفة في برامج مختلفة. لكن ببساطة، فإن مصحح الأنظمة المدمجة لديه مطلبين رئيسيين:.

• تحديد وتسليم الأخطاء في النظام (مثلا، مشكلات منطقية أومشكلات تزامن في الكود، أوخطأ تصميم في الأجزاء الخارجية hardware)
• جمع معلومات عن حالات تشغيل النظام والتي من الممكن يتم استخدامها لتحليل النظام: لإيجاد طرق لدعم أدائه أولتحسين الخصائص الأخرى المهمة (مثلا استهلاك الطاقة، الثبات، الاستجابة زمن حقيقي الخ).

مقاومة تسليم الخطأ

مقاومة تسليم الخطأ هو" تطبيق أسلوب أوأكثر داخل كود الحاسوب والذي يعوق محاولات الهندسة العكسية أوتسليم عملية مستهدفة". ويتم استخدامه بشكل نشط في حماية النسخ القانونية، لكنه أيضا يستخدم عن طريق برمجيات خبيثة لتعقيد اكتشافه والتخلص منه. والأساليب المستخدمة في مقاومة التسليم تضم:

• API-based: فحص وجود مصحح باستخدام معلومات النظام
• قائمة على الاستثناء: فحص لرؤية ما إذا كانت هناك استثناءت متداخلة
• عوائق العميلة والسلك: فحص ما إذا تم استخدام عوائق عملية وسلك
• كود معدل: البحث عن تعديلات للكود عن طريق نقاط توقف في برنامج للتعامل مع المصحح
• قائمة على الأجزاء الخارجية والتسجيل: البحث عن نقاط توقف في الأجزاء الخارجية وتسجيلات وحدة المعالجة المركزية
• التوقيت والكمون: البحث عن الوقت المستغرق في تطبيق التعليمات
• اكتشاف المصحح ومعاقبته.

انظر أيضا

• مصحح
• Magic debug values
• خطأ برمجي
• فحص البرمجيات
• فشل

مراجع

لمزيد من القراءة

• David J. Agans: Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems, AMACOM, 2002. ISBN 0-8144-7168-4
• Bill Blunden: Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code, APress, 2003. ISBN 1-59059-234-4
• Ann R. Ford, Toby J. Teorey: Practical Debugging in C++, Prentice Hall, 2002. ISBN 0-13-065394-2
• Thorsten Grötker, Ulrich Holtmann, Holger Keding, Markus Wloka, The Developer's Guide to Debugging, Springer, 2008. ISBN 1-4020-5539-0
• Robert C. Metzger: Debugging by Thinking: A Multidisciplinary Approach, Digital Press, 2003. ISBN 1-55558-307-5
• Glenford J Myers: *The Art of Software Testing, John Wiley & Sons inc, 2004. ISBN 0-471-04328-1
• John Robbins: Debugging Applications, Microsoft Press, 2000. ISBN 0-7356-0886-5
• Matthew A. Telles, Yuan Hsieh: The Science of Debugging, The Coriolis Group, 2001. ISBN 1-57610-917-8
• Dmitry Vostokov: Memory Dump Analysis Anthology, Volume 1, OpenTask, 2008. ISBN 978-0-9558328-0-2
• Andreas Zeller: Why Programs Fail: A Guide to Systematic Debugging, Morgan Kaufmann, 2005. ISBN 1-55860-866-4
• Artzi, Shay (2008). "Finding bugs in dynamic web applications": 261. doi:10.1145/1390630.1390662.

وصلات خارجية

• Crash dump analysis patterns — In-depth articles on analyzing and finding bugs in crash dumps
• Learn the essentials of debugging — How to improve your debugging skills, a good article at آي بي إم developerWorks.
• Plug-in Based Debugging For Embedded Systems