دانلود رایگان ترجمه مقاله ایجاد مورد آزمایشی مبتنی بر جهش (سال 2016)

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

به عنوان یک ابزار TCG جعبه سیاه، MoMuT::UML نیاز به یک محیط تست جهش قوی دارد، که بدان معنی است که آن تنها می تواند شامل یک جهش شناسایی (“خاتمه یافته “) باشد، اگر جهش یک تفاوت در رفتار قابل مشاهده نسبت به اصلی نشان دهد. رابطه انطباق که ما برای تست استفاده می کنیم، انطباق ورودی-خروجی Tretman است [17]، که در سیستم های انتقال برچسب شده تعریف می شود و گفته می شود که هر گونه مشاهده که بتواند از سیستم تحت تست (SUT) بعد از یک اثر خاص ایجاد شود، باید توسط مدل پیش بینی شود. توجه داشته باشید که اگر SUT فقط یک زیرمجموعه از مشاهدات ممکن تولید کند، آن هنوز خوب است. برای تعریف رسمی ioco و LTS، ما به Tretman [17] مراجعه می کنیم.
شکل 1 یک مرور کلی از معماری MoMuT را نشان می دهد. ابزار به عنوان فایل .jar توزیع شده و یک پایان جلو ، نوشته شده در جاوا، با یک پایان عقب را ترکیب می کند که در C++11 نوشته شده است. در حالی که پایان جلو برای چک کردن ورودی معتبر است، پایان عقب کار واقعی را انجام می دهد. توجه داشته باشید که پایان جلو و عقب توسط بافرهای پروتکل گوگل از هم جدا می شوند، بنابراین آن ممکن است از پایان عقب به طور مستقل استفاده کند. به عنوان ورودی، MoMuT::UML ممکن است از نمودارهای حالت UML یا سیستم-های عمل شیء گرا (OOAS) استفاده کند. اگر یک مدل UML – شامل نمودار حالت، نمودار کلاس، و نمودار نمونه – استفاده شود، MoMuT ابتدا آن را به کد OOAS ترجمه می کند [10]. مرحله بعد اضافه کردن جهش ها به مدل است. همانطور که در شکل مشاهده می کنید، این در سطح OOAS انجام می شود. استفاده از جهش ها به طور مستقیم برای OOAS، مزیت قابل اجرا بودن برای تمام زبان های پایان جلو است (نه تنها UML). چیزی که ممکن است دیده شود احتمال معرفی “جهش های UML معنایی” به عنوان یک نقطه ضعف است، اما از آنجایی که نگاشت UML به OOAS، ساختار مدل UML را حفظ می کند، اکثریت جهش ها دارای یک نگاشت یک به یک به UML هستند. برای مثال، عملگر جهش غیر فعال کردن یک نقشه فرمان محفوظ به غیر فعال کردن انتقال در مدل UML.
جدول 2 یک مرور کلی از عملگرهای جهش استفاده شده در آزمایش های شرح داده شده در این مقاله ارائه می-کند. بعد از اضافه کردن جهش، OOAS برای کد ماشین اجرا می شود و سرانجام مرحله تولید مورد تست آغاز می شود. مانند تمام ابزارهای تست مدل، MoMuT موارد تست در سطح انتزاع از مدل تحویل می دهد – به عبارت دیگر موارد تست انتزاعی [19]. از این رو قبل از اجرای هر تست در SUT، آنها ممکن است نیاز به واقعی شدن داشته باشند. به عنوان یک فرمت خروجی مورد تست، MoMuT فرمت دبران را استفاده می کند، اما یک نقطه نمودار را نیز می نویسد.

2.1 زبان ورودی: سیستم های عمل شیء گرا
OOAS یک زبان مدل سازی مناسب هستند که دارای معناشناسی رسمی هستند، نسبتاً ساده هستند، و به خوبی برای بیان سیستم انتقال حالت گسسته مناسب هستند. یک مثال از OOAS می تواند در سایت www.momut.org یافت شود. این زبان بر اساس یک تعمیمی از زبان فرمان محفوظ دیکسترا [14] و فرمالیسم سیستم عمل برگشت [5] است. این شبیه به رویداد-B در برخی مفهوم است، اگرچه از نظر دستورات و اقدامات محفوظ کمتر محدود است.

شکل 2 یک مدل نمونه در MoMuT::UML در حال تجزیه را نشان می دهد. هر سیستم عمل ممکن است ویژگی ها، روش ها، اقدامات برچسب شده، و یک بلوک do-od را اعلام کند، که اجرا را تحریک می کند. تا زمانی که یک عمل در بلوک do-od می تواند اجرا شود، بلوک تکرار کردن را ادامه می دهد. MoMuT:UML چندین تعمیم برای سیستم عمل اصلی را استفاده می کند، یکی از اقدامات برچسب شده است. عمل می تواند با “obs” (قابل مشاهده)، “ctr” (قابل کنترل) و یا نه، علامت دار شود، که به این معنی است که آن یک عمل درونی است. توجه کنید که ما بازگشت را در OOAS نمی پذیریم و همچنین حلقه ها را ارائه نمی دهیم (به استثنای بلوک do-od). در عوض، زبان یک عملگر برابر فراهم می کند. انواع داده ها، از جمله فهرست ها و اعداد صحیح، نیاز به اعلام شدن با کران ها دارند. دسترسی مستقیم به ویژگی های اشیاء دیگر ممنوع است. در عوض، روش گیرنده/گذارنده استفاده می شود.
توضیحات می توانند با ترتیبی (“;”)، غیر قطعی (“[]”)، یا اولویت بندی (“//”) عملگرهای ترکیب، ترکیب شوند. نمونه شیء فقط روی ویژگی های مقداردهی اولیه به عنوان MoMuT::UML مجاز است که مجموعه ای از اشیاء مؤثر در زمان اجرا را محاسبه می کند. فراخوانی روش روی شیء (late-binding) پشتیبانی نمی شود. ویژگی های زبان یک راه برای بیان یک سیاست برنامه ریزی ساده: بر اساس سیستم، اشیاء می توانند با توجه به اولویت (“//”) روی اشیاء سیستم های دیگر باشند. ویژگی نهایی زبان، پروژه نامیده می شود. با توجه به جمله var input: t_UserAction: c_userAction(input) که در آن t_UserAction یک شمارنده با مقدار SetPause…StopMeasurment است، سیستم برای اجرای c_userAction با تمام مقادیر ممکن t_UserAction تلاش خواهد کرد. به طور متفاوت، آن یک مخفف است برای گفتن c_userAction(SetPause) [] … [] c_userAction(StopMeasurement).
تفاوت اصلی بین OOAS و زبان های متعارف، راه ترکیب متوالی کارها همراه با دستورات محافظت شده (“نیاز”) است. اگر ما یک جمله نیاز (A): skip end، نیاز(B): skip end داشته باشیم، سیستم ابتدا بررسی می کند که آیا A و B برآورده می شوند در زمان مورد نیاز قبل از اجرای جمله ترکیب شده. این سیستم، به عبارت دیگر، نیاز به محاسبه قابل فعال بودن اعمال دارد. برای مدل انیمیشن این بدان معنی است که نوعی از عقبگرد الزامی است. همچنین، چنانکه همزمانی از طریق انتخاب غیر قطعی بیان می شود، یک موتور جستجو کارآمد مورد نیاز است، در هنگام محاسبه تمام آثار ممکن از طریق OOAS.

با توجه به تمام راه های مختلف ترکیب اعمال در راه های غیرمتوالی، آن جالب توجه است که چگونه بسیاری از سطوح عمقی این ساختارها معمولاً تو در تو است. شکل 3 یک برش از گراف تصمیم گرفته شده از مدل ایستگاه راه آهن بزرگ را نشان می دهد. گره قرمز بلوک اولیه است، که بخشی از زمانبندی است. این جایی است که اجرا شروع می شود. تمام دیگر گره ها، رنگی شده، گره ها نشان دهنده نقاط عقب گرد/تصمیم هستند. گره خاکستری برای ترکیب اولیه، گره نارنجی برای ترکیب غیرقطعی، و گره بنفش برای تصویر (خود حلقه نشان دهنده مقدار ارزش برای امتحان کردن است) استفاده می شود. گره های سفید نشان دهنده یک پایان ، بلوک متوالی است. همانطور که دیده می شود، نگاشت UML معمولاً ساختارهای عقب گرد بسیار عمیق تولید نمی کند. با این حال، این یک نگرش ایستا است و عملگرهایی مانند fold، foral و با جزئیات کامل را به حساب نمی آورد.

3. یک معماری برای جهش کوتاه مدت
در مقایسه با تولید های قبلی MoMuT::UML، تغییرات مهم معماری (a) کامپایل به موقع محلی ، (b) فشرده سازی جهش از طریق طرح، (c) اتخاظ روش های کاهش سفارش جزئی، و (d) نمونه پویا از جهش کوتاه مدت، هستند. به منظور تسهیل در این تغییرات، پایان عقب به طور کامل با تمرکز بر عملکرد بازنویسی می شود.
گام اول نسبت به این هدف، اجرای محلی مدل OOAS است. این جایی است که MoMuT متکی بر چارچوب کامپایلر LLVM [11] برای کامپایل به موقع مدل باشد. از آنجا که OOAS ذاتاً غیر قطعی هستند و نیاز به عقبگرد دارند، اولین نمونه اصلی، کد را برای جستجو عقبگرد در نمایش واسط LLVM (LLVM-IR) از مدل در خط می کند. با این حال، اثبات بسیار ضعیف (منطق حفظ پشته، ناتوانی برای مقایسه حالت های میانی، الگوریتم جستجوی ثابت)، بنابراین ما به رویکرد اجرای رو به جلو روی می آوریم. اجرای رو به جلو به این معنی است که هیچ عقبگردی در داخل مدل وجود ندارد. در عوض، در حین اجرا، مدل کامپایل شده درخواست اجزاء زمانبندی خارجی می کند، که بخشی از زمان اجرا ارائه شده توسط MoMuT است، که جایگزینی برای گرفتن است. این برای یک ردیابی در بلوک do-od در یک زمان انجام می شود. در مورد زمانبندی کردن هدایت موتور اجرا برای برخی از دستور محافظت که غیرفعال است، اجرا لغو شده و زمانبند در مورد نتیجه مطلع می شود.

در نمودار کلاس ساده شده شکل 4، کلاس های FWTraceExecutor و FWDfsScheduler چارچوب اجرای اساسی را می سازند. توجه داشته باشید که اجرای رو به جلو در مورد ما، به عنوان اعمال در داخل یک تکرار بلوک do-od از یک سیستم که توابع بسیار پیچیده ریاضی را محاسبه نمی کند ، کار می کند. بنابراین زمان صرف شده برای محاسبه دوباره نتایج، ناچیز است.
با استفاده از این چارچوب اجرای ساده مبتنی بر ردیابی به عنوان پایه، MoMuT::UML موفق در اضافه کردن یک جستجوگر عمومی (FWExplorerGeneric) شده و یکی که سفارشات جزئی (FWPartialOrderExplorer) را در بالا به حساب می آورد. در واقع برای تولید موارد تست، یک نمونه از کلاس FETcgGraphExplorer می تواند استفاده شود. این کلاس FWPartialOrderExplorer را می-گیرد و منطق برای ایجاد یک نمودار تست را می افزاید. منطقی که استراتژی جهش کوتاه مدت را ایجاد می کند، در FWOtfTaskmaster پیاده سازی می شود. این کلاس دارای مجموعه ای از کارگران (FWOtfWorker) است و وظایف اکتشاف را مدیریت می کند (FWOtfTask). هر کارگر در رشته خود اجرا می شود و یک نمونه از FWOtfExplorer را دارا است، یک زیر کلاس از FWTcgGraphExplorer.
در مجموع، معنی که شامل موتور عقب گرد است، MoMuT::UML شامل حدود 74600 LoC جاوا است، و 59300 LoC کدهای C++. بخش جاوا از کامپایلر OOAS اخیراً تحت BSD منتشر شده و در www.momut.org موجود است. ما در حال حاضر به دنبال گزینه های ساخت منبع C++ در دسترس تحت برخی مجوز تحقیقات دانشگاهی هستیم.