פיתוח קושחה מהימן עבור מערכות ניידות מחוברות

הסעיף הבא דן כיצד ביצוע מבחני יחידות ואינטגרציה הופך אוטומטי ועקבי כאשר הם משולבים בצינור CI/CD.

ובהמשך יודגם כיצד תוצאות מבחני יחידה ואינטגרציה הופכות לראיה ניתנת לביקורת עבור:

• מקרי בטיחות פונקציונליים תחת ISO 26262
• דרישות אבטחת סייבר תחת ISO/SAE 21434

תהליכי בנייה ידניים ובדיקות אד-הוק מובילים בהכרח לאיכות לא עקבית. צינורות CI/CD אוטומטיים מבטיחים שאותם שלבים מבוצעים באופן עקבי עבור כל בנייה.

צינורות אלו הופכים אוטומציה של בניית קושחה ובדיקות באמצעות פלטפורמות כגון Azure DevOps, Jenkins או GitLab CI.

CI/CD הוא גם מעשי מאוד לעמידה ברגולציה, אם כי לא חובה. זוהי גישה נפוצה לשמירה על איסוף הראיות העקבי והיסודי הנדרש על פני מחזורי ביקורת חוזרים, ולאורך התפתחות מוצר EV לאורך חייו.

בפועל, CI/CD מכונה לעתים קרובות פשוט כ-CI. ואכן, אספקה ​​מתמשכת רומזת בעיקרה להכנה אוטומטית של מוצר לשחרור, אבל בעיקר באינטגרציה מתמשכת מתרחשים בעיקר פיתוח מוצר ויצירת ראיות.

צינור CI טיפוסי כולל:

• ניתוח סטטי (עם דיווח MISRA)
• בניית קושחה
• בדיקת יחידה
• בדיקת אינטגרציה
• אריזת חפצים

חבילת החפצים מכילה את כל התפוקות הרלוונטיות לביקורות תאימות, כולל תמונות קושחה, מניפסטים, מטא נתונים ודוחות בדיקה.

בדיקת רגרסיה היא המטרה העיקרית של CI. בכל פעם שנוצר מבנה חדש, כל הבדיקות – ניתוח סטטי, בדיקות יחידה ומבחני אינטגרציה – מופעלות מחדש.

רגרסיה מתייחסת להחדרה לא מכוונת או להחדרה מחדש של פגמים בעקבות שינויים כגון תיקוני באגים או שיפורים. בדיקות רגרסיה אוטומטיות מבטיחות שעדכונים חדשים לא ישברו התנהגות קיימת.

כאשר מתגלה פגם בשטח, התיקון שלו חייב לכלול מבחן רגרסיה מתאים. ובאופן טבעי זה יקרה, מכיוון שצינור ה-CI הוא זה שמייצר בנייה חדשה מהקוד המתוקן.

אם נשמור על הכל בפרספקטיבה, עלינו לציין שבדיקת רגרסיה אוטומטית אינה מבטלת את הצורך בבדיקת רגרסיה ידנית. לדוגמה, עדיין יש להשתמש בבדיקה ידנית כאשר הוכחה לבטיחות האדם תלויה בחוויית המשתמש, כגון באינטראקציה שלו עם ממשק משתמש, או כאשר השגת משוב אוטומטי על תוצאת הבדיקה אינה מעשית.

יתר על כן, תחזוקה אנושית של בדיקות הרגרסיה האוטומטיות היא הכרחית; למשל, הוספת יחידות חדשות ובדיקות אינטגרציה כדי לתמוך בתכונות מוצר חדשות.

הסעיף הבא יסביר כיצד לארגן את הנתונים והתוצאות של מבחני רגרסיה לכדי ראיות ניתנות למעקב.

עקיבות היא מה שקושר הכל יחד. הוא מקשר דרישות לעיצוב, קוד ובדיקות. הקישורים הניתנים למעקב אלו מהווים את הליבה של ראיות תאימות. יכולת העקיבה תומכת:

• ביקורת בטיחות תפקודית (ISO 26262)
• ביקורת אבטחת סייבר (ISO/SAE 21434)
• הערכות תהליך של ASPICE

ללא מעקב, באג עלול להחמיץ מכיוון שאין קשר ברור בין דרישה לבדיקה המאמתת את יישום הדרישה.

מבקרי ציות לתקנות זקוקים להוכחות לכך שכל דרישות בטיחות ואבטחה יושמו ואומתו. העקיבות הופכת את הביקורות לשיטתיות על ידי הדגמה ברורה של כיסוי הדרישות.

הכלי העיקרי לתיעוד העקיבות הוא מטריצת המעקב של דרישות (RTM). RTM מקשר כל דרישה ל:

• יישומו בקוד.
• מקרי הבדיקה שמאמתים זאת.
• התוצאות והממצאים הנלווים.

RTM שתופס את הבדיקות לדוגמה שהוצגו בעבר ייראה בערך כמו הבא לוּחַ.