تست وب سرویس

الگوی محاسبات سرویس گرا (SOC) امکان تعامل سیستم های کامپیوتری با یکدیگر را فراهم می سازد. SOC اجازه می دهد اپلیکیشن های توزیع شده، مستقل از بستر پیاده سازی با یکدیگر ترکیب شوند و لذا هزینه ها کاهش پیدا کرده و توسعه سیستم‌ ها نیز راحت تر و سریع تر می گردد. در حال حاضر وب سرویس ها به دلیل عدم وابستگی به پلتفرم یا زبان برنامه نویسی یکی از پذیرفته شده ترین تکنولوژی های مبتنی بر سرویس هستند. در هر حال وب سرویس نیز چالش هایی دارد. برای مثال، تست client-side وب سرویس به دلیل ماهیت پیچیده وب سرویس و عدم دسترسی به کد منبع از تست دیگر نرم افزارهای سنتی سخت تر است. در این مقاله به بررسی تاریخچه تست وب سرویس، نقاط ضعف و قوت استراتژی های تست وب سرویس و شناسایی مسائل برای اقدامات آتی می پردازیم. تست وب سرویس شامل تست عملکردهای اصلی وب سرویس، تست تعامل پذیری وب سرویس، تست کارایی شامل تست بار و فشار، تست امنیت و غیره می باشد.

تست وب سرویس

1.ایجاد موارد آزمون (Test-Case)

براساس استانداردهای تست IEEE، مورد آزمون عبارت است از "مشخصات ورودی های تست، نتایج مورد انتظار و شرایط اجرا برای هر آیتم تست". بنابراین برای ایجاد موارد آزمون ابتدا باید ورودی های آزمون را ایجاد نمود. برای ایجاد ورودی های تست باید به سیستمی که می خواهیم تست کنیم توجه نموده و با بررسی مواردی از جمله رفتار سیستم، مشخصات سیستم، سورس کد، نیازمندی های سیستم و غیره ورودی های تست را به دست آوریم. در تست وب سرویس ها، از دو روش تست مبتنی بر مشخصات (specification-based) و مبتنی بر مدل (model-based) برای تولید ورودی های آزمون استفاده می شود.

ایجاد موارد آزمون

تست مبتنی بر مشخصات، صحت سنجی سیستم را با استفاده از سندهای مرجع مثل مشخصات رابط کاربری، لیست نیازمندی ها، سند طراحی و غیره بررسی می کند. به طور معمول تست مبتنی بر مشخصات، تنها با سندهایی که برای سیستم موجود است قابل اجراست و مواردی که در اسناد نیامده باشند قابل تست نیستند. در وب سرویس از مهم ترین سندهایی که باید بررسی شوند WSDL specifications و XML Schema Datatype هستند.

2.تست پارتیشن (Partition Testing)

تست پارتیشن یک تکنیک تست است که هدف از آن یافتن زیرمجموعه هایی از موارد آزمون موجود است که بتواند به اندازه کافی یک سیستم را تست کند. هدف از تست پارتیشن آن است که دامنه ورودی سیستم تحت تست را به زیر دامنه هایی تقسیم نمود. بنابراین انتخاب یا ایجاد تعدادی از موارد آزمون از هر زیر دامنه برای تست کل دامنه کافی خواهد بود. نتایج نشان می دهد که تست پارتیشن می تواند با کاهش تعداد موارد آزمون مورد نیاز برای تست و در نتیجه کاهش تعداد تست ها، منجر به کاهش هزینه های تست شود[1].

تست پارتیشن

3.تست واحد وب سرویس (Unit Testing of Web Services)

تست واحد می تواند یک روش تست پایه برای هر سیستم باشد. در تست واحد، واحدهای مجزای یک سیستم که می توانند به صورت مستقل اجرا شوند، به عنوان پایه در نظر گرفته می شوند. از دیدگاه وب سرویس ، عملیات ارائه شده توسط یک سرویس می تواند به عنوان واحد تحت تست مورد توجه قرار گیرد. تست واحد وب سرویس ، با ارسال و دریافت پیام های SOAP توسط تستر انجام می شود. تستر پیام های SOAP را از طریق اطلاعات فایل WSDL برای عملیات تحت آزمون تولید می کند. در این روش تست واحد می تواند صحت WSDL و عملکرد درست سیستم تحت تست را تأیید کند.
یکی از مسائل اصلی آزمون عملکردی وب سرویس، هزینه بالای آن است[1]. تست واحد یکی از مهمترین سطوح تست است که هر سیستم نرم افزاری اصولا باید از آن استفاده نماید. چالش اصلی در تست واحد وب سرویس، هزینه های بالای تست است که می تواند با خودکار سازی فرآیند تست به حداقل برسد. برای تست واحد، ابزارهایی برای ارائه تست های خودکار مانند Parasoft SOAtest ، SOAP Sonar، HP service Test و Oracle Application Testing Suite ارائه شده است. با اینکه این ابزارها به کاهش کار دستی مورد نیاز برای تولید موارد آزمون و تهیه گزارشات تست کمک می کنند، ولی روند تست اتوماتیک را به طور کامل انجام نمی دهند. در استفاده از تمام این ابزارها، موارد آزمون توسط تستر تولید و ابزار، درخواست های SOAP را برای هر مورد آزمون تولید می کند.

تست واحد وب سرویس

یکی از مشکلات عمده تست نرم افزار، مشکل اوراکل است [3 ، 2]. اوراکل مکانیزمی است که برای تعیین خروجی مورد انتظار برای هر ورودی آزمون مورد استفاده قرار می گیرد. در تست وب سرویس، کاربر سرویس اغلب هیچ تست قابل اعتمادی از اوراکل ندارد. عدم وجود یک تست اوراکل یکی از چالش های تست وب سرویس خودکارسازی شده است.

4.تست مبتنی بر مدل و تأیید رسمی وب سرویس

تست مبتنی بر مدل یک روش تست است که در آن موارد آزمون با استفاده از یک مدل که رفتار سیستم تحت تست را توصیف می کند، تولید می شوند. مزایای تست مبتنی بر مدل، از قبیل فرآیند تولید اتوماتیک موارد آزمون و توانایی تحلیل کیفیت محصول به صورت ایستا، آن را یک روش تست محبوب کرده است.

4-1. تست مبتنی بر مدل با استفاده از اجرای نمادین (Symbolic Execution)

اجرای نمادین به عنوان مبنایی برای یک روش تایید استفاده می شود که بین تایید رسمی و غیر رسمی قرار دارد. در آزمون نمادین، سیستم تحت تست بطور نمادین با استفاده از مجموعه ای از ورودی های انتزاعی به جای مجموعه ورودی های واقعی آزمون اجرا می شود. یک کلاس ورودی انتزاعی، به عنوان یک نماد، نشان دهنده مجموعه ای از مقادیر ورودی ممکن است. خروجی اجرای نمادین به صورت یک تابع از ورودی تولید می شود.
یک روش نمونه که با استفاده از اجرای نمادین موارد آزمون تولید می کند، روش BZ-Testing-Tools (BZ-TT) است [4]. روش BZ-TT مشخصات B و Z و State-chart را به عنوان ورودی می گیرد و بر روی آنها چندین استراتژی تست مانند تجزیه پارتیشن، تست اثر علت، تست مرزی، تست دامنه و چندین تست مدل پوشش، مانند شرایط چندگانه پوشش مرزی و پوشش انتقال را انجام می دهد.

4-2. تست مبتنی بر مدل با استفاده از وارسی مدل (Model-Checking)

وارسی مدل یک روش تایید رسمی است و به عنوان یک روش برای تایید سیستم های همزمان حالت محدود به کار می رود [5]. وارسی مدل اطمینان می دهد که آیا مدل سیستم می تواند خواص داده شده را به صورت یک منطق زمانی انطباق دهد یا خیر. برای انجام وارسی مدل، یک ابزار به نام Checker Model مورد استفاده قرار می گیرد. در طول فرایند اثبات، model checker مدارک و مثال نقض برای ویژگی ارائه شده را تشخیص می دهد. مدارک و مثال نقض، مسیری در مدل اجرایی هستند. یک مدرک، مسیری است که ویژگی های آن رضایت بخش است، در حالی که یک مثال نقض، یک مسیر یعنی دنباله ای از ورودی هاست که در آن سیستم حالت محدود، خود را از حالت اولیه به حالتی که در آن مالکیت نقض شده است، می برد. مثال های نقض برای تولید موارد آزمون مورد استفاده قرار می گیرند.

تست مبتنی بر مدل با استفاده از وارسی مدل

4-3. تست مبتنی بر مدل با استفاده از Petri-Net

Petri-Net (Place / Transition Net) یک روش مدل سازی ریاضی و گرافیکی برای تعیین و تحلیل سیستم های همزمان، غیر همزمان، توزیع شده، موازی، غیرمتمرکز و تصادفی است [6] Petri-Net . تحلیل های مختلفی را برروی مدل مانند دسترسی، محدودیت، بن بست ، زنده بودن، برگشت پذیری، عدالت و تحلیل حفاظت امکان پذیر می سازد. Petri-Net همچنین می تواند برای اندازه گیری پوشش موارد آزمون استفاده شود. Petri-Net برای تست مبتنی بر مدل وب سرویس نیز مورد استفاده قرار می گیرد. به عنوان مثال، دونگ و یو روش تست Petri-Net را مطرح کرده اند که در آن High level Petri-Net (HPN)، مشابه Petri-Net ها از فایل های WSDL ساخته شده است[7 , 8]. این روش از HPNs تولید شده برای پوشش خطای بالا (fault-coverage) استفاده می کند. موارد آزمون با استفاده از HPNs و ایجاد داده های تست مبتنی بر محدودیت (constraint) تولید می شود. محدودیت های تعریف شده توسط کاربر برای انواع داده XML و محدودیت های مبتنی بر خط مشی مشخص شده توسط تستر، محدودیت های لازم برای تولید داده های تست را فراهم می کند.

مدل شبکه پتری

تست مبتنی بر مدل یک روش تست محبوب است. تست مبتنی بر مدل، یک سیستم را با استفاده از مدلی تست می کند که رفتار مورد انتظار سیستم تحت تست را برای تست هدف به شکلی مناسب توصیف کند. برای ترکیبات BPEL، یک مدل که می تواند به اندازه کافی نمایانگر فرایند باشد، ایجاد شده و بدین ترتیب تست های مبتنی بر مدل و تأیید رسمی اعمال می شود. تأیید رسمی گردش کارهای یک موضوع به طور گسترده مورد بررسی قرار گرفته است و محبوبیت این موضوع در میزان کارهایی که درباره تایید رسمی BPEL صورت گرفته است، منعکس می شود. متاسفانه، یک مدل مبتنی بر مشخصات WSDL ممکن است رفتار کاملی از وب سرویس را به دلیل کمبود اطلاعات رفتاری نشان ندهد. از سوی دیگر، مشخصات وب سرویس معنایی مانند OWL-S و WSDL-S اطلاعات بیشتری را در مورد رفتار ارائه می دهد و اجازه می دهد که یک مدل بهتر از سیستم تحت تست ایجاد شود ولذا امکان تست موثرتری بر اساس مدل فراهم گردد.

5. تست مبتنی بر قرارداد وب سرویس ها (Contract-Based)

DBC یک شیوه توسعه نرم افزار است که در آن قراردادها، پیش شرایط یک مولفه قابل دسترس را تعریف می کنند و همچنین پس شرایطی را که باید پس از اجرای متدهای مولفه با پیش شرایط مشخص شده نگه داشته شود، تعیین می کنند[10]. با استفاده از قراردادها، برخی از رفتارهای غیرمنتظره سیستم تحت تست را می توان تشخیص داد. اطلاعات مربوط به قرارداد نیز می تواند برای افزایش فرایند تست استفاده شود. از آنجایی که وب سرویس سنتی فقط اطلاعات رابط را فراهم می کند، محققان پیشنهاد استفاده از قراردادها را در جنبه های مختلف SOA مانند انتخاب خدمات، ساختار سرویس و تأیید سرویس پیشنهاد کرده اند. این قراردادها اطلاعاتی در مورد جنبه های مختلف SOA مانند رفتار سرویس و کیفیت سرویس را ارائه می دهد. این اطلاعات اضافی در مورد رفتار یک سرویس مانند پیش شرایط و پس شرایط عملیات، تست پذیری خدمات را افزایش می دهد. این نوع اطلاعات برای تست بسیار ارزشمند است. تست های وب سرویس با استفاده از قراردادها توسط بسیاری از محققین انجام شده است. برای مثال Heckel و Lochmann استفاده از روش DBC را برای وب سرویس پیشنهاد داده اند و در مورد دلایل قراردادهایی که در سطوح مختلف مانند سطح پیاده سازی، سطح XML و سطح مدل در نظر گرفته شده، بحث نموده اند[11]. قراردادهای تعریف شده در سطح مدل از خصوصیات سطح مدل استخراج شده و دلیل آن به حداقل رساندن تلاش لازم برای ایجاد قرارداد است. قرارداد های ایجاد شده در تست واحد سرویس ها، برای بررسی اینکه آیا سرویس مطابق با مشخصات آن است، استفاده می شود. با استفاده از قراردادها، روش تست پیشنهاد شده امکان ایجاد خودکار موارد آزمون و تست اوراکل را فراهم می سازد.
تست های مبتنی بر قرارداد وب سرویس می تواند تست بهتر و کارآمدتری نسبت به تست مبتنی بر WSDL را ارائه نماید طوریکه تست پذیری افزایش یابد. همچنین اجازه می دهد تا تولید موارد آزمون خودکار و ایجاد تست اوراکل کارآمدتر باشد. صرف نظر از مزایایی که قراردادها ارائه می دهند، هزینه ایجاد قراردادها باعث می شود که DBC به طور گسترده ای مورد استفاده قرار گیرد.

6. تست مبتنی بر خطای وب سرویس

هدف از آزمون مبتنی بر خطا آن است که اثبات کند سیستم تحت تست، هیچ خطای مجازی ندارد [12]. تفاوت بین موارد آزمون مبتنی بر خطا و موارد آزمون معمول، آن است که موارد آزمون مبتنی بر خطا، به جای تلاش برای یافتن خطاهای موجود، خطای شناخته شده را ثابت می کنند. تست مبتنی بر خطا می تواند سرویس های وب را برای خطاهای معمولی که می تواند در محیط SOA وجود داشته باشد و قابلیت اطمینان سرویس را افزایش دهد، تحت بررسی قرار دهد. هانا و مونرو تولید داده تست را برای تکنیک های تست مختلف طبقه بندی کرده و همچنین تحقیقات تستی مبتنی بر خطا را در حوزه وب سرویس انجام داده اند[13]. این تکنیک های تست عبارتند از:

1. تحلیل انتشار رابط که توسط برهم زدن تصادفی ورودی به یک مولفه نرم افزار انجام میشود.
2. تست ثبات مبتنی بر مقدار مرزی که در آن داده های آزمون در اطراف مرزهای پارامتر ورودی انتخاب می شوند.
3. تست syntax با ورودی نامعتبر که در آن قوانین مشخصات پارامتر ورودی نقض می شوند.
4. پارتیشن بندی هم ارز با کلاس پارتیشن معتبر که در آن فضای ورودی یا دامنه به تعداد محدودی از کلاس های هم ارز با داده های نامعتبر تقسیم می شود.

در این بررسی، دسته بندی تحقیقاتی که در تست وب سرویس مبتنی بر خطا صورت گرفته، بر اساس سطح تولید خطاها انجام شده است. تست مبتنی بر خطای سرویس های وب می تواند به سه دسته مختلف بر اساس سطح مورد استفاده برای خطاها گروه بندی شود:

اختلالات پیام XML / SOAP

تزریق خطای سطح شبکه

تغییر مشخصات وب سرویس

6-1. اختلال XML / SOAP

اختلالات XML / SOAP با ضبط پیام های SOAP بین سرویس ها و کاربران آنها انجام می شود. پیام هایی که شامل خطا هستند، به وسیله تزریق خطا به پیام های ارسال شده ، قبل از ارسال آنها یا فقط با ارسال پیام SOAP معیوب به وب سرویس ایجاد می شوند. پس از اختلال (Perturbation)، رفتار وب سرویس با پیام معیوب جهت تأیید مشاهده می شود.
یکی از اولین نمونه های اختلال SOAP توسط Offutt و Xu پیشنهاد شده است [25]. Offutt و Xu سه نوع اختلال مختلف را پیشنهاد داده اند.

1. اختلال ارزش داده (DVP) که توسط اصلاح مقادیر در یک پیام SOAP انجام می شود.
2. روش های از راه دور باعث اختلال در ارتباطات (RCP) می شود که با اصلاح استدلال روش های از راه دور انجام می شود.
3. اختلالات ارتباطات داده (DCP)که برای تست پیام هایی که شامل روابط و محدودیت های پایگاه داده هستند، استفاده می شود.

نتایج حاصل از اختلالات SOAP ، اثربخشی این رویکرد را در آشکار سازی خطاها در خدمات وب اثبات کرده است. به عنوان مثال در آزمایشات Offutt و Xu، 18 خطا در سیستم ارتباطات ربات مارپیچ (MRCS) قرار می گیرند و صد تست DVP و پانزده تست RCP و 27 تست DCP تولید می شوند. تست های تولید شده، میزان نرخ کشف خطای 78٪ در خطاهای بذرافشانی شده را به دست آورده (14 از 18) و همچنین دو خطای طبیعی را نشان داده است.

6-2. تزریق خطای سطح شبکه

تزریق خطای سطح شبکه (NLFI) ، یک روش تزریق خطاست که در آن خطاها با تخریب، رها کردن و مرتب سازی بسته های شبکه تزریق می شوند. Looker و همکاران استفاده از این تکنیک را همراه با چارچوبی به نام ابزار تزریق خطای وب سرویسپیشنهاد می کنند. تزریق تاخیر در سطح شبکه را می توان با اختلال SOAP انجام داد [14]. WS-FIT می تواند هر دو اختلال SOAP و تزریق تاخیر را انجام دهد. Looker و همکاران همچنین یکی دیگر از روش های تزریق خطا را پیشنهاد می دهند که یک سرویس معیوب را شبیه سازی می کند. تزریق سرویس معیوب با جایگزینی مقادیر در پیام های SOAP با مقادیر اشتباه و در محدوده مشخص از پارامتر انجام میشود. Looker و همکاران همچنین یک آنتولوژی مدل خطای توسعه یافته را پیشنهاد می کنند که برای تولید خطاها و حالت های شکست استفاده می شود، و آنتولوژی نوع خطاها را مشخص می کند.

اختلال SOAP با قرار دادن پارامترهای اشتباه

Looker و همکاران یک سیستم معاملاتی شبیه سازی شده بازار سهام را که شامل سه وب سرویس است، آزمایش کردند. آزمون های پایه نشان داد که تزریق تاخیر باعث شد که سیستم نتایج غیر منتظره در 63٪ از مواقع داشته باشد. با توجه به نتایج تزریق سرویس های معیوب، متوجه می شویم که کاربران با استفاده از این روش تزریق، خطاها را تجربه نمی کنند؛ با این حال، نتایج غیر منتظره زمانی مورد توجه قرار می گیرند که نتایج این روش با آزمایش های قبلی مقایسه می شود.

6-3. تغییر مشخصات وب سرویس (Mutation)

تست تغییر (موتاسیون)روشی است که برای اندازه گیری کفایت یک سوییت آزمون و نیز تولید داده های آزمون استفاده می شود. تست تغییر با تزریق خطا به سیستم تحت تست مانند تغییر و اصلاح کد منبع یا تغییر وضعیت سیستم تحت تست، در هنگام اجرای تست انجام می شود. این تغییرات با استفاده از قوانین تحول به نام اپراتورهای تغییر اعمال می شوند.

تغییر مشخصات وب سرویس

اپراتورهای تغییر در وب سرویس به طور کلی مشخصات وب سرویس را به کارمی برند. مشخصات WSDL اجازه ایجاد تغییر در سطح رابط را می دهد. سطوح دیگری از تغییر مانند کد منبع یا سطح شیء به علت محدودیت در SOA، در جامعه محققان در نظر گرفته نمی شود. نمره تغییر در سطح رابط با تعداد اشتباهاتی که در هنگام اجرای موارد آزمون به وجود می آید، با استفاده از رابط های معیوب تعیین می شود.
به طور طبیعی، یکی از اولین نمونه های تست تغییر وب سرویس به مشخصات WSDL اعمال می شود. سیبلی و منصور استفاده از تغییر WSDL را برای تشخیص خطاهای رابط در سرویس های وب پیشنهاد داده اند[15]. برای تولید مشخصات وب سرویس تغییر یافته، 9 اپراتور تغییر برای سه گروه مختلف از عناصر WSDL تعریف شده است:

1. انواع المان ها: هفت اپراتور مختلف برای این عنصر وجود دارد.

الف) تغییر نوع در نوع داده پیچیده

ب) تغییر ویژگی های یکسان در نوع داده پیچیده

پ) اضافه یا حذف عنصر در یک نوع داده پیچیده

ت) اضافه یا حذف یک ویژگی اختیاری در یک نوع داده پیچیده

ث) تنظیم ویژگی nil در یک نوع داده پیچیده

ج) تغییر عناصر انواع داده های مشابه

چ) تغییر ویژگی های انواع داده های مشابه

2. المان پیام: سوئیچ کردن قطعات بین انواع پیام های مشابه

3. المان PortType : سوئیچ پیام های مشابه در المان عملیات

H. Mei و L. Zhang اپراتور تغییر را برای قرارداد تعریف کرده اند. قراردادهای این رویکرد در مشخصات WSDL گسترش یافته گنجانده شده است[16]. قراردادهای تغییر یافته در انتخاب داده های آزمون استفاده می شوند. اپراتورهای تغییر تعریف شده توسط H. Mei و L. Zhang عبارتند از:

1. اپراتور تخفیف قرارداد
2. اپراتور مبادله وضعیت
3. اپراتور تضعیف پیش شرط
4. اپراتور تقویت پس شرط
5. قرارداد گیرنده اپراتور

گام بعدی در تست تغییر وب سرویس، تغییر در وب سرویس معنایی بود. مقدار اطلاعاتی که توسط OWL-S ارائه می شود، امکان استفاده از اپراتورهای تغییر در سطوح مختلف را نسبت به تغییر WSDL فراهم می کند. به عنوان مثال، لی و همکاران یک تغییر مبتنی بر آنتولوژی را برای اندازه گیری مناسب آزمون معنایی برای خدمات وب ترکیبی و جهت شناسایی خطاهای معنایی پیشنهاد داده اند [17]. لی و همکاران چهار نوع تغییر برای OWL-S تعریف نموده اند:

1. تغییر داده ورودی / خروجی که در آن اپراتورهای تغییر، تعاریف کلاس آنتولوژی OWL را تغییر می دهد
2. تغییر شرایط که در آن اپراتور تغییر، مشخصات شرایط را تغییر می دهد
3. کنترل جریان تغییر که در آن اپراتور تغییر، یک ساختار کنترل را با یک جایگزین معتبر، جایگزین می کند.
4. تغییر جریان داده ها که در آن اپراتورهای تغییر تعاریف و خواص وابستگی های مختلف را تغییر می دهد

کلاس های انتخابی و خواص نمایه

R. Wang و N. Huang یک تست تغییردیگری مبتنی بر آنتولوژی را پیشنهاد داده اند که از مدل الزامات OWL-S استفاده می کند[18]. R. Wang و N. Huang یک نسخه اصلاح شده از الگوی مورد نیاز را با زبان معنایی وب (SWRL) به منظور کمک به تولید تغییر ارائه نموده اند[19]. رویکرد پیشنهادی از محدودیت های اعمال شده در این مدل، برای تولید تغییر ها با استفاده از رویکرد برنامه ریزی جهت گرا استفاده می کند. AOP اجازه می دهد که به منبع کد اصلی برای تولید تغییر نیاز پیدا کند. R. Wang و N. Huang هشت اپراتور مختلف تغییر را تعریف کرده اند:

1. پارامتر خالی که جایگزین پارامترهای یک روش با رشته خالی یا مقدار صفر است
2. پارامتر مبادله که پارامترهای یک روش را مبادله می کند
3. وارد کردن اپراتور غیرمستقیم که عملگرها را به پارامترها اعمال می کند
4. تغییر پارامتر که عملگر تغییر را به پارامترها اعمال می کند
5. تغییر طول پارامتر که محدودیت هایی را که طول نوع داده ها را تعریف می کنند، تغییر می دهد.
6. تخصیص پارامتر که پارامترها را به مقادیر مرزی خود با استفاده از محدودیت های تعریف شده ،تنظیم می کند
7. زمان پاسخگویی به سرویس فرزند که اگر یک محدودیت زمان تعریف شود، فراخوانی درخواست خدمات دیگر را به تاخیر می اندازد
8. مبادله رابط سرویس فرزند که جایگزین واسط های خدماتی است که در زمان فراخوانی مورد استفاده قرار می گیرند

با توجه به نتایج رویکردهای پیشنهادی، آزمون تغییر (موتاسیون) برای سنجش کفایت مورد آزمون در خدمات وب مؤثر است. امتیاز موتاسیون، در تغییر WSDL Mei و Zheng به 95٪، در تغییر OWL-S متعلق به Wang و Huang به 98.7٪ و در تغییر OWL-S لی و همکاران به 99.4٪ رسید [16 , 17 , 18]. نتایج همچنین اثر بخشی آزمون تغییر در انتخاب سوییت آزمون را اثبات نموده است. رویکرد Mei و Zheng با کاهش 96٪ و 81.5٪ در موارد آزمون در حالی که پوشش تست حفظ شده باشد، همراه بود.
تست مبتنی بر خطای وب سرویس ، زمانی که سرویس گیرنده می خواهد خطاهای رایج مانند خطاهای رابط، خطاهای معنایی و خطاهای ناشی از پلت فرم وب سرویس را بررسی کند، می تواند یک روش تست بسیار موثری باشد.

7. تست مشترک (Collaborative)

تست مشترک نرم افزار، مفهومی است که در آن چندین گروه در یک وب سرویس، مانند توسعه دهنده، تستر و کاربر، در فرایند تست شرکت می کنند. تست مشترک معمولا در تکنیک های تست استفاده می شود. چالش هایی که شامل تست سیستم های سرویس گرا هستند توسط Canfora و Di Penta شناسایی شده است و برخی از این چالش ها نیازمند راه حل های مشارکتی است[1]. چالش هایی که ممکن است نیاز به راه حل های مشارکتی داشته باشند عبارتند از:

1. کاربرانی فاقد سوییت آزمون واقعی
2. کاربران فاقد رابط کاربری برای تست سیستم های وب سرویس
3. نیاز به تست شخص ثالث و تایید QoS به جای تست توسط هر کاربر سرویس

تست مشترک نرم افزار

رویکردهای تست مشترک پیشنهاد شده، برای حل برخی از چالش های درگیر در تست وب سرویس است. مزایای ادعا شده از این رویکردها، ضرورت تست مشترک در محیط های سرویس گرا را ثابت می کند.

8. تست رگرسیون وب سرویس

تست رگرسیون استفاده مجدد از موارد آزمون موجود از تست های قبلی سیستم است. تست رگرسیون زمانی انجام می شود که یک سیستم موجود اصلاح شود یا چیزی به آن اضافه شود. در تست رگرسیون سنتی فرض می شود که تستر به کد منبع دسترسی داشته و تست رگرسیون با روش سفارشی انجام می شود. انجام تست رگرسیون جعبه سفید، به طور عمده به مدیریت موارد آزمون کمک می کند.
تعدادی از روش های مدیریت موارد آزمون و روش های اولویت بندی مانند روش اجرای نمادین و رویکرد مبتنی بر برش پویا، دسترسی تسترها به کد منبع را نیاز دارند. با این حال، روشی مانند رویکرد GWA که نیازی به دسترسی به کد منبع ندارد، می تواند در تست رگرسیون وب سرویس (WSRT) استفاده شود[20]. دلیل مهم برای تشخیص روش های انتخاب رگرسیون (RTS) که نیاز به دسترسی به کد منبع دارند، مشخص کردن روش های RTS مناسب برای آزمایش وب سرویس است. از آنجایی که تست وب سرویس به عنوان یک تست جعبه سیاه محسوب می شود، روش های RTS که نیاز به دسترسی به کد منبع دارند، برای سرویس های وب غیرقابل استفاده هستند.

تست رگرسیون وب سرویس

یکی از مسائل اصلی در WSRT آن است که کاربر نمی داند چه زمانی تست رگرسیون را اجرا کند [1]. از آنجا که کاربر سرویس هیچ کنترلی بر تکامل وب سرویس ندارد، ممکن است از تغییرات در وب سرویس اطلاع نداشته باشد. دو سناریو ممکن برای اطلاع دادن به کاربر سرویس در مورد تغییرات وجود دارد. این سناریوها بر اساس دانش ارائه دهنده سرویس، در مورد کاربران سرویس است.
اولین سناریو زمانی رخ می دهد که سیستم تحت تست با یک کارگزار UDDI ثبت می شود. سرویس اشتراک در UDDI نسخه سه، آگاه شدن خودکار کاربران را هنگام تغییر یک سرویس، امکان پذیر می سازد. برای سرویس ارائه شده فرض می شود که ارائه دهنده سرویس جزئیات کاربران سرویس را از طریق روش های صورتحساب و یا موافقت نامه های سرویس به دست می آورد. در این سناریو اطلاع دادن به کاربران سرویس در مورد تغییرات وب سرویس مشکل نخواهد بود. با این حال، هنوز یک جای کوچک برای خطا وجود دارد. اگر کاربران سرویس به درستی در مورد تغییر روش های وب سرویس مطلع نشده باشند، ممکن است یک سری تست ها را انجام دهند؛ حتی اگر توابع مورد استفاده آنها تحت تاثیر قرار نگیرند یا به دلیل کمبود اطلاعات ، اجرای تست های ضروری با شکست روبه رو شود.
سناریوی دوم زمانی رخ می دهد که وب سرویس نیاز به تست رگرسیون دارد. یک وب سرویس عمومی بدون ثبت نام UDDI است و ارائه دهنده اطلاعاتی در مورد کاربران آن ندارد. این سناریو مشکل ساز است، زیرا کاربر سرویس تنها می تواند با مشاهده خطاها در رفتار سیستم یا تغییرات در عملکرد سیستم، از تغییرات آگاهی پیدا کند. در طول تغییرات یک سرویس و کاربر آن، ممکن است به دلیل خطاها یا کاهش کیفیت سرویس، کشف تغییرات، اعتماد به سرویس کاهش یابد.
چالش دیگری در WRST مسائل همروندی (concurrency) است که ممکن است در حین تست به وجود آید. زیرا تستر روی همه وب سرویس مشترک کنترل ندارد. مشکل مربوط به این مسئله محلی سازی خطا نامیده می شود. در طول فرایند تست رگرسیون، اگر یک تستر در مورد تغییراتی در وب سرویس،که توسط سیستم تحت تست فراخوانی می شود، اطلاع نداشته باشد، خطاهای ناشی از این سرویس را می توان به عنوان خطاهای سیستم تحت تست مشاهده کرد.
روش های پیشنهادی توسط محققان معمولا در روش گراف های جریان کنترل(CFG) متفاوت هستند. CFG یک زبان نمایشی است که از نماد گراف برای نشان دادن تمام مسیرهایی که ممکن است در طی اجرای برنامه نادیده گرفته شود استفاده می کند [21].

برخی مثال های ساده شده گراف جریان کنترل

9. تست تعاملات وب سرویس (Interoperability)

تعاملات، قابلیت مولفه های چندگانه برای همکاری با یکدیگر، یعنی برای تبادل اطلاعات و پردازش اطلاعات مبادله شده است. تعامل یک مسئله بسیار مهم در پلت فرم های باز مانند SOA است. با وجود اینکه وب سرویس باید با پروتکل های استاندارد و مشخصات سرویس مطابقت داشته باشند، مسائل ناسازگاری هنوز هم ممکن است بوجود آیند.
نیاز به قابلیت تعامل وهمکاری در میان مشخصات سرویس توسط صنعت و سازمان صنعتی WS-I ، که توسط شرکت های پیشرو فناوری اطلاعات تشکیل شده، به رسمیت شناخته شده است. این سازمان یک سند استاندارد WS-I را برای تطبیق قابلیت همکاری وب سرویس تعریف کرد[22]. سازمان WS-I سناریوهای همکاری را که باید مورد تست قرار گیرند، و تعدادی از ابزارهای کمک به فرآیند تست را ارائه می دهد.

تست تعاملات وب سرویس

محققان همچنین نیازمند تست قابلیت همکاری در میان سرویس ها هستند. به عنوان مثال، بارتولینو و پولینی چارچوبی را پیشنهاد می دهند که قابلیت همکاری سرویس را با استفاده از سرویس فایل WSDL همراه با پروتکل PSM ارائه می کند[23 ,24]. نمودار PSM اطلاعاتی را براساس دستور فراخوانی عملیات برای یک سرویس شامل می شود. چارچوب پیشنهادی، نظم اعلان وب سرویس را در بین وب سرویس های مختلف بررسی می کند و تلاش می کند تا مشکلات احتمالی قابلیت همکاری را مشخص کند.

10. تست یکپارچه سازی وب سرویس

تست یکپارچه سازی در مهندسی نرم افزار جهت بررسی اطمینان از کارکرد تمام اجزا به عنوان یک سیستم، اهمیت دارد. از آنجایی که ایده SOA داشتن سرویس های چند منظوره متصل و هماهنگ برای ایجاد یک سیستم نرم افزاری است، آزمون یکپارچه سازی در SOA ضروری می شود. با انجام تست یکپارچه سازی، تمام عناصر SOA از جمله سرویس ها، پیام ها، اینترفیس ها و فرآیندها را می توان تست کرد. تست یکپارچه سازی یکی از مهمترین تکنیک های تست در SOA است که عملکرد درست سیستم های سرویس گرا را تضمین می کند. تست یکپارچه سازی موثر نیاز به سناریوهای موثر دارد که تمامی قابلیت های SUT و تمامی سناریوهای ممکن اجرا را ضبط می کند.

11. نتیجه گیری

SOC درک کسب و کار از صنعت نرم افزار را تغییر داده است. با این حال، تغییر از نرم افزار سنتی به سرویس و استفاده از سرویس هنوز در میزان مورد انتظار نیست. یکی از مهمترین مسائلی که مانع استفاده گسترده تر از وب سرویس ها می شود، مسئله قابلیت اعتماد است. یکی از راه حل های موثر برای افزایش اعتماد، تست می باشد.
این نظرسنجی بر تکنیک های تست عملکردی و رویکردهایی که برای تست وب سرویس پیشنهاد شده، متمرکز شده است. تست وب سرویس چالش بیشتری نسبت به تست نرم افزارهای سنتی به دلیل پیچیدگی فن آوری وب سرویس و محدودیت های ناشی از محیط SOA دارا می باشد. پیچیدگی وب سرویس ها به دلیل استانداردهای آنها، نه تنها بر تست تاثیر می گذارد بلکه امکان انتقال وب سرویس را نیز کاهش می دهد.
مسائل دیگری در تست وب سرویسوجود دارد که در سیستم های سنتی نرم افزار وجود ندارد. از قبیل:

1. میزان مورد نیاز تست
2. تست بدون اختلال در عملکرد سرویس
3. تعیین زمانی که تست مورد نیاز بوده و اینکه کدام عملیات باید مورد آزمایش قرار گیرد

زمانی که وب سرویس ها توجه بیشتری از صنعت و جوامع تحقیقاتی را به خود جلب نمود، مسائل مربوط به تست وب سرویس شناسایی شدند. برخی از مسائل که قبلا شناسایی شده، مورد بحث قرار گرفته و برخی نیازمند توجه هستند. این بررسی تست واحد، تست رگرسیون، تست یکپارچه سازی و تست قابلیت همکاری از وب سرویس را شامل می شود. این تکنیک های تست، ابعاد کاربردی مهم وب سرویس ها را بررسی می کند. روش های تست مانند تست مبتنی بر مدل، تست مبتنی بر خطا، تایید رسمی، تست پارتیشن، تست مبتنی بر قرارداد و تولید مورد آزمون نیز مورد بررسی قرار می گیرند. بعضی از رویکردهای تست مورد بررسی که در آن اجزای مختلف یک وب سرویس در تست شرکت می کنند، تحت تست مشترک می باشند. سایر روش های تست موجود که هدف از آنها تست جنبه های غیر کارکردی وب سرویس ها مانند امنیت یا QoS است، در خارج از محدوده این بررسی قرار دارند.

شرکت مهندس پیشگان آزمون افزار یاس، خدمات زیر را در حوزه تست وب سرویس ارائه می دهد:

تست عملکردی وب سرویس

تست پرفورمنس (تست بار و فشار) وب سرویس

تست امنیت و نفوذ وب سرویس

برون سپاری تست نرم افزارهای وب سرویسی

ارائه مشاوره در حوزه تست وب سرویس

ارائه استاندارد، متدولوژی، ابزار و چک-لیست در حوزه تست وب سرویس

تهیه و آموزش ابزار SOATest برای تست عملکردی وب سرویس

تهیه و آموزش ابزار WPLT برای تست کارایی (تست بار و فشار) وب سرویس

تهیه و آموزش ابزار WebInspect و AppScan برای تست نفوذ وب سرویس

بررسی کیفیت و امنیت نرم افزارهای وب سرویسی از طریق ابزارهای تحلیل ایستا (مرور سورس کد) همچون Checkmarx