متن کامل پایان نامه را در سایت منبع fuka.ir می توانید ببینید متن کامل پایان نامه را در سایت منبع 2 fuka.ir می توانید ببینید

*8

متن کامل پایان نامه را در سایت منبع fuka.ir می توانید ببینید

تشکر و سپاس
سپاس و ستایش مر خدای را جل و جلاله که آثار قدرت او بر چهره روز روشن، تابان است و انوار حکمت او در دل شب تار، درفشان. آفریدگاری که خویشتن را به ما شناساند و درهای علم را بر ما گشود و عمری و فرصتی عطا فرمود تا بدان، بنده ضعیف خویش را در طریق علم و معرفت بیازماید.
و تشکر از اساتید گرامی جناب آقای دکتر شیرازی و جناب آقای دکتر موتمنی که با راهنماییهایی خود من را در این راه پر پیچ و خم یاری کردند.
و تقدیم به خانوادهام که با صبر و شکیبایی در این مدت من را یاری کردند و با حمایتهای بی دریغشان تحمل دشواریهای این راه را برایم آسان کردند.
چکیدهایده ی اصلی تست جهش براساس استفاده از نقصها (faults) برای شبیه سازی خطاهایی است که برنامه نویسان انجام میدهند. بروز نقصها ممکن است در دو سطح یکپارچگی و در سطح واحد اتفاق بیافتد که در بعضی موارد ممکن است جستجو و یافتن محل نقص دشوار باشد با تزریق نقصها به صورت مجازی میتوان دادهها ورودی مناسب که میتواند وجود آنها را آشکار کند پیدا کرد.
انجام فرآیند تست جهش هزینه بر است این هزینهها به طور کلی از چهار منبع نشات میگیرند که عبارتند از :1- تولید ورودیهای تست 2- زمان کامپایل کد جهش یافته و کد اصلی 3- اجرا کد جهش یافته و اصلی 4- مقایسهی نتایج خروجی برنامهی اصلی با برنامهی جهش یافته. در این پایاننامه برای کاهش هزینهی اول با استفاده از الگوریتم کلونی زنبور تولید دادههای تست را به صورت خودکار انجام دادیم از طرف دیگر از طریق تکنیکهای تزریق بایت کد جاوا هزینه کامپایل را نیز به صفر رساندیم و برای بالا بردن عملکرد سیستم اجرای تست را به صورت موازی انجام دادهایم.
کلید واژه: تست جهش، خودکارسازی، ورودیهای تست، موارد تست، الگوریتم کلونی زنبور.
فهرست مطالبعنوانصفحه
TOC o “1-3” h z u 1فصل اول مقدمه و کلیات تحقیق PAGEREF _Toc386406899 h 11-1مروری بر دغدغههای تست نرمافزار PAGEREF _Toc386406900 h 21-1-1مقدمه PAGEREF _Toc386406901 h 21-1-2بهره گیری از طبیعت PAGEREF _Toc386406902 h 41-1-3هدف از انجام PAGEREF _Toc386406903 h 62فصل دوم ادبیات و پیشینه تحقیق PAGEREF _Toc386406904 h 82-1تست جهش PAGEREF _Toc386406905 h 92-1-1تئوری و نظریات PAGEREF _Toc386406906 h 92-1-2متدلوژی PAGEREF _Toc386406907 h 122-1-3عملگرها PAGEREF _Toc386406908 h 142-1-4تکینکهای کاهش هزینه PAGEREF _Toc386406909 h 202-1-5تولید جهش کمتر PAGEREF _Toc386406910 h 212-1-6تکنیکهای کاهش هزینه در زمان اجرای برنامه PAGEREF _Toc386406911 h 292-1-7جهشهای برابر PAGEREF _Toc386406912 h 382-1-8خودکار سازی تست PAGEREF _Toc386406913 h 432-2نتیجهگیری PAGEREF _Toc386406914 h 473فصل سوم روش تحقیق PAGEREF _Toc386406915 h 503-1شرح روشهای مشابه PAGEREF _Toc386406916 h 513-1-1روش مبتنی بر CBT PAGEREF _Toc386406917 h 513-1-2روش اجرای سمبلیک PAGEREF _Toc386406918 h 523-1-3ترکیب روش اجرای پویای سمبلیک (DSE) با اسکیما PAGEREF _Toc386406919 h 573-1-4روشهای مبتنی بر جستجو PAGEREF _Toc386406920 h 593-2شرح ابزار ارائه شده PAGEREF _Toc386406921 h 603-2-1ابزارهای ارائه شدهی مبتنی بر جاوا PAGEREF _Toc386406922 h 603-2-2تولید کنندهی جهشها PAGEREF _Toc386406923 h 633-2-3تولید کنندهی ورودیهای تست PAGEREF _Toc386406924 h 663-2-4الگوریتم کلونی زنبور PAGEREF _Toc386406925 h 673-2-5کلاس تولید کنندهی موارد تست PAGEREF _Toc386406926 h 693-2-6اجرا کنندهی تست PAGEREF _Toc386406927 h 773-2-7دستیاران PAGEREF _Toc386406928 h 783-3نتیجهگیری PAGEREF _Toc386406929 h 824فصل چهارم PAGEREF _Toc386406930 h 84محاسبات و یافته های تحقیق PAGEREF _Toc386406931 h 844-1تاثیر تعداد نخها در از بین رفتن جهشها PAGEREF _Toc386406932 h 854-2بررسی اثر تعداد نخها در معیار پوشش PAGEREF _Toc386406933 h 864-3نتایج بدست آمده از تست سه برنامه PAGEREF _Toc386406934 h 885فصل پنجم نتیجه گیری و پیشنهادات PAGEREF _Toc386406935 h 916پیوست PAGEREF _Toc386406936 h 946-1الگوریتم کلونی مورچه PAGEREF _Toc386406937 h 946-2K-means PAGEREF _Toc386406938 h 986-3Agglomerative PAGEREF _Toc386406939 h 986-4منابع PAGEREF _Toc386406940 h 99
فهرست جداول TOC h z c “جدول” جدول(‏21): 22 عملگر مُدرا [9] PAGEREF _Toc386406941 h 14جدول(‏22): عملگرهای جهش ارائه شده در سطح بین کلاس [10] PAGEREF _Toc386406942 h 18جدول(‏23): سه جهش M2,M1 وM3 [15] PAGEREF _Toc386406943 h 24جدول (‏24): : فاصلهی همینگ سه جهش M2,M1 وM3 [15] PAGEREF _Toc386406944 h 24جدول(‏25): خلاصهی نتایج بدست آمده حاصل از اجرای روش دستهبندی بر روی پنج برنامه [15] PAGEREF _Toc386406945 h 25جدول(‏26): تاثیر حاصل ترکیب جهش های برابر و نابرابر با یکدیگر PAGEREF _Toc386406946 h 28جدول(‏27): محدودیتهای تولید شدهی متناظر با جهشها [29] PAGEREF _Toc386406947 h 41جدول(‏28): مقایسه بین روشهای مختلف PAGEREF _Toc386406948 h 47جدول(‏31): نمونهای از مسیرها و محدودیتهای انها در اجرای سمبلیک PAGEREF _Toc386406949 h 54جدول(‏32): بررسی حالات مختلف برای محاسبهی شایستگی PAGEREF _Toc386406950 h 72جدول(41): نتایج بدست آمده از تست سه برنامه PAGEREF _Toc386406951 h 88جدول(‏42):مقایسهی روش ارائه شده با سایر ابزارها PAGEREF _Toc386406952 h 89
فهرست تصاویر و نمودارها TOC h z c “شکل” شکل(‏21): چارت فرآیند تست جهش PAGEREF _Toc386406953 h 13شکل(‏22): درصد استفادهی مقالات از تکنیکهای کاهش هزینه [2] PAGEREF _Toc386406954 h 21شکل(‏23): چهار متغییر مقایسهی جهش ضعیف [23] PAGEREF _Toc386406955 h 32شکل (‏24):گراف کنترل جریان برنامهی MID [30] PAGEREF _Toc386406956 h 36شکل (‏25): نمایش دامنه قبل و بعد از تقسیم [30] PAGEREF _Toc386406957 h 36شکل (‏26): فرآیند MSG [31] PAGEREF _Toc386406958 h 38شکل (‏27): ارتباط دامنهی ورودی سه شرط کفایت، ضرورت و دسترسی [29] [34] PAGEREF _Toc386406959 h 43شکل (‏31): ساختار Godzilla PAGEREF _Toc386406960 h 51شکل(‏32): نمونهای از اجرای سمبلیک PAGEREF _Toc386406961 h 54شکل(‏33): چهارچوب ارائه شده در مقالهی [40] PAGEREF _Toc386406962 h 58شکل(‏34): کلونی مورچه و تست جهش PAGEREF _Toc386406963 h 59شکل(‏35): ماژول تولید کنندهی جهش PAGEREF _Toc386406964 h 66شکل (‏36): ماژول تولید کنندهی ورودیهای تست PAGEREF _Toc386406965 h 76شکل(‏37): گراف کنترل جریان برنامه تشخیص نوع مثلث PAGEREF _Toc386406966 h 81شکل(‏38): مدل روش ارائه شده PAGEREF _Toc386406967 h 83شکل(41): اثر تعداد نخها در از بین بردن جهش PAGEREF _Toc386406968 h 86شکل (42) پوشش مسیرهای تست در گراف CFG PAGEREF _Toc386406969 h 87شکل(43): اثر تعداد نخها بر پوشش مسیرهای تست در گراف CFG PAGEREF _Toc386406970 h 87شکل(‏61): شیوه حرکت مورچهگان در هنگام برخورد با مانع PAGEREF _Toc386406971 h 95شکل (‏62) : گراف شهرها و مسیرها PAGEREF _Toc386406972 h 96
فصل اول مقدمه و کلیات تحقیقمروری بر دغدغههای تست نرمافزارمقدمه
یکی از چالشهای امروز پروژههای نرمافزار، تست است زیرا برخلاف محصولات تولید شده توسط سایر علوم مهندسی، نرمافزار محصولی غیرقابل لمس است از این جهت برای اطمینان از کیفیت، نیاز به صرف هزینه و وقت بیشتر برای تست آن است. تست در حقیقت یکی از اساسیترین روشها برای ارزیابی نرمافزار تحت توسعه است. روشهای سنتی تست نرمافزار، تنها به یافتن بعضی از خطاها بعد از فاز پیادهسازی محدود میشد و از این جهت ریسک وجود خطا در نرمافزار، بعد از تحویل، افزایش می یافت و حتی وجود خطاها در نرمافزار گاهی موجب شکست نرمافزار میشود اما منشاء بخشی از این خطاها در کجاست؟ منشاء بخشی از این خطاها در نقصهایی است که برنامه نویسان به طور غیر عمدی و بر اثر بی دقتی وارد کد برنامه میکنند مانند: کوچکتر از حد نیاز در نظر گرفتن طول یک آرایه، اشتباه در پرانتز گذاری عبارتها، استفادهی نادرست از عملگرهای دودویی و یکانی و … که در صورت شناسایی محل آن در بسیاری از موارد با ایجاد یک تغییر کوچک در کد برنامه قابل اصلاح است اما در صورت عدم اصلاح وجود یک یا چند نقص در برنامه سبب ایجاد یک وضعیت درونی اشتباه در برنامه شود که در برخی از موارد با وارد کردن یک ورودی خاص تحریک شده و ممکن است این وضعیت درونی به یک رفتار بیرونی اشتباه تبدیل شود و حتی در برخی از موارد موجب شکست برنامه شود به عنوان مثال اگر بدن انسان را به یک برنامهی کامپیوتری تشبیه کنیم نقصها در حقیقت عوامل بیماری زا هستند که در یک بدن سالم وارد میشوند و آن را تحت تصرف خود درمیآورند، خطاها مانند یک وضعیت درونی غیر عادی در بدن مانند فشار خون بالا، وجود یک نوع باکتری در خون، بی نظمی در نبض بیمار که پزشکان با کنارهم قرار دادن این علائم تلاش میکنند به علت بیماری پی ببرند، از کار افتادگیها در حقیقت علائم درونی هستند که از حالت نهان و درونی خود خارج شده به طوری که توسط بیمار نیز قابل تشخیص و بیان هستند.
حال که توانستیم مفهوم نقص، خطا و شکست را شرح دهیم، میتوانیم میان سه مفهوم تست، تست شکست و اشکال زدایی، تمایز قائل شویم وآن عبارت است از:
تست: ارزیابی نرمافزار با استفاده از مشاهده و بررسی آن در هنگام اجرا.
تست شکست: اجرای برنامه که منجر به شکست آن میشود.
اشکال زدایی: فرآیندی که با توجه به شکستها محل نقصهای مربوطه را پیدا میکند.
یکی از چالشهای عمده در این بخش یافتن نقصهای برنامه است زیرا به ازای هر نقص تعداد محدودی از ورودیها خروجی برنامه را تغییر میدهند بنابراین پیدا کردن محل نقص همواره کار سادهای نیست با در نظر گرفتن این ایده به سه شرط اساسی میرسیم که وجود آنها برای تبدیل یک نقص به یک شکست ضروری است:
دسترسی: محلهایی از برنامه که در آنها نقص وجود دارند باید قابل دسترسی باشد به عبارت دیگر نقص در محل کد مرده واقع نشده باشد.
آلودگی: بعد از اجرای محل نقصدار، برنامه در یک وضعیت اشتباه قرار گیرد.
انتشار: آلودگی ایجاد شده از طریق اجرای بخش نقص دار باید در قسمتهای مختلف برنامه انتشار پیدا کند تا آنجا که خروجی برنامه تغییر کند و آن را نادرست کند.
همانطور که در علم پزشکی پیشگیری بهتر از درمان است، برای جلوگیری از شکست برنامه بهتر است با استفاده از روشهای موجود تا آنجایی که امکان دارد از ورود نقصها به کد برنامه جلوگیری کنیم. این موضوع اولین بار توسط Myers طرح شد، وی مدعی شد تست نرمافزار موفق، تستیاست که سبب از کار افتادگی نرمافزار شود به عبارت دیگر دیدگاه Myers استفاده از نقصهای شناخته شده جهت یافتن خطاهای پنهان موجود در برنامه بود به این روش تست، تست نقص میگویند. در این روش به جای آنکه به دنبال خطا در برنامه برویم نشان می دهیم که برنامه بدون نقص است.
بهره گیری از طبیعت
پدیدههای طبیعی از گذشته همواره مورد توجه و الهام بخش انسان برای حل مسائل زندگی خود بوده است، یکی از جالبترین آنها اجتماع زنبوران و مورچهها است که برای حل مسائل خود (به عنوان مثال پیدا کار کردن غذا ) از راهکارهای سادهای استفاده میکنند که نه تنها قادر به حل مسائل خود هستند بلکه ما میتوانیم با مشاهده و الگو برداری از رفتار آنها بسیاری از مسائل پیچیدهای که نیاز به راه حلهای پویا دارند را به طور کارا حل کنیم، اما این الگوهای پیچیدهی رفتاری از کجا ایجاد میشود؟ پاسخ این سوال استفاده از هوش جمعی است، به عنوان مثال تصور کنید قرار است به محلی بروید که از آدرس آن به طور کامل آگاهی ندارید. یکی از راهکارهای موثر پرسش از کسانی است که در راه با آنها برخورد میکنید در برخی از موارد ممکن است پاسخهای نادرست دریافت کنید اما شما با توجه به پیش زمینه ذهنی و هدف از پیش تعریف شدهی خود تا حدی قادر به تشخیص آنها خواهید بود. در حقیقت شما ممکن است در کارهای روزمره خود بارها از هوش جمعی برای یافتن پاسخ مشکلات خود بهرهمند شوید. متاسفانه تاکنون تعریف دقیق ریاضی برای هوش جمعی وجود ندارد اما به طور کلی سیستمهایی که براساس هوش جمعی مسائل خود را حل میکنند در ویژگیهای زیر مشترک هستند:
توانایی حل مسائل پیچیده
توانایی حل مسائل به صورت توزیع شده
کار در محیط پویا
عدم نیاز به هر گونه کمک از محیط بیرون در هنگام حل مسائل
و بدون نیاز به سیستم کنترلی(مدیریت درونی)
اگر به زندگی مورچهها نگاه کنیم، برای حل مسائل خود از چندین روش استفاده میکنند که یکی از مهمترین آنها مادهی شیمیایی به نام فرمون است و از خواص این ماده بوی آن است که بعد از گذشت زمان از شدت آن کاسته شده و به تدریج از بین میرود. اما این ویژگی چه کمکی به حل مسائل مورچهها میکند؟ به عنوان مثال مسئلهی یافتن کوتاه ترین مسیر را در نظر بگیرید در حقیقت مورچهها با گذشت زمان یاد گرفتهاند که برای یافتن غذا همواره کوتاهترین مسیر را از کلونی تا غذای خود پیدا کنند. هنگامی که اولین مورچه برای یافتن غذا خارج میشود یک مسیر را از میان چندین مسیر به صورت تصادفی انتخاب میکند. هر مورچه در مسیری که طی میکند از خود فرمون به جای میگذارد وبعد از یافتن غذا از مسیر پیموده شدهی خود که برروی آن فرمون به جای گذاشته است به کلونی باز میگردد. از آنجایی که تعداد مورچههای زیادی به طور همزمان برای یافتن غذا از کلونی خارج میشوند نخستین مورچهای که به کلونی باز میگردد به احتمال زیاد مسیر کوتاهتری به نسبت سایر مورچهها پیموده است و بوی فرمون آن ماندگاری بیشتری دارد چون در مدت زمان کمتری طی شده است پس آن مسیر توسط سایر مورچهها انتخاب خواهد شد.
هدف از انجامعلیرغم اینکه تست نرمافزار یکی از مهمترین مراحل توسعهی نرمافزار است اما در کشور ما در حد اهمیتش به آن پرداخته نمیشود و تنها عنوانهای تحقیقاتی به چند مورد خاص در شبکه محدود میشود از طرف دیگر اغلب مهندسان نرمافزار به دلیل عدم آگاهی و یا هزینهی عملیات تست آن را تنها در سطح یک دیباگ ساده انجام میدهند در حالیکه تست نرمافزار از سطوح مختلفی تشکیل شده که پایینترین سطح آن دیباگ است ADDIN EN.CITE <EndNote><Cite><Author>Ammann</Author><Year>2008</Year><RecNum>10</RecNum><DisplayText>[1]</DisplayText><record><rec-number>10</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>10</key></foreign-keys><ref-type name=”Book”>6</ref-type><contributors><authors><author>Ammann, P.</author><author>Offutt, J.</author></authors></contributors><titles><title>Introduction to software testing</title></titles><dates><year>2008</year></dates><publisher>Cambridge University Press</publisher><isbn>0521880386</isbn><urls></urls></record></Cite></EndNote>[1]. از مشکلات دیگر این حوزه عدم شفافیت در بیان اطلاعات و در دسترس نبودن ابزارهای ارائه شده است بطوریکه از نه عنوان مطرح شده در ADDIN EN.CITE <EndNote><Cite><Author>Jia</Author><Year>2011</Year><RecNum>46</RecNum><DisplayText>[2]</DisplayText><record><rec-number>46</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>46</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Jia, Yue</author><author>Harman, Mark</author></authors></contributors><titles><title>An analysis and survey of the development of mutation testing</title><secondary-title>Software Engineering, IEEE Transactions on</secondary-title></titles><periodical><full-title>Software Engineering, IEEE Transactions on</full-title></periodical><pages>649-678</pages><volume>37</volume><number>5</number><dates><year>2011</year></dates><isbn>0098-5589</isbn><urls></urls></record></Cite></EndNote>[2] که با زبان جاوا کار میکنند کمتر از نیمی به صورت کد منبع باز در دسترس هستند. در این پایاننامه همت خود را بر آن گذاشتیم که تا حد امکان از این موضوع پنهان مانده برای مهندسین نرمافزار ایرانی پرده برداری کنیم تا موجب آشنایی بیشتر جامعهی علمی و افزایش عنوانهای تحقیقاتی در این زمینه شود. برای نیل به این هدف تمامی مقالات ذکر شده در این پایاننامه با ذکر مثال، رابطههای مربوطه و با شرح بیشتر آورده شده است و سعی شده تا جایی که امکان دارد به شکلی ساده بیان شود. از طرف دیگر با پیادهسازی یک ابزار و در دسترس قرار دادن آن در راه رسیدن به هدف خود که آشنایی بیشتر جامعهی مهندسان ایرانی با تست نرمافزار است گام دوم را برداشتهایم. امید است با پیوستگی گامهای کوچک به این هدف بزرگ دست یابیم.
ترتیب فصول این پایاننامه بدین شرح است در فصل دوم به شرح مختصری از تاریخچهی تست به خصوص تاریخچهی تست جهش خواهیم پرداخت در فصل سوم به شرح روشهای ممکن برای پیادهسازی یک ابزار تست و روش پیاده سازی شده در این پایاننامه خواهیم پرداخت، در فصل چهارم یافتههای این تحقیق را در قالب نمودار نشان میدهیم و در فصل پنجم نتیجهگیری خواهیم داشت.
فصل دومادبیات و پیشینه تحقیقتست جهشتئوری و نظریات
یافتن خطاها در نرمافزار از گذشته همواره یکی از اصلی ترین دغدغههای توسعه دهندگان نرمافزار بوده است و تاکنون روشهایی برای تست نرمافزار عرضه شده است اما چگونه میتوان دریافت که تستی موفق بوده یا نه؟ آیا نبود خطا در کد برنامه، نشانهی موفقیت تست است یا شکست آن؟ در حقیقت، ممکن است تستی در کد برنامه خطایی را پیدا نکند به دلیل آنکه توانایی شناسایی خطا را در کد برنامه (که ممکن است ناشی از عدم دسترسی به کد خطا باشد) نداشته باشد یکی از روشهای مناسب برای پاسخ به سوالات بالا استفاده از دادههای تست مناسب است بطوریکه بتواند بیشتر انشعابات برنامه را پوشش دهد و به تست کننده این اطمینان را بدهد که در صورت وجود نقص در برنامه میتواند آن را شناسایی کند. اما چگونه میتوان دادههای مناسب را تولید کرد؟ یکی از راه حلهای مناسب شبیه سازی، عمل تست است. به عبارت دیگر میتوانیم با قرار دادن نقصها در کد برنامه به طور مصنوعی که در اصطلاح جهش نامیده میشوند یک برنامهی نقصدار ایجاد کنیم، با این کار میتوانیم از نقصدار بودن برنامه خود اطمینان حاصل کنیم و دادههای تست ورودی را به خوبی ارزیابی کنیم. ایدهی تست جهش، برای اولین بار در یک مقالهی دانشجویی به نام R.lipton ADDIN EN.CITE <EndNote><Cite><Author>Lipton</Author><Year>1971</Year><RecNum>35</RecNum><DisplayText>[3]</DisplayText><record><rec-number>35</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>35</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Lipton, R</author></authors></contributors><titles><title>Fault diagnosis of computer programs</title><secondary-title>Student Report, Carnegie Mellon University</secondary-title></titles><periodical><full-title>Student Report, Carnegie Mellon University</full-title></periodical><dates><year>1971</year></dates><urls></urls></record></Cite></EndNote>[3] سال 1971 مطرح شد اما زیر بنای تست جهش، در دههی 70 با کارهای G. J. Myers ADDIN EN.CITE <EndNote><Cite><Author>DeMillo</Author><Year>1978</Year><RecNum>42</RecNum><DisplayText>[4]</DisplayText><record><rec-number>42</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>42</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>DeMillo, Richard A</author><author>Lipton, Richard J</author><author>Sayward, Frederick G</author></authors></contributors><titles><title>Hints on test data selection: Help for the practicing programmer</title><secondary-title>Computer</secondary-title></titles><periodical><full-title>Computer</full-title></periodical><pages>34-41</pages><volume>11</volume><number>4</number><dates><year>1978</year></dates><isbn>0018-9162</isbn><urls></urls></record></Cite></EndNote>[4] و R. G. Hamlet ADDIN EN.CITE <EndNote><Cite><Author>Hamlet</Author><Year>1977</Year><RecNum>43</RecNum><DisplayText>[5]</DisplayText><record><rec-number>43</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>43</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Hamlet, Richard G.</author></authors></contributors><titles><title>Testing programs with the aid of a compiler</title><secondary-title>Software Engineering, IEEE Transactions on</secondary-title></titles><periodical><full-title>Software Engineering, IEEE Transactions on</full-title></periodical><pages>279-290</pages><number>4</number><dates><year>1977</year></dates><isbn>0098-5589</isbn><urls></urls></record></Cite></EndNote>[5] شکل گرفت. ایدهی اصلی تست جهش استفاده از نقص ها، برای تولید دادههای مناسب و شایسته برای تست نرمافزار است که به طور کلی براساس دو فرضیه استوار است:
برنامه نویسان لایق: از آنجا که برنامه نویسان، ماشین نیستند برنامهای تولید میکنند که نزدیک به برنامهی صحیح است. به عبارت دیگر برنامهی تولید شده ممکن است حاوی نقصهایی باشد که برنامه نویسان، ناخواسته در کد آن، وارد کردهاند. البته در اکثر موارد به دلیل آنکه نرمافزار تولید شده نزدیک به نرمافزار صحیح است، نقصها به صورت ساده است طوریکه با یک تغییر کوچک در کد برنامه قابل اصلاح هستند.
اثر اتصال: دادهی تستی که قادر است تمام تفاوتهای یک برنامهی صحیح را از یک برنامهی نادرست با استفاده از شناسایی خطاهای ساده تشخیص دهد آنقدر نسبت به وجود خطا حساس استکه می تواند خطاهای پیچیده تر را نیز تشخیص دهد. در حقیقت خطاهای ساده به خطاهای پیچیده متصل هستند ADDIN EN.CITE <EndNote><Cite><Author>DeMillo</Author><Year>1978</Year><RecNum>42</RecNum><DisplayText>[4]</DisplayText><record><rec-number>42</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>42</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>DeMillo, Richard A</author><author>Lipton, Richard J</author><author>Sayward, Frederick G</author></authors></contributors><titles><title>Hints on test data selection: Help for the practicing programmer</title><secondary-title>Computer</secondary-title></titles><periodical><full-title>Computer</full-title></periodical><pages>34-41</pages><volume>11</volume><number>4</number><dates><year>1978</year></dates><isbn>0018-9162</isbn><urls></urls></record></Cite></EndNote>[4].

Offutt, A Jefferson ADDIN EN.CITE <EndNote><Cite><Author>Offutt</Author><Year>1992</Year><RecNum>44</RecNum><DisplayText>[6]</DisplayText><record><rec-number>44</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>44</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Offutt, A Jefferson</author></authors></contributors><titles><title>Investigations of the software testing coupling effect</title><secondary-title>ACM Transactions on Software Engineering and Methodology (TOSEM)</secondary-title></titles><periodical><full-title>ACM Transactions on Software Engineering and Methodology (TOSEM)</full-title></periodical><pages>5-20</pages><volume>1</volume><number>1</number><dates><year>1992</year></dates><isbn>1049-331X</isbn><urls></urls></record></Cite></EndNote>[6] موضوع اثر اتصال را به طور دقیقتر، و در تست جهش بررسی کرده است. برای این کار، ابتدا برای تولید جهشهای پیچیدهتر تغییراتی در سیستم مٌدرا ایجاد میکند سپس با قرار دادن این جهشها در برنامههایی مانند تشخیص نوع مثلث، جستجو، و یافتن میانه به صورت تجربی نشان میدهد جهشهای سادهتر، دشوارتر از جهشهای پیچیدهتر از میان میروند و تعریفی را برای فرضیه اتصال در تست جهش به این صورت مطرح میکند: اتصال جهشهای پیچیده به جهشهای ساده به گونهای است که دادههای تست، درصد بیشتری از جهشهای پیچیده را نسبت به جهشهای ساده شناسایی میکند. برای اثبات این قضیه در برخی مقالات مانند ADDIN EN.CITE <EndNote><Cite><Author>DeMillo</Author><Year>1978</Year><RecNum>42</RecNum><DisplayText>[4]</DisplayText><record><rec-number>42</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>42</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>DeMillo, Richard A</author><author>Lipton, Richard J</author><author>Sayward, Frederick G</author></authors></contributors><titles><title>Hints on test data selection: Help for the practicing programmer</title><secondary-title>Computer</secondary-title></titles><periodical><full-title>Computer</full-title></periodical><pages>34-41</pages><volume>11</volume><number>4</number><dates><year>1978</year></dates><isbn>0018-9162</isbn><urls></urls></record></Cite></EndNote>[4] تنها با استفاده از مشاهدات تجربی بیان شده است اما در این زمینه مقالاتی برای ارائه یک اثبات دقیق و ریاضی نیز یافت میشود. به عنوان نمونه K. Kapoor ADDIN EN.CITE <EndNote><Cite><Author>Kapoor</Author><Year>2006</Year><RecNum>34</RecNum><DisplayText>[7]</DisplayText><record><rec-number>34</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>34</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Kapoor, Kalpesh</author></authors></contributors><titles><title>Formal analysis of coupling hypothesis for logical faults</title><secondary-title>Innovations in Sys–s and Software Engineering</secondary-title></titles><periodical><full-title>Innovations in Sys–s and Software Engineering</full-title></periodical><pages>80-87</pages><volume>2</volume><number>2</number><dates><year>2006</year></dates><isbn>1614-5046</isbn><urls></urls></record></Cite></EndNote>[7] نظریه اتصال را برای فرمولهای بولی و نقصهای منطقی به صورت رسمی تحلیل میکند. یکی از موضوعاتی که با اثر اتصال جهشها ارتباط نزدیکی دارد سطح جهشها است که به این صورت تعریف میشود جهش سطح n ام از ترکیب جهشهای سطح اول، دوم، سوم تا n-1 ام بدست میآید. جهشهای سطح اول همان نقصها هستند که به صورت مصنوعی به کد برنامه تزریق میشوند و جهشهای سطوح بالاتر هر ترکیبی از جهشهای سطح اول است. Yue Jia *, Mark Harman ADDIN EN.CITE <EndNote><Cite><Author>Jia</Author><Year>2009</Year><RecNum>49</RecNum><DisplayText>[8]</DisplayText><record><rec-number>49</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>49</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Jia, Yue</author><author>Harman, Mark</author></authors></contributors><titles><title>Higher order mutation testing</title><secondary-title>Information and Software Technology</secondary-title></titles><periodical><full-title>Information and Software Technology</full-title></periodical><pages>1379-1393</pages><volume>51</volume><number>10</number><dates><year>2009</year></dates><isbn>0950-5849</isbn><urls></urls></record></Cite></EndNote>[8] جهشهای سطح بالاتر را براساس دو پارامتر متصل بودن و شامل بودن به شش دسته، تقسیم میکنند. متصل بودن بدان معناست که اگر ورودی تستی بتواند تمام جهشهای سطح اولیه که یک جهش سطح بالاتر را میسازند از میان ببرد، میتواند آن جهش سطح بالاتر را نیز از بین ببرد و برعکس آن تعریفی برای عدم اتصال است. شامل بودن جهشهای سطح بالایی است که به نسبت جهشهای سطح اولیه شان سختتر از میان میروند. دستهی اول جهشهای متصلِ شامل قوی: اشتراک دادههای استفاده شده برای از میان بردن جهشهای سطح اولیه میتوانند برای از میان بردن جهشهای سطح بالاتر استفاده شوند. دستهی دوم جهشهای متصل شامل ضعیف: تنها بخشی از دادههای اشتراکی و غیر اشتراکی تولید شده برای از میان بردن جهشهای سطح اول در از بین بردن جهشهای سطح بالاتر قابل بکارگیری هستند. دستهی سوم جهشهای غیر متصل شامل ضعیف: در این دسته دادههایی که جهش سطح بالا را از بین میبرند با دادههایی که جهش سطح اولیه را از بین میبرند هیچ نقطهی اشتراکی ندارند دستهی چهارم و پنجم جهشهای غیر متصل غیر شامل: در این دسته دادههای ورودی یا مانند دستهی سوم هستند یا جهش سطح بالای به وجود آمده جهش برابر(که در ادامه توضیح داده خواهد شد) است که هیچ دادهای نمیتواند جهش سطح بالا را از میان ببرد. دستهی ششم جهشهای متصل غیر شامل: در این دسته جهش سطح بالای ایجاد شده نسبت به جهشهای سطح اولیه خود راحتتر از میان میرود. در این مقاله نویسنده دستههای اول، دوم و سوم را در گروه جهشهای سخت قرار میدهد.
متدلوژی
همانطور که در شکل(2-1) نشان داده شده است ابتدا برنامه وارد شده را با اعمال تغییراتی در کد آن، جهشدار میکنیم سپس با استفاده از روشهای خودکار و یا غیر خودکار برای آن یک مجموعه ی ورودی تست آماده میکنیم. در این هنگام، به جهت اطمینان از عدم وجود خطا در برنامه جهش نیافته آنرا با ورودیهای تولید شده، تست میکنیم در صورت وجود بافتن خطا در برنامه جهش نیافته، آنرا جهت تعمیر ارسال میکنیم. (این مرحله برای آن است که بتوانیم خروجیهای برنامهی جهش یافته را با برنامه اصلی به طور دقیق مقایسه کنیم.) در صورت عدم وجود خطا در برنامه اصلی، برنامهی جهش نیافته را با دادههای تست، آزمایش میکنیم سپس از طریق مقایسهی خروجی برنامهی اصلی و برنامهی جهش یافته و شمارش جهشهای کشف نشده امتیاز جهش را از طریق معادله(‎2-2) به دست میآوریم:
معادله( STYLEREF 1 s ‏2 SEQ معادله * ARABIC s 1 1): MS=|killed mutants|mutants-| equivalents | ×100 که در صورت مشاهدهی بدست آمدن امتیاز جهش بالا، تست پایان یافته است. در غیر این صورت آنرا برای یافتن جهشهای برابر ارسال میکنیم.

شکل( STYLEREF 1 s ‏2 SEQ شکل * ARABIC s 1 1): چارت فرآیند تست جهشعملگرهابرای ایجاد تغییرات یا به اصطلاح ایجاد جهش در کد برنامه، عملگرهای زیادی برای ایجاد تغییراتی مانند درج حذف جابهجایی و … معرفی شدهاند. که برخی در سطح توابع استفاده میشوند و به تازگی عملگرهایی جدیدی مطرح شدهاند که در سطح کلاس استفاده میشوند.
عملگرهای سطح تابع
همانطور که از نام آنها مشخص است این عملگرها با توابع و هر آنچه درون آن است سروکار دارند در ابتدا 22 عملگر توسط مٌدرا ADDIN EN.CITE <EndNote><Cite><Author>King</Author><Year>1991</Year><RecNum>45</RecNum><DisplayText>[9]</DisplayText><record><rec-number>45</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>45</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>King, Kim N</author><author>Offutt, A Jefferson</author></authors></contributors><titles><title>A fortran language sys– for mutation‐based software testing</title><secondary-title>Software: Practice and Experience</secondary-title></titles><periodical><full-title>Software: Practice and Experience</full-title></periodical><pages>685-718</pages><volume>21</volume><number>7</number><dates><year>1991</year></dates><isbn>1097-024X</isbn><urls></urls></record></Cite></EndNote>[9] برای زبان فرترن ارائه شد که در جدول(2-1) آورده شده است.
جدول( STYLEREF 1 s ‏2 SEQ جدول * ARABIC s 1 1): 22 عملگر مُدرا ADDIN EN.CITE <EndNote><Cite><Author>King</Author><Year>1991</Year><RecNum>45</RecNum><DisplayText>[9]</DisplayText><record><rec-number>45</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>45</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>King, Kim N</author><author>Offutt, A Jefferson</author></authors></contributors><titles><title>A fortran language sys– for mutation‐based software testing</title><secondary-title>Software: Practice and Experience</secondary-title></titles><periodical><full-title>Software: Practice and Experience</full-title></periodical><pages>685-718</pages><volume>21</volume><number>7</number><dates><year>1991</year></dates><isbn>1097-024X</isbn><urls></urls></record></Cite></EndNote>[9]
توضیح عملگر جهش
جابهجایی منبع آرایه(Array reference for array reference replacement) AAR
فرار دادن مقدار مطلق (Absolute value insertion) ABS
جابهجایی آرایه با یک مقدار ثابت(Array reference for constant replacement) ACR
جابهجایی عملگرهای حسابی(Arithmetic operator replacement) AOR
جابهجایی آرایه با متغییرهای عددی(Array reference for scalar variable replacement) ASR
جابهجای مقدار ثابت با آرایه (Constant for array reference replacement) CAR
جابهجایی نام یک آرایه(Comparable array name replacement) CNR
جایگذاری مقادیر ثابت(Constant replacement) CRP
جایگذاری مقادیر ثابت با متغییرها(Constant for scalar variable replacement) CSR
جایگذاری برچسب عبارت do (DO sta–ent end replacement) DER
همانند CRPاست اما بر عبارتهای دادهای تاثیر میگذارد(DATA sta–ent alterations) DSA
جایگذاری برچسب GOTO) (GOTO label replacement GLR
جایگذاری اتصال منطقی(Logical connector replacement) LCR
جایگذاری عملگر رابطهای(Relational operator replacement) ROR
جایگذاری عبارت (RETURN sta–ent replacement) return RSR
هر عبارتی که درون یک بلاک پایه و یا درون یک عبارت شرطی باشد با TRAPجایگزین میشود(Sta–ent analysis) SAN
جایگذاری آرایهها با متغییرها (Scalar variable for array reference replacement)
ذازی SAR
جابهجایی متغییرها با مقادیر ثابت (Scalar for constant replacements) SCR
حذف یک عبارت (Sta–ent deletion) SDL
هر ثابت ریاضی با ثابت ریاضی دیگر جایگزین میشود (Source constant replacement) SRC
جایگزینی متغییرهای عددی (Scalar variable replacement) SVR
درج عملگرهای یگانی (Unary operator insertion) UOI
اکنون برای شرح دقیق تر موضوع عملگرهای ABS، UOI، ROR، AOR وLOR ، که برای زبان جاوا طراحی شده است را شرح میدهیم ADDIN EN.CITE <EndNote><Cite><Author>Ammann</Author><Year>2008</Year><RecNum>10</RecNum><DisplayText>[1]</DisplayText><record><rec-number>10</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>10</key></foreign-keys><ref-type name=”Book”>6</ref-type><contributors><authors><author>Ammann, P.</author><author>Offutt, J.</author></authors></contributors><titles><title>Introduction to software testing</title></titles><dates><year>2008</year></dates><publisher>Cambridge University Press</publisher><isbn>0521880386</isbn><urls></urls></record></Cite></EndNote>[1]:
ABS قرار دادن مقدار مطلق: هر عبارت و زیر عبارت محاسباتی توسط سه تابع abs()، negAbs() و failOnZero() تغییر داده میشود. ABS مقدار مطلق عدد را برمیگرداند، negAbs مقدار منفی یک عدد مطلق را برمیگرداند، failOnZero بررسی میکند که آیا مقدار عبارت برابر با صفر است یا خیر، به عنوان مثال: عبارت X=3 * a; را در نظر بگیرید اگر عملگر بالا را روی آن اعمال کنیم بدین شکل میشود:
X=3*abs(a);X=3*-abs(a);X=3* failOnZero(a);
UOI عملگر درج یگانی: هر عملگر یگانی مانند +، -،! ، ~، قبل از هر عبارت و با توجه به نوع عبارت، درج میشود به عنوان مثال: عبارت X=3 * a; در نظر بگیرید:
X=3*+a;X=3*-a;X=+3*a;X=-3*a;X=!3*a;
همانطور که مشاهده میکنید در جهش آخر، به دلیل عدم تطبیق نوع عملگر و عبارت، خطا رخ داده است.
ROR عملگر جابهجایی ارتباط: هرکدام از عملگرهای رابطهای (=,≠,<,>,≥,≤) با یکدیگر جابهجا شده و یا با استفاده از دو تابع trueOP() وfalseOP() (که تنها مقدار “False”و “True” را درون عبارت شرط قرار میدهند)مقدار خروجی را تغییر میدهند به عنوان مثال: جهشهای عبارت شرطی if(m>n) عبارتند از:
If(m>=n) if(m<n) if(m<=n) if(m==n) if(m!=n) if(false) if(true)
AOR جابهجایی عملگرهای محاسباتی: جابهجایی هر یک از عملگرهای محاسباتی (*،**،/، -،+ و% ) و یا با استفاده از دو عملگر rightOp و LeftOp(که به ترتیب عملوند سمت راست یا چپ را حذف میکنند) میتوان در کد برنامه تغییر ایجاد کرد. به عنوان مثال: جهشهای عبارت X=a+b; را در نظر بگیرید
X=a-b; X=a*b; X=a/b; X=a**b; X=a; X=b; X=a%b;
LOR جایگزینی عملگر منطقی: جابهجایی هر کدام از نشانههای عملگرهای منطقی (&، |، ^) و یا هرکدام از عملگرهای rightOp و LeftOpمیتواند در کد برنامه، تغییر ایجاد کند. به عنوان مثال جهشهای عبارت x=m & n را در نظر بگیرید:
x=m|n; x=m^n; x=m; x=n;
عملگرهای سطح کلاس
در برنامه نویسی شئگرا خواص جدیدی نسبت به برنامههای سنتی همچون کپسوله سازی، ارث بری و چند ریختی وجود دارد، این ویژگیها زمینهی جدیدی برای تست جهش ایجاد میکند در تست واحد و تست یکپارچه سازی به چهار سطح تقسیم میشوند:
درون توابع: نقص درون توابع زمانی رخ میدهد که عملکرد یک تابع به طور نادرستی پیاده سازی شده است. که مشابه با عملگرهای درون توابع است.
بین توابع: نقص بین توابع در ارتباط بین جفت توابع در یک کلاس رخ میدهد.
درون کلاس: در این سطح به بررسی هر آنچه که در یک کلاس قرار دارد میپردازد که میتواند شامل تعامل توابع عمومی درون یک کلاس زمانی که با ترتیبهای مختلف فراخوانی میشوند و … باشد.
بین کلاسها: در این سطح به بررسی نقصها در نحوی یکپارچه سازی کلاسها میپردازد در این بخش نقصها بیشتر مربوط به چندریختیها، ارث بری و دسترسی به کلاسها هستند
در جدول(2-2) این عملگرها نشان داده شدهاند ADDIN EN.CITE <EndNote><Cite><Author>Ma</Author><Year>2005</Year><RecNum>30</RecNum><DisplayText>[10]</DisplayText><record><rec-number>30</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>30</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Ma, Yu‐Seung</author><author>Offutt, Jeff</author><author>Kwon, Yong Rae</author></authors></contributors><titles><title>MuJava: an automated class mutation sys–</title><secondary-title>Software Testing, Verification and Reliability</secondary-title></titles><periodical><full-title>Software Testing, Verification and Reliability</full-title></periodical><pages>97-133</pages><volume>15</volume><number>2</number><dates><year>2005</year></dates><isbn>1099-1689</isbn><urls></urls></record></Cite></EndNote>[10].
جدول( STYLEREF 1 s ‏2 SEQ جدول * ARABIC s 1 2): عملگرهای جهش ارائه شده در سطح بین کلاس ADDIN EN.CITE <EndNote><Cite><Author>Ma</Author><Year>2005</Year><RecNum>30</RecNum><DisplayText>[10]</DisplayText><record><rec-number>30</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>30</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Ma, Yu‐Seung</author><author>Offutt, Jeff</author><author>Kwon, Yong Rae</author></authors></contributors><titles><title>MuJava: an automated class mutation sys–</title><secondary-title>Software Testing, Verification and Reliability</secondary-title></titles><periodical><full-title>Software Testing, Verification and Reliability</full-title></periodical><pages>97-133</pages><volume>15</volume><number>2</number><dates><year>2005</year></dates><isbn>1099-1689</isbn><urls></urls></record></Cite></EndNote>[10]
ویژگی زبانی عملگر شرح
کنترل دسترسی AMC تغییر دسترسی خصیصههای موجود در کلاس مانند: عمومی، خصوصی و محافظت شده(Access modifier change)
ارث بری IHD مخفی سازی حذف متغییرها (Hiding variable deletion)
IHI مخفی سازی درج متغییرها (Hiding variable insertion)
IOD Override حذف یک تابع (Overriding method deletion)
IOP Override تابعی که محل فراخوانی آن تغییر کرده (overriding method calling position change)
IOR Override تغییر نام یک تابع (Overriding method rename)
ISK حذف عبارت کلیدی Super
IPC حذف فراخوانی متد سازندهی والد (Explicit call of a parent’s constructor deletion)
چندریختی PNC جایگزینی فراخوانی تابع با نوع کلاس فرزند (new method call with child class type)
PMD جایگزینی یک متغییر با نوع کلاس والد (Instance variable declaration with parent class type)
PPD جایگزینی متغییر پارامتر با نوع(type) کلاس فرزند (Parameter variable declaration with child class type)
PRV تخصیص مرجع به انواع قابل مقایسه (Reference assignment with other comparable type)
بارگذاری OMR بارگذاری تغییر محتوی تابع (Overloading method contents change)
OMD بارگذازی حذف تابع (Overloading method deletion)
OAO تغییر ترتیب آرگومان (Argument order change)
OAN تغییر تعداد آرگومان (Argument number change)
اشتباههای رایج در برنامه نویسی EOA جایگزینی مرجع تخصیص با مرجع محتوی (Reference assignment and content assignment replacement)
EOC جایگزینی مرجع مقایسه با محتوی مقایسه (Reference comparison and content comparison replacement)
EAM تغییر تابع Accessor (Accessor method change)
EMM تغییر توصیف کنندهی تابع (Modifier method change)
تکینکهای کاهش هزینهدر روشهای سنتی برای کاهش هزینهی تست، ابتدا برنامه جهش یافته از روی کد برنامهی اصلی ایجاد شده سپس به صورت جداگانه با ورودیهای تست کامپایل میشود و در نهایت نتایج خروجی بدست آمده از آنها با یکدیگر مقایسه میشد. اگرنتایج بدست آمده، متفاوت بود جهش از میان رفته بود و در غیر این صورت باید فرآیند جستجو برای جهش برابرآغاز میشد که انجام این فرآیند، نیازمند تلاش انسانی و صرف هزینه میشد. به همین دلیل تا قبل از آنکه تکنیکهایی برای خودکارسازی فرآیند تست عرضه شود این روش، به عنوان یک روش گران قیمت و ناکار آمد شناخته میشد تا آن زمان که تکنیکهای کاهش هزینه را به سه دستهی انجام کمتر، انجام هوشمندانه و انجام سریعتر تقسیم شد ADDIN EN.CITE <EndNote><Cite><Author>Offutt</Author><Year>2001</Year><RecNum>31</RecNum><DisplayText>[11]</DisplayText><record><rec-number>31</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>31</key></foreign-keys><ref-type name=”Book Section”>5</ref-type><contributors><authors><author>Offutt, A Jefferson</author><author>Untch, Roland H</author></authors></contributors><titles><title>Mutation 2000: Uniting the orthogonal</title><secondary-title>Mutation testing for the new century</secondary-title></titles><pages>34-44</pages><dates><year>2001</year></dates><publisher>Springer</publisher><isbn>1441948880</isbn><urls></urls></record></Cite></EndNote>[11]. در این پایاننامه، مشابه ADDIN EN.CITE <EndNote><Cite><Author>Jia</Author><Year>2011</Year><RecNum>46</RecNum><DisplayText>[2]</DisplayText><record><rec-number>46</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>46</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Jia, Yue</author><author>Harman, Mark</author></authors></contributors><titles><title>An analysis and survey of the development of mutation testing</title><secondary-title>Software Engineering, IEEE Transactions on</secondary-title></titles><periodical><full-title>Software Engineering, IEEE Transactions on</full-title></periodical><pages>649-678</pages><volume>37</volume><number>5</number><dates><year>2011</year></dates><isbn>0098-5589</isbn><urls></urls></record></Cite></EndNote>[2] آنها را به دو دستهی تولید کمتر جهش و کاهش هزینهی اجرا تقسیم میکنیم. همانطور که در شکل(2-2) ADDIN EN.CITE <EndNote><Cite><Author>Jia</Author><Year>2011</Year><RecNum>46</RecNum><DisplayText>[2]</DisplayText><record><rec-number>46</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>46</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Jia, Yue</author><author>Harman, Mark</author></authors></contributors><titles><title>An analysis and survey of the development of mutation testing</title><secondary-title>Software Engineering, IEEE Transactions on</secondary-title></titles><periodical><full-title>Software Engineering, IEEE Transactions on</full-title></periodical><pages>649-678</pages><volume>37</volume><number>5</number><dates><year>2011</year></dates><isbn>0098-5589</isbn><urls></urls></record></Cite></EndNote>[2] (که حاصل بررسی 390 مقاله است) مشاهده میشود تاکنون تکنیکهای جهش انتخابی و جهش ضعیف در مقایسه با سایر روشها بیشتر مورد توجه بوده است.( سایر روشها اغلب حاصل کمتر از 5 مقاله بوده است.)

شکل( STYLEREF 1 s ‏2 SEQ شکل * ARABIC s 1 2): درصد استفادهی مقالات از تکنیکهای کاهش هزینه ADDIN EN.CITE <EndNote><Cite><Author>Jia</Author><Year>2011</Year><RecNum>46</RecNum><DisplayText>[2]</DisplayText><record><rec-number>46</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>46</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Jia, Yue</author><author>Harman, Mark</author></authors></contributors><titles><title>An analysis and survey of the development of mutation testing</title><secondary-title>Software Engineering, IEEE Transactions on</secondary-title></titles><periodical><full-title>Software Engineering, IEEE Transactions on</full-title></periodical><pages>649-678</pages><volume>37</volume><number>5</number><dates><year>2011</year></dates><isbn>0098-5589</isbn><urls></urls></record></Cite></EndNote>[2]
تولید جهش کمتریکی از ابتدایی ترین روشهای کاهش هزینه، تولید جهش کمتر است. زیرا هر چه تعداد جهشهای موجود در کد برنامه بیشتر باشد به همان نسبت نیاز به تولید دادههای تست بیشتری داریم این کار هزینه بر است اما از طرف دیگر کاهش تعداد جهشها ممکن است اثر بخشی فرآیند تست را پایین بیاورد. در این زمینه تلاش شده تا ضمن حفظ یا کاهش حداقل اثر بخشی تعداد جهشها را نیز کاهش داد. در زیر به چند روش اشاره میکنیم:
نمونه برداری از جهشها: در این روش، تمرکز بر پیدا کردن مجموعهای از موارد تست است که با وجود موارد تست کمتر معیار پوشش را حفظ کند. در اینجا لازم است کمی در مورد معیار پوشش توضیح دهیم: هر کد برنامه را میتوان به صورت یک گراف نمایش داد که هر گره ی آن، بخشی از کد است که قابلیت اجرا در یک واحد زمانی را داشته باشد. از طرف دیگر یالها نیز نحوی ارتباطات این گرهها با یکدیگر را نشان میدهند. در هرگراف، مسیرهایی وجود دارد که دنبالهای از گرهها را شامل میشود. هر مسیر، شامل چندین زیر مسیر است که برخی از آنها مسیر تست هستند. مسیرهای تست مسیرهایی هستند که از گره آغازین گراف شروع و به گره پایانی آن ختم میشوند. در هر بار فرآیند تست، تنها یکی از مسیرهای تست اجرا خواهد شد. پس در حقیقت دادههای ورودی که بتواند مسیرهای تست بیشتری را اجرا کند، بهتر خواهد بود. برای پوشش، به طورکلی دو معیار وجود دارد: 1- ساختیافته 2-جریان داده، معیارهای ساختیافته تنها برروی گرافی تعریف میشوند که شامل گره و یال است و میتوان به عنوان مثال به معیارهای NC (پوشش تمامی گرههای گراف) EC (پوشش تمامی یالهای گراف) و… . معیار جریان دادهها تنها برروی گرافهایی، قابل تعریف است که در آن منبع هر متغییر ذکر شده باشد. هدف این معیار ردگیری محل تعریف def و استفادهی use متغییرها، جهت کسب اطمینان از استفادهی درست از آنها استdef (n). و def (e) به متغییرهایی گفته میشود که در یال e و یا گره n تعریف میشوند و متقابلا use (n) و use (e) به متغییرهایی گفته میشود که در گره n و یا یال e استفاده میشوند.
R. Horgan ADDIN EN.CITE <EndNote><Cite><Author>Horgan</Author><Year>1992</Year><RecNum>49</RecNum><DisplayText>[12]</DisplayText><record><rec-number>49</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>49</key></foreign-keys><ref-type name=”Conference Proceedings”>10</ref-type><contributors><authors><author>Horgan, J Robert</author><author>London, Saul</author></authors></contributors><titles><title>A data flow coverage testing tool for C</title><secondary-title>Assessment of Quality Software Development Tools, 1992., Proceedings of the Second Symposium on</secondary-title></titles><pages>2-10</pages><dates><year>1992</year></dates><publisher>IEEE</publisher><isbn>0818626208</isbn><urls></urls></record></Cite></EndNote>[12] با ایجاد مجموعه تستهای کمینه سعی در کاهش هزینه تست دارد بگونهای که در عین کاهش تعداد موارد تست بتوانند کیفیت تست را ثابت نگاه دارد. در این تحقیق برای تولید مجموعه تستهای کمینه از ابزاری به نام ATACMIN استفاده میشود که با استفاده از آن در ابتدا برای 1000 جهش مورد تست، تولید میشود سپس آنها را براساس پوشش بلاکها در دستههای (50-55)% ، (60-65)%، (70-75)%، (80-85)% و (90-95)% قرار میگیرند پس از بررسیهایی که بر روی 10 نرمافزار انجام شد چهار نتیجه دست آمد که عبارت است از:
کاهش اثر بخشی: کاهش مقدار اثر بخشی بر اثر کاهش کمینه سازی دسته های تست (50-55)% ، (60-65)%، (70-75)%، (80-85)% و (90-95)% به ترتیب برابر است با: 0%، 0.03%، 0.01%، 0.38%و1.45% است که این مقدار در کاهش اثر بخشی قابل چشم پوشی است.
کاهش اندازه: کاهش اندازه برای هر دسته تست (50-55)% ، (60-65)%، (70-75)%، (80-85)% و (90-95)% به ترتیب برابر است با: 1.19%، 4.46%، 7.78%، 17.44% و 44.23% است که در برابر کاهش اثر بخشی ناچیز آن، قابل توجه است.
تاثیر سختی نقصها: در این بخش نویسنده به بررسی ارتباط میان نقصهای پیچیده و کمینه سازی مجموعه تست پرداخته است. برای این کار در ابتدا نقصها را به چهار دسته از 1تا4 به از پیچیده تا ساده تقسیم میکند و نشان میدهد کاهش اثر بخشی برای هر دسته به ترتیب 0.39%، 0.66%، 0.098% و 0% است این مساله نشان میدهد نقصهایی که توسط تعداد محدودی از موارد تست کشف میشود ممکن است در صورت کاهش مجموعهی تست قابل کشف نباشند. در این مورد نیز کاهش اثر بخشی آنقدر نیست که قابل ملاحظه باشد ADDIN EN.CITE <EndNote><Cite><Author>Wong</Author><Year>1995</Year><RecNum>48</RecNum><DisplayText>[13]</DisplayText><record><rec-number>48</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>48</key></foreign-keys><ref-type name=”Conference Proceedings”>10</ref-type><contributors><authors><author>Wong, W Eric</author><author>Horgan, Joseph R</author><author>London, Saul</author><author>Mathur, Aditya P</author></authors></contributors><titles><title>Effect of test set minimization on fault detection effectiveness</title><secondary-title>Software Engineering, 1995. ICSE 1995. 17th International Conference on</secondary-title></titles><pages>41-41</pages><dates><year>1995</year></dates><publisher>IEEE</publisher><isbn>0897917081</isbn><urls></urls></record></Cite></EndNote>[13].
در روش دیگر از روشهای تصادفی برای انتخاب بخشی از دادههای تست مناسب استفاده میشود (به عنوان مثال از 10% تا 40% از دادههای تست را انتخاب میشود) سپس با انجام آزمایشهای مختلف به این نتیجه میرسد که برای پوشش تمام معیارها، تنها کمتر از 14% درصد تمام موارد تست نیاز است ADDIN EN.CITE <EndNote><Cite><Author>Mathur</Author><Year>1994</Year><RecNum>47</RecNum><DisplayText>[14]</DisplayText><record><rec-number>47</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>47</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Mathur, Aditya P</author><author>Wong, W Eric</author></authors></contributors><titles><title>An empirical comparison of data flow and mutation‐based test adequacy criteria</title><secondary-title>Software Testing, Verification and Reliability</secondary-title></titles><periodical><full-title>Software Testing, Verification and Reliability</full-title></periodical><pages>9-31</pages><volume>4</volume><number>1</number><dates><year>1994</year></dates><isbn>1099-1689</isbn><urls></urls></record></Cite></EndNote>[14].
روش دستهبندی: ایدهی اصلی این روش ابتدا توسط S. Hussain ADDIN EN.CITE <EndNote><Cite><Author>Hussain</Author><Year>2008</Year><RecNum>37</RecNum><DisplayText>[15]</DisplayText><record><rec-number>37</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>37</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Hussain, Shamaila</author></authors></contributors><titles><title>Mutation clustering</title><secondary-title>Ms. Th., King’s College London, Strand, London</secondary-title></titles><periodical><full-title>Ms. Th., King’s College London, Strand, London</full-title></periodical><dates><year>2008</year></dates><urls></urls></record></Cite></EndNote>[15] مطرح شد در این روش جهشهای تولید شده را براساس ویژگیهای مشترک دستهبندی میشوند سپس از میان آنها چند جهش انتخاب شده و برای هر دسته به طور مجزا دادههای تست تولید میشود. برای دستهبندی جهشهای پنج برنامه از دو روش K-means ، Agglomerative (که در فصل ضمایم توضیح داده شدهاند) و کد فاصله همینگ استفاده شده است. با استفاده از این فاصله میتوانیم فاصلهی بین جهشها را اندازهگیری کرده و جهشهای مشابه را در یک دسته قرار دهیم برای این کار به عنوان مثال سه جهش M2,M1 وM3 به صورت جدول(2-3) در نظر بگیرید.
جدول( STYLEREF 1 s ‏2 SEQ جدول * ARABIC s 1 3): سه جهش M2,M1 وM3 ADDIN EN.CITE <EndNote><Cite><Author>Hussain</Author><Year>2008</Year><RecNum>37</RecNum><DisplayText>[15]</DisplayText><record><rec-number>37</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>37</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Hussain, Shamaila</author></authors></contributors><titles><title>Mutation clustering</title><secondary-title>Ms. Th., King’s College London, Strand, London</secondary-title></titles><periodical><full-title>Ms. Th., King’s College London, Strand, London</full-title></periodical><dates><year>2008</year></dates><urls></urls></record></Cite></EndNote>[15]
1 0 1 0 0 1 1 M1
0 0 1 1 1 1 1 M2
0 0 1 1 1 1 0 M3
همانطور که مشاهده میکنید برای هر جهش هفت ویژگی در نظر گرفته شده است که در صورت وجود آن ویژگی مقدار آن با یک و در صورت عدم وجود با صفر نمایش داده شده است. برای اندازهگیری فاصلهی همینگ قسمتهای متفاوت هر M با یک دیگر جمع شده تا فاصلهی همینگ مطابق جدول(2-4) بدست آید.
جدول ( STYLEREF 1 s ‏2 SEQ جدول * ARABIC s 1 4): : فاصلهی همینگ سه جهش M2,M1 وM3 ADDIN EN.CITE <EndNote><Cite><Author>Hussain</Author><Year>2008</Year><RecNum>37</RecNum><DisplayText>[15]</DisplayText><record><rec-number>37</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>37</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Hussain, Shamaila</author></authors></contributors><titles><title>Mutation clustering</title><secondary-title>Ms. Th., King’s College London, Strand, London</secondary-title></titles><periodical><full-title>Ms. Th., King’s College London, Strand, London</full-title></periodical><dates><year>2008</year></dates><urls></urls></record></Cite></EndNote>[15]
M3 M2 M1 4 3 0 M1
1 0 3 M2
0 1 4 M3
درنهایت با انجام تکنیکهای فوق جهشها را دسته بندی کرده و همانطور که در جدول (2-5) مشاهده می کنید در عین صرفه جویی در تعداد نقصها و موارد تست، تنها سبب از دست رفتن بخشی از امتیازجهش، تنها دریک برنامه شده است.
جدول( STYLEREF 1 s ‏2 SEQ جدول * ARABIC s 1 5): خلاصهی نتایج بدست آمده حاصل از اجرای روش دستهبندی بر روی پنج برنامه ADDIN EN.CITE <EndNote><Cite><Author>Hussain</Author><Year>2008</Year><RecNum>37</RecNum><DisplayText>[15]</DisplayText><record><rec-number>37</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>37</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Hussain, Shamaila</author></authors></contributors><titles><title>Mutation clustering</title><secondary-title>Ms. Th., King’s College London, Strand, London</secondary-title></titles><periodical><full-title>Ms. Th., King’s College London, Strand, London</full-title></periodical><dates><year>2008</year></dates><urls></urls></record></Cite></EndNote>[15]
برنامهها تعداد کل جهشها اعداد بهینهی جهشها باقی مانده بر اثر دستهبندی کل موارد تست موارد تست کاهش یافته میانگین امتیاز جهش
Triangle 584 62 34 12 95.6%
TCAS 856 212 1608 21 100%
Schedul 972 83 1399 2 100%
Totinfo 1879 173 1052 7 100%
Printtokens 506 68 2021 4 100%
C. Ji, Z ADDIN EN.CITE <EndNote><Cite><Author>Ji</Author><Year>2009</Year><RecNum>51</RecNum><DisplayText>[16]</DisplayText><record><rec-number>51</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>51</key></foreign-keys><ref-type name=”Conference Proceedings”>10</ref-type><contributors><authors><author>Ji, Changbin</author><author>Chen, Zhenyu</author><author>Xu, Baowen</author><author>Zhao, Zhihong</author></authors></contributors><titles><title>A Novel Method of Mutation Clustering Based on Domain Analysis</title><secondary-title>SEKE</secondary-title></titles><pages>422-425</pages><dates><year>2009</year></dates><urls></urls></record></Cite></EndNote>[16] هر برنامه را به سه بخش دامنهی ورودی، مسیر شرطی و مسیر ماژول بعدی تقسیم میکند. هر مسیر شرطی در هنگام اجرا برنامه چندین شرط را از چندین ماژول را با عملگر منطقی عطف و نقیض یکپارچه میکند. بهعنوان مثال اگر Condition 1 و Condition 2 به ترتیب شروط ماژول 1 و 2 باشند پس از اجرای مسیر شرطی به صورت ¬Condition 1∧¬Condition 2 یکپارچهسازی میشود C. Ji, Z. برای تشخیص جهشها در مسیر شرطی متغییرهایی تعریف میکند که به شرح زیر است:
شرط عدم خروج: انتخاب مسیر جهشی که سبب خروج از برنامه نشود.
شرطهای تودرتو: در یک ماژول، ممکن است شرطهای تودرتویی وجود داشته باشد که برای ارضاء شرط جهش، نیاز به ارضاء تمام آنها است.
شرطهای جهش یافته: عملگرهای جهشیکه سبب تغییر دستوری در کد شرط میشود.
دامنهی ورودی باید ترکیبی از این شرطها را ارضاء کند. از این سه شرط برای اندازهگیری فاصلهی همینگ جهشها استفاده میشود. پس از اندازهگیری فاصله همینگ برای قرار گیری هر جهش در دسته مناسب متغیری به نام K که مقدار آن برابر نیمی از تعداد کل جهشها، و یک حد آستانه که مقدار آن برابر با نیمی از بیشتر فاصلهی بین دو جهش است تعریف میشوند. در ابتدا K جهش بهصورت تصادفی انتخاب میشود و آنها را در دستههای اولیه قرار میدهد سپس باقی جهشها با توجه به آنکه فاصلهی آنها کمتر از حد آستانه است دستهبندی میشود. در مرحلهی بعد از هر دسته یک جهش به صورت تصادفی انتخاب شده و خود یک دستهبندی جدید را تشکیل میدهد که با استفاده از این روش، علاوه بر کاهش تعداد جهشها موارد تستی که نتواند دسته جهشی را از بین ببرد از مجموعهی تست حذف میشود.
جهش انتخابی: یکی از روشهای کاهش تعداد جهشها، کاهش تعداد عملگرهای استفاده شده برای تولید جهش است. مانند روشهای قبل، این روش نیز در کنار کاهش تعداد جهشها حفظ اثر بخشی تست مهم است. برای افزایش سرعت اجرای برنامههایی که کامپایل آنها زمان بر است، ابزاری به نام CIT معرفی شده است که این ابزار امکان تست یکپارچه و تولید جهش را به کامپایلر میدهد و از طرف دیگر آنرا برای انجام، به صورت همزمان کارآمد میکند. همچین برای اولینبار روش جهش محدود شده که منجر به حذف دو عملگر SVR و ASR مطرح میشود ADDIN EN.CITE <EndNote><Cite><Author>Mathur</Author><Year>1991</Year><RecNum>52</RecNum><DisplayText>[17]</DisplayText><record><rec-number>52</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>52</key></foreign-keys><ref-type name=”Conference Proceedings”>10</ref-type><contributors><authors><author>Mathur, Aditya P</author></authors></contributors><titles><title>Performance, effectiveness, and reliability issues in software testing</title><secondary-title>Computer Software and Applications Conference, 1991. COMPSAC&apos;91., Proceedings of the Fifteenth Annual International</secondary-title></titles><pages>604-605</pages><dates><year>1991</year></dates><publisher>IEEE</publisher><isbn>0818621524</isbn><urls></urls></record></Cite></EndNote>[17] ، این ایده، به نام جهش انتخابی دوگانه، مطرح شده است. A. J. Offutt ADDIN EN.CITE <EndNote><Cite><Author>Offutt</Author><Year>1993</Year><RecNum>53</RecNum><DisplayText>[18]</DisplayText><record><rec-number>53</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>53</key></foreign-keys><ref-type name=”Conference Proceedings”>10</ref-type><contributors><authors><author>Offutt, A Jefferson</author><author>Rothermel, Gregg</author><author>Zapf, Christian</author></authors></contributors><titles><title>An experimental evaluation of selective mutation</title><secondary-title>Proceedings of the 15th international conference on Software Engineering</secondary-title></titles><pages>100-107</pages><dates><year>1993</year></dates><publisher>IEEE Computer Society Press</publisher><isbn>0897915887</isbn><urls></urls></record></Cite></EndNote>[18] در تلاش اول، برای تخمین پیچیدگی جهش ازطریق فرمولهای همبستگی خطی ساده و همبستگی چندگانهی خطی به بررسی ارتباط میان تعداد جهشهای تولید شده، خطوط برنامه، تعداد متغییرهای برنامه، تعداد منابع متغییرها و تعداد انشعابات میپردازد سپس ایدهی جهش انتخابی دوگانه را بسط داده و برای جهشهای چهارگانه و ششگانه نیز مطرح میکند. میانگین صرفه جویی در تعداد جهشهای تولید شده در پیاده سازی این روش روی ده برنامه به ترتیب 23.98% برای جهش انتخابی دوگانه و 41.36% برای جهشهای چهارگانه است. R. H. Untch ADDIN EN.CITE <EndNote><Cite><Author>Offutt</Author><Year>1996</Year><RecNum>54</RecNum><DisplayText>[19]</DisplayText><record><rec-number>54</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>54</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Offutt, A Jefferson</author><author>Lee, Ammei</author><author>Rothermel, Gregg</author><author>Untch, Roland H</author><author>Zapf, Christian</author></authors></contributors><titles><title>An experimental determination of sufficient mutant operators</title><secondary-title>ACM Transactions on Software Engineering and Methodology (TOSEM)</secondary-title></titles><periodical><full-title>ACM Transactions on Software Engineering and Methodology (TOSEM)</full-title></periodical><pages>99-118</pages><volume>5</volume><number>2</number><dates><year>1996</year></dates><isbn>1049-331X</isbn><urls></urls></record></Cite></EndNote>[19] عملگرها را به صورت کلاسهای دسته بندی (مانند ES-Selective mutation که از22 عملگر، عملگرهای AAR, ACR, ASR, CAR, CNR, CRP, CSR, SAR, SCR, SRC, وSVR در آن وجود ندارند) دستهبندی میکند و پس از ترکیب دستههای مختلف به این نتیجه میرسد، که پنج عملگر ABS، AOR، LCR، ROR و UOI.توانایی تولید 95% از جهشها را دارند. در نتیجه عملگرهای کلیدی نامیده میشوند.
جهشهای سطح بالاتر
میتوان با ترکیب جهشهای سطوح مختلف جهشهای سطح بالاتری به وجود آورد به گونهای که با کاهش مقدار ناچیزی از کیفیت تست مقدار قابل توجهی در تعداد ورودیهای تست و جهشهای برابر وارد شده به کد برنامه، صرفه جویی کرد. برای ایجاد این گونه جهشها سه استراتژی وجود دارد که اولین بار در ADDIN EN.CITE <EndNote><Cite><Author>Polo</Author><Year>2009</Year><RecNum>53</RecNum><DisplayText>[20]</DisplayText><record><rec-number>53</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>53</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Polo, Macario</author><author>Piattini, Mario</author><author>García‐Rodríguez, Ignacio</author></authors></contributors><titles><title>Decreasing the cost of mutation testing with second‐order mutants</title><secondary-title>Software Testing, Verification and Reliability</secondary-title></titles><periodical><full-title>Software Testing, Verification and Reliability</full-title></periodical><pages>111-131</pages><volume>19</volume><number>2</number><dates><year>2009</year></dates><isbn>1099-1689</isbn><urls></urls></record></Cite></EndNote>[20] مطرح شد. این سه استراتژی عبارت است از:
ادغام تصادفی”RandomMix”: جهشهای به وجود آمده در این روشحاصل از ترکیب تصادفی دو عملگر است.
عملگرهای مختلف “DifferentOperators” : جهشهای ایجاد شده در این روش حاصل از ترکیب دو عملگر متفاوت است.
روش آخر به اول “LastToFirst”: جهشها براساس ترکیب عملگر جهش اول با عملگر جهش آخر در لیست عملگرهای جهشهای انتخابی اعمال میشوند.
سپس تاثیر حاصل از ترکیب جهشهای برابر و نابرابر نشان میدهد که در جدول(2-6) آورده شده است
جدول( STYLEREF 1 s ‏2 SEQ جدول * ARABIC s 1 6): تاثیر حاصل ترکیب جهش های برابر و نابرابر با یکدیگرMiMjMi,jجهش برابر جهش برابر جهش برابر
جهش برابر جهش غیر برابر جهش غیر برابر
جهش غیر برابر جهش برابر جهش غیر برابر
جهش غیر برابر جهش غیر برابر جهش غیر برابر(به احتمال زیاد)
Mike Papadakis ADDIN EN.CITE <EndNote><Cite><Author>Papadakis</Author><Year>2010</Year><RecNum>54</RecNum><DisplayText>[21]</DisplayText><record><rec-number>54</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>54</key></foreign-keys><ref-type name=”Conference Proceedings”>10</ref-type><contributors><authors><author>Papadakis, Mike</author><author>Malevris, Nicos</author></authors></contributors><titles><title>An empirical evaluation of the first and second order mutation testing strategies</title><secondary-title>Software testing, verification, and validation workshops (ICSTW), 2010 third international conference on</secondary-title></titles><pages>90-99</pages><dates><year>2010</year></dates><publisher>IEEE</publisher><isbn>142446773X</isbn><urls></urls></record></Cite></EndNote>[21] سه استراتژی موجود برای ترکیب جهشهای سطح اول که مطرح شد را بررسی میکند و به تاثیر آن پنج استراتژی دیگر معرفی میکند که عبارتند از:”First2Last”، “SameNode”، “SU_F2Last”، “SU_DiffOp”و “DiffOp” سپس نشان میدهد جهشهای سطح بالاتر اگر با استراتژی مناسبی ترکیب شوند میتوانند 80 تا 90 درصد جهش برابر کمتری تولید کنند. از طرف دیگر موارد تست مورد نیاز نیز به نسبت جهش قوی به مقدار قابل توجهای کاهش میابد.
تکنیکهای کاهش هزینه در زمان اجرای برنامهیکی ازروشهای دیگر صرفه جویی درهزینه وزمان تست جهش استفاده ازتکنیکهای بهینه سازی فرآیند اجرای تست است که به طور کلی به دو دستهی شیوهی اجرای کد جهش یافته و تکنیکهای مربوط به کامپایلرها و مفسرها تقسیم میشوند.
شیوهی اجرای کد جهش یافته به طور کلی کد جهش یافته را به سه صورت میتوان اجرا کرد که در اصلاح به آن، جهش قوی، جهش ضعیف و جهش محکم میگویند :
جهش قوی: این روش برای اولین بار توسط R. A. DeMillo ADDIN EN.CITE <EndNote><Cite><Author>DeMillo</Author><Year>1978</Year><RecNum>42</RecNum><DisplayText>[4]</DisplayText><record><rec-number>42</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>42</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>DeMillo, Richard A</author><author>Lipton, Richard J</author><author>Sayward, Frederick G</author></authors></contributors><titles><title>Hints on test data selection: Help for the practicing programmer</title><secondary-title>Computer</secondary-title></titles><periodical><full-title>Computer</full-title></periodical><pages>34-41</pages><volume>11</volume><number>4</number><dates><year>1978</year></dates><isbn>0018-9162</isbn><urls></urls></record></Cite></EndNote>[4] مطرح شد. دو برنامه (جهش یافته و نیافته) به طور مجزا در این روش اجرا میشوند و خروجی حاصل از اجرای آنها تنها پس از اجرای کامل خطوط هر دو برنامه (جهت مشاهدهی تغییر) با یکدیگر مقایسه خواهد شد که این روش از نظر هزینه به صرفه نیست.
جهش ضعیف: در روش اجرای ضعیف جهش فرض میشود که برنامه از یک مجموعهی n مؤلفه مانند C=[c1,c2,…,cn} تشکیل شده است که در هر مؤلفه میتوانیم به طور مجزا جهش ایجاد کرده وآنرا با c’i نشان میدهیم سپس برای از بین بردن جهشهای برای مولفهی جهش یافته، دادههای تست مناسب تولید میکنیم و خروجی حاصل از اجرای همان مؤلفه را با خروجیهای مولفهی نظیر در برنامه اصلی، مقایسه میکنیم در صورت مشاهدهی تغییر، جهش از میان رفته است. مولفههای هر برنامه را به پنج دستهی منبع متغییرها، متغییرهای تخصیص یافته، عبارت محاسباتی، عبارت ارتباطی و عبارت منطقی تقسیم میشود. A. J. Offutt ADDIN EN.CITE <EndNote><Cite><Author>Zhang</Author><Year>2010</Year><RecNum>19</RecNum><DisplayText>[22]</DisplayText><record><rec-number>19</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>19</key></foreign-keys><ref-type name=”Conference Proceedings”>10</ref-type><contributors><authors><author>Zhang, Lingming</author><author>Xie, Tao</author><author>Zhang, Lu</author><author>Tillmann, Nikolai</author><author>De Halleux, Jonathan</author><author>Mei, Hong</author></authors></contributors><titles><title>Test generation via dynamic symbolic execution for mutation testing</title><secondary-title>Software Maintenance (ICSM), 2010 IEEE International Conference on</secondary-title></titles><pages>1-10</pages><dates><year>2010</year></dates><publisher>IEEE</publisher><isbn>1424486300</isbn><urls></urls></record></Cite></EndNote>[22] این ایده را گسترش داده و چهار متغییر برحسب نقطه از کد که خروجی برنامهی جهش یافتهی آن با خروجی برنامهی اصلی مقایسه میشود تعیین میگردد این چهار متغییر عبارتند از:
(Expression-weak/1)EX-weak/1: نقطهی پایان اجرا و مقایسه خروجی در عبارتهای داخلی کد برنامه بعد از اولین اجرا و پیرامون عبارت جهش یافته در برنامه است.
(Sta–ent-weak/1)ST-weak/1: نقطهی پایان اجرا و مقایسه خروجیها دقیقا پس از اجرای عبارت جهش یافته است.
(Basic block weak /1 execution)BB-weak/1: هر بلاک پایه تکهای از کد برنامه است که تنها میسر ورودی به آن وارد شده و تنها یک مسیر خروجی نیز از آن خارج میشود پس نقطهی پایان اجرا و مقایسهی خروجی در پایان پس از اجرای هر بلاک پایه است.
(Basic block weak /n execution)BB-weak/n: نویسنده با بررسی حلقهها در مییابد که برخی از جهشها در حلقه تنها با یک بار اجرا از میان نمیروند و برای از بین بردن آنها نیاز به اجرای n بار یک حلقه داریم پس نقطهی پایان اجرا و مقایسه خروجی بعد از اجرای n بار یک بلاک پایه است.
در شکل(2-3) برنامهی جهش یافتهی تبدیل ضرب به جمع و محدودهی چهار متغییر بالا نشان داده شده است . یکی از مشکلات روش جهش ضعیف تفاوت خروجی حاصل از اجرای مولفههای برنامهی با اجرای کل برنامه است که از اثر بخشی روش جهش ضعیف میکاهد ADDIN EN.CITE <EndNote><Cite><Author>Offutt</Author><Year>1994</Year><RecNum>55</RecNum><DisplayText>[23]</DisplayText><record><rec-number>55</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>55</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Offutt, A Jefferson</author><author>Lee, Stephen D</author></authors></contributors><titles><title>An empirical evaluation of weak mutation</title><secondary-title>Software Engineering, IEEE Transactions on</secondary-title></titles><periodical><full-title>Software Engineering, IEEE Transactions on</full-title></periodical><pages>337-344</pages><volume>20</volume><number>5</number><dates><year>1994</year></dates><isbn>0098-5589</isbn><urls></urls></record></Cite></EndNote>[23].

شکل( STYLEREF 1 s ‏2 SEQ شکل * ARABIC s 1 3): چهار متغییر مقایسهی جهش ضعیف ADDIN EN.CITE <EndNote><Cite><Author>Offutt</Author><Year>1994</Year><RecNum>55</RecNum><DisplayText>[23]</DisplayText><record><rec-number>55</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>55</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Offutt, A Jefferson</author><author>Lee, Stephen D</author></authors></contributors><titles><title>An empirical evaluation of weak mutation</title><secondary-title>Software Engineering, IEEE Transactions on</secondary-title></titles><periodical><full-title>Software Engineering, IEEE Transactions on</full-title></periodical><pages>337-344</pages><volume>20</volume><number>5</number><dates><year>1994</year></dates><isbn>0098-5589</isbn><urls></urls></record></Cite></EndNote>[23]
جهش محکم: اجرای بخشی از کد برنامه بیش از یک بار که خطایی ساده به آن وارد شده است را جهش قوی گویند این روش از مزایای هر دو روش جهش ضعیف و قوی استفاده میکند. برای مقایسهی روش محکم با روش جهش ضعیف و قوی M. Woodward ADDIN EN.CITE <EndNote><Cite><Author>Woodward</Author><Year>1988</Year><RecNum>57</RecNum><DisplayText>[24]</DisplayText><record><rec-number>57</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>57</key></foreign-keys><ref-type name=”Conference Proceedings”>10</ref-type><contributors><authors><author>Woodward, MR</author><author>Halewood, K</author></authors></contributors><titles><title>From weak to strong, dead or alive? an analysis of some mutation testing issues</title><secondary-title>Software Testing, Verification, and Analysis, 1988., Proceedings of the Second Workshop on</secondary-title></titles><pages>152-158</pages><dates><year>1988</year></dates><publisher>IEEE</publisher><isbn>0818608684</isbn><urls></urls></record></Cite></EndNote>[24] دو متغییر به نامtchange: بخشی از اجرای برنامه است که تغییرات ایجاد میشود وtundo: بخشی از اجرای برنامه است که تغییرات به حالت اولیه بازگردانده میشود و خروجیها مقایسه میشوند. برای مثال: جهش قوی و ضعیف با این دو متغییر به این صورت تعریف میشوند. اگر tchange قبل و tundo بعد از اجرای کامل برنامه باشد جهش قوی و اگر tchange قبل و tundo بلافاصله بعد از یک بار اجرای مولفهی خاصی در کد برنامه باشد جهش ضعیف است. در حالیکه در جهش محکم tchange و tundo قبل و بعد یک محدودهی از پیش تعیین شده در کد برنامه قرار میگیرند محلی از کد که برای تغییر انتخاب شده است ممکن است به تعداد مولفههای اجرا شده یا به مقدار دادهها در کد برنامه بستگی داشته باشد. از مزایای این روش، میتوان به آزادی عمل بیشتر در استفاده از عملگرهای جهش و اعمال آن بر روی مولفهها، کنترل بیشتر جهت مقایسه نتایج بدست آمده از خروجی برنامه و کم هزینه بودن نسبت به روش جهش قوی اشاره کرد و از معایب آن میتوان به عدم وجود روشی مشخص برای تعیین ناحیهای که توسط جهش قوی اجرا میشود نام برد.
تکنیکهای مربوط به اجرای کد جهش یافته توسط کامپایلرها و مفسرها
به طور کلی در این تکنیکها با ایجاد تغییر در کامپایلرها و مفسرها سعی در افزایش سرعت کامپایل کد جهش یافته دارد. M. E. Delamaro و J. C. Maldonado ADDIN EN.CITE <EndNote><Cite><Author>Delamaro</Author><Year>1996</Year><RecNum>58</RecNum><DisplayText>[25]</DisplayText><record><rec-number>58</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>58</key></foreign-keys><ref-type name=”Conference Proceedings”>10</ref-type><contributors><authors><author>Delamaro, Marcio E</author><author>Maldonado, Jose C</author></authors></contributors><titles><title>Proteum–a tool for the assessment of test adequacy for c programs</title><secondary-title>Proceedings of the Conference on Performability in Computing Sys– (PCS 96)</secondary-title></titles><pages>79-95</pages><dates><year>1996</year></dates><urls></urls></record></Cite></EndNote>[25] سیستمی به نام Proteum معرفی میکنند که توانایی کامپایل جداگانهی هر جهش را پیش از اجرا دارد اما در این روش مشکلی به نام گلوگاه وجود دارد. این مشکل زمانی به وجود میآید که زمان کامپایل برنامه از زمان اجرای آن بیشتر شود. برای حل مشکل گلوگاه یک کامپایلر یکپارچه ایجاد میشود که کدهای جهش به صورت تکهی برنامههایی مجزا کامپایل میکند و برحسب اولویتشان بر روی کد برنامهی اصلی یک بار کامپایل شده اعمال میشوند. ADDIN EN.CITE <EndNote><Cite><Author>Krauser Jr</Author><Year>1991</Year><RecNum>59</RecNum><DisplayText>[26]</DisplayText><record><rec-number>59</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>59</key></foreign-keys><ref-type name=”Thesis”>32</ref-type><contributors><authors><author>Krauser Jr, Edward William</author></authors></contributors><titles><title>Compiler-integrated software testing</title></titles><dates><year>1991</year></dates><publisher>Citeseer</publisher><urls></urls></record></Cite></EndNote>[26] اما همواره استفاده از کامپایلر یکپارچه سبب افزایش سرعت فرآیند تست نمیشود. برای پیدا کردن سرعت مناسب دو پارامتر به نام زمان کامپایل و زمان اجرا را مطرح میشود. در صورتیکه زمان اجرا > زمان کامپایل باشد، روش کامپایل مجزا سبب افزایش سرعت فرآیند تست میشود و زمانیکه زمان اجرا< زمان کامپایل باشد، روش کامپایلر یکپارچه روش مناسبی است ADDIN EN.CITE <EndNote><Cite><Author>May</Author><Year>2007</Year><RecNum>60</RecNum><DisplayText>[27]</DisplayText><record><rec-number>60</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>60</key></foreign-keys><ref-type name=”Thesis”>32</ref-type><contributors><authors><author>May, Peter S</author></authors></contributors><titles><title>Test data generation: two evolutionary approaches to mutation testing</title></titles><dates><year>2007</year></dates><publisher>Computing Laboratory</publisher><urls></urls></record></Cite></EndNote>[27]. از روشهای جدیدتر میتوان به روشهای ترجمهی “بایت کد” اشاره کرد ADDIN EN.CITE <EndNote><Cite><Author>Ma</Author><Year>2005</Year><RecNum>30</RecNum><DisplayText>[10]</DisplayText><record><rec-number>30</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>30</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Ma, Yu‐Seung</author><author>Offutt, Jeff</author><author>Kwon, Yong Rae</author></authors></contributors><titles><title>MuJava: an automated class mutation sys–</title><secondary-title>Software Testing, Verification and Reliability</secondary-title></titles><periodical><full-title>Software Testing, Verification and Reliability</full-title></periodical><pages>97-133</pages><volume>15</volume><number>2</number><dates><year>2005</year></dates><isbn>1099-1689</isbn><urls></urls></record></Cite></EndNote>[10] و ADDIN EN.CITE <EndNote><Cite><Author>Offutt</Author><Year>2004</Year><RecNum>33</RecNum><DisplayText>[28]</DisplayText><record><rec-number>33</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>33</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Offutt, Jeff</author><author>Ma, Yu-Seung</author><author>Kwon, Yong-Rae</author></authors></contributors><titles><title>An experimental mutation sys– for Java</title><secondary-title>ACM SIGSOFT Software Engineering Notes</secondary-title></titles><periodical><full-title>ACM SIGSOFT Software Engineering Notes</full-title></periodical><pages>1-4</pages><volume>29</volume><number>5</number><dates><year>2004</year></dates><isbn>0163-5948</isbn><urls></urls></record></Cite></EndNote>[28] که بیشتر در زبان جاوا کاربرد دارند. به طور کلی در این روشها جهشها تبدیل به بایت کد میشوند و از آنجاییکه کدهای “بایتکد” توانایی اجرا به صورت مستقیم بدون نیاز به کامپایل را دارند، در زمان انجام فرآیند تست صرفه جویی میشود.
روش کاهش دامنه
تکنیک کاهش دامنه در ابزاری به نام Godzilla ADDIN EN.CITE <EndNote><Cite><Author>DeMilli</Author><Year>1991</Year><RecNum>62</RecNum><DisplayText>[29]</DisplayText><record><rec-number>62</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>62</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>DeMilli, RA</author><author>Offutt, A. Jefferson</author></authors></contributors><titles><title>Constraint-based automatic test data generation</title><secondary-title>Software Engineering, IEEE Transactions on</secondary-title></titles><periodical><full-title>Software Engineering, IEEE Transactions on</full-title></periodical><pages>900-910</pages><volume>17</volume><number>9</number><dates><year>1991</year></dates><isbn>0098-5589</isbn><urls></urls></record></Cite></EndNote>[29] قرار گرفت. این روش به محدودیتهای تولید شده برای موارد تست برنامه به شکل یک فضای N جهته از مقادیر ورودی مینگرد که با استفاده از پیدا کردن مقادیر برای متغیرهای درون محدودیتهای کوچکتر و جانشانی آن در متغیرهای بزرگتر قادر به حل محدودیتها خواهد بود. تکنیک کاهش دامنه در CBT دارای پنج ایراد است: 1- قبل از شروع ارضاء محدودیتها، نیاز به در دسترس بودن تمام محدودیتها است. 2- چون تخصیص مقادیر به متغییرها به صورت تصادفی صورت میگیرد، ممکن است به یک متغییر چندین مقدار یکسان، تخصیص یابد. 3- فرآیند کاهش دامنه بسیار ساده است که با پیچیده شدن حالات نرمافزارهای واقعی نمیتواند عملکرد مناسبی داشته باشد. 4- با اجرای حقلهها مشکل دارد 5- ارایهها را به صورت یک متغییر در نظر میگیرد. برای حل برخی از مشکلات روش پیشین کاهش دامنهی پویا (DDR) ADDIN EN.CITE <EndNote><Cite><Author>Offutt</Author><Year>1999</Year><RecNum>65</RecNum><DisplayText>[30]</DisplayText><record><rec-number>65</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>65</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Offutt, A Jefferson</author><author>Jin, Zhenyi</author><author>Pan, Jie</author></authors></contributors><titles><title>The dynamic domain reduction procedure for test data generation</title><secondary-title>Software-Practice and Experience</secondary-title></titles><periodical><full-title>Software-Practice and Experience</full-title></periodical><pages>167-194</pages><volume>29</volume><number>2</number><dates><year>1999</year></dates><isbn>0038-0644</isbn><urls></urls></record></Cite></EndNote>[30] مطرح شد. برای شروع کار با این روش، نیاز به اطلاعاتی همچون گراف کنترل جریان برنامه، گره آغازی و گره پایانی و دامنه مقادیر تمام متغییرهای برنامه هست. سپس در گام اول مجموعهای متناهی از مسیرهای تست شناسایی پیموده و تحلیل میشوند. با استفاده از شرط مسیر پیموده شده محدودهی دامنه کوچکتر شده تا آنکه به محدودهی مورد نظر برسد برای اشکار شدن بیشتر موضوع، به مثال زیر توجه کنید: میخواهیم با استفاده از روش کاهش دامنهی پویا دامنه سه متغییر تابعی به نام MID (x,y,z) که هدف از آن پیدا کردن میانه بین سه متغییر است کاهش دهیم به طور پیش فرض دامنهی هر متغییر بین -10 تا 10 است. گراف کنترل جریان به در شکل(2-4) نشان داده است در این گراف گره آغازین 1 و گره پایانی 10 است حال فرض کنید بخواهیم مسیر 1-2-3-5-10 را مطابق آنچه که با خطوط نقطه چین نشان داده شده است طی کنیم در این مسیر سه شرط وجود دارد که دامنهی ورودی متغییرها را محدود خواهند کرد زمانیکه بخواهیم از مسیر بین 1-2 عبور کنیم که شرط آن به صورت y < z است نیاز به یک نقطه برای تقسیم دامنه داریم این نقطه را صفر در نظر میگیریم و دامنهی بین 10- تا 0 را به y و دامنهی بین 1 تا 10 را به z اختصاص میدهیم برای عبور از مسیر 2-3 که شرط آن x<= y است نقطهی تقسیم کنندهی دامنه را -5 در نظر میگیرم که دامنهی x بین ه تا -5 و دامنهی y بین -5 تا -10 است این فرآیند در شکل(2-5) نشان داده شده است.

شکل ( STYLEREF 1 s ‏2 SEQ شکل * ARABIC s 1 4):گراف کنترل جریان برنامهی MID ADDIN EN.CITE <EndNote><Cite><Author>Offutt</Author><Year>1999</Year><RecNum>65</RecNum><DisplayText>[30]</DisplayText><record><rec-number>65</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>65</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Offutt, A Jefferson</author><author>Jin, Zhenyi</author><author>Pan, Jie</author></authors></contributors><titles><title>The dynamic domain reduction procedure for test data generation</title><secondary-title>Software-Practice and Experience</secondary-title></titles><periodical><full-title>Software-Practice and Experience</full-title></periodical><pages>167-194</pages><volume>29</volume><number>2</number><dates><year>1999</year></dates><isbn>0038-0644</isbn><urls></urls></record></Cite></EndNote>[30]

شکل ( STYLEREF 1 s ‏2 SEQ شکل * ARABIC s 1 5): نمایش دامنه قبل و بعد از تقسیم ADDIN EN.CITE <EndNote><Cite><Author>Offutt</Author><Year>1999</Year><RecNum>65</RecNum><DisplayText>[30]</DisplayText><record><rec-number>65</rec-number><foreign-keys><key app=”EN” db-id=”svprvrfvddwpxbewt07xfwd4swr5pea2faz5″>65</key></foreign-keys><ref-type name=”Journal Article”>17</ref-type><contributors><authors><author>Offutt, A Jefferson</author><author>Jin, Zhenyi</author><author>Pan, Jie</author></authors></contributors><titles><title>The dynamic domain reduction procedure for test data generation</title><secondary-title>Software-Practice and Experience</secondary-title></titles><periodical><full-title>Software-Practice and Experience</full-title></periodical><pages>167-194</pages><volume>29</volume><number>2</number><dates><year>1999</year></dates><isbn>0038-0644</isbn><urls></urls></record></Cite></EndNote>[30]
روش اسکیما: از روشهایی مورد توجه در زمینه کاهش هزینه اجرا، روش تولید جهش اسکیما MSG ADDIN EN.CITE <EndNote><Cite><Author>Untch</Author><Year>1993</Year><RecNum>45</RecNum><DisplayText>[31]</DisplayText><record><rec-number>45</rec-number><foreign-keys><key app=”EN” db-id=”vzz9zwxx100zr3e0azr5s02v2rxev5wvs52t”>45</key></foreign-keys><ref-type name=”Conference Proceedings”>10</ref-type><contributors><authors><author>Untch, Roland H</author><author>Offutt, A Jefferson</author><author>Harrold, Mary Jean</author></authors></contributors><titles><title>Mutation analysis using mutant schemata</title><secondary-title>ACM SIGSOFT Software Engineering Notes</secondary-title></titles><pages>139-148</pages><volume>18</volume><number>3</number><dates><year>1993</year></dates><publisher>ACM</publisher><isbn>0897916085</isbn><urls></urls></record></Cite></EndNote>[31] است به طور کلی در این روش تکه برنامهای مشابه از برنامهی اصلی ایجاد شده که در آن مشخصههایی مانند شناساگرهای دادهها، ثابتها و … وجود ندارد و این مساله باعث افزایش سرعت کامپایل میشود. این روش از چهار متغییر اصلی (Meta Mutant) M، G (Mutagens) ،ِD ، Meta procedure تشکیل شده است برای تولید M برای برنامهی P ابتدا ابر جهش مورد نظر را از درون لیست تولید کنندهی جهش G که از مجموعهای از ابر رویهها است (به عنوان مثال ابر رویه عملگر جایگزینی حسابی *AOR در قطعه کد زیر نمایش داده شده است) انتخاب میشود.
PROCEDURE AOrr
(LeftOp,RightOp:REAL; ChangePt:INTEGER):REAL;
BEGIN
CASE Variant(ChangePt) OF
aoADD: RETURN LeftOp + RightOp; | aoSUB: RETURN LeftOp – RightOp; | aoMULT: RETURN LeftOp * RightOp; | aoDIV: RETURN LeftOp / RightOp; | aoMOD: RETURN LeftOp MOD RightOp; | aoRIGHT: RETURN RightOp; | aoLEFT: RETURN LeftOp;
ELSE Error( “AOrr CASE out of range” ); RETURN 0.0;END;
END AOrr;
پس از انتخاب و تولید جهش مورد نظر با استفاده از لیست توصیف کنندهی جهش D ارگومانهای ورودی ابر رویهی جهش، مقدار دهی میشود و بعد از آن بر روی برنامهی p اعمال و با مجموعهی تست تولید و اجرا میشوند در نهایت نیز امتیاز جهش، محاسبه میشود در شکل(2-6) این فرآیند نشان داده شده است. در کل این روش با جمع آوری برنامه اصلی و برنامهی جهش یافته در یک نسخهی برنامه سبب کاهش هزینهی فضای تست جهش میشود.

متن کامل و مطالب مشابه در سایت هماتز

« (Previous Post)
(Next Post) »

پاسخ دهید

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