יום שבת, 19 במרץ 2016

Pairwise Testing AKA All Pairs Testing

כידוע לכל בודק מתחיל, יש יותר אפשרויות בדיקה מאשר זמן שמוקצה לבדיקות.
  
למשל יש לנו קטגוריה של מערכות הפעלה, ובקטוגוריה זו יש לנו שמונה מערכות שעלינו להקיף.
ובכל מערכת אנו בודקים את קטגוריית המשתמש שערך ראשון זהו המשתמש בעל הרשאות האדמין והערך השני הינו משתמש עם הרשאות מוגבלות, כלומר שתי אפשרויות.
ובקטגורית הדפדפנים יש לנו גם שמונה (אני כולל דפדפן וגרסה כערך אחד, אז יש לנו אקספלורר 9 כערך אחד, אקספלורר 10 כערך שני וכד').
כמה אפשרויות בדיקה יש לנו כאן? פשוט מכפילים: 8x2x8 = 128 אפשרויות.
  
כיוון שבפועל בד"כ יש יותר אפשרויות, וכיוון שבפועל בד"כ אין הזמן לבדוק את הכול מה עושים? מצמצמים.
  
לפי מה מצמצמים? כך עשינו עד כה:
סבירויות גבוהות יותר למשל אנו יודעים שלרוב המשתמשים היום יש מערכות הפעלה של Win7 אז חלק יחסי ובהתאמה גדול יותר של הבדיקות יתרכז במערכת הפעלה זו.
ניהול סיכונים - אנו יודעים שבמשתמש ב-WIn XP עלולות להיות יותר בעיות התקנה קריטיות במשתמש עם הרשאות מוגבלות אז נוודא שזה נבדק היטב.
מוודאים שכל ערך נבדק תחת כול קטגוריה, כולל ערכים שמשפיעים האחד על השני. למשל בדיקת קטגוריה דפדפן פתוח או סגור בודקים לא רק כשכל דפדפן פתוח וסגור אלא גם צירופים, למשל במקרה אחד: *IE פתוח אבל *CH סגור וכך גם ה-*FF.
  
זה לא רע ואני יכול לומר שבסה"כ כנראה שעלינו על רוב הבאגים. אבל תמיד הייתה לי הרגשה שזה לא מספיק טוב.
  
כאן נכנסת לתמונה מתודת ה-Pairwise Testing.
  
לפי מחקרים**, ולא פחות לפי האינטואיציה, רוב הבאגים נמצאים בערכים יחידים, כמו שהתקנה נכשלת ב-Win 8. חשוב לציין שייתכן שזה קורה גם בשאר מערכות ההפעלה או בחלק מהן, אבל עדיין מדובר בערך בודד ולא בצירוף של ערך עם ערך אחר בקטגוריה אחרת. לפי המחקר הנ"ל בין 30% ל-70% מהבאגים מתגלים כאן. אגב את זה ואת שאר ההנחות כאן אפשר לבדוק בקלות במערכת ניטור הבאגים שלכם.
  
החלק הגדול השני של הבאגים מתגלה בצירוף של שני ערכים מקטגוריות שונות. למשל באג שקורה בכרום במקרה שהרשאות המשתמש הן מוגבלות.
  
חלק קטן הרבה יותר יקרה בצירוף של שלוש קטגוריות, למשל באג שקורה רק ב-Win XP, רק במשתמש מוגבל ורק בכרום. אני מניח שצירוף כזה עשוי להיות נדיר גם אצל המשתמשים, אבל לא לסמוך על זה.
  
ויש אחוזים בודדים של באגים שיקרו בצירוף של ארבע קטגוריות ומעלה.
  
איך זה מתקשר לאפשרות המוגבלת שלנו לבדוק בצורה איכותית כמויות רבות של ערכים? התשובה היא שאנו פשוט נבדוק את כל המקרים הבודדים, ואת כל הצירופים של שני ערכים קיימים. תוך כדי כך נבדוק ממילא את כל הקטגוריות יחד (לפחות במקרה שלי) אבל לא את כל צירופי הערכים.
  
הינה דוגמא***:
יש לנו שלש קטגוריות עם שני ערכים בכל אחת:
X = A,B
Y = C,D
Z = E,F
  
אלו כל האפשרויות שלנו:

אפשר לראות שאת הזוג A ו-E בודקים בטסט 1 (T1), את A ו-D בטסט 4, ואת D ו-E בטסט 6.
כלומר שלשת הצירופים הזוגיים של טסט 2 נבדקים ולכן ניתן להסיר אותו.
  
לאחר שנעשה כך על כל הצירופים, נוכל להגיע למצב הבא:

ובזהירות - שלא נוציא שורות שהסתמכנו עליהן.
לא רע בכלל.

חסרונות:
1. עצוב שמראש יודעים שאנו מוותרים על אחוז מסוים של באגים. מצד שני, בכל מקרה אנו מוותרים עליהם.
2. בהסתמך רק על המתודה שלעיל אנו עלולים להפסיד קומבינציות חשובות. לכן חשוב מאוד שבודק מיומן יבחן את התוצאות, כלומר את הצירופים החשובים, ויוודא ש:
- אנו בודקים יותר את הסבירויות הגבוהות יותר.
- אנו בודקים מקומות מסוכנים יותר.
3. חשוב לבחור את הפרמטרים הנכונים. למשל, אני יכול להחליט שאני לא בונה קטגוריה שתכיל כל מערכות ההפעלה אלא מספיקה לי קטגוריה של 32 מול 64 ביט. לפי המוצר שלי, ייתכן שזו חלוקה נכונה, אבל ייתכן שחשובה לי הרבה יותר קטגוריה של מערכות הפעלה שתכיל את כל האפשרויות של הביטים בתוכה.

כלים ניתן למצוא כאן.
מאמר של באך שמזהיר מהסכנות של המתודה ניתן למצוא כאן.


* FF - Firefox
IE = Internet Explorer
CH = Chrome

** למשל הגעתי לכאן דרך מאמר במגזין "חושבים בדיקות".
  
*** מכאן

יום ראשון, 13 במרץ 2016

בדיקת תעבורה בין הקליינט לשרת וחזרה

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

יש לנו אפליקציה בטלפון והיא אמורה לקבל עדכון. בתרשים זרימה כללי, הקליינט פונה נניח פעם ביום, לשרת. הוא שולח לשרת את הגרסה שלו, השרת בודק אם זו הגרסה העדכנית, ואם לא הוא מקבל עדכון בצורת לינק לגרסה החדשה.
בדיקת תעבורה בין הקליינט לשרת וחזרה
עכשיו נניח שאתם שולטים על כל התהליך, יש לכם גישה לכל מקום בשרת ובקליינט ואתם בקיאים בזה.
אתם גם יודעים שיש לכם גרסה לא עדכנית והשרת אמור להחזיר לכם את הגרסה החדשה, אך זה לא קורה. איפה יכולה להיות הבעיה? נסו לחשוב על כך כמה דקות.
  
פעמים רבות כשאני שואל בודקים אני מקבל תשובות חלקיות על כך. אנסה כאן להעביר איך אפשר לחשוב על נושאים כאלה בצורה שיטתית. לשם כך ננסה לחשוב על נקודות אפשריות ע"פ תרשים זרימה ומה עלול להתרחש בכל אחת מהן.
#
נקודה
בעיה
איך בודקים
1
תהליך הבדיקה: הקליינט בודק: האם יש גרסה חדשה?
האם תהליך הבדיקה מול השרת, לא מונע בכלל או אינו עובד כראוי?
לבדוק פרוססים, לבדוק אם בכלל יש פניה לשרת ע"י שימוש בסניפרים, צפייה בלוגים.
2
יש פניה לשרת.
האם טופס הפניה תקין (למשל XML, JSON)? -אם לא, השרת עשוי לא לטפל בפנייה.
שימוש בסניפרים, לוגים.


האם הגרסה המדווחת נכונה? – אם לא, אולי השרת "חושב" שיש לנו את הגרסה החדשה
שימוש בסניפרים, לוגים.


האם השרת החזיר תשובה שהוא קיבל את הפנייה (אישור בלבד)?
שימוש בסניפרים, לוגים. האם השרת מגיב מהר או שיש חשש לטיים אאוט.
3
האם השרת ענה עם הגרסה והלינק?
אם לא, אולי בעיות בתהליכים בשרת.
סניפרים, פרוססים, לוגים.
4
יש תשובה, אך עדיין אין עדכון
האם טופס החזרה תקין?
שימוש בסניפרים, לוגים.


האם הגרסה נכונה?
שימוש בסניפרים, לוגים. בדיקה בבסיס הנתונים.


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


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


אם הוא מריץ, אולי הבעיה בקובץ ההתקנה או בסביבת הבדיקות.
לבדוק פרוססים, לוגים. להריץ את הקובץ עצמו.

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

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

רשומות פופולריות