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

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

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

إدارة نموذج الاختبار هي عملية مستمرة طوال الوقت دورة الحياةمنتج.

تغطية نموذج الاختبار

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

جودة البرنامج النصي

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

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

المستويات الممكنة لوصف حالات الاختبار:

في المستوى الرابع ، يمكن استبدال الاتفاقية مع العميل بالاتفاق.

يمكن أن تكون معايير الجودة لوصف حالات الاختبار كما يلي:

• يجب كتابة حالات الاختبار وفقًا للمتطلبات

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

• استخدم الشروط المسبقة التفصيلية

كيف توفر الوقت في حالات الاختبار؟

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

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

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

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

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

تحديث نموذج الاختبار

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

للتحديث يمكنك الاحتفاظ "بمصفوفة المتطلبات"(مصفوفة تتبع المتطلبات): بعد كل تغيير في متطلب معين ، يتم تحديد جميع سيناريوهات الاختبار المتعلقة بهذا المطلب من نظام تتبع الاختبار وتحديثها.

ضوابط نموذج الاختبار:

• اختبار السكك الحديدية
• رابط الاختبار
• جيرا + زفير
• مدير اختبار Microsoft (MTM)
• تتفوق

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

أهداف عملية الاختبار

الغرض من الاختبار هو تقييم الجودة منتج البرنامجعبر

• فحوصات تفاعل المكونات ؛
• التحقق من التكامل الصحيح للمكونات ؛
• التحقق من دقة تنفيذ كافة المتطلبات وتحديد العيوب.

ملامح عملية الاختبار في RUP

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

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

مطور اختبارمسؤول عن تخطيط وتطوير وتنفيذ الاختبارات. يقوم بإنشاء خطة ونموذج اختبار ، وإجراءات اختبار (انظر أدناه) وتقييم نتائج الاختبار.

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

الآثار

أثناء الاختبار ، يتم إنشاء المستندات التالية:

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

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

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

نتائج الإختباروالبيانات التي تم الحصول عليها أثناء تنفيذ الاختبارات.

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

عيوب- هذه هي أوصاف لحقائق عدم امتثال النظام للمتطلبات التي تم العثور عليها أثناء الاختبار. هم نوع من طلبات التغيير.

يتم تنفيذ أعمال الاختبار في كل تكرار في جميع المراحل ، ولكن تختلف الأهداف والغايات في المراحل المختلفة من المشروع اختلافًا كبيرًا.

مرحلة دخول المشروع. في هذه المرحلة ، يتم التحضير للاختبار. ويشمل:

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

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

• تطوير سيناريوهات الاختبار.
• إنشاء نصوص الاختبار.
• تطوير مهام الرقابة.
• تطوير طرق الاختبار.
• تطوير نموذج عبء العمل.

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

• قم بإنشاء خطة اختبار لكل تكرار.
• صقل وإضافة نموذج الاختبار.
• تنفيذ الاختبارات.
• وصف العيوب التي تم العثور عليها.
• وصف نتائج الاختبار.
• تقييم نتائج الاختبار.

بناءً على نتائج الاختبار ، يتم إجراء تغييرات على رمز البرنامج لإزالة العيوب المحددة ، وبعد ذلك يتم إعادة الاختبار.

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

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

دعم فعال

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

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

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

نموذج الشلال (نموذج دورة حياة البرنامج المتسلسل الخطي)

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

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

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

تعرف على المزيد حول نموذج الشلال من المقالة السابقة..

نموذج V (نموذج التحقق والتحقق)

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

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

قد تختلف الخطوات الرئيسية لهذه المنهجية ، ولكنها تشمل عادةً ما يلي:

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

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

نموذج تزايدي

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

1. التصميم والتطوير
2. اختبارات
3. تطبيق.

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

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

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

نموذج حلزوني

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

1. تخطيط
2. تحليل المخاطر
3. تطوير
4. صف دراسي

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

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

اقرأ المزيد عن النموذج الحلزوني في منشور المدونة السابق..

رشيق

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

تعرف على المزيد حول Agile(ملاحظة - المقال باللغة الإنجليزية).

البرمجة المتطرفة (XP ، البرمجة المتطرفة)

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

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

سكرم

Scrum - جزء من منهجية Agile ، وهو إطار عمل تدريجي تكراري تم إنشاؤه لإدارة عملية تطوير البرامج. وفقًا لمبادئ Scrum ، يجب أن يشارك فريق الاختبار في الخطوات التالية:

• المشاركة في تخطيط سكروم
• دعم اختبار الوحدة
• اختبار قصة المستخدم
• تعاون مع العميل ومالك المنتج لتحديد معايير القبول
• توفير الاختبار الآلي

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

في الوقت نفسه ، أدت مبادئ منهجية Agile في Scrum إلى ظهور ميزات محددة:

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

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

استنتاج

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

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

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

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

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

لماذا تقيم؟

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

1. البحث عن نقاط ضعفك.بطبيعة الحال ، نحن بحاجة إلى هذا؟ ليس فقط للحزن ، ولكن لمعرفة المواضع التي تحتاج إلى تحسينات. ما المجالات الوظيفية التي لا تغطيها الاختبارات؟ ما الذي لم نتحقق منه؟ أين هي أكبر مخاطر فقدان الأخطاء؟
2. نادرًا ما نحصل على تغطية 100٪ من نتائج التقييم. ما الذي يجب تحسينه؟ اين نذهب؟ ما هي النسبة الآن؟ كيف يمكننا زيادتها بأي مهمة؟ ما السرعة التي يمكن أن نصل بها إلى 100؟ كل هذه الأسئلة تضفي الشفافية والوضوح على عمليتنا.، والإجابات عليها من خلال تقدير التغطية.
3. محور الاهتمام.لنفترض أن منتجنا يحتوي على حوالي 50 مجالًا وظيفيًا مختلفًا. يخرج نسخة جديدة، ونبدأ في اختبار الأول منها ، ونجد الأخطاء المطبعية هناك ، والأزرار التي تحركت بضع وحدات بكسل ، وتفاهات أخرى ... والآن انتهى وقت الاختبار ، وتم اختبار هذه الوظيفة بالتفصيل .. والباقي 50؟ يسمح لنا تقييم التغطية بتحديد أولويات المهام بناءً على الحقائق الحالية والمواعيد النهائية.

كيف تقيم؟

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

تقييم تغطية المتطلبات بالاختبارات

لنفترض أن لديك محللين في فريقك ، وهم لا يقضون وقتهم سدى. وقت العمل. بناءً على نتائج عملهم ، تم إنشاء المتطلبات في RMS (نظام إدارة المتطلبات) - HP QC و MS TFS و IBM Doors و Jira (مع ملحقات إضافية) ، إلخ. في هذا النظام ، يضعون متطلبات تتوافق مع متطلبات المتطلبات (آسف على الحشو). هذه المتطلبات ذرية ، ويمكن تتبعها ، ومحددة ... بشكل عام ، ظروف مثالية للاختبار. ماذا يمكننا أن نفعل في مثل هذه الحالة؟ عند استخدام نهج نصي ، ومتطلبات الارتباط والاختبارات. نجري الاختبارات في نفس النظام ، ونجري اتصالًا باختبار المتطلبات ، وفي أي وقت يمكننا الاطلاع على تقرير حول المتطلبات التي لها اختبارات ، وأي منها لا ، ومتى تم اجتياز هذه الاختبارات ، والنتيجة.
نحصل على خريطة تغطية ، نغطي جميع المتطلبات غير المغطاة ، الجميع سعداء وراضون ، لا تفوتنا الأخطاء ...

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

المشكلة: المتطلبات ليست ذرية.

كما يخطئ المحللون أحيانًا في وجود سلطة في رؤوسهم ، وعادة ما يكون هذا محفوفًا بالمشاكل في المشروع بأكمله. على سبيل المثال ، أنت تطور محرر نصوص ، وقد يكون لديك متطلبان في نظامك (من بين أمور أخرى): "يجب دعم تنسيق html" و "عند فتح ملف بتنسيق غير مدعوم ، تظهر نافذة منبثقة بها سؤال يجب أن تظهر." كم عدد الاختبارات المطلوبة للتحقق الأساسي من المتطلب الأول؟ وللثاني؟ الفرق في الإجابات ، على الأرجح ، حوالي مائة مرة !!! لا يمكننا القول أنه إذا كان هناك اختبار واحد على الأقل في المتطلب الأول ، فهذا يكفي - ولكن حول الاختبار الثاني ، على الأرجح ، تمامًا.

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

1. في هذه الحالة ، يمكن إزالة الحساب التلقائي لتغطية المتطلبات عن طريق الاختبارات - فهي لا تزال لا تحمل عبءًا دلاليًا.
2. لكل متطلب ، بدءًا من الأولوية القصوى ، نقوم بإعداد الاختبارات. عند التحضير ، نقوم بتحليل الاختبارات التي ستكون مطلوبة لهذا المطلب ، فكم سيكون كافياً؟ نجري تحليل اختبار كامل ، ولا نتجاهل "هناك اختبار واحد ، ولكن حسنًا".
3. اعتمادًا على النظام المستخدم ، نقوم بتصدير / تحميل الاختبارات حسب الطلب و ... نقوم باختبار هذه الاختبارات! هل هم كافون؟ من الناحية المثالية ، بالطبع ، يجب إجراء مثل هذا الاختبار مع محلل ومطور لهذه الوظيفة. اطبع الاختبارات ، وأغلق زملائك في غرفة الاجتماعات ، ولا تتركهم حتى يقولون "نعم ، هذه الاختبارات كافية" (يحدث هذا فقط بموافقة مكتوبة ، عندما يتم نطق هذه الكلمات لإلغاء الاشتراك ، حتى بدون تحليل الاختبارات. أثناء المناقشة الشفوية ، سينتقد زملاؤك انتقاداتهم للحوض ، وفقدان الاختبارات ، ومتطلبات سوء الفهم ، وما إلى ذلك - وهذا ليس ممتعًا دائمًا ، ولكنه مفيد جدًا للاختبار!)
4. بعد الانتهاء من الاختبارات عند الطلب والاتفاق على اكتمالها ، يمكن تمييز هذا المتطلب في النظام بالحالة "التي تغطيها الاختبارات". ستعني هذه المعلومات أكثر من "يوجد اختبار واحد على الأقل هنا".

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

المشكلة: لا توجد متطلبات على الإطلاق.

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

1. قم بإنشاء قائمة الميزات. سامي! في شكل google-tablet ، بتنسيق PBI في TFS - اختر أيًا ، طالما أنه ليس تنسيقًا نصيًا. ما زلنا بحاجة إلى جمع الأوضاع! نقوم بتضمين جميع المجالات الوظيفية للمنتج في هذه القائمة ، ونحاول اختيار مستوى عام واحد من التحلل (يمكنك كتابة كائنات البرامج ، أو البرامج النصية للمستخدم ، أو الوحدات النمطية ، أو صفحات الويب ، أو أساليب واجهة برمجة التطبيقات ، أو نماذج الشاشة .. .) - ولكن ليس كل هذا مرة واحدة! صيغة تحليل واحدة تجعل من الأسهل والأكثر وضوحًا عدم تفويت الأشياء المهمة.
2. نقوم بتنسيق اكتمال هذه القائمة مع المحللين والمطورين والشركات ضمن فريقنا ... حاول أن تفعل كل شيء حتى لا تفقد أجزاء مهمة من المنتج! مدى عمق التحليل متروك لك. في ممارستي ، لم يكن هناك سوى عدد قليل من المنتجات التي أنشأنا لها أكثر من 100 صفحة في الجدول ، وكانت هذه منتجات عملاقة. في أغلب الأحيان ، 30-50 سطرًا هي نتيجة قابلة للتحقيق لمزيد من المعالجة الدقيقة. في فريق صغير بدون محللي اختبار مخصصين أكثرسيكون من الصعب للغاية الحفاظ على عناصر fichelista.
3. بعد ذلك ، ننتقل إلى الأولويات ، ونعالج كل سطر من قائمة fichel كما في قسم المتطلبات الموصوف أعلاه. نكتب الاختبارات ونناقشها ونتفق على الكفاية. نقوم بوضع علامة على الحالات ، والتي توجد فيها اختبارات كافية للميزة. نحصل على حالة الاختبارات وتقدمها وتوسيعها من خلال التواصل مع الفريق. الجميع سعداء!

لكن ... ماذا لو تم الحفاظ على المتطلبات ، ولكن ليس بتنسيق يمكن تتبعه؟

المشكلة: المتطلبات لا يمكن تتبعها.

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

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

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

المشكلة: المتطلبات تتغير في كل وقت.

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

1. لنفترض أنك قمت بالفعل بجمع روابط للمعارف التقليدية والمواصفات في شكل قائمة ميزات ، PBI ، المتطلبات ، ملاحظات Wiki ، إلخ. لنفترض أن لديك بالفعل اختبارات لهذه المتطلبات. والآن ، الشرط يتغير! قد يعني هذا تغييرًا في RMS ، أو مهمة في TMS (نظام إدارة المهام) ، أو رسالة في البريد. في كلتا الحالتين ، يؤدي إلى نفس النتيجة: اختباراتك قديمة! أو قد تكون غير ذات صلة. هذا يعني أنها تتطلب التحديث (التغطية بالاختبارات نسخة قديمةالمنتج بطريقة ما لا يعتبر كثيرًا ، أليس كذلك؟)
2. في قائمة الميزات ، في RMS ، في TMS (نظام إدارة الاختبار - testrails ، sitechco ، إلخ) يجب وضع علامة على الاختبارات على أنها غير ذات صلة على الفور وبدون فشل! في HP QC أو MS TFS ، يمكن القيام بذلك تلقائيًا عند تحديث المتطلبات ، وفي جهاز لوحي google أو wiki ، سيتعين عليك وضع أقلام. لكن يجب أن ترى على الفور: الاختبارات غير ذات صلة! هذا يعني أننا ننتظر إعادة المسار الكامل: التحديث ، وإعادة تشغيل تحليل الاختبار ، وإعادة كتابة الاختبارات ، والاتفاق على التغييرات ، وبعد ذلك فقط ضع علامة على الميزة / المتطلبات مرة أخرى على أنها "مغطاة بالاختبارات".

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

المشكلة: لا يوجد وقت كاف لتوثيق الاختبارات.

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

1. ما زلت بحاجة إلى المتطلبات كمتطلبات كاملة أو كقائمة ميزات ، لذلك سيظل أحد الأقسام المذكورة أعلاه ضروريًا ، اعتمادًا على عمل المحللين في المشروع. حصلت على المتطلبات / قائمة الميزات؟
2. نصف استراتيجية اختبار قصيرة ونتفق عليها شفهيًا ، دون توثيق اختبارات محددة! يمكن تحديد هذه الإستراتيجية في عمود جدول ، أو على صفحة wiki ، أو في أحد المتطلبات في RMS ، ويجب الاتفاق عليها مرة أخرى. كجزء من هذه الإستراتيجية ، سيتم إجراء المراجعات بطرق مختلفة ، لكنك ستعرف: متى يتم ذلك آخر مرةتم اختباره وبأي استراتيجية؟ وهذا ، كما ترى ، ليس سيئًا أيضًا! وسيكون الجميع سعداء.

ولكن… ماذا "لكن"؟ أيّ؟؟؟

لنفترض أننا سنلتف حول كل شيء ، وقد تكون المنتجات عالية الجودة معنا!

| تخطيط الدرس للعام الدراسي | المراحل الرئيسية للنمذجة

الدرس 2
المراحل الرئيسية للنمذجة

من خلال دراسة هذا الموضوع سوف تتعلم:

ما هي النمذجة؟
- ما يمكن أن يكون بمثابة نموذج أولي للنمذجة ؛
- ما هو مكان النمذجة في النشاط البشري ؛
- ما هي المراحل الرئيسية للنمذجة ؛
- ما هو نموذج الكمبيوتر ؛
ما هي تجربة الكمبيوتر.

تجربة الكمبيوتر

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

في المدرسة ، تجري تجارب في دروس علم الأحياء والكيمياء والفيزياء والجغرافيا.

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

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

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

خطة التجربة

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

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

اختبار - مجموعة من البيانات الأولية تسمح لك بتحديد صحة بناء النموذج.

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

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

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

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

إجراء البحوث

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

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

يظهر مخطط إعداد وإجراء تجربة كمبيوتر في الشكل 11.7.

أرز. 11.7. مخطط لتجربة الكمبيوتر

تحليل نتائج المحاكاة

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

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

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

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

أسئلة التحكم والمهام

1. ما هما النوعان الرئيسيان لبيان مشكلة النمذجة.

2. في "كتاب المشاكل" المعروف لجي أوستر ، هناك المشكلة التالية:

تعمل الساحرة الشريرة بلا كلل وتحول 30 أميرة إلى يرقات في اليوم. كم يوما ستستغرقها لتحويل 810 أميرة إلى يرقات؟ كم عدد الأميرات في اليوم الذي سيتعين عليهن أن يتحولن إلى يرقات لإنجاز المهمة في 15 يومًا؟
أي سؤال يمكن أن يُعزى إلى نوع "ماذا سيحدث إذا ..." ، وأي سؤال - إلى نوع "كيف نفعل ذلك ..."؟

3. ضع قائمة بأهم أهداف النمذجة المعروفة.

4. إضفاء الطابع الرسمي على المشكلة المرحة من "كتاب مشاكل" جي أوستر:

من مقصورتين تقعان على مسافة 27 كم من بعضهما البعض ، قفز كلبان مشاكسان باتجاه بعضهما البعض في نفس الوقت. الأول يعمل بسرعة 4 كم / ساعة ، والثاني - 5 كم / ساعة.
إلى متى ستبدأ المعركة؟

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

6. ما هي خصائص المراهق الضرورية للتوصية باختيار مهنة؟

7. لماذا يستخدم الكمبيوتر على نطاق واسع في المحاكاة؟

8. قم بتسمية أدوات نمذجة الكمبيوتر التي تعرفها.

9. ما هي تجربة الكمبيوتر؟ اعط مثالا.

10. ما هو اختبار النموذج؟

11. ما هي الأخطاء التي تمت مواجهتها في عملية النمذجة؟ ما الذي يجب عمله عند اكتشاف خطأ؟

12. ما هو تحليل نتائج المحاكاة؟ ما هي الاستنتاجات التي يتم استخلاصها عادة؟