خلل برمجي

الموسوعة الحرة

فشل برنامج BASIC بسبب خطأ في بناء الجملة في الكود الخاص به

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

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

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

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

تاريخ

يُستخدم مصطلح "الخطأ البرمجي" لوصف عيب ما، وهو مصطلح هندسي شائع منذ سبعينيات القرن التاسع عشر على الأقل، أي قبل ظهور الحواسيب الإلكترونية وبرامجها بفترة طويلة. فعلى سبيل المثال، كتب توماس إديسون الكلمات التالية في رسالة إلى أحد زملائه عام ١٨٧٨:

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

كانت المشاكل التي طرأت على المعدات العسكرية خلال الحرب العالمية الثانية تُعرف باسم الأخطاء أو الخلل. [ 3 ]

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

صفحة من سجل حاسوب هارفارد مارك 2 الكهروميكانيكي، تعرض صورة لعثة ميتة تم إزالتها من الجهاز.

اشتهرت قصةٌ عن عثةٍ تسببت في عطلٍ في حاسوبٍ كهروميكانيكيٍّ مبكر ، بفضل الأدميرال غريس هوبر ، رائدة الحوسبة في البحرية الأمريكية. [ 4 ] وبينما كانت هوبر تعمل على حاسوبي مارك 2 ومارك 3 كعضو هيئة تدريس في جامعة هارفارد حوالي عام 1947، اكتشف المشغلون خطأً في حاسوب مارك 2، ورجعوا إلى عثةٍ عالقةٍ في مرحل. أُزيلت العثة من الآلية ووُضعت في سجلٍّ مع ملاحظةٍ تقول: "أول حالةٍ فعليةٍ لاكتشاف خللٍ برمجيٍّ". [ 5 ] ويُقال إن المشغلين، بمن فيهم ويليام "بيل" بيرك، الذي عمل لاحقًا في مختبر الأسلحة البحرية في دالغرين، فرجينيا ، [ 6 ] كانوا على درايةٍ بالمصطلح الهندسي، وربما كانوا يمزحون بدمج معنيي كلمة "خللٍ برمجيٍّ" (البيولوجي والتقني). حتى لو كانت القصة مزحة، فإنها تُشير إلى أن المصطلح كان شائع الاستخدام في مجال الحوسبة في ذلك الوقت. [ 7 ] [ 8 ] [ 9 ] [ 10 ]

مصطلحات

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

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

أمثلة

تم ربط أخطاء البرمجيات بالكوارث.

الجدل

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

يزعم البعض أن مصطلح "خلل" قد يُستخدم للتغطية على قرار تصميمي مُتعمّد. ففي عام ٢٠١١، وبعد أن تعرّضت شركة آبل لانتقادات من السيناتور الأمريكي آل فرانكن لتسجيلها وتخزينها مواقع المستخدمين في ملفات غير مُشفّرة، [ ١٨ ] وصفت آبل هذا السلوك بأنه خلل. إلا أن جاستن بروكمان من مركز الديمقراطية والتكنولوجيا اعترض مباشرةً على هذا الوصف، قائلاً: "أنا سعيدٌ بإصلاحهم لما يُسمّونه خللاً، لكنني أختلف مع إنكارهم القاطع لتتبّع المستخدمين". [ ١٩ ]

وقاية

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

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

الدعم اللغوي

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

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

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

float num = "3";

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

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

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

التقنيات

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

على سبيل المثال، تسمح معظم لغات البرمجة من عائلة C بحذف الأقواس حول كتلة التعليمات إذا كانت تحتوي على تعليمة واحدة فقط. ينفذ الكود التالي الدالة fooفقط إذا conditionكانت القيمة صحيحة:

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

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

إذا (كان الشرط)؛ foo();

إن استخدام الأقواس - حتى لو لم يكن مطلوبًا بشكل صارم - يمنع هذا الخطأ بشكل موثوق:

إذا (كان الشرط) { foo(); }

قد يكون تطبيق الاتفاقيات يدويًا (أي من خلال مراجعة التعليمات البرمجية ) أو من خلال أدوات آلية مثل أدوات فحص الأخطاء البرمجية .

مواصفة

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

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

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

ممارسات أجايل

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

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

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

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

الأجهزة

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

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

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

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

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

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

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

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

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

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

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

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

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

إدارة

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

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

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

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

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

خطورة

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

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

أولوية

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

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

رقعة

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

إصدار صيانة

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

مشكلة معروفة

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

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

تداعيات

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

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

المقاييس

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

أشارت دراسة أخرى أُجريت عام 1990 إلى أن عمليات تطوير البرمجيات المتميزة للغاية قادرة على تحقيق معدلات فشل نشر منخفضة تصل إلى 0.1 لكل 1000 سطر برمجي. [ 39 ] وقد ورد هذا الرقم في مراجع مثل كتاب "Code Complete" لستيف ماكونيل ، [ 40 ] ودراسة ناسا حول تعقيد برمجيات الطيران . [ 41 ] بل إن بعض المشاريع حققت خلوًا تامًا من العيوب: مثل البرامج الثابتة في آلة الكتابة IBM Wheelwriter التي تتكون من 63000 سطر برمجي، وبرمجيات مكوك الفضاء التي تتكون من 500000 سطر برمجي. [ 39 ]

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

  • معيار سيمنز [ 42 ]
  • ManyBugs هو معيار لقياس 185 خطأ برمجي في لغة C في تسعة برامج مفتوحة المصدر. [ 43 ]
  • Defects4J هو معيارٌ لتقييم 341 خطأً برمجيًا في لغة جافا من 5 مشاريع مفتوحة المصدر. [ 44 ] ويحتوي على التصحيحات المقابلة، والتي تغطي أنواعًا مختلفة من التصحيحات. وقد استُخدم على نطاق واسع في أبحاث إصلاح البرامج تلقائيًا. [ 45 ]

الأنواع

بعض أنواع الأخطاء البرمجية البارزة:

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

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

الحساب

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

تدفق التحكم

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

التفاعل

  • استخدام غير صحيح لواجهة برمجة التطبيقات (API).
  • تطبيق البروتوكول بشكل غير صحيح.
  • التعامل غير الصحيح مع الأجهزة.
  • افتراضات خاطئة حول منصة معينة.
  • أنظمة غير متوافقة . قد يبدو أن واجهة برمجة تطبيقات جديدة أو بروتوكول اتصالات يعمل بشكل صحيح عند استخدام نظامين لإصدارات مختلفة، ولكن قد تحدث أخطاء عند تغيير وظيفة أو ميزة مُطبقة في إصدار ما أو غيابها في إصدار آخر. في أنظمة الإنتاج التي يجب أن تعمل باستمرار، قد لا يكون إيقاف النظام بالكامل لإجراء تحديث رئيسي ممكنًا، كما هو الحال في قطاع الاتصالات [ 47 ] أو الإنترنت [ 48 ] [ 49 ] [ 50 ] . في هذه الحالة، تُحدَّث أجزاء أصغر من النظام الكبير بشكل فردي، لتقليل تعطيل الشبكة الكبيرة. مع ذلك، قد تُغفل بعض الأجزاء ولا تُحدَّث، مما يتسبب في أخطاء توافق قد يصعب اكتشافها وإصلاحها.
  • تعليقات توضيحية غير صحيحة للرمز البرمجي.

التزامن

الموارد

بناء الجملة

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

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

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

في السياسة

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

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

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

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

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

انظر أيضاً

مراجع

  1. ↑ "أخطاء البرمجيات تُكلّف الاقتصاد الأمريكي ثمناً باهظاً" . 10 يونيو 2009. مؤرشف من الأصل في 10 يونيو 2009. تم الاطلاع عليه في 24 سبتمبر 2012 .
  2. ↑ رسالة من إديسون إلى بوشكاس، بتاريخ 13 نوفمبر 1878، أوراق إديسون، مختبر إديسون الوطني، دائرة المتنزهات الوطنية الأمريكية، ويست أورانج، نيوجيرسي، نقلاً عن هيوز، توماس بارك (1989). النشأة الأمريكية: قرن من الاختراع والحماس التكنولوجي، 1870-1970 . دار بنغوين للنشر. ص 75. ISBN  978-0-14-009741-2.
  3. ↑ «حاملات الطائرات الحديثة هي نتيجة 20 عامًا من التجارب الذكية» . مجلة لايف . 29 يونيو 1942. ص 25. مؤرشف من الأصل في 4 يونيو 2013. تم الاطلاع عليه في 17 نوفمبر 2011 . 
  4. ↑ اختبار FCAT NRT ، هاركورت، 18 مارس 2008
  5. ↑ "سجل بيانات به خلل في الكمبيوتر" . americanhistory.si.edu . تم الاطلاع عليه بتاريخ 16 أغسطس 2024 .
  6. ↑ حوليات معهد مهندسي الكهرباء والإلكترونيات لتاريخ الحوسبة، المجلد 22، العدد 1، 2000
  7. ↑ جيمس س. هيغنز. "أول خطأ برمجي في الحاسوب" . Jamesshuggins.com. مؤرشف من الأصل في 16 أغسطس 2000. تم الاطلاع عليه في 24 سبتمبر 2012 .
  8. ↑ " تمت أرشفة هذا الخطأ في 23 مارس 2017، في Wayback Machine "، ملف المصطلحات ، الإصدار 4.4.7. تم استرجاعه في 3 يونيو 2010.
  9. ↑ " سجل مع خلل في الكمبيوتر مؤرشف في 23 مارس 2017، في Wayback Machine "، المتحف الوطني للتاريخ الأمريكي، مؤسسة سميثسونيان.
  10. ↑ " أول "خلل في الحاسوب "، المركز التاريخي البحري. لكن تجدر الإشارة إلى أن حاسوب هارفارد مارك الثاني لم يكتمل حتى صيف عام 1947.
  11. ↑ "تجربة الاختبار : مجلة للمختبرين المحترفين". تجربة الاختبار . ألمانيا: testingexperience: 42. مارس 2012. ISSN 1866-5705 .   (الاشتراك مطلوب)
  12. 1 2 3 4 5 6 7 8 9 610.12-1990: معجم مصطلحات هندسة البرمجيات القياسي الصادر عن معهد مهندسي الكهرباء والإلكترونيات (IEEE ) . معهد مهندسي الكهرباء والإلكترونيات . 31 ديسمبر 1990. doi : 10.1109/IEEESTD.1990.101064 . ISBN 978-0-7381-0391-4.
  13. ↑ ليفيسون، نانسي ج .؛ تيرنر، كلارك س. (1 يوليو 1993). "تحقيق في حوادث ثيراك-25" . مجلة الكمبيوتر . 26 (7). جمعية مهندسي الكهرباء والإلكترونيات : 18-41 . رمز Bibcode : 1993Compr..26g..18L . doi : 10.1109/ MC.1993.274940 . eISSN 1558-0814 . ISSN 0018-9162 . LCCN 74648480. OCLC 2240099. S2CID 9691171 .     
  14. ↑ «تقرير لجنة التحقيق في فشل رحلة أريان 5 رقم 501» . وكالة الفضاء الأوروبية . تقرير لجنة التحقيق في حادثة أريان 501 ( 33-1996 ). 23 يوليو/تموز 1996.
  15. ↑ سيمون روجرسون (أبريل 2002). "كارثة مروحية شينوك" . مجلة IMIS . 12 (2). مؤرشف من الأصل في 10 أبريل 2016. تم الاطلاع عليه في 27 مايو 2024 .رابط بديل
  16. ↑ "فضيحة مكتب البريد دمرت حياة الناس، بحسب ما ورد في التحقيق" . بي بي سي نيوز . 14 فبراير 2022.
  17. ↑ همفري، واتس س. (1 أبريل 1999). "أخبار معهد هندسة البرمجيات - أخطاء أم عيوب؟" (ملف PDF) . أخبار معهد هندسة البرمجيات . صفحة 73 من 154 في ملف PDF. مؤرشف (PDF) من الأصل في 15 أكتوبر 2023. تم الاطلاع عليه في 2 فبراير 2025 .(مرتبط من أرشيف أخبار معهد الدراسات العليا لعام 1999 )
  18. ↑ غريغ كايزر (21 أبريل 2011). "أبل تواجه أسئلة من الكونغرس حول تتبع أجهزة آيفون" . كمبيوتر وورلد .
  19. ↑ غريغ كايزر (27 أبريل 2011). "أبل تنفي تتبع مستخدمي آيفون، لكنها تعد بإجراء تغييرات" . كمبيوتر وورلد .
  20. ↑ دوروتا هويزينغا؛ آدم كولاوا (سبتمبر 2007). الوقاية الآلية من العيوب: أفضل الممارسات في إدارة البرمجيات . مطبعة وايلي-IEEE لجمعية الحاسبات. ISBN 978-0-470-04212-0.
  21. ↑ ماكدونالد ، مارك؛ موسون، روبرت؛ سميث، روس (2007). الدليل العملي للوقاية من العيوب . مطبعة مايكروسوفت. ص 480. ISBN  978-0-7356-2253-1.
  22. ↑ داي، سومين؛ تشاكرابورتي، أشيش كومار (ديسمبر 2024). "تقدير موثوقية البرمجيات باستخدام نمذجة متحيزة الحجم" . مجلة الإحصاء التطبيقي . 51 (16): 3386-3406 . Bibcode : 2024JApSt..51.3386D . doi : 10.1080/ 02664763.2024.2352751 . ISSN 1360-0532 . PMC 11610320. PMID 39628856 .   
  23. ↑ "أصدر مبكرًا، أصدر كثيرًا" مؤرشف في 14 مايو 2011، في Wayback Machine ، إريك س. ريموند ، الكاتدرائية والبازار
  24. ↑ "المصدر المفتوح على نطاق واسع" مؤرشف في 29 سبتمبر 2007، في آلة Wayback ، إلياس ليفي ، SecurityFocus ، 17 أبريل 2000
  25. ↑ "اقتباسات موريس ويلكس" . موقع QuoteFancy . تم الاطلاع عليه بتاريخ 28 أبريل 2024 .
  26. ↑ "تاريخ شركة بولي سبيس تكنولوجيز" . christele.faure.pagesperso-orange.fr . تم الاطلاع عليه بتاريخ 1 أغسطس 2019 .
  27. ↑ ألين، ميتش (مايو-يونيو 2002). "أساسيات تتبع الأخطاء: دليل للمبتدئين للإبلاغ عن العيوب وتتبعها" . مجلة اختبار البرمجيات وهندسة الجودة . المجلد 4، العدد 3، الصفحات 20-24 . تاريخ الاطلاع: 19 ديسمبر 2017 .   
  28. ↑ ريكس بلاك (2002). إدارة عملية الاختبار ( الطبعة الثانية). وايلي إنديا برايفت ليمتد. ص 139. ISBN   978-8126503131تم الاطلاع عليه بتاريخ 19 يونيو 2021 .
  29. ↑ كريس فاندر ماي (2012). التميز في الشحن - دروس عملية في بناء وإطلاق برامج متميزة، مكتسبة من العمل في جوجل وأمازون . دار نشر أورايلي ميديا . الصفحات 79-81 . ISBN  978-1449336608.
  30. ↑ سليماني نيسياني، بهزاد؛ بابامر، سيد مرتضى؛ أريتسوغي، ماسايوشي (1 أكتوبر 2020). "نموذج فعال لاستخلاص الميزات لتحسين أداء التحقق من صحة اكتشاف تقارير الأخطاء المكررة في أنظمة فرز أخطاء البرمجيات" . تكنولوجيا المعلومات والبرمجيات . 126 106344. doi : 10.1016/j.infsof.2020.106344 . S2CID 219733047 . 
  31. ↑ "5.3. تشريح الخلل" . bugzilla.org . مؤرشف من الأصل في 23 مايو 2013.
  32. ↑ جونز، ويلبر د. الابن، محرر (1989). "مُعطِّل العرض" . مُعجم: مُختصرات ومصطلحات الاستحواذ الدفاعي ( الطبعة الرابعة). فورت بيلفوار، فيرجينيا: وزارة الدفاع، كلية إدارة أنظمة الدفاع . ص 123. hdl : 2027/mdp.39015061290758 – عبر هاثي تراست.  
  33. ↑ زاكاري، جي. باسكال (1994). عرضٌ مذهل!: السباق المحموم لإنشاء ويندوز إن تي والجيل التالي في مايكروسوفت . نيويورك: ذا فري برس . ص 158. ISBN  0029356717– عبر موقع archive.org.
  34. ↑ "معجم الجيل القادم 1996 من الألف إلى الياء: إصدار سليبستريم". الجيل القادم . العدد 15. مارس 1996. ص 41.  
  35. ↑ كار، نيكولاس (2018). "" إنها ليست مشكلة، بل ميزة." مبتذلة - أم مناسبة تمامًا ؟ wired.com
  36. ↑ لينتز، بي بي؛ سوانسون، إي بي؛ تومبكينز، جي إي (1978). "خصائص صيانة برامج التطبيقات" . مجلة اتصالات رابطة مكائن ​​الحوسبة . 21 (6): 466-471 . doi : 10.1145/359511.359522 . S2CID 14950091 . 
  37. ↑ أميت، إيدان؛ فيتلسون، درور ج. (2020). "مقياس جودة الكود لاحتمالية الالتزام التصحيحي". arXiv : 2007.10912 [ cs.SE ].
  38. ↑ "نظرة عامة على مختبر هندسة البرمجيات" (ملف PDF) . سلسلة مختبر هندسة البرمجيات (SEL-94-005): 22293. ديسمبر 1994. رمز Bibcode : 1994ntrs.rept22293.
  39. 1 2 كوب، ريتشارد هـ.؛ ميلز، هارلان د. (1990). "هندسة البرمجيات في ظل مراقبة الجودة الإحصائية" . مجلة IEEE للبرمجيات . 7 (6): 46. رمز Bibcode : 1990ISoft...7f..45C . doi : 10.1109/52.60601 . ISSN 1937-4194 . S2CID 538311 - عبر جامعة تينيسي - مجموعة هارلان د. ميلز.  
  40. ↑ ماكونيل، ستيفن سي. (1993). كود كومبليت . ريدموند، واشنطن: مطبعة مايكروسوفت. ص 611. ISBN  978-1556154843– عبر موقع archive.org. (كوب وميلز 1990)
  41. ↑ جيرارد هولزمان (5 مارس 2009). "الملحق د - تعقيد البرمجيات" (ملف PDF) . التقرير النهائي: دراسة ناسا حول تعقيد برمجيات الطيران (دانيال ل. دفوراك (محرر)) . برنامج التميز التقني التابع لمكتب كبير المهندسين في ناسا.
  42. ↑ هيكمان، سارة؛ ويليامز، لوري (2008). "حول وضع معيار لتقييم تقنيات تحديد أولويات التنبيهات وتصنيفها في التحليل الثابت" (ملف PDF) . جامعة ولاية كارولينا الشمالية . تم الاطلاع عليه في 2 مايو 2026 .
  43. ↑ لو غويس، كلير ؛ هولتشولت، نيل؛ سميث، إدوارد ك.؛ برون، يوري؛ ديفانبو، بريمكومار؛ فورست، ستيفاني؛ وايمر، ويستلي (2015). "معايير ManyBugs وIntroClass للإصلاح الآلي لبرامج لغة C" . معاملات IEEE في هندسة البرمجيات . 41 (12): 1236-1256 . Bibcode : 2015ITSEn..41.1236L . doi : 10.1109/TSE.2015.2454513 . ISSN 0098-5589 . 
  44. ↑ جست، رينيه؛ جلالي، داريوش؛ إرنست، مايكل د. (2014). "Defects4J: قاعدة بيانات للأخطاء الموجودة لتمكين دراسات الاختبار المضبوطة لبرامج جافا". وقائع الندوة الدولية لاختبار البرمجيات وتحليلها لعام 2014 - ISSTA 2014. الصفحات 437-440 . CiteSeerX 10.1.1.646.3086 . doi : 10.1145/2610384.2628055 . ISBN   9781450326452. S2CID 12796895 . 
  45. ↑ مارتينيز، ماتياس؛ دوريو، توماس؛ سوميرارد، رومان؛ شوان، جيفنغ؛ مونبيروس، مارتن (أغسطس 2017). "الإصلاح التلقائي للأخطاء الحقيقية في جافا: تجربة واسعة النطاق على مجموعة بيانات defects4j". هندسة البرمجيات التجريبية . 22 (4): 1936-1964 . arXiv : 1811.02429 . doi : 10.1007/s10664-016-9470-4 . ISSN 1573-7616 . 
  46. ↑ أنتوني دي فرانكو؛ هوي غو؛ سيندي روبيو-غونزاليس (23 نوفمبر 2017). دراسة شاملة لخصائص الأخطاء العددية في العالم الحقيقي . المؤتمر الدولي الثاني والثلاثون لعام 2017 التابع لمعهد مهندسي الكهرباء والإلكترونيات / رابطة مكائن ​​الحوسبة حول هندسة البرمجيات الآلية (ASE). معهد مهندسي الكهرباء والإلكترونيات . doi : 10.1109/ASE.2017.8115662 .
  47. ↑ كيمبلر، ك. (1998). تفاعلات الميزات في أنظمة الاتصالات والبرمجيات، المجلد الخامس . دار نشر IOS. ص 8. ISBN  978-90-5199-431-5.
  48. ↑ سيد، محبوب الرحمن (2001). شبكات الوسائط المتعددة: التكنولوجيا والإدارة والتطبيقات . مجموعة آيديا (IGI). ص 398. ISBN  978-1-59140-005-9.
  49. ↑ وو، تشوان-هوا (جون)؛ إيروين، ج. ديفيد (2016). مقدمة في شبكات الحاسوب والأمن السيبراني . مطبعة سي آر سي. ص 500. ISBN  978-1-4665-7214-0.
  50. ↑ RFC 1263 : "امتدادات TCP تُعتبر ضارة" اقتباس: "قد يستغرق توزيع الإصدار الجديد من البروتوكول على جميع الأجهزة المضيفة وقتًا طويلاً (بل قد يستغرق وقتًا طويلاً جدًا في الواقع). ... إذا كان هناك أدنى عدم توافق بين الإصدارات القديمة والجديدة، فقد ينتج عن ذلك فوضى عارمة."
  51. ↑ ويلسون، أندي؛ شولمان، روس؛ بانكستون، كيفن؛ هير، تري. "أخطاء في النظام" (ملف PDF) . معهد السياسات المفتوحة . مؤرشف (ملف PDF) من الأصل في 21 سبتمبر 2016. تم الاطلاع عليه في 22 أغسطس 2016 .
  52. 1 2 3 4 روزينز، تريسي (12 أغسطس 2016). "إصلاحات الأمن السيبراني ضرورية لتعزيز اكتشاف أخطاء البرمجيات والإبلاغ عنها: تقرير مؤسسة أمريكا الجديدة - أخبار الاستعداد للأمن الداخلي" . تم الاطلاع عليه في 23 أغسطس 2016 .
  53. ^ أولمان ، إلين (2004). العلة . بيكادور . رقم ISBN 978-1-250-00249-5.