عنوان مقاله: متدولوژی RUP و آزمون پذیرش سیستم

RUP Methodology and System Acceptance Test

نویسنده/ مترجم: اکبر قراخانی بهار

Akbar Gharakhani Bahar

آدرس­ پست الکترونیکی نویسنده/ مترجم: a_gh_bahar@hotmail.com

تاریخ تهیه: 1384

ارسال کننده: همفکران جامعه مجازی - تاریخ ارسال: 1388

آدرس­ پست الکترونیکی ارسال کننده:

موضوع اصلی: تولید نرم­افزار - موضوع فرعی: متدولوژی­های نرم­افزار

سه کلیدواژه اصلی به ترتیب اهمیت: unit test، integration test، system test

سه کلیدواژه فرعی به ترتیب اهمیت: acceptance test،alpha test ، beta test

 

چکیده مقاله

در RUP، کار انتقال سیستم از محیط ایجاد کننده به محیط استفاده کننده آن، در طی«فاز انتقال» که آخرین فاز از فازهای چهارگانه RUP است، صورت می­گیرد. با توجه به وجود «تکرار» در فازهای RUP، سیستم نهایی غالبا در طی تکرارهای مختلف و در هر تکرار نسخه کامل­تری از سیستم به محیط استفاده کننده منتقل می­گردد. قبل از اجرای فاز انتقال در RUP، لازم است که مراحل آزمون اولیه نرم­افزار توسط ایجاد کننده آن انجام شده و «معیار» مربوط به پایان «فاز ساخت» به عنوان فاز سوم پیش از فاز انتقال نیز محقق شده باشد. مفهوم معیار مربوط به پایان فاز ساخت این است که نرم­افزار به مرحله عملیاتی شدن رسیده و می­تواند به صورت آزمایشی توسط استفاده کنندگان مورد استفاده قرار گیرد. مفهوم تکرار در RUP متضمن شکستن پروژه اصلی به چند پروژه فرعی است. انجام پروژه­های فرعی با شروع از پروژه فرعی اول در قالب یک تکرار و ادامه کار با پروژه­های فرعی در قالب تکرارهای بعدی، به صورتی پیش­رونده ما را در نهایت با محصول کل پروژه و نرم­افزار نهایی همراه می­کند. در این نگرش، «پیش­رونده» به این مفهوم است که با هر تکرار در واقع نسخه جدیدی از نرم­افزار که نسبت به نسخه قبلی «کامل­تر» و نیز «بی­­عیب­تر» است، به استفاده کنندگان ارائه می­شود. به بیان دیگر در پایان پروژه فرعی n، نسخه­های جدید محصولات پروژه­های فرعی 1 تا 1- n (ضمن رفع مشکلات نسخ پیشین آن­ها) به علاوه محصول پروژه فرعی n ارائه می­شود. به همین خاطر گفته می­شود که در RUP آزمون­های پذیرش در طول فرایند ایجاد نرم­افزار در قالب تکرارهای RUP از طرف استفاده کنندگان نهایی همواره می­توانند انجام ­شوند. بدین ترتیب در RUP به جای یک آزمون پذیرش در روش سنتی، می­توان n آزمون پذیرش ترتیب داد که به صورتی پیش­رونده از بخش اول سیستم شروع و با انباشت بخش­های بعدی سیستم بر روی هم، در نهایت به آزمون پذیرش کل سیستم ختم ­شود.

دریافت فایل PDF مقاله

متدولوژی RUP و آزمون پذیرش سیستم

مقدمه

هر سیستم نرم­افزاری بعد از آماده شدن برای اجرا، در محیط استفاده کنندگان نهایی آن نصب و آماده اجراهای آزمایشی توسط استفاده کنندگان می­گردد. در RUP، کار انتقال سیستم از محیط ایجاد کننده به محیط استفاده کننده آن، در طی« فاز انتقال» (Transition Phase) که آخرین فاز از فازهای چهارگانه RUP است، صورت می­گیرد. البته با توجه به وجود «تکرار» (iteration) در فازهای RUP، سیستم نهایی غالبا در طی تکرارهای مختلف و در هر تکرار نسخه کامل­تری از سیستم به محیط استفاده کننده منتقل می­گردد. بدین خاطر در عمل ممکن است فاز انتقال چندین تکرار یا مرحله را شامل شود.

 

بدیهی است که قبل از اجرای فاز انتقال در RUP، لازم است که مراحل آزمون اولیه نرم­افزار توسط ایجاد کننده آن انجام شده و «معیار» (milestone) مربوط به پایان «فاز ساخت» (Construction Phase) به عنوان فاز سوم پیش از فاز انتقال نیز محقق شده باشد. لازم به یادآوری است که معیار مربوط به پایان فاز ساخت Initial Operative Capability (IOC) است و مفهوم آن این است که نرم­افزار به مرحله عملیاتی شدن رسیده و می­تواند به صورت آزمایشی توسط استفاده کنندگان مورد استفاده قرار گیرد.

 

باید اضافه شود که RUP دارای ابزارهای متعددی برای انجام آزمون یا مدیریت آن است. در این زمینه ClearQuest، ClearCase، RequisitePro، Purify، PureCoverage،   Robotو غیره می­توانند به کار گرفته شوند. در این مطلب به ابعاد مختلف آزمون پذیرش یک سیستم نرم­افزاری اشاره خواهد شد.

 

انواع آزمون سیستم

آزمون یک سیستم نرم­افزاری از نظر انجام دهنده یا محل انجام آزمون، در دو وجه مختلف زیر قابل طرح است:

  • آزمون­های ایجاد کننده / Developer's Tests
  • آزمون­های استفاده کننده / User's Tests

آزمون­های ایجاد کننده که غالبا برای کشف و رفع «خطاها/ اشتباهات» (faults) و «قصور/ کمبودها» (failures) اجرایی در سیستم ایجادی انجام می­شوند، شامل انجام آزمون­های شناخته شده در صنعت نرم­افزار است. این آزمون­ها موارد زیر را شامل می­شوند:

  • آزمون تک تک واحدها/ Unit Test شامل آزمون مربوط به تک تک واحدهای نرم­افزاری که مجموع آن­ها کل سیستم نرم­افزاری را به وجود می­آورند.
  • آزمون واحدهای تجمیع شده به صورت سیستم/ Integration Test شامل آزمون مربوط به کل سیستم که از تجمیع یا یک پارچه کردن واحدهای نرم­افزاری قبلا آزموده شده به دست آمده است.
  • آزمون سیستم/ System Test شامل آزمون مربوط به سیستم حاصل از تجمیع واحدها در تعامل با سایر سیستم­های مرتبط با این سیستم

 

آزمون سیستم غالبا طی دو مرحله جداگانه به شرح زیر صورت می­گیرد:

  • آزمون آلفا/ Alpha Test شامل آزمون سیستم به صورت «درونی» (internal) و از طریق مجموعه­ای کوچک از «آزمون کنندگان» (testers) در محیط ایجاد کننده
  • آزمون بتا/ Beta Test شامل آزمون سیستم به صورت «بیرونی» (external) و از طریق مجموعه نسبتا بزرگی از«استفاده کنندگان» (users) در خارج از محیط ایجاد کننده و حتی عموم. از نرم­افزار عرضه شده برای این منظور غالبا به عنوان «نسخه بتا» (Beta Version) نیز یاد می­شود. همان­طور که دیده می­شود، معیار پایان فاز ساخت در RUP نیز در واقع شامل تهیه نسخه بتا از نرم­افزار است.

 

آزمون­های مربوط به استفاده کننده، در عمل تحت عنوان «آزمون پذیرش» (Acceptance Test) یا «آزمون عملکرد» (Functional Test) انجام می­شود. همچنین بعد از انجام هر گونه تغییرات در سیستم، آزمونی تحت عنوان «آزمون برگشتی» (Regression Test) انجام می­شود تا اطمینان حاصل شود که تغییرات انجام شده باعث ایجاد خطا و قصور یا اثرات جانبی نامطلوب در سیستم نشده­است. این آزمون ممکن است توسط هر دو طرف ایجاد کننده و استفاده کننده از سیستم انجام شود. به عنوان سفارش دهنده یا تحویل گیرنده یک سیستم نرم­افزاری، ما در این مطلب به وجوه آزمون پذیرش یا عملکرد که متولی انجام آن استفاده کنندگان نهایی سیستم هستند، خواهیم پرداخت.

 

مفهوم آزمون پذیرش

آزمون پذیرش وسیله­ای است که استفاده کنندگان نهایی سیستم با انجام آن از کارکرد درست سیستم از نظر خود، اطمینان حاصل می­کنند. اگر آزمون­های قابل انجام توسط ایجاد کننده را وسیله­ای برای کسب اطمینان از «انجام درست کارها» (Doing Things Right) در مورد «آنچه که ایجاد شده­است» در نظر بگیریم، در این صورت آزمون پذیرش که از طرف استفاده کننده انجام می­شود، به عنوان وسیله­ای برای کسب اطمینان از «انجام کارهای درست» (Doing Right Things) در مورد «آنچه که خواسته شده­است»، خواهد بود.

 

ذی­نفع اصلی در آزمون پذیرش، استفاده کننده سیستم است. اهداف استفاده کننده از سیستم از انجام آزمون پذیرش کسب اطمینان از موارد زیر است:

  • برآورده کردن نیازهای استفاده کننده/ Capturing User Requirements
  • اجرای بری از خطا و قصور سیستمFault and Failure Free / Running

آزمون پذیرش به عنوان «قرارداد»ی بین ایجاد کننده و استفاده کننده از سیستم تلقی می­شود. با این تعبیر، وقتی یک آزمون پذیرش با موفقیت انجام شود، می­توان گفت که با این عمل در واقع پروژه مربوط به ایجاد سیستم پایان یافته است.

 

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

 

چگونگی انجام آزمون پذیرش

آزمون پذیرش در بخش برآورده کردن نیازهای استفاده کننده، باید برآورده شدن یا نشدن نیازهای استفاده کننده را مشخص نماید. این کار می­تواند با اجرای آزمایشی سیستم و بررسی اجزاء و مؤلفه­های کل سیستم و تطابق آن با نیازمندی­های عنوان شده در مستندات پیشین، صورت گیرد. آزمون پذیرش در بخش اجرای بری از خطا و قصور سیستم نیز باید وجود یا عدم وجود خطا و قصور در اجزاء و مؤلفه­های سیستم  را مشخص کند. این کار نیز می­تواند با اجرای آزمایشی سیستم و ثبت موارد خطا و قصور و گزارش آن به ایجاد کننده سیستم صورت گیرد.

 

همان­طور که خود سیستم حول «موارد کاربرد» (Use Cases) قابل شکل­گیری است، آزمون پذیرش سیستم نیز در حول «موارد آزمون» (Test Cases) قابل انجام است. به تعبیر استاندارد IEEE 829-1998 ، یک «مورد آزمون» شامل «ورودی­های معین» و «خروجی­های مورد انتظار» است. همان­طور که یک سیستم می­تواند شامل چندین مورد کاربرد باشد، یک آزمون پذیرش سیستم نیز می­تواند شامل چندین مورد آزمون باشد. با این تعبیر، هر مورد کاربرد می­تواند شامل یک یا چند مورد آزمون پذیرش باشد.

 

مطالب قابل بیان در باره یک مورد آزمون پذیرش شامل اقلامی نظیر شماره شناسایی آزمون، شماره ترتیب انجام و سایر نیازمندی­های آن است. این نیازمندی­ها می­تواند شامل پیش­شرط/ پیش­نیازهای آزمون، ورودی، رویه عملیاتی مورد آزمون در سیستم و خروجی مورد انتظار باشد. کل یک آزمون پذیرش را می­توان به صورت یک جدول «صفحه گسترده» (Spread Sheet) و یک مورد آزمون را  نیز می­توان به صورت سطری از این جدول سازمان داد. در این صورت باید برای نتیجه واقعی که از طریق آزمون به دست آمده است، نام انجام دهنده آزمون، تاریخ و محل انجام آزمون و غیره نیز ستون­هایی در نظر گرفته شود.

 

آزمون­ پذیرش ممکن است به صورت دستی، نیمه دستی+نیمه اتوماتیک و یا اتوماتیک صورت گیرد. بسته به مورد، آزمون­های پذیرش ممکن است با عناوینی از قبیل Test Specification، Test Suite یا  Test Script نیز مورد خطاب قرار گیرند. در این صورت عنوان به کار رفته ممکن است به نوعی نشان دهنده نوع آزمون ازقبیل دستی، نیمه دستی+نیمه اتوماتیک و یا اتوماتیک نیز باشد.

 

توصیه­های RUP در انجام آزمون پذیرش

یکی از نقاط قوت RUP در ایجاد سیستم­های نرم­افزاری، ایجاد نرم­افزار در طی «تکرار» های مختلف است. همان­طور که می­دانیم مفهوم تکرار در RUP متضمن شکستن پروژه اصلی به چند پروژه فرعی است. انجام پروژه­های فرعی با شروع از پروژه فرعی اول در قالب یک تکرار و ادامه کار با پروژه­های فرعی در قالب تکرارهای بعدی، به صورتی پیش­رونده ما را در نهایت با محصول کل پروژه و نرم­افزار نهایی همراه می­کند. در این نگرش، «پیش­رونده» به این مفهوم است که با هر تکرار در واقع نسخه جدیدی از نرم­افزار که نسبت به نسخه قبلی «کامل­تر» و نیز «بی­­عیب­تر» است، به استفاده کنندگان ارائه می­شود.

 

به بیان دیگر در پایان پروژه فرعی n، نسخه­های جدید محصولات پروژه­های فرعی 1 تا 1- n (ضمن رفع مشکلات نسخ پیشین آن­ها) به علاوه محصول پروژه فرعی n ارائه می­شود. به همین خاطر گفته می­شود که در RUP آزمون­های پذیرش در طول فرایند ایجاد نرم­افزار در قالب تکرارهای RUP از طرف استفاده کنندگان نهایی همواره می­توانند انجام ­شوند. بدین ترتیب در RUP به جای یک آزمون پذیرش در روش سنتی، می­توان n آزمون پذیرش ترتیب داد که به صورتی پیش­رونده از بخش اول سیستم شروع و با انباشت بخش­های بعدی سیستم بر روی هم، در نهایت به آزمون پذیرش کل سیستم ختم ­شود.