مقدمه :

معماریهاي سرویس گرا بطور سریع چشم اندازي از امـروز و فـرداي مهندسـ ی نـرم افـزار را تغییـ ر مـ ی دهـد ، 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هزار تومان