— (720)

1833245-501015
وزارت علوم، تحقیقات و فناوری
دانشگاه علوم و فنون مازندران
پایان نامه
مقطع کارشناسی ارشد
رشته : مهندسی فناوری اطلاعات
عنوان: اولویت بندی کارآمد موارد تست نرم افزار به کمک شبکه‌ های بیزیاستاد راهنما : دکتر حسین مومنی
استاد مشاور : دکتر بابک شیرازی
دانشجو : محمد رضا قلی پور
تابستان 1392
تقدیم
به دو گوهر بی همتای حیاتم، پدر ارجمند و مادر عزیزم، که با درخشش و گرمای نگاه خود کویر وجودم را چون گلستانی طراوت و تازگی می بخشند و با قلب مهربان خود نامهربانی های ایام را می زدایند.
بوسه هایم نثار دستان شما بزرگ آموزگاران زندگی باد.
همچنین تقدیم :
به روح برادر کوچک و مهربانم، مصطفی که همیشه یادش در اندیشه ام خواهد ماند.
سپاسگزاری
الهی در دل های ما جز تخم محبّت مکار و بر جان های ما جز الطاف و مرحمت خود منگار و بر کشت های ما جز باران رحمت خود مبار، به لطف، ما را دست گیر و به کرم، پای دار. الهی حجاب از راه بردار و ما را به ما مگذار.
این گفتار فرصتی است تا از کسانی که در به انجام رساندن این پایان نامه مرا یاری نمودند تشکر و قدردانی کنم. استاد راهنمای ارجمند و فرزانه آقای دکتر حسین مومنی که در سایه ی رهنمودها، صبر و شکیبایی ایشان توانستم این پایان نامه را به پایان برسانم. جناب آقای دکتر بابک شیرازی، استاد مشاور، که با سعه ی صدر مرا مرهون و مدیون لطف خویش نمودند. همچنین از دوست عزیز و ارجمندم مهندس هادی کامفر نیز نهایت تشکر و قدردانی را دارم. امیدوارم روزگار مرا به جبران زحمت های این عزیزان توفیق دهد.
محمد رضا قلی پور
چکیده
رگرسیون این اطمینان را حاصل می‌کند كه تغییرات بر روی رفتار كنونی نرم افزار اثر نامطلوبی نگذاشته است. یكی از تكنیك های تست رگرسیون تكنیک اولویت بندی است كه باعث افزایش كارایی تست می‌شود. تکنیک های اولویت بندی موارد تست در بهبود تشخیص نرخ خطای تست رگرسیون موثراند. با این حال، بیشتر تکنیک های پیشنهاد شده قبلی برای خطاهای تشخیص داده شده در طول تست، شدت برابری را در نظر می‌گیرند که در عمل اینگونه نیست. علاوه بر این، بیشتر تکنیک های موجود برروی اطلاعات قبلی بدست آمده از اجرای موارد تست قبلی یا تغییر در کد برنامه تکیه می‌کنند و تعداد کمی از آنها می‌توانند به طور مستقیم برای تست غیر رگرسیون استفاده شوند. در این رساله، با هدف بهبود نرخ تشخیص خطا برای تست رگرسیون و همچنین تست غیر رگرسیون، پیشنهاد کردیم یک رویکرد جدید اولویت بندی موارد تست را با استفاده از شبکه‌های بیزی با تکیه بر تجزیه تحلیل ساختار برنامه تحت تست. برای پیاده سازی رویکرد پیشنهادی، ما از ابزار Netica و همچنین روش کد نویسی در نرم افزار MATLAB استفاده می‌کنیم. و همچنین از متریک APFD (متوسط درصد شناسایی خطا) جهت ارزیابی نرخ تشخیص خطا در این رساله تكیه می‌کنیم. و روش مبتنی بر شبکه‌های بیزی بر اساس تجزیه و تحلیل ساختار برنامه را ارائه خواهیم نمود. در نهایت با كمك یك بررسی موردی، كاربرد روش خود را نشان می‌دهیم. نتایج مقایسه تكنیك پیشنهادی با سایر تكنیك ها نشان می‌دهد كه روش ارائه شده نسبت به سایر روش‌ها نتیجه دقیق تری را ارائه می‌نماید. ضمن اینکه روش پیشنهادی قادر به تصمیم گیری در وضعیت عدم قطعیت هم می باشد و این به عنوان ویژگی محسوب می شود. همچنین علاوه بر در نظر گرفتن معیار احتمال ابتلا به خطا و اهمیت خطا ، معیارهایی نظیر اثر گذاری خطای ماژول بر دیگر ماژول‌ها و شدت خطای هر ماژول را نیز مورد توجه قرار می‌دهد و به همین خاطر روشی کامل‌تر از روش مشابه می‌ باشد و این توانایی را دارد که علاوه بر تست رگرسیون در تست توسعه نرم افزار هم مورد استفاده قرار بگیرد.
کلمات کلیدی : تست رگرسیون ، شبکه های بیزی ، اولویت بندی موارد تست، نرخ تشخیص خطا
فهرست رئوس مطالب
فصل اول : مقدمه و کلیات تحقیق TOC \o “1-3” \h \z \u
مقدمه31-1 – یك شیوه استراتژیك برای آزمایش نرم افزار5 1-2- اصول آزمایش نرم افزار6 1-3- برخی از انواع سطوح تست نرم افزار 6
1-4- آشنایی با شبکه‌ های بیزی9
1-4-1- مقدمه ای بر شبکه‌ های بیزی9
1-5- اندازه گیری و متریک10 1-6- بیان مسئله16 1-7- چالش موجود در تست رگرسیون17 1-8- راه حل برای چالش موجود در تست رگرسیون17 1-9- توجیه ضرورت انجام طرح18 1-10- هدف از اجراء19 1-11- نوآوری تحقیق19 فصل دوم : ادبیات و پیشینه تحقیق
2-1- پیشینه تحقیق21 2-1-1- کارهای مرتبط21 2-1-2- بررسی مشکلات موجود در روش‌های مطالعه شده قبلی22 2-2- تست نرم افزار24 2-3- صحت و اعتبار سنجی24 2-4- اهداف آزمایش25 2-5- اصول آزمایش26 2-6- قانون Pareto در فرآیند تست نرم افزار26 2-7- چند نمونه از انواع تست27 2-8- مراحل انجام تست27 2-9- ویژگی‌های یک نرم‌افزار تست‌ پذیر28 2-10- ویژگی‌های یک تست خوب29 2-11- طراحی نمونه‌های آزمایش30 2-11-1 تست جعبه سیاه 31 2-11-2 تست جعبه سفید 31 2-11-3 آزمایش ساختاركنترل31 2-11-4 آزمایش واحد31 2-11- 5 خطاهای متداول محاسبه که اغلب مشاهده می‌شوند32
2-12- آزمایش یکپارچه سازی 32 2-13- آزمایش رگرسیون 33 2-14- متدولوژی های مربوط به تست رگرسیون35 2-14-1- اجرای مجدد همه‌ ی تست ها 35 2-14-2- انتخاب تست رگرسیون 36 2-14-3- کاهش مجموعه تست 36 2-14-4- اولویت بندی موارد تست 36 2-15- اولویت بندی37 2-15-1- مقدمه ای بر اولویت بندی372-15-2 – معیارهای اولویت دهی38
2-15-3- اولویت بندی موارد تست39 2-16- متریک39 2-16-1- مقدمه ای برای متریک39 2-17- متریک های تست نرم افزار40 2-17-1- خواص متریک ها در شرایط ایده آل40 2-18- معیار و متریک در تست نرم افزار43 2-18-1- مراحل انجام کاردر فرایند اندازه گیری43 2-19- متریک های آزمون43 2-20- مزایای استفاده از متریک ها44 2-21- شبکه‌ های بیزی45 2-21-1- استنتاج با استفاده از توزیع توام كامل45 2-21-2- مشكلات استنتاج با توزیع توام كامل و راه ‌حل آن ‌ها47 2-21-3- مثالی از شبکه ‌های بیزی48 2-22- مفاهیم شبكه ‌های بیزی50 2-22-1- نمایش توزیع توام كامل50 2-22-2- رابطه ‌های استقلال شرطی در شبكه‌ های بیزی52 2-22-3- نمایش كارآمد توزیع ‌های شرطی53 2-23- یادگیری شبكه‌ های بیزی54 2-24- استنتاج دقیق در شبكه‌ های بیزی55 2-25- استنتاج بوسیله محاسبه تك ‌تك عناصر احتمالی55 2-26- الگوریتم حذف متغیر57 2-27- استنتاج تقریبی در شبكه‌ های بیزی58 2-28- روش‌های نمونه‌گیری مستقیم58 2-28-1- نمونه ‌گیری با رد كردن59 2-28-2- نمونه ‌گیری وزن ‌دار60 2-28-3- نمونه‌ گیری زنجیره ماركوفی61 2-28-4- جمع ‌بندی شبکه‌های بیزی62 2-29- تحولات انجام شده تا کنون63فصل سوم : روش تحقیق
-3 انگیزه و هدف ما از ارائه این رویکرد66 3-1- رویکرد پیشنهادی68 3-1-1- روند کلی در رویکرد پیشنهادی68 3-2- محاسبه و استخراج شاخص‌ها برای ماژول‌ها70
3-3 – معیارهای رویکرد پیشنهادی70 3-3-1- اهمیت هر ماژول71 3-3-2- احتمال ابتلا به خطای ماژول72 3-3-3- اثرگذاری خطای ماژول بر دیگر ماژول‌ها72 3-3-4- شدت خطای هر ماژول73 3-4- شاخص‌های وزن دهی به ماژول‌ ها74 3-5- ساخت شبکه بیزی74 3-6- ایجاد ساختار گراف75 3-7- محاسبه جداول احتمال شرطی76 3-8- تبدیل اندازه‌ی كیفی صفت‌ ها به مقادیركمی79
3-9-روش اول برای صفت‌ های سه حالته79 3-9-1- مثالی از روش اول برای صفت های سه حالته80 3-10- روش دوم برای صفت‌های سه حالته81 3-10-1- مثالی از روش دوم برای صفت های سه حالته81 3-11- تبدیل اندازه‌ی كیفی صفت‌ های غیرهم وزن به مقادیركمی82 3-11-1- مثالی از روش تبدیل اندازه‌ی كیفی صفت‌ های غیرهم وزن به مقادیركمی83 3-12- پیاده سازی مدل تست کارآمد نرم افزار با استفاده از نرم افزار Netica85 3-13- پركردن جدول احتمال شرطی با استفاده از كد نویسی87 3-14- نمونه هایی از جداول احتمال شرطی فاکتورهای تست و کارآمدی اولویت بندی90 3-15- پیاده سازی رویکرد پیشنهادی در مثال واقعی94فصل چهارم : محاسبات و یافته های تحقیق
– 4 1- ارزیابی مدل پیشنهادی972-4 – متریک (APFD)97 4-3- اولویت بندی با کمک تکنیک شبکه های بییزی 98 4-4- اولویت بندی با تکنیک اصلی 101 4-5- اولویت بندی با تکنیک تصادفی102 4-6- مقایسه روش های اولویت بندی با روش پیشنهادی103فصل پنجم : نتیجه گیری و پیشنهادات
1-5 نتیجه گیری1082-5 پیشنهادات آینده110 پیوست الف: واژه نامه ی فارسی به انگلیسی111پیوست ب: واژه نامه ی انگلیسی به فارسی114 منابع و ماخذ117فهرست جداول
جدول2-1: توزیع یک قلمرو ساده45
جدول2-2 : سیر تحولات در مورد اولویت بندی موارد تست 63
جدول3-1 : سیستمی ساده شامل 10 ماژول و 10 مورد تست67
جدول3-2 : سطح شدت خطای هر ماژول74
جدول3-3 : تعداد سطرهای جدول احتمال شرطی فاکتورهای تست78
جدول3-4 : انتساب مقدار عددی به اندازه‌های کیفی در صفت‌های سه حالته79
جدول3-5 : بازه‌های تبدیل میانگین به اندازه‌های کیفی در صفت‌های سه حالته 80
جدول3-6 : نمونه سطری از جدول احتمال شرطی فاكتوراحتمال ابتلا به خطای ماژول، سه حالته 81
جدول3-7 : سطری از جدول احتمال شرطی احتمال ابتلا به خطای ماژول با سه ویژگی فرعی 82
جدول3-8 : نمونه سطری از جدول احتمال شرطی فاكتوراحتمال ابتلا به خطای ماژول، سه حالته 85
جدول3-9 : اندازه درصد احتمال حالت‌ها در فاکتورها بدون مشاهده ویژگی‌های فرعی، سه حالته 87
جدول 3-10: اندازه ویژگی‌های فرعی در یک پروژه نرم افزاری نمونه 94
جدول4-1: تعداد خطای شناسایی شده توسط موارد تست با توجه به زمان کل هر مورد تست 98
جدول4-2 : نتایج ارزیابی از نسخه های مختلف برنامه تحت تست 106
جدول4-3 : تکنیک های اولویت بندی استفاده شده در این ارزیابی 106
فهرست تصاویر و نمودار
شکل2-1:گراف متریک های کلی نرم افزار 41
شكل2-2 : شبکه بیزی قلمرو دستگاه آژیر 48
شکل3-2 : ارائه مفاهیم ساختاری به دو صورت معمول 53
شكل4-2 : جواب به درخواست با محاسبه عبارت بهینه‌تر 56
شکل5-2 : الگوریتم حذف متغیر 57
شكل6-2 : الگوریتم نمونه‌گیری با رد کردن 59
شكل7-2 : الگوریتم نمونه‌گیری وزن‌دار 61
شكل8-2 : الگوریتم نمونه‌گیری وزن‌دار 62
شکل3-1 : ماژول‌ های یک سیستم ساده نرم افزاری 66
شکل3-2 : یک پیاده سازی عمومی برای چارچوب مبتنی بر شبکه‌ های بیزی 69
شکل3-3 : گراف شبکه بیزی تست کارآمد نرم افزار 75
شکل3-4 : پیاده سازی مدل تست کارآمد نرم افزار با استفاده ازنرم افزار Netica 86
شکل3-5 : شبه کد پر کردن جدول احتمال شرطی برای اهمیت ماژول با دو ویژگی فرعی 88
شکل3-6 : شبه کد پر کردن جدول احتمال شرطی برای تعداد خطاها با سه ویژگی فرعی 89
شکل3-7 : جدول احتمال شرطی تعداد موارد تست 90
شکل3-8 : جدول احتمال شرطی تعداد خطاها 91
شکل3-9 : جدول احتمال شرطی اهمیت ماژول 92
شکل3-10 : جدول احتمال شرطی کارآمدی نهایی تست نرم افزار 93
شکل3-11 : پیاده سازی مدل تست کارآمد نرم افزار بروی سیستم مدیریت پرونده های قضایی 95
شکل4-1 : نمودار نرخ شناسایی خطا با روش BN برای اولویت بندی موارد تست 100
شکل4-2 : نمودار نرخ شناسایی خطا با روش Orginal برای اولویت بندی موارد تست 102
شکل4-3 : نمودار نرخ شناسایی خطا با روش Random برای اولویت بندی موارد تست 103
شکل4-4 : نمودار مقایسه نتایج روش پیشنهادی با دو روش دیگر در نرخ شناسایی خطا 104

فصل اول
مقدمه و کلیات تحقیق
مقدمه
سیستم های نرم افزاری امروزه با فراگیر شدن در علوم مختلف نقش بسیار مهمی را در برطرف نمودن نیازها و خواسته‌های مشتریان ایفا می‌کنند و همچنین به عنوان یک جزء اصلی و لاینفک در امور روزمره به حساب می‌آیند. با گسترش روز افزون تولید سیستم های نرم افزاری همچنان تقاضا برای تولید سیستم های نرم افزاری جدید وجود دارد. بحث مهم بعد از تولید نرم افزارها نگهداری و ارتقاء آنها می‌باشد. وجود خطا و اشتباه در نرم افزارها می‌تواند منجر به خسارات زیادی از قبیل هزینه‌های مالی، زمانی، فیزیکی وحتی در برخی کاربردهای حساس و بحرانی مانند کاربردهای پزشکی، کنترل کننده موشک و کنترل کننده‌های ترافیک هوایی خسارت جانی را نیز به بار آورد. از این رو برای اینکه قابلیت اطمینان را در استفاده از سیستم های نرم اقزاری افزایش دهیم باید نرم افزار را مورد تست قرار دهیم. تست نرم افزار در توسعه سیستم های نرم افزاری از جایگاه مهم و با ارزشی برخوردار است. به خصوص در سیستم های نرم افزاری مقیاس بزرگ و پیچیده امروزی. زیرا فعالیت‌های تست هم زمان بر و هم هزینه بر هستند. نرم افزارها برای اینکه ارتقاء یابند می‌بایست توسعه داده شوند و نسبت به نسخه‌های اولیه رشد و تکامل یابند. یکی از فعالیت‌های مهم و هزینه بر در جهت ارتقاء نرم افزار تست نرم افزار است که انواع متفاوتی از تست برای بخش‌های مختلف و در زمانهای مختلف طراحی و ایجاد شده‌اند. تست فرآیندی است مخرب که محصول نرم افزاری را مورد حمله قرار می‌دهد تا اینکه خطا بروز کند. تست نرم افزار شامل تحقیق و بررسی بر روی نرم افزار تولید شده است که این تحقیق و برسی برای پیدا کردن خطاها انجام می‌شود. به طور کلی یک سری از سوال و جواب‌هایی هستند که نرم‌افزار را با آن امتحان می‌کنیم در حالی که از برنامه انتظار داریم با توجه به ورودی‌هایی که با استفاده از سوالات وارد می‌کنیم، جواب‌های صحیحی را به عنوان خروجی به دست دهد. آزمایش نرم‌افزار حیطه وسیعی از فعالیت‌های مربوط به تولید برنامه‌های رایانه‌ای را دربرمی‌گیرد که از آزمایش کردن کد برنامه توسط برنامه‌نویس گرفته تا نشان دادن عملکرد درست یک سیستم اطلاعاتی بزرگ به مشتری. سازمانها یا شرکت‌هایی که نرم افزارها را توسعه می‌دهند، محصولی به نام نرم افزار تولید می‌کنند. ولی چه عامل یا عواملی باعث می‌شوند که یک نرم افزار از نرم افزار مشابه دیگر متمایز و برجسته شود؟ عوامل متعددی را می‌توان نام برد که باعث این برتری و تمایز شود اما یکی از این عوامل می‌تواند کیفیت محصول نهایی باشد که به بازار عرضه خواهد شد. اما برای رسیدن به این نقطه برتری، باید چگونه عمل کرد و اندیشید؟ یکی از پاسخ‌ها به این سوال بدون شک تست نرم افزار و نحوه انجام آن می‌تواند باشد.
اهمیت آزمایش نرم افزار و اثرات آن بر كیفیت نرم افزار نیاز به تأكید بیشتر ندارد.Deutch در این باره اینگونه بیان می‌نماید: توسعه سیستمهای نرم افزاری شامل یكسری فعالیت‌های تولید می‌باشد كه امكان اشتباهات انسانی در آن زیاد است. خطاها در ابتدای یك فرآیند و مراحل توسعه بعدی آن ظهور می ‌نمایند. به دلیل عدم توانایی انجام كارها و برقراری ارتباط به صورت كامل، توسعه نرم افزار همواره با فعالیت تضمین كیفیت همراه است. آزمایش نرم افزار عنصری حیاتی از تضمین كیفیت نرم افزار می ‌باشد و مرور تقریبی مشخصه، طراحی، و تولید كد رانشان می ‌دهد. [1]
1-1 – یك شیوه استراتژیك برای آزمایش نرم افزارآزمایش،مجموعه فعالیت‌هایی است كه می‌تواند از قبل به صورت سیستماتیك برنامه ریزی و هدایت شوند . به این دلیل، الگویی برای آزمایش نرم افزار باید برای فرآیند نرم افزار تعریف شود. این الگو شامل مجموعه مراحلی است كه می‌توان تكنیك های خاص طراحی نمونه‌های آزمایش و روش‌های آزمایش را در آن قرار داد.
چند استراتژی آزمایش نرم افزار در این رابطه پیشنهاد شده است . همه آنها برای توسعه دهنده نرم افزار، الگویی را به منظور آزمایش فراهم می‌کنند و همگی دارای خصوصیات زیر هستند:
آزمایش از سطح مؤلفه شروع می‌شود به سمت خارج در جهت مجتمع سازی كل سیستم كامپیوتری پیش می‌رود.
تكنیك های متفاوت آزمایش، در نقاط زمانی مختلف مناسب می ‌باشند.
آزمایش توسط توسعه دهنده نرم افزار و برای پروژه‌های بزرگ توسط گروه مستقل آزمایش، هدایت می‌شود.
آزمایش و اشكال زدایی فعالیت‌های متفاوتی هستند، اما اشكال زدایی باید با هر استراتژی آزمایش همراه باشد.
یك استراتژی برای آزمایش نرم افزار باید آزمایش‌های سطح پایینی را هدایت كند كه برای بازبینی صحت پیاده سازی یك قطعه كد كوچك لازم می ‌باشند. همچنین این استراتژی باید آزمایش‌های سطح بالایی را سازمان دهی كند كه اكثر توابع سیستم را در رابطه با نیازهای مشتری اعتبار سنجی می‌ نمایند. یك استراتژی باید راهنمایی‌هایی را برای مجری و مجموعه ای از علایم نشان دهنده را برای مدیر فراهم نماید. چون این مراحل استراتژی آزمایش زمانی انجام می شوند كه فشار مربوط به پایان مهلت، شروع به افزایش می‌نماید، پیشرفت باید قابل اندازه گیری باشد و مشكلات باید تا حد امكان به سادگی برطرف شوند.
1-2- اصول آزمایش نرم افزارآزمایش، موارد غیر معمول جالب توجه ای را برای مهندس نرم افزار آشكار می‌نماید. در ضمن فعالیت‌های اولیه مهندسی نرم افزار، مهندس، سعی در ایجاد نرم افزار با استفاده از مفهومی مجرد و بدست آوردن محصولی واضح و كامل دارد و اینك آزمایش باید انجام شود .مهندس تست یكسری نمونه‌های آزمایش ایجاد می‌ کند كه باید نرم افزار ایجاد شده را با شكست روبرو نماید. در واقع، آزمایش، یك مرحله در فرآیند نرم افزار است كه می ‌تواند به عنوان فرآیندی مخرب به جای سازنده در نظر گرفته شود (حداقل از نظر روانشناسی) به هرحال هدف از آزمایش چیزی متفاوت از آنچه انتظار می ‌رود می ‌باشد. در بسیاری از شرکت‌ها حدود 30 تا 50 درصد از هزینه نرم افزار را صرف تست آن می‌کنند، با این وجود برخی هنوز هم بر این عقیده‌اند که نرم افزارها قبل از انتشار و تحویل به مشتری به درستی تست نمی‌شوند. چند دلیل باعث این باور می‌شوند : اول اینکه انجام تست نرم افزار امری است بسیار مشکل. دوم اینکه معمولاَ به خاطر زمانبر بودن و دیگر عوامل از قبیل : هزینه‌ی بالای تست نرم افزار ، فشارهای وارده از سوی بازار ، مشتری و رقبا منجر به این شده‌اند تا مدت زمان اختصاص داده شده برای انجام تست بسیار کمتر از دیگر بخش‌های فرایند تولید نرم افزار گردد. دلیل دیگر نداشتن برنامه (استفاده از متدولوژی و ابزاری مشخص) برای تست کردن می‌باشد. با این وجود تمامی شرکت‌های تولید کننده نرم افزار با هدف تولید نرم افزاری با کیفیت و افزایش رضایتمندی مشتری، محصول خود را مورد تست قرار می‌دهند. کیفیت چیزی است که ما در تمامی چرخه تولید نرم افزار از قبیل تولید محصولات نرم افزاری ، فرایندها و خدمات ارائه شده به مشتری یا کاربران به دنبال آن هستیم. [2]
1-3- برخی از انواع سطوح تست نرم افزار تست عملکرد: در این نوع تست، نرم افزار تست می‌شود تا از لحاظ درستی عملکرد بررسی شود تست ها اجرا می‌شوند تا ببینند که آیا نرم افزار همان گونه که انتظار می‌رود عمل می‌کند. معمولا این روش در انتهای کار انجام می‌شود ولی می‌توان از همان ابتدای کار با تست کردن قسمت‌های کوچک مثل جزء ها نتیجه نهایی را ساده کرد.
تست فشار : برنامه در مقابل بار سنگین مثل مقادیر عددی پیچیده ، مقادیر زیادی ورودی و مقادیر زیادی پرس وجو امتحان می‌شود . که میزان باری که برنامه می‌تواند آن را تحمل کند را بررسی می‌کند . هدف ، طراحی محیطی است که مخرب تر از محیطی که برنامه در دنیای واقعی و در شرایط نرمال با آن روبرو می‌شود.
تست بار : برنامه در مقابل بار زیاد ورودی‌ها تست می‌شود مثل تست وب سایت ها برای یافتن نقاطی که در آن نقاط وب سایت یا برنامه شکست می‌خورد و یا نقاطی که در آنها کارایی وب سایت کاهش پیدا می‌کند. تست بار در سطح بار از پیش تعیین شده ای انجام می‌شود. بالاترین باری که سیستم می‌تواند بپذیرد، در حالیکه هنوز به درستی کار می‌کند. اما می‌خواهد سیستم را به طور پیوسته زیر بار نگه دارد و در صورت ایجاد مشکل با پیغام زیر روبرو می‌شود.
Error! Reference source not found
تست امنیت : با پیشرفت تجارت الکترونیک در فضای وب طراحی و تست سیستم های نرم افزاری برای اطمینان از ایمن و مطمئن بودن سیستم، مسأله ای اساسی است که توسعه دهندگان نرم افزار و متخصصان تست با آن مواجه هستند.
تست رگرسیون : بعد از تغییر نرم افزار ، حتی برای تغییر در عملکرد یا برای تصحیح یک خطا ، یک تست رگرسیون روی تمام تست هایی که قبلاً نرم افزار آنها را با موفقیت انجام داده اجرا می‌کند تا اطمینان حاصل کند که نرم افزار تصادفاً در عملکردهای قبلی دچار خطا نشده است. تست رگرسیون می‌تواند در هیچ یا همه سطوح قبلی صورت بگیرد.
از تست رگرسیون به عنوان یکی از گران قیمت‌ترین وظایف در میان فعالیت‌های نگهداری نرم افزار یاد می‌شود.[2] تست رگرسیون، به هر نوع از تست نرم افزار که به دنبال کشف خطاهای جدید نرم افزار باشد اطلاق می‌شود. رگرسیون‌ها در محیط‌های عملکردی و غیر عملکردی از یک سیستم بعد از اعمال تغییرات، از جمله تکامل، قطعه کدها یا تغییرات پیکربندی آنها ساخته شده است. همچنین از تست رگرسیون برای انجام اعتبار سنجی نرم افزارهای تغییر یافته استفاده می‌شود.
وجود خطا در نرم افزار و اجرای آن تاثیر منفی بر روی عملکرد و کارایی سیستم می‌گذارد. برای اینکه اثرات این خطرات را کاهش دهند مهندسان تست بر بکارگیری و اجرای تست رگرسیون تکیه می‌کنند. مهندسان تست در تست رگرسیون، موارد تست موجود در مجموعه تست را که قبلاَ هم بروی نرم افزار اجرا شده‌اند مجدداَ اجرا می‌کنند، همچنین موارد تست جدیدی را طراحی و ایجاد می‌کنند تا اینکه اطمینان حاصل شود که تمامی اثرات تغییرات در نظر گرفته شده و هیچ عوارض جانبی باقی نمانده است. تست رگرسیون تقریباَ به طور عمومی توسط نرم افزار سازمان بکار گرفته شده است[2].
تست رگرسیون را نه تنها برای آزمایش صحت از یک برنامه ، بلکه اغلب برای ردیابی با کیفیت بودن خروجی هم می‌توان استفاده کرد. برای مثال، در طراحی یک کامپایلر، تست رگرسیون می‌تواند اندازه کد، زمان شبیه سازی و زمان تلفیقی از موارد مجموعه تست را اندازه گیری کند. تست های رگرسیون را می‌توان به طور عمده به عنوان آزمون عملکردی یا آزمون واحد طبقه بندی کرد. آزمون عملکردی، عمل کردن برنامه کامل با ورودی‌های مختلف است. تست واحد، عمل کردن انفرادی زیر روال‌ها یا متدهای شیء. ابزارهای هر دو نوع تست عملکردی و تست واحد تمایل دارند به وجود بخش سوم محصولات که بخشی از مجموعه کامپایلر نیست، و هر دو تمایل دارند به خودکار سازی. یک تست عملکردی ممکن است یک سری اسکریپت از ورودی‌های برنامه، و حتی شامل یک مکانیزم خودکار برای کنترل حرکات ماوس و کلیک ها باشد. یک تست واحد ممکن است مجموعه ای از عملکردهای جداگانه در خود کد باشد. بعد از تغییر نرم افزار ، حتی برای تغییر در عملکرد یا برای تصحیح یک خطا یک تست رگرسیون روی تمام تست هایی که قبلاَ نرم افزار آنها را با موفقیت انجام داده اجرا می‌کنند تا اینکه اطمینان حاصل کنند نرم افزار تصادفاََ یا به طور اتفاقی در عملکردهای قبلی دچار خطا نشده است. تست رگرسیون را می‌توان در همه‌ی سطوح تست قبل یا هیچکدام از آنها مانند : تست بار، تست فشار، تست عملکرد بکار برد. از اینرو بکار گیری و اجرای تست گرسیون برای کیفیت نرم افزار مهم است، اما قابل ذکر است که می‌تواند گران و هزینه بر باشد. برای کم کردن هزینه‌های تست رگرسیون تکنیک هایی همچون کاهش مجموعه تست و اولویت بندی موارد تست نیز پیشنهاد شده‌اند که هر کدام را به طور مجزا شرح می‌دهیم.
1-4- آشنایی با شبکه‌های بیزیامروزه بسیاری از مشكلات انسان ها، با كمك هوش مصنوعی حل می‌شود. یكی از مهم‌ترین خصوصیات این مشكلات وجود عدم قطعیت در آنها است. روش‌های زیادی در هوش مصنوعی برای كنترل عدم قطعیت پیشنهاد شده‌اند كه اكثر آنها بر پایه نظریه احتمالات و نظریه فازی بنا نهاده شده‌اند. در این مطالعه می‌خواهیم یك روش برای کنترل عدم قطعیت در مسائل بر پایه نظریه احتمالات به نام شبكه‌های بیزیرا بررسی كنیم.[3]
1-4-1- مقدمه ای بر شبکه‌های بیزیمیدانیم که روش توزیع توام كامل می‌تواند هر درخواستی را جواب دهد، ولی می‌تواند به طور غیرقابل کنترلی بزرگ شود. همچنین می‌دانیم استقلال و یا استقلال شرطی بین متغیرها می‌تواند تعداد احتمالاتی كه برای محاسبه توزیع كامل لازم است، را به طور قابل توجهی كاهش دهد. در این قسمت به معرفی یك ساختمان داده به نام شبكه بیزی می ‌پردازیم كه نشان دهنده وابستگی‌های فرض شده بین متغیرها است و توزیع كامل با توجه به این فرض‌های وابستگی را به طور دقیق تعیین می‌كند. شبكه بیزی یك گراف جهت‌دار است كه رئوس آن شامل اطلاعات مقادیر احتمالات شرطی هستند.
به طور دقیق‌تر این شبکه شامل اجزا و خصوصیات زیر است:
1ـ یك مجموعه از متغیرهای تصادفی، مجموعه رئوس گراف را تشكیل می‌دهند كه این متغیرها می‌توانند گسسته یا پیوسته باشند.
2ـ یك مجموعه از یال‌های جهت‌دار كه اگر یك یال از راس به راس باشد، را والد می‌نامیم.
3ـ هر گره ، یك توزیع احتمال شرطی دارد كه تاثیر گره‌های والد بر روی این گره را به صورت عددی نشان می‌دهند.
4ـ گراف هیچ دور جهت‌داری ندارد و در واقع، یك گراف بدون دور جهت‌دار است.
ساختار شبكه نشان دهنده وابستگی‌های شرطی در قلمرو است. به صورت شهودی، معنی یك یال از به وجود تاثیر مستقیم بر و یا وابستگی مستقیم به است. باید توجه داشت که تعیین این وابستگی‌های مستقیم براییك فرد خبره قلمرو كار مشکلی نمی‌باشد و به همین دلیل معمولاً در صورت وجود فرد خبره تعیین ساختار شبکه آنچنان سخت نمی‌باشد. پس از تعیین ساختار، تعیین توزیع شرطی مربوط به گره‌ها، ساختمان داده شبكه بیزی را كامل می‌كند و با استفاده از آن می‌توان توزیع توام كامل را بدست آورد كه در ادامه توضیح داده خواهد شد.[3]
1-5- اندازه گیری و متریکزمانی شما می‌توانید اندازه گیری کنید چیزی را که در موردش صحبت می‌کنید و برای آن اعداد و ارقام بیان کنید که درخصوص آن دانش و اطلاعاتی داشته باشید، اما زمانیکه شما نمی توانید اندازه گیری کنید چیزی را و برای آن اعداد و ارقام بیان کنید، دانش شما از نوع ناچیز و غیر رضایتبخش است. دلیل اینکه ما به متریک ها نیاز داریم این است که شما نمی‌توانید بهبود دهید چیزی را که نمی‌توانید اندازه گیری کنید و همینطور شما نمی‌توانید کنترل کنید چیزی را که نتوانید اندازه گیری نمائید.
علاوه بر این متریک های تست کمک می‌کنند به شما در موارد زیر :[4]
تصمیم گیری برای مرحله بعدی فعالیت‌ها
بر اساس مدارک و شواهد ادعا و یا حتی پیش بینی کنید
تصمیم گیری در فرآیندها و یا تغییر فناوری
معیارهای زیادی در خوصوص کیفیت و بهره وری تست وجود دارد. متریک های تست بیشتر برای متریک های برنامه و پروژه‌ها در نظر گرفته می ‌شوند. نواقص در مراحل نیازمندی‌ها ، طراحی و فاز توسعه از پروژه نرم افزاری تزریق می‌ شوند. تست تلاش می ‌کند با توجه به افزایش درجه تزریق نقص کاهش دهد هزینه تعمیر و یا اصلاح نقص را و همچنین در مراحل بعدی از چرخه زندگی توسعه نرم افزار است. در تست باید به انجام برنامه ریزی برای به دام انداختن نقص پیش از آنکه محصول انتشار داده شود بپردازیم. 35 درصد از پروژه ‌های فناوری اطلاعات با موفقیت اجرا می‌شوند و به اتمام می‌رسند. برآورد تست انجام شده توسط دو نفر به احتمال زیاد با همدیگر متفاوتند. معیارهایی که در رویکردهای قبلی بکار گرفته شده‌اند عمدتاَ بر اساس داده‌های جمع آوری شده در طول تست های قبلی از نرم افزار و یا تفاوت بین نسخه‌های مختلف نرم افزار بوده است. این گونه عملکرد آنان باعث این شده که نتوان اینگونه رویکردها را در تست غیر رگرسیون بکار برد. زیرا در تست غیر رگرسیون، داده‌ها و اطلاعات اجراهای موارد تست های قبلی و اطلاعاتی از تغییر کد برنامه در دسترس نیست. در کنار روش‌های فوق الذکر رویکردهایی هم پیشنهاد شده‌اند که برای ترکیب اطلاعات چندگانه از جمله دانش کاربر و نیازمندی‌ها برای اولویت بندی موارد تست استفاده می‌کنند که این امر آنها را قادر می‌سازد به در نظر گرفتن شدت خطا از نقطه نظر ساختار برنامه. اما همچنان ممکن است خطاهای با تهدید جدی برای سیستم زود تشخیص داده نشوند. در این پایان نامه ما برای اولویت بندی شاخصی را ارائه می‌کنیم که در آن بر اساس چند معیار فرایند اولویت بندی صورت می‌گیرد. عواملی همچون احتمال ابتلا به خطا، اهمیت خطا، اثرگذاری خطا . از سیستم‌‏های پیشرفته سرگرمی‌‏های خانگی گرفته تا سیستم‌‏های پیچیده مالی و تجاری كه معاملات چند میلیاردی را در سراسر جهان سازماندهی‏ می‌‏كنند، همگی با نرم‌‏افزار سر و كار دارند، به عبارت دیگر نرم‌‏افزار بخش جذایی ناپذیری از فعالیت‌‏های انسان مدرن است. این میزان وابستگی انسان ها به محصولات نرم‌‏افزاری و استفاده این دستاورد بزرگ در دنیای الكترونیك تاثیر نارسایی‌‏های نرم‌‏افزاری را افزایش می‌‏دهد. امروزه تولید كنندگان و طراحان نرم‌‏افزار با طیف گسترده‌‏ای از مخاطبان روبرو هستند كه از آنها به عنوان كاربر یاد می‌‏شود. این كاربرها نمی‌‏توانند وجود نارسایی در محصولات نرم‌‏افزاری را تحمل كنند. در حالی كه شخصی كه دارای دانش تخصصی است و با ویژگی‌‏های نرم‌‏افزار آشنا است، نواقص و كاستی‌‏ها را پدیده‌‏ای عادی تلقی می‌‏كند. با وجود اینكه ریسك از دست دادن اعتماد مشتریان در نتیجه نارسایی‌‏های موجود در محصولات نرم‌‏افزاری در فضای كنونی فناوری افزایش یافته است، شركت‌‏هایی كه در حوزه طراحی نرم‌‏افزار فعالیت می‌‏كنند اساساً همان راه سنتی خود را می‌‏روند و به فکر تغییر در روش خود نیستند. فرایند كنونی حاكم در طراحی نرم‌‏افزار به گونه‌‏ای نیست كه با تضمین كیفیت محصول در راستای كاهش نارسایی‌‏ها و بهبود بخشیدن تجربه كاربر از آن عمل كند. از سوی دیگر؛ فشار فزاینده بازاریابی و تلاش شركت‌‏ها برای عرضه سریع‌‏تر محصول، مهندسان را مجبور می‌‏كند زمان كمتری را صرف طراحی محصول یا ارتقای نسخه‌‏های جدید آن كنند كه این امر خود شرایط را بدتر می‌‏كند. عوامل مذكور باعث می‌‏شود مجموعه‌‏ای از نارسایی‌‏ها در طراحی نرم‌‏افزار به وجود بیاید؛ هزینه‌‏های پشتیبانی پس از فروش افزایش یابد و سابقه بدی كه كیفیت پایین‌‏ نرم‌‏افزار بر جا می‌‏گذارد تشدید شود. پژوهش‌‏های دانشگاهی نشان می‌‏دهد كه تنها در سال ۲۰۰۲ ، صنعت فناوری رقم سرسام ‌‏آوری معادل ۶۰ میلیارد دلار را صرف تشخیص و ترمیم نارسایی‌‏های موجود در محصولات نرم‌‏افزاری كرده است. شمار زیادی از شركت‌‏ها در گزارش‌‏های خود گفته‌‏اند حدود ۵۰ درصد هزینه‌‏های طراحی نرم‌‏افزار را به تشخیص و ترمیم نارسایی‌‏های موجود در محصولات خود اختصاص می‌‏دهند. [4]بدیهی است كه وقت آن رسیده تغییراتی بنیادین در نحوه طراحی نرم‌‏افزارها ایجاد شود تا منابع با ارزش شركت‌‏ها صرف كار مجدد بر روی محصولاتی كه می‌‏توانست از اول با دقت بیشتری طراحی شود نگردد. آزمایش؛ مرحله‌‏ای كه در طراحی نرم‌‏افزار نادیده گرفته شده است. و یا اینکه آنگونه که باید به آن توجه نشده است و این عدم توجه کافی به آن سبب بروز مشکلات فوق گردیده است. نتایج یك نظرسنجی از مدیران ارشد فناوری شركت‌‏های فروشنده نرم‌‏افزار و مدیران فناوری اطلاعات شركت‌‏هایIT نشان می‌‏دهد بیشتر مدیران در این مورد اجماع دارند كه صنعت فناوری مساله تضمین كیفیت نرم‌‏افزار را نادیده گرفته و سرمایه‌‏گذاری در این زمینه كمتر از میزان بایسته است. 
این پدیده غالباً به صورت‌‏های زیر نمود می‌‏كند: 
شركت‌‏ها در برنامه خود یك مرحله آزمایش رسمی را در پایان چرخه طراحی نرم‌‏افزار می‌‏گنجانند. بیشتر آزمایش‌‏هایی كه قبل از این مرحله انجام می‌شود غیر رسمی و موقتی است و در آنها بسیار به جنبه‌‏های مهندسی توجه می‌‏شود تا شرایط و نیازهای كاربر. 
بعضی از آزمایش‌‏ها تا اواخر چرخه مهندسی نرم‌‏افزار كاملاً نادیده گرفته می‌‏شوند، آزمایش‌‏هایی كه غالباً نادیده گرفته می‌‏شوند از نوع جعبه سفید (آزمایش انطباق عملكرد بازدهی نرم افزار با توجه به ساختار درونی و كد دهی آن) و تست عملكرد هستند. این نادیده گرفتن و اهمال در آزمایش‌‏های لازم باعث بروز نارسایی در نرم‌‏افزار و مشكلات عملكردی در مواقعی می‌‏شود كه به تصور مهندسان در مرحله طراحی توجه لازم به آن شده است. 
نبود برنامه‌‏ریزی رسمی برای آزمایش نرم‌‏افزار، مشخص نبودن و ناهماهنگی روش‌‏ها و ابزار آزمایش نظیر نرم‌‏افزارهای موجود، خدمات حرفه‌‏ای كارشناسان تست نرم‌‏افزار و چهارچوب‌‏های آزمایش. 
نبود معیارهای رسمی سنجش كیفیت كه باعث كاهش كارایی تصمیم‌‏گیری‌‏های مدیریتی می‌‏شود.
تصور كنید شركت از یك طرف باید نرم‌‏افزار را به موقع در اختیار مشتری مهم خود قرار دهد و از طرف دیگر نیازمند سرمایه‌‏گذاری بیشتر بر روی آزمایش محصول خود است، حال آن كه اهداف كیفی مشخصی برای محصول خود ندارد. چنین شركتی تلاش می‌‏كند اعتبار خود را نزد مشتری از دست ندهد؛ اما عدم وجود معیارهای كیفی باعث می‌‏شود مدیران این شركت در تصمیم‌‏گیری‌‏های خود دچار ناتوانی و سرگردانی شوند. مهم‌ترین پیامد اجرای یك پروژه طراحی نرم‌‏افزار كه از كاستی‌‏های فوق رنج می‌‏برد این است که ‌تیم مهندسی اهداف كیفی را نمی‌‏شناسد و در راستای آنها عمل نمی ‌‏كند. این امر باعث می‌‏شود میزان سرمایه‌‏گذاری بر روی آزمایش محصول با اهداف كاربردی نرم‌‏افزار سازگار نباشد و ریسك توان نرم‌‏افزار در تامین نیازهای كاربر افزایش یابد.  سازمان هایی كه به كمك متخصصان تست نرم‌‏افزار فعالیت‌‏های خود را به بهترین وجه ممكن انجام می‌‏دهند برنامه‌‏های عمده طراحی نرم‌‏افزار را با صرف زمان برابر برای تعیین اهداف كیفی و كاربرد محصول خود آغاز می‌‏كنند. در این نوع برنامه‌‏ریزی در درجه اول مجموعه‌‏ای از معیارها مشخص می‌‏شود كه بخش‌‏های مهندسی، مدیریت محصول و مدیریت اجرایی می‌‏توانند از آنها برای نظارت بر پیشرفت كیفی نرم‌‏افزار در دست طراحی كمك بگیرند. این معیارها امكان كنترل نارسایی، اندازه‌‏گیری ریسك نارسایی‌‏ها، بسامد نارسایی‌‏ها، عملكرد و هزینه آزمایش را فراهم می‌‏كند. سپس، به عنوان بخشی از برنامه‌‏ریزی اولیه پروژه های تیم مهندسی توجه خود را روی جنبه‌‏های اساسی هماهنگ كردن مدیریت آزمایش و كیفیت نظیر برنامه تست واحد، برنامه تست عملكرد، قابلیت اتوماسیون تست، برنامه تست پس‌‏رفت، فرایندهای نظارت بر آزمایش و گزارش ‌‏دهی و فرایندهای مهندسی متمركز می‌‏كند تا نارسایی‌‏های شناسایی شده را برطرف كند. این برنامه‌‏ریزی و سازمان‌‏دهی فرایند آزمایش به مدیران و مهندسان این توان را می‌‏دهد كه در تعیین میزان سرمایه‌‏گذاری بر روی منابع آزمایش، نرم‌‏افزارهای لازم، خدمات حرفه‌‏ای كارشناسان آزمایش نرم‌‏افزار و زیرساخت با دانش و دقت بیشتری عمل كنند. یكی از جنبه‌‏های كیفیت نرم‌‏افزار كه غالباً نادیده گرفته می‌‏شود امكان ردیابی و پی‌‏گیری نرم‌‏افزار بعد از رسیدن به دست مشتری است. داشتن ارتباط مستقیم و پیوسته با مشتری می‌‏تواند به شركت در تشخیص و رفع سریع نواقص عملكردی محصول آن كمك كند. تیم‌‏های مهندسی كه بر روی كیفیت سرمایه‌‏گذاری می‌‏كنند باید بر روی سیستم‌‏های ردیابی محصول نیز سرمایه‌‏گذاری كافی انجام دهند. تا بتوانند با تحلیل و بررسی نواقص، عوامل اصلی تضعیف كننده و تقویت كننده كارایی نرم‌‏افزار را شناسایی كنند. ردیابی كارآمد به مهندسان اجازه می‌‏دهد با تشخیص به موقع از عوامل اصلی عملكرد خوب یا بد نرم‌‏افزار درس بگیرند. تیم مهندسی باید در تعیین سیستم مدیریت كیفیت چارچوب انعطاف‌‏پذیری را ایجاد كند تا با پیشرفت پروژه متناسب با شرایط در روش‌‏ها و معیارها تغییراتی ایجاد كند. سازمان هایی كه غالباً در اجرای پروژه‌‏های بزرگ نرم‌‏افزاری با كیفیت بالا موفق بوده‌‏اند آنهایی هستند كه برای درسی كه از نتایج پروژه می‌‏گیرند اهمیت خاصی داده‌‏اند. در پایان هر پروژه حقایقی آشكار می‌شود كه می‌‏تواند در افزایش كارآیی پروژه‌‏های آینده شركت تاثیر به سزایی داشته باشد. تیم مدیریت اجرایی اصولاً تلاش می‌‏كند با مرور نتایج پروژه قوانینی را برای فعالیت موفق‌‏آمیزتر در پروژه‌‏های آینده استخراج كند. 
1-6- بیان مسئلهاز مشکلات اساسی در مورد تست نرم افزار و اولویت بندی موارد تست به موارد زیر می‌توان اشاره کرد :
ما نمی‌توانیم همه چیز را تست کنیم
سیستم نمی‌تواند به طور کامل تست شود
زیاد بودن تعداد موارد تست برای اجرا بر روی برنامه تحت تست
محدود بودن زمان و هزینه برای انجام تست
1-7- چالش موجود در تست رگرسیونیکی از چالش‌های موجود در تست رگرسیون، زیاد بودن تعداد موارد تست است. زیرا تست رگرسیون از موارد تست موجود در مجموعه تست نیز به منظور اجرای مجدد آنها بروی نرم افزار استفاده می‌کند تا اینکه مطمئن شود خطاهای قبلی مجدداَ ظهور نمی‌کنند و یا اینکه نرم افزار به طور اتفاقی تست های انجام شده قبلی را با موفقیت پشت سر نگذاشته است. بیشتر تکنیک های اولویت بندی بر روی افزایش نرخ تشخیص خطا تمرکز کرده‌اند و در بهبود دادن آن تلاش و روش‌هایی را ارائه داده‌اند. که به صورت تجربی هم مفید بودن این تکنیک ها در افزایش تشخیص نرخ خطا در تست رگرسیون ثابت گردیده است. اما با این حال همه‌ی خطاها با شدت برابر در نظر گرفته می‌شوند بدلیل اینکه اکثر تکنیک های موجود بر روی اطلاعات بدست آمده از اجرای موارد تست قبلی یا تغییر کد منبع تکیه می‌کنند، تعداد کمی از تکنیک ها قادرند به طور مستقیم برای تست غیر رگرسیون استفاده شوند. برای اینکه بتوان از تکنیک پیشنهادی هم در تست رگرسیون و هم در تست غیر رگرسیون استفاده کنیم تکنیک اولویت بندی موارد تست بر اساس تجزیه و تحلیل ساختار برنامه پیشنهاد شده است. اما با این حال بایستی از تخمین زدن و پیش بینی کردن هم به همراه این تکنیک استفاده کرد تا اینکه زودتر از دیگر روش‌ها نتایج اولویت بندی را به مهندسان تست نشان دهد و عدم قطعیت را هم در تصمیمات لحاظ نماید، تا اینکه از اجرای موارد تست با اولویت پایین خودداری گردد و این امر سبب کاهش زمان مورد نیاز جهت انجام تست رگرسیون و صرفه جویی در منابع و زمان خواهد شد. برای رسیدن به این اهداف، برای اولویت دهی به موارد تست از شبکه‌های بیزی می‌توان استفاده کرد و چالش ذکر شده را رفع کرد.
1-8- راه حل برای چالش موجود در تست رگرسیونبرای رفع چالش ذکر شده ما پیشنهاد کر دیم مکانیزم اولویت بندی موارد تست را در تست رگرسیون با کمک شبکه‌های بیزی که در این مکانیزم که بر اساس تجزیه تحلیل ساختار برنامه انجام می‌گیرد معیارهایی نظیر شدت احتمال ابتلا به خطا و میزان اثر بخش بودن خطا در نظر گرفته می‌شود. موارد تست موجود در مجموعه تست که قبلاَ هم بر روی نرم افزار اجرا شده‌اند بایستی با توجه به چند معیار در اولویت بالاتری نسبت به بقیه قرار بگیرند. این معیارها عبارتند از محل‌هایی تغییر کد برنامه، محل‌هایی که در تست های قبلی خطا در آنها وجود داشته، در جاهایی که مقداری به تابع فراخوان برگردانده می‌شود، در حلقه‌های تکرار ، در دستورات شرطی می باشند. با استفاده از روش شبکه‌های بیزی اطلاعات موجود اولیه و دانش موجود در مستند سازی‌ها و احتمالات اولیه که از افراد خبره دریافت می‌گردد، تا ساختار و روابط علی بین متغییر ها استخراج گردد، تا در نهایت کارایی و کارآمدی اولویت بندی به حد مطلوب خود برسد و بتواند زمان انجام تست رگرسیون و هزینه‌های لازمه را از طریق محاسبات و معیارهای مدنظر به طور چشمگیری کاهش بدهد.
این تحقیق شامل پنج فصل است. فصل اول شامل تعاریف اولیه از تست نرم افزار و اهمیت موارد تست، ضرورت و اهداف تحقیق می‌باشد و در فصل دوم به شرح و بسط مفاهیم تست رگرسیون، شبکه‌های بیزی، اولویت دهی موارد تست و سیر تحولات رخ داده تا به امروز را بررسی می‌کنیم و یک پیشینه ای از آن ارائه می‌کنیم و سپس در فصل سوم رویکرد پیشنهادی خود را شرح می‌دهیم و بعد از آن در فصل چهارم نتایج و یافته‌های حاصل از محاسبات خود را ارائه می‌کنیم و در نهایت در فصل پنجم نتایج حاصل از محاسبات انجام شده را نشان می دهیم و سپس پیشنهاداتی را برای کارهای آینده بیان می‌کنیم.
1-9- توجیه ضرورت انجام طرحما در این پروژه با استفاده از شبکه‌های بیزی به انجام محاسبات متریک های اولویت بندی با در نظر گرفتن عدم قطعیت در آنها می‌پردازیم. شبکه‌های بیزی روابط علی بین متغیرها را به طور رسمی و فرمال نمایش می‌دهند که این خود مزیتی برای مدل پیشنهادی ما به شمار می‌آید. همچنین متخصصان حوزه تست با به ‌کارگیری این رویکرد و با مد نظر قرار دادن معیارهای دیگر و افزایش کیفیت فعالیت‌های تست در طول مرحله تست زمان بیشتری را برای رفع خطاهای شناسایی شده خواهند داشت.
1-10- هدف از اجراءارائه مدلی کارآمد برای اولویت بندی موارد تست که بتوان آنرا هم در تست رگرسیون و هم در تست غیر رگرسیون بکار گرفت. همچنین زمان و هزینه لازم برای تست را از طریق اولویت بندی کارآمد موارد تست با کمک مدل پیشنهادی مبتنی بر شبکه‌های بیزی کاهش داد. زیرا چالش موجود در تست رگرسیون زیاد بودن تعداد موارد تست است و اجرای تمامی آنها از بهره وری یا کارآمدی تست رگرسیون می‌کاهد. از اینرو ما قصد داریم تا با ارائه رویکردی که بتواند از داده‌های در دسترس و ساختار برنامه موجود بر اساس معیارهای مشخص شده در رویکرد پیشنهادی نتایج بهتری را در خصوص شناسایی تعداد خطای بیشتر و کاهش تعداد خطای باقیمانده ارائه کند.
1-11- نوآوری تحقیقنوآوری موجود در رویکرد پیشنهادی ما عبارتند از: 1- در نظر گرفتن ساختار برنامه در سطح ماژول که در روش‌های پیشنهادی قبل از این کار در سطح کلاس بوده است. 2– در نظر گرفتن متریک های اثرگذاری خطای ماژول بر دیگر ماژول‌ها به همراه داده‌های در دسترس دیگر(نیازمندی‌های کاربر، اجراهای قبلی موارد تست ها، داده‌های تاریخی، اطلاعات تغییرات برنامه و نظرات افراد خبره در حوزه تست نرم افزار ) می‌باشد. 3- استفاده از شبکه بیزی به کمک نظرات افراد خبره و داده‌های موجود برای انجام محاسبات می‌ باشد.
فصل دوم
ادبیات و پیشینه تحقیق
2-1- پیشینه تحقیق2-1-1- کارهای مرتبطدر این فصل، به زمینه‌های تحقیقاتی مربوط به موضوع این پایان نامه پرداخته شده است. برای بهبود فعالیت تست نرم افزار، محققان پیشنهاد کرده‌اند تکنیک های زیادی را جهت اولویت بندی موارد تست در سالهای اخیر. Wong و همکاران یک راه برای اولویت بندی موارد تست با توجه به معیار (افزایش هزینه بر پوشش اضافی) [5]. Rothermel و همکاران یک تعریف رسمی از مشکل اولویت بندی مورد تست و ارائه متریک هایی برای اندازهگیری نرخ تشخیص خطا از مجموعه تست ارائه کرده‌اند. نویسندگان APFD را به عنوان معیاری برای نرخ تشخیص خطا و ارزیابی تجربی در کاتالوگ خودشان معرفی می‌ کنند [6]. در مطالعات موردی بزرگ‌تر تکنیک ها با بیش از یک معیار ارزیابی می‌شوند. Kim و همکاران اولویت بندی موارد تست را تدوین و رابطه کردند بر اساس تئوری احتمال[7]. تکنیک های زیادی برای تست پیشنهاد شده‌اند مانند کاهش مجموعه تست [8] و اولویت بندی موارد تست [9] . مطالعات تجربی انجام شده نشان می‌دهند که ، بیشتر تکنیک های اولویت بندی موارد تست در بهبود نرخ تشخیص خطا در تست رگرسیون مفید و موثر هستند. استفاده از روش بهینه سازی اجتماع مورچگان یک راه جدید برای حل مشکل محدودیت زمان اولویت بندی است. در این رهکار ارائه شده، هدف اولویت بندی در تست رگرسیون برای دوباره مرتب کردن مجموعه تست در محیط محدود است. ممکن است تکنیک های آگاه به زمان برای اولویت بندی موارد تست، نرخ تشخیص خطای بهتری نسبت به روش‌های سنتی اولویت بندی موارد تست دست یابد. رویکرد جدیدی را برای آگاه به زمان اولویت بندی موارد تست با استفاده از برنامه نویسی خطی عدد صحیح را پیشنهاد می‌کند. اولویت بندی موارد تست به چالشی در سیستم های نرم افزاری مبتنی بر مولفه شده است (CBSS) که تسهیل می‌کند توسعه سیستم های پیچیده را با یکپارچه سازی اجزای قابل استفاده مجدد. CBSSبه عنوان یک رویکرد ظهور کرده که توسعه سریع سیستم را با استفاده از منابع و تلاش کمتر ارائه می‌کند. ایده اصلی استفاده مجدد و کاهش هزینه‌های توسعه را می‌توان به دست آورد از اجزای ارائه خدمات قابل اعتماد. بنابراین، ادغام اجزاء و آزمایش تبدیل شدن به یک مرحله مهم در CBSS. در هدف تجزیه و تحلیل روش های اولویت بندی موارد تست موجود مبتنی بر کد، بر اساس نیازمندی و تکنیک های اولویت بندی مبتنی بر مدل و در نهایت پیاده سازی آنها در CBSS است [10] .
در [27] اولویت بندی موارد تست نرم افزار براساس شبکه های بیزی برای تست رگرسیون ارائه گردیده است. در رویکرد پیشنهاد شده، اطلاعات تغییرات در نرم افزار ، کد برنامه و مجموعه تست رگرسیون ورودی های مدل پیشنهاد شده را تشکیل می دهند. در ضمن این رویکرد برای تست رگرسیون ارائه شده و برای استفاده در تست غیر رگرسیون نمی توان از این رویکرد بهره برد. در این روش پس از ارزیابی و محاسبه متریک احتمال ابتلا به خطا ، تجزیه و تحلیل تغییرات کد برنامه و بررسی پوشش موارد تست، شواهد لازم برای ساخت شبکه بیزی استخراج می شوند و بر اساس اطلاعات بدست آمده ساختار گراف ایجاد می گردد. پس از ایجاد گراف در شبکه بیزی، استنتاج احتمالات صورت می گیرد و موارد تست بر اساس آن اولویت بندی می شوند. برای مدل پیشنهادی که مورد مطالعه قرار گرفته است می توان این نکته را بیان کرد، اینکه مدل پیشنهادی با توجه به استفاده از شبکه بیزی دارای یک نقص می باشد و آن هم اینکه فقط برای تست رگرسیون می توان از آن استفاده کرد و برای تست غیر رگرسیون کاربرد ندارد.
در[31] اولویت بندی بر اساس تجزیه تحلیل ساختار برنامه برای تست رگرسیون و هم تست غیر رگرسیون ارائه شده است. مدل ارائه شده مشکل موجود در رویکرد ارائه شده در [27] را حل کرده است. اینگونه که مدل خود را در سطح ماژول ها ارائه کرده است و بر اساس ساختار برنامه به اولویت بندی کردن موارد تست می پردازد. در این روش با بکار گیری روش های فراخوانی گراف روابط بین ماژول ها را مشخص می کند و بعد از این مرحله معیارها و متریک هایی را برای وزن دهی به هر یک از متریک ها در نظر می گیرد. ورودی این مدل را ساختار برنامه و مجموعه تست تشکیل می دهند. در مدل پیشنهاد شده، از مجموعه تست برای سنجش اینکه موارد تست چه میزان از برنامه تحت تست را پوشش می دهند استفاده می شود. در نهایت اطلاعات حاصل از مرحله تجزیه و تحلیل پوشش موارد تست نرم افزار و محاسبه متریک ها، اطلاعات مورد نیاز جهت اولویت بندی موارد تست در خروجی بدست می آیند. از موارد مهمی که در این مدل بایستی بهبود داده شوند این موارد قابل ذکر می باشند. اول اینکه عدم قطعیت در این مدل نادیده گرفته شده است و بایستی در مدل حتماَ گنجانده شود. متریک های در نظر گرفته شده می تواند متعدد باشد و همچنین شدت خطاهای شناسایی شده باهم یکسان نمی باشند.
در [37] اثر محدودیت های زمانی در مورد اولویت بندی موارد تست مورد بررسی قرار گرفته است. ورودی های این مدل عبارتند از : داده های پوشش تست،اطلاعات تغییر کد ، داده های متریک کیفیت و مجموعه های تست. در این مدل از سه گروه از تکنیک های تست استفاده شده است. گروه های استفاده شده عبارتند از : تکنیک های کنترل ، تکنیک های بدون بازخورد و تکنیک های با مکانیزم بازخورد. از بین تمامی مجموعه های تست موجود نرخ شناسایی همگی محاسبه می گردد و مجموعه تست ای که نرخ شناسایی خطای در آن از بقیه بیشتر است انتخاب می گردد و سپس اطلاعات تشخیص خطای حاصل از آن به عنوان ورودی به مدل های هزینه – فایده داده می شود تا اینکه تعیین گردد در مواقعی که در محدودیت زمانی اجرا می شوند نرخ شناسایی خطای قابل قبولی را ارائه می کنند. نتایج حاصله از آزمایشات انجام گرفته در این تحقیق نشان دهنده این موضوع می باشد که استفاده از شبکه های بیزی در اولویت بندی موارد تست نتایج مطلوبی را بدست می دهند.در [39] ساخت مدل های شبکه بیزی از عدم قطعیت های موجود در تست و نگهداری نرم افزار صورت گرفته است. عدم قطعیت در مهندسی نرم افزار که بطور گسترده در تائید ، ارزیابی و پیش بینی دیده می شود. عدم قطعیت در مهندسی نرم افزار ذاتی و اجتناب ناپذیر است. عدم قطعیت در خصوص تجزیه تحلیل نیازمندی های کاربر هم یکی از بحث های مهم در حوزه مهندسی نرم افزار می باشد. در این روش از شبکه های بیزی باور الهام گرفته شده است و برای مدل کردن عدم قطعیت موجود در هر یک از فازهای مهندسی نرم افزار استفاده کرده است.

2-1-2- بررسی مشکلات موجود در روش‌های مطالعه شده قبلیکارهای مرتبط ذکر شده در بالا دارای نقاط ضعف و کمبودهایی هستند که در ادامه اشاره ای مختصر به آنها خواهیم داشت. اول اینکه روش‌های بالا همگی در بکارگیری اولویت بندی موارد تست در تست رگرسیون مشترک هستند. تمرکز بر افزایش نرخ تشخیص خطا یکی دیگر از مشترکات کارهای مرتبط می‌باشد. روش‌های مورد مطالعه برای ارائه مدلی که بتواند در تست غیر رگرسیون هم بکار گرفته شود راهکاری ندارند و برای مدل های خود در شروع فرآیند تست نیاز به یک سری موارد تست اجرا شده قبلی، اطلاعات از مستندات نوشته شده از مراحل قبل، تست های اجرا شده قبلی بر روی نرم افزار و تغییرات کد منبع دارند. از دیگر مشکلاتی که می‌توان ذکر کرد، در نظر گرفتن شدت مساوی برای خطاهای یافت شده است که این یک نقص محسوب می‌شود. با وجود موارد ضعف ذکر شده برای رویکردهای قبلی مورد مطالعه در حوزه تست نرم افزار، استفاده از یک مدل ریاضی و احتمالی میتواند بسیاری از ضعفها را پوشش دهد. راهکار پیشنهادی ما، استفاده از شبکههای بیزی میباشد که با تکیه بر متریک هایی که بر اساس تجزیه تحلیل ساختار برنامه انتخاب شده‌اند در اولویت بندی موارد تست بکار گرفته شوند. امروزه شبکههای بیزی به یک ابزار متداول برای مدلسازی مسئلههای مختلف آماری مبدل شده است. یکی از مهم‌ترین اهداف شبکههای بیزی اجتماع عدم قطعیت با سیستمهای خبره است[7]. با مدل سازی معیارهای تست نرمافزار به کمک شبکههای بیزی میتوان عدم قطعیت در برآورد متریکها و فاکتورهای تست را پوشش داد. ایده اصلی در مدل پیشنهادی جدید به ‌کارگیری شبکههای بیزی در مدلسازی معیارها و متریک های مهم برای اولویت بندی موارد تست است. به عبارتی در دیگر رویکردها معیارهای تست به صورت جداگانه مورد بررسی و مطالعه قرار گرفته‌اند. در این مدل به صورت یکجا و هرکدام با اولویت خاص خود که توسط متخصصان این حوزه به هر یک از متریک ها اختصاص می‌دهند مدل سازی شده‌اند. هدف اصلی استفاده از شبکههای بیزی در مدل پیشنهادی این است که بتوانیم عدم قطعیت را در برآورد متریکهای تست نرمافزار مدیریت نماییم و همچنین در تصمیم گیری و اولویت بندی لحاظ کنیم. برخی از تکنیک های اولویت بندی که تا کنون پیشنهاد شده فقط بروی تست رگرسیون قابل اجرا هستند و برخی قابلیت اجرا بر روی هر دو تست رگرسیون و غیر رگرسیون را دارند. ما در این تحقیق بر روی تکنیک های اولویت بندی موارد تست بر اساس تجزیه و تحلیل ساختار برنامه با کمک شبکه‌های بیزی تمرکز کرده‌ایم. به منظور بهبود مقرون به صرفه بودن فعالیت‌های تست ، تکنیک های تست همچون کاهش مجموعه تست و اولویت بندی موارد تست پیشنهاد شده‌اند. تکنیک کاهش مجموعه تست به منظور پیدا کردن موارد تست زائد و حذف آنها از مجموعه تست ارائه شده است. به طوری که مهندس تست می‌تواند با صرف کمترین زمان و منابع اجرای مجموعه تست را به حداقل برساند. اما هدف اصلی در اولویت بندی به غیر از حذف موارد تست زائد، دادن رتبه به اجرای موارد تست ها به جهت تشخیص خطاهای اولیه که ممکن می‌گردد است. تکنیک های اولویت بندی مزایایی را به دنبال دارند که عبارتند از: اول اینکه ، خطاهای بیشتری را تحت شرایط محدودیت منابع و زمان پیدا می‌کنند و در نتیجه قابلیت اطمینان سیستم را بهبود می‌بخشند. دوم اینکه، چون خطاها در ابتدا به نمایش در می‌آیند و تشخیص داده می‌شوند، مهندسان تست زمان بیشتری را خواهند داشت جهت رفع این خطاها و زمانبندی پروژه نرم افزاری خود جهت ارائه به بازار و این در نهایت به افزایش رضایت مشتری و کیفیت محصول منجر می‌شود.
– تست نرم افزار 2-2در طول فرآیند تولید نرم‌افزار، مهندس نرم‌افزار سعی می‌کند از یک سری مفاهیم مجرد و تحلیل نیازمندی‌ها به یک پیاده‌ سازی مشخص برسد. بعد از گام پیاده‌ سازی، مرحله تست و آزمایش نرم‌افزار یک سری نمونه‌های تست ساخته می‌شود که هدف از اعمال آنها روی نرم‌افزار ایجاد شرایطی است که تحت این شرایط نرم‌افزار درست کار نکند. در واقع فرآیند تست را می‌توان یک فرآیند مخرب دانست. تست نرم‌افزار نیاز دارد که درستی نرم‌افزار تولید شده را کاملاً نادیده گرفته، شرایطی را ایجاد کند تا خطاهای کشف نشده، پیدا شوند.
2-3- صحت و اعتبار سنجیآزمایش نرم افزار یك عنصر از عنوان گسترده تری است كه اغلب با صحت و اعتبار سنجی V&V شناخته می‌ شود. صحت اشاره به مجموعه فعالیت‌هایی دارد كه مطمئن می‌سازند نرم افزار به درستی یك تابع خاص را پیاده سازی می‌نماید. اعتبارسنجی اشاره به مجموعه ای متفاوت دارد كه مطمئن می ‌سازند نرم افزاری كه ایجاد شده منطبق بر نیازهای مشتری است. Boehm این مطلب را اینگونه بیان می ‌کند:
صحت: آیا محصول را درست ایجاد می ‌کنیم؟
اعتبارسنجی: آیا محصول درستی را ایجاد می ‌کنیم؟
تعریفV&V شامل بسیاری از فعالیت‌هایی است كه تضمین كیفیت نرم افزار نامیده می ‌شوند. صحت و اعتبارسنجی شامل گروه وسیعی از فعالیت‌های تضمین كیفیت نرم افزار می ‌باشد شامل : مرورهای فنی رسمی، بررسی كیفیت و پیكر بندی، نظارت بر كارایی، شبیه سازی، امكان سنجی، مرور مستندات، مرور بانك اطلاعاتی، تحلیل الگوریتم، آزمایش توسعه، آزمایش كیفی و آزمایش نصب . اگرچه آزمایش نقش بسیار مهمی را در V&Vدارد، بسیاری از فعالیت‌های دیگر نیز لازم می ‌باشند.[11]
2-4- اهداف آزمایشدرمورد آزمایش نرم افزار، Myers چند قانون زیر را بیان می ‌کند كه اهداف مناسبی برای آزمایش هستند:
آزمایش فرآیندی است شامل اجرای برنامه با هدف یافتن خطا.
یك نمونه آزمایش خوب، نمونه ای است كه با احتمال بالایی خطاها را بیابد.
آزمایش موفق، آزمایشی است كه خطاهای یافت نشده تاكنون را بیابد.
این اهداف تغییری دراماتیك را در دیدگاه ایجاد می ‌نمایند. این اهداف باعث تغییر دردیدگاه متداولی می‌شوند كه آزمایش موفق را آن نوع آزمایش می ‌داند كه در آن خطایی یافت نشود هدف، طراحی آزمایش‌هایی است كه به طور سیستماتیك رده‌های متفاوتی از خطاها را آشكار نمایند، و این عمل را با حداقل مقدار زمان و فعالیت انجام دهند.
2-5- اصول آزمایشقبل از بكار گیری روش‌های طراحی نمونه‌های مؤثر آزمایش، مهندس نرم افزار باید اصول اولیه ای را كه آزمایش نرم افزار را هدایت می ‌کنند بفهمد.
Davis مجموعه ای از اصول آزمایش را پیشنهاد می ‌کند که عبارتند از :
تمام آزمایش‌ها باید بر اساس نیازهای مشتری قابل پیگیری باشند.
آزمایش‌ها باید مدتی طولانی قبل از شروع آزمایش برنامه ریزی شوند.
اصل Pareto برای آزمایش نرم افزار بكار گرفته شود .
آزمایش باید با“توجه به اجزاء“شروع شود و به سمت آزمایش“كلی“پیش رود.
آزمایش كامل و جامع امكان پذیر نیست.
به منظور داشتن بیش‌ترین تأثیر، آزمایش باید توسط تیم مستقلی هدایت شود. [12]
2-6- قانون Pareto در فرآیند تست نرم افزار80 درصد از همه خطاهای کشف شده در طول فرآیند تست، احتمالاً در 20 درصد از روال‌های برنامه وجود دارند.بهتر است که این روال‌ها را شناخته و آنها را کاملاً تست کنیم.
تست باید از قطعات کوچک آغاز شود و به سمت تست قطعات بزرگ‌تر پیش رود.
تست های اولیه روی روال ‌های منفرد برنامه اعمال می‌شوند. در حالیکه فرآیند تست به پیش می‌رود، تمرکز روی پیدا کردن خطاها در مجموعه ‌های یکپارچه از پیمانه‌ها بوده، سپس به کل سیستم منتقل می‌شود.[13]
2-7- چند نمونه از انواع تستUnit Test: برای تست از پائین‌ترین نقطه شروع می‌کنیم.
(کوچک‌ترین واحدهای قابل تست Unit نامیده می‌شوند.)
Integration Test: واحدها را در کنار هم تست می‌کنیم.
Sys– Test: تستی که روی سیستم کلی (سخت‌افزار، نرم‌افزار، DB، شبکه و …) انجام می‌شود.
Requirement Test: آزمون نیازهای کاربر و مشتری
2-8- مراحل انجام تستمرحله‌ی تست آلفا: تست را در محیط آزمایشگاهی انجام می‌دهیم.
مرحله‌ی تست بتا: نرم افزار در محیط استفاده ‌کننده قرار می‌گیرد و تست می‌شود.
تست احراز اعتبار: تستی که نرم‌افزار به صورت رسمی منتشر می‌شود و آزمون نهایی روی آن انجام می‌شود.
تست جامع و کامل ممکن نیست. به خاطر زیاد بودن مسیرهای موجود در یک برنامه، اجرای همه آنها‌ و هر الحاقی از آنها با هم در طول فرآیند تست غیرممکن است. اما امکان انجام تستی که منطق برنامه را به اندازه کافی پوشش دهد و تمام شرایط طراحی رویه ای را در بر بگیرد، وجود دارد. برای بالا بردن کارایی، عمل تست باید توسط یک گروه مستقل انجام شود. تجربه نشان داده است که مهندس نرم‌افزاری که سیستم را ساخته است، فرد مناسبی برای پیشبرد تست نمی‌ باشد.
2-9- ویژگی‌های یک نرم‌افزار تست‌ پذیرOperability -1 : نرم‌افزار هرچه بهتر کار کند، کاراتر تست می‌شود.
سیستم خطاهای کمتری دارد.
هیچ خطایی، اجرای تست را متوقف نمی‌کند.
محصول در گام ‌های عملی مشخصی به تدریج تکمیل می‌شود.
Observability -2 : همان چیزی را تست کنید که می‌بینید.
برای هر ورودی یک خروجی معینی تولید می‌شود.
حالت‌های سیستم در طول اجرای آن قابل رویت هستند.
حالت‌های قبلی سیستم، در طول اجرای آن قابل رویت هستند.
همه عواملی که در خروجی تاثیر می‌گذارند، قابل رویت هستند.
خروجی‌های نادرست به آسانی قابل تشخیص هستند.
Controllability -3: هرچه بهتر بتوان نرم‌افزار را کنترل کرد، خودکارسازی و بهینه‌سازی تست بهتر انجام می‌شود.
همه خروجی‌های ممکن، توسط یک مجموعه معین از ورودی‌ها قابل تولید باشند.
همه کد، از طریق مجموعه معینی از ورودی‌ها قابل اجرا باشد.
حالات سخت‌افزار و نرم‌افزار، مستقیما َ توسط مهندس تست قابل



قیمت: 10000 تومان

متن کامل در سایت homatez.com

About: admin


دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *