رمز الاختبار للتطبيق المضمن

Question

خلفية:

أقوم بتطوير مشروع كبير باستخدام Atmel AVR atmega2560.يحتوي هذا المشروع على الكثير من الوظائف القائمة على الأجهزة (7 أجهزة SPI، 2 I2C، 2 منافذ RS485 MODBUS، والكثير من منافذ الإدخال/الإخراج التناظرية والرقمية).لقد قمت بتطوير "برامج تشغيل" لجميع هذه الأجهزة التي توفر حلقة التطبيق الرئيسية بواجهة للوصول إلى البيانات المطلوبة.

سؤال:

يجب أن يفي المشروع الذي أقوم بتطويره في النهاية بمعايير SIL.

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

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

هل أحتاج إلى أجهزة لمراقبة الإدخال/الإخراج على الجهاز ومحاكاة الأجهزة المتصلة خارجيًا؟أي مؤشرات يمكن تقديمها ستكون موضع تقدير كبير.

--ستيف

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

Vectorcast هي أداة تجارية لتشغيل اختبارات الوحدة على الأجهزة بتغطية رمز.

Answer 4

هل لديك موصل JTAG؟ قد تكون قادرًا على استخدام JTAG لمحاكاة ظروف الخطأ على الشريحة.

Answer 5

أحب فصل المهام. على سبيل المثال ، عندما قمت بعمل مخزن مؤقت دائري لـ ATMEL AVR ، كتبت كل شيء في الكود :: الكتل وتجميعه باستخدام برنامج التحويل البرمجي العادي GCC بدلاً من برنامج التحويل البرمجي AVR GCC ، ثم أقوم بإنشاء اختبار وحدة له. لقد استخدمت ملف رأس خاص لتوفير أنواع البيانات المناسبة التي أردت العمل معها (uint8_t على سبيل المثال). لقد وجدت أخطاء في اختبارات الوحدة ، وثبتها ، ثم أخذت الرمز الثابت إلى AVR Studio ودمجته. بعد ذلك ، استخدمت وظائف الدعم و ISRs لتناسب المخزن المؤقت في رمز مفيد (أي ، بايت بايت من المخزن المؤقت ، ودفعه إلى سجل إخراج بيانات UART ، وإلحاق سلسلة ثابتة إلى المخزن المؤقت لوظيفة printf ، إلخ). ثم استخدمت محاكاة AVR للتأكد من استدعاء ISRs ووظائف بلدي وأن البيانات الصحيحة ظهرت في السجلات. بعد ذلك قمت ببرمجته على الشريحة وعملت بشكل مثالي.

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

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

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