בדיקות בארכיטקטורה מכוונת שירותים
איך לבדוק ארכיטקטורה מכוונת שירותים (SOA)

כיצד לבדוק תוכנה בארכיטקטורת SOA? התשובה היא לא לבדוק.
יש לחשוב על תוכנה בארכיטקטורת SOA כלגו הבנוי מחלקים רבים. צריך לפרק את התוכנה לרכיבים הבנויים משירותים, בטיחות, מדיניות וכדומה ולבדוק כל רכיב בנפרד.
מדיניות - לארגון המייצר תוכנה בארכיטקטורת מכוונת שירותים חייבת להיות מדיניות מוגדרת היטב של בדיקות וסטנדרטים.
המדיניות צריכה לקבוע את הסטנדרטים בתחומים הבאים:
איכות השירות - ביצועים, אבטחה
הגדרת החוקים של הטרנזקציות העסקיות.
מדיניות של audit - כמה זמן לשמור את הלוגים, לאילו פעולות לבצע לוג וכדומה.
מדיניות התשתית - הרשאות גישה ודרכי גישה למידע, גיבויים, התאוששות מכשלונות.
על צוות הבדיקות והמתכננים ליצור מקרי בדיקה לכל מדיניות כזו ולאכוף את יישום המדיניות לאורך כל תהליך הפיתוח.
בדיקות יחידה - בדיקת יחידה היא בדיקה של הרכיבים הכי קטנים שמרכיבים את התוכנה. כל שירות מורכב ממספר קומפוננטות.
בדרך כלל בדיקות אלו מבוצעות על ידי צוות המפתחים ומטרתם לבדוק שהפונקציונליות הבסיסית של הקומפוננטות בתוך השירות עובדת כראוי ובהתאם לתכנון. כל קומפוננטה תיבדק בנפרד לפני שתשלח לאינטגרציה לתוך שירות.
צריך לבדוק שהקומפוננטה עומדת במדיניות שהגדירה החברה.
בדיקות השירותים - בגלל העיקרון של ארכיטקטורה מכוונת שירותים שיש למקסם את השימוש החוזר בשירות, נדרש מהשירות להיות נטול באגים ככל האפשר. באר שימצא בשירות יחלחל לכל הלקוחות שמשתמשים בו. מסיבה זו בדיקות שירותים הם החלק המרכזי בבדיקות ארכיטקטורת SOA.
הבדיקות הבאות נדרשות בעת בדיקת השירות:
בדיקת השירות להבטיח שהוא עומד בסטנדרטים שהוגדרו על ידי הארגון.
הבדיקות צריכות להבטיח שהשירות לא רק עומד בדרישות שהוגדרו בתכנון אלא גם בכל דרישה עתידית אפשרית שצפויה להיות. זה נובע מהעיקרון שייתכן שלשירות הנבדק יהיו בעתיד שימושים אחרים על ידי הארגון.
בדיקות רב שימושיות - צוות הבדיקות צריך להכין רשימה של כל תרחישי השימוש האפשריים בשירות ולבדוק את השירות על כל התרחישים.
בדיקות אמיתיות ובדיקות סימולציה - השירות ייבדק על ידי בדיקות סימולציה בהם צוות הבדיקות יצור driver ו-stubs דרכם הוא יתקשר עם השירות. והשירות ייבדק גם על ידי שימוש אמיתי בסביבת בדיקות.
יש לבדוק שהשירות אינו מוגבל לשימוש בפלטפורמות שונות - על צוות הבדיקות להריץ בדיקות שימוש בכל מערכות ההפעלה על מנת להבטיח שהשירות יהיה ניתן לשימוש על ידי לקוחות המשתמשים במערכות הפעלה שונות והן על ידי טכנולוגיות שונות. לדוגמה שירות יכול להצרך על ידי לקוח גם באמצעות טכנולוגית ‎.NET וגם על ידי java.
בדיקות פונקציונליות - צוות הבדיקות צריך לוודא שהשירות עונה על הדרישות הפונקציונליות שהוגדרו בתכנון.
בדיקות עומסים - צוות התוכנה צריך להריץ בדיקות עומסים כדי לוודא שהסטנדרט שהארגון התחייב לספק אכן נשמר. בדיקות אלו יכללו בדיקה של השירות כמול כמות גדולה של משתמשים ועומסים שונים כדי לראות בכמה משתמשים בו זמנית השירות מסוגל לתמוך.
בדיקות אבטחה - מכיוון שארכיטקטורת שירותים מבוזרת על פני מחשבים רבים וכל שירות בארכיטקטורה עצמאי ויכול להשתמש בבסיס נתונים שונה, יש חשיבות רבה לעקוף אחר סטנדרט אבטחה אחיד לאורך השירותים המרכיבים את התוכנה. יש לתת דגש בבדיקות על בדיקות אבטחה בכל שירות ובמעבר המידע בין השירותים השונים.
בדיקות אינטגרציה - בדיקות אינטגרציה הם הבדיקות שבודקות את החיבור של כל השירותים השונים המרכיבים את התוכנה. כל מה שנוגע לאינטגרציה בתוכנה מועצם כאשר מדובר על ארכיטקטורת SOA. בבדיקות אינטגרציה של SOA צריכים לקחת בחשבון שירותים של צד שלישי, שירותים שנפלו או חסרים, שירותים שעברו שינוי ודברים נוספים שאינם קיימים בארכיטקטורה "רגילה".
השירותים מבוזרים ויכולים לרוץ על פלטפורמות שונות ולהיכתב בשפות שונות. המוסכמה ב-SOA שגם אם שירות משתדרג ומשתנה הוא חייב לתמוך בממשק אותו הוא פרסם ועל זה מתבססות גם הבדיקות. יש צורך לבדוק גם בתהליך הפיתוח וגם לאורך חיי המוצר שכל השירותים תומכים בממשק שהם פרסמו.
כיוון שהתוכנה מורכבת משירותים שונים יש לוודא שכל השירותים מתקשרים בצורה נכונה אחד עם השני. בבדיקות אלו יינתן דגש על בדיקות הממשקים של השירות ומעבר המידע בין השירותים. יבדקו פרוטוקולי הרשת והאבטחה הנדרשים לתקשורת בין השירותים.
בדיקות מערכת - בבדיקות אלו נבדוק את מוצר התוכנה השלם.
בדיקות אלו מתבצעות לאחר כל שלבי הבדיקות הקודמים ולכן נניח שכל שאר המרכיבים השונים בתוכנה כבר נבדקו. בבדיקות אלו נשים דגש בתרחישי השימוש השונים של המשתמשים. יבדקו התקינות של הטרנזקציות העסקיות שהלקוחות הגדירו בעת תכנון התוכנה. כדי להבטיח ששלב זה יבוצע כראוי יש לשלב בצוות בדיקות התוכנה גם את נציגי הלקוח.
בדיקות לא פונקציונליות - 
כאשר השירות מפורסם ברשת לא ניתן לחזות במדויק מה תהיה רמת העומס בו הוא יצטרך לעמוד. שירותים יכולים להיות פופולריים במהרה וידרשו לתמוך במספר משתמשים רב בו זמנית.
צריכים להיכתב בדיקות שיבדקו כיצד השירות מתנהג שמביאים אותו לקצה היכולת מבחינת עומסי השימוש.
לפי SLA s-service level agreements בדרך כלל נדרש משירות להיות זמין בסביבות 95% - 99% מהזמן. צריכות להיות בדיקות שירוצו זמן רב וימדדו את רמת הזמינות של השירות ולבדוק אם רמת הביצועים של השירות משתנה כתלות בזמן ובעומסים.
יש כלים רבים בשוק שמאפשרים לבדוק ביצועים של שירותים, אך הכלים האוטומטים אינם מספיקים בפני עצמם. כבר בשלב התכנון של המוצר, יש להגדיר בצורה ברורה מהן הדרישות הלא פונקציונליות ולהגדיר מקרי בדיקה מתאימים שילוו את המפתחים לאורך כל שלב הפיתוח. בתכנון מקרי בדיקה אלו יגדירו אילוצים כמו: זמן תגובה מקסימלי, מספר מקסימלי של משתמשים לשנייה וכדומה.