مقدمه :

معماریهای سرویس گرا بطور سریع چشم اندازی از امـروز و فـردای مهندسـ ی نـرم افـزار را تغییـ ر مـ ی دهـد ، SOA اجازه انعطاف پذیری و پویایی بالای سیستم ها را در طول کشف و ترکیب سرویس، انقیاد فوق العاده دیر ، مذاکرات خودکار و مدیریت توافق سطح سرویس (SLA)و دوباره پیکربندی اتوماتیک سیستم را می دهد.
SOA اساسا در حال تغییر ابعاد توسعه ، بالا بردن جدایی مالکیت نرم افزار(نرم افـزار بـه عنـوان محصـول ) از کاربری اش( نرم افزار به عنوان سرویس) می باشد.
پذیرش فزاینده ای از SOAبرای ماموریت سیستم های بحرانی، روشهای موثری را برای تضمین قابلیت اعتماد بالا ایجاب می کند . استراتژیهای متفاوت می توانند مورد پیگیری برای افزایش اطمینان در SOAباشند : یـ ک امکان این است که تحمل خطا را بوسیله تکرار محقق نمایند ، برای مثال یکی ازپیشنهادات این اسـت کـه هـر سرویس که بوسیله یک سیستم احضار شده است می تواند بواسطه ظرفی که سرویسـها ی هـم ارز را احضـار می کند و همانند یک رای دهنده عمل کند جابجا شود .
امکان دیگر این است که یک سرویس میانی رابطور پیوسته در طول اجرایش ما نیتور نمـائ یم و عملکردهـا ی صحیحی را در صورت نیاز بکار ببریم . هنگامیکه یک رخداد استثناء تشخیص داده می شود یک عملکرد بازی ـابی راه اندازی می شود . برای مثال اگر یک سرویس درجه حرارت که قسمتی از سیستم پیش بینی هـوا اسـت در دسترس نباشد یک سرویس دیگری مشخص و احضار شده است.
در حالیکه ما نیتورینگ یک ابزار موثر برای ساخت خود سازنده و خود تعمیر کننده سیستم های سرویس میانی می باشد ، اما این نیاز دارد که واکنشهای بازیابی کافی برای همه رخدادهای ممکن استثناء پیاده سـاز ی شـده باشند ، بنابراین تست یک فرایند کلیدی را برای کاهش می نیمم تعداد از این قبیل رخدادهای اسـتثناء را بـاق ی می گذارد.
بسیاری روشهای تست یکپارچه که سالها برای سیستم های سنتی بکار گرفته شده است به همان انـدازه بـرا ی سیستم های سرویس میانی بکار گفته شده است . اصولا ایده ای که از ترکیب آزمون واحد ، جامعیت و رگرسیون برای بدست آوردن اطمینان نیاز شده است برای این است که سیستم کارکرد مورد انتظار را تحویل خواهد داد.با این حال طبیعت پویا و وفق پذیر SOAتکنیکهای تست موجود را بطور مستقیم قابل اجرا برای تست سرویسها و سیستم های سرویس میانی نمی سازد.به عنوان مثال دراغلب روشهای تست قدیمی فـرض بـر ایـ ن اسـت کـه همیشه توانایی شناسایی قسمت واقعی کد که در سایت صدا زننده احضار شده است وجود دارد یا همانند مواردی در زبانهای برنامه نویسی شی– میانی که همه انقیا د های ممکن از مولفه چند ریختی شناخته شده اند، اما ایـ ن فرضیات هیچگاه در مورد SOA صحیح نیست. نمونه هایی از ویژگیهای خاص SOA که پیچیدگی را به مسئولیت تست اضافه می کند. [1]شامل:
– سیستم های مبتنی بر سرویس فی نفسه توزیع شده اند و این نیاز دارد که QoS برای مستقر کـردن پیکربندیهای مختلف تضمین شده باشد.
– سرویسها در یک سیستم بطور مستقل از یکدیگر تغییر می کنند و این مسـاله باعـث تـاث یر روی تسـت رگرسیون می شود.
– سیستم ها رفتارهای وفقی را یا بوسیله جایگزینی سرویسهای فردی یا با اضافه کردن یک سرویس جدید پیاده سازی می کنند که بنابراین تست جامعیت مجبو ر به اقدام تغییر پیکربندی می باشد.
– مالکیت روی قسمتهای سیستم در بین افراد مختلف به اشتراک گذاشته شده است ، بنابراین برای تست سیستم نیازمند همکاری این افراد هستیم.
وفق پذیری SOA و بعلاوه تغییر معماری سیستم باعث تغییر فرآیند ساختار سیستم و استفاده آن می شود که این باعث اثر زیاد روی آزمون می شود . سرویسهایی که استفاده شده اند( نـه سـرو یس هـا یی کـه خـودمالک آنها است) بطور فیزیکی درون سیستمی که آنها را استفاده می کننـد و در یـ ک زی ـر سـاختار فـراهم کننده سرویس اجرا می شوند ، مجتمع نشده اند . که این مفاهیم متعددی برای تست دارا می باشد:
کد قابلیت دسترس پذیری برای مجتمع کننده سیستم ندارد، استراتژی تکـامل ی یـ ک سـرو یس(یعنـ ی نـرم افزاری که پشت سرویس قرار می گیرد ) تحت کنترل سیستم مالک نیست و مدیران سیسـتم نمـ ی تواننـد ازتوانایی طراحی برای جلوگیری از شکست SLA استفاده کنند . که ما در این گزارش به بررسی سطوح مختلف تست و چالشهای آن و سپس بـ ه معیارهـ ای ارزی ـابی قابلیـتتست پذیری برای نرم افزار SOA پرداخته و نقش تکمیلی مانیتورینگ را در کنار تست بیان می نماییم.

برای دانلود رایگان قسمت های بیشتراز فایل به انتهای مطلب مراجعه کنید

فهرست مطالب

چکیده………………………………………………………………………………………………………………………….1 مقدمه…………………………………………………………………………………………………………………………..2

فصل اول : کلیات

هنگامیکه یک تکنولوژی جدید به ظهور می رسد، در نتیجه فرآیندها / روشهای مهندسی نرم افزار برای این قبیل تکنولوژی مجبور به توسعه است ، یک سوال عمومی که وجود دارد این است کـه آیـ ا امکـان اسـتفاده مجدد/ وفق دادن روشهای موجودکه سابقا برای انواع دیگر سیستمها توسعه یافته بود مـ ی باشـد در واقـع سوالی که در اینجا مطرح است این است که آیا روشـها ی تسـت و تکنیکهـا ی توسـعه بـرا ی سیسـتم هـا ی
یکپارچه قدیمی ، سیستم های توزیع شده ، سیستم های مبتنی بر مولفه و برنامه های کابردی وب می تواند
برای تست سیستم های میانی مورد وفق یا استفاده مجدد قرار گیرد. برای پاسخگویی به این سوال نیازمنـ د تحلیل ویزگیهایی که سیستم سرویس میانی را متفاوت از بقیه سیستم ها می سازد تا آنجاییکـ ه بـه فراینـد تست مربوط است، می باشد.
موضوعات کلیدی که قابلیت تست پذیری سیستم های سرویس میانی را محدود می کند [2]شامل:
– کمبود مشاهده پذیری ساختارو کد سرویس:
برای کاربران و مجتمع کنندگان سیستم ، سرویسها تنها واسط هستند و این از روشهای تسـت جعبـه
سفید که نیاز به دانش ساختار و جریان داده دارد جلوگیری می کند.هنگامیکه دانش بیشتری برای هدف تست مورد نیاز شده است یعنی توصیف وابستگیها بین عملکردهای سرویس یا یک مدل رفتاری کامل از سرویس نیاز باشد یا فراهم کننده سرویس این قبیل اطلاعات را باید فراهم کند یا تست کننده مجبور به استنباط این بوسیله مشاهده سرویس از بیرون باشد.
– پویایی و انطباق :
برای سیستم های قدیمی کسی هست که همیشه توانایی معین کردن مولفه احضار شده در سایت صدا کننده مشخص را داشته باشد.اما این موضوع برای SOA صحیح نیست در جایی که یـ ک سیسـتم مـ ی
تواند بوسیله جریان کاری سرویسهای انتزاعی که بطور اتوماتیک محدود به سرویسهای عینی بازیابی شده از یک یا بیشتر رجیستری در طول اجرای نمونه جریان کاری هستند، توصیف شده باشد.
– کمبود کنترل :
هنگامی مولفه ها /کتابخانه ها بطور فیزیکی در یک سیستم نرم افزاری مجتمع می شوند (که همچنـ ین مطلبی برای سرویسها نیست ) که روی زیرساختارهای مستقل اجرا شوند و تحت کنترل انحصاری فراهم کننده استنتاج شوند . ترکیب این دو ویژگی به این مطلب دلالت دارد که مجتمع کنندگان سیستم نمـ ی توانندتصمیم استراتژی برای مهاجرت به یک ورژن جدیدی از سرویس و بالنتیجه برای تسـت رگرسـ یون سیستم بگیرند .
– کمبود اطمینان:
یک سرویس ممکن بواسطه توصیفاتی از ویژگیهایش (برای نمونه یک مدل رفتـار ی )اطلاعـات ی دربـاره
سطوح تضمین شده QoS فراهم نماید. این قبیل اطلاعات( در تئوری)می تواند بوسیله مجتمع کنندگان
برای کشف سرویس، برای مقایسه ویژگیهایش وبرای انتخابش مورد استفاده قرار می گیرد.با این وجود این امکان ندارد که گارانتی کنیم که هر قسمت از اطلاعات یک فراهم کننده سـرو یس بـا حقیقـت مطابقـت داشته باشد . بطور کلی یک فراهم کننده سرویس ممکن حقیقت را نگوید و توصیف غیر صـح یح از یـ ک رفتار کارکردی و غیر کاردی سرویس فراهم نماید.بنابراین تصمیمات موثر مجتمع کنندگان ممکـن روی استفاده سرویس گرفته شود.
– هزینه تست : احضار سرویس های واقعی بواسطه ماشین فراهم کننده روی هزینـ ه تسـت مـوثر اسـت همچنین اگر سرویسها در هر بار استفاده شارژ شده باشند. بعلاوه فراهم کنندگان سـرو یس مـ ی تواننـد پدیده های انکار سرویس در مواردی از تست کلان تجربه کنند و احضـار سـرو یس را بـرا ی تسـت ی کـه ممکن نیست قابل اجرا باشد را تکرار کند، در واقع هنگامیکه سرویس اثرات جانبی تولید کنـد هماننـد مورد سرویس ثبت هتل[2]

1-1) هدف…………………………………………………………………………………………………………………………6
1-2) پیشینه تحقیق……………………………………………………………………………………………………………..8
1-3) روش کار و تحقیق………………………………………………………………………………………………………….8

فصل دوم: معماری سازمانی

معماری سرویس گرا در واقع دستآوردی است جهت ساخت سیستمهای توزیع شده به نحوی کـه کارکردهـایبرنامه ها را در قالب سرویس به کاربر نهایی یا سرویس های دیگر ارائه کند.
معماری سرویس گرا وابسته به نقش شخص و محتوی معانی متفـاوت ی دارد .از دی ـد کسـب و کـار SOA : یـ ک مجموعه سرویسهای ترکیب شده برای گرفتن طراحی کسب و کار را تعریف می کند که سازمانها مـ ی خواهنـد ازدرون نمایش دهند. از دیدگاه معماری SOA: یک سبک معماری که سرویس گرایی را پشتیبانی می کند . در
سطح پیاده سازی ، SOA استفاده از زیر ساختار مبتنی بر استاندارد ها ، مدل برنامه نویسی و تکنولوژی همانند سرویس های وب را بوقوع می رساند.از دیدگاه عملیاتی SOA : شامل یک مجموعه از توافقات بین فراهم کننده سرویس و مصرف کننده سرویس که کیفیت سرویس را به همان خوبی گزارش گیـ ری روی شاخصـها ی کلیـ دی کسب و کار و IT را مشخص می کنند . معماری سرویس گراء در واقع پلی را بین مدل های کسب و کار و معماری های IT ایجاد می کند و به عنوان مبنایی برای سرعت بخشیدن کسب وکار مطرح می شود . معماری سرویس گراء محیطی را فـراهم مـی کنـد تـاسازمان انعطاف لازم جهت پاسخگویی به نیاز های جدید بازار را داشته باشند . و سرویس گرایی یک متدی از یکپارچگی فرایند ها و برنامه های کسب و کار که مانند سرویس های متصل شده را تعریف می کنند. و برنامه کاربردی مرکب یک مجموعه از سرویسهای یکپارچـه و وابسـته اسـت کـه فراینـد کسب وکار ساخته شده روی SOA را پشتیبانی می کند.
2-1) اجزاء یک معماری سرویس گرا[4]:
معماریهای سرویس گرا بر مبنی 4 مفهوم اساسی بوجود آمده اند:
1- نرم افزار کاربردی نهایی 2- سرویس 3- مخزن سرویس 4- گذرگاه سرویس در حقیقت سرویس ها کارکردهای را فراهم می کنند که برنامه های کاربردی و سرویس های دیگر مـیتواننـد ازآنها استفاده کنند. و سرویس ها شامل منطق کاری ،داده ها و قراردادهای هستند که کارکرد،نحوه به کارگیری و محدودیت های آن سرویس را توصیف می کند . واسط یک سرویس نحوۀ کارکرد آن سـرویس را بیـان مـی کنـد . مخزن سرویس ها قراردادهای هر سرویس را ذخیره می کند و درگاه سـرویس هـا برنامـههـای کـاربردی نهـایی وسرویس ها را به یکدیگر اتصال می دهد[3].
1- بخش نهایی برنامه کاربردی:
بخش نهایی برنامۀ کاربردی در واقع نقش اساسی را معماریهای سرویس گرا بازی می کند .و کلیۀ فعالیت های سازمان را راه اندازی و کنترل می کنند .بخش نهایی یک برنامۀ کاربردی می تواند به صورت واسـط گرافیکـی کـاربرباشد مانند برنامه های کاربردی وب و یا به صورت برنامه هایی که مستقیماً با کاربر در ارتباط هستند و یـا ممکـناست ارتباط با کاربر به صورت مستقیم نباشد مانند پردازش هایی که یک کار خاص را در اثر یک رخداد مشـخص،یا در دوره های زمانی مشخص انجام می دهند. بخش نهایی یک برنامۀ کاربردی جهت پیاده سازی وظایف خـود از سرویس ها استفاده می کند .

2 -1)اجزاء یک معماری سرویس گرا…………………………………………………………………………………………….11
2-2)پشته معماری سرویس گرا…………………………………………………………………………………………………61
2-3)مفاهیمSOA………………….ا……………………………………………………………………………………………….71
2 -4)موجودیتهایSOA ……ا……………………………………………………………………………………………………….81
2-5)سرویسهایوب……………………………………………………………………………………………………………………12
2 -7)متدولوژی تست SOA…………………….ا………………………………………………………………………………….52
2-7-1)روشتست سنتی ………………………………………………………………………………………………………….52
2 -7-1-1)روش تست تجدید نظرشده برای SOA…….ا………………………………………………………………………..62
2-7-2)شیوهتستSOA…………………………………….ا……………………………………………………………………….72
2-7-2-1)هدف………………………………………………………………………………………………………………………..72
2-7-2-2)چه طور معماری SOA را تست نماییم؟………………………………………………………………………………….82
2-8)تولیداتتجاری…………………………………………………………………………………………………………………….92

فصل3:دیدگاههاوتس سطوح مختلف معماری سرویس گرا…

SOA نیازها و چالشهای متفاوتی را برای افراد مختلفی که در فعالیتهای تست درگیر هسـتند را بی ـان مـ ی کندکه این افراد شامل :توسعه دهندگان، فراهم کنندگان، مجتمع کنندگان، تصدیق کنندگان( شخص ثالث )وکاربر نهایی است . جدول 3-1 خلاصه ای از موافق و مخالف تجربه افراد در سطوح مختلف تست را فراهم می کند[1].
توسعه دهنده سرویس :
توسعه دهنده سرویس، سرویس را برای تشخیص ماکزیمم تعداد خطای ممکـن تسـت مـ ی کنـد . توسـعه دهنده سرویس مالک پیاده سازی سرویس است، بنابراین آن شخص قادر به اجرای تست جعبه سفید مـ ی
باشد . در بین موارد دیگر ، توسعه دهنده سعی بر ارزیابی ویژگیهای غیر کارکردی سرویس و توانایی اش را برای مدیریت صحیح استثناء ها دارد .گرچه هزینه های تست در این مورد محدود شده است( البته توسـعه دهنده مجبور به پرداخت هزینه هنگامیکه سـرو یس خـودش را تسـت مـ ی کنـد نمـ ی باشـد ) کـه تسـت غیرکارکردی واقعی نیست به این دلیل که این موضوع برای زی ـر سـاختارفراهم کننـده و مصـرف کننـده و پیکربندی و بار شبکه به حساب نمی آید . بطور کلی نمونه های تست طراحی شده بوسـ یله توسـعه دهنـده ممکن نیست یک سناریوی کاربردی واقعی را منعکس کند.
فراهم کننده سرویس :
فراهم کننده سرویس ، سرویس را برای گارانتی تضمین قرارداد نیازمندیهایی که در SLA با مصرف کننده بسته شده است را تست می کند .هزینه های تست محدود شده هستند.با این وجود فـراهم کننـده ممکـن نیست تکنیک جعبه سفید را هنگامیکه آن شخص /سازمان متفاوت ازآن کسی باشد که سـرو یس را توسـعه داده است ، بکار ببرد. بنابراین تست غیر کارکردی زیر ساختار مصرف کننده و پیکر بندی یا بارگذاری شبکه را منعکس نمی کند و همچنین نمونه های تست سناریوی کاربردی واقعی سرویس را نیز منعکس نمی کند. جدول3-1: دیدگاه اشخاص مختلف ، نقشها و مسئولیتها به فرم خوابیده ،منفعت ها به صورت (+) ومشکلات به صورت(-)نشان داده شده است .

8

3-1)دیدگاههایتست…………………………………………………………………………………………………………………..33
3-2)سطوحتست……………………………………………………………………………………………………………………..63
3-2-1)تستواحد………………………………………………………………………………………………………………………63
3-2-1-1) تست واحد ترکیبات سرویس……………………………………………………………………………………………93
3-2-2)تستجامعیت…………………………………………………………………………………………………………………..14
3-2-3)تسترگرسیون ……………………………………………………………………………………………………………………24
3-2-4) تست غیر کارکردی……………………………………………………………………………………………………………..47
3-2-4-1) تست نیرومندی……………………………………………………………………………………………………………….47
3-2-4-3) تست برای قابلیت اعتماد……………………………………………………………………………………………………94
3-2-4-4)تستامنیت………………………………………………………………………………………………………………………35
3-4) چالشها در SOA ………………….ا………………………………………………………………………………………………75
3-4-1)تستواحد……………………………………………………………………………………………………………………………85
3-4-1-1)چالشها…………………………………………………………………………………………………………………………..85
3-4-1-1)راهحل……………………………………………………………………………………………………………………………85
3-4-2)تستجامعیت ………………………………………………………………………………………………………………………95
3-4-2-1)چالشها………………………………………………………………………………………………………………………….06
3-4-2-2)راهحل……………………………………………………………………………………………………………………………06
3-4-3)تست سیستم کارکردی…………………………………………………………………………………………………………62
3-4-3-1)چالشها………………………………………………………………………………………………………………………..62
3-4-3-2)راهحل…………………………………………………………………………………………………………………………..36
3-4-4) تست سیستم غیرکارکردی…………………………………………………………………………………………………….64
3-4-4-1)چالشها…………………………………………………………………………………………………………………………..46
3-4-4-2)راهحل…………………………………………………………………………………………………………………………….56
3-5) نقش تست و دیده بانی در معتبرسازی سیستم SOA…..ا……………………………………………………………………..66
3-5-1)نقش تست و دیده بانی……………………………………………………………………………………………………………86
3-5-1-1)بررسی ویژ گیهای کارکردی سرویس………………………………………………………………………………………….68
3-5-1-1-1)نقشتست……………………………………………………………………………………………………………………..86
3-5-1-1-2) نقش دیده بانی………………………………………………………………………………………………………………96
3-5-1-2) بررسی QoS سرویس………………………………………………………………………………………………………….96
3-5-1-2-1)نقشتست………………………………………………………………………………………………………………………96
3-5-1-2-2) نقش دیده بانی……………………………………………………………………………………………………………..07
3-5-1-3-1)نقشتست…………………………………………………………………………………………………………………….17
3-5-1-3-2)نقش دیده بانی……………………………………………………………………………………………………………….17
3-5-1-4) بررسی تکاملی سرویس………………………………………………………………………………………………………27
3-5-1-4-1)نقشتست ……………………………………………………………………………………………………………………..27
3-5-1-4-2)نقش دیده بانی……………………………………………………………………………………………………………….72
3-5-2) ترکیب تست و دیده بانی………………………………………………………………………………………………………..27

فصل 4 : قابلیت تست پذیری نرم افزار در معماری سرویس گرا47.

همانطور که می دانیم معماری سرویس گرا معماری است که در آن مجمو عه ای از سرویس های ارتباط ضـع یف و مستقل به وسیله ی رابطهای استاندارد و پروتکل های مبادله ی پیام با هم در ارتباط هستند.SOA بـه عنـوانیک تکنولوژی ادغام شده در توسعه ی نرم افزار، نمونه ی جدیدی است که بر همـه ی چرخـه ی توسـعه ی نـرمافزار از جمله آنالیز،تعیین مشخصات، طراحی، پیاده سازی، اعتبارسنجی، نگهداری و تکامل تاثیرگذار اسـ ت. کـهدر این فصل به معیارهای ارزیابی قابلیت تست پذیری برای نرم افزار SOA می پردازیم .
از نظر تکنیکی یک سرویس یک رابط بین تولیدکننده و مشتری است .
از دیدگاه تولیدکننده ، سرویس یک واحد خوش تعریف و خود محتواست که به مفهوم،موقعیت و تـابع دیگـر ی وابسته نیست. و سرویس غالبا به عنوان یک عامل در نظر گرفته می شود، که می تواند به عنوان یک سـرو یس جدید ساخته شود یا همان سرویس قبلی اما با رابط های جدید باقی بماند .
از دیدگاه سازنده ،سرویس بخشی از کار انجام شده توسط تهیه کننده برای رسیدن به خواسـته هـای مشـتر ی است. یک سرویس به طور نرمال توسط یک رابط کاربردی با سرویس های دیگر در ارتباط است .
سرویس ها از یکدیگر مستقل هستند و می توانند در کامپیوترهـ ای متفـاوت مسـتقر شـوند و از سـرویس هـ ا ی یکدیگر برای رسیدن به هدف و نتیجه ی نهایی استفاده کنند. یک سرویس جدید می تواند در زمان اجرا مبتنـ ی بر یک سرویس محلی یا راه دور که در دسترس می باشد ساخته شود. کارگزارهای سرویس که سـرو یس هـا ی راه دور را برای دسترس عمومی منتشر می کنند وظیفه یافتن و اکتشاف سرویس ها بر عهده دارنـد . سرویسـه ای وب یک معماری سرویس گرا را بر اساس وب، به وسیله ی پروتکل هـا ی XML,WSDL,UDDI,SOAPپی ـاده سازی می کنند. اخیرا ebXML مجموعه ای از پروتکلهـا ی همکـار ی پویـ ا DCP مثـل CPP و CPA را معرفی کرده است .
مفهوم DCP آن است که سرویس ها همکاریشان را در زمان اجرا تعیین خواهند کرد .در گذشته، غالبا همکـار ی سرویس ها به وسیله ی جریان کار مشخص می شود. همچنین DCP بعد دیگری از پویـ ایی را در SOA معرفـ ی کرد. این پویایی جدید هم چالش هایی جدیدی را در اعتبـار و صـحت سـنج ی V&V برنامـه هـای کـاربر دی
SOA معرفی کرد .
در ابتدا نگاهی به سیر تکاملی چالش های صحت سنجی می اندازیم[15]:

4-1)قابلیتتست پذیری…………………………………………………………………………………………………………………….77
4-2) درک قابلیت تست پذیری سرویس………………………………………………………………………………………………..87
4-2-1)قابلیت تست پذیری سرویس اتمیک ……………………………………………………………………………………………08
4-2-2) قابلیت تست پذیری اصل داده…………………………………………………………………………………………………..81
4-2-3) قابلیت تست پذیری یکپارچه سازی سرویس …………………………………………………………………………………28
4-2-4) قابلیت تست پذیری همکاری سرویس ………………………………………………………………………………………..48

فصلپنجم:نتیجهگیر و پیشنهادات

نتیجهگیری……………………………………………………………………………………………………………………………….68
پیشنهادات………………………………………………………………………………………………………………………………78

منابعوماخذ………………………………………………………………………………………………………………………………90
فهرستمنابعلاتین………………………………………………………………………………………………………………………..09 سایتهایاطلاعرسانی…………………………………………………………………………………………………………………….19 چکیدهانگلیسی………………………………………………………………………………………………………………………..29

برای دانلود رایگان قسمت های بیشتراز فایل به انتهای مطلب مراجعه کنید

فهرست جداول

3-1:دیدگاه اشخاص مختلف………………………………………………………………………………………………………….43
3 -2:خلاصه روشهای تست رگرسیون………………………………………………………………………………………………45

فهرست شکل ها

2-1:ساختاریکسرویس…………………………………………………………………………………………………………………31
2-2:گذرگاهسرویس……………………………………………………………………………………………………………………51
2-3:پشتهمعمار سرویس گرا…………………………………………………………………………………………………………..61
2-4:فرایند ثبت ، جستجو و اتصال سرویس…………………………………………………………………………………………..81
2-5:فرایند فراخوانی سرویس توسط سرویس پراکسی……………………………………………………………………………02
2-6:V-مدل………………………………………………………………………………………………………………………………..24.
2-7:مولفههایSOA………ا……………………………………………………………………………………………………………92
3-2:مشخصات faceted یک سرویس………………………………………………………………………………………………..44
3-3:تسترگرسیونسرویس………………………………………………………………………………………………………………..64
3-4:تست SLAیک سرویس مرکب……………………………………………………………………………………………………….84
3-5:گذرگاه سرویس سازمانی تست توانا شده……………………………………………………………………………………….26
3-6:نقشتستودیده بانی…………………………………………………………………………………………………………………..17
4-1:ارائه عوامل قابلیت تست پذیری سرویس…………………………………………………………………………………………08

 

ABSTRAC:
Testing of Service Oriented Architectures (SOA) plays a critical role in ensuring a successful deployment in any enterprise. SOA testing must span several levels, from individual services to inter-enterprise federations of systems, and must cover functional and non-functional aspects.
SOA unique combination of features, such as run-time discovery of services, ultra-late binding, QoS aware composition, and SLA automated negotiation, challenge many existing testing techniques. As an example, run-time discovery and ultra-late binding entail that the actual configuration of a system is known only during the execution, and this makes many existing integration testing techniques inadequate. Similarly, QoS aware composition and SLA automated negotiation means that a service may deliver with different performances in different contexts, thus making most existing performance testing techniques to fail.
Whilst SOA testing is a recent area of investigation, the literature presents a number of approaches and techniques that either extend traditional testing or develop novel ideas with the aim of addressing the specific problems of testing servicecentric systems. This reports a survey of recent research achievements
related to SOA testing. Challenges are analyzed from the viewpoints of different stakeholders and solutions are presented for different levels of testing, including unit, integration, and regression testing and also covers both functional and non-functional testing. Then check testability of application in SOA , and present the role of the testing and of the monitoring in validation of SOA.



مقطع : کارشناسی ارشد

قیمت 25 هزار تومان

خرید فایل pdf به همراه فایلword

قیمت:35هزار تومان