מבדק WHQL – להתגבר על ייסורי ההסמכה

מבדק WHQL – להתגבר על ייסורי ההסמכה
03 דצמ 2019

מאת : מנחם שפירא

נקודת הכאב

ב-TandemG אנחנו מאז ומעולם מפתחים דרייברים ל-Windows ומספקים עבורם הסמכה של חברת מיקרוסופט. בכל פרויקט עולה שאלת מיליון הדולר: האם כדאי לנו להשיג את לוגו ההסמכה של מיקרוסופט (WHQL) ? האם כדאי לנו לעבור את התהליך הארוך והמפרך רק כדי לקבל את החותמת של Windows ?

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

בעבר השקענו שעות עבודה רבות בהרצת מבדקי WHQL עבור לקוחותינו. הניסיון המצטבר מעיד כי השקענו את מירב הזמן בביצוע המשימות הבאות:

קונפיגורציה – אחדים מהדרייברים והתקני החומרה שבחנו לא היו מסוגלים לעבור את המבדקים עם קונפיגורציות ברירת המחדל. כדי לעבור את המבחן, היינו צריכים להגדיר ידנית סדרה פשוטה של מפתחות ב-Registry. לדוגמה, בהתקן Ethernet שבחנו הוא לא הצליח להתחבר למהירויות של מעל ל-100MB והיינו צריכים להגדיר ידנית את החיבור למהירות זו.  במהלך התקנה זו השבתנו את התמיכה בחבילות נתונים גדולות של TCP.

הקמת הסביבה – היה לנו מספר קטן של מכשירים שיכלו לשמש כהתקני מבחן (DUT), כך שאחרי שהרצנו מערכת הפעלה מסוימת נדרשנו להתקין מחדש את Windows עבור הסוג הבא של מערכת ההפעלה. במהלך הזמן מיקרוסופט חייבה עמידה במספר גדל והולך של מערכות הפעלה – ולקוחות מסוימים ביקשו הסמכה למערכות כמו:

Windows 7 (x64+x86), Windows 8.0 (x64+x86), Windows 8.1 (x64+x86), Windows 10 (RS0), RS1, RS2, RS3, RS4 (x64+x86), Server 2008 R2, 2012, 2016

לכל מבחן נדרשו משאבי זמן רבים והתהליך כולו היו מועד לטעויות.

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

באגים מסוג HCK/HLK – לעתים גילינו שמכונה נמצאת במצב "לא נקי" ונדרשה התערבות דרך מנהל HCK (כלומר, הגדרת המכשיר כ-"לא בטוח"). לעתים לא הצלחנו אפילו להבין מדוע מבחנים נקטעו בעת ההרצה והיינו חייבים להתקין מחדש את Windows ואפילו לפרמט את הכונן.

טעויות אנוש – הרצה ידנית של מבחנים גרמה לטעויות רבות שלנו. אחדות מהן חייבו אותנו להריץ מחדש חבילת מבחנים שלמה תוך איבוד ימים ואף שבועות של עבודה. לדוגמה, התקנת מערכת הפעלה לא מתאימה בהתקן המבחן או מערכות הפעלה לא תואמות בהתקן המבחן ובמערכת הנבחנת (SUT).

 

 

הכלי האוטומטי שלנו ל-WHQL

לאחר שבחנו את המדריך למפתח HLK החלטנו ליצור כלי חלופי להסמכת WHQL. התרשים שלהן מתאר את הסביבה שיצרנו.

 

 

Each Test machine has the following (simplified) configuration

 

רצף פעולות הבחינה הוא עתה פשוט וברור. לגבי כל מבחן ב-"מבחנים להרצה" (במקביל):

  1. בחר מבחן להרצה
  2. בחר מכשיר/ים זמינים לשימוש במבחן.
  3. התקן את מערכות ההפעלה המתאימות במכשיר היעד (תוך שימוש בשירות שרץ על "Recovery Partition" לכל התקן מבחן).
  4. אתחול כל ההתקנים תחת מבחן (דורש גישה לשקע חשמל פיזי)
  5. קישור לשרת המבחן HCK/HLK
  6. יצירה של פרויקט חדש
  7. העברה של ההתקנים למאגר ההתקנים
  8. התקנה של לקוחות HCK/HLK בהתקן המבחן ובמערכת הנבחנת
  9. התקנה של דרייבר ההתקן
  10. הרצת המבחן
  11. קונפיגורציה של ה-Registry על מנת לקבוע את המצב הנכון למבחן
  12. יצירת חבילת הגשה (submission package)
  13. מיזוג חבילה עם חבילת ההגשה
  14. איסוף נתונים שגויים לצורך תיקון באגים
  15. תוצאות :

א. אם המבחן עבר בהצלחה: סימון המבחן כ-"עבר"

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

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

 

לאחר שאנחנו מסיימים את ההרצה, אנו מנתחים את הנתונים שנאספו, את הלוגים ואת נתוני הקריסה (Core dumps) ככל שיש כאלה ומתחילים בעבודה האמיתית – ניפוי באגים בתוצאות המבחן, תיקון המכשיר וקוד הדרייבר.

מחזורי המבחן הם אוטומטיים לגמרי, אנו מכניסים את הקובץ הבינארי של הדרייבר למחיצה הנכונה ומחכים קצת. למעשה, מחכים הרבה מאוד זמן, לעתים ימים או שבועות. משך הזמן תלוי במאפיינים הבאים: כמה מבחנים מיקרוסופט דורשת, סוגי המכשירים ולאילו מערכות הפעלה בכוונתנו לבצע הסמכה. הפלט הוא חבילה מוכנה להגשה באתר של מיקרוסופט (Hardware dev portal).

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

Share

Sharon

OPEN POSITIONS