پروژه تغییر IPv4 به IPv6 و تغییرات آن روی شبکه و فرق این دو باهم

پروژه پایانی  مقطع کارشناسی رشته کامپیوتر

یک پروتکل برای بررسی ادبیات سیستماتیک از روش برخورد با مشکل آزمون جهش (تحول)

۱-۱-مقدمه
آزمون یک روش کلیدی برای اطمینان از کیفیت نرم افزار می باشد. اما چگونه می توان در صورت پیدا کردن مجموعه تست به اندازه کافی تمام جنبه های با کیفیت را پوشش داد؟ برخی از راه حل های تعیین شده برای ارزیابی در صورتی که تعداد موارد آزمون کافی باشد وجود دارد، اما هنوز راه های کمتری برای ارزیابی کیفیت آزمون وجود دارد. آزمون جهش را می توان به عنوان یکی از آنها نام برد. آزمون جهش گسل اجتماعی را به یک نرم افزار (جهش) تبدیل کرده و چک می کند که آیا یک مجموعه آزمون می تواند این گسل را تشخیص دهد. اگر این گسل ها یافت نشود، مجموعه آزمون به عنوان کافی نبودن آزمون” در نظر گرفته شده است. همچنین جهش، بدون تغییر حفظ معناشناسی برنامه نمی تواند توسط هر مجموعه آزمون تشخیص داده شود. یک راه را انتخاب کنید، اما ممکن است راه انتخاب شده راه درستی نباشد، این جهش نیز به عنوان مشکل معادل جهش شناخته شده است. مشکل معادل جهش به طور فزاینده ای از آزمون جهش اول مورد مطالعه قرار گرفت و در سال ۱۹۷۱ توسط ریچارد لیپتون پیشنهاد شد رشد این رشته نیز در اواخر ۱۹۷۰s مورد توجه قرار گرفت، هنگامی که مقالات DeMillo و همکاران. هملت و باد و همکاران منتشر شد.

۱-۲-هدف SLR

هدف کلی از این مطالعه توسعه جدید است، که یک روش موثر برای غلبه بر مشکل معادل جهش یافته و یا به منظور ارتقاء روش های موجود است. برای انجام این کار، بررسی ادبیات نظام‌مند در زمینه مشکل جهش معادل، برای دانستن وضعیت فعلی دانش و به یک نقطه برای شروع خوب مورد نیاز است. اهداف زیر تعریفی برای دیدار با هدف است:

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

آزمون محوری توسعه مداوم (CTDD)-یک تمرین برای توسعه نرم افزار و پشتیبانی از ابزارها

۲-۱- مقدمه
در سال ۲۰۰۱ یک گروه از پیشتاران تفکر توسعه نرم افزار “یک بیانیه برای باشگاه توسعه نرم افزار” (بک و همکاران، ۲۰۰۱) را منتشر کردند. این ها مجموعه ای از ۱۲ اصل را پیشنهاد می کنند. این بدون دلیل نیست که اولین اصل از بیانیه باشگاه این است که بالاترین اولویت راضی مشتری است، در حالی راه نرم افزار برای رسیدن به آن است. این اصل در مرکز پژوهش ما است. ما در حال هدف قرار دادن مفهوم اولین برنامه آزمون هستیم، که توسط بک در برنامه نویسی (XP) کشف شده است (بک، ۱۹۹۹؛ بک و آندرس، ۲۰۰۴). یکی از مفاهیم توسعه  XP است که توسط آزمون هدایت می شود. از این مفهوم عمل آزمون محوری توسعه (TDD) به وجود می آید. پیشنهاد شده است که با استفاده از یک TDD می تواند پوشش بهتر به آزمون داد (Astels، ۲۰۰۳) و اعتماد به نفس برای توسعه آزمون (بک، ۲۰۰۲) بالاتر می رود. مطالعات تجربی توسط( Madeyski Madeyski، ۲۰۱۰a) نشان داد که TDD در تولید نرم افزار سست و بی پایه در مقایسه با آزمون های سنتی آخرین نرم افزار توسعه بهتر است.
در این مقاله ما TDD را ، به نام آزمون محوری توسعه مداوم (CTDD) گسترش می دهیم، که در آن ما TDD را با آزمون مداوم ترکیب می کنیم (صف و ارنست، ۲۰۰۳) حل این مشکل از زمان آزمون در حال اجرا در طول توسعه ارائه شده است. علاوه بر این، ما وضعیت فعلی از ابزار اطراف تست مداوم را نشان می دهیم و در حال حاضر از ابزار به طور تجربی برای بررسی عمل( CTDD)  AutoTest NET4CTDD استفاده می کنیم ، یک منبع باز مداوم برای استودیو مایکروسافت ویژوال در مجتمع توسعه محیط زیست (IDE) آزمایش می شود، که باعث می شود ما یک مطالعه تجربی در محیط های صنعتی در پروژه توسعه نرم افزار تجاری انجام دهیم. ما همچنین یک ارزیابی اولیه (پیش آزمون) از ابزار AutoTest.NET4CTDD با استفاده از یک نظرسنجی با الهام از مدل فناوری پذیرش (TAM) انجام می دهیم (دیویس، ۱۹۸۹؛ Venkatesh و دیویس، ۲۰۰۰). این نظر سنجی با یک تیم از مهندسین نرم افزار های حرفه ای از شرکت توسعه نرم افزار واقع در لهستان انجام شد.