سؤال

هل نجح أي شخص في أتمتة الاختبار مباشرة على الأجهزة المدمجة؟

على وجه التحديد، أفكر في أتمتة مجموعة من اختبارات الوحدات لوحدات طبقة الأجهزة.نحن بحاجة إلى ثقة أكبر في كود طبقة الأجهزة لدينا.تستخدم الكثير من مشاريعنا مؤقتات تعتمد على المقاطعة، وADCs، وsery io، وأجهزة SPI التسلسلية (ذاكرة فلاش) وما إلى ذلك.

هل هذا يستحق هذا الجهد؟

نحن نستهدف عادة:

المعالج:وحدات تحكم دقيقة 8 أو 16 بت (بعض عناصر DSP)
لغة:C (أحيانًا c++).

هل كانت مفيدة؟

المحلول

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

ومع ذلك، يقوم المطورون أيضًا ببناء جهاز اختبار أرخص (أقل من 1000 دولار) يتضمن مجموعة من منافذ الإدخال/الإخراج USB، A/D، إدخال/إخراج PWM، وما إلى ذلك، وإما استخدام البرمجة النصية على محطة العمل، أو برنامج اختبار HIL/SIL المصمم لهذا الغرض مثل مكسفديف.

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

ما إذا كان الأمر يستحق ذلك يعتمد.

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

في الصناعة الاستهلاكية، مع المشاريع غير المعقدة، لا يستحق الأمر عادةً ذلك.

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

يظهر الاختبار فورًا عند دخول مشكلة إلى البناء.

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

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

للحصول على إعداد أرخص بكثير، يمكنك الحصول على لوحات تحكم دقيقة بقيمة 100 دولار مع USB و/أو إيثرنت (مثل عائلة Atmel UC3) والتي يمكنك توصيلها بجهازك وإجراء الاختبار الأساسي.

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

-آدم

نصائح أخرى

نعم.لقد حققت نجاحًا، لكنها ليست مشكلة يجب حلها بسرعة.باختصار، هذا ما فعله فريقي:

  1. تم تحديد مجموعة متنوعة من اختبارات الوحدات باستخدام إطار اختبار وحدة C محلي الصنع.في الأساس، فقط الكثير من وحدات الماكرو، تم تسمية معظمها TEST_EQUAL, TEST_BITSET, TEST_BITVLR, ، إلخ.

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

  3. ستقوم الاختبارات الفردية بتسجيل مخرجاتها باستخدام المنفذ التسلسلي.كان هذا مناسبًا لتصميمنا لأن المنفذ التسلسلي كان مجانيًا.سيتعين عليك إيجاد طريقة لتخزين نتائجك إذا تم استهلاك كل عمليات الإدخال والإخراج الخاصة بك.

انها عملت!وكان من الرائع أن يكون لديك.باستخدام مسجل البيانات المخصص لدينا، يمكنك الضغط على زر "اختبار"، وبعد بضع دقائق، ستحصل على جميع النتائج.انا اوصي بشده به.

محدث لتوضيح كيفية عمل سائق الاختبار.

نعم.

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

ومع ذلك، هناك شيء واحد يجب مراعاته بالضبط ما الذي تحاول التحقق منه.

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

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

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

سيكون اختبار مسارات الاتصالات بجهازك أمرًا بسيطًا نسبيًا ولا يتطلب إنشاء تعليمات برمجية خاصة.

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

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

بعض الأشياء التي يجب مراعاتها:

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

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

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

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

نعم، أفعل هذا، على الرغم من أنه كان لدي دائمًا منفذ تسلسلي متاح لاختبار الإدخال/الإخراج.

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

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

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

لقد نجحنا في تطوير بروتوكول تسلسلي خارجي (إما رسائل rs232 أو udp أو tcpip) مع الأوامر الأساسية لممارسة hw مع تسجيل التصحيح في برامج التشغيل ذات المستوى المنخفض التي تبحث عن حالات خاطئة أو حتى حالات غير طبيعية قليلاً (خاصة للتحقق من الحدود)

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

أعلم أن هذا أصبح قديمًا الآن، لكن ربما سيساعد.نعم، يمكنك القيام بذلك ولكن ذلك يعتمد على المبلغ الذي تريد استثماره في الحل الذي تريده.لقد عملت لأكثر من عامين على الاختبار والتحقق من صحة طبقة MCAL الخاصة بـ AUTOSAR.يعد هذا أقل ما يمكنك الحصول عليه عندما يتعلق الأمر باختبار البرامج.لقد كان نوعًا من اختبار مستوى المكونات.قد يسميه البعض مستوى الوحدة ولكنه كان أعلى قليلاً من ذلك لأننا كنا نختبر واجهات برمجة التطبيقات (APIs) الخاصة بمكونات MCAL.اشياء مثل:ADC، SPI، ICU، DIO، وما إلى ذلك.

الحل المستخدم يشمل:- إطار اختبار تم تشغيله على جهاز Micro الهدف - مربع DSPACE لتوفير وقراءة الإشارات من وإلى الهدف عند الاقتضاء - إمكانية الوصول إلى XCP من خلال Canape Vector لتشغيل تنفيذ الاختبار وجمع النتائج - إطار Python لإجراء التحكم في الاختبار والتحقق من النتائج

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

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

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

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top