פרק #35 טכניקת בדיקה - קופסא לבנה ISTQB בואו לשמוע את קובי יונסי מרצה מוביל בתחום הבדיקות מדבר על אחת מטכניקות הבדיקה ״קופסא לבנה״ על פי הסמכת בפרק הפעם נשוחח על אחת מטכניקות הבדיקה ״קופסא לבנה״ אשר נמצא בפרק מס 5 בסילבוס של ISTQB. הפרק הוא חלק מסדרת שורטקאסטים ומתמקד בטכניקות בדיקה חשובות למפתחי תוכנה ובודקים, כאשר טכניקת הקופסא הלבנה מאפשרת הבנה עמוקה של מבנה הקוד הנבדק והיכולת לבדוק את כל המנגנונים הפנימיים שלו. יונסי מסביר את עקרונות הטכניקה, יתרונותיה ויישומים מעשיים בעבודה היומיומית של אנשי בדיקות תוכנה. הפרק מתאים גם לאלו המעוניינים להעמיק ביסודות הבדיקות וגם לאנשי מקצוע מנוסים.
תאריך עליית הפרק לאוויר: 05/10/2024.
[מוזיקת פתיחה]
שלום לכולם, שוב, קובי יונסי, מדריך מהאקדמיה ומהתעשייה לבדיקות תוכנה, והיום אתם שוב איתי בעוד פרק מהפודקאסט של "TestIL", העמותה לקידום מקצוע הבדיקות בישראל.
היום בעצם אנחנו נדבר על הנושא של בדיקות קופסה לבנה, מה שנקרא White Box Testing. מדובר כמובן על בדיקות שמתייחסות למבנה הפנימי של הרכיב או המערכת. להבדיל מקופסה שחורה, אנחנו לא מתייחסים דווקא לדרישות של הרכיב, אלא בודקים את נכונות החלקים הפנימיים של הרכיב.
כמובן, כדי לעשות זאת, אנחנו מתבססים בבדיקות על קוד המקור, ומכורח העניין יוצא שמי שבדרך כלל מבצע את הבדיקות הללו, אלו המתכנתים. וזה יכול להיות בכל מיני רמות, גם ברמת בדיקות יחידה, גם ברמת בדיקות אינטגרציה, בדיקות נסיגה, וכמובן בדיקות של מערכת.
בבדיקות קופסה לבנה ישנם שני טכניקות שהם הטכניקות המובילות.
הטכניקה הראשונה נקראת בדיקת הצהרות קוד והכיסוי שלהם, זה ייקרא באנגלית "Statement Testing and Coverage".
שיטת הבדיקה הזאת קובעת את מקרי הבדיקה כך שכל הצהרת קוד, הצהרת קוד שווה שורה בקוד, כלומר, כל שורה שמופיעה בקוד, נחשבת כהצהרה, וכל שורה כזאת צריכה להיבדק לפחות פעם אחת. המטרה בגדול היא להגיע ל-100% כיסוי של הצהרות קוד. כלומר, ככל שאפשר, ננסה לעשות מעבר, או ננסה להגיע לכל שורה בקוד, ולוודא שאכן עברנו שם, וקיבלנו את האפקט, את התוצר, את ה-output, שחיכינו לו. כמובן, לפי איפיון ולפי דרישות המערכת.
הטכניקה השנייה היא טכניקה שנקראת בדיקת החלטות וכיסויין. נקראת באנגלית "Decision Testing and Coverage".
בשיטה זאת, אנחנו בעצם קובעים את מקרי הבדיקה, כך שבכל הצהרה או שורת קוד, אנחנו נחפש את התנאי. כמובן שתוכנה מבוססת הרבה פעמים על משפטי תנאי, if, כשלכל תנאי יש תמיד אפשרות של כן ולא, True ו-False. המטרה שלנו היא לעבור בכל שורת קוד שנמצא בה תנאי, גם בצד של האמת, כלומר, כשהקוד, כשהשורה מתקיימת, כשהתנאים מתקיימים, וגם כשהתנאים אינם מתקיימים, כלומר שאנחנו מקבלים False. ופה המטרה שלנו היא להגיע ל-100% כיסוי החלטות.
מעבר לשתי הטכניקות הללו, יש טכניקות אחרות של קופסה לבנה שכוללות ריבוי מסלולים, ונושאים נוספים שנשוחח על כך בהמשך.
כמובן שהשאיפה היא לכתוב סט בדיקות שיוודאו את נכונות כל הקוד ברכיב. הבדיקות נכתבות ומתכתבות מול הקוד, מסתמכות כמובן על הידע של הבודק וההבנה שלו בלוגיקה של הרכיב.
באופן כללי, הבודק בוחר קלט שיבדוק חלק מסוים בקוד, וכמובן משווה אותו עם הפלט שהוא מצפה לקבל. כך נוכל בעצם לעשות הערכה מהי רמת כיסוי הקוד שביקשנו לממש.
אנחנו בדרך כלל נעזרים בכיסוי קוד להבין מה בעצם היקף הבדיקות שביצענו.
מאוד דומה, אם אנחנו עובדים בשיטת קופסה שחורה, על נושא של כיסוי דרישות שמובאות אלינו לשולחן. שם אנחנו קוראים לזה בשם Requirement Coverage, והמטרה כמו ב-Code Coverage, היא לכסות ככל שאפשר, בזמן קצר, את כמות האפשרויות הגבוהה ביותר, ולמקסם את היעילות של הבדיקה.
כמובן שאנחנו נמצאים בעידן שהתוצרים והמוצרים יוצאים בקצב מאוד מאוד מהיר, ואנחנו אף פעם לא מספיקים לבדוק את כל האפשרויות, אגב זה חלק מעקרונות הבדיקה, לא ניתן לבדוק את כל האפשרויות כי פשוט אין לנו זמן, והמטרה שלנו היא לנסות להתמקד בעשייה מינימלית שנותנת לנו מטרות או תוצאות אפקטיביות, והן בעצם ברמה מקסימלית.
וכך אנחנו הופכים את הבדיקות להרבה יותר יעילות בהעדר זמן ומשאבים אחרים, יכול להיות גם כוח אדם או כסף, וזה חלק מהנושא של תכנון הבדיקות.
דרך טובה כמובן להתחיל, היא להבטיח שיהיה לנו כיסוי שורות קוד מרבי ככל שאפשר, להבטיח שכל שורת קוד לפחות תרוץ פעם אחת. כדי לעשות זאת אפשר להשתמש בכל מיני טכניקות, ישנם תוכנות שיכולות לסמלץ לנו את המסלולים השונים, ואנחנו יכולים גם במקביל להיעזר בתרשימי זרימה. תרשימי זרימה של הרכיב יכולים לתת לנו איזושהי עדות לגבי מסלולים אפשריים של זרימת הקוד על בסיס של פעילות היוזר. דרך זה נוכל בעצם לוודא, או לנסות לבדוק, להגיע לשאיפה של בדיקה, של כל המסלולים האפשריים בתהליך הזה.
השיטה הזאת נקראת בדיקת מסלולי בסיס, והיא מספקת כמה שפחות בדיקות כדי להגיע למצב של כיסוי שורות קוד מקסימלי. וכמובן, בנוסף לכיסוי שורות קוד, אנחנו צריכים לבדוק נושאים נוספים שקשורים בעצם הקוד, כמו לבדוק את הנושא של לולאות, לבדוק את הנושא של תנאים, מן הסתם, לבדוק כל מיני דברים שקשורים ברמת הקוד, שיצריכו מאיתנו בסוף לוודא שבעצם המערכת עובדת.
ואולי שווה לתת פה איזושהי דוגמה, כדי להמחיש את הרעיון. אז בואו נדמיין שיש לנו איזשהו תנאי, שמשתנה של Age, גיל, אמור להיות גדול מ-18. ובקוד נרשם ש:
if A קטן מ-18
then תופיע הודעה "Access Denied"
"Access Denied"
וכמובן, end בסיום שורת הקוד.
אם אנחנו רוצים לבדוק בדיקת הצהרת קוד, כלומר, סטייטמנט טסטינג, בדיקת המשפט, עלינו פשוט לדאוג לממש את אותה, את אותו תנאי, ולראות שאנחנו מקבלים את התוצאה הרצויה. כלומר, במקרה שלנו, נבחר לשים איזשהו ערך ב-Age שהוא קטן מ-18, ולוודא שאנחנו מקבלים את הודעת המידע, את הפופ-אפ שקופץ, ואומר שהכניסה אסורה, או לא אפשרית. בעצם זה אנחנו סיימנו את הבדיקה של שורת הקוד. כלומר, הכנסנו איזשהו פרמטר, value, שנכנס לקוד, ועובר דרך כל שורות הקוד, ונוכל לסמן על כך שהכיסוי של הקוד בוצע.
כדי לבדוק בדיקות שקשורות במשפטים, או בהחלטות, Decision Testing, אנחנו נצטרך לא רק לבדוק גיל קטן מ-18, נצטרך גם לבדוק מצב של False. כלומר, במקרה שלנו, גיל שהוא גדול מ-18. שם אולי אנחנו נרצה לראות שפעילות אחרת מתבצעת. כלומר, אם אני קטן מ-18 תופיע הודעה, אבל עליי לבדוק גם מה קורה אם אני לא קטן מ-18, כלומר גדול מ-18. בשארית הקוד כנראה שיהיה כתוב, או שיוסבר, מהי בעצם הפעולה האפשרית, בין אם זה כניסה לגיטימית למערכת, או בין אם זה מהלך אחר, בהתאם לאפיון.
אבל כדי לכסות את החלק הזה של הקוד, יש לי שתי צורות - או בדיקת הצהרה, שאז אני מכסה ב-100% כשאני בודק שה-Age קטן מ-18, או בדיקת Decision, שאני אוכל לכסות דרך מצב כזה רק 50%, ונותרו לי עוד 50% לבדוק מה קורה כשהתנאי לא מתקיים. לא רק את ה-True, גם את ה-False.
זו בעצם הדוגמה שמממשת את המהות האמיתית, את ההבדל האמיתי, בין שתי צורות הכיסוי שמתאפשרות דרך בדיקות של קופסה לבנה.
חשוב לציין פה אולי גם טכניקה נוספת, שקשורה בכיסוי מרובה תנאים. למה הכוונה? כאשר יש לנו תנאי שגורר לתנאי נוסף, ואולי גורר לתנאי שלישי, יש לנו מה שנקרא תנאי משורשר. כלומר, אוסף של if-ים שבעצם מתגלגלים מאחד לשני. בסיטואציה כזאת, לא תמיד נסתפק רק לבדוק כל תנאי מצד ימין או מצד שמאל, כלומר, ב-True וב-False שלו, אלא ננסה לעשות את כל הקומבינציות של המסלולים האפשריים. זה אומר שלא נסתפק רק ב-True, True ו-True, ו-False, False ו-False, וכך נכסה ונגיע ל-100% כיסוי של משפטים, אלא נבצע את כל הקומבינציה האפשרית. הכוונה היא, True-True-True אמנם, False-False-False אבל את כל הקומבינציות בפנים, כלומר, True-False-True למשל, או True-True-False או False-True-True וכך הלאה. כשאנחנו עושים את הפעולה הזאת, אנחנו תמיד נחשוב שכמות התנאים היא זאת שתכתיב לנו את גודל והיקף כיסוי הקוד שנצטרך לבצע. זה יהיה תמיד 2 בחזקת התנאי של ה-if שרלוונטי, כלומר, אם יש לנו 3 תנאים, אז 2 בחזקת 3 תיתן לנו בעצם, במינימום, 8 מסלולי בדיקה.
זוהי דוגמה לעוד סוג של כיסוי שניתן לבצע כאשר יש לנו תנאים מרובים שיכולים לייצר הרבה מאוד סימולציות של החלטות.
זה יכול להיות, למשל, במצב שמישהו אמור לקבל או לא לקבל את היכולת של ביטוח, או אולי משכנתא. בחברות פיננסיות כמו בנקים או חברות ביטוח, ששם אוסף של כמות גבוהה מאוד של תנאים, תוליד תוצאה שונה בין מקרה א' למקרה ב'. במצבים הללו, בבדיקות קופסה לבנה, יהיה נכון להשתמש בכיסוי מרובה תנאים, כדוגמה, לאיזושהי טכניקה שהיא טכניקה קצת יותר מורכבת, אבל יכולה לאפשר לכסות כמה שיותר מצבים ולהותיר אותנו עם רמת סיכון נמוכה ממוצר שאנחנו רוצים להוציא לשוק.
מילה נוספת, שווה לומר, על הנושא של היתרונות והחסרונות של בדיקות קופסה לבנה.
אז ברמת היתרונות, כמובן שהבדיקות עוזרות לגלות מקרי קצה ושגיאות שחבויות בקוד. איזה שגיאות אנחנו עלולים לזהות בקוד? זה יכול להיות, למשל, נושא של זליגת זיכרון, או אולי קוד לא יעיל, מה שאנחנו אוהבים לקרוא לו בשם 'קוד ספגטי'. זה יכול להיות נושאים שקשורים לבעיות של אבטחה, או אולי סוגיות שקשורות בנושא של חולשות אבטחה, שיכולות לאפשר לתוקף להזין כל מיני חלקי קוד, או להזין אינפוטים כאלו, שעלולים לפרוץ את המערכת. אולי כדוגמה, נאמר, SQL Injection.
הנושא הנוסף זה שברמת היתרונות, הבדיקות הללו מעודדות את מי שכותב את התוכנה להבין בדיקות, להכיר את הקוד, ואם אנחנו מהצד של הבודקים, אנחנו נצטרך להכיר את האזור, את הקוד מקור, ולהבין היטב מאיפה בעצם שורש הבעיה. כלומר, זה לא משאיר אותנו כבודק שרק יודע לומר שהתהליך לא עובד על בסיס איפיון, אלא גם מאפשר לנו להיכנס, לחקור ולגלות איפה בעצם שורת הקוד שמסבה את הבעיה, וזה בהחלט יכול להרים ולשפר גם את המקצועיות של הבודק וגם את היכולת שלו לאתר את ה-source, את המקור, של אותה בעיה. ובאותה מידה, אם אנחנו מדברים על מתכנתים שעושים בדיקת קוד זה לזה, או באופן עצמאי, לפני שהם משחררים את הגרסה, זה משפר גם את היכולת הבדיקתית שלהם. כלומר, איך שלא נסתכל על זה, בשני הכיוונים, כמתכנתים או כבודקים, זה יכול לשפר אותנו, בין אם זה בהבנה של קוד ובין אם זה בהבנה של בדיקות.
נושא שלישי הוא שכשאנחנו מריצים בדיקות שמבוססות על הקוד, כאשר יש לנו איזשהו כישלון, כאשר אנחנו מזהים failure, יותר קל לנו למצוא את שורת הקוד כיוון שאנחנו יודעים בדיוק את ה-source שאחראי לאותה בעיה. באותה נקודת כשל, נוכל בעצם לדעת מה גרם לנושא, ובעצם זה מייעל לנו את החקירה אל תוך הבעיה שגרמה לתקלה.
מבחינת חסרונות, הבדיקות הללו מסובכות יחסית לכתיבה, ומעבר לזה, וזה הנושא החשוב, כדי לדעת לכתוב או לעשות בדיקות, לחקור את מה שקשור בקוד, עליך לדעת לכתוב קוד. וכמובן, זה מצריך ממך יכולת תכנות מסוימת. כמובן שלא בכל החברות הבודקים נדרשים ליכולת כזאת, ולכן הרבה מאוד פעמים אנחנו נראה שחברות יעדיפו שהבודק יתעסק בבדיקות קופסה שחורה, ושייצג בעצם את המשתמש קצה, היוזר, שגם הוא אינו מבין בקוד, אינו חשוף לקוד, ולכן ישנה הפרדה לכך שבדיקות קופסה לבנה יבוצעו על ידי המתכנתים ולא על ידי הבודקים.
נושא נוסף הוא, שיכולים להיות מצבים בהחלט, שאנחנו רואים בתעשייה, שיש לנו מסלולים רבים בתוך שורת הקוד, ולא ניתן באופן כללי ואבסולוטי לכסות תמיד את כל המסלולים. מה שאומר שחלק מהקוד לא ייבדק, ואנחנו יוצאים מנקודת הנחה שהיכולת שלנו לבדוק את הקוד היא בסופו של יום יכולת חלקית מאוד.
זה כמובן מתכתב עם אחד מעקרונות הבדיקה של ה-ISTQB שמדבר על כך שלא ניתן לבדוק את כלל האפשרויות. הנחת עבודה שאנחנו חייבים לאמץ אותה, והיא בעצם תוביל אותנו ליכולת שלנו לעבוד בצורה של ניהול סיכונים ותעדוף הבדיקות שנרצה לבצע. זה נכון בהחלט גם לבדיקות קופסה לבנה. נצטרך להחליט איפה אנחנו בעצם שמים את הדגש.
נושא נוסף שחשוב לומר אותו כחסרון, זה למרות שיש פה באמת אופציה לבדוק ולמצוא הרבה מאוד בעיות ושגיאות, אנחנו לא נוכל באמצעות בדיקות קופסה לבנה לזהות בעיות שקשורות ברמת הדרישות החסרות, או חלקים שלא מימשו בקוד, מהסיבה הפשוטה שאין לנו חשיפה לדרישות עצמם אם אנחנו בודקים קוד, ואנחנו גם יכולים לבדוק קוד אבל לא לדעת איזה חלקים חסרים ואיזה חלקים לא מימשו, כי אנחנו נמצאים מול קוד מסוים ואנחנו לא יודעים מה היה אמור להיות. כך שמהבחינה הזאת יש לנו חסרון מסוים בשיטה או באימוץ השיטה הזאת.
[חסות]
שאלה שיכולה להישאל, אוקיי, אז איפה זה פוגש אותנו? איפה נראה את הנושא הזה של White box Testing, גם אם זה נעשה במחלקות הפיתוח?
אז ברור לכולם שכל חברה בעצם מבצעת בדיקות קוד לפני שהמוצר משתחרר לשוק.
בימינו, בהווה, זה הופך להיות עוד יותר קריטי, בעיקר כשאנחנו מדברים על הקצאה של release-ים בקצב מאוד מהיר. שחרור של מוצרים לשוק בתדירויות ובמהירויות שאנחנו לא רגילים. מכאן גם מגיע נושא של מודולים אג'יליים, מודולים מאוד מהירים, שבהם הבודקים והמתכנתים הופכים בעצם לשחקנים בקבוצה אחת. ואם נרצה, נוכל לתת לא מעט דוגמאות, ובעיקר, במקומות שבהם יש שימוש בלמידת מכונה ומערכות של בינה מלאכותית, ששם גם הנושא של הקוד הוא מאוד קריטי. סטייה, ולו הקלה שבקוד, יכולה להוביל לתוצאות הרות אסון, גם ברמה של תובנות לא נכונות, וגם בסטייה ממה שהלקוח ביקש לקבל.
ניקח דוגמא את חברת "Nvidia", שמבצעת על בסיס יומי וויט בוקס טסטינג, עבור הפלטפורמות של AI, כדי להבטיח ביצועים אופטימליים בנושא של מחשוב ויישומי למידת מכונה.
חברת "Salesforce" הידועה, משתמשת בווייט בוקס טסטינג, כדי לאמת את האלגוריתמים בכלים שמונעים על ידי AI, ומפה הם מביאים הבטחה לדיוק של תחזיות ותובנות, בנושא של מכירות, עבור חברות חיצוניות.
"ספוטיפיי", ענק המוזיקה, משתמשים בבדיקות יומיומיות של הנושא, כדי לזהות בעצם את נתוני המשתמש, לעבד אותם בצורה נכונה, ובכך להמליץ להם על פלייליסטים שמותאמים אישית לטעמו של המאזין.
כך גם לגבי אפל עם סירי, ו"אליבאבא", או בכלל כל מערכות מכירה, "אמזון", שמתעסקות בנושא של העדפות הצרכן והמלצות מבוססות אלגוריתם, על תובנות לגבי איזה מוצרים נכונים לו ומה כדאי למכור.
אלו דוגמאות בודדות, אבל יש לא מעט כאלו, שמוכיחות את הנושא של שימוש בבדיקות קופסה לבנה לצד בדיקות קופסה שחורה, כדי לזהות הנעה נכונה של האלגוריתם ודיוק מקסימלי ביכולת עיבוד של התוכנה, שבעצם תוביל לתוצאות עבור המשתמשים.
ואם ניתן דוגמא מחברה ישראלית, אז יש לנו כמובן את "וויז", שבעצם מקור הקוד נבדק לא מעט פעמים על בסיס המלצות ודיווחים של המשתמשים, כדי לאפשר לחזות בצורה יותר טובה, משימוש לשימוש, את זמני התנועה שאותו לקוח עושה בהם שימוש, כדי לדעת לדייק אותו מבחינת זמן הגעה ופרמטרים נוספים.
דוגמא נוספת, שלא נוכל לתת את שם החברה, עוסקת בנושא הזה של בדיקות קופסה לבנה וכיצד הם שיפרו את המוצר שאותם הם מציגים ללקוחות שלהם.
אז מה שאני אספר, הוא על חברת סטארט-אפ בתחום הפינטק, בתחום הפיננסי, שמפתחת אפליקציה לניהול פיננסי אישי. אחרי שהם משיקים את המוצר, הם קיבלו משוב, פידבק, מהמשתמשים, שהאפליקציה מציעה המלצות לא מדויקות לגבי הוצאות.
הם לקחו את התלונה והרימו את הכפפה, והחליטו לעשות בדיקות מקיפות לכל הנושא של האלגוריתם של המוצר, קופסה לבנה כמובן, לבדוק את הלוגיקה, את התהליכים, את כל מה שקשור בעצם בכתיבת הקוד. תוך כדי הבדיקות הם מגלים שהמודל לא לקח בחשבון גורמים כמו שינויים עונתיים והוצאות חד-פעמיות. הדבר הזה כמובן הייתה לו השפעה על הנושא של התחזיות, שבסופו של יום לא היו מדויקות. בעקבות הממצאים הללו, הם החליטו לעשות מהלך ולשפר את המודל, כך שיכלול פרמטרים נוספים ויוכל ללמוד מהנתונים בזמן אמת.
אחרי שהשדרוג הזה קורה, האפליקציה מתחילה להוציא הצעות הרבה יותר מדויקות, משתמשים מדווחים על חוויית שימוש משופרת, והדבר הזה, כשלעצמו, הביא לעלייה משמעותית במספר המשתמשים הפעילים והגביר כמובן את נאמנות הלקוחות.
אז זוהי דוגמא מסיפור שקרה, וכולי תקווה שהפקתם מהשורטקאסט הזה, ולמדנו ביחד מה זה בדיקות קופסה לבנה ולמה הן חשובות. כמובן שבמציאות אפשר לממש אותם גם באמצעות תהליכי אוטומציה, כדי להקל את החזרתיות של הבדיקות הללו וכדי לאפשר לעלות על הבעיה בזמן כמה שיותר קרוב לזמן הפיתוח.
אני רוצה להודות לכם על ההקשבה, ומקווה מאוד שנראה אתכם בפודקאסטים הבאים.
אז תודה ולהתראות.
[מוזיקת סיום]
לעוד פרקים של הפודקאסט לחצו על שם הפודקאסט למטה
Comments