20. التحقق وإصدار الشهادات برمجة
يعد التحقق والتحقق من الصحة بمثابة عمليات الاختبار والمراجعة التي تتحقق من أن البرنامج يلبي مواصفاته ومتطلبات العملاء. يغطي التحقق والشهادة كاملاً دورة الحياةالبرمجيات - تبدأ في مرحلة تحليل المتطلبات وتنتهي بالتحقق من رمز البرنامج في مرحلة اختبار نظام البرنامج النهائي.
التحقق والشهادة ليسا نفس الشيء، على الرغم من أنه من السهل الخلط بينهما. وباختصار يمكن تحديد الفرق بينهما على النحو التالي:
يجيب التحقق على سؤال ما إذا كان النظام قد تم إنشاؤه بشكل صحيح؛
تجيب الشهادة على سؤال ما إذا كان النظام يعمل بشكل صحيح.
وفقًا لهذه التعريفات، يتحقق التحقق من امتثال البرنامج لمواصفات النظام، ولا سيما المتطلبات الوظيفية وغير الوظيفية. الشهادة هي عملية أكثر عمومية. أثناء عملية الاعتماد، من الضروري التأكد من أن منتج البرنامج يلبي توقعات العميل. تتبع الشهادة التحقق لتحديد مدى تلبية النظام ليس فقط للمواصفات، ولكن أيضًا لتوقعات العميل.
كما ذكرنا سابقًا، في المراحل الأولى من تطوير البرمجيات، تعد شهادة متطلبات النظام أمرًا مهمًا للغاية. الأخطاء والسهو شائعة في المتطلبات؛ وفي مثل هذه الحالات، من المحتمل ألا يلبي المنتج النهائي توقعات العميل. لكن بالطبع، لا يمكن للتحقق من صحة المتطلبات تحديد جميع المشكلات الموجودة في مواصفات المتطلبات. في بعض الأحيان يتم اكتشاف أوجه القصور والأخطاء في المتطلبات فقط بعد اكتمال تنفيذ النظام.
تستخدم عمليات التحقق وإصدار الشهادات تقنيتين رئيسيتين للتحقق من الأنظمة وتحليلها.
1. فحص البرمجيات.تحليل تمثيلات النظام المختلفة والتحقق منها، مثل وثائق مواصفات المتطلبات أو المخططات المعمارية أو كود مصدر البرنامج. يتم إجراء الفحص في جميع مراحل عملية تطوير نظام البرمجيات. بالتوازي مع التفتيش، يمكن إجراء التحليل التلقائي للكود المصدري للبرنامج والوثائق ذات الصلة. يعد الفحص والتحليل الآلي من طرق التحقق والتحقق الثابتة لأنها لا تتطلب نظامًا قابلاً للتنفيذ.
2. اختبار البرمجيات.قم بتشغيل التعليمات البرمجية القابلة للتنفيذ مع بيانات الاختبار وفحص خصائص الإخراج والأداء منتج برمجيللتحقق من التشغيل الصحيح للنظام. يعد الاختبار طريقة ديناميكية للتحقق وإصدار الشهادات حيث يتم تطبيقه على نظام قيد التشغيل.
في التين. يوضح الشكل 20.1 مكان الفحص والاختبار في عملية تطوير البرمجيات. تشير الأسهم إلى مراحل عملية التطوير التي يمكن تطبيق هذه الأساليب فيها. وفقًا لهذا المخطط، يمكن إجراء الفحص في جميع مراحل عملية تطوير النظام، ويمكن إجراء الاختبار في الحالات التي يتم فيها إنشاء نموذج أولي أو برنامج قابل للتنفيذ.
تتضمن طرق الفحص ما يلي: فحص البرنامج، والتحليل التلقائي لشفرة المصدر، والتحقق الرسمي. لكن الأساليب الثابتة يمكنها فقط التحقق من امتثال البرامج للمواصفات، ولا يمكن استخدامها للتحقق من الأداء الصحيح للنظام. بالإضافة إلى ذلك، لا يمكن التحقق من الخصائص غير الوظيفية مثل الأداء والموثوقية باستخدام الطرق الثابتة. لذلك، لتقييم الخصائص غير الوظيفية، يتم إجراء اختبار النظام.
أرز. 20.1. التحقق وإصدار الشهادات الثابتة والديناميكية
على الرغم من الاستخدام الواسع النطاق لفحص البرمجيات، لا يزال الاختبار هو الطريقة السائدة للتحقق وإصدار الشهادات. الاختبار هو اختبار تشغيل البرامج ببيانات مشابهة للبيانات الحقيقية التي ستتم معالجتها أثناء تشغيل النظام. يتم الكشف عن وجود العيوب وعدم المطابقة في البرنامج من خلال فحص بيانات المخرجات وتحديد الشذوذ منها. يتم إجراء الاختبار في مرحلة تنفيذ النظام (للتأكد من أن النظام يلبي توقعات المطورين) وبعد الانتهاء من تنفيذه.
في مراحل مختلفة من عملية تطوير البرمجيات يستخدمونها أنواع مختلفةاختبارات.
1. اختبار العيوبيتم إجراؤها لاكتشاف التناقضات بين البرنامج ومواصفاته والتي تنتج عن أخطاء أو عيوب في البرامج. تم تصميم هذه الاختبارات لتحديد الأخطاء في النظام، وليس لمحاكاة تشغيله.
2. الاختبارات الإحصائيةيقيم أداء وموثوقية البرامج، وكذلك تشغيل النظام في أوضاع التشغيل المختلفة. تم تصميم الاختبارات لمحاكاة تشغيل النظام الحقيقي باستخدام بيانات الإدخال الحقيقية. يتم تقييم موثوقية النظام من خلال عدد حالات الفشل التي لوحظت في تشغيل البرامج. يتم تقييم الأداء من خلال قياس إجمالي وقت تنفيذ العمليات ووقت استجابة النظام عند معالجة بيانات الاختبار.
الغرض الرئيسي من التحقق والتأهيل هو التأكد من أن النظام "مناسب للغرض". إن امتثال نظام برمجي للغرض المقصود منه لا يعني أنه يجب أن يكون خاليًا تمامًا من الأخطاء. وبدلاً من ذلك، يجب أن يخدم النظام بشكل معقول الأغراض التي تم تصميمه من أجلها. المستوى المطلوب موثوقية الامتثاليعتمد ذلك على الغرض من النظام وتوقعات المستخدم وظروف سوق البرمجيات.
1. الغرض من البرنامج.يعتمد مستوى الثقة في الامتثال على مدى أهمية البرنامج الذي يتم تطويره وفقًا لمعايير معينة. على سبيل المثال، ينبغي أن يكون مستوى الثقة في الأنظمة ذات الأهمية الحيوية للسلامة أعلى بكثير من نفس مستوى الثقة في النماذج الأولية أنظمة البرمجيات، يجري تطويرها لإظهار بعض الأفكار الجديدة.
2. توقعات المستخدم.ومن المحزن أن نلاحظ أن معظم المستخدمين حاليًا لديهم متطلبات برمجية منخفضة. لقد اعتاد المستخدمون على حالات الفشل التي تحدث أثناء تشغيل البرامج بحيث لا يتفاجأون بذلك. إنهم على استعداد لتحمل فشل النظام إذا كانت فوائد استخدامه تفوق العيوب. ومع ذلك، منذ أوائل التسعينيات، بدأ تناقص تحمل المستخدم للفشل في أنظمة البرمجيات تدريجيًا. في الآونة الأخيرة، أصبح إنشاء أنظمة غير موثوقة غير مقبول عمليا، لذلك تحتاج الشركات التي تقوم بتطوير منتجات البرمجيات إلى إيلاء المزيد والمزيد من الاهتمام للتحقق من البرامج وإصدار الشهادات لها.
3. ظروف سوق البرمجيات.عند تقييم نظام برمجي، يجب على البائع معرفة الأنظمة المنافسة، والسعر الذي يرغب المشتري في دفعه مقابل النظام، والتاريخ المستهدف لإصدار النظام إلى السوق. إذا كان لدى شركة التطوير العديد من المنافسين، فمن الضروري تحديد موعد دخول النظام إلى السوق قبل نهاية الاختبار الكامل وتصحيح الأخطاء، وإلا فقد يكون المنافسون أول من يدخل السوق. إذا كان العملاء غير راغبين في شراء البرامج بسعر مرتفع، فقد يكونون على استعداد لتحمل المزيد من حالات فشل النظام. ويجب أن تؤخذ كل هذه العوامل في الاعتبار عند تحديد تكاليف عملية التحقق وإصدار الشهادات.
كقاعدة عامة، أثناء التحقق وإصدار الشهادات، يتم اكتشاف الأخطاء في النظام. يتم إجراء تغييرات على النظام لتصحيح الأخطاء. هذا عملية التصحيحيتم دمجها عادةً مع عمليات التحقق والتأهيل الأخرى. ومع ذلك، فإن الاختبار (أو بشكل عام، التحقق وإصدار الشهادات) وتصحيح الأخطاء هما عمليتان مختلفتان ولهما أهداف مختلفة.
1. التحقق والشهادة هي عملية اكتشاف العيوب في نظام البرمجيات.
2. تصحيح الأخطاء هو عملية تحديد العيوب (الأخطاء) وتصحيحها (الشكل 20.2).
أرز. 20.2. عملية التصحيح
لا توجد طرق بسيطة لتصحيح أخطاء البرامج. يكتشف مصححو الأخطاء ذوو الخبرة الأخطاء من خلال مقارنة أنماط مخرجات الاختبار مع مخرجات الأنظمة قيد الاختبار. يتطلب تحديد موقع الخطأ معرفة أنواع الأخطاء وأنماط الإخراج ولغة البرمجة وعملية البرمجة. المعرفة حول عملية تطوير البرمجيات مهمة جدًا. يعرف مصححو الأخطاء أخطاء المبرمجين الأكثر شيوعًا (على سبيل المثال، الأخطاء المرتبطة بزيادة قيمة العداد). تؤخذ أيضًا في الاعتبار الأخطاء النموذجية لبعض لغات البرمجة، على سبيل المثال تلك المرتبطة باستخدام المؤشرات في لغة C.
إن تحديد موقع الأخطاء في رمز البرنامج ليس دائمًا عملية سهلة لأن الخطأ لا يقع بالضرورة بالقرب من المكان الذي حدثت فيه المشكلة في رمز البرنامج. لتوطين الأخطاء، يقوم مبرمج مصحح الأخطاء بتطوير اختبارات برمجية إضافية تساعد في تحديد مصدر الخطأ في البرنامج. قد يكون من الضروري تتبع تنفيذ البرنامج يدويًا.
تعد أدوات تصحيح الأخطاء التفاعلية جزءًا من مجموعة أدوات دعم اللغة المدمجة مع نظام تجميع التعليمات البرمجية. أنها توفر بيئة تنفيذ خاصة للبرنامج يمكن من خلالها الوصول إلى جدول المعرفات، ومن هناك، إلى القيم المتغيرة. غالبًا ما يتحكم المستخدمون في تنفيذ البرنامج بطريقة خطوة بخطوة، وينتقلون بالتسلسل من عبارة إلى أخرى. بعد تنفيذ كل عبارة، يتم فحص قيم المتغيرات وتحديد الأخطاء المحتملة.
يتم تصحيح الخطأ المكتشف في البرنامج، وبعد ذلك من الضروري التحقق من البرنامج مرة أخرى. للقيام بذلك، يمكنك فحص البرنامج مرة أخرى أو تكرار الاختبار السابق. يتم استخدام إعادة الاختبار للتأكد من أن التغييرات التي تم إجراؤها على البرنامج لم تسبب أخطاء جديدة في النظام، لأنه في الممارسة العملية فإن نسبة عالية من "إصلاحات الأخطاء" إما تفشل تمامًا أو تقدم أخطاء جديدة في البرنامج.
من حيث المبدأ، أثناء إعادة الاختبار بعد كل إصلاح، يجب إجراء جميع الاختبارات مرة أخرى، ولكن في الممارسة العملية يعد هذا الأسلوب مكلفًا للغاية. لذلك، عند التخطيط لعملية اختبار، يتم تحديد التبعيات بين أجزاء النظام وتعيين اختبارات لكل جزء. ومن الممكن بعد ذلك تتبع عناصر البرنامج باستخدام حالات اختبار خاصة (بيانات اختبار) مصممة خصيصًا لتلك العناصر. إذا تم توثيق نتائج التتبع، فيمكن استخدام مجموعة فرعية فقط من مجموعة بيانات الاختبار بأكملها لاختبار عنصر البرنامج الذي تم تغييره ومكوناته التابعة.
الغرض من هذه الدورة هو تقديم نظرة شاملة لعملية التحقق من البرمجيات. موضوع المناقشة هو مختلف الأساليب والأساليب المستخدمة في مجال التحقق، وعلى وجه الخصوص، اختبار البرمجيات. من المفترض أن البرنامج الذي يتم تطويره هو جزء من المزيد النظام المشترك. يتضمن هذا النظام أجهزة ومعلومات ومكونات تنظيمية (مستخدم بشري، مشغل بشري، إلخ)، ربما تم تطويرها بواسطة فرق مختلفة. ولذلك، هناك حاجة إلى وثائق التطوير التي تحدد متطلبات المكونات المختلفة للنظام وقواعد تفاعلها. بالإضافة إلى ذلك، من المفترض أن فشل النظام يمكن أن يؤدي إلى عواقب خطيرة أو أخرى، لذلك أثناء تطوير البرمجيات، تكون الجهود المبذولة لتحديد العيوب المخفية ضرورية ومبررة. يتعلق هذا أولاً بأدوات وإجراءات التحقق من البرامج. تشتمل الدورة على عدد من التمارين العملية التي توضح، باستخدام نظام بسيط كمثال، تقنيات وأساليب التحقق من البرامج في بيئة Microsoft Visual Studio 2005 Team Edition لمختبري البرامج. يعد هذا المنشور جزءًا من مكتبة المقررات الدراسية، والتي يتم تطويرها كجزء من برنامج التعاون الأكاديمي التابع لـ MSDN Academic Alliance (MSDN AA).
يتم الحصول على النص أدناه عن طريق الاستخراج التلقائي من مستند PDF الأصلي وهو مخصص للمعاينة.
لا توجد صور (صور، صيغ، رسوم بيانية).
أرز. 7 الاختبار والتحقق والتحقق من صحة التحقق من البرامج هو مفهوم أكثر عمومية من الاختبار. الغرض من التحقق هو التأكد من أن العنصر الذي يتم التحقق منه (المتطلبات أو رمز البرنامج) يلبي المتطلبات، ويتم تنفيذه دون وظائف غير مقصودة، ويلبي مواصفات ومعايير التصميم. تتضمن عملية التحقق عمليات التفتيش واختبار الكود وتحليل نتائج الاختبار وإنشاء تقارير المشكلات وتحليلها. وبالتالي، فمن المقبول عمومًا أن تكون عملية الاختبار جزءًا لا يتجزأ من عملية التحقق، ويتم وضع نفس الافتراض في هذه الدورة التدريبية. التحقق من صحة النظام البرمجي هو عملية تهدف إلى إثبات أننا، نتيجة لتطوير النظام، قد حققنا الأهداف التي خططنا لتحقيقها من خلال استخدامه. بمعنى آخر، التحقق من الصحة هو التحقق من أن النظام يلبي توقعات العميل. القضايا المتعلقة بالتحقق هي خارج نطاق هذا دورة تدريبيةوتمثل موضوعًا منفصلاً مثيرًا للاهتمام للدراسة. إذا نظرت إلى هذه العمليات الثلاث من حيث السؤال الذي تجيب عليه، فإن الاختبار يجيب على السؤال "كيف يتم ذلك؟" أو "هل سلوك البرنامج المطور يلبي المتطلبات؟"، التحقق - "ما الذي تم فعله؟" أو "هل يفي النظام المطور بالمتطلبات؟"، والتحقق من الصحة هو "هل قام بما يجب عليه فعله؟" أو “هل النظام المطور يلبي توقعات العميل؟” 1.7. الوثائق التي تم إنشاؤها في مراحل مختلفة من دورة الحياة تتم مزامنة جميع مراحل التطوير بمساعدة المستندات التي يتم إنشاؤها في كل مرحلة. في هذه الحالة، يتم إنشاء الوثائق على الجزء المباشر من دورة الحياة - أثناء تطوير نظام البرمجيات، وعلى العكس - أثناء التحقق منها. دعونا نحاول، باستخدام مثال دورة الحياة على شكل حرف V، تتبع أنواع المستندات التي يتم إنشاؤها في كل قطعة، وما هي العلاقات الموجودة بينها (الشكل 8). نتيجة مرحلة تطوير متطلبات النظام هي صياغة متطلبات النظام - وثيقة تصف المبادئ العامة لتشغيل النظام وتفاعله مع " بيئة» - مستخدمو النظام وكذلك البرامج والأجهزة التي تضمن تشغيله. عادة، بالتوازي مع متطلبات النظام، يتم إنشاء خطة التحقق وتحديد استراتيجية التحقق. تحدد هذه المستندات النهج العام لكيفية إجراء الاختبار، وما هي التقنيات التي سيتم استخدامها، وما هي جوانب النظام المستقبلي التي ستحتاج إلى اختبار شامل. هناك مهمة أخرى يتم حلها عن طريق تحديد استراتيجية التحقق وهي تحديد موقع عمليات التحقق المختلفة وارتباطاتها بعمليات التطوير. 20 عملية التحقق التي تعمل مع متطلبات النظام هي عملية التحقق من صحة المتطلبات ومقارنتها مع التوقعات الحقيقية للعميل. وبالنظر إلى المستقبل، لنفترض أن عملية التحقق من الصحة تختلف عن اختبارات القبول التي يتم إجراؤها عند نقل النظام النهائي إلى العميل، على الرغم من أنه يمكن اعتبارها جزءًا من هذه الاختبارات. التحقق من الصحة هو وسيلة لإثبات ليس فقط صحة تنفيذ النظام من وجهة نظر العميل، ولكن أيضًا صحة المبادئ التي يقوم عليها تطويره. أرز. 8 العمليات والوثائق في تطوير الأنظمة البرمجية متطلبات النظام هي الأساس لعملية تطوير المتطلبات الوظيفية وهندسة المشروع. خلال هذه العملية، يتم تطوير المتطلبات العامة لبرنامج النظام والوظائف التي يجب أن يؤديها. تتضمن المتطلبات الوظيفية غالبًا تعريف أنماط سلوك النظام في المعايير و حالات طارئة وقواعد معالجة البيانات وتعريفات واجهة المستخدم. يتضمن نص المتطلب، كقاعدة عامة، الكلمات "يجب، يجب" وله هيكل النموذج "إذا وصلت قيمة درجة الحرارة عند مستشعر ABC إلى 30 درجة مئوية أو أعلى، فيجب أن يتوقف النظام عن إصدار إشارة صوتية. " المتطلبات الوظيفية هي الأساس لتطوير بنية النظام - وصف بنيته من حيث الأنظمة الفرعية والوحدات الهيكلية للغة التي يتم التنفيذ بها - المجالات والفئات والوحدات والوظائف وما إلى ذلك. بناءً على المتطلبات الوظيفية، تتم كتابة متطلبات الاختبار - المستندات التي تحتوي على تعريف النقاط الأساسية التي يجب التحقق منها لضمان التنفيذ الصحيح للمتطلبات الوظيفية. غالبًا ما تبدأ متطلبات الاختبار بالكلمات "اختبر ذلك" وتحتوي على إشارات إلى المتطلبات الوظيفية المقابلة لها. مثال على متطلبات الاختبار للمتطلبات الوظيفية المذكورة أعلاه سيكون "التحقق من أنه عندما تنخفض درجة الحرارة في مستشعر ABC إلى أقل من 30 درجة مئوية، يصدر النظام صوت تنبيه" و"التحقق من أنه عندما تكون قيمة درجة الحرارة في مستشعر ABC أعلى من 30 درجة مئوية" درجة مئوية"، فإن النظام لا يصدر إشارة صوتية." 21 إحدى المشكلات التي تنشأ عند كتابة متطلبات الاختبار هي عدم قابلية الاختبار الأساسية لبعض المتطلبات، على سبيل المثال، لا يمكن التحقق من مطلب "يجب أن تكون واجهة المستخدم بديهية" دون تعريف واضح لما يشكل واجهة بديهية. عادةً ما يتم تعديل هذه المتطلبات الوظيفية غير المحددة لاحقًا. يمكن أيضًا أن تكون الميزات المعمارية للنظام بمثابة مصدر لإنشاء متطلبات الاختبار التي تأخذ في الاعتبار ميزات تنفيذ البرنامج للنظام. ومن الأمثلة على هذا المتطلب، على سبيل المثال، "التأكد من أن قيمة درجة الحرارة عند حساس ABC لا تتجاوز 255." بناءً على المتطلبات الوظيفية والهندسة المعمارية، تتم كتابة رمز النظام، وللتحقق منه، يتم إعداد خطة اختبار بناءً على متطلبات الاختبار - وصف لتسلسل حالات الاختبار التي تتحقق من امتثال تنفيذ النظام للمتطلبات. تحتوي كل حالة اختبار على وصف محدد للقيم المقدمة لمدخلات النظام، والقيم المتوقعة عند الإخراج، ووصف لسيناريو تنفيذ الاختبار. اعتمادًا على كائن الاختبار، يمكن إعداد خطة الاختبار إما على شكل برنامج في بعض لغات البرمجة، أو على شكل ملف بيانات إدخال لمجموعة الأدوات التي تنفذ النظام قيد الاختبار وتنقل إليه القيم المحددة في خطة الاختبار، أو على شكل تعليمات لنظام المستخدم توضح الإجراءات اللازمة التي يجب القيام بها لاختبار وظائف النظام المختلفة. نتيجة لتنفيذ جميع حالات الاختبار، يتم جمع إحصائيات حول نجاح الاختبار - النسبة المئوية لحالات الاختبار التي تزامنت قيم المخرجات الفعلية لها مع القيم المتوقعة، ما يسمى بالاختبارات التي تم اجتيازها. الاختبارات الفاشلة هي البيانات الأولية لتحليل أسباب الأخطاء وتصحيحها لاحقًا. في مرحلة التكامل، يتم تجميع وحدات النظام الفردية في وحدة واحدة ويتم تنفيذ حالات الاختبار التي تتحقق من وظائف النظام بالكامل. وفي المرحلة الأخيرة، يتم تسليم النظام النهائي إلى العميل. قبل التنفيذ، يقوم متخصصو العملاء، جنبًا إلى جنب مع المطورين، بإجراء اختبارات القبول - حيث يقومون بفحص الوظائف المهمة للمستخدم وفقًا لبرنامج اختبار معتمد مسبقًا. في حالة إتمام الاختبارات بنجاح، يتم نقل النظام إلى العميل، وإلا يتم إرساله للمراجعة. 1.8. أنواع عمليات الاختبار والتحقق ومكانها في نماذج دورة الحياة المختلفة 1.8.1. اختبار الوحدة تخضع الوحدات الصغيرة (الإجراءات والفئات وما إلى ذلك) لاختبار الوحدة. عند اختبار وحدة نمطية صغيرة نسبيًا يتراوح حجمها بين 100 و1000 سطر، من الممكن التحقق، إن لم يكن كلها، على الأقل من العديد من الفروع المنطقية في التنفيذ، ومسارات مختلفة في الرسم البياني لتبعية البيانات، والقيم الحدودية للمعلمات. ووفقاً لهذا، يتم وضع معايير تغطية الاختبار (يتم تغطية جميع المشغلين، وجميع الفروع المنطقية، وجميع النقاط الحدودية، وما إلى ذلك). . عادة ما يتم إجراء اختبار الوحدة لكل مستقل وحدة البرمجياتوربما يكون هذا هو النوع الأكثر شيوعًا من الاختبارات، خاصة للأنظمة الصغيرة والمتوسطة الحجم. 1.8.2. اختبار التكامل التحقق من صحة جميع الوحدات، للأسف، لا يضمن الأداء الصحيح لنظام الوحدات. تناقش الأدبيات أحيانًا 22 النموذج "الكلاسيكي" للتنظيم غير السليم لاختبار نظام الوحدات، والذي يُطلق عليه غالبًا طريقة "القفزة الكبيرة". يتمثل جوهر الطريقة أولاً في اختبار كل وحدة على حدة، ثم دمجها في نظام واختبار النظام بأكمله. بالنسبة للأنظمة الكبيرة، هذا غير واقعي. باستخدام هذا النهج، سيتم قضاء الكثير من الوقت في توطين الأخطاء، وستظل جودة الاختبار منخفضة. البديل عن "القفزة الكبيرة" هو اختبار التكامل، عندما يتم بناء النظام على مراحل، يتم إضافة مجموعات من الوحدات تدريجيا. 1.8.3. اختبار النظام يخضع منتج البرنامج الذي تم تنفيذه بالكامل لاختبار النظام. في هذه المرحلة، لا يهتم المُختبر بالتنفيذ الصحيح للإجراءات والأساليب الفردية، بل بالبرنامج بأكمله، كما يراه المستخدم النهائي. الاختبارات مبنية على المتطلبات العامةللبرنامج، بما في ذلك ليس فقط التنفيذ الصحيح للوظائف، ولكن أيضًا الأداء ووقت الاستجابة ومقاومة الفشل والهجمات وأخطاء المستخدم وما إلى ذلك. بالنسبة لاختبار النظام والمكونات، يتم استخدام أنواع محددة من معايير تغطية الاختبار (على سبيل المثال، هل يتم تغطية جميع سيناريوهات العمل النموذجية، وجميع السيناريوهات ذات المواقف غير الطبيعية، والتركيبات الزوجية للسيناريوهات، وما إلى ذلك). 1.8.4. اختبار الحمل لا يوفر اختبار الحمل بيانات تنبؤية حول أداء النظام تحت الحمل والتي توجه القرارات المعمارية فحسب، بل يوفر أيضًا معلومات تشغيلية لفرق الدعم الفني، بالإضافة إلى مديري المشاريع والتكوين المسؤولين عن إنشاء تكوينات الأجهزة والبرامج الأكثر إنتاجية. يتيح اختبار التحميل لفريق التطوير اتخاذ قرارات أكثر استنارة تهدف إلى تطوير التراكيب المعمارية المثالية. يحصل العميل من جانبه على فرصة إجراء اختبارات القبول في ظل ظروف قريبة من الظروف الحقيقية. 1.8.5. عمليات التفتيش الرسمية يعد الفحص الرسمي أحد الطرق للتحقق من المستندات ورموز البرامج التي تم إنشاؤها أثناء عملية تطوير البرامج. أثناء التفتيش الرسمي، يقوم فريق من المتخصصين بشكل مستقل بالتحقق من مطابقة المستندات التي تم فحصها مع المستندات الأصلية. يتم ضمان استقلالية التفتيش من خلال حقيقة أنه يتم إجراؤه بواسطة مفتشين لم يشاركوا في تطوير الوثيقة التي يتم فحصها. 1.9. التحقق من البرامج المعتمدة دعونا نقدم العديد من التعريفات التي تحدد الهيكل العامعملية اعتماد البرامج: شهادة البرامج هي عملية إنشاء والاعتراف رسميًا بأن تطوير البرامج تم تنفيذه وفقًا للمتطلبات المحددة. أثناء عملية الاعتماد، يكون هناك تفاعل بين مقدم الطلب وهيئة التصديق والهيئة الإشرافية. مقدم الطلب هو منظمة تقدم طلبًا إلى هيئة التصديق ذات الصلة للحصول على شهادة (المطابقة والجودة والملاءمة وما إلى ذلك) من شهادة منتج. هيئة التصديق هي منظمة تنظر في طلب مقدم الطلب للحصول على شهادة البرمجيات، وتقوم إما بشكل مستقل أو من خلال تشكيل لجنة خاصة بتنفيذ مجموعة من الإجراءات التي تهدف إلى تنفيذ عملية شهادة البرمجيات الخاصة بمقدم الطلب. 23 هيئة إشرافية - لجنة من المتخصصين الذين يراقبون عمليات تطوير مقدم الطلب للحصول على الشهادة نظام معلوماتوإبداء الرأي حول مدى امتثال هذه العملية لمتطلبات معينة، والتي يتم تقديمها للنظر فيها إلى سلطة التصديق. يمكن أن تهدف الشهادة إلى الحصول على شهادة المطابقة أو شهادة الجودة. في الحالة الأولى، نتيجة الشهادة هي الاعتراف بامتثال عمليات التطوير لمعايير معينة، ووظيفة النظام مع متطلبات معينة. ومن الأمثلة على هذه المتطلبات الوثائق التوجيهية الخدمة الفيدرالية بشأن الرقابة الفنية ومراقبة الصادرات في مجال أمن أنظمة البرمجيات. وفي الحالة الثانية تكون النتيجة الاعتراف بامتثال عمليات التطوير لمعايير معينة تضمن مستوى مناسب من جودة المنتج المصنع ومدى ملاءمته للاستخدام في ظروف معينة. مثال على هذه المعايير هو سلسلة معايير الجودة الدولية ISO 9000:2000 (GOST R ISO 9000-2001) أو معايير الطيران DO-178B، AS9100، AS9006. اختبار البرامج المعتمدة له غرضين متكاملين: الغرض الأول هو إثبات أن البرنامج يلبي المتطلبات الخاصة به. الهدف الثاني هو الإثبات بمستوى عالٍ من الثقة أنه تم تحديد الأخطاء التي قد تؤدي إلى حالات فشل غير مقبولة، على النحو المحدد في عملية تقييم سلامة أخطاء النظام، أثناء عملية الاختبار. على سبيل المثال، يتطلب DO-178B ما يلي لتحقيق أهداف اختبار البرامج: يجب أن تعتمد الاختبارات بشكل أساسي على متطلبات البرامج؛ وينبغي تصميم الاختبارات للتحقق من الأداء الصحيح والكشف عن الأخطاء المحتملة. يجب أن يحدد تحليل مدى اكتمال الاختبارات بناءً على متطلبات البرامج المتطلبات التي لم يتم اختبارها. يجب أن يحدد تحليل اكتمال الاختبارات بناءً على بنية كود البرنامج الهياكل التي لم يتم تنفيذها أثناء الاختبار. يتحدث هذا المعيار أيضًا عن الاختبارات القائمة على المتطلبات. لقد وجد أن هذه الإستراتيجية هي الأكثر فعالية في تحديد الأخطاء. تتضمن المبادئ التوجيهية لاختيار حالات الاختبار بناءً على المتطلبات ما يلي: لتحقيق أهداف اختبار البرمجيات، يجب إجراء فئتين من الاختبارات: اختبارات للمواقف العادية واختبارات للمواقف غير الطبيعية (غير المتطلبات، القوية). ينبغي تطوير حالات اختبار محددة لمتطلبات البرامج ومصادر الأخطاء الكامنة في عملية تطوير البرامج. الغرض من اختبارات المواقف العادية هو إظهار قدرة البرنامج على الاستجابة للمدخلات والظروف العادية كما هو مطلوب. 24 الغرض من اختبارات المواقف غير الطبيعية هو إظهار قدرة البرنامج على الاستجابة بشكل مناسب للمدخلات والظروف غير الطبيعية، وبعبارة أخرى، لا ينبغي أن يتسبب ذلك في فشل النظام. يتم تحديد فئات الفشل للنظام من خلال تحديد مدى خطورة حالة الفشل بالنسبة للطائرة وركابها. يمكن أن يتسبب أي خطأ في البرنامج في حدوث فشل يساهم في حدوث حالة فشل. وبالتالي، فإن مستوى سلامة البرامج المطلوبة للتشغيل الآمن يرتبط بحالات فشل النظام. هناك 5 مستويات لحالات الفشل من البسيطة إلى الحرجة. ووفقاً لهذه المستويات تم تقديم مفهوم مستوى أهمية البرمجيات. يحدد مستوى الأهمية تكوين الوثائق المقدمة إلى هيئة إصدار الشهادات، وبالتالي عمق تطوير النظام وعمليات التحقق. على سبيل المثال، قد يختلف عدد أنواع المستندات ومقدار أعمال تطوير النظام المطلوبة للحصول على الشهادة إلى أدنى مستوى من الأهمية DO-178B بأمر أو أمرين من حيث الحجم من العدد والحجم المطلوبين للحصول على الشهادة إلى الحد الأقصى مستوى عال. يتم تحديد المتطلبات المحددة وفقًا للمعيار الذي يتم من خلاله التخطيط لإصدار الشهادات. 25 الموضوع 2. اختبار كود البرنامج (المحاضرات 2-5) 2.1. مهام وأهداف اختبار كود البرنامج اختبار كود البرنامج هو عملية تنفيذ كود البرنامج، بهدف تحديد العيوب الموجودة فيه. يُفهم الخلل هنا على أنه جزء من كود البرنامج، والذي يؤدي تنفيذه، في ظل ظروف معينة، إلى سلوك غير متوقع للنظام (أي سلوك لا يفي بالمتطلبات). يمكن أن يؤدي السلوك غير المتوقع للنظام إلى حدوث أعطال وفشل، وفي هذه الحالة يتحدثون عن عيوب كبيرة في كود البرنامج. تسبب بعض العيوب مشاكل بسيطة لا تعطل عمل النظام ولكنها تجعل العمل به صعبًا إلى حد ما. في هذه الحالة يتحدثون عن عيوب متوسطة أو طفيفة. ومهمة الاختبار بهذا الأسلوب هي تحديد الظروف التي تظهر فيها عيوب النظام وتسجيل هذه الظروف. لا تتضمن مهام الاختبار عادةً تحديد أقسام معيبة محددة في كود البرنامج ولا تتضمن أبدًا تصحيح العيوب - فهذه مهمة تصحيح يتم تنفيذها بناءً على نتائج اختبار النظام. الغرض من استخدام إجراء اختبار رمز البرنامج هو تقليل عدد العيوب، وخاصة العيوب الهامة، في المنتج النهائي. لا يمكن للاختبار في حد ذاته أن يضمن الغياب الكامل للعيوب في رمز النظام. ومع ذلك، بالاشتراك مع عمليات التحقق والتحقق التي تهدف إلى القضاء على عدم الاتساق وعدم الاكتمال وثائق المشروع(على وجه الخصوص، متطلبات النظام)، يضمن الاختبار المنظم جيدًا أن النظام يلبي المتطلبات ويتصرف وفقًا لها في جميع المواقف المقصودة. عند تطوير أنظمة ذات موثوقية متزايدة، على سبيل المثال، أنظمة الطيران، يتم تحقيق ضمانات الموثوقية من خلال تنظيم واضح لعملية الاختبار، وتحديد ارتباطها بعمليات دورة الحياة الأخرى، وإدخال الخصائص الكمية التي تسمح بتقييم نجاح الاختبار. علاوة على ذلك، كلما ارتفعت متطلبات موثوقية النظام (مستوى حرجته)، كلما تم فرض المتطلبات الأكثر صرامة. وبالتالي، أولا وقبل كل شيء، نحن لا نعتبر النتائج المحددة لاختبار نظام معين، ولكن التنظيم العام عملية الاختبار، وذلك باستخدام النهج "عملية منظمة تنظيما جيدا تنتج نتيجة الجودة." هذا النهج مشترك في العديد من معايير الجودة الدولية والصناعية، والتي سيتم مناقشتها بمزيد من التفصيل في نهاية هذه الدورة. إن جودة النظام المطور بهذا النهج هي نتيجة لعملية التطوير والاختبار المنظمة، وليست نتيجة مستقلة لا يمكن السيطرة عليها. نظرًا لأن أنظمة البرامج الحديثة كبيرة جدًا، يتم استخدام طريقة التحلل الوظيفي عند اختبار كود البرنامج الخاص بها. ينقسم النظام إلى وحدات منفصلة (الفئات، ومساحات الأسماء، وما إلى ذلك) التي لها وظائف وواجهات تحددها المتطلبات. بعد ذلك، يتم اختبار كل وحدة على حدة - يتم إجراء اختبار الوحدة. ثم يتم تجميع الوحدات الفردية في تكوينات أكبر - يتم إجراء اختبار التكامل، وفي النهاية يتم اختبار النظام ككل - يتم إجراء اختبار النظام. من وجهة نظر الكود، هناك الكثير من القواسم المشتركة بين الوحدة والتكامل واختبار النظام، لذلك سيركز هذا الموضوع على اختبار الوحدة، مع مناقشة ميزات التكامل واختبار النظام لاحقًا. 26 أثناء اختبار الوحدة، يتم اختبار كل وحدة للتأكد من امتثالها للمتطلبات وغياب المناطق الإشكالية في كود البرنامج والتي يمكن أن تسبب أعطالًا وأعطالًا في النظام. كقاعدة عامة، لا تعمل الوحدات خارج النظام - فهي تتلقى البيانات من وحدات أخرى وتعالجها وتنقلها بشكل أكبر. من أجل عزل الوحدة عن النظام والقضاء على تأثير أخطاء النظام المحتملة من ناحية، ومن ناحية أخرى، لتزويد الوحدة بجميع البيانات اللازمة، يتم استخدام بيئة اختبار. تتمثل مهمة بيئة الاختبار في إنشاء بيئة تشغيل للوحدة ومحاكاة جميع الواجهات الخارجية التي تصل إليها الوحدة. سيتم مناقشة ميزات تنظيم بيئة الاختبار في هذا الموضوع. يتكون إجراء الاختبار النموذجي من إعداد وتنفيذ حالات الاختبار (وتسمى أيضًا الاختبارات ببساطة). يتحقق كل مثال اختبار من "موقف" واحد في سلوك الوحدة ويتكون من قائمة القيم التي تم تمريرها إلى مدخلات الوحدة، ووصف إطلاق وتنفيذ معالجة البيانات - برنامج نصي للاختبار، وقائمة من القيم المتوقعة عند مخرجات الوحدة إذا كانت تتصرف بشكل صحيح. يتم تجميع نصوص الاختبار بطريقة تستبعد الوصول إلى البيانات الداخلية للوحدة، ويجب أن تتم جميع التفاعلات فقط من خلال واجهاتها الخارجية. يتم دعم تنفيذ حالة الاختبار من خلال بيئة اختبار تتضمن تنفيذ برنامج للبرنامج النصي للاختبار. يبدأ التنفيذ بتمرير بيانات الإدخال إلى الوحدة وتشغيل البرنامج النصي. يتم حفظ بيانات الإخراج الفعلية الواردة من الوحدة نتيجة لتنفيذ البرنامج النصي ومقارنتها بالبيانات المتوقعة. فإذا تطابقت يعتبر الاختبار ناجحا، وإلا يعتبر فاشلا. يشير كل اختبار فاشل إما إلى وجود خلل في الوحدة قيد الاختبار، أو في بيئة الاختبار، أو في وصف الاختبار. تشكل مجموعة أوصاف حالات الاختبار خطة اختبار - الوثيقة الرئيسية التي تحدد إجراء الاختبار لوحدة البرنامج. لا تحدد خطة الاختبار حالات الاختبار نفسها فحسب، بل تحدد أيضًا الترتيب الذي تظهر به، والذي قد يكون مهمًا أيضًا. سيتم مناقشة هيكل وميزات خطط الاختبار في هذا الموضوع، وسيتم مناقشة المشكلات المرتبطة بترتيب حالات الاختبار في موضوع "اختبار التكرار". عند الاختبار، غالبا ما يكون من الضروري أن تأخذ في الاعتبار ليس فقط متطلبات النظام، ولكن أيضا هيكل رمز البرنامج للوحدة التي يتم اختبارها. في هذه الحالة، يتم تصميم الاختبارات بطريقة تسمح بالكشف أخطاء نموذجية المبرمجين بسبب سوء تفسير المتطلبات. يتم استخدام فحوصات حالة الحدود وفحوصات فئة التكافؤ. إن غياب الإمكانيات في النظام التي لم تحددها المتطلبات يتم ضمانه من خلال تقديرات مختلفة لتغطية كود البرنامج عن طريق الاختبارات، أي. تقدير النسبة المئوية لبعض بنيات اللغة المكتملة نتيجة تنفيذ جميع أمثلة الاختبار. كل هذا سيتم مناقشته في نهاية هذا الموضوع. 2.2. طرق الاختبار 2.2.1. الصندوق الأسود الفكرة الرئيسية في اختبار النظام باعتباره الصندوق الأسود هي أن جميع المواد المتوفرة للمختبر هي متطلبات للنظام، تصف سلوكه والنظام نفسه، والتي لا يمكنه العمل بها إلا من خلال تطبيق بعض المؤثرات الخارجية عليه. مدخلاته وملاحظة المخرجات تنتج بعض النتائج. يتم إخفاء جميع الميزات الداخلية لتطبيق النظام عن القائم بالاختبار، وبالتالي فإن النظام عبارة عن "صندوق أسود" يجب التحقق من سلوكه الصحيح فيما يتعلق بالمتطلبات. 27 من وجهة نظر كود البرنامج، يمكن أن يكون الصندوق الأسود عبارة عن مجموعة من الفئات (أو الوحدات النمطية) ذات واجهات خارجية معروفة، ولكن لا يمكن الوصول إلى رموز المصدر. تتمثل المهمة الرئيسية للمختبر في طريقة الاختبار هذه في التحقق باستمرار من أن سلوك النظام يلبي المتطلبات. بالإضافة إلى ذلك، يجب على المختبر التحقق من تشغيل النظام في المواقف الحرجة - ماذا يحدث إذا تم توفير قيم إدخال غير صحيحة. في الوضع المثالي، يجب وصف كافة المتغيرات للمواقف الحرجة في متطلبات النظام ولا يمكن للمختبر سوى التوصل إلى اختبارات محددة لهذه المتطلبات. ومع ذلك، في الواقع، نتيجة للاختبار، عادة ما يتم تحديد نوعين من مشاكل النظام: 1. عدم تناسق سلوك النظام مع المتطلبات 2. السلوك غير المناسب للنظام في المواقف غير المنصوص عليها في المتطلبات. يتم الإبلاغ عن كلا النوعين من المشكلات وإبلاغهما للمطورين. في الوقت نفسه، عادة ما تسبب مشاكل النوع الأول تغييرات في رمز البرنامج، وفي كثير من الأحيان - تغييرات في المتطلبات. قد يكون تغيير المتطلبات في هذه الحالة ضروريًا بسبب عدم اتساقها (تصف عدة متطلبات مختلفة نماذج مختلفة لسلوك النظام في نفس الموقف) أو عدم صحتها (المتطلبات لا تتوافق مع الواقع). من الواضح أن مشاكل النوع الثاني تتطلب تغيير المتطلبات بسبب عدم اكتمالها - من الواضح أن المتطلبات تغفل الموقف الذي يؤدي إلى سلوك غير مناسب للنظام. في هذه الحالة، يمكن فهم السلوك غير المناسب على أنه انهيار كامل للنظام، أو بشكل عام أي سلوك غير موصوف في المتطلبات. يُطلق على اختبار الصندوق الأسود أيضًا اسم اختبار المتطلبات لأنه... هذا هو المصدر الوحيد للمعلومات لبناء خطة الاختبار. 2.2.2. صندوق زجاجي (أبيض) عند اختبار نظام كصندوق زجاجي، لا يتمكن المختبر من الوصول إلى متطلبات النظام ومدخلاته ومخرجاته فحسب، بل أيضًا إلى بنيته الداخلية - فهو يرى رمز البرنامج الخاص به. يؤدي توفر كود البرنامج إلى توسيع قدرات المختبر حيث يمكنه رؤية مدى امتثال المتطلبات لأقسام كود البرنامج وبالتالي معرفة ما إذا كانت المتطلبات موجودة لرمز البرنامج بأكمله. يُطلق على كود البرنامج الذي لا توجد متطلبات له اسم الكود الذي لا تغطيه المتطلبات. يعد هذا الرمز مصدرًا محتملاً لسلوك النظام غير المناسب. بالإضافة إلى ذلك، تسمح لك شفافية النظام بتعميق تحليل مناطقه التي تسبب المشكلات - غالبًا ما تؤدي مشكلة ما إلى تحييد مشكلة أخرى ولا تحدث أبدًا في وقت واحد. 2.2.3. اختبار النموذج يختلف اختبار النموذج إلى حد ما عن الطرق الكلاسيكية للتحقق من البرمجيات. بادئ ذي بدء، يرجع ذلك إلى حقيقة أن موضوع الاختبار ليس النظام نفسه، ولكن نموذجه المصمم بالوسائل الرسمية. إذا تركنا جانبًا قضايا التحقق من صحة النموذج نفسه وقابليته للتطبيق (يُعتقد أنه يمكن إثبات صحته وامتثاله للنظام الأصلي بالوسائل الرسمية)، فإن المختبر لديه أداة قوية إلى حد ما للتحليل. السلامة العامة للنظام. من خلال العمل مع النموذج، يمكنك إنشاء مواقف لا يمكن إنشاؤها في مختبر اختبار لنظام حقيقي. من خلال العمل باستخدام نموذج رمز برنامج النظام، يمكنك تحليل خصائصه ومعلمات النظام مثل تحسين الخوارزميات أو استقرارها. 28 ومع ذلك، لم ينتشر اختبار النماذج على نطاق واسع على وجه التحديد بسبب الصعوبات التي تمت مواجهتها في تطوير وصف رسمي لسلوك النظام. أحد الاستثناءات القليلة هو أنظمة الاتصالات، التي تم تطوير أجهزتها الحسابية والرياضية بشكل جيد. 2.2.4. تحليل كود البرنامج (عمليات التفتيش) في كثير من الحالات، يكون اختبار سلوك النظام ككل أمرًا مستحيلًا - قد لا يتم تنفيذ الأجزاء الفردية من كود البرنامج أبدًا، ولكن سيتم تغطيتها بواسطة المتطلبات. مثال على أقسام التعليمات البرمجية هذه هو معالجات الاستثناءات. على سبيل المثال، إذا قامت وحدتان بتمرير قيم رقمية لبعضهما البعض، وكانت وظائف التحقق من القيمة تعمل في كلتا الوحدتين، فلن يتم تنشيط وظيفة التحقق من وحدة الاستقبال أبدًا، لأن سيتم قطع جميع القيم الخاطئة في جهاز الإرسال. في هذه الحالة، يتم إجراء تحليل يدوي لكود البرنامج للتأكد من صحته، ويسمى أيضًا مراجعات الكود أو عمليات التفتيش. إذا تم تحديد مناطق المشكلات نتيجة للتفتيش، فسيتم إرسال المعلومات حول هذا إلى المطورين لتصحيحها، إلى جانب نتائج الاختبارات المنتظمة. 2.3. بيئة الاختبار عادةً ما يتم إجراء الجزء الأكبر من اختبار أي نظام معقد تقريبًا الوضع التلقائي. بالإضافة إلى ذلك، عادةً ما يتم تقسيم النظام قيد الاختبار إلى وحدات منفصلة، يتم اختبار كل منها أولاً بشكل منفصل عن الوحدات الأخرى، ثم ككل. وهذا يعني أنه من أجل إجراء الاختبار، من الضروري إنشاء بعض البيئة التي تضمن إطلاق وتنفيذ الوحدة قيد الاختبار، ونقل بيانات الإدخال إليها، وجمع بيانات الإخراج الحقيقية التي تم الحصول عليها نتيجة تشغيل النظام على بيانات الإدخال المعطاة. بعد ذلك، يجب على البيئة مقارنة بيانات المخرجات الفعلية مع البيانات المتوقعة، وبناءً على هذه المقارنة، التوصل إلى استنتاج حول امتثال سلوك الوحدة النمطية للسلوك المحدد (الشكل 9). اختبار السائق الناتج المتوقع المعالجة المختبرة وحدة نتيجة بيانات الإدخال بيانات الإخراج الحقيقية بذرة الشكل. 9 رسم تخطيطي معمم لبيئة الاختبار يمكن أيضًا استخدام بيئة الاختبار لعزل وحدات النظام الفردية عن النظام بأكمله. يتيح لك فصل وحدات النظام في المراحل الأولى من الاختبار توطين المشكلات التي تنشأ في كود البرنامج الخاص بها بشكل أكثر دقة. لدعم تشغيل الوحدة النمطية بمعزل عن النظام، يجب أن تحاكي بيئة الاختبار سلوك جميع الوحدات التي يتم الوصول إلى وظائفها أو بياناتها بواسطة الوحدة قيد الاختبار. 29
إرسال عملك الجيد في قاعدة المعرفة أمر بسيط. استخدم النموذج أدناه
سيكون الطلاب وطلاب الدراسات العليا والعلماء الشباب الذين يستخدمون قاعدة المعرفة في دراساتهم وعملهم ممتنين جدًا لك.
تم النشر على http://www.allbest.ru/
مقال
طرق التحقق من البرمجيات واختبارها
مقدمة
يميل البشر إلى ارتكاب الأخطاء. لقد كانت هناك دائما أخطاء، وسوف يكون هناك دائما. هناك مزحة في مجتمع تكنولوجيا المعلومات مفادها أنه إذا تم تشغيل البرنامج في المرة الأولى وعمل على الفور، فأنت بحاجة إلى البحث عن الخطأ.
جنبا إلى جنب مع التنمية تكنولوجيا الكمبيوترومع تغلغلها في جميع مجالات الحياة، فإن عدد الأخطاء في البرامج يتزايد أيضًا. علاوة على ذلك، فإن نمو الأخطاء لا يتناسب مع النمو في عدد البرامج. في كل عام، يتم تجديد صفوف المبرمجين بمبرمجين متخلفين (واسمهم الفيلق)، الذين يطورون مجال الأخطاء في التقدم الهندسي.
الأخطاء ليست ملحوظة في كل مجال. على سبيل المثال، لا أحد يهتم بالأخطاء ونقاط الضعف في متصفحات أميغو. والخسائر الناجمة عن مثل هذه الأخطاء ضئيلة: أقصى ما يمكن أن يخسره المستخدم العادي هو الحسابات على الشبكات الاجتماعية وألف ونصف صورة لا قيمة لها من الإجازة ومجموعة من المواد الإباحية.
ولكن هناك مجالات يمكن أن تؤدي فيها أخطاء البرمجة إلى عواقب وخيمة. إحدى الحالات الأولى التي تمكنت من العثور عليها كانت المركبة الفضائية مارينر 1، التي دمرت في 22 يوليو 1962، بعد 293 ثانية من الإقلاع بسبب خطأ في برنامج الكمبيوتر الموجود على متنها. من الجيد أنه لم تكن هناك وفيات في ذلك الوقت.
ماذا سيحدث إذا قام الكمبيوتر الموجود على متن طائرة بوينج 747، وعلى متنها أربعمائة راكب، بطرح استثناء؟.
في مثل هذه المجالات التي يمكن تسميتها "خطيرة" تم اختراع طرق التحقق والاختبار.
في بعض الأدبيات الأجنبية، تم تحديد عمليات التحقق والاختبار، وفي بعض الأماكن يعتبر الاختبار إحدى طرق التحقق. سأقوم بتنفيذ هذا العمل حسب فهمي، وسأفكر بشكل منفصل في عمليات التحقق والاختبار. ولكي أكون منصفًا أيضًا، سأتطرق إلى موضوع التحقق من صحة البرامج.
1. تعريفات
دورة الحياةبرنامج (LC). يشير هذا المصطلح إلى الفاصل الزمني، بدءًا من فكرة إنشاء برنامج يتمتع بالوظائف اللازمة لحل مشكلات معينة حتى التوقف التام عن الاستخدام احدث اصدارهذا البرنامج.
الآثاردورة حياة البرمجيات. يتضمن ذلك مجموعة متنوعة من المواد الإعلامية المتعلقة بإنشاء البرامج. هذه مواصفات فنية ووصف للبنية وكود المصدر ووثائق المستخدم والمستندات الأخرى. المواد التي تم استخدامها أثناء التطوير ولكن لم يتم تسجيلها في نموذج يمكن الوصول إليه (على سبيل المثال، التعليقات في التعليمات البرمجية وتوبيخ المطورين في الدردشة) ليست عناصر.
2. تَحَقّق
يتحقق التحقق من امتثال بعض العناصر التي تم إنشاؤها أثناء تطوير وصيانة البرامج مع العناصر الأخرى التي تم إنشاؤها أو استخدامها مسبقًا كبيانات إدخال، بالإضافة إلى امتثال هذه العناصر وعمليات تطويرها للقواعد والمعايير. على وجه الخصوص، يتحقق التحقق من الامتثال بين المعايير وأوصاف المتطلبات (المواصفات الفنية) للبرامج وحلول التصميم وكود المصدر ووثائق المستخدم وعمل البرنامج نفسه. وبالإضافة إلى ذلك، يتم التحقق من أن المتطلبات حلول التصميمتم تصميم الوثائق والتعليمات البرمجية وفقًا للقواعد والمعايير المعتمدة في بلد وصناعة ومنظمة معينة عند تطوير البرامج، وأيضًا أثناء إنشائها، تم تنفيذ جميع العمليات المحددة في المعايير بالتسلسل المطلوب. الأخطاء والعيوب المكتشفة أثناء التحقق هي اختلافات أو تناقضات بين العديد من المستندات المدرجة، بين المستندات والتشغيل الفعلي للبرنامج، بين المعايير والعمليات الفعلية لتطوير البرامج وصيانتها. في الوقت نفسه، فإن تحديد المستند الذي يخضع للتصحيح (ربما كلاهما) هو مهمة منفصلة.
ما ورد أعلاه هو التعريف الرسمي للتحقق. في الواقع، كل شيء أبسط من ذلك بكثير: التحقق يحدد هل نقوم بتنفيذ البرنامج بشكل صحيح؟.
وبالتالي، فإن طرق التحقق الرئيسية هي الفحص والتفتيش.
برنامج التحقق من الامتحان
3. تصديق
أثناء عملية التحقق من الصحة، يتم التحقق من مدى توافق أي عناصر تم إنشاؤها أو استخدامها أثناء تطوير وصيانة البرنامج مع احتياجات ومتطلبات مستخدمي وعملاء هذا البرنامج، مع مراعاة القوانين موضوع النقاشوالقيود المفروضة على سياق استخدام البرمجيات.
ومرة أخرى، وراء العديد من الكلمات هناك جدا مهمة بسيطة: أثناء عملية التحقق من الصحة، يتم التحقق مما إذا كان هؤلاء المستخدمون/العملاء يحتاجون إلى وظائف معينة في البرنامج. هل يلبي منتج البرنامج رغبات العملاء والمستخدمين النهائيين؟
4. الاختبار
الاختبار هو عملية اكتشاف الأخطاء في البرامج عن طريق تنفيذ التعليمات البرمجية لنظام برمجي على بيانات الاختبار، وجمع خصائص الأداء في ديناميكيات التنفيذ في بيئة تشغيل محددة، وتحديد الأخطاء والعيوب والإخفاقات والعيوب المختلفة الناجمة عن المواقف غير المنتظمة والشاذة أو الإنهاء الطارئ للبرنامج.
تاريخيًا، كان النوع الأول من الاختبارات هو تصحيح الأخطاء.
تصحيح الأخطاء هو فحص لوصف كائن البرنامج في لغة البرمجة من أجل اكتشاف الأخطاء فيه وإزالتها لاحقًا. يكتشف المترجم الأخطاء عندما يتم فحصها من الناحية النحوية. بعد تصحيح الأخطاء، يتم إجراء التحقق للتحقق من صحة الكود والتحقق من الصحة للتحقق مما إذا كان المنتج يلبي المتطلبات المحددة.
1. طرق الاختبار الثابتة
تُستخدم الأساليب الثابتة لإجراء عمليات الفحص ومراجعة مواصفات المكونات دون تنفيذها. تتضمن تقنية التحليل الثابت مراجعة وتحليل بنية البرامج بشكل منهجي وإثبات صحتها. يهدف التحليل الثابت إلى تحليل المستندات التي تم تطويرها في جميع مراحل دورة الحياة ويتكون من فحص كود المصدر والتحكم الشامل في البرنامج.
فحص البرمجيات هو فحص ثابت لامتثال البرنامج للمواصفات المحددة؛ ويتم إجراؤه من خلال تحليل التمثيلات المختلفة لنتائج التصميم (الوثائق أو المتطلبات أو المواصفات أو الرسوم البيانية أو الكود المصدري للبرامج) في عمليات دورة الحياة. توفر المراجعات وعمليات التفتيش على نتائج التصميم ومدى امتثالها لمتطلبات العملاء المزيد جودة عاليةأنظمة البرمجيات التي تم إنشاؤها.
2. طرق الاختبار الديناميكية
طريقة "الصندوق الأسود". عند استخدام هذه الطريقة، يتم استخدام معلومات حول المشكلة التي يتم حلها، ولكن لا يُعرف أي شيء عن بنية البرنامج. الهدف من الاختبار وفقًا لهذا المبدأ هو تحديد الحد الأقصى لعدد الأخطاء باختبار واحد باستخدام مجموعة فرعية صغيرة من بيانات الإدخال المحتملة.
تُستخدم طرق الاختبار المبنية على هذا المبدأ لاختبار الوظائف المنفذة في البرنامج عن طريق التحقق من وجود تناقضات بين السلوك الفعلي للوظائف والسلوك المتوقع في ضوء مواصفات المتطلبات. أثناء التحضير لهذا الاختبار، يتم إنشاء جداول الحالة وأعمدة السبب والنتيجة 1 ومناطق الأعطال. بالإضافة إلى ذلك، يتم إعداد حالات الاختبار التي تأخذ في الاعتبار المعلمات والظروف البيئية التي تؤثر على سلوك الوظائف.
طريقة الصندوق الأبيض.
تتيح لك هذه الطريقة فحص البنية الداخلية للبرنامج، ويعتبر اكتشاف جميع الأخطاء في البرنامج معيارًا للاختبار الشامل لمسارات تدفق التحكم، ومن بينها:
معيار تغطية المشغل - يجب أن تضمن مجموعة الاختبارات معًا اجتياز كل مشغل مرة واحدة على الأقل؛
معيار اختبار الفرع (المعروف أيضًا باسم تغطية القرار أو تغطية النقل) - يجب أن تضمن مجموعة الاختبارات معًا اجتياز كل فرع أو مخرج مرة واحدة على الأقل.
3. الاختبارات الوظيفية
الغرض من الاختبار الوظيفي هو اكتشاف التناقضات بين السلوك الفعلي للوظائف المنفذة والسلوك المتوقع وفقًا للمواصفات والمتطلبات الأولية. يجب أن تغطي الاختبارات الوظيفية جميع الوظائف المنفذة، مع مراعاة أنواع الأخطاء الأكثر احتمالا. تهدف سيناريوهات الاختبار التي تجمع بين الاختبارات الفردية إلى التحقق من جودة الحلول للمشكلات الوظيفية.
يتم إنشاء الاختبارات الوظيفية من مواصفات الوظيفة ومعلومات التصميم ونص لغة البرمجة وتستخدم لتحديد مدى اكتمال تنفيذ المهام الوظيفية ومدى امتثالها للمتطلبات الأصلية.
تشمل مهام الاختبار الوظيفي ما يلي:
تحديد المتطلبات الوظيفية المتعددة؛
تحديد الوظائف الخارجية وبناء تسلسلات الوظائف وفقًا لاستخدامها في النظام البرمجي؛
تحديد مجموعة البيانات المدخلة لكل وظيفة وتحديد مجالات التغيير فيها.
بناء حالات الاختبار وسيناريوهات اختبار الوظيفة؛
تحديد وتقديم جميع المتطلبات الوظيفية باستخدام حالات الاختبار وإجراء اختبار الأخطاء في البرنامج وعند التفاعل مع البيئة.
ترتبط الاختبارات التي تم إنشاؤها باستخدام معلومات التصميم بهياكل البيانات والخوارزميات والواجهات بين المكونات الفردية وتستخدم لاختبار المكونات وواجهاتها. الهدف الرئيسي هو ضمان اكتمال واتساق الوظائف المنفذة والواجهات بينها.
5. أنواع أخطاء ANSI/IEEE-7 29 -8 3
خطأ (خطأ) - حالة البرنامج التي يتم فيها إنتاج نتائج غير صحيحة، والسبب هو وجود عيوب (خلل) في بيانات البرنامج أو في العملية التكنولوجيةتطورها، مما يؤدي إلى تفسير غير صحيح معلومات اساسيةوبالتالي إلى قرار غير صحيح.
الخلل في البرنامج هو نتيجة لأخطاء المطور في أي مرحلة من مراحل التطوير، والتي قد تكون موجودة في مواصفات المصدر أو التصميم، أو نصوص كود البرنامج، أو الوثائق التشغيلية، وما إلى ذلك. أثناء تنفيذ البرنامج، قد يتم اكتشاف خلل أو فشل.
الفشل هو انحراف برنامج عن العمل أو عدم قدرة البرنامج على أداء وظائف محددة بالمتطلبات والقيود، وهو ما يعتبر حدثًا يساهم في انتقال البرنامج إلى حالة غير صالحة للتشغيل بسبب الأخطاء والعيوب المخبأة فيه أو فشل في بيئة التشغيل. قد يكون الفشل نتيجة للأسباب التالية:
مواصفات خاطئة أو متطلبات محذوفة، مما يعني أن المواصفات لا تعكس بدقة ما قصده المستخدم؛
قد تحتوي المواصفات على متطلبات لا يمكن تلبيتها مع الأجهزة والبرامج المحددة؛
قد يحتوي تصميم البرنامج على أخطاء (على سبيل المثال، تم تصميم قاعدة البيانات بدون وسائل حماية ضد وصول المستخدم غير المصرح به، ولكن الحماية مطلوبة)؛
قد يكون البرنامج غير صحيح، أي. ينفذ خوارزمية غير عادية أو لم يتم تنفيذها بالكامل.
خاتمة
إن معايير GOST الروسية المتعلقة بالتحقق من البرمجيات واختبارها هي ترجمة للمعايير "البرجوازية"، مثل ISO 12207 وANSI/IEEE-729-83 وغيرها (هناك الكثير منها). والمشكلة هي أن هذه المعايير الدولية تعالج قضايا الاختبار والتحقق بشكل مختلف. لا يعني أنهم يتعارضون تماما مع بعضهم البعض، لكنهم يمكن أن يسببوا الحيرة.
تمت صياغة كل هذه المعايير في الثمانينيات من القرن الماضي لصناعة الفضاء الأمريكية. وفي السنوات اللاحقة، تم تصحيحها وإعادة نشرها، لكن الخلافات والتناقضات في الوثائق ظلت قائمة.
الخلاصة: يجب أن يُنظر إلى هيكل التحقق والتحقق وطرق الاختبار على أنه مشروط.
فهرس
1. الموسوعة الحرة wikipedia.org
2. كوليامين ف. طرق التحقق من البرمجيات م: معهد برمجة النظم، 2008
3. Lavrishcheva E., Petrukhin V. محاضرة "طرق التحقق واختبار البرامج والأنظمة": NOU "INTUIT" http://www.intuit.ru/studies/professional_retraining/944/courses/237/print_lecture/6130
تم النشر على موقع Allbest.ru
...وثائق مماثلة
إن دورة حياة البرنامج هي عملية مستمرة تبدأ باتخاذ قرار بشأن الحاجة إلى إنشاء برنامج وتنتهي بإزالته بالكامل من الخدمة. مناهج رايلي وليمان وبوم في تحديد دورة حياة البرمجيات.
الملخص، أضيف في 11/01/2009
مفهوم تكنولوجيا تطوير البرامج. أساسيات تصميم البرمجيات. نماذج دورة الحياة التي نشأت تاريخياً أثناء تطوير نظرية تصميم البرمجيات. النماذج الحلزونية والمتتالية والتكرارية.
تمت إضافة العرض بتاريخ 11/05/2015
تاريخ التطور وأنواع اختبار البرمجيات. التثبيت والانحدار والتكوين والتكامل والتعريب واختبار الوحدة. طرق تقليل كثافة العمالة في اختبار الوحدة للتطبيق المطور.
تمت إضافة الدورة التدريبية في 12/16/2015
استعصاء مشكلة اختبار البرمجيات. أنواع ومستويات الاختبار. استراتيجيات الاختبار من أسفل إلى أعلى ومن أعلى إلى أسفل. طرق الصندوق "الأبيض" و"الأسود". الاختبار الآلي واليدوي. التطوير القائم على الاختبار.
تمت إضافة الدورة التدريبية في 22/03/2015
متطلبات تكنولوجيا تصميم البرمجيات. تكوين ووصف مراحل دورة حياة البرنامج الكاملة. تصنيف نماذج دورة حياة البرمجيات وخصائصها. منهجيات تطوير البرمجيات، تقنيات البرمجة المتطرفة.
تمت إضافة العرض بتاريخ 19/09/2016
تاريخ اختبار البرمجيات والأهداف والميزات الرئيسية لتنفيذه. أنواع وأنواع الاختبارات ومستويات أتمتتها. الاستخدام والبحث التقنيات اللازمة. دورة كاملةتشغيل نظام المراقبة بأكمله.
أطروحة، أضيفت في 05/03/2018
المعايير الدولية الأساسية في هذا المجال تقنيات المعلومات. المعيار الدولي ISO/IEC 9126. الجودة ودورة الحياة. خصائص سمات الجودة الداخلية والخارجية. تحليل وظائف البرمجيات.
تمت إضافة التقرير في 13/06/2017
أهداف وغايات هندسة البرمجيات. مفهوم البرمجيات. ستة مبادئ الاستخدام الفعالبرمجة. أنواع البرمجيات: على مستوى النظام، والشبكة، والتطبيق. مبادئ بناء البرمجيات.
تمت إضافة الدورة التدريبية في 29/06/2010
الخصائص العامةنماذج دورة الحياة الرئيسية: المتتالية، التزايدية، الحلزونية. مرحلة كجزء من عملية إنشاء البرنامج، وتقتصر على إطار زمني محدد وتنتهي بإصدار منتج معين.
تمت إضافة العرض بتاريخ 27/12/2013
المعلوماتية في روسيا. سوق برمجة. المهام الرئيسية للتوحيد القياسي وإصدار الشهادات والترخيص في مجال المعلوماتية. مجموعة من الأساليب الهندسية وأدوات إنشاء البرمجيات. دورة حياة البرمجيات.
يعد التحقق والتحقق من الصحة بمثابة عمليات الاختبار والمراجعة التي تتحقق من أن البرنامج يلبي مواصفاته ومتطلبات العملاء. يغطي التحقق والشهادة دورة حياة البرنامج الكاملة - حيث يبدأان في مرحلة تحليل المتطلبات وينتهيان بالتحقق من رمز البرنامج في مرحلة اختبار نظام البرنامج النهائي.
التحقق والشهادة ليسا نفس الشيء، على الرغم من أنه من السهل الخلط بينهما. وباختصار يمكن تحديد الفرق بينهما على النحو التالي:
يجيب التحقق على سؤال ما إذا كان النظام قد تم إنشاؤه بشكل صحيح؛
تجيب الشهادة على سؤال ما إذا كان النظام يعمل بشكل صحيح.
وفقًا لهذه التعريفات، يتحقق التحقق من امتثال البرنامج لمواصفات النظام، ولا سيما المتطلبات الوظيفية وغير الوظيفية. الشهادة هي عملية أكثر عمومية. أثناء عملية الاعتماد، من الضروري التأكد من أن منتج البرنامج يلبي توقعات العميل. تتبع الشهادة التحقق لتحديد مدى تلبية النظام ليس فقط للمواصفات، ولكن أيضًا لتوقعات العميل.
كما ذكرنا سابقًا، في المراحل الأولى من تطوير البرمجيات، تعد شهادة متطلبات النظام أمرًا مهمًا للغاية. الأخطاء والسهو شائعة في المتطلبات؛ وفي مثل هذه الحالات، من المحتمل ألا يلبي المنتج النهائي توقعات العميل. لكن بالطبع، لا يمكن للتحقق من صحة المتطلبات تحديد جميع المشكلات الموجودة في مواصفات المتطلبات. في بعض الأحيان يتم اكتشاف أوجه القصور والأخطاء في المتطلبات فقط بعد اكتمال تنفيذ النظام.
تستخدم عمليات التحقق وإصدار الشهادات تقنيتين رئيسيتين للتحقق من الأنظمة وتحليلها.
1. فحص البرمجيات.تحليل تمثيلات النظام المختلفة والتحقق منها، مثل وثائق مواصفات المتطلبات أو المخططات المعمارية أو كود مصدر البرنامج. يتم إجراء الفحص في جميع مراحل عملية تطوير نظام البرمجيات. بالتوازي مع التفتيش، يمكن إجراء التحليل التلقائي للكود المصدري للبرنامج والوثائق ذات الصلة. يعد الفحص والتحليل الآلي من طرق التحقق والتحقق الثابتة لأنها لا تتطلب نظامًا قابلاً للتنفيذ.
2. اختبار البرمجيات.قم بتشغيل التعليمات البرمجية القابلة للتنفيذ مع بيانات الاختبار وفحص خصائص الإخراج والأداء لمنتج البرنامج للتحقق من أن النظام يعمل بشكل صحيح. يعد الاختبار طريقة ديناميكية للتحقق وإصدار الشهادات حيث يتم تطبيقه على نظام قيد التشغيل.
في التين. يوضح الشكل 20.1 مكان الفحص والاختبار في عملية تطوير البرمجيات. تشير الأسهم إلى مراحل عملية التطوير التي يمكن تطبيق هذه الأساليب فيها. وفقًا لهذا المخطط، يمكن إجراء الفحص في جميع مراحل عملية تطوير النظام، ويمكن إجراء الاختبار في الحالات التي يتم فيها إنشاء نموذج أولي أو برنامج قابل للتنفيذ.
تتضمن طرق الفحص ما يلي: فحص البرنامج، والتحليل التلقائي لشفرة المصدر، والتحقق الرسمي. لكن الأساليب الثابتة يمكنها فقط التحقق من امتثال البرامج للمواصفات، ولا يمكن استخدامها للتحقق من الأداء الصحيح للنظام. بالإضافة إلى ذلك، لا يمكن التحقق من الخصائص غير الوظيفية مثل الأداء والموثوقية باستخدام الطرق الثابتة. لذلك، لتقييم الخصائص غير الوظيفية، يتم إجراء اختبار النظام.
أرز. 20.1. التحقق وإصدار الشهادات الثابتة والديناميكية
على الرغم من الاستخدام الواسع النطاق لفحص البرمجيات، لا يزال الاختبار هو الطريقة السائدة للتحقق وإصدار الشهادات. الاختبار هو اختبار تشغيل البرامج ببيانات مشابهة للبيانات الحقيقية التي ستتم معالجتها أثناء تشغيل النظام. يتم الكشف عن وجود العيوب وعدم المطابقة في البرنامج من خلال فحص بيانات المخرجات وتحديد الشذوذ منها. يتم إجراء الاختبار في مرحلة تنفيذ النظام (للتأكد من أن النظام يلبي توقعات المطورين) وبعد الانتهاء من تنفيذه.
يتم استخدام أنواع مختلفة من الاختبارات في مراحل مختلفة من عملية تطوير البرمجيات.
1. اختبار العيوبيتم إجراؤها لاكتشاف التناقضات بين البرنامج ومواصفاته والتي تنتج عن أخطاء أو عيوب في البرامج. تم تصميم هذه الاختبارات لتحديد الأخطاء في النظام، وليس لمحاكاة تشغيله.
2. الاختبارات الإحصائيةيقيم أداء وموثوقية البرامج، وكذلك تشغيل النظام في أوضاع التشغيل المختلفة. تم تصميم الاختبارات لمحاكاة تشغيل النظام الحقيقي باستخدام بيانات الإدخال الحقيقية. يتم تقييم موثوقية النظام من خلال عدد حالات الفشل التي لوحظت في تشغيل البرامج. يتم تقييم الأداء من خلال قياس إجمالي وقت تنفيذ العمليات ووقت استجابة النظام عند معالجة بيانات الاختبار.
الهدف الرئيسيالتحقق والاعتماد - للتأكد من أن النظام "مناسب للغرض". إن امتثال نظام برمجي للغرض المقصود منه لا يعني أنه يجب أن يكون خاليًا تمامًا من الأخطاء. وبدلاً من ذلك، يجب أن يخدم النظام بشكل معقول الأغراض التي تم تصميمه من أجلها. المستوى المطلوب موثوقية الامتثاليعتمد ذلك على الغرض من النظام وتوقعات المستخدم وظروف سوق البرمجيات.
1. الغرض من البرنامج.يعتمد مستوى الثقة في الامتثال على مدى أهمية البرنامج الذي يتم تطويره وفقًا لمعايير معينة. على سبيل المثال، ينبغي أن يكون مستوى الثقة في الأنظمة ذات الأهمية الحيوية للسلامة أعلى بكثير من مستوى الثقة في أنظمة البرمجيات النموذجية التي تم تطويرها لإظهار بعض الأفكار الجديدة.
2. توقعات المستخدم.ومن المحزن أن نلاحظ أن معظم المستخدمين حاليًا لديهم متطلبات برمجية منخفضة. لقد اعتاد المستخدمون على حالات الفشل التي تحدث أثناء تشغيل البرامج بحيث لا يتفاجأون بذلك. إنهم على استعداد لتحمل فشل النظام إذا كانت فوائد استخدامه تفوق العيوب. ومع ذلك، منذ أوائل التسعينيات، بدأ تناقص تحمل المستخدم للفشل في أنظمة البرمجيات تدريجيًا. في الآونة الأخيرة، أصبح إنشاء أنظمة غير موثوقة غير مقبول عمليا، لذلك تحتاج الشركات التي تقوم بتطوير منتجات البرمجيات إلى إيلاء المزيد والمزيد من الاهتمام للتحقق من البرامج وإصدار الشهادات لها.
3. ظروف سوق البرمجيات.عند تقييم نظام برمجي، يجب على البائع معرفة الأنظمة المنافسة، والسعر الذي يرغب المشتري في دفعه مقابل النظام، والتاريخ المستهدف لإصدار النظام إلى السوق. إذا كان لدى شركة التطوير العديد من المنافسين، فمن الضروري تحديد موعد دخول النظام إلى السوق قبل نهاية الاختبار الكامل وتصحيح الأخطاء، وإلا فقد يكون المنافسون أول من يدخل السوق. إذا كان العملاء غير راغبين في شراء البرامج بسعر مرتفع، فقد يكونون على استعداد لتحمل المزيد من حالات فشل النظام. ويجب أن تؤخذ كل هذه العوامل في الاعتبار عند تحديد تكاليف عملية التحقق وإصدار الشهادات.
كقاعدة عامة، أثناء التحقق وإصدار الشهادات، يتم اكتشاف الأخطاء في النظام. يتم إجراء تغييرات على النظام لتصحيح الأخطاء. هذا عملية التصحيحيتم دمجها عادةً مع عمليات التحقق والتأهيل الأخرى. ومع ذلك، فإن الاختبار (أو بشكل عام، التحقق وإصدار الشهادات) وتصحيح الأخطاء هما عمليتان مختلفتان ولهما أهداف مختلفة.
1. التحقق والشهادة هي عملية اكتشاف العيوب في نظام البرمجيات.
2. تصحيح الأخطاء هو عملية تحديد العيوب (الأخطاء) وتصحيحها (الشكل 20.2).
أرز. 20.2. عملية التصحيح
لا توجد طرق بسيطة لتصحيح أخطاء البرامج. يكتشف مصححو الأخطاء ذوو الخبرة الأخطاء من خلال مقارنة أنماط مخرجات الاختبار مع مخرجات الأنظمة قيد الاختبار. يتطلب تحديد موقع الخطأ معرفة أنواع الأخطاء وأنماط الإخراج ولغة البرمجة وعملية البرمجة. المعرفة حول عملية تطوير البرمجيات مهمة جدًا. يعرف مصححو الأخطاء أخطاء المبرمجين الأكثر شيوعًا (على سبيل المثال، الأخطاء المرتبطة بزيادة قيمة العداد). تؤخذ أيضًا في الاعتبار الأخطاء النموذجية لبعض لغات البرمجة، على سبيل المثال تلك المرتبطة باستخدام المؤشرات في لغة C.
إن تحديد موقع الأخطاء في رمز البرنامج ليس دائمًا عملية سهلة لأن الخطأ لا يقع بالضرورة بالقرب من المكان الذي حدثت فيه المشكلة في رمز البرنامج. لتوطين الأخطاء، يقوم مبرمج مصحح الأخطاء بتطوير اختبارات برمجية إضافية تساعد في تحديد مصدر الخطأ في البرنامج. قد يكون من الضروري تتبع تنفيذ البرنامج يدويًا.
تعد أدوات تصحيح الأخطاء التفاعلية جزءًا من مجموعة أدوات دعم اللغة المدمجة مع نظام تجميع التعليمات البرمجية. أنها توفر بيئة تنفيذ خاصة للبرنامج يمكن من خلالها الوصول إلى جدول المعرفات، ومن هناك، إلى القيم المتغيرة. غالبًا ما يتحكم المستخدمون في تنفيذ البرنامج بطريقة خطوة بخطوة، وينتقلون بالتسلسل من عبارة إلى أخرى. بعد تنفيذ كل عبارة، يتم فحص قيم المتغيرات وتحديد الأخطاء المحتملة.
يتم تصحيح الخطأ المكتشف في البرنامج، وبعد ذلك من الضروري التحقق من البرنامج مرة أخرى. للقيام بذلك، يمكنك فحص البرنامج مرة أخرى أو تكرار الاختبار السابق. يتم استخدام إعادة الاختبار للتأكد من أن التغييرات التي تم إجراؤها على البرنامج لم تسبب أخطاء جديدة في النظام، لأنه في الممارسة العملية فإن نسبة عالية من "إصلاحات الأخطاء" إما تفشل تمامًا أو تقدم أخطاء جديدة في البرنامج.
من حيث المبدأ، أثناء إعادة الاختبار بعد كل إصلاح، يجب إجراء جميع الاختبارات مرة أخرى، ولكن في الممارسة العملية يعد هذا الأسلوب مكلفًا للغاية. لذلك، عند التخطيط لعملية اختبار، يتم تحديد التبعيات بين أجزاء النظام وتعيين اختبارات لكل جزء. ومن الممكن بعد ذلك تتبع عناصر البرنامج باستخدام حالات اختبار خاصة (بيانات اختبار) مصممة خصيصًا لتلك العناصر. إذا تم توثيق نتائج التتبع، فيمكن استخدام مجموعة فرعية فقط من مجموعة بيانات الاختبار بأكملها لاختبار عنصر البرنامج الذي تم تغييره ومكوناته التابعة.
التخطيط للتحقق والتأهيل
التحقق وإصدار الشهادات عملية مكلفة. بالنسبة للأنظمة الكبيرة، مثل أنظمة الوقت الفعلي ذات القيود غير الوظيفية المعقدة، يتم إنفاق نصف ميزانية تطوير النظام على عملية التحقق والتحقق من الصحة. ولذلك، فإن الحاجة إلى التخطيط الدقيق لهذه العملية واضحة.
وينبغي أن يبدأ التخطيط للتحقق وإصدار الشهادات، باعتبارها إحدى مراحل تطوير أنظمة البرمجيات، في أقرب وقت ممكن. في التين. يوضح الشكل 20.3 نموذج تطوير البرمجيات الذي يأخذ في الاعتبار عملية تخطيط الاختبار. وهنا يبدأ التخطيط في مراحل المواصفات وتصميم النظام. يسمى هذا النموذج أحيانًا بالنموذج V (لرؤية الحرف V، تحتاج إلى تدوير الشكل 20.3 بمقدار 90 درجة). ويوضح هذا الرسم البياني أيضًا تقسيم عملية التحقق والتأهيل إلى عدة مراحل، مع إجراء الاختبارات المقابلة في كل مرحلة.
أرز. 20.3. تخطيط الاختبار أثناء التطوير والاختبار
في عملية التخطيط للتحقق وإصدار الشهادات، من الضروري تحديد العلاقة بين الطرق الثابتة والديناميكية للتحقق من النظام، وتحديد المعايير والإجراءات الخاصة بفحص البرامج واختبارها، والموافقة الخريطة التكنولوجيةفحوصات البرنامج (انظر القسم 19.2) ووضع خطة اختبار البرنامج. يعتمد ما إذا كان يجب إيلاء المزيد من الاهتمام للفحص أو الاختبار على نوع النظام الذي يتم تطويره وخبرة المنظمة. كلما زادت أهمية النظام، زادت الحاجة إلى إيلاء المزيد من الاهتمام لطرق التحقق الثابتة.
تركز خطة التحقق والتحقق على معايير عملية الاختبار بدلاً من التركيز على وصف اختبارات محددة. هذه الخطة ليست مخصصة للإدارة فقط، ولكنها مخصصة في المقام الأول لأولئك المشاركين في تطوير النظام واختباره. وتمكن الخطة الموظفين الفنيين من الحصول على صورة كاملة لاختبار النظام وتخطيط عملهم في هذا السياق. توفر الخطة أيضًا معلومات للمديرين المسؤولين عن التأكد من أن فريق الاختبار لديه جميع الأجهزة والبرامج اللازمة المتاحة.
خطة الاختبار ليست وثيقة غير قابلة للتغيير. وينبغي مراجعتها بانتظام لأن الاختبار يعتمد على عملية تنفيذ النظام. على سبيل المثال، إذا لم يكتمل تنفيذ أي جزء من النظام، فمن المستحيل اختبار تجميع النظام. ولذلك يجب مراجعة الخطة بشكل دوري للتأكد من إمكانية الاستعانة بأفراد الاختبار في وظائف أخرى.
غالبًا ما يتم الخلط بين مفهومي التحقق من الصحة والتحقق. بالإضافة إلى ذلك، غالبًا ما يتم الخلط بين التحقق من صحة متطلبات النظام والتحقق من صحة النظام نفسه. أقترح النظر في هذه المسألة.
في المقالة، نظرت إلى طريقتين لنمذجة كائن ما: ككل وكبنية. وفي المقال الحالي سنحتاج إلى هذا التقسيم.
دعونا نحصل على كائن وظيفي مصمم. دعونا نعتبر هذا الكائن جزءًا من تصميم كائن وظيفي آخر. يجب أن يكون هناك وصف لبناء كائن، بحيث يحتوي على وصف للكائن. في مثل هذا الوصف، يكون للكائن وصف ككل، أي أنه يتم وصف واجهاته للتفاعل مع الكائنات الأخرى في إطار تصميم الكائن. دع وصف الكائن كهيكل يتم تقديمه. يجب أن يكون هناك كائن معلومات يحتوي على متطلبات تصميم وصف الكائن كهيكل. يجب أن تكون هناك مجموعة من المعرفة تحتوي على قواعد الاستدلال، والتي على أساسها يتم الحصول على وصف الكائن كبنية من وصف الكائن ككل. مجموعة المعرفة هي ما يتم تدريسه للمصممين في المعاهد - الكثير والكثير من المعرفة. فهي تسمح، بناءً على المعرفة حول كائن ما، بتصميم هيكله.
لذلك، يمكننا أن نبدأ. يمكننا التأكيد على أنه إذا تم وصف الكائن ككل بشكل صحيح، وإذا كانت المعرفة صحيحة، وإذا تم اتباع قواعد الاستدلال، فإن الوصف الناتج لتصميم الكائن سيكون صحيحًا. وهذا هو، بناء على هذا الوصف، سيتم بناء كائن وظيفي مطابق ظروف حقيقيةعملية. ما هي المخاطر التي قد تنشأ:
1. استخدام معرفة غير صحيحة عن الكائن. قد لا يتوافق نموذج الشيء الموجود في أذهان الناس مع الواقع. لم يعرفوا الخطر الحقيقي للزلازل، على سبيل المثال. وفقا لذلك، قد يتم صياغة متطلبات الكائن بشكل غير صحيح.
2. تسجيل غير كامل للمعرفة حول الكائن - تم تفويت شيء ما وارتكاب أخطاء. على سبيل المثال، علموا بالرياح، لكنهم نسوا ذكرها. قد يؤدي هذا إلى وصف غير كامل لمتطلبات الكائن.
3. مجموعة غير صحيحة من المعرفة. لقد تعلمنا أن نعطي الأولوية للكتلة على العوامل الأخرى، ولكن اتضح أنه يتعين علينا زيادة السرعة.
4. التطبيق غير الصحيح لقواعد الاستدلال على وصف الكائن. الأخطاء المنطقية، هناك شيء مفقود في متطلبات تصميم الكائن، وتتبع المتطلبات مكسورة.
5. التسجيل غير الكامل لنتائج تصميم النظام. لقد أخذوا كل شيء في الاعتبار، وحسبوا كل شيء، لكنهم نسوا تدوينه.
6. النظام الذي تم إنشاؤه لا يتوافق مع الوصف.
من الواضح أن جميع القطع الأثرية للمشروع تظهر، كقاعدة عامة، في شكلها المكتمل فقط في نهاية المشروع، وحتى ذلك الحين ليس دائمًا. لكن إذا افترضنا أن التنمية شلالية فإن المخاطر كما وصفت. التحقق من كل خطر هو عملية محددة يمكن تسميتها. إذا كان أي شخص مهتمًا، فيمكنك محاولة التوصل إلى هذه الشروط والتعبير عنها.
ما هو التحقق؟ في اللغة الروسية، التحقق هو التحقق من الامتثال للقواعد. يتم وضع القواعد في شكل وثيقة. أي أنه يجب أن يكون هناك مستند يتضمن متطلبات التوثيق. إذا كانت الوثائق تفي بمتطلبات هذه الوثيقة، فقد اجتازت عملية التحقق.
ما هو التحقق من الصحة؟ في اللغة الروسية، التحقق هو التحقق من صحة الاستنتاجات. وهذا يعني أنه يجب أن يكون هناك مجموعة من المعرفة التي تصف كيفية الحصول على وصف للتصميم بناءً على بيانات حول الكائن. التحقق من التطبيق الصحيح لهذه الاستنتاجات هو التحقق من الصحة. يتضمن التحقق التحقق من الوصف للتأكد من اتساقه واكتماله وسهولة فهمه.
غالبًا ما يتم الخلط بين التحقق من صحة المتطلبات والتحقق من صحة المنتج المبني على تلك المتطلبات. لا يجب أن تفعل ذلك.
