تصحيح برمجي

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

صورة للخطأ "الأول" بشكل زائف، والذي تم تصحيحه عام 1947.

الأصل

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

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

وتدوين قاموس أوكسفورد الإنجليزي لمصطلح " يصحح الخطأ " ينقل مصطلح " تصحيح الخطأ" debugging المستخدم في اختبار محرك الطائرة في مقال عام 1945 بمجلة جمعية الطيران الملكي، ووجد أن خطأ برمجي bug التي قالتها هوبر قد وجدت في التاسع من سبتمبر علم 1947. ولم يستخدم مبرمجو الحاسوب هذا المصطلح حتى أوائل الخمسينات. والمقال الرائد للعالم Gill[3] في عام 1951 هو المناقشة المتعمقة الأولى لأخطاء البرمجة، إلا أنه لا يستخدم مصطلح " خطأ برمجي" أو " تصحيح الخطأ ". وفي المكتبة الرقمية رابطة مكائن الحوسبة، كان الاستخدام الأول لمصطلح " تصحيح الخطأ " في ثلاث مقالات من الاجتماعات المحلية لرابطة مكائن الحوسبة.[4][5][6] اثنان من الثلاثة يستخدم المصطلح بين قوسين. وفي عام 1963، كان مصطلح " تصحيح الخطأ " شائعا بدرجة كافية ليتم ذكره والمرور عليه بدون تفسير على الصفحة رقم 1 من دليل نظام المشاركة الزمنية المتوافقة CTSS.[7] ومقال Kidwell " Stalking the Elusive Computer Bug"[8] يناقش أصل مصطلح " 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 هو تصحيح البرنامج بعد أن تم توقفه فجأة. والأساليب المرتبطة غالبا ما تشمل أساليب متعددة للتتبع (مثلا ,[9]) أو تحليل تفريغ الذاكرة (أو core dump(للعملية المتوقفة. وإفراغ العملية يمكن أن يحدث بشكل آلي عن طريق النظام (مثلا، عندما تكون العملية قد توقفت بسبب استثناء لم يتم التعامل معه) أو عن طريق تعليمات يضعها المبرمج، أو يدويا عن طريق المستخدم التفاعلي.
  • تصحيح دلتا Delta Debugging – هو أسلوب تبسيط آلي للحالة الاختبارية.[10]:p.123

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

تصحيح الأنظمة المدمجة

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

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

مقاومة تصحيح الخطأ

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

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

انظر أيضا

مراجع
  1. مُعجم الحاسبات النسخة الثانية الموسعة سنة تسعين وتسعمائة وألف جريجورية من معاجم مَجْمَعِ اللغة العربية في القاهرة الصفحة الثامنة والخمسين.
  2. Grace Hopper from FOLDOC نسخة محفوظة 05 مارس 2016 على موقع واي باك مشين.
  3. S. Gill, The Diagnosis of Mistakes in Programmes on the EDSAC, Proceedings of the Royal Society of London. Series A, Mathematical and Physical Sciences, Vol. 206, No. 1087 (May 22, 1951), pp. 538-554 "نسخة مؤرشفة". Archived from the original on 6 مارس 2020. اطلع عليه بتاريخ 16 أبريل 2020. الوسيط |CitationClass= تم تجاهله (مساعدة)صيانة CS1: BOT: original-url status unknown (link)
  4. Robert V. D. Campbell, Evolution of automatic computation, Proceedings of the 1952 ACM national meeting (Pittsburgh), p 29-32, 1952. نسخة محفوظة 17 مارس 2020 على موقع واي باك مشين.
  5. Alex Orden, Solution of متباينة خطية on a digital computer, Proceedings of the 1952 ACM national meeting (Pittsburgh), p. 91-95, 1952. نسخة محفوظة 17 مارس 2020 على موقع واي باك مشين.
  6. Howard B. Demuth, John B. Jackson, Edmund Klein, N. Metropolis, Walter Orvedahl, James H. Richardson, MANIAC, Proceedings of the 1952 ACM national meeting (Toronto), p. 13-16 نسخة محفوظة 17 مارس 2020 على موقع واي باك مشين.
  7. The Compatible Time-Sharing System, M.I.T. Press, 1963 نسخة محفوظة 27 مايو 2012 على موقع واي باك مشين.
  8. Peggy Aldrich Kidwell, Stalking the Elusive Computer Bug, IEEE Annals of the History of Computing, 1998. نسخة محفوظة 06 أكتوبر 2014 على موقع واي باك مشين.
  9. Postmortem Debugging, Stephen Wormuller, Dr. Dobbs Journal, 2006 نسخة محفوظة 27 مايو 2012 على موقع واي باك مشين.
  10. Andreas Zeller: Why Programs Fail: A Guide to Systematic Debugging, Morgan Kaufmann, 2005. ISBN 1-55860-866-4
  11. Kent Beck, Hit 'em High, Hit 'em Low: Regression Testing and the Saff Squeeze نسخة محفوظة 25 مايو 2015 على موقع واي باك مشين.
  12. "Plug-in Based Debugging For Embedded Systems" (PDF). clarinox. مؤرشف من الأصل (PDF) في 10 ديسمبر 2019. اطلع عليه بتاريخ 15 سبتمبر 2010. الوسيط |CitationClass= تم تجاهله (مساعدة)
  13. Shields, Tyler (2008-12-02). "Anti-Debugging Series - Part I". Veracode. مؤرشف من الأصل في 19 أكتوبر 2016. اطلع عليه بتاريخ 17 مارس 2009. الوسيط |CitationClass= تم تجاهله (مساعدة)
  14. Software Protection through Anti-Debugging Michael N Gagnon, Stephen Taylor, Anup Ghosh [وصلة مكسورة] نسخة محفوظة 5 مارس 2012 على موقع واي باك مشين.

    لمزيد من القراءة
    • 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. الوسيط |CitationClass= تم تجاهله (مساعدة); Cite journal requires |journal= (مساعدة)

    وصلات خارجية
    • بوابة برمجة الحاسوب
    This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.