دانلود پاورپوینت آشنایی با اصول آزمایش نرم افزار

تکنیک های آزمایش نرم  افزار

عنوان های پاورپوینت  : 

آشنایی با اصول آزمایش نرم افزار

تکنیک های آزمایش نرم  افزار

نگاهی گذرا

چه کسی  آن را انجام می دهد؟

دلیل اهمیت آن چیست ؟

مراحل انجام آن چیست؟

محصول کاری چیست؟

چگونه می توان از صحت انجام آن مطمئن شد؟

1-17 اصول آزمایش نرم افزار

1-1-17  اهداف آزمایش

2-1-17  اصول آزمایش

3-1-17  قابلیت آزمایش

تجزیه پذیری

2-17  طراحی ابزار آزمایش

3-17  آزمایش جعبه سفید

4-17  آزمایش مسیر مبنا

1-4-17  نشان گذاری گراف جریان

2-4-17  پیچیدگی دوره ای

تهیه ابزارهای آزمایش

4-4-17 ماتریس های گراف

آزمایش ساختار کنترل

1-5-17- آزمایش شرط

2-5-17 آزمایشجریان داده

17-5-3 آزمایش حلقه تکرار

حلقه های ساده.

حلقه های متداخل.

حلقه های احاق شده.

حلقه های بدون ساختار .

آزمایش جعبه سیاه

آزمایش ها برای پاسخ گویی به این سوالات مطرح می شوند :

1-6-17 روش های ازمایش بر مبنای گراف

2ـ6ـ17ـ تقسیم بندی مساوی

3ـ6ـ17 تحلیل مقدار مرزی

آشکارسازی تمام خطاهای دوگانه.

خطاهای چندگانه.

7ـ17 آزمایشی برای محیط ها، معماری ها و کاربردهای خاص

1ـ7ـ17 آزمایشی GUIها

2ـ7ـ17 آزمایش معماری سرویس دهنده ـ سرویس گیرنده

3ـ7ـ17 مستندسازی آزمایش و امکانات کمک

4ـ7ـ17 آزمایش سیستم های بلادرنگ

قسمت ها و تکه های اتفاقی از فایل

7ـ17 آزمایشی برای محیط ها، معماری ها و کاربردهای خاص

نرم افزار کامپیوتر پیچیده تر شده، و نیاز برای شیوه های آزمایش خاص نیز رشد نموده است. روشهای آزمایش جعبه سیاه و جعبه سفید بحث شده در بخش های 5ـ17 و 6ـ17 برای تمام محیط ها، معماری ها، و کاربردها قابل به کارگیری هستند، اما راهنمایی های منحصر به فرد و شیوه هایی برای آزمایش گاهی توصیه می شوند. در این بخش، راهنمایی های آزمایش برای محیط ها، معماری ها، و کاربردهای خاصی که به طور متداول مهندسین نرم افزار با آنها روبرو می شوند ارائه می گردد.

1ـ7ـ17 آزمایشی GUIها

رابط های کاربر گرافیکی (GUIها) زمینة جالبی را برای مهندسین نرم افزار ارائه می نمایند. به علت اجزاء قابل استفاده مجددی که به عنوان بخشی از محیط های توسعة GUI فراهم می شوند، ایجاد رابط کاربر زمان کمتری نیاز دارد و دقیق تر است. اما در عین حال، پیچیدگی GUI نیز افزایش یافته است، و باعث مشکلات بیشتر در طراحی و اجرای ابزارهای آزمایش می شود.

چون بسیاری از GUIهای مدرن، احساس و جلوة یکسانی دارند، یک سری از آزمایشهای استاندارد قابل ایجاد است. گرافهای مدلسایز حالت محدود می توانند استفاده شوند تا یک سری آزمایشهایی را ایجاد کنند که اشیاء و داده های خاص مربوط به GUI برنامه را مورد توجه قرار دهند.

2ـ7ـ17 آزمایش معماری سرویس دهنده ـ سرویس گیرنده

معماری های سرویس دهنده ـ سرویس گیرنده (C-S) موارد مهمی را برای آزمایش کننده های نرم افزار نشان می دهند. ماهیت توزیع شدة محیط های C-S، موارد کارایی مربوط به پردازش تراکنش، حضور بالقوة سکّوهای سخت افزاری متفاوت، پیچیدگیهای ارتباط شبکه، نیاز برای سرویس دادن به چندین سرویس گیرنده از بانک اطلاعاتی متمرکز (یا توزیع شده)، و نیازهای هماهنگ سازی تحمیل شده بر سرویس دهنده، همگی ترکیب می شوند و باعث می شوند آزمایش معماری C-S، و نرم افزاری که بر روی آنها قرار می گیرد، تا حد قابل توجهی مشکل تر از کاربردهای مجزا باشد. در واقع، مطالعات اخیر صنایع نشان می دهد که افزایش عمده ای در زمان و هزینة آزمایش محیط های C-S وجود دارد.

3ـ7ـ17 مستندسازی آزمایش و امکانات کمک

واژة آزمایش نرم افزار، شامل تصاویری از تعداد زیادی از ابزارهای آزمایش می باشد که برای بررسی برنامه های کامپیوتری و داده هایی که دستکاری می کنند آماده شده اند. تعریف نرم افزار را که در اولین فصل این کتاب ارائه شد به خاطر آورید، توجه به این نکته مهم است که آزمایش باید به سومین عنصر پیکربندی نرم افزار، یعنی مستندات، توسعه یابد.

خطاها در مستندات می توانند به همان اندازة خطاها در کد مبدأ برنامه یا داده ها، باعث اشکالاتی در قبول برنامه شوند. هیچ چیز نگران کننده تر از این نمی باشد که راهنمای کاربر یا امکان کمک سیستم دقیقاً دنبال شود و به نتایج یا رفتاری منتهی شود که منطبق با آنچه توسط مستندات پیش بینی شده نباشد. به این دلیل است که آزمایش مستندات باید بخش معنی داری برای هر طرح آزمایش نرم افزار باشد.

آزمایش مستندات در دو فاز قابل انجام است. اولین فاز که مرور و بازبینی نام دارد (فصل 8)، مستندات را برای وضوح ویرایشی بررسی می کند. فاز دوم، که آزمایش زنده نام دارد، مستندات را همراه با استفاده از برنامة واقعی، مورد استفاده قرار می دهد.

به شکل تعجب آوری، آزمایش زنده برای مستندات با استفاده از تکنیک هایی مشابه بسیاری از روشهای جعبه سیاه بحث شده در بخش 6ـ17، قابل انجام است. آزمایش بر مبنای گراف می تواند استفاده شود تا استفاده از برنامه را توصیف کند. تقسیم بندی مساوی و تحلیل مقدار مرزی برای تعریف رده های گوناگون ورودی وارتباطات مربوط به آنها استفاده می شوند. سپس استفاده از برنامه از طریق مستندات پیگیری می شود. سئوالات زیر باید در طول هر دو فاز پاسخ داده شوند:

4ـ7ـ17 آزمایش سیستم های بلادرنگ

ماهیت وابسته به زمان و غیر همزمان بسیاری از کابردهای بلادرنگ، عنصری جدید و احتمالاً مشکل را به نام زمان به آزمایش می افزاید. طراح ابزار آزمایش باید ابزارهای آزمایش جعبه سفید و جعبه سیاه را همراه، با ادارة واقعه (یعنی پردازش وقفه)، زمانبندی داده ها، و موازی بودن taskهای اداره کنندة داده ها در نظر داشته باشد. در بسیاری از موارد، داده های آزمایش زمانی فراهم می شوند که سیستم بلادرنگ در یک حالت خاص قرار دارد و باعث تولید پردازش مناسب می شود، در حالی که همان داده ها اگر زمانی به سیستم داده شوند که در حالت دیگری قرار دارد، ممکن است باعث بروز خطا شوند.

برای مثال، نرم افزار بلادرنگی که دستگاه کپی جدیدی را کنترل می کند، وقفه های اوپراتور را بدون خطا می پذیرد (یعنی اوپراتور ماشین کلیدی کنترلی مانند RESET یا DARKEN را می زند)، وقتی ماشین در حال گرفتن کپی ها است (در حالت “کپی” قرار دارد). همین وقفه های اوپراتور، اگر در حالت “جمع شدن کاغذ” وارد شوند، باعث نمایش کد شناسایی می شوند تا محل جمع شدن کاغذ را که باید برطرف شود مشخص نمایند (خطا).

علاوه بر آن، رابطه نزدیک بین نرم افزار بلادرنگ و محیط سخت افزاری نیز باعث می شود آزمایش با مشکل روبرو شود. آزمایشهای نرم افزار باید تأثیر خطاهای سخت افزار را بر پردازش نرم افزار در نظر بگیرند. شبیه سازی چنین اشکالاتی ممکن است بسیار مشکل باشد.

روشهای طراحی ابزارهای طراحی برای سیستم های بلادرنگ هنوز در حال تکامل است. به هر حال، یک استراتژی کلی چهار مرحله ای پیشنهاد می شود:

آزمایش task: اولین مرحله در آزمایش نرم افزار بلادرنگ، آزمایش هر task به طور مستقل می باشد. یعنی آزمایشهای جعبه سفید و جعبه سیاه برای هر task طراحی و اجر شوند. هر task به طور مستقل در ضمن این آزمایشات اجرا می شود. آزمایش task خطاهایی را در منطق و عملکرد آشکار می کند، اما خطاهای زمانبندی و رفتاری آشکار نمی شوند.

آزمایش رفتاری. با استفاده از مدلهای سیستم هایی که با ابزارهای CASE ایجادشده اند، امکان شبیه سازی رفتار سیستم بلادرنگ و آزمایش رفتار آن در نتیجة وقایع خارجی، وجود دارد. این فعالیت های تحلیل، مبنایی را فراهم می کنند برای طراحی ابزارهای آزمایشی که در زمان ایجاد نرم افزار بلادرنگ هدایت می شوند. با استفاده از تکنیکی مشابه تقسیم بندی مساوی (بخش 1ـ6ـ17)، وقایع (برای مثال، وقفه ها، سیگنالهای کنترل) برای آزمایش دسته بندی می شوند. برای مثال، وقایعی برای دستگاه فتوکپی عبارتند از: وقفه های کاربر (برای مثال، صفر کردن شمارنده)، وقفه های مکانیکی (برای مثال، جمع شدن کاغذ)، وقفه های سیستم (برای مثال، کم شدن پودر قرمز)، و مودهای شکست (برای مثال، سربار رولر). هر یک از این وقایع به طور مجزا آزمایش می شوند و رفتار سیستم اجرایی آزمایش می گردد تا خطاهایی در نتیجة پردازش مربوط به این وقایع، آشکار شوند. رفتار مدل سیستم (که در ضمن فعالیت تحلیل توسعه داده شده) و نرم افزار اجرایی برای مسائل کارایی مقایسه می شوند.

پس از آزمایش هر رده از وقایع، وقایع به ترتیب تصادفی و با تکرار تصادفی به سیستم داده می شوند. رفتار سیستم آزمایش می شود تا خطاهای رفتاری آشکار گردند.

آزمایش بین taskها: پس از جدا شدن خطاهای هر یک از task ها و رفتار سیستم، آزمایش به سمت خطاهای زمانی هدایت می شود. Taskهای غیر همزمان که با یکدیگر ارتباط برقرار می کنند، با سرعت انتقال داده ها و بار پردازش متفاوت آزمایش می شوند تا مشخص کنند آیا خطاهای همزمانی ارتباط بین taskها اتفاق می افتد یا خیر. علاوه بر آن، taskهایی که با استفاده از صف پیغام یا حافظة داده ها ارتباط برقرار می نمایند آزمایش می گردند تا خطاهای مربوط به اندازة این ناحیه های حافظه آشکار شوند.

آزمایش بین taskها: پس از جدا شدن خطاهای هر یک از task ها و رفتار سیستم، آزمایش به سمت خطاهای زمانی هدایت می شود. Taskهای غیر همزمان که با یکدیگر ارتباط برقرار می کنند، با سرعت انتقال داده ها و بار پردازش متفاوت آزمایش می شوند تا مشخص کنند آیا خطاهای همزمانی ارتباط بین taskها اتفاق می افتد یا خیر. علاوه بر آن، taskهایی که با استفاده از صف پیغام یا حافظة داده ها ارتباط برقرار می نمایند آزمایش می گردند تا خطاهای مربوط به اندازة این ناحیه های حافظه آشکار شوند.

آزمایش سیستم: نرم افزار و سخت افزار مجتمع می شوند و محدودة کاملی از آزمایشهای سیستم (فصل 18) هدایت می شوند تا خطاهای ارتباط سخت افزار ـ نرم افزار آشکار شود. اکثر سیستم های بلادرنگ، وقفه ها را پردازش می کنند. بنابراین، آزمایش ادارة این وقایع بولی ضروری است. با استفاده از نمودار تغییر حالت و مشخصة کنترل (فصل 12)، آزمایش کننده، لیستی از تمام وقفه های ممکن و پردازش هایی را که در نتیجة آن وقفه ها انجام می شوند توسعه می دهد. سپس آزمایشهایی طراحی می شوند تا به خصوصیات سیستم که در زیر ارائه شده برسند:

30 تا 70 درصد پروژه | پاورپوینت | سمینار | طرح های کارآفرینی و  توجیهی |  پایان-نامه |  پی دی اف  مقاله ( کتاب ) | نقشه | پلان طراحی |  های آماده به صورت رایگان میباشد ( word | pdf | docx | doc )