בדיקות בארכיטקטורה מכוונת שירותים

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

בדיקות תוכנה בארכיטקטורה מוכוונת שירותים לעומת בדיקות תוכנה רגילות

השוני העיקרי נובע מהיתרונות שהארכיטקטורה מציגה לתהליך הפיתוח - מהירות וגמישות.
היתרונות מושגים באמצעות תהליך של אי-צמידות, תהליך שמנסה לגרום לתלות נמוכה ככל האפשר בין המערכות השונות. התהליך גורר צרכים מיוחדים לפיתוח בארכיטקטורה מכוונת שירותים.
כדי להמחיש מהם בדיקות בארכיטקטורה מכוונת שירותים נראה דוגמה לתהליך של קניית מחשב באינטרנט. התהליך כולל צפייה בקטלוג המוצרים של החברה ובחירת המוצר. לאחר בחירת המוצר תהליך הרכישה מתבצע באמצעות web services. שירותי הרשת שישתתפו בתהליך יהיו: בדיקת זמינות המוצר במלאי, יצירת בקשת הרכישה ופרטי המשלוח לשירות אחר שיחשב את עלות המשלוח והעלות הכוללת של המוצר. לאחר חישוב העלות הבקשה תשלח לשירות שיקבע מספר הזמנה ייחודי במערכת ההזמנות לצורך מעקב וביצוע התשלום. משם יעשה שימוש בשירות שבודק בחברת האשראי את פרטי האשראי ומאמת שניתן לבצע את העסקה. כדי לבדוק את התהליך הנ"ל יש לבדוק את כל אחד מהשירותים בתהליך. כאשר יש לוודא שכל השירותים יודעים ל"דבר" אחד עם השני. למשל אם שירות אחד מצפה לקבל מספר לקוח כ-integer ושירות אחר מצפה לקבל מספר לקוח כ-string. יש לוודא שכל התקשורת בין השירותים עובדת כראוי.

ממשק משתמש

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

פערים טכנולוגיים

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

לוגיקה

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

QoS - איכות השירות

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