בדיקות בארכיטקטורה מכוונת שירותים
בדיקות ארכיטקטורה מכוונת שירותים - ערך זה מתאר את עקרונות בדיקות התוכנה בארכיטקטורה מוכוונת-שירותים.
פיתוח בארכיטקטורה מוכוונת-שירותים מקל על מנהלי הארגון (חיסכון בעלויות פרויקטים), מאתגרת את עבודתם של המפתחים בארגון (אינטגרציה בין מערכות שונות), אך מקשה על עבודת הבודקים. פיתוח בארכיטקטורה זו אומנם מוזיל בעלויות הפרויקט אך ללא יישום מתודולוגיית פיתוח נאותה עלול להגדיל את עלויות הפרויקט בשל הצורך במשאבים רבים על-מנת לבדוק את התהליך או המוצר הסופי. על-מנת ליהנות מהיתרונות שבפיתוח בארכיטקטורה זו מוטל על החברה להטמיע ידע, מתודולוגיות וכלים מתאימים המוקדשים לבדיקות SOA.
בדיקות תוכנה בארכיטקטורה מוכוונת שירותים לעומת בדיקות תוכנה רגילות
עריכההשוני העיקרי נובע מהיתרונות שהארכיטקטורה מציגה לתהליך הפיתוח - מהירות וגמישות. היתרונות מושגים באמצעות תהליך של אי-צמידות, תהליך שמנסה לגרום לתלות נמוכה ככל האפשר בין המערכות השונות. התהליך גורר צרכים מיוחדים לפיתוח בארכיטקטורה מכוונת שירותים.
כדי להמחיש מהם בדיקות בארכיטקטורה מכוונת שירותים נראה דוגמה לתהליך של קניית מחשב באינטרנט. התהליך כולל צפייה בקטלוג המוצרים של החברה ובחירת המוצר. לאחר בחירת המוצר תהליך הרכישה מתבצע באמצעות web services. שירותי הרשת שישתתפו בתהליך יהיו: בדיקת זמינות המוצר במלאי, יצירת בקשת הרכישה ופרטי המשלוח לשירות אחר שיחשב את עלות המשלוח והעלות הכוללת של המוצר. לאחר חישוב העלות הבקשה תשלח לשירות שיקבע מספר הזמנה ייחודי במערכת ההזמנות לצורך מעקב וביצוע התשלום. משם יעשה שימוש בשירות שבודק בחברת האשראי את פרטי האשראי ומאמת שניתן לבצע את העסקה. כדי לבדוק את התהליך הנ"ל יש לבדוק את כל אחד מהשירותים בתהליך. כאשר יש לוודא שכל השירותים יודעים ל"דבר" אחד עם השני. למשל אם שירות אחד מצפה לקבל מספר לקוח כ-integer ושירות אחר מצפה לקבל מספר לקוח כ-string. יש לוודא שכל התקשורת בין השירותים עובדת כראוי.
צרכים מיוחדים בבדיקות SOA
עריכהממשק משתמש
עריכהבדיקות התוכנה המסורתיות מניחות את קיומו של ממשק משתמש כלשהו, לעיתים גרפי, באמצעותו ניתן לתקשר עם המערכת על-מנת לבצע בדיקות פונקציונליות, בדיקות עומסים ועוד. בבדיקות SOA הממשק הנתון אינו גרפי ומגיע בפלטפורמות שונות (SOAP לדוגמה). על בודק התהליך לדעת להתממשק ולתקשר עם השירות הנבדק ואף לחבר אליו כלי בדיקה במידת הצורך.
העדר הממשק המסורתי מציג קושי נוסף - תרחישי שימוש מרובים וקלטים מהמשתמש. הממשקים המסורתיים "מגבילים" את המשתמש בכך שהם מנחים סדר פעולות ותרחישים קבועים ושדות קלט המנסים להגדיר את סוגי הקלט השונים. בהיעדר ממשק לבדיקת השירות, על הבודק לזהות תרחישים וקלטים אפשריים שכמותם עשויה להיות גדולה עד בלתי אפשרית לחיזוי. העדר "ראש" לשירות הנבדק מציג רמת קושי איתה נאלץ להתמודד הבודק.
פערים טכנולוגיים
עריכהבפיתוח "מסורתי" רוב הפרויקט מתבצע כתהליך יחיד על ידי צוות אחד או יותר בתוך אותה החברה. שירותי SOA מאוחסנים בשרתים מרוחקים, בסביבות טכנולוגיות הטרוגניות ופותחו על ידי מפתחים שונים בזמנים שונים. על בודק התוכנה להיות מסוגל לאסוף את כל השירותים המעורבים בתהליך יחד על-מנת ליצור בדיקה לתהליך שלם.
לוגיקה
עריכהבשירותי SOA הלוגיקה של האפליקציה נמצאת במעיין שכבת ביניים, עושה שימוש במספר טכנולוגיות ונמצאת על-גבי שרתים מחוץ לארגון. עובדה זו מציגה אתגר בפני הבודק שנאלץ לאתר בעיה או תקלה באפליקציה שהוא אינו יכול לצפות בלוגיקה שלה ולעיתים אף לא מציעה תמיכה מספקת.
באפליקציות "קלאסיות", העושות שימוש ברשת, העומס בו יעשו שימוש הלקוחות חזוי מראש. כמו כן, ידועים גם פרופילי המשתמש ותרחישי השימוש. באפליקציה העושה שימוש בשירותי SOA, בשל השימוש בשירותים ואפליקציות חיצוניות, על המפתח לנסות ולחזות את כל תרחישי ופרופילי השימוש איתם תתמודד האפליקציה. על הבודק, כחולייה בשרשרת קביעת איכות התוכנה, לקבוע האם האפליקציה עומדת בסטנדרט איכות השירות לה התחייבה החברה אל מול הלקוח, עם דגש על מגוון סוגי השימוש ועומסים נתונים, על-מנת לספק את שביעות רצונו.
אתגרים מיוחדים לבדיקות SOA
עריכהבנוסף לצרכים המיוחדים הנובעים מההבדלים בין בדיקות "רגילות" לבדיקות SOA, קיימים אתגרים ייחודיים לבדיקות מכוונות שירותים המציבים אתגרים בפני הבודקים.
- אבטחה - ניתן להתבונן על אפליקציה המפותחת ב-SOA, כעל אוסף של אפליקציות בלתי-תלויות המחוברות יחד על-מנת ליצור תהליך עסקי בעל-ערך. כל אחת מהאפליקציות הללו מיישמת מנגנון אבטחה משלה ואוכפת מדיניות אבטחה עצמאית. בעקבות זאת נדרש לקבוע מי אחראי לבדיקת השירותים (מפתח השירות או דורש השירות), וקביעת סטנדרט אמינות מסוים.
- עדכונים - ניתן להביט על כל שירות כעל אפליקציה עצמאית. ככזו, כל שירות עשוי, עם הזמן, להתפתח, להשתדרג ולהשתנות. על הבודק, כפי שחל גם על דורש השירות, חלה האחריות לבדיקת השירות בכל זמן מסוים על מנת לעדכן את התהליך העושה בו שימוש. שירות שהשתנה עשוי לשנות את רמת השימושיות או את רמת הביצועים בהם תומכת המערכת.
עקרונות לבדיקות תוכנה בארכיטקטורת SOA
עריכה- יש להקדיש כמות משאבים זהה לבדיקות לאורך כל התהליך הפיתוח. בבדיקות תוכנה בכלל ובבדיקות ארכיטקטורת SOA בפרט התחלה של שלב הבדיקות רק לאחר השלמת הפיתוח עלולה לגרום לנפילת הפרויקט. יש חשיבות רבה לגילוי שגיאות מוקדם בפיתוח SOA עקב השימוש החוזר הרב שנעשה בשירותים. באג שלא יתגלה בשלב מוקדם יחלחל וישפיע על שירותים רבים נוספים שמשתמשים בשירות התקול.
- צוות הבודקים צריך להיות בעל הידע הטכנולוגי המתאים לבדיקות SOA. בודק תוכנה בארכיטקטורת SOA צריך להיות בעל ידע נרחב ברשתות ואבטחה. יתר על כן מכיוון שהלוגיקה של התוכנה מבוזרת על פני שירותים רבים, קשה לבדוק את הטרנזקציות העסקיות ולכן רצוי לשלב עם צוות הבודקים גם אנשים בעלי אוריינטציה עסקית שמבינים את הטרנזקציות העסקיות לעומק.
- בדיקות האבטחה אינן חלק זניח שמבצעים בסוף הפרויקט.
- מכיוון שהשירותים עוברים שינויים וצומחים לאורך הזמן יש להשתמש בכלים אוטומטים שיוכלו בכל רגע לבצע ניטור על כל השירותים שהתוכנה משתמשת בהם ולזהות בצורה אוטומטית מתי שירות אינו עומד בסטנדרטים שהוגדרו על ידי החברה או שאינו תומך בממשק שפרסם.
כיצד לבדוק תוכנה בארכיטקטורת SOA? התשובה היא לא לבדוק. יש לחשוב על תוכנה בארכיטקטורת SOA כלגו הבנוי מחלקים רבים. צריך לפרק את התוכנה לרכיבים הבנויים משירותים, בטיחות, מדיניות וכדומה ולבדוק כל רכיב בנפרד.
מדיניות - לארגון המייצר תוכנה בארכיטקטורת מכוונת שירותים חייבת להיות מדיניות מוגדרת היטב של בדיקות וסטנדרטים. המדיניות צריכה לקבוע את הסטנדרטים בתחומים הבאים:
- איכות השירות - ביצועים, אבטחה
- הגדרת החוקים של הטרנזקציות העסקיות.
- מדיניות של audit - כמה זמן לשמור את הלוגים, לאילו פעולות לבצע לוג וכדומה.
- מדיניות התשתית - הרשאות גישה ודרכי גישה למידע, גיבויים, התאוששות מכשלונות.
על צוות הבדיקות והמתכננים ליצור מקרי בדיקה לכל מדיניות כזו ולאכוף את יישום המדיניות לאורך כל תהליך הפיתוח.
בדיקות יחידה - בדיקת יחידה היא בדיקה של הרכיבים הכי קטנים שמרכיבים את התוכנה. כל שירות מורכב ממספר קומפוננטות. בדרך כלל בדיקות אלו מבוצעות על ידי צוות המפתחים ומטרתם לבדוק שהפונקציונליות הבסיסית של הקומפוננטות בתוך השירות עובדת כראוי ובהתאם לתכנון. כל קומפוננטה תיבדק בנפרד לפני שתשלח לאינטגרציה לתוך שירות. צריך לבדוק שהקומפוננטה עומדת במדיניות שהגדירה החברה.
בדיקות השירותים - בגלל העיקרון של ארכיטקטורה מכוונת שירותים שיש למקסם את השימוש החוזר בשירות, נדרש מהשירות להיות נטול באגים ככל האפשר. באר שימצא בשירות יחלחל לכל הלקוחות שמשתמשים בו. מסיבה זו בדיקות שירותים הם החלק המרכזי בבדיקות ארכיטקטורת SOA. הבדיקות הבאות נדרשות בעת בדיקת השירות:
- בדיקת השירות להבטיח שהוא עומד בסטנדרטים שהוגדרו על ידי הארגון.
- הבדיקות צריכות להבטיח שהשירות לא רק עומד בדרישות שהוגדרו בתכנון אלא גם בכל דרישה עתידית אפשרית שצפויה להיות. זה נובע מהעיקרון שייתכן שלשירות הנבדק יהיו בעתיד שימושים אחרים על ידי הארגון.
- בדיקות רב שימושיות - צוות הבדיקות צריך להכין רשימה של כל תרחישי השימוש האפשריים בשירות ולבדוק את השירות על כל התרחישים.
- בדיקות אמיתיות ובדיקות סימולציה - השירות ייבדק על ידי בדיקות סימולציה בהם צוות הבדיקות יצור driver ו-stubs דרכם הוא יתקשר עם השירות. והשירות ייבדק גם על ידי שימוש אמיתי בסביבת בדיקות.
- יש לבדוק שהשירות אינו מוגבל לשימוש בפלטפורמות שונות - על צוות הבדיקות להריץ בדיקות שימוש בכל מערכות ההפעלה על מנת להבטיח שהשירות יהיה ניתן לשימוש על ידי לקוחות המשתמשים במערכות הפעלה שונות והן על ידי טכנולוגיות שונות. לדוגמה שירות יכול להצרך על ידי לקוח גם באמצעות טכנולוגית .NET וגם על ידי java.
- בדיקות פונקציונליות - צוות הבדיקות צריך לוודא שהשירות עונה על הדרישות הפונקציונליות שהוגדרו בתכנון.
- בדיקות עומסים - צוות התוכנה צריך להריץ בדיקות עומסים כדי לוודא שהסטנדרט שהארגון התחייב לספק אכן נשמר. בדיקות אלו יכללו בדיקה של השירות כמול כמות גדולה של משתמשים ועומסים שונים כדי לראות בכמה משתמשים בו זמנית השירות מסוגל לתמוך.
- בדיקות אבטחה - מכיוון שארכיטקטורת שירותים מבוזרת על פני מחשבים רבים וכל שירות בארכיטקטורה עצמאי ויכול להשתמש בבסיס נתונים שונה, יש חשיבות רבה לעקוף אחר סטנדרט אבטחה אחיד לאורך השירותים המרכיבים את התוכנה. יש לתת דגש בבדיקות על בדיקות אבטחה בכל שירות ובמעבר המידע בין השירותים השונים.
בדיקות אינטגרציה - בדיקות אינטגרציה הם הבדיקות שבודקות את החיבור של כל השירותים השונים המרכיבים את התוכנה. כל מה שנוגע לאינטגרציה בתוכנה מועצם כאשר מדובר על ארכיטקטורת SOA. בבדיקות אינטגרציה של SOA צריכים לקחת בחשבון שירותים של צד שלישי, שירותים שנפלו או חסרים, שירותים שעברו שינוי ודברים נוספים שאינם קיימים בארכיטקטורה "רגילה". השירותים מבוזרים ויכולים לרוץ על פלטפורמות שונות ולהיכתב בשפות שונות. המוסכמה ב-SOA שגם אם שירות משתדרג ומשתנה הוא חייב לתמוך בממשק אותו הוא פרסם ועל זה מתבססות גם הבדיקות. יש צורך לבדוק גם בתהליך הפיתוח וגם לאורך חיי המוצר שכל השירותים תומכים בממשק שהם פרסמו. כיוון שהתוכנה מורכבת משירותים שונים יש לוודא שכל השירותים מתקשרים בצורה נכונה אחד עם השני. בבדיקות אלו יינתן דגש על בדיקות הממשקים של השירות ומעבר המידע בין השירותים. יבדקו פרוטוקולי הרשת והאבטחה הנדרשים לתקשורת בין השירותים.
בדיקות מערכת - בבדיקות אלו נבדוק את מוצר התוכנה השלם. בדיקות אלו מתבצעות לאחר כל שלבי הבדיקות הקודמים ולכן נניח שכל שאר המרכיבים השונים בתוכנה כבר נבדקו. בבדיקות אלו נשים דגש בתרחישי השימוש השונים של המשתמשים. יבדקו התקינות של הטרנזקציות העסקיות שהלקוחות הגדירו בעת תכנון התוכנה. כדי להבטיח ששלב זה יבוצע כראוי יש לשלב בצוות בדיקות התוכנה גם את נציגי הלקוח.
בדיקות לא פונקציונליות - כאשר השירות מפורסם ברשת לא ניתן לחזות במדויק מה תהיה רמת העומס בו הוא יצטרך לעמוד. שירותים יכולים להיות פופולריים במהרה וידרשו לתמוך במספר משתמשים רב בו זמנית. צריכים להיכתב בדיקות שיבדקו כיצד השירות מתנהג שמביאים אותו לקצה היכולת מבחינת עומסי השימוש. לפי SLA s-service level agreements בדרך כלל נדרש משירות להיות זמין בסביבות 95% - 99% מהזמן. צריכות להיות בדיקות שירוצו זמן רב וימדדו את רמת הזמינות של השירות ולבדוק אם רמת הביצועים של השירות משתנה כתלות בזמן ובעומסים. יש כלים רבים בשוק שמאפשרים לבדוק ביצועים של שירותים, אך הכלים האוטומטים אינם מספיקים בפני עצמם. כבר בשלב התכנון של המוצר, יש להגדיר בצורה ברורה מהן הדרישות הלא פונקציונליות ולהגדיר מקרי בדיקה מתאימים שילוו את המפתחים לאורך כל שלב הפיתוח. בתכנון מקרי בדיקה אלו יגדירו אילוצים כמו: זמן תגובה מקסימלי, מספר מקסימלי של משתמשים לשנייה וכדומה.
תוכנות בדיקות בארכיטקטורה מכוונת שירותים
עריכה- soupUI - כלי נפוץ מאוד שמאפשר ליצור, לבחון ולפתח שירותי ווב. אפשר לשלב אותו בקלות במסגרת לבדיקה של עומסים ופונקציות.
- Green Hat - גרין האט מסייעת בשיפור איכות יישומי תוכנה, באמצעות שימוש בטכנולוגיות מחשוב ענן, לצורך עריכת בדיקות מקיפות עוד לפני פריסת התוכנה בפועל. הפתרונות של גרין האט מאפשרים הקמת סביבת בדיקות וירטואלית בתוך דקות ספורות לעומת שבועות ארוכים שנדרשו לכך בעבר, ובעלויות מופחתות בהרבה. החברה נרכשה על ידי IBM ופועלת בתחומי הבדיקות והבדיקות האוטומטיות בסביבת ענן, שירותי ווב, ארכיטקטורה מוכוונת שירותים (SOA) ועוד.
- Parasoft - יחודו של כלי זה בהיותו כולל סט מלא ושלם של כלים סטטיים ודינמיים מורכבים, הערוכים לתת מענה מספק לרוב דרישות פרויקט העושה שימוש בארכיטקטורה מוכוונת שירותים. התוכנה מאפשרת אוטומציה של תהליכים המאפשרים, בין היתר, לנהל בצורה אוטומטית בדיקות של אפליקציות ברשת, שליחת מסרים בפרוטוקולים שונים, בדיקות בענן ובדיקות אבטחה.