توجه : این پروژه به صورت فایل power point (پاور پوینت) ارائه میگردد
پاورپوینت تکنیک های آزمایش نرم افزار pdf دارای 51 اسلاید می باشد و دارای تنظیمات کامل در Power Point می باشد و آماده پرینت یا چاپ است
فایل پاور پوینت پاورپوینت تکنیک های آزمایش نرم افزار pdf کاملا فرمت بندی و تنظیم شده در استاندارد دانشگاه و مراکز دولتی می باشد.
این پروژه توسط مرکز مرکز پروژه های دانشجویی آماده و تنظیم شده است
لطفا به نکات زیر در هنگام خرید
دانلود پاورپوینت تکنیک های آزمایش نرم افزار pdf
توجه فرمایید.
1-در این مطلب، متن اسلاید های اولیه
دانلود پاورپوینت تکنیک های آزمایش نرم افزار pdf
قرار داده شده است
2-به علت اینکه امکان درج تصاویر استفاده شده در پاورپوینت وجود ندارد،در صورتی که مایل به دریافت تصاویری از ان قبل از خرید هستید، می توانید با پشتیبانی تماس حاصل فرمایید
3-پس از پرداخت هزینه ، حداکثر طی 12 ساعت پاورپوینت خرید شده ، به ادرس ایمیل شما ارسال خواهد شد
4-در صورت مشاهده بهم ریختگی احتمالی در متون زیر ،دلیل ان کپی کردن این مطالب از داخل اسلاید ها میباشد ودر فایل اصلی این پاورپوینت،به هیچ وجه بهم ریختگی وجود ندارد
5-در صورتی که اسلاید ها داری جدول و یا عکس باشند در متون زیر قرار داده نشده است
بخشی از متن پاورپوینت تکنیک های آزمایش نرم افزار pdf :
اسلاید 1 :
تکنیک های آزمایش نرم افزار
اهمیت آزمایش نرم افزار و اثرات آن بر کیفیت نرم افزار نیاز به تأکید بیشتر ندارد. Deutch در این باره اینگونه بیان می نماید :
توسعه سیستم های نرم افزاری شامل یک سری فعالیت های تولید می باشد که امکان اشتباهات انسانی در آن زیاد است. خطاها در ابتدای یک فرآیند و مراحل توسعه بعدی آن ظهور می نمایند که اهداف با خطا یا به صورت ناقص مشخص شده باشند. به دلیل عدم توانایی انجام کارها و برقراری ارتباط به صورت کامل، توسعه نرم افزار با فعالیت تضمین کیفیت همراه است.
آزمایش نرم افزار عنصری حیاتی از تضمین کیفیت نرم افزار می باشد و مرور تقریبی مشخصه، طراحی، و تولید کد را نشان می دهد.
قابلیت رویت در حال افزایش نرم افزار به عنوان عنصری از سیستم، و هزینه های مربوط به شکست نرم افزار، نیروهای محرکی هستند برای برنامه ریزی خوب از طریق آزمایش. برای یک سازمان توسعه نرم افزار، غیرمعمول نیست که بین 30 تا 40 درصد کل فعالیت پروژه را برای آزمایش صرف کند. در نهایت، آزمایش نرم افزاری که برای انسان حیاتی است (برای مثال، کنترل پرواز، نظارت راکتور هسته ای) سه تا پنج برابر، هزینه بیشتر از تمام مراحل مهندسی نرم افزار را در مجموع خواهد داشت. در این فصل، اصول بنیادی آزمایش نرم افزار اهداف قابل تغییری را برای آزمایش نرم افزار تعریف می نما یند. طراحی ابزار آزمایش بر مجموعه ای از تکنیک ها برای ا یجاد ابزارهای طراحی که اهداف کلی آزمایش را برآورده نمایند تأکید دارند. در فصل 18 ، استراتژی های آزمایش و اشکال زدایی نرم افزار ارائه می گردند .
اسلاید 2 :
نگاهی گذرا
در مورد چه چیزی بحث می شود؟
پس از تولید کد مبدأ، نرم افزار باید مورد آزمایش قرار گیرد تا هر تعداد خطا را که ممکن است، قبل از تحویل به مشتری کشف (و تصحیح) نماید. هدف طراحی یک سری ابزارهای آزمایش می باشد که با احتمال بالایی خطاها را می یابند، اما چگونه؟ در این مرحله است که تکنیک های آزمایش نرم افزار ظاهر می شوند. این تکنیک ها، راهنمایی سیستماتیک را برای آزمایش هایی فراهم می کنند که
(1) منطق داخلی مؤلفه های برنامه را مورد آزمایش قرار می دهد
(2) محدوده ها ی ورودی و خروجی برنامه را آزمایش می کند تا خطاهایی را در عملکرد، رفتار، و کارایی برنامه بیابد.
چه کسی آن را انجام می دهد؟
در ضمن مراحل اولیه آزمایش، مهندسی نرم افزار تما آزمایشها را انجام می دهد. به هر حال، با پیشرفت فرآیند آزمایش، متخصصین آزمایش نیز ظاهر می شوند .
اسلاید 3 :
دلیل اهمیت آن چیست ؟
مرورها و فعالیت های SQA ، خطاها را آشکار می نمایند، ا ما کافی نیست. با هر اجرای برنامه، مشتری آن را آزمایش می نماید! بنابراین، باید برنامه قبل از مشتری اجرا گردد، با هدف یافتن و حذف تمام خطاها، به منظور یافتن بیشترین خطاها، آزمایشها باید بطور سیستماتیک هدایت شوند و ابزارهای آزمایش باید با استفاده از تکنیک‌های خاص طراحی گردند.
مراحل انجام آن چیست؟
نرم افزار از دو نما مورد آزمایش قرار می گیرد. نیازهای نرم افزار با استفاده از تکنیک های طر احی ابزارهای آزمایش جعبه سیاه مورد آزمایش قرار می گیرند. در هر دو حالت، هدف یافتن حداکثر تعداد خطاها با حداقل مقدار فعالیت و زمان می باشد.
محصول کاری چیست؟
مجموعه ای از ابزارهای آزمایش، برای آزمایش منطق داخلی و نیازهای خارجی برنامه، طراحی و مستند سازی می شوند. نتایج مورد انتظار تعریف می‌شوند، و نتایج واقعی ثبت می گردند .
چگونه می توان از صحت انجام آن مطمئن شد؟
هنگام شروع آزمایش، دیدگاه خود را تغییر دهید. سعی کنید کار نرم افزار را مختل کنید! ابزارهای آزمایشی به صورت اصولی طراحی کنید و این ابزارهای آزمایش ایجاد شده را برای قوت آن ها مرور نماید
اسلاید 4 :
1-17 اصول آزمایش نرم افزار
آزمایش، موارد غیرمعمول جالبی را برای مهندس نرم افزار آشکار می نماید. در ضمن فعالیت های اولیه مهندسی نرم افزار، مهندس، سعی در ایجاد نرم افزار با استفاده از مفهومی مجرد و بدست آوردن محصولی و اضع و کامل دارد . اینک آزمایش باید انجام شود. این مهندس یک سری ابزار آزمایش ایجاد می کنئد که باید نرم افزار ایجاد شده را با شکست روبرو نمایند. در واقع، آزمایش، یک مرحله در فرآیند نرم افزار است که می تواند به عنوان فرآیندی مخرب به جای سازنده در نظر گرفته شود (حداقل از نظر روانشناسی).
طبیعت مهندسین نرم افزار سازندگی است. آزمایش نیازمند این است که توسعه دهنده، نکات اولیه صحت نرم افزار را صرف نظر کند و بر تناقض ایجاد شده در نتیجه تشخیص خطا غلبه نماید . Beizer این وضعیت را به این صورت بیان می کند :
نکته غیر قابل باوری وجود دارد که اگر در برنامه نویسی به خوبی در نظر گرفته شود، خطایی برای یافتن وجود نخواهد داشت. اگر امکان تمرکز واقعی وجود داشته باشد، اگر همه از برنامه نویسی ساخت یافته، طراحی بالا به پایین ، و جداول تصمیم گیری استفاده کنند، اگر ابزار صحیح را در اختیار داشته باشیم، خطایی نیز وجود نخواهد داشت. خطاها وجود دارند، چون آنچه انجام می دهیم کاملاً درست نیست، و اگر این کارها درست انجام نشوند، در مورد آنها گناهکار هستیم. بنابراین، آزمایش و طراحی ابزار آزمایش، پذیرش شکست است، که به تدریج به گناه پذیرفته شده تبدیل می شود. و انجام آزمایش، تنبیهی است برای این خطاها. تنبیه برای چه؟ برای انسان بودن؟ گناه برای چه؟ برای شکست در رسیدن به تکامل؟ برای تشخیص ندادن بین آنچه یک برنامه نویس فکر می کند و آنچه بیان می کند؟ برای شکست در برقراری ارتباط تله پاتی؟ برای عدم حل مشکلات ارتباطات انسانی که به وجود می آیند; برای چهارده قرن؟
آیا آزمایش احساس گناه است؟ آیا آزمایش واقعاً مخرب است؟ پاسخ به این سئوالات «خیر» است! به هر حال، هدف از آزمایش چیزی است متفاوت از آنچه انتظار می رود.
اسلاید 5 :
1-1-17 اهداف آزمایش
در کتابی در مورد آزمایش نرم افزار، Glen Myers چند قانون را بیان می کند که اهداف مناسبی برای آزمایش هستند :
üآزمایش فرآیندی است شامل اجرای برنامه با هدف یافتن خطا .
üیک ابزار آزمایش خوب، ابزاری است که با احتمال بالایی خطای یافت نشده را بیابد.
üآزمایش موفق، آزمایشی است که خطاهای یافت نشده تاکنون را بیابد.
این اهداف تغییری دراماتیک را در دیدگاه ایجاد می نمایند . این اهداف باعث تغییر در دیدگاه متداولی می شوند که آزمایش موفق را آن نوع آزمایش می داند که در آن خطایی یافت نشود. هدف، طراحی آزمایشهایی است که به طور سیستماتیک رده های متفاوتی از خطاها را آشکار نمایند، و این عمل را با حداقل مقدار زمان و فعالیت انجام دهند.
اگر آزمایش با موفقیت هدایت شود (بر طبق اهداف بیان شده)، خطاها را در نرم افزار آشکار خواهد نمود. به عنوان فایده ثانویه، آزمایش بیان می دارد که به نظر می رسد توابع و نرم افزار بر طبق مشخصه عمل می کنند، و نیازهای رفتاری و کارایی برآورده شده اند. علاوه بر آن، داده های جمع آوری شده در ضمن هدایت آزمایش، نمایش خوبی برای قابلیت اطمینان نرم افزار و کیفیت کلی نرم افزار می باشد. اما آزمایش، عدم وجود خطاها و اشکالات را نشان نمی دهد، فقط می تواند نشان دهد که خطاها و اشکالات نرم افزار وجود دارند. در ضمن هدایت مراحل آزمایش، به خاطر سپردن این نکته مهم است.
اسلاید 6 :
2-1-17 اصول آزمایش
قبل از به کارگیری روشهای طراحی ابزارهای موثر آزمایش, مهندس نرم افزار بایداصول اولیه ای را که آزمایش نرم افزار را هدایت می کنند بفهمد. Davis مجموعه ای از اصول آزمایش را پیشنهاد می کند که در این کتاب استفاده شده اند :
تمام آزمایشها باید براساس نیازهای مشتری قابل پیگیری باشند. همانگونه که مشاهده شد, هدف از آزمایش نرم افزار کشف خطاها است. در نتیجه, مشکل ترین خطاها (از دیدگاه مشتری) آنهایی هستند که باعث می شوند برنامه با شکست روبرو شود و نتواند نیازها را برآورده نماید.
آزمایشها باید مدتی طولانی قبل از شروع آزمایش برنامه ریزی شوند. برنامه ریزی آزمایش (فصل18) می تواند با تکمیل مدل آغاز گردد. تعریف همراه با جزئیات از ابزارهای آزمایش, با شکل گیری مدل طراحی قابل انجام است. بنابراین, تمام آزمایشها می توانند قبل از هر تولید کد, برنامه ریزی و طراحی شوند.
اصل Pareto برای آزمایش نرم افزار به کار گرفته شود. به بیان ساده, اصل Pareto بیان می دارد که 80 درصد تمام خطاهایی که در ضمن آزمایش کشف می شوند, احتمالاً برای 20 درصد از تمام مولفه های برنامه قابل پیگیری هستند. این مسئله به این منظور مهم است که مولفه های مشکوک جدا شوند و کاملاًَ مورد آزمایش قرار گیرند .
اسلاید 7 :
آزمایش باید با «توجه به اجزاء» شروع شود و به سمت آزمایش «کلی» پیش رود. اولین آزمایشها عموماً به گونه ای برنامه ریزی و اجرا می شوند که تمرکز بر هر یک از اجزاء دارند. با پیشرفت آزمایش, تمرکز به سمت تلاش برای یافتن خطاها در مجموعه مولفه های مجتمع شده (و احتمالاً کل سیستم) انتقال می یابد.
آزمایش کامل امکان پذیر نیست. تعداد ترکیبات مسیرهای برنامه ای متوسط بسیار زیاد است. به این دلیل, اجرای همه ترکیبات مسیرها در ضمن آزمایش امکان پذیر نمی باشد. به هر حال, این امکان وجود دارد که تا حد مطلوبی منطق برنامه پوشش داده شود تا اطمینان حاصل شود که تمام شرط های طراحی در سطح مولفه بررسی شده اند.
به منظور داشتن بیشترین تأثیر, آزمایش باید توسط تیم مستقلی هدایت شود. بیشترین تأثیر, به این معنی است که آزمایش با بالاترین احتمال بتواند خطاها را بیابد (اولین هدف از آزمایش). به دلایلی که قبلاً بیان شد, و با جزئیات بیشتر در فصل 18 بررسی می گردند, مهندس نرم افزاری که سیستم را ایجاد کرده, بهترین فرد برای هدایت کردن تمام آزمایشات نرم افزار نمی باشد.
3-1-17 قابلیت آزمایش
در موارد ایده آل, مهندس نرم افزار برنامه ای کامپیوتری, سیستم, یا محصولی را با در نظر داشتن قابلیت آزمایش طراحی می کند. این مسئله باعث می شود افرادی که مسئول آزمایش هستند, ابزارهای آزمایشی موثر را ساده تر ایجاد نمایند. اما قابلیت آزمایش چیست؟ Bach James قابلیت آزمایش را اینگونه توصیف می کند :
اسلاید 8 :
قابلیت آزمایش نرم افزار یعنی میزان سادگی آزمایش برنامه کامپیوتری. با توجه به این که آزمایش بسیار مشکل است, به منظور سهولت آن, چه اعمالی باید انجام شود. بعضی مواقع, برنامه نویس ها تمایل به انجام کارهایی دارند که به فرآیند آزمایش کمک کنند, و یک چک لیست از نکات طراحی, جنبه ها و غیره می تواند برای استفاده از آنها مفید باشند.
مطمئناً معیارهایی وجود دارند که برای اندازه گیری قابلیت آزمایش در اکثر جنبه ها قابل استفاده هستند. گاهی اوقات, قابلیت آزمایش به این مفهوم استفاده می شود که تا چه حد یک مجموعه خاص از آزمایشات, یک محصول را پوشش می دهند. در کاربردهای نظامی, به این معنی است که با چه سهولتی یک ابزار می تواند در میدان عملیات بررسی و تعمیر شود. این دو مفهوم مشابه قابلیت آزمایش نرم افزار نیستند. چک لیستی که در ادامه قرار دارد مجموعه ای از خصوصیاتی را بیان می کند که نرم افزار قابل آزمایش باید داشته باشد :
- خروجی های مجزا برای هر ورودی تولید می شوند .
- حالت های سیستم و متغیرها در ضمن اجرا قابل رویت و قابل پرس و جو باشند .
- حالت های قبلی سیستم و متغیرها قابل پرس و جو می باشند (برای مثال , ثبت تراکنشها).
- تمام فاکتورهای موثر بر خروجی قابل رویت باشند .
- خروجی غلط به راحتی مشخص شود .
- خطاهای داخلی به طور خودکار از طریق مکانیزم های خود آزمایی آشکار شوند .
- خطاهای داخلی به طور خودکار گزارش شوند .
- کد مبدأ قابل دسترسی باشد .
- قابلیت کنترل . « هر چه نرم افزار بهتر کنترل شود, آزمایش بیشتر به طور خودکار و بهینه قابل انجام است.»
- تمام خروجی های ممکن نمی توانند از طریق برخی ترکیبات ورودی تولید شوند.
- تمام دستورات از طریق برخی ترکیبات ورودی قابل اجرا باشند .
- حالت ها و متغیرهای نرم افزار و سخت افزار مستقیماً توسط مهندس آزمایش قابل کنترل باشند .
- قالب های ورودی و خروجی یکنواخت و ساخت یافته باشند .
- آزمایشها می توانند به طور مناسبی مشخص شوند, و به طور خودکار انجام گیرند و دوباره تولید گردند.
اسلاید 9 :
تجزیه پذیری . «با کنترل نمودن محدوده آزمایش, با سرعت بیشتری مسائل تجزیه می شوند و آزمایش های هوشمندانه تری انجام می گیرد. »
- سیستم نرم افزار از پیمانه های مستقل ساخته می شود.
- پیمانه های نرم افزاری به طور مستقل قابل آزمایش هستند .
- سادگی . « هر چه مورد برای آزمایش کمتر باشد, با سرعت بیشتری قابل آزمایش است.»
- سادگی تابعی (برای مثال, مجموعه جنبه هایی که حداقل لازم برای دستیابی به نیازها هستند.)
- سادگی ساختاری (برای مثال, معماری پیمانه بندی می شود تا انتشار اشکالات را محدود نماید.)
- سادگی کد (برای مثال, استاندارد کد نویسی برای سهولت بازبینی و نگهداری تعریف می شود).
- پایداری . «هر چه تغییرات کمتر باشد, انحراف از آزمایش کمتر است.»
- تغییرات در نرم افزار غیر متداول هستند .
- تغییرات در نرم افزار کنترل شده هستند .
- تغییرات در نرم افزار, آزمایش های موجود را نامعتبر نمی سازند.
- نرم افزار از شکست ها به خوبی خارج می شود.
- قابلیت فهم . « هر چه اطلاعات بیشتری در اختیار داشته باشیم, آزمایش هوشمندانه تری انجام می شود. »
- طراحی کاملاً قابل فهم است.
- وابستگی های بین مولفه های داخلی, خارجی, و اشتراکی کاملاً قابل فهم هستند.
- تغییرات طراحی منتقل می شوند .
- مستند سازی تکنیکی قابل دسترسی است.
- ستند سازی تکنیکی به طور مناسبی سازماندهی شده است.
- مستند سازی تکنیکی دقیق است.
اسلاید 10 :
صفات پیشنهاد شده توسط Bach می توانند توسط مهندس نرم افزار استفاده شوند تا پیکربندی نرم افزار (یعنی, برنامه ها, داده ها, و مستندات) که تحت کنترل آزمایش می باشد توسعه دهند .
در مورد آزمایشها چطور؟ Falk, Kaner و Nguyen صفات زیر را برای آزمایش خوب پیشنهد می کنند :
یک آزمایش خوب با احتمال بالا خطا را می یابد. به منظور دستیابی به این هدف, آزمایش کننده باید نرم افزار را بفهمد و سعی در توسعه تصویری رفتاری از نحوه شکست نرم افزار داشته باشد. در حالت ایده آل, رده های شکست تفکیک می شوند. برای مثال, یک رده از شکست های بالقوه در GUI (رابط کاربر گرافیکی), شکست در تشخیص موقعیت مناسب موش می باشد. مجموعه ای از آزمایشات طراحی می شوند تا موش را مورد آزمایش قرار دهند تا خطای شناسایی موقعیت موش را آشکار نمایند .
کلمات کلیدی :
