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

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

كأس الاختبار - البطولة البولندية لاختبار البرمجيات، كاتوفيتشي ، مايو 2016

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

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

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

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

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

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

غالباً ما يتم استخدام اختبار البرمجيات للإجابة على السؤال التالي: هل يقوم البرنامج بما يفترض أن يقوم به وما يحتاج إلى القيام به؟

يمكن استخدام المعلومات المستقاة من اختبار البرمجيات لتحسين عملية تطوير البرمجيات. [ 5 ] : 41-43

يُعدّ "هرم الاختبار" أحد الأساليب الشائعة المقترحة للاختبار الآلي، حيث تكون معظم الاختبارات عبارة عن اختبارات وحدة ، تليها مجموعة أصغر من اختبارات التكامل ، وأخيرًا عدد قليل من اختبارات التكامل الشامل (e2e) . [ 6 ] [ 7 ] [ 8 ]

الاقتصاد

أفادت دراسة أجراها المعهد الوطني للمعايير والتكنولوجيا (NIST) عام 2002 أن أخطاء البرمجيات تكلف الاقتصاد الأمريكي 59.5 مليار دولار سنوياً. ويمكن تجنب أكثر من ثلث هذه التكلفة إذا تم إجراء اختبارات برمجيات أفضل. [ 9 ]

يُعدّ الاستعانة بمصادر خارجية لاختبار البرمجيات بسبب التكاليف أمرًا شائعًا للغاية، وتُعتبر الصين والفلبين والهند وباكستان وجهات مفضلة. [ 10 ]

تاريخ

قدّم غلينفورد ج. مايرز مفهوم فصل تصحيح الأخطاء عن اختبار البرمجيات لأول مرة عام ١٩٧٩. [ ١١ ] ورغم أن تركيزه انصبّ على اختبار الأعطال ("حالة الاختبار الناجحة هي التي تكشف خطأً لم يُكتشف بعد." [ ١١ ] : ١٦ )، إلا أن ذلك أوضح رغبة مجتمع هندسة البرمجيات في فصل أنشطة التطوير الأساسية، مثل تصحيح الأخطاء، عن أنشطة التحقق. يتضمن اختبار البرمجيات عادةً معالجة أخطاء البرمجيات - وهي عيوب في الكود تُسبب نتائج غير مرغوب فيها. [ ١٢ ] : ٣١. تُبطئ الأخطاء عمومًا عملية الاختبار وتتطلب مساعدة المبرمجين لتصحيحها وإصلاحها.

لا تؤدي جميع العيوب إلى الفشل. على سبيل المثال، لا يُعتبر العيب في التعليمات البرمجية غير المستخدمة فشلاً.

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

الأهداف

عادةً ما يكون اختبار البرمجيات موجهاً نحو تحقيق هدف محدد.

اكتشاف الأخطاء

يشمل اختبار البرمجيات عادةً معالجة الأخطاء البرمجية - وهي عيوب في الكود تتسبب في نتائج غير مرغوب فيها. [ 12 ] : 31 تُبطئ الأخطاء البرمجية عمومًا عملية الاختبار وتتطلب مساعدة المبرمجين لتصحيحها وإصلاحها.

لا تؤدي جميع العيوب إلى الفشل. على سبيل المثال، لا يُعتبر العيب في التعليمات البرمجية غير المستخدمة فشلاً.

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

قد يؤدي عيب واحد إلى ظهور أعراض فشل متعددة.

ضمان تلبية المتطلبات

قد يتضمن اختبار البرمجيات فجوة في المتطلبات - أي إغفال أحد المتطلبات من التصميم. [ 5 ] : 426 ويمكن أن تكون فجوات المتطلبات في كثير من الأحيان متطلبات غير وظيفية مثل قابلية الاختبار ، وقابلية التوسع ، وقابلية الصيانة ، والأداء ، والأمان .

تغطية التعليمات البرمجية

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

على الرغم من أن اختبار كل مدخل محتمل ليس بالأمر العملي، إلا أنه يمكن للاختبار استخدام التوافقية لزيادة التغطية إلى أقصى حد مع تقليل الاختبارات إلى أدنى حد. [ 15 ]

فئات

يمكن تصنيف الاختبارات بعدة طرق. [ 16 ]

الاختبار الآلي

أتمتة الاختبار هي استخدام برمجيات (منفصلة عن البرمجيات قيد الاختبار) للتحكم في تنفيذ الاختبارات ومقارنة النتائج الفعلية بالنتائج المتوقعة. [ 17 ] تدعم أتمتة الاختبار اختبار النظام قيد الاختبار (SUT) دون تدخل يدوي، مما يُسرّع عملية الاختبار ويزيد من وتيرة إجرائه. تُعدّ أتمتة الاختبار عنصرًا أساسيًا في الاختبار المستمر ، وغالبًا ما تُستخدم في التكامل المستمر والتسليم المستمر (CI/CD). [ 18 ]

المستويات

يمكن تصنيف اختبار البرمجيات إلى مستويات بناءً على مدى تركيز الاختبار على نظام البرمجيات . [ 19 ] [ 20 ] [ 21 ] [ 22 ]

اختبار الوحدة

اختبار الوحدة ، المعروف أيضًا باختبار المكونات أو الوحدات، هو شكل من أشكال اختبار البرمجيات يتم من خلاله اختبار شفرة المصدر المعزولة للتحقق من صحة السلوك المتوقع. [ 23 ]

اختبار التكامل

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

اختبار النظام

اختبار النظام ، المعروف أيضًا باسم اختبار من البداية إلى النهاية (E2E)، هو اختبار يتم إجراؤه على نظام برمجي كامل .

الاختبارات الثابتة والديناميكية والسلبية

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

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

يتضمن الاختبار الثابت التحقق ، بينما يتضمن الاختبار الديناميكي أيضًا التحقق من الصحة . [ 25 ]

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

استكشافي

الاختبار الاستكشافي هو منهج لاختبار البرمجيات يُوصف بإيجاز بأنه تعلم متزامن، وتصميم الاختبار ، وتنفيذه. وقد عرّفه جيم كانر ، الذي صاغ هذا المصطلح عام 1984، [ 27 ] بأنه "أسلوب لاختبار البرمجيات يُركز على الحرية الشخصية ومسؤولية كل مُختبِر في تحسين جودة عمله باستمرار، وذلك من خلال اعتبار التعلم المتعلق بالاختبار، وتصميم الاختبار، وتنفيذه، وتفسير نتائجه أنشطة متكاملة ومتوازية طوال فترة المشروع". [ 28 ]

الاختبار المُعدّ مسبقًا مقابل الاختبار التكيفي

يعتمد نوع استراتيجية الاختبار التي سيتم تنفيذها على ما إذا كان ينبغي تحديد الاختبارات التي سيتم تطبيقها على IUT قبل بدء تنفيذ خطة الاختبار (الاختبار المسبق [ 29 ] ) أو ما إذا كان كل مدخل يتم تطبيقه على IUT يمكن أن يعتمد ديناميكيًا على المخرجات التي تم الحصول عليها أثناء تطبيق الاختبارات السابقة (الاختبار التكيفي [ 30 ] [ 31 ] ).

صندوق أسود/أبيض

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

اختبار الصندوق الأبيض

مخطط اختبار الصندوق الأبيض
مخطط اختبار الصندوق الأبيض

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

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

تشمل التقنيات المستخدمة في اختبار الصندوق الأبيض ما يلي: [ 33 ] [ 35 ]

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

  • تغطية الوظائف ، والتي تقدم تقارير عن الوظائف المنفذة
  • تغطية العبارات ، والتي تُبلغ عن عدد الأسطر التي تم تنفيذها لإكمال الاختبار
  • تغطية القرار ، التي تُبلغ عما إذا كان قد تم تنفيذ كل من الفرع الصحيح والفرع الخاطئ لاختبار معين

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

اختبار الصندوق الأسود

مخطط الصندوق الأسود

يُعرّف اختبار الصندوق الأسود (المعروف أيضًا بالاختبار الوظيفي) بأنه تصميم حالات اختبار دون معرفة تفاصيل التنفيذ، ودون قراءة شفرة المصدر. لا يدرك المختبرون سوى ما يفترض أن يفعله البرنامج، وليس كيفية أدائه. [ 39 ] تشمل أساليب اختبار الصندوق الأسود ما يلي: تجزئة التكافؤ ، وتحليل القيم الحدية ، واختبار جميع الأزواج ، وجداول انتقال الحالة ، واختبار جداول القرار، واختبار التشويش ، والاختبار القائم على النموذج ، واختبار حالات الاستخدام ، والاختبار الاستكشافي ، والاختبار القائم على المواصفات. [ 32 ] [ 33 ] [ 37 ]

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

يمكن استخدام اختبار الصندوق الأسود لأي مستوى من مستويات الاختبار، وإن كان ذلك عادةً لا يتم على مستوى الوحدة. [ 34 ]

اختبار واجهة المكونات

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

الاختبار البصري

يهدف الاختبار المرئي إلى تزويد المطورين بالقدرة على فحص ما كان يحدث عند نقطة فشل البرنامج، وذلك من خلال عرض البيانات بطريقة تُمكّن المطور من العثور بسهولة على المعلومات التي يحتاجها، مع توضيح المعلومات بشكل جليّ. [ 45 ] [ 46 ]

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

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

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

اختبار الصندوق الرمادي

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

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

مع ظهور مفهوم اختبار الصندوق الرمادي، تلاشى هذا "التمييز التعسفي" بين اختبار الصندوق الأسود واختبار الصندوق الأبيض إلى حد ما. [ 34 ]

اختبار التركيب

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

  • يجب على المستخدم اختيار مجموعة متنوعة من الخيارات.
  • يجب تخصيص الملفات والمكتبات التابعة أو تحميلها أو تحديد موقعها.
  • يجب أن تكون تكوينات الأجهزة صالحة.
  • قد تحتاج أنظمة البرمجيات إلى الاتصال للتواصل مع أنظمة برمجيات أخرى. [ 50 ] : 145
  • يجب أن تكون الوثائق الصحيحة والدقيقة والكافية (مثل دليل التثبيت، ودليل المستخدم ، ودليل المرجع السريع، وملف README ، وما إلى ذلك) موجودة ويمكن الوصول إليها. [ 51 ]

اختبار التوافق

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

اختبار الدخان والعقلانية

يحدد اختبار سلامة العقل ما إذا كان من المعقول المضي قدماً في إجراء المزيد من الاختبارات.

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

اختبار الانحدار

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

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

اختبار القبول

اختبار القبول هو اختبار على مستوى النظام لضمان تلبية البرنامج لتوقعات العملاء. [ 53 ] [ 54 ] [ 55 ] [ 56 ]

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

غالباً ما يتم تجميع الاختبارات في هذه المستويات حسب مكان إجرائها في عملية تطوير البرمجيات، أو حسب مستوى خصوصية الاختبار. [ 56 ]

  • اختبار قبول المستخدم (UAT)
  • اختبار القبول التشغيلي (OAT)
  • اختبارات القبول التعاقدية والتنظيمية
  • اختبار ألفا وبيتا

في بعض الأحيان، يتم إجراء اختبار قبول المستخدم (UAT) من قبل العميل، في بيئته وعلى أجهزته الخاصة.

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

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

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

اختبار ألفا

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

اختبار بيتا

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

الاختبار الوظيفي مقابل الاختبار غير الوظيفي

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

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

الاختبار المستمر

الاختبار المستمر هو عملية تنفيذ اختبارات آلية كجزء من مسار تسليم البرمجيات للحصول على تغذية راجعة فورية حول المخاطر التجارية المرتبطة بإصدار برمجي مرشح. [ 61 ] [ 62 ] يشمل الاختبار المستمر التحقق من صحة كل من المتطلبات الوظيفية وغير الوظيفية ؛ ويمتد نطاق الاختبار من التحقق من صحة المتطلبات التصاعدية أو قصص المستخدم إلى تقييم متطلبات النظام المرتبطة بالأهداف التجارية الشاملة. [ 63 ] [ 64 ]

الاختبارات التدميرية

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

اختبار أداء البرمجيات

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

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

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

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

اختبار قابلية الاستخدام

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

اختبار إمكانية الوصول

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

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

معايير مشتركة للامتثال

اختبار الأمان

يُعد اختبار الأمان أمراً ضرورياً للبرامج التي تعالج البيانات السرية لمنع اختراق النظام من قبل المتسللين .

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

التدويل والتوطين

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

يتحقق اختبار العولمة من أن البرنامج مُكيَّف مع ثقافة جديدة، مثل العملات المختلفة أو المناطق الزمنية المختلفة. [ 68 ]

يجب اختبار الترجمة الفعلية إلى اللغات البشرية أيضًا. تشمل إخفاقات التوطين والعولمة المحتملة ما يلي:

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

اختبار التطوير

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

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

اختبار أ/ب

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

الاختبار المتزامن

يقيّم اختبار التزامن سلوك وأداء البرامج والأنظمة التي تستخدم الحوسبة المتزامنة ، وذلك عادةً في ظل ظروف الاستخدام العادية. ومن المشكلات الشائعة التي يكشف عنها هذا النوع من الاختبار حالات الجمود، وحالات التنافس، ومشكلات إدارة الذاكرة/الموارد المشتركة.

اختبار المطابقة أو اختبار النوع

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

اختبار مقارنة المخرجات

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

اختبار الخصائص

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

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

يُعرف اختبار الخصائص أحيانًا باسم "الاختبار التوليدي" أو "اختبار QuickCheck" نظرًا لأنه تم تقديمه ونشره بواسطة مكتبة Haskell QuickCheck . [ 69 ]

اختبار التحول

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

اختبار جهاز الفيديو

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

انتشرت هذه التقنية في تطوير الويب بفضل مكتبة روبي vcr .

اختبار العقود

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

الاختبارات بمساعدة الذكاء الاصطناعي

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

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

وجدت دراسة من الدرجة الثالثة نُشرت في مجلة ACM Computing Surveys (2023) أن أساليب الذكاء الاصطناعي قد طُبقت على نطاق واسع في جميع المراحل الرئيسية لدورة حياة تطوير البرمجيات، وحددت توليد حالات الاختبار، والتنبؤ بالأخطاء، والإصلاح الآلي باعتبارها المجالات الثلاثة الأكثر نشاطًا في أبحاث الاختبار بمساعدة الذكاء الاصطناعي. [ 74 ]

اختبار التحول إلى اليسار

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

أظهرت الأبحاث التجريبية أن اختبار "التحول إلى اليسار" يؤدي إلى انخفاض بنسبة 40-60% في الوقت اللازم لاكتشاف العيوب، وانخفاض بنسبة 75-85% في تكلفة إزالة العيوب عند تحديدها في المراحل المبكرة من التطوير، مقارنةً بالأساليب التقليدية التي يتم فيها تأجيل الاختبار إلى مراحل لاحقة. [ 76 ]

أظهرت دراسة حالة عُرضت في المؤتمر الدولي لإدارة المعلومات والتكنولوجيا (ICIMTech) لعام 2023 أن دمج اختبار "التحول إلى اليسار" في منهجية التطوير الرشيقة على مدار عام واحد قد قلل بشكل ملحوظ من عدد الأخطاء التي تصل إلى مرحلة الإنتاج. [ 77 ]

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

الأدوار

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

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

تشمل الأدوار والمسميات الوظيفية البارزة في مجال اختبار البرمجيات ما يلي: [ 78 ] مدير الاختبار ، قائد فريق الاختبار ، محلل الاختبار ، مصمم الاختبار ، المختبر ، مطور الأتمتة ، ومسؤول الاختبار . [ 79 ]

العمليات

تختلف المنظمات التي تقوم بتطوير البرمجيات في طريقة إجراء الاختبارات، ولكن هناك أنماط مشتركة. [ 2 ]

تطوير الشلالات

في منهجية تطوير البرمجيات المتسلسلة (Waterfall) ، يُجرى الاختبار عادةً بعد اكتمال كتابة الكود، ولكن قبل تسليم المنتج للعميل. [ 80 ] غالبًا ما تؤدي هذه الممارسة إلى استخدام مرحلة الاختبار كفترة احتياطية لتعويض التأخيرات في المشروع، مما يُقلل من الوقت المخصص للاختبار. [ 11 ] : 145-146

يرى البعض أن منهجية الشلال تسمح ببدء الاختبار عند بدء مشروع التطوير، وأن تكون عملية مستمرة حتى انتهاء المشروع. [ 81 ]

التطوير الرشيق

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

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

حتى في المؤسسات التي تفصل الفرق حسب وظائف البرمجة والاختبار، غالباً ما يقوم المبرمجون بإجراء اختبارات الوحدة . [ 84 ]

عملية أخذ العينات

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

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

جودة

التحقق من صحة البرامج والتحقق من صحتها

يُستخدم اختبار البرمجيات بالاقتران مع التحقق والتدقيق : [ 85 ]

  • التحقق: هل قمنا ببناء البرنامج بشكل صحيح؟ (أي، هل يلبي المتطلبات).
  • التحقق: هل قمنا ببناء البرنامج الصحيح؟ (أي، هل تلبي المخرجات احتياجات العميل).

يُستخدم مصطلحا التحقق والتحقق من الصحة بشكل متبادل في هذا المجال؛ كما يشيع استخدام تعريفات متناقضة لهذين المصطلحين. وفقًا لمسرد مصطلحات هندسة البرمجيات القياسي الصادر عن معهد مهندسي الكهرباء والإلكترونيات (IEEE) : [ 12 ] : 80-81

التحقق هو عملية تقييم نظام أو مكون لتحديد ما إذا كانت منتجات مرحلة تطوير معينة تفي بالشروط المفروضة في بداية تلك المرحلة.
التحقق هو عملية تقييم نظام أو مكون أثناء أو في نهاية عملية التطوير لتحديد ما إذا كان يفي بالمتطلبات المحددة.

ووفقًا لمعيار ISO 9000:

التحقق هو تأكيد من خلال الفحص وتقديم أدلة موضوعية على استيفاء المتطلبات المحددة.
التحقق هو تأكيد من خلال الفحص وتقديم أدلة موضوعية على استيفاء متطلبات استخدام أو تطبيق محدد.

وينتج هذا التناقض عن استخدام مفهومي المتطلبات والمتطلبات المحددة ولكن بمعانٍ مختلفة.

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

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

لذلك، عندما يتم تعريف هذه الكلمات بمصطلحات شائعة، يختفي التناقض الظاهر.

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

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

ضمان جودة البرمجيات

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

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

مقاسات

تشمل مقاييس الجودة مواضيع مثل الصحة ، والشمولية، والأمان، ومتطلبات ISO/IEC 9126 مثل القدرة، والموثوقية ، والكفاءة ، وقابلية النقل ، وقابلية الصيانة ، والتوافق، وسهولة الاستخدام .

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

القطع الأثرية

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

خطة الاختبار

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

مصفوفة التتبع

في تطوير البرمجيات ، تُعدّ مصفوفة التتبع (TM) [ 86 ] : 244 وثيقة، عادةً ما تكون على شكل جدول، تُستخدم للمساعدة في تحديد اكتمال العلاقة من خلال ربط أي وثيقتين أساسيتين باستخدام مقارنة علاقة متعددة الأطراف. [ 86 ] : 3-22 ويُستخدم هذا النوع من المصفوفات غالبًا مع المتطلبات عالية المستوى (والتي غالبًا ما تتضمن متطلبات التسويق) والمتطلبات التفصيلية للمنتج، وذلك لربطها بالأجزاء المطابقة من التصميم عالي المستوى ، والتصميم التفصيلي، وخطة الاختبار ، وحالات الاختبار .

حالة اختبار

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

نص الاختبار

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

مجموعة الاختبارات

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

تجهيزات الاختبار أو بيانات الاختبار

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

مجموعة اختبار

يُشار إلى البرامج والأدوات وعينات إدخال البيانات وإخراجها والتكوينات مجتمعة باسم " مجموعة الاختبار" .

تشغيل تجريبي

تُعرَّف عملية الاختبار بأنها مجموعة من حالات الاختبار أو مجموعات الاختبار التي يُنفِّذها المستخدم ويقارن النتائج المتوقعة بالنتائج الفعلية. عند اكتمالها، يُمكن إنشاء تقرير بجميع الاختبارات المنفذة.

الشهادات

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

الجدل

تتضمن بعض أبرز الخلافات المتعلقة باختبار البرمجيات ما يلي :

المنهج الرشيق مقابل المنهج التقليدي
هل ينبغي على المختبرين تعلم العمل في ظل ظروف عدم اليقين والتغيير المستمر، أم ينبغي عليهم السعي نحو "نضج" العملية ؟ اكتسبت حركة الاختبار الرشيق شعبية متزايدة منذ أوائل العقد الأول من القرن الحادي والعشرين، لا سيما في الأوساط التجارية، [ 89 ] [ 90 ] بينما يستخدم مزودو البرامج الحكومية والعسكرية [ 91 ] هذه المنهجية، بالإضافة إلى نماذج الاختبار الأخيرة التقليدية (مثل نموذج الشلال ). [ 92 ]
الاختبار اليدوي مقابل الاختبار الآلي
يرى بعض الكتّاب أن أتمتة الاختبارات مكلفة للغاية مقارنةً بقيمتها، لذا ينبغي استخدامها باعتدال. [ 93 ] ويمكن اعتبار أتمتة الاختبارات وسيلةً لتحديد المتطلبات وتنفيذها. وكقاعدة عامة، كلما كبر حجم النظام وزادت تعقيداته، زاد العائد على الاستثمار في أتمتة الاختبارات. كما يمكن توزيع الاستثمار في الأدوات والخبرات على مشاريع متعددة مع وجود مستوى مناسب من تبادل المعرفة داخل المؤسسة.
هل وجود معيار اختبار البرمجيات ISO 29119 مبرر؟
ظهرت معارضة كبيرة من داخل صفوف مدرسة اختبار البرمجيات القائمة على السياق لمعيار ISO 29119. وقد حاولت جمعيات الاختبار المهنية، مثل الجمعية الدولية لاختبار البرمجيات، سحب المعيار. [ 94 ] [ 95 ]
يصرح بعض الممارسين بأن مجال الاختبار غير جاهز للتصديق.
[ 96 ] لا تشترط أي شهادة معتمدة حاليًا على المتقدم إثبات قدرته على اختبار البرمجيات. ولا تستند أي شهادة إلى مجموعة معارف مقبولة على نطاق واسع. ولا يمكن للشهادة بحد ذاتها قياس إنتاجية الفرد أو مهارته أو معرفته العملية، ولا تضمن كفاءته أو احترافيته كمختبر برمجيات. [ 97 ]
استُخدمت الدراسات لإظهار التكلفة النسبية لإصلاح العيوب
توجد آراء متباينة حول مدى ملاءمة الدراسات المستخدمة لإظهار التكلفة النسبية لإصلاح العيوب اعتمادًا على وقت حدوثها واكتشافها. على سبيل المثال:

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

تكلفة إصلاح العيبتم رصد الوقت
متطلباتبنيانبناءاختبار النظامبعد الإصدار
الوقت قدممتطلبات1×3×5-10×10×10-100×
بنيان–1×10×15×25–100×
بناء––1×10×10-25×

البيانات التي استُخلص منها هذا الجدول شحيحة. يقول لوران بوسافيت في تحليله:

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

لم يستشهد بوهم بأي ورقة بحثية لبيانات شركة TRW، إلا عند كتابته لمجلة "صناعة البرمجيات" عام 2010، حيث استشهد بالمقال الأصلي المنشور عام 1976. توجد دراسة واسعة النطاق أُجريت في شركة TRW في الوقت المناسب لبوهم للاستشهاد بها، لكن تلك الورقة البحثية لا تحتوي على البيانات التي تدعم مزاعمه. [ 99 ]

انظر أيضاً

مراجع

  1. ↑ كانر، سيم (17 نوفمبر 2006). الاختبار الاستكشافي (ملف PDF) . المؤتمر السنوي العالمي لاختبار البرمجيات، معهد ضمان الجودة. أورلاندو، فلوريدا . تم الاطلاع عليه بتاريخ 22 نوفمبر 2014 .
  2. 1 2 بان، جيانتاو (ربيع 1999). "اختبار البرمجيات" (مقرر دراسي). جامعة كارنيجي ميلون . تم الاطلاع عليه بتاريخ 21 نوفمبر 2017 .
  3. 1 2 3 4 كانر، سيم ؛ فالك، جاك؛ نغوين، هونغ كوك (1999). اختبار برامج الحاسوب (الطبعة الثانية ). نيويورك: جون وايلي وأولاده. ISBN  978-0-471-35846-6.
  4. ↑ لايتنر، أندرياس؛ سيوبا، إيلينكا؛ أوريول، مانويل؛ ماير، برتراند ؛ فيفا، أرنو (سبتمبر 2007). تطوير البرمجيات الموجه بالعقود = تطوير البرمجيات الموجه بالاختبار - كتابة حالات الاختبار (ملف PDF) . مؤتمر ESEC/FSE'07: المؤتمر الأوروبي لهندسة البرمجيات وندوة ACM SIGSOFT حول أسس هندسة البرمجيات 2007. دوبروفنيك، كرواتيا . تاريخ الاسترجاع: 8 ديسمبر 2017 .
  5. 1 2 كولاوا، آدم؛ هويزينغا، دوروتا (2007). الوقاية الآلية من العيوب: أفضل الممارسات في إدارة البرمجيات . مطبعة وايلي-جمعية مهندسي الكهرباء والإلكترونيات. ISBN 978-0-470-04212-0.
  6. ↑ كوهن، مايك (2009). النجاح مع منهجية أجايل: تطوير البرمجيات باستخدام سكروم . أديسون-ويسلي بروفيشنال. ISBN 978-0321579362.
  7. ↑ مولينا، أليساندرو (2021). تصميم برمجيات قائمة على الاختبار باستخدام بايثون: كتابة مجموعات اختبار قابلة للتوسع مع احتياجات تطبيقاتك وتعقيدها باستخدام بايثون وPyTest . دار نشر Packt. رقم ISBN 978-1838642655.
  8. ↑ فرنانديز دا كوستا، لوكاس (2021). اختبار تطبيقات جافا سكريبت . مانينغ. ISBN 978-1617297915.
  9. ↑ "الآثار الاقتصادية لعدم كفاية البنية التحتية لاختبار البرمجيات" (ملف PDF) . المعهد الوطني للمعايير والتكنولوجيا . مايو 2002. تم الاطلاع عليه بتاريخ 19 ديسمبر 2017 .
  10. ↑ فاشيشتا، أفيناش؛ خان، عمرانا (أكتوبر 2009). "أفضل 50 مدينة عالمية ناشئة في مجال التعهيد: دراسة عالمية للخدمات - ثولونز" . تم الاطلاع عليه في 25 أكتوبر 2025 .
  11. 1 2 3 مايرز، جلينفورد ج. (1979). فن اختبار البرمجيات . جون وايلي وأولاده. ISBN 978-0-471-04328-7.
  12. 1 2 3 معجم مصطلحات هندسة البرمجيات القياسي لمعهد مهندسي الكهرباء والإلكترونيات، معهد مهندسي الكهرباء والإلكترونيات، 1990، doi : 10.1109/IEEESTD.1990.101064 ، ISBN 978-1-55937-067-7
  13. 1 2 "منهج المستوى التأسيسي لاختبار البرمجيات المعتمد" . المجلس الدولي لمؤهلات اختبار البرمجيات . 31 مارس 2011. القسم 1.1.2. مؤرشف من الأصل (ملف PDF) في 28 أكتوبر 2017. تم الاطلاع عليه في 15 ديسمبر 2017 .
  14. ↑ "منهج المستوى التأسيسي لاختبار البرمجيات المعتمد" (ملف PDF) . المجلس الدولي لمؤهلات اختبار البرمجيات . 1 يوليو 2005. المبدأ 2، القسم 1.3. مؤرشف من الأصل (ملف PDF) في 17 ديسمبر 2008. تم الاطلاع عليه في 15 ديسمبر 2017 .
  15. ↑ راملر، رودولف؛ كوبيتزكي، ثيودوريتش؛ بلاتز، فولفغانغ (17 أبريل 2012). تصميم الاختبارات التوافقية في مجموعة اختبارات TOSCA: الدروس المستفادة والتطبيقات العملية . المؤتمر الدولي الخامس لمعهد مهندسي الكهرباء والإلكترونيات (IEEE) حول اختبار البرمجيات والتحقق من صحتها (ICST). مونتريال، كيبيك، كندا. doi : 10.1109/ICST.2012.142 .
  16. ↑ كانر، سيم؛ باخ، جيمس؛ بيتيكورد، بريت (2001). الدروس المستفادة في اختبار البرمجيات: منهج قائم على السياق . وايلي. ص 31-43 . ISBN  978-0-471-08112-8.
  17. ↑ كولاوا، آدم؛ هويزينغا، دوروتا (2007). الوقاية الآلية من العيوب: أفضل الممارسات في إدارة البرمجيات . مطبعة وايلي-IEEE لجمعية الحاسبات. ص 74. ISBN  978-0-470-04212-0.
  18. ↑ أوكونور، روري ف.؛ أكايا، مارية أوميه؛ كيمانيجي، كرم؛ يلماز، مراد؛ بوث، ألكسندر؛ ميسنارز، ريتشارد (15 أكتوبر 2015). تحسين عمليات الأنظمة والبرمجيات والخدمات: المؤتمر الأوروبي الثاني والعشرون، يوروسبي 2015، أنقرة، تركيا، 30 سبتمبر - 2 أكتوبر 2015. وقائع المؤتمر . سبرينغر. ISBN 978-3-319-24647-5.
  19. ↑ بورك، بيير؛ فيرلي، ريتشارد إي، محرران (2014). "الفصل 5" . دليل إلى مجموعة معارف هندسة البرمجيات . 3.0. جمعية مهندسي الكهرباء والإلكترونيات (IEEE). ISBN 978-0-7695-5166-1تم الاطلاع عليه بتاريخ 2 يناير 2018 .
  20. ↑ بورك، ب.؛ فيرلي، ر. د.، محرران. (2014). "الفصل 4: اختبار البرمجيات" (ملف PDF) . SWEBOK الإصدار 3.0: دليل إلى مجموعة معارف هندسة البرمجيات . IEEE. الصفحات 4-1-4-17. ISBN  978-0-7695-5166-1أُرشف من النسخة الأصلية (PDF) بتاريخ 19 يونيو 2018. تم الاطلاع عليه بتاريخ 13 يوليو 2018 .
  21. ↑ دولي، ج. (2011). تطوير البرمجيات والممارسة المهنية . دار النشر APress. ص 193-194 . ISBN  978-1-4302-3801-0.
  22. ↑ ويغرز، ك. (2013). بناء ثقافة هندسة البرمجيات . أديسون-ويسلي. ص 211-212 . ISBN  978-0-13-348929-3.
  23. ↑ كولاوا، آدم؛ هويزينغا، دوروتا (2007). الوقاية الآلية من العيوب: أفضل الممارسات في إدارة البرمجيات . مطبعة وايلي-IEEE لجمعية الحاسبات. ص 75. ISBN  978-0-470-04212-0.
  24. 1 2 غراهام، د.؛ فان فينيندال، إي؛ إيفانز، آي. (2008). أسس اختبار البرمجيات . التعلم سينجاج. ص 57 – 58. ISBN  978-1-84480-989-9.
  25. 1 2 3 4 أوبركامبف، دبليو إل؛ روي، سي جيه (2010). التحقق والتدقيق في الحوسبة العلمية . مطبعة جامعة كامبريدج. ص 154-155 . ISBN  978-1-139-49176-1.
  26. ↑ لي، د.؛ نيترافالي، أ.ن.؛ سابناني، ك.ك.؛ سوغلا، ب.؛ جون، أ. (1997). "الاختبار السلبي وتطبيقاته في إدارة الشبكات". وقائع المؤتمر الدولي لبروتوكولات الشبكات لعام 1997. جمعية مهندسي الكهرباء والإلكترونيات. ص 113-122 . doi : 10.1109/icnp.1997.643699 . ISBN  978-0-8186-8061-8. S2CID 42596126 . 
  27. ↑ جيم كانر، " دليل تعليمي في الاختبار الاستكشافي " مؤرشف بتاريخ 12-06-2013 في موقع Wayback Machine ، ص 2
  28. ↑ سيم كانر، برنامج تعليمي في الاختبار الاستكشافي مؤرشف في 2013-06-12 في Wayback Machine ، ص. 36.
  29. ↑ لي، د.؛ ياناكاكيس، م. (1996). "مبادئ وأساليب اختبار آلات الحالة المحدودة - دراسة استقصائية" . وقائع معهد مهندسي الكهرباء والإلكترونيات . 84 (8): 1090-1123 . رمز Bibcode : 1996IEEEP..84.1090L . doi : 10.1109/5.533956 .
  30. ↑ بيترينكو، أ.؛ يفتوشينكو، ن. (2011). "الاختبار التكيفي للتطبيقات الحتمية المحددة بواسطة آلات الحالة المحدودة غير الحتمية" . في اختبار البرمجيات والأنظمة: المؤتمر الدولي الثالث والعشرون لمجموعة العمل 6.1 التابعة للاتحاد الدولي لمعالجة المعلومات، ICTSS 2011، باريس، فرنسا، 7-10 نوفمبر . سلسلة محاضرات في علوم الحاسوب. المجلد 7019. سبرينغر برلين هايدلبرغ. الصفحات 162-178 . doi : 10.1007/978-3-642-24580-0_12 . ISBN   978-3-642-24579-4.
  31. ↑ بيترينكو، أ.؛ يفتوشينكو، ن. (2014). "الاختبار التكيفي للأنظمة غير الحتمية باستخدام آلة الحالة المحدودة". في ندوة IEEE الدولية الخامسة عشرة لهندسة الأنظمة عالية الموثوقية لعام 2014. IEEE. ص 224-228 . doi : 10.1109/HASE.2014.39 . ISBN  978-1-4799-3466-9.
  32. 1 2 3 4 ليماي، إم جي (2009). اختبار البرمجيات . دار تاتا ماكجرو هيل للتعليم. الصفحات 108-111 . ISBN  978-0-07-013990-9.
  33. 1 2 3 4 صالح، كا (2009). هندسة البرمجيات . جيه روس للنشر. ص 224 – 41. ISBN  978-1-932159-94-3.
  34. 1 2 3 أمان، ب.؛ أوفوت، ج. (2016). مقدمة في اختبار البرمجيات . مطبعة جامعة كامبريدج. ص 26. ISBN  978-1-316-77312-3.
  35. ↑ إيفرات، جي دي؛ ماكلويد الابن، آر. (2007). "الفصل 7: الاختبار الوظيفي". اختبار البرمجيات: الاختبار عبر دورة حياة تطوير البرمجيات بأكملها . جون وايلي وأولاده. ص 99-121 . ISBN  978-0-470-14634-7.
  36. 1 2 كورنيت، ستيف (حوالي 1996). "تحليل تغطية الكود" . تقنية اختبار بولز آي. مقدمة . تم الاسترجاع في 21 نوفمبر 2017 .
  37. 1 2 بلاك، ر. (2011). اختبار البرمجيات العملي: كيف تصبح محترف اختبار فعال وكفؤ . جون وايلي وأولاده. ص 44-46 . ISBN  978-1-118-07938-6.
  38. ↑ كمثال بسيط،دالة C من عبارة واحدة فقط. ستنجحجميع الاختبارات التي تُجرى على المواصفاتتم اختيارها بالصدفة.intf(intx){returnx*x-6*x+8;}f(x)>=0x=3
  39. ↑ باتون، رون (2005). اختبار البرمجيات ( الطبعة الثانية). إنديانابوليس: دار سامز للنشر. ISBN  978-0-672-32798-8.
  40. ↑ لايكوك، جيلبرت ت. (1993). نظرية وممارسة اختبار البرمجيات القائم على المواصفات (ملف PDF) (أطروحة دكتوراه). قسم علوم الحاسوب، جامعة شيفيلد . تم الاطلاع عليه في 2 يناير 2018 .
  41. ↑ باخ، جيمس (يونيو 1999). "الاختبار القائم على المخاطر والمتطلبات" (ملف PDF) . مجلة الكمبيوتر . 32 (6): 113-114 . تم الاطلاع عليه بتاريخ 19 أغسطس 2008 .
  42. ↑ ماثور، أ.ب. (2011). أسس اختبار البرمجيات . بيرسون للتعليم الهند. ص 63. ISBN  978-81-317-5908-0.
  43. 1 2 كلاب، جوديث أ. (1995). مراقبة جودة البرمجيات، وتحليل الأخطاء، والاختبار . ويليام أندرو. ص 313. ISBN  978-0-8155-1363-6تم الاطلاع عليه بتاريخ 5 يناير 2018 .
  44. ↑ ماثور، أديتيا ب. (2007). أسس اختبار البرمجيات . بيرسون للتعليم الهند. ص 18. ISBN  978-81-317-1660-1.
  45. ↑ لونبيرغ، يان (7 أكتوبر 2003). الاختبار البصري للبرمجيات (ملف PDF) (رسالة ماجستير). جامعة هلسنكي للتكنولوجيا . تم الاطلاع عليه في 13 يناير 2012 .
  46. ↑ شيما، راسبال. "الاختبار البصري" . مجلة TEST . مؤرشف من الأصل في 24 يوليو 2012. تم الاطلاع عليه في 13 يناير 2012 .
  47. 1 2 3 لويس، دبليو إي (2016). اختبار البرمجيات والتحسين المستمر للجودة ( الطبعة الثالثة). مطبعة سي آر سي. الصفحات 68-73 . ISBN   978-1-4398-3436-7.
  48. 1 2 رانسوم، ج.؛ ميسرا، أ. (2013). أمن البرمجيات الأساسية: الأمن من المصدر . مطبعة سي آر سي. ص 140-143 . ISBN  978-1-4665-6095-6.
  49. ↑ "أدوات اختبار بنية الخدمات الموجهة (SOA) للصناديق السوداء والبيضاء والرمادية" (ورقة بيضاء). كروس تشيك نتوركس. مؤرشف من الأصل في 1 أكتوبر 2018. تم الاطلاع عليه في 10 ديسمبر 2012 .
  50. 1 2 مايرز، ج. (2004). ساندلر، سي؛ بادجيت، تي؛ توماس، إم. (محررون). فن اختبار البرمجيات ( الطبعة الثانية). وايلي. ISBN  9780471469124.
  51. ↑ كانر، سيم؛ فالك، جاك؛ نغوين، هونغ كيو. (1999). اختبار برامج الحاسوب ( الطبعة الثانية). وايلي. ISBN  0471358460.
  52. ↑ أمان، بول؛ أوفوت، جيف (28 يناير 2008). مقدمة في اختبار البرمجيات . مطبعة جامعة كامبريدج . ص 215. ISBN  978-0-521-88038-1تم الاطلاع عليه بتاريخ 29 نوفمبر 2017 .
  53. 1 2 3 لويس، دبليو إي (2016). اختبار البرمجيات والتحسين المستمر للجودة ( الطبعة الثالثة). مطبعة سي آر سي. الصفحات 92-96 . ISBN   978-1-4398-3436-7.
  54. ↑ ماتشادو، ب.؛ فينسينزي، أ.؛ مالدونادو، ج. س. (2010). "الفصل 1: اختبار البرمجيات: نظرة عامة" . في: بوربا، ب.؛ كافالكانتي، أ.؛ سامبايو، أ.؛ وودكوك، ج. (محررون). تقنيات الاختبار في هندسة البرمجيات . سبرينغر ساينس آند بيزنس ميديا. ص 13-14 . ISBN  978-3-642-14334-2.
  55. ↑ كلاب، جيه إيه؛ ستانتن، إس إف؛ بينغ، دبليو دبليو؛ وآخرون . (1995). مراقبة جودة البرمجيات، وتحليل الأخطاء، والاختبار . شركة نوفا داتا. ص 254. ISBN   978-0-8155-1363-6.
  56. 1 2 3 "منهج ISTQB CTFL لعام 2018" (ملف PDF) . ISTQB - المجلس الدولي لمؤهلات اختبار البرمجيات . مؤرشف (ملف PDF) من الأصل بتاريخ 24 مارس 2022. تم الاطلاع عليه بتاريخ 11 أبريل 2022 .
  57. ↑ ليسكين، أولغا؛ هيرمان، كريستوف؛ كناوس، إريك؛ كوربيك، توماس؛ رومبي، برنارد؛ شنايدر، كورت (2012). "دعم اختبار القبول في مشاريع البرمجيات الموزعة باستخدام أنظمة التغذية الراجعة المتكاملة: الخبرات والمتطلبات". المؤتمر الدولي السابع لهندسة البرمجيات العالمية IEEE لعام 2012. الصفحات 84-93 . arXiv : 1409.0402 . doi : 10.1109/ICGSE.2012.34 . 
  58. ↑ وودز، أنتوني ج. (5 يونيو 2015). "القبول التشغيلي - تطبيق معيار اختبار البرمجيات ISO 29119" (ورقة بيضاء). كابجيميني أستراليا . تم الاطلاع عليه في 9 يناير 2018 .
  59. ↑ "المعجم القياسي للمصطلحات المستخدمة في اختبار البرمجيات" (ملف PDF) . الإصدار 3.1. المجلس الدولي لمؤهلات اختبار البرمجيات . تم الاطلاع عليه بتاريخ 9 يناير 2018 .
  60. ↑ أورايلي، تيم (30 سبتمبر 2005). "ما هو ويب 2.0؟" . أورايلي ميديا. القسم 4. نهاية دورة إصدار البرمجيات . تم الاطلاع عليه في 11 يناير 2018 .
  61. ↑ أورباخ، آدم (3 أغسطس 2015). "جزء من خط الأنابيب: لماذا يُعد الاختبار المستمر ضروريًا" . رؤى تيك ويل . شركة تيك ويل . تم الاطلاع عليه في 12 يناير 2018 .
  62. ↑ فيليب-إدموندز، كاميرون (5 ديسمبر 2014). "العلاقة بين المخاطرة والاختبار المستمر: مقابلة مع واين أريولا" . ستيكي مايندز . تم الاطلاع عليه في 16 يناير 2018 .
  63. ↑ أريولا، واين؛ دنلوب، سينثيا (أكتوبر 2015). ديف أوبس: هل تُسرّع من إرسال الأخطاء إلى العملاء؟ (ملف PDF) . مؤتمر جودة البرمجيات في شمال غرب المحيط الهادئ. مؤرشف من الأصل (ملف PDF) في 14 فبراير 2025. تم الاطلاع عليه في 16 يناير 2018 .
  64. ↑ أورباخ، آدم (2 أكتوبر 2014). "التحول إلى اليسار ووضع الجودة في المقام الأول" . رؤى تيك ويل . شركة تيك ويل . تم الاطلاع عليه في 16 يناير 2018 .
  65. ↑ ميلر، بارتون ب.؛ فريدريكسن، لارس؛ سو، برايان (1990). "دراسة تجريبية لموثوقية أدوات يونكس". اتصالات رابطة مكائن ​​الحوسبة . 33 (12): 32-44 . doi : 10.1145/96267.96279 .
  66. ↑ تقي، فروة؛ بتول، سيدة هينا؛ أرشد، علياء (23 مايو 2024). "تطوير والتحقق من صحة مقياس تطوير سهولة استخدام تطبيقات الحوسبة السحابية" . المجلة الدولية للتفاعل بين الإنسان والحاسوب . 41 (7): 4376-4391 . doi : 10.1080/10447318.2024.2351715 . ISSN 1044-7318 . 
  67. ↑ "القسم 4.38". ISO/IEC/IEEE 29119-1:2013 – هندسة البرمجيات والأنظمة – اختبار البرمجيات – الجزء 1 – المفاهيم والتعريفات . المنظمة الدولية للتوحيد القياسي . تم الاطلاع عليه بتاريخ 17 يناير 2018 .
  68. ↑ "العولمة خطوة بخطوة: منهج الاختبار الجاهز للعالم. شبكة مطوري مايكروسوفت" . شبكة مطوري مايكروسوفت. مؤرشف من الأصل في 23 يونيو 2012. تم الاطلاع عليه في 13 يناير 2012 .
  69. ↑ كلايسن، كوين؛ هيوز، جون (2000). "QuickCheck" . وقائع المؤتمر الدولي الخامس لجمعية ACM SIGPLAN حول البرمجة الوظيفية . ICFP '00. الصفحات 268-279 . doi : 10.1145/351240.351266 . ISBN  978-1-58113-202-1. S2CID 5668071 . 
  70. ↑ "ما هو اختبار العقود وأهميته؟" . BrowserStack . تم الاطلاع عليه في 15 نوفمبر 2025 .
  71. ↑ فاولر، مارتن. "bliki: اختبار العقد" . martinfowler.com . تم الاطلاع عليه بتاريخ 15 نوفمبر 2025 .
  72. ↑ باقر، محمد؛ خاندا، راجات (2025). الحوسبة الذكية . سلسلة محاضرات في الشبكات والأنظمة. المجلد 1424. arXiv : 2409.05808 . doi : 10.1007/978-3-031-92605-1 . ISBN  978-3-031-92604-4.
  73. ^ ريكا، فيليبو؛ ماركيتو، أليساندرو؛ ستوكو ، أندريا (12 أغسطس 2024). “مراجعة الأدبيات الرمادية المتعددة السنوات حول أتمتة الاختبار بمساعدة الذكاء الاصطناعي”. أرخايف : 2408.06224 [ cs.SE ].
  74. ^ أمالفيتانو، دومينيكو؛ فارالي، ستيفانو؛ هوك، جان كارلو روسا؛ ماتالونجا، سانتياغو؛ بعيد ، داميانو (2023). “الذكاء الاصطناعي المطبق على اختبار البرمجيات: دراسة جامعية”. مسوحات الحوسبة ACM . 56 (3): 1– 38. دوى : 10.1145/3616372 . اتش دي ال : 11573/1689760 .
  75. ↑ سميث، لاري (سبتمبر 2001). "اختبار التحول إلى اليسار" . مجلة دكتور دوب . 26 (9): 56 وما بعدها . تم الاطلاع عليه في 19 يونيو 2026 .
  76. ↑ "تطبيق نموذج Shift Left: تأثيره على جودة البرمجيات وكفاءة الاختبار" . 25 يوليو 2025. تم الاطلاع عليه في 19 يونيو 2026 .
  77. ↑ أندريادي، كوس؛ سوبارنو، هاريونو؛ غاول، فورد لومبان؛ أريفين، يولياني (2023). "أثر اختبار التحول إلى اليسار على جودة البرمجيات في منهجية أجايل: دراسة حالة". المؤتمر الدولي لإدارة المعلومات والتكنولوجيا 2023 (ICIMTech) . الصفحات 259-264 . Bibcode : 2023cimt.conf...56A . doi : 10.1109/ICIMTech59029.2023.10277919 . ISBN  979-8-3503-2609-3. S2CID 264294801 . 
  78. ↑ جيلبرين، ديفيد ؛ هيتزل، بيل (1 يونيو 1988). "نمو اختبار البرمجيات" . اتصالات رابطة آلات الحوسبة . 31 (6): 687-695 . doi : 10.1145/62959.62965 . S2CID 14731341 . 
  79. ↑ غريغوري، جانيت؛ كريسبين، ليزا (2014). المزيد من اختبارات أجايل . أديسون-ويسلي بروفيشنال. ص 23-39 . ISBN  978-0-13-374956-4.
  80. ↑ "دورة حياة اختبار البرمجيات" . etestinghub . مرحلة الاختبار في اختبار البرمجيات . تم الاطلاع عليه في 13 يناير 2012 .
  81. ↑ داستن، إلفرايد (2002). اختبار البرمجيات الفعال . أديسون-ويسلي بروفيشنال. ص 3. ISBN  978-0-201-79429-8.
  82. 1 2 "ما هو تطوير البرمجيات الموجه بالاختبار (TDD)؟" . تحالف أجايل . 5 ديسمبر 2015. تم الاطلاع عليه في 17 مارس 2018 .
  83. ↑ "التطوير القائم على الاختبار والتكامل المستمر لتطبيقات الجوال" . شبكة مطوري مايكروسوفت . 14 يناير 2009. تم الاطلاع عليه في 17 مارس 2018 .
  84. ↑ براون، كريس؛ كوب، غاري؛ كولبرتسون، روبرت (12 أبريل 2002). مقدمة في اختبار البرمجيات السريع .
  85. ↑ تران، يوشيوان (1999). "التحقق/التصديق/الاعتماد" (مقرر دراسي). جامعة كارنيجي ميلون . تم الاطلاع عليه بتاريخ 13 أغسطس 2008 .
  86. 1 2 غوتيل، أورلينا؛ كليلاند-هوانغ، جين ؛ هايز، جين هوفمان؛ زيسمان، أندريا؛ إيغيد، ألكسندر؛ غرونباخر، بول؛ ديختيار، أليكس؛ أنطونيول، جوليانو؛ ماليتيك، جوناثان (1 يناير 2012). كليلاند-هوانغ، جين؛ غوتيل، أورلينا؛ زيسمان، أندريا (محررون). تتبع البرمجيات والأنظمة . سبرينغر لندن. doi : 10.1007/978-1-4471-2239-5_1 . ISBN 9781447122388.
  87. ↑ معهد مهندسي الكهرباء والإلكترونيات (1998). معيار معهد مهندسي الكهرباء والإلكترونيات لتوثيق اختبار البرمجيات . نيويورك: معهد مهندسي الكهرباء والإلكترونيات. رقم ISBN 978-0-7381-1443-9.
  88. ↑ بينتو، لياندرو ساليس؛ سينها، سوراب؛ أورسو، أليساندرو (11 نوفمبر 2012). "فهم أساطير وحقائق تطور مجموعات الاختبار" . وقائع ندوة ACM SIGSOFT الدولية العشرين حول أسس هندسة البرمجيات . رابطة آلات الحوسبة. الصفحات 1-11 . doi : 10.1145/2393596.2393634 . ISBN  9781450316149. S2CID 9072512 . 
  89. ↑ ستروم، ديفيد (1 يوليو 2009). "كلنا جزء من القصة" . تعاونية اختبار البرمجيات والأداء. مؤرشف من الأصل في 31 أغسطس 2009.
  90. ↑ غريفيث، م. (2005). "تدريس إدارة المشاريع الرشيقة لمعهد إدارة المشاريع". مؤتمر التطوير الرشيق (ADC'05) . ieee.org. ص 318-322 . doi : 10.1109/ADC.2005.45 . ISBN  978-0-7695-2487-0. S2CID 30322339 . 
  91. ↑ ويليسون، جون س. (أبريل 2004). "تطوير البرمجيات الرشيقة لقوة رشيقة" . كروس توك (أبريل 2004). مركز علوم وتكنولوجيا البرمجيات. مؤرشف من الأصل في 29 أكتوبر 2005.
  92. ↑ بيرغ، هيلين؛ ريتشل، جوناثان د. (يوليو 2023). "خصائص مشاريع تكنولوجيا المعلومات العسكرية الناجحة: دراسة تجريبية عبر الدول" . المجلة الدولية لنظم المعلومات وإدارة المشاريع . 11 (2): 25-44 . doi : 10.12821/ijispm110202 . ISSN 2182-7788 . 
  93. ↑ مثال على ذلك: مارك فيوستر، دوروثي غراهام: أتمتة اختبار البرمجيات. أديسون ويسلي، 1999، رقم ISBN 978-0-201-33140-0.
  94. ↑ "stop29119" . commonsensetesting.org . مؤرشف من الأصل في 2 أكتوبر 2014.
  95. ↑ بول كريل (22 أغسطس 2014). "مختبرو البرمجيات يترددون في قبول مقترح معايير ISO 29119" . إنفو وورلد .
  96. ↑ كانر، سيم (2001). "مقترح منحة من المؤسسة الوطنية للعلوم لـ "وضع أساس لتحسينات كبيرة في جودة الدورات الأكاديمية والتجارية في اختبار البرمجيات"( ملف PDF) . مؤرشف من النسخة الأصلية (ملف PDF) بتاريخ 27 نوفمبر 2009. تم الاطلاع عليه بتاريخ 13 أكتوبر 2006 .
  97. ↑ كانر، سيم (2003). قياس فعالية مختبري البرمجيات (ملف PDF) . ستار إيست. مؤرشف من الأصل (ملف PDF) في 26 مارس 2010. تم الاطلاع عليه في 18 يناير 2018 .
  98. ↑ ماكونيل ، ستيف (2004). كود كومبليت ( الطبعة الثانية). مطبعة مايكروسوفت. ص 29. ISBN   978-0-7356-1967-8.
  99. ↑ بوسافيت، لوران (20 نوفمبر 2013). "تكلفة العيوب: تاريخ مصور". أساطير هندسة البرمجيات: كيف تتحول الخرافات إلى حقائق وماذا نفعل حيال ذلك . دار نشر لين.

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