Header Ads Widget

Responsive Advertisement

Embedded Sw Testing - اختبار الانظمة المدمجة #1


 


 

في المقال ده هشارك معاكم ملخص بداية شرح لمحاضرات كنت مقدمها عن التستنج (Testing) في مجال السوفت وير وخصوصا الامبيديد. 

ههنحاول نفهم مع بعض ليه التستنج مهم، وأنواعه، وإزاي بيترتب جوه البروسيس بتاعة تطوير السوفت وير.. خصوصا من وجهة نظر Automotive Process (ASPICE)



ليه أصلاً نعمل تستنج؟

أول انطباع بييجي لأي حد عن التستنج إنه "آخر خط دفاع" قبل ما المنتج يوصل للعميل.

  • التستنج بيأكد إن اللي اتطلب في الـ Requirements هو اللي اتنفذ فعلًا.

  • بيكشف الفجوة بين اللي كنا عايزينه واللي الكود بيعمله.

  • بيوفر وقت وفلوس على الشركة: لأن اكتشاف الغلط بدري أرخص بكتير من اكتشافه بعد ما المنتج ينزل السوق.

ببساطة: التستنج مش رفاهية، ده ضرورة.


التستنج جزء من البروسيس:

في أي شركة محترمة، التستنج مش حاجة جانبية. هو جزء أساسي من دورة حياة السوفت وير (V-Model أو غيره).

  • من أول ما ال customer يطلب حاجة، بتنزل في صورة Requirements.

  • بعد كده تتكسر لـ High Level Design → Component Design → Code.

  • في كل مرحلة بيكون فيه نوع من التستنج مناسب لها.



أنواع التستنج:

خلينا نقول دلوقتى ببساطة إن عندنا 3 مستويات رئيسية:

  1. Unit Testing

    • بيتعمل على مستوى الfunctions فى الكود او على مستوى الComponent نفسه لو الشركة بتعتبره كده.

    • الهدف: أتأكد إن كل جزء صغير شغال لوحده صح.

    • بنحاول يكون Black Box شوية وبيقلب White Box بعد كده.


  1. Integration Testing

    • لما الأجزاء الصغيرة تبدأ تتكلم مع بعض.

    • أو نتأكد مين ينفع يكلم مين فى الSw وامتى.

    • الهدف: أتأكد إن التواصل بينهم مظبوط، مفيش حاجة بتبوّظ حاجة تانية او بتبوظ من حاجة تانية.

    • برضه بنحاول يكون Black Box شوية وبيقلب White Box  بعد كده. وفيه أجزاء منه ضرورى انها تكون White Box..


  1. Validation / Sw Test

  • ده اللي بيتعمل على الSw ككل.

  • الهدف: أتأكد إن المنتج النهائي بيحقق اللي الCustomer طلبه.

  • هنا المفروض Black Box (يعني أتعامل مع السوفت وير من برّه من غير ما أبص على الكود).



الـ Requirements ودورها

الـ Software Requirements Specification (SRS) هي الأساس.

  • بتوصف العلاقة بين الـ Inputs والـ Outputs.

  • كل Requirement بيكون ليه ID، Attributes (زي Safety Level، Delivery Week)، ونص واضح يشرح المطلوب.

  • التستنج بيعتمد عليها بشكل مباشر: لو Requirement مكتوبة غلط أو مش قابلة للتستنج، يبقى عندنا مشكلة من البداية.

عشان كده بيكون فيه Review للـ Requirements من أكتر من طرف:

  • الـ Sw Architect يشوف هل يقدر يصمم السوفتوير لعمل كده؟

  • ال Sw Developers عشان يأكدوا على الArchitect انهم يقدروا ينفذوا ده.

  • الـ Tester يشوف هل يقدر يختبرها؟

  • وأحيانًا تتعدل وتتحدث (بـ Versioning) لحد ما تبقى واضحة وقابلة للتنفيذ.



أمثلة بسيطة جدا من أرض الواقع للتوضيح فقط:

بعض التفاصيل اللى هاقولها هى أصلا اختبار على مستوى الSystem يعنى تجميع الSW و الHw  والشرح كان على Sw Level بس مش موضوعنا دلوقتى..


#1: تشغيل موتور

تخيل إن عندك Requirement بتقول:

"السيستم لازم يوقف الموتور في أقل من 2000ms لو درجة الحرارة زادت عن 120°C."

إزاي نختبر ده؟

  • Unit Test: نختبر اننا بنقدر نقرأ من الـ Sensor ونقدر نطلع PWM. 

  • Integration Test: ممكن ابتدى اجرب أختبر إن الكود بيغير الـ PWM لما الحرارة تزيد. بعدها أوصل الـ Sensor الحقيقي بالـ Microcontroller، وأشوف هل الإشارة بتوصل صح من الـ ADC للكود وبيحصل التأثير اللى انا عاوزه على PWM.

  • Validation Test: أشغل الموتور فعليًا، أرفع الحرارة (بمحاكاة أو جهاز تسخين)، وأقيس بالـ Oscilloscope هل فعلاً الـ PWM وقف في الوقت المطلوب.



#2: لمبة تحذير (Warning LED)

Requirement:

"لو البطارية أقل من 11V، لمبة التحذير لازم تنور."

  • Unit Test: أعمل Function تاخد Input Voltage وتدي Boolean (On/Off). أختبرها بقيم مختلفة (10.5V → On، 12V → Off).

  • Integration Test: أوصل الـ ADC بالـ Battery Input، وأتأكد إن القراءة بتوصل صح.

  • Validation Test: أوصل بطارية فعلية، أنزل الفولت تحت 11V، وأشوف بعيني إن اللمبة نورت.


#3: Software Mode Switching

Requirement:

"السيستم يتحول من Start Mode إلى Running Mode في أقل من 5ms."

  • Unit Test: أختبر Function الـ Mode Switching لوحدها.

  • Integration Test: أشوف هل الـ Scheduler أو الـ Tasks بتتغير صح لما يحصل Switch.

  • Validation Test: أشغل السيستم بالكامل، وأقيس بالـ Debugger أو Logic Analyzer او Oscilloscope  وقت التحويل.




ليه بقا التستنج مهم للشركة؟

  • بيحافظ على سمعة الشركة: منتج فيه Bugs = عميل مش راضي.

  • بيقلل الـ Rework: بدل ما نرجع نعيد الكود من الأول.

  • بيخلي الفريق كله واثق إن اللي طالع للسوق "هاي كواليتي".



زي ما قلت في المحاضرة: التستنج هو آخر خط دفاع قبل ما تتفضح.


Post a Comment

0 Comments