چکیده
اشتیاق زیادی نسبت به وب سرویسها در جهان امروز وجود دارد. وب سرویسها از اینترنت برای ارتباط بین دو دستگاه الکترونیکی متصل از طریق شبکه استفاده میکنند. آزمون وب سرویس چالشی است که یک درخواستکنندهی سرویس کد منبع را ندارد و بهنوعی نیاز به تست کامل تاثیر تغییرات در نرم افزار دارد. تست رگرسیون یکپارچگی نرم افزار را تایید میکند و اطمینان حاصل میکند که تغییرات خطا های نرم افزار جدید معرفی شده است. روش ما شامل تجزیه فایل WSDL XML برای استخراج اطلاعات مربوط به نام عملیات، پیامهای ورودی و پیام های خروجی است. هر دو فایل اصلی و تغییریافتهی XML برای وب سرویس برای استخراج اطلاعات مربوطه ی خود از نوع پورت و عنصر پیام WSDL تجزیه شده است. پس از آن، یک جدول هش از اطلاعات استخراج شده برای هر دو WSDL اصلی و دلتا ایجاد شده است. جداول هش به یک مقایسهکننده به عنوان ورودی وارد میشود، پس از آن جداول هش مقایسه شده و تغییرات عملیات را به صورت خروجی تولید میکند. در مرحلهی آخر آزمون موارد برای تست رگرسیون از وب سرویسهای تغییر یافته انتخاب خدمات بر اساس تغییرات در عملیات ارائه شده توسط مقایسه کننده انتخاب میشود.
مقدمه
اشتیاق زیادی برای وب سرویس ها در جهان امروز وجود دارد. وب سرویسها از اینترنت برای ارتباط بین دو دستگاه الکترونیکی متصل از طریق شبکه استفاده میکنند. وب سرویس در اصل یک سیستم نرم افزاری است که عملکرد سازگاری برای حمایت از تعامل ماشین به ماشین برای انتقال داده ها در یک شبکه از خود نشان میدهد [1]. آنها برنامه های کاربردی استاندارد وب هستند که مشخصات آنها در دایرکتوری UDDI که با دیگر برنامه های کاربردی وب به منظور تبادل اطلاعات ارتباط برقرار میکنند انتشار شده است. وب سرویس ها از پنج استاندارد اصلی برای برقراری ارتباط در طول شبکه استفاده میکنند: زبان توصیف وب سرویس ها (WSDL) ]3[، زبان توسعه یافتهی (XML)، پروتکل انتقال متن (HTTP)، پروتکل ساده دسترسی به شی (SOAP) ]2[ و توضیحات جهانی، کشف و یکپارچه سازی (UDDI).
وب سرویسها دارای یک درخواستکنندهی سرویس و ارائهدهندهی خدمات است. نرم افزاری که داده درخواست میکند درخواستکنندهی سرویس نامیده میشود و نرم افزاری که درخواست درخواستکننده را پردازش میکند و داده را ارائه میکند ارائه دهندهی خدمات نامیده میشود. کد منبع برای وب سرویس با ارائه دهندهی خدمات است. درخواستکنندهی سرویس تنها WSDLدارد. بنابراین، هر زمان که یک تغییر در وب سرویس رخ میدهد، تست مجدد وب سرویس مورد نیاز است. تست یک چالش برای درخواستکنندهی سرویس است همانطور که کد منبع را ندارد و نیاز به تست کامل تاثیر تغییرات در درخواست خود را دارد. وب سرویسها رابط گرافیکی کاربر ندارد. در عوض، آنها از یک رابط برنامه ریزی برای تبادل پیام استفاده میکنند[7].
وب سرویسها در طول زمان مانند هر نرم افزار دیگری تکامل مییابند. به همین ترتیب، ما نیاز به انجام آزمون رگرسیون هنگام تغییر در وب سرویس داریم. تست رگرسیون انجام شده است تا اطمینان حاصل شود که نسخهی تغییر یافتهی وب سرویس در حال کار کردن است و تمام عملیات به درستی انجام میشود. آزمون رگرسیون یکپارچگی نرم افزار را تایید میکند و اطمینان حاصل میکند که تغییرات، خطاهای جدیدی در نرم افزار بهوجود نیاورده است [6]. آزمون رگرسیون وب سرویس چالش بیشتری از فراهم آوردن حداکثر آزمون پوشش برای ادغام با نرم افزار برای تضمین حداقل تعداد موارد آزمون با کمترین هزینه ارزیابی و خطر است.
[4] ها و پارک یک روش پیشنهادی از هستی شناختی دارند، به طوریکه آنها کیفیت سرویس در سطح کاربر را بهکار میبرند(QoS) که دو سطح مختلف برای وب سرویس با کیفیت مناسب را ارائه میدهند. تا به امروز تلاش زیادی برای تحقیق در تست وب سرویس [7] برای یکپارچه سازی با برنامههای کاربردی دیگر انجام شده است. آزمون رگرسیون وب سرویس منطقهای است که نیاز به تحقیق و بهبود بهرهوری و زمان تست دارد. بسیاری از روشهای موجود برای آزمون رگرسیون از خدمات وب سرویس بر اساس تست های براساس کد است. آنها محدودیتهای خود را بهعنوان درخواستکنندهی سرویس جهت آزمایش کد منبع برای وب سرویس دارند. یک رویکرد مبتنی بر مشخصات برای تست وب سرویسها توسط مسعود و نادم پیشنهاد شده است[8]. ما رویکرد آنها را گسترش داده و برخی از تغییرات را در XML به منظور کاهش انتخاب مورد آزمون رگرسیون وب سرویسها پیشنهاد دادهایم.
رویکرد مبتنی بر مشخصات با بهرهگیری از WSDL برای وب سرویس برای انتخاب موارد آزمون جهت تست مجدد وب سرویس اجرا میشود. WSDL یک زبان تعریف رابط مبتنی بر XML است. که عملکرد و عملیات ارائه شده توسط یک وب سرویس را توصیف میکند. WSDL شامل تمام جزئیات در مورد عملیاتی است که میتواند توسط وب سرویس انجام شود- نام عملیات، نوع پورت، انواع پیام، پیام ورودی، پیام خروجی و صحافی. نوع پورت شامل اطلاعات مربوط به نام عملیات موجود در وب سرویس و پیامهای مرتبط با آن است. پیامها شامل عناصر دادهها از عملیات مانند نام پارامتر و انواع آنها و نوع خروجی عملیات است.
رویکرد ما شامل تجزیه فایل WSDL XML برای استخراج اطلاعات مربوط به نام عملیات، ورودی پیام و خروجی است. هر دو فایل XML اصلی و تغییر یافته برای وب سرویس برای استخراج اطلاعات مربوطه از نوع پورت و پیام عنصر از WSDL تجزیه میشود. پس از آن، یک جدول هش از اطلاعات استخراج شده برای هر دو WSDL اصلی و دلتا تولید میکنیم. جداول هش را به یک مقایسهکننده به عنوان ورودی وارد میکنیم، که پس از آن جداول هش مقایسه شده و تغییرات عملیات به عنوان خروجی تولید میشود. در آخرین مرحله موارد آزمون رگرسیون برای تست وب سرویس تغییر یافته بر اساس تغییرات در عملیات ارائه شده توسط مقایسهکننده انتخاب میشود.
موارد آزمون با عملیات در وب سرویس بهطور مستقیم رابطه برقرار میکند. مجموعه تست ما موارد آزمون همراه با نام عملیات را حفظ میکند. انتخابگر آزمون رگرسیون تنها کسانی که مورد آزمون هستند انتخاب میکند که در آن یک تغییر در نام عملیات و یا ارزشهای مرتبط و یا یک عملیات جدید اضافه شده وجود دارد. موارد آزمون دیگر که در آن هیچ تغییری در سیستم وجود ندارد همچنین ممکن است برای آزمون رگرسیون انتخاب شود. این کار بهمنظور حصول اطمینان از رفتار نرمافزار همانند قبل است. تمام قطعات سیستم در رگرسیون تحت پوشش تست تضمین ایمنی هستند [10]. آزمون ایمنی رگرسیون تمام موارد آزمون برای سیستم را به منظور درستی آزمون پوشش میدهد.
بقیه مقاله برای توصیف رویکرد پیشنهادی به جزئیات نوشته شده است. سازماندهی مقاله به شرح زیر است: بخش دوم به کارهای گذشته اختصاص داده شده است و بخش سوم به تشریح جزئیات روش پیشنهادی میپردازد. بخش چهارم یک نتیجهگیری برای مقاله است و بخش پنجم شامل دیدگاههای آتی برای تحقیق و بحث است.
Abstract
there is much enthusiasm around web services in today’s world. Web Services take the advantage of internet to communicate between two electronic devices connected via a network. Testing a Web Service is a challenge as the Service Requester does not have the source code and somehow needs to fully test the impact of changes on his application. Regression testing verifies the integrity of the application and makes sure that the changes have not introduced new software errors. Our approach involves the parsing of the WSDL XML file to extract information regarding the operation name, input message and output message. Both the original and changed XML files for the web service are parsed to extract their respective information from the port type and message element of WSDL. Then, we generate a hash table form the extracted information for both the original and delta WSDL. We pass the hash tables to a Comparator as input, which then compares the hash tables and generates the operation changes as output. In the last step test cases are selected for regressing testing of the changed web service based upon the changes in operations provided by the comparator.
I. INTRODUCTION
There is much enthusiasm around web services in today’s world. Web Services take the advantage of internet to communicate between two electronic devices connected via a network. Web Service is essentially a software system whose function is to support interoperable machine-to-machine interaction for transmitting data in a network [1]. They are standardized web applications which publish their specification in the UDDI directory that interact with other web applications for the purpose of exchanging data. Web services use five main standards to communicate over the network: Web Services Description Language (WSDL) [3], Extensible Mark up Language (XML), Hyper Text Transfer Protocol (HTTP), Simple Object Access Protocol (SOAP) [2] and Universal Description, Discovery, and Integration (UDDI).
Web Service has a Service Requester and a Service Provider. The application software which requests data is called a Service Requester, and the application software that would process the Requester’s request and provide the data is called the Service Provider. The source code for the web service is with the Service Provider. Service Requester has only the WSDL. So, whenever a change occurs in the web service, retesting of web service is required. Testing is challenge for the Service Requester as he does not have the source code and needs to fully test the impact of changes on his application. Web services do not have a Graphical User Interface. Instead they use a programmable interface for exchange of messages [7].
Web Services evolve over time as any other software application. Likewise, we need to perform Regression testing whenever there is change in the Web Service. Regression testing is done to ensure that the changed version of the Web Service is working as desired and it is still performing all the operations correctly. Regression testing verifies the integrity of the application and makes sure that the changes have not introduced new software errors [6]. Regression testing of Web Services poses a greater challenge of providing maximum test coverage to the integration with the application ensuring minimum number of test cases with minimal cost of appraisal and risk.
[4] Ha and Park have Proposed an ontological technique where they apply user level Quality of Service (QoS) that provides two different levels to serve Web service with proper quality by contribution value. Till date, great effort has been put into the research of testing Web Services [7] for integration with other applications. Regression Testing of Web Services is one such area which needs to be researched and improve the efficiency and time of testing. Many of the existing approaches for Regression testing of Web Services are based on Code based testing. They have their limitations as the Service Requester does not have the source code for the Web Service to be tested. A specification based approach of testing of web services has been proposed by Masood and Nadeem [8]. We have extended their approach and suggested some changes in the way XML are stored in order to ease the regression test case selection of Web Services.
Specification based approach utilizes the WSDL for a Web Service for selecting the test cases to be executed to retest the web service. WSDL is an XML-based interface definition language. It describes the functionality and operations offered by a web service. WSDL contains all the details regarding the operations that can be performed by the web service – Operation Name, Port Type, Message Types, Input Message, Output Message and Binding. Port Type contains the information regarding the operation names available in the web service and the messages associated with it. Messages have the data elements of the operation like parameter names and their types and the output type of the operation.
Our approach involves the parsing of the WSDL XML file to extract information regarding the operation name, input message and output message. Both the original and changed XML files for the web service are parsed to extract their respective information from the port type and message element of WSDL. Then, we generate a hash table form the extracted information for both the original and delta WSDL. We pass the hash tables to a Comparator as input, which then compares the hash tables and generates the operation changes as output. In the last step test cases are selected for regressing testing of the changed web service based upon the changes in operations provided by the comparator.
Test Cases are associated with the operations in the web services directly. Our test suite maintains the test cases along with the operation names. The Regression Test selector chooses only those test cases where there is a change in the operation name or related values or added a new operation. Other test cases for which there is no change in the system may also be selected for regression testing. This is done to ensure that the application is behaving as is before the changes. All parts of the system are covered in the Regression Testing which ensures safety [10]. The Safe Regression Test Suite covers all the test cases for the system to be tested properly. It covers the test cases for the parts which have changed as well as the parts that have not changed in the system.
Rest of the paper has been written to describe the proposed approach in detail. It is organized as follows: Section II is dedicated to literature and Section III outlines the details of the proposed approach. Section IV provides a conclusion for the paper and Section V includes any further directions for research and discussion.
چکیده
1. مقدمه
2. کارهای گذشته
3. روش ارائهشده
4. نتیجهگیری
5. کارهای آینده
منابع
Abstract
1. INTRODUCTION
2. RELATED WORK
3. PROPOSED APPROACH
4. CONCLUSION
5. FUTURE RESEARCH
REFERENCES