خطأ في البرنامج

📅 آخر تحديث: ٢٧ يوليو ٢٠٢٦
✍️ نُشر في: ٢٧ يوليو ٢٠٢٦
📷 يحتوي على 5 صور
الموسوعة الحرة

جزء من سلسلة عن
تطوير البرمجيات
الأنشطة الأساسية
النماذج والأنماط
المنهجيات والأطر
دعم التخصصات
الممارسات
أدوات
المعايير وهيئات المعرفة
القواميس
الخطوط العريضة
  • ف
  • ت
  • هـ

خطأ برمجي هو خطأ في برنامج الكمبيوتر .

يمكن وصف برنامج الكمبيوتر الذي يحتوي على العديد من الأخطاء الخطيرة بأنه مليء بالأخطاء .

تتراوح تأثيرات خطأ البرنامج من تأثيرات بسيطة (مثل كلمة مكتوبة بشكل خاطئ في واجهة المستخدم ) إلى تأثيرات شديدة (مثل التعطل المتكرر ).

ارتبطت أخطاء البرامج بالكوارث. كانت أخطاء البرامج في جهاز العلاج الإشعاعي Therac-25 مسؤولة بشكل مباشر عن وفيات المرضى في الثمانينيات. في عام 1996، تم تدمير النموذج الأولي لصاروخ Ariane 5 التابع لوكالة الفضاء الأوروبية والذي تبلغ تكلفته مليار دولار أمريكي بعد أقل من دقيقة من الإطلاق بسبب خطأ في برنامج الكمبيوتر الإرشادي الموجود على متن الطائرة. [1] في عام 1994، تحطمت مروحية شينوك التابعة لسلاح الجو الملكي البريطاني ، مما أسفر عن مقتل 29 شخصًا؛ تم إلقاء اللوم في البداية على خطأ الطيار، ولكن يُعتقد لاحقًا أنه كان بسبب خطأ في البرنامج في كمبيوتر التحكم في المحرك . [2] تسببت البرامج المعيبة في فضيحة مكتب البريد البريطاني في أوائل القرن الحادي والعشرين . [3]

في عام 2002، خلصت دراسة بتكليف من المعهد الوطني للمعايير والتكنولوجيا التابع لوزارة التجارة الأمريكية إلى أن "أخطاء البرمجيات منتشرة للغاية وضارة للغاية لدرجة أنها تكلف الاقتصاد الأمريكي ما يقدر بنحو 59 مليار دولار سنويًا، أو حوالي 0.6 في المائة من الناتج المحلي الإجمالي". [4]

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

تاريخ

مصطلحات

يشير تحول الخطأ (من الكلمة اليونانية meta = "تغيير"، morph = "شكل") إلى تطور عيب في المرحلة النهائية من نشر البرنامج. وقد أطلق على تحول "خطأ" ارتكبه محلل في المراحل المبكرة من دورة حياة تطوير البرنامج، والذي يؤدي إلى "عيب" في المرحلة النهائية من الدورة، اسم "تحول الخطأ". [5]

يمكن وصف المراحل المختلفة للخطأ في دورة التطوير على أنها خطأ، [6] : 31  شذوذ، [6] : 10  عيب، [6] : 31  فشل، [6] : 31  خطأ، [6] : 31  استثناء، [6] : 31  تعطل، [6] : 22  خلل، خطأ، [6] : 14  عيب، حادث، [6] : 39  أو تأثير جانبي.

الجدل

في بعض الأحيان يكون استخدام كلمة bug لوصف سلوك البرنامج مثيرًا للجدل بسبب الإدراك. يقترح البعض التخلي عن المصطلح واستبداله بكلمة عيب أو خطأ .

يزعم البعض أن كلمة "bug" تعني أن العيب نشأ من تلقاء نفسه ويدفعون إلى استخدام كلمة "devil" بدلاً من ذلك لأنها تشير بشكل أكثر وضوحًا إلى سبب بشري. [7]

يزعم البعض أن الخلل قد يُستخدم للتغطية على قرار تصميم متعمد. في عام 2011، بعد تلقي التدقيق من السيناتور الأمريكي آل فرانكن لتسجيل وتخزين مواقع المستخدمين في ملفات غير مشفرة، [8] وصفت شركة Apple هذا السلوك بأنه خلل. ومع ذلك، تحدى جاستن بروكمان من مركز الديمقراطية والتكنولوجيا هذا التصوير بشكل مباشر، قائلاً "أنا سعيد لأنهم يصلحون ما يسمونه خللًا، لكنني أعترض على إنكارهم القوي لتتبع المستخدمين". [9]

وقاية

خطأ ناتج عن خلل في البرنامج يظهر على شاشتين في محطة لا كروا دي بيرني في فرنسا

يعد منع الأخطاء في أقرب وقت ممكن في عملية تطوير البرمجيات هدفًا للاستثمار والابتكار. [10] [11]

دعم اللغة

تميل لغات البرمجة الأحدث إلى أن تكون مصممة لمنع الأخطاء الشائعة بناءً على نقاط الضعف في اللغات الحالية. تُستخدم الدروس المستفادة من اللغات القديمة مثل BASIC و C لتوجيه تصميم اللغات اللاحقة مثل C# و Rust .

قد تتضمن اللغات ميزات مثل نظام النوع الثابت ، ومساحات الأسماء المقيدة ، والبرمجة المعيارية . على سبيل المثال، بالنسبة للغة مكتوبة ومترجمة (مثل C ): 

تعويم رقم = "3"؛

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

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

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

تسمح اللغة المترجمة باكتشاف بعض الأخطاء المطبعية (مثل معرف مكتوب بشكل خاطئ) قبل وقت التشغيل، وهو وقت مبكر في عملية تطوير البرمجيات مقارنة باللغة المفسرة .

التقنيات

تهدف تقنيات البرمجة مثل أسلوب البرمجة والبرمجة الدفاعية إلى منع الأخطاء المطبعية.

على سبيل المثال، قد يكون سبب الخطأ خطأ مطبعيًا بسيطًا نسبيًا في الكود. على سبيل المثال، ينفذ هذا الكود الوظيفة fooفقط إذا conditionكانت صحيحة. 

إذا (شرط) foo();

لكن هذا الكود ينفذ دائمًا foo: 

إذا (شرط)؛ foo();

إن الاتفاقية التي تميل إلى منع هذه المشكلة على وجه الخصوص هي طلب الأقواس للكتلة حتى لو كانت تحتوي على سطر واحد فقط. 

إذا (شرط) {
  فو();
}

قد يتم تنفيذ الاتفاقيات يدويًا (أي عبر مراجعة الكود ) أو عبر أدوات آلية.

مواصفة

يزعم البعض أن كتابة مواصفات البرنامج التي تحدد سلوك البرنامج، يمكن أن تمنع الأخطاء.

يزعم البعض أن المواصفات الرسمية غير عملية لأي شيء سوى البرامج الأقصر، بسبب مشاكل الانفجار التركيبي وعدم التحديد .

اختبار البرمجيات

أحد أهداف اختبار البرمجيات هو العثور على الأخطاء.

يمكن أن توفر القياسات أثناء الاختبار تقديرًا لعدد الأخطاء المحتملة المتبقية. يصبح هذا أكثر موثوقية كلما طالت مدة اختبار المنتج وتطويره. [ بحاجة لمصدر ]

الممارسات الرشيقة

قد يتضمن تطوير البرامج بطريقة Agile إصدارات متكررة للبرامج مع تغييرات صغيرة نسبيًا. يتم الكشف عن العيوب من خلال تعليقات المستخدمين.

في التطوير الموجه بالاختبار (TDD)، تتم كتابة اختبارات الوحدة أثناء كتابة كود الإنتاج، ولا يُعتبر كود الإنتاج مكتملًا حتى تكتمل جميع الاختبارات بنجاح.

التحليل الثابت

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

الأجهزة

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

المصدر المفتوح

يسمح تطوير المصدر المفتوح لأي شخص بفحص الكود المصدر. تقول مدرسة فكرية روج لها إريك س. رايموند باسم قانون لينوس أن البرامج مفتوحة المصدر الشائعة لديها فرصة أكبر لوجود عدد قليل من الأخطاء أو عدم وجودها مقارنة بالبرامج الأخرى، لأنه "إذا نظرنا إليها بشكل كافٍ، فإن جميع الأخطاء سطحية". [12] ومع ذلك، فقد تم التشكيك في هذا التأكيد: كتب أخصائي أمن الكمبيوتر إلياس ليفي أنه "من السهل إخفاء الثغرات الأمنية في الكود المصدري المعقد وغير المفهوم وغير الموثق"، لأنه "حتى إذا كان الأشخاص يراجعون الكود، فهذا لا يعني أنهم مؤهلون للقيام بذلك". [13] ومن الأمثلة على خطأ البرامج مفتوحة المصدر ثغرة OpenSSL لعام 2008 في دبيان .

تصحيح الأخطاء

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

يمكن لبرنامج يُعرف باسم مصحح الأخطاء أن يساعد المبرمج في العثور على الكود الخاطئ من خلال فحص العمليات الداخلية للبرنامج مثل تنفيذ الكود سطرًا بسطر وعرض قيم المتغيرات.

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

يزعم البعض أن تحديد موقع الخطأ يعد نوعًا من الفن.

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

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

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

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

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

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

منذ تسعينيات القرن العشرين، وخاصة بعد كارثة رحلة أريان 5 رقم 501 ، ارتفع الاهتمام بالمساعدات الآلية لتصحيح الأخطاء، مثل تحليل الكود الثابت عن طريق التفسير المجرد . [15]

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

في النظام المضمن ، يتم تعديل البرنامج غالبًا للتغلب على خطأ في الأجهزة نظرًا لأنه أرخص من تعديل الأجهزة.

إدارة

مثال لتاريخ الأخطاء ( بيانات مشروع GNU Classpath ). في البداية، لا يتم تأكيد الخطأ الجديد . بمجرد تأكيد إمكانية إعادة إنتاجه، يتم تغييره إلى مؤكد . بمجرد حل المشكلة، يتم تغييره إلى ثابت .

يتم إدارة الأخطاء من خلال أنشطة مثل التوثيق والتصنيف والتعيين وإعادة إنتاج وتصحيح وإصدار الكود المصحح.

غالبًا ما تُستخدم الأدوات لتتبع الأخطاء والمشكلات الأخرى المتعلقة بالبرمجيات. عادةً، يستخدم فريق تطوير البرمجيات أدوات مختلفة لتتبع عبء العمل الخاص بهم مقارنة بخدمة العملاء لتتبع تعليقات المستخدمين . [16]

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

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

خطورة

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

يُطلق على الخلل الخطير الذي قد يؤدي إلى تأخير إصدار المنتج اسم " الخلل الذي يعيق إطلاق المنتج" . [21] [22]

أولوية

تصف الأولوية أهمية حل الخطأ فيما يتعلق بالأخطاء الأخرى. قد تكون الأولويات رقمية، مثل 1 إلى 5، أو مسماة، مثل حرجة وعالية ومنخفضة ومؤجلة . قد تكون القيم مماثلة أو متطابقة مع تصنيفات الخطورة، على الرغم من أن الأولوية هي جانب مختلف .

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

رقعة

قد تستحق الأخطاء ذات الأولوية العالية إصدارًا خاصًا يُطلق عليه أحيانًا اسم التصحيح .

إصدار الصيانة

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

مشكلة معروفة

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

  • يجب الالتزام بالموعد النهائي والموارد غير كافية لإصلاح جميع الأخطاء بحلول الموعد النهائي [23]
  • تم إصلاح الخلل بالفعل في إصدار قادم، وهو ليس ذا أولوية عالية
  • التغييرات المطلوبة لإصلاح الخطأ مكلفة للغاية أو تؤثر على العديد من المكونات الأخرى، مما يتطلب نشاط اختبار رئيسيًا
  • قد يكون من المشكوك فيه أو من المعروف أن بعض المستخدمين يعتمدون على السلوك الخاطئ الحالي؛ وقد يؤدي الإصلاح المقترح إلى إدخال تغيير جذري
  • تكمن المشكلة في منطقة ستصبح قديمة مع إصدار قادم؛ ولا داعي لإصلاحها
  • "إنها ليست خطأ، بل هي ميزة" [24] يوجد سوء فهم بين السلوك المتوقع والسلوك الفعلي أو الميزة غير الموثقة

تداعيات

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

بصرف النظر عن الضرر الناجم عن الأخطاء، فإن بعض تكلفتها ترجع إلى الجهد المبذول في إصلاحها. في عام 1978، أظهر ليينتز وآخرون أن متوسط ​​المشاريع يستثمر 17 في المائة من جهد التطوير في إصلاح الأخطاء. [25] في عام 2020، أظهر البحث على مستودعات GitHub أن المتوسط ​​هو 20٪. [26]

يكلف

في عام 1994، تمكن مركز جودارد لرحلات الفضاء التابع لوكالة ناسا من تقليل متوسط ​​عدد الأخطاء من 4.5 لكل 1000 سطر من التعليمات البرمجية ( SLOC ) إلى خطأ واحد لكل 1000 SLOC. [27]

أفادت دراسة أخرى أجريت عام 1990 أن عمليات تطوير البرامج الجيدة بشكل استثنائي يمكن أن تحقق معدلات فشل في النشر تصل إلى 0.1 لكل 1000 SLOC. [28] تم تكرار هذا الرقم في الأدبيات مثل Code Complete بواسطة Steve McConnell ، [29] ودراسة وكالة ناسا حول تعقيد برامج الطيران . [30] حتى أن بعض المشاريع حققت صفر عيوب: البرامج الثابتة في آلة كاتبة IBM Wheelwriter التي تتكون من 63000 SLOC، وبرنامج Space Shuttle مع 500000 SLOC. [28]

معيار

لتسهيل إجراء أبحاث قابلة للتكرار حول الاختبار وتصحيح الأخطاء، يستخدم الباحثون معايير مختارة للأخطاء:

  • معيار سيمنز
  • ManyBugs [31] هو معيار لـ 185 خطأ C في تسعة برامج مفتوحة المصدر.
  • Defects4J [32] هو معيار لـ 341 خطأ في Java من 5 مشاريع مفتوحة المصدر. ويحتوي على التصحيحات المقابلة، والتي تغطي مجموعة متنوعة من أنواع التصحيحات.

أنواع

بعض أنواع الأخطاء الملحوظة:

خطأ في التصميم

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

الحساب

يمكن أن تؤدي العمليات الرقمية إلى إخراج غير متوقع أو معالجة بطيئة أو تعطل. [33] يمكن أن يكون هذا الخطأ من نقص الوعي بخصائص تخزين البيانات مثل فقدان الدقة بسبب التقريب أو الخوارزميات غير المستقرة رقميًا أو فيض الحساب أو نقصه أو من نقص الوعي بكيفية التعامل مع الحسابات بواسطة لغات ترميز البرامج المختلفة مثل القسمة على الصفر والتي قد تطرح استثناءً في بعض اللغات وقد تعيد في لغات أخرى قيمة خاصة مثل NaN أو infinity .

التحكم في التدفق

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

الواجهة

  • استخدام API غير صحيح.
  • تنفيذ بروتوكول غير صحيح.
  • التعامل مع الأجهزة بشكل غير صحيح.
  • افتراضات خاطئة لمنصة معينة.
  • الأنظمة غير المتوافقة . قد يبدو أن واجهة برمجة التطبيقات أو بروتوكول الاتصالات الجديد يعمل عندما يستخدم نظامان إصدارات مختلفة، ولكن قد تحدث أخطاء عندما تتغير وظيفة أو ميزة تم تنفيذها في إصدار واحد أو تكون مفقودة في إصدار آخر. في أنظمة الإنتاج التي يجب أن تعمل باستمرار، قد لا يكون إيقاف تشغيل النظام بأكمله لتحديث رئيسي ممكنًا، كما هو الحال في صناعة الاتصالات [34] أو الإنترنت. [35] [36] [37] في هذه الحالة، تتم ترقية أجزاء أصغر من نظام كبير بشكل فردي، لتقليل التعطل في شبكة كبيرة. ومع ذلك، يمكن تجاهل بعض الأقسام وعدم ترقيتها، مما يتسبب في أخطاء التوافق التي قد يكون من الصعب العثور عليها وإصلاحها.
  • تعليقات الكود غير صحيحة.

التزامن

توفير الموارد

بناء الجملة

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

العمل الجماعي

  • التحديثات غير المنتشرة؛ على سبيل المثال، يقوم المبرمج بتغيير "myAdd" ولكنه ينسى تغيير "mySubtract"، والذي يستخدم نفس الخوارزمية. يتم التخفيف من هذه الأخطاء من خلال فلسفة "لا تكرر نفسك " .
  • تعليقات قديمة أو غير صحيحة: يفترض العديد من المبرمجين أن التعليقات تصف الكود بدقة.
  • الفرق بين التوثيق والمنتج.

في السياسة

تقرير "أخطاء في النظام"

أصدر معهد التكنولوجيا المفتوحة، الذي تديره مجموعة نيو أميركا ، [38] تقريرًا بعنوان "أخطاء في النظام" في أغسطس 2016 ينص على أن صناع السياسات في الولايات المتحدة يجب أن يقوموا بإصلاحات لمساعدة الباحثين على تحديد أخطاء البرامج ومعالجتها. ويسلط التقرير "الضوء على الحاجة إلى الإصلاح في مجال اكتشاف نقاط الضعف في البرامج والإفصاح عنها". [39] وقال أحد مؤلفي التقرير إن الكونجرس لم يفعل ما يكفي لمعالجة نقاط الضعف في البرامج الإلكترونية، على الرغم من أن الكونجرس أقر عددًا من مشاريع القوانين لمكافحة القضية الأكبر المتمثلة في الأمن الإلكتروني. [39]

إن الباحثين الحكوميين والشركات وخبراء الأمن السيبراني هم الأشخاص الذين يكتشفون عادةً عيوب البرامج. ويدعو التقرير إلى إصلاح قوانين الجرائم الحاسوبية وحقوق النشر. [39]

وذكر التقرير أن قانون الاحتيال وإساءة استخدام الكمبيوتر وقانون الألفية الرقمية لحقوق الطبع والنشر وقانون خصوصية الاتصالات الإلكترونية تجرم وتفرض عقوبات مدنية على الأفعال التي يقوم بها باحثو الأمن بشكل روتيني أثناء إجراء أبحاث أمنية مشروعة. [39]

  • في ألعاب الفيديو، يُستخدم مصطلح " خلل " أحيانًا للإشارة إلى خلل في البرنامج. ومن الأمثلة على ذلك الخلل والنوع غير الرسمي من البوكيمون MissingNo.
  • في كل من رواية 2001 : ملحمة الفضاء الصادرة عام 1968 وفيلم 2001 : ملحمة الفضاء الصادر عام 1968، يحاول الكمبيوتر الموجود على متن المركبة الفضائية، هال 9000 ، قتل جميع أفراد طاقمها. في رواية 2010 : ملحمة الفضاء الثانية الصادرة عام 1982 والفيلم المصاحب لها عام 1984، 2010 ، تم الكشف عن أن هذا الإجراء كان بسبب برمجة الكمبيوتر بهدفين متضاربين: الكشف الكامل عن جميع معلوماته، والحفاظ على سرية الغرض الحقيقي من الرحلة عن الطاقم؛ تسبب هذا الصراع في إصابة هال بجنون العظمة وفي النهاية بالميل إلى القتل.
  • في النسخة الإنجليزية من أغنية نينا 1983 99 Luftballons (99 بالون أحمر) نتيجة "أخطاء في البرنامج"، تم إطلاق مجموعة من 99 بالونًا أحمر تم الخلط بينها وبين إطلاق صاروخ نووي للعدو، مما يتطلب استجابة إطلاق مكافئة، مما يؤدي إلى كارثة.
  • في الفيلم الكوميدي الأمريكي Office Space لعام 1999 ، حاول ثلاثة موظفين (دون جدوى) استغلال انشغال شركتهم بمشكلة الكمبيوتر Y2K باستخدام فيروس كمبيوتر يرسل أجزاء مدورة من البنس إلى حسابهم المصرفي - وهي تقنية معروفة منذ فترة طويلة توصف بتقطيع السلامي .
  • رواية The Bug التي كتبتها إلين أولمان عام 2004 تتحدث عن محاولة أحد المبرمجين العثور على خطأ مراوغ في تطبيق قاعدة بيانات. [40]
  • الفيلم الكندي Control Alt Delete لعام 2008 يدور حول مبرمج كمبيوتر في نهاية عام 1999 يكافح من أجل إصلاح الأخطاء في شركته المتعلقة بمشكلة عام 2000.

انظر أيضا

مراجع

  1. ^ "تقرير فشل الرحلة 501 لصاروخ أريان 5 من قبل لجنة التحقيق". وكالة الفضاء الأوروبية . تقرير لجنة التحقيق في صاروخ أريان 501 (33-1996). 23 يوليو 1996.
  2. ^ سيمون روجرسون (أبريل 2002). "كارثة مروحية شينوك". مجلة IMIS . 12 (2). مؤرشف من الأصل في 15 سبتمبر 1993. تم الاسترجاع في 27 مايو 2024 .عنوان URL البديل
  3. ^ "فضيحة البريد دمرت حياة الناس، تحقيقات تستمع". بي بي سي نيوز . 14 فبراير 2022.
  4. ^ "أخطاء البرمجيات تكلف الاقتصاد الأميركي غالياً". 10 يونيو 2009. مؤرشف من الأصل في 10 يونيو 2009. تم الاسترجاع في 24 سبتمبر 2012 .
  5. ^ "Testing experience : te : the magazine for professional testers". Testing Experience . ألمانيا: testingexperience: 42. مارس 2012. ISSN  1866-5705. (الاشتراك مطلوب)
  6. ^ abcdefghi 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology . IEEE . 31 ديسمبر 1990. doi :10.1109/IEEESTD.1990.101064. ISBN 978-0-7381-0391-4.
  7. ^ "أخبار معهد هندسة البرمجيات، سبتمبر 1999". مجلة SEI Interactive . 2 (3). جامعة كارنيجي ميلون : معهد هندسة البرمجيات . 1 سبتمبر 1999.
  8. ^ جريج كايزر (21 أبريل 2011). "أبل تواجه أسئلة من الكونجرس حول تعقب الآيفون". Computerworld .
  9. ^ جريج كايزر (27 أبريل 2011). "أبل تنفي تعقب مستخدمي آيفون، لكنها تعد بالتغييرات". Computerworld .
  10. ^ دوروتا هويزينجا؛ آدم كولاوا (سبتمبر 2007). منع العيوب الآلي: أفضل الممارسات في إدارة البرمجيات. مطبعة جمعية الكمبيوتر التابعة لمعهد مهندسي الكهرباء والإلكترونيات وايلي. رقم ISBN 978-0-470-04212-0.
  11. ^ ماكدونالد، مارك؛ موسون، روبرت؛ سميث، روس (2007). الدليل العملي للوقاية من العيوب . مطبعة مايكروسوفت. ص. 480. رقم ISBN 978-0-7356-2253-1.
  12. ^ "الإصدار المبكر، الإصدار المتكرر" محفوظ في 14 مايو 2011، على موقع واي باك مشين ، إريك س. رايموند ، الكاتدرائية والبازار
  13. ^ "Wide Open Source" محفوظ في 29 سبتمبر 2007، على موقع Wayback Machine ، إلياس ليفي ، SecurityFocus ، 17 أبريل 2000
  14. ^ "اقتباسات موريس ويلكس". QuoteFancy . تم الاسترجاع في 28 أبريل 2024 .
  15. ^ "تاريخ شركة PolySpace Technologies". christele.faure.pagesperso-orange.fr . تم الاسترجاع في 1 أغسطس 2019 .
  16. ^ ألين، ميتش (مايو-يونيو 2002). "أساسيات تتبع الأخطاء: دليل المبتدئين للإبلاغ عن العيوب وتتبعها". مجلة اختبار البرمجيات وهندسة الجودة . المجلد 4، العدد 3. ص 20-24 . تم الاسترجاع في 19 ديسمبر 2017 .
  17. ^ ريكس بلاك (2002). إدارة عملية الاختبار (الطبعة الثانية). وايلي إنديا بي في تي المحدودة. ص 139. رقم ISBN 978-8126503131تم الاسترجاع في 19 يونيو 2021 .
  18. ^ كريس فاندر ماي (2012). عظمة الشحن - دروس عملية حول بناء وإطلاق برامج متميزة، تعلمها أثناء العمل في جوجل وأمازون. أوريلي ميديا . ص 79-81. رقم ISBN 978-1449336608.
  19. ^ سليماني نيسياني، بهزاد؛ بابامير، سيد مرتضى؛ أريتسوغي، ماسايوشي (1 أكتوبر 2020). "نموذج استخراج الميزات الفعّال لتحسين أداء التحقق من اكتشاف تقارير الأخطاء المكررة في أنظمة فرز أخطاء البرامج". تكنولوجيا المعلومات والبرمجيات . 126 : 106344. doi :10.1016/j.infsof.2020.106344. S2CID  219733047.
  20. ^ "5.3. تشريح حشرة". bugzilla.org . مؤرشف من الأصل في 23 مايو 2013.
  21. ^ جونز، ويلبر د. الابن، محرر (1989). "Show stopper". Glossary: ​​defense acquire acronyms and terms (4 ed.). فورت بيلفوار، فرجينيا: وزارة الدفاع، كلية إدارة أنظمة الدفاع . ص. 123. hdl :2027/mdp.39015061290758 – عبر Hathitrust.
  22. ^ زاكاري، ج. باسكال (1994). عرض مذهل!: السباق المحموم لإنشاء نظام التشغيل Windows NT والجيل القادم في مايكروسوفت . نيويورك: ذا فري بريس . ص. 158. رقم ISBN 0029356717- عبر archive.org.
  23. ^ "معجم الجيل القادم لعام 1996 من الألف إلى الياء: إصدار Slipstream". الجيل القادم . العدد 15. مارس 1996. ص 41.
  24. ^ كار، نيكولاس (2018). ""إنها ليست حشرة، بل ميزة. هل هي مبتذلة أم مجرد صواب؟". wired.com .
  25. ^ Lientz, BP; Swanson, EB; Tompkins, GE (1978). "خصائص صيانة برامج التطبيقات". Communications of the ACM . 21 (6): 466–471. doi : 10.1145/359511.359522 . S2CID  14950091.
  26. ^ أميت، إيدان؛ فيتلسون، درور جي. (2020). "مقياس جودة رمز احتمالية الالتزام التصحيحي". arXiv : 2007.10912 [cs.SE].
  27. ^ "نظرة عامة على مختبر هندسة البرمجيات" (PDF) . سلسلة مختبر هندسة البرمجيات (SEL-94-005). ديسمبر 1994.
  28. ^ ab Cobb, Richard H.; Mills, Harlan D. (1990). "Engineering software under statistical quality control". IEEE Software . 7 (6): 46. doi :10.1109/52.60601. ISSN  1937-4194. S2CID  538311 – via University of Tennessee – Harlan D. Mills Collection.
  29. ^ McConnell, Steven C. (1993). Code Complete . ريدموند، واشنطن: Microsoft Press. ص. 611. ISBN 978-1556154843– عبر archive.org. (كوب وميلز 1990)
  30. ^ جيرارد هولزمان (5 مارس 2009). "الملحق د – تعقيد البرمجيات" (PDF) . التقرير النهائي: دراسة ناسا حول تعقيد برمجيات الطيران (دانييل إل. دفوراك (المحرر)) . برنامج التميز التقني لمكتب كبير المهندسين التابع لوكالة ناسا.
  31. ^ Le Goues, Claire; Holtschulte, Neal; Smith, Edward K.; Brun, Yuriy; Devanbu, Premkumar; Forrest, Stephanie; Weimer, Westley (2015). "The ManyBugs and IntroClass Benchmarks for Automated Repair of C Programs". معاملات معهد مهندسي الكهرباء والإلكترونيات في هندسة البرمجيات . 41 (12): 1236–1256. doi : 10.1109/TSE.2015.2454513 . ISSN  0098-5589.
  32. ^ Just, René; Jalali, Darioush; Ernst, Michael D. (2014). "Defects4J: a database of existing faults to enable controlled testing studies for Java programs". Proceedings of the 2014 International Symposium on Software Testing and Analysis – ISSTA 2014 . ص. 437–440. CiteSeerX 10.1.1.646.3086 . doi :10.1145/2610384.2628055. ISBN  9781450326452. S2CID  12796895.
  33. ^ أنتوني دي فرانكو؛ هوي جو؛ سيندي روبيو جونزاليس (23 نوفمبر 2017). دراسة شاملة لخصائص الأخطاء العددية في العالم الحقيقي . المؤتمر الدولي الثاني والثلاثون لمعهد مهندسي الكهرباء والإلكترونيات / رابطة آلات الحوسبة الآلية حول هندسة البرمجيات الآلية (ASE) لعام 2017. IEEE . doi :10.1109/ASE.2017.8115662.
  34. ^ كيمبلر، ك. (1998). تفاعلات الميزات في أنظمة الاتصالات والبرمجيات، المجلد 8، دار نشر آي أو إس. رقم ISBN 978-90-5199-431-5.
  35. ^ سيد، محبوب الرحمن (2001). الشبكات المتعددة الوسائط: التكنولوجيا والإدارة والتطبيقات: التكنولوجيا والإدارة والتطبيقات. شركة آيديا جروب (IGI). ص. 398. رقم ISBN 978-1-59140-005-9.
  36. ^ وو، تشوان هوا (جون)؛ إروين، جيه ديفيد (2016). مقدمة إلى شبكات الكمبيوتر والأمن السيبراني. دار نشر سي آر سي. ص 500. رقم ISBN 978-1-4665-7214-0.
  37. ^ RFC 1263: "تم اعتبار ملحقات TCP ضارة" اقتباس: "قد يستغرق توزيع الإصدار الجديد من البروتوكول على جميع المضيفين وقتًا طويلاً للغاية (إلى الأبد في الواقع). ... إذا كان هناك أدنى قدر من عدم التوافق بين الإصدارات القديمة والجديدة، فقد يؤدي ذلك إلى الفوضى."
  38. ^ ويلسون، أندي؛ شولمان، روس؛ بانكستون، كيفن؛ هير، تري. "أخطاء في النظام" (PDF) . معهد السياسة المفتوحة . مؤرشف من الأصل (PDF) في 21 سبتمبر 2016. تم الاسترجاع في 22 أغسطس 2016 .
  39. ^ abcd روزنز، تريسي (12 أغسطس/آب 2016). "الإصلاحات السيبرانية ضرورية لتعزيز اكتشاف أخطاء البرمجيات والإفصاح عنها: تقرير نيو أميركا – أخبار الاستعداد للوطن" . تم الاسترجاع في 23 أغسطس/آب 2016 .
  40. ^ أولمان ، إلين (2004). العلة . بيكادور . رقم ISBN 978-1-250-00249-5.
يحتوي موقع MediaWiki على وثائق تتعلق بـ: إدارة الأخطاء
  • "تعداد نقاط الضعف الشائعة" - صفحة ويب متخصصة تركز على الأخطاء، على موقع NIST.gov
  • نوع من الأخطاء من جيم جراي – نوع آخر من الأخطاء
  • صورة "أول خطأ في الكمبيوتر" على موقع Wayback Machine (تم أرشفتها في 12 يناير 2015)
  • "أول خطأ في الكمبيوتر!" - رسالة بريد إلكتروني من عام 1981 حول خطأ الأدميرال هوبر
  • "نحو فهم أخطاء المترجم في GCC وLLVM". دراسة أجريت عام 2016 حول الأخطاء في المترجمين
تم الاسترجاع من "https://en.wikipedia.org/w/index.php?title=خلل_البرمجيات&oldid=1244997414"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate