פתרון בדיקת שירות שלם

פתרון התרגיל הראשון

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

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

enum class state { active, completed, cancelled };
state state_ = state::active;

// Inside cancel, after authorization:
if (state_ != state::active) return decision::already_finished;
state_ = state::cancelled;
++cancellations_;
return decision::cancelled;

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

bool complete() {
    std::lock_guard guard(lock_);
    if (state_ != state::active) return false;
    state_ = state::completed;
    return true;
}

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

פתרון התרגיל השני

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

תרחיש	זהות ומצב	תוצאה צפויה	ראיה פנימית
התקנת שירות	מנהל, רשומה חסרה	התקנה מצליחה	חשבון ונתיב תואמים להגדרה
התקנה ללא זכות	משתמש רגיל ללא זכות יצירה	דחייה	אין רשומה חדשה
התחלה תקינה	מנהל, שירות עצור	מעבר לריצה	מנוע מוכן לקבלה
התחלה עם תצורה פגומה	מנהל, שירות עצור	כשל מוסבר	אין listener פעיל
עצירה מורשית	מנהל, עבודות פעילות	סגירת קבלה וניקוז	אין buffer בשימוש אחרי ניקוי
עצירה ללא זכות	משתמש ללא זכות עצירה	דחייה	השירות ממשיך במצבו
ביטול בבעלות	משתמש א, עבודה א פעילה	ביטול אחד	מעבר מצב יחיד
ביטול של משתמש אחר	משתמש ב, עבודה א פעילה	דחייה	אין שינוי בעבודה
הודעה קטועה	לקוח מחובר, body חסר	סגירה או שגיאה מוגדרת	אין ביצוע חלקי
גרסה זרה	לקוח ישן שאינו נתמך	דחייה מוקדמת	אין parsing של body שגוי
שדרוג שנכשל	מנהל, מעבר schema	חזרה או עצירה מוסברת	גרסת הנתונים ידועה
קריאת אבחון	משתמש לפי הרשאת channel	גישה מוגבלת לפי המדיניות	אין סודות בחבילה

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

פתרון התרגיל השלישי

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

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

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