תכנון בדיקות ל- Client/Server Application

בפוסט הזה נעסוק בתכנון בדיקות של C/S Application. ננסה להתמקד בשלבים השונים של הבדיקות של המוצר.

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


לפני שמתחילים לבדוק מוצר C/S, כדאי ללמוד עליו היטב. ממה הוא בנוי, האם קיים לו API, עם אילו רכיבים הוא מתקשר, באילו מערכות הפעלה הוא נתמך, אם הוא Web Application - אז מתווספים לעניין תמיכה ב- Browsers שונים.

שלב א - סרטוט הסכימה של המוצר

c-sharpcorner.com

commons.wikimedia.org

מוצר C/S אינו חי בתוך וואקום. כמעט תמיד הוא מתקשר עם חוליות שונות מלבד התקשורת הבסיסית בין ה-Client ל-Server.

למוצר שלכם ייתכנו פריסות שונות של תקשורת: ה-Client וה-Server עשויים לרוץ על אותה מכונה, או לרוץ על מכונות שונות באותה רשת או מקושרים דרך האינטרנט.

ה-Server עשוי להתקשר עם שרתים נוספים - כמו DB, Storage וכדו' מהם הוא עשוי לבצע שאילתות כדי להציג אותם מול ה- Client.

ה-Server עשוי לשרת משתמש בודד או מספר רב של משתמשים.

לכל אלה ישנן השלכות משמעותיות על תכנון הטסטים שתכתבו.

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

שלב ב - תכנון רזולוצית הבדיקות

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

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

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

כדאי לברר אם ל-Server קיים API איתו ניתן לתקשר באמצעות קוד. במידה וכן ניתן לכתוב בדיקות שימומשו ע"י אנשי אוטומציה שיכתבו את הקוד שיבצע את הבדיקות.

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

לעיתים אין לשרת API או שאנשי הפיתוח אינם מתכוונים להשקיע מזמנם לטובת הנושא, אך עדיין השרת יודע לענות לשאילתות כמו REST או SNMP.

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

שלב ג - תכנון שלבים לבדיקות

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

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

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

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

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

שלב ד - תכנון ביצוע הבדיקות

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

ייתכן שמדובר בבדיקות שירוצו אוטומאטית ע"י שרתים ייעודיים כמו Jenkins - גם כאן כדאי לבדוק האם הבדיקות צריכות לרוץ על כל build או אולי לחכות שמישהו יריץ אותם לפי הצורך.

שלב ה - תכנון הבדיקות

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

במידה ומדובר ב- Web Application כדאי לשקול בדיקות Penetration Tests ובדיקות של Error Injection.

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

מהו ה- Quality Of Service הרצוי ? האם השרת צריך לספק בכל מצב נתונים ולתת מענה לכל דרישה ? 

לכמה מערכות הפעלה צריך לתת מענה ? האם לכל הגרסאות כולל x86 ו- x64 ? האם גם למחשבי Mac ?

לכמה Browserים צריך לתת מענה ? האם לכל גרסה שיצאה ? 

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

תשתית ה- Selenium לא חייבת להיות בנויה in-house - ניתן להשתמש בשירותים חיצוניים דוגמת Saucelabs

לסיכום - 

ראינו, על קצה המזלג, אפשרויות שונות לתכנון מקיף לבדיקות למוצר C/S.

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

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

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