اولویت بندی کارآمد موارد تست نرم افزار به کمک شبکه های بیزی- قسمت … |
۲-۱۱- طراحی نمونههای آزمایش
طراحی آزمایشهایی برای نرم افزار و محصولات مهندسی دیگر می تواند به اندازه طراحی اولیه خود محصول متغیر باشد. با این وجود، مهندسین نرم افزار اغلب با آزمایش به عنوان فعالیتی نهایی برخورد مینمایند، و نمونه های آزمایشی طراحی می کنند که ظاهرًا درست هستند اما اطمینان کمی از کامل بودن آنها وجود دارد. اهداف آزمایش را به خاطر آورید، بر اساس آنها آزمایشهایی باید طراحی شوند که احتمال بالایی برای یافتن اکثر خطاها، با حداقل مقدار زمان و فعالیت داشته باشند. مجموعه ای غنی از روشهای طراحی نمونههای آزمایش برای نرم افزار تکامل یافته اند . این روشها برای توسعه دهنده، روشی سیستماتیک را برای آزمایش فراهم می کنند. مهمتر اینکه، این روشها مکانیزمی را فراهم می کنند که به اطمینان از کامل بودن آزمایشها کمک می کند و احتمال بالایی برای کشف خطاهای نرم افزاری را نیز تضمین می نمایند.
هر محصول مهندسی و اکثر چیزهای دیگر میتواند به یکی از این دو روش زیر آزمایش شود:
با دانستن تابع خاصی که یک محصول برای انجام آن طراحی شده، آزمایشهایی طراحی می شوند که مشخص کنند هر تابع کاملاً عملیاتی است در حالیکه در عین حال در هر تابع برای یافتن خطاها جستجو نیز انجام می گیرد (آزمایش جعبه سیاه).
با دانستن عملکرد داخلی محصول، آزمایشها به گونه ای طراحی می شوند که تعیین نماید اعمال داخلی مطابق با مشخصه ها انجام میشوند و تمام مؤلفه های داخلی به طور مناسبی آزمایش می گردند(آزمایش جعبه سفید). [۱۵]
دانلود کامل پایان نامه در سایت pifo.ir موجود است. |
۲-۱۱-۱ تست جعبه سیاه[۷]
تست با هدف نشان دادن این که هر وظیفه مندی به درستی انجام میشود و نیز یافتن خطاها در زمینه وظیفه مندی را تست جعبه سیاه می گویند.
۲-۱۱-۲ تست جعبه سفید [۸]
تست کردن برای اطمینان از این که اعمال داخلی نرمافزار مطابق با مشخصات موردنظر کار میکنند و تمام مؤلفههای داخلی مورد امتحان قرار گرفتهاند، تست جعبه سفید نامیده میشود. در واقع این نوع تست، امتحان دقیق جزئیات روالی برنامه می باشد که در آن مسیرهای منطقی با ایجاد موارد تستی که مجموعهای از شرایط و حلقهها را بررسی می کنند، تست میشود.
۲-۱۱-۳ آزمایش ساختارکنترل
تکنیک آزمایش مسیر پایه توصیف شده، یکی از چند تکنیک آزمایش ساختار کنترلی است. اگرچه آزمایش مسیر پایه ساده و بسیار مفید است، ولی به تنهایی کافی نیست . این حالتها پوشش آزمایش را گسترش داده و کیفیت آزمایش جعبه سفید را افزایش می دهند.
۲-۱۱-۴ آزمایش واحد
آزمایش واحد، بر فعالیت بازبینی کوچک ترین واحد طراحی نرم افزار، که مؤلفه نرم افزار یا پیمانه نامیده می شود تمرکز دارد. با استفاده از توصیف طراحی در سطح مؤلفه به عنوان راهنما، مسیرهای کنترلی مهم آزمایش میشوند تا خطاهای موجود در مرز پیمانه پیدا شوند. پیچیدگی نسبی آزمایشها و خطاهای آشکار شده، بامحدوده ایجاد شده برای آزمایش واحد، محدود می شود. آزمایش واحد، گرایش به جعبه سفید دارد، واین مرحله میتواند به موازات برای چند مؤلفه هدایت شود.
۲-۱۱- ۵ خطاهای متداول محاسبه که اغلب مشاهده می شوند
اولویت محاسباتی نادرست
اعمال ترکیبی
آماده سازی غلط
عدم دقت کافی در محاسبه
نمایش غلط یک نماد محاسباتی
مقایسه و کنترل جریان تا حد زیادی به یکدیگر نزدیک هستند(یعنی تغییر جریان، معمولاَ بعد از مقایسه انجام میشود).
نمونههای آزمایش باید خطاهایی را از این قبیل آشکار نمایند:
مقایسه انواع داده متفاوت
عملگرهای منطقی یا اولویت نادرست
داشتن انتظار تساوی در زمانیکه خطا در دقت محاسبه باعث عدم تساوی می شود
مقایسه غلط متغیرها
خاتمه حلقه نامناسب یا عدم وجود خاتمه حلقه
شکست در خروج، زمانیکه حلقه نامتناهی تشخیص داده می شود
اصلاح نامناسب متغیرهای حلقه
۲-۱۲- آزمایش یکپارچه سازی[۹]
یک فرد مبتدی در دنیای نرم افزار ممکن است سؤالی به ظاهر ساده را بعد از اینکه آزمایش واحد بر روی تمام پیمانهها صورت گرفت بپرسد: “اگر همه آنها به تنهایی کار می کنند، چرا مشکوک هستید که آنها و قتی کنار هم قرار گیرند کار می کنند یا خیر؟“ این مشکل، کنار هم قرار دادن مولفه ها، یعنی ارتباط بین آنها است. داده ممکن است در یک ارتباط ناپدید شود . یک پیمانه ممکن است اثر نامطلوب و ناخواسته ای را بر دیگری داشته باشد. زیر توابع، زمانی که با هم ترکیب می شوند، ممکن است تابع بزرگ تر مورد نظر را تولید نکنند . مقادیر نا دقیقی که در هر یک به تنهایی پذیرفته شدهاند، ممکن است بزرگ شوند و به سطوح غیر قابل قبول برسند. ساختمان دادههای سراسری ممکن است مشکل ساز شود، این لیست همچنان به طور نگران کننده ای ادامه دارد. آزمایش یکپارچه سازی، روشی سیستماتیک برای ایجاد ساختار برنامه است درحالیکه، آزمایشها نیز انجام می شوند تا خطاهای مربوط به واسطها آشکار شوند . هدف، دریافت مؤلفههای آزمایش واحد و ایجاد ساختار برنامه ای است که توسط طراح دیکته شده است.
۲-۱۳- آزمایش رگرسیون (Regression Testing)
تجربه نشان داده است که به عنوان نرم افزار ثابت یا تکمیل شده، ظهور جدید یا ظهور مجدد خطاهای قدیمی کاملاَ رایج است. گاهی اوقات ظهور مجدد رخ میدهد به دلیل اینکه رفع آنها از طریق شیوههای کنترل ضعیف یا خطاهای ساده انسانی در کنترل روی میدهند. تست رگرسیون به طور قابل توجهی از سوی دانشگاهیان و افراد شاغل در زمینه تست نرم افزار در طول بیست سال گذشته کانون توجه قرار گرفته است. حتی استفاده از تکنیک های تست رگرسیون اغلب منجر به محصول نرم افزاری با کیفیت بالا شده است، اما اجراهای مکرر موارد تست میتواند بسیار پر هزینه باشد که نیمی از هزینه نگهداری سیستم نرم افزاری را به خود اختصاص میدهد. هردفعه که پیمانه جدیدی به عنوان بخشی از آزمایش یکپارچه سازی افزوده می شود، نرم افزار تغییرمیکند. مسیرهای جریان دادهی ایجاد میشوند ، I/O جدیدی ایجاد میگردد، و منطق کنترل جدیدی فراخوانی می شود . این تغییرات ممکن است باعث بروز مشکلاتی با توابعی شوند که قبلاً بدون خطا کار می کردند . در رابطه با استراتژی آزمایش یکپارچه سازی، آزمایش رگرسیون، اجرای مجدد زیر مجموعه ای از آزمایشهایی است که قبلاً انجام شدهاند تا اطمینان حاصل شود که تغییرات، باعث انتشار اثرات جانبی ناخواسته نشده اند. در محدوده وسیعتر، آزمایشهای موفقیت آمیز (ازهرنوع) باعث کشف خطاها می شوند، و خطاها باید اصلاح شوند. هر زمانیکه نرم افزار اصلاح میشود، جنبه ای از پیکر بندی نرم افزار (برنامه، مستندات، یا دادههایی که آنها را حمایت می کنند ) تغییر می نماید .آزمایش رگرسیون میتواند به صورت دستی هدایت شود . این عمل با اجرای مجدد زیر مجموعه ای از تمام نمونههای آزمایش، با استفاده از ابزارهای خودکارCapture/Playback انجام شود. ابزارهای Capture/Playback باعث می شوند مهندس نرم افزار نمونههای آزمایش را دریافت کند و با حرکت به عقب، مقایسههایی را انجام دهد .[۱۶]
مجموعه آزمایش رگرسیون (زیرمجموعه ای از آزمایشهایی که باید انجام شوند) شامل سه رده متفاوت از نمونههای آزمایش می باشد :
نمونههایی از آزمایشهایی که تمام عملکرد نرم افزار را بررسی می نمایند.
[جمعه 1399-09-21] [ 11:34:00 ق.ظ ]
|