دانلود فایل پاورپوینت تکنیک های آزمایش نرم افزار

بخشی از پاورپوینت

--- پاورپوینت شامل تصاویر میباشد ----

اسلاید 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 (رابط کاربر گرافیکی), شکست در تشخیص موقعیت مناسب موش می باشد. مجموعه ای از آزمایشات طراحی می شوند تا موش را مورد آزمایش قرار دهند تا خطای شناسایی موقعیت موش را آشکار نمایند .

      یک آزمایش خوب بیش از حد انجام نمی شود. زمان آزمایش و منابع محدودند. دلیلی برای هدایت کردن آزمایشی که هدفی مشابه آزمایش دیگر دارد, وجود ندارد. هر آزمایش باید هدف متفاوتی داشته باشد (حتی اگر تفاوت غیرآشکاری باشد). برای مثال, یک پیمانه از نرم افزار Safe Home (که قبلاً بحث شد). برای تشخیص کلمه عبور کاربر طراحی شده است تا سیستم را فعال نماید. در تلاشی برای آشکار نمودن خطا در ورود کلمه عبور, آزمایش کننده یک سری آزمایشها را طراحی می کند که دنباله ای از کلمه های عبور را وارد می کنند. کلمه های عبور معتبر یا نامعتبر باید روش متفاوت شکست را بررسی نماید. برای مثال, کلمه عبور نامعتبر 1234 نباید توسط سیستمی که برای پذیرش 8080 برنامه ریزی شده, پذیرفته شود. در صورت پذیرفته شدن, خطایی آشکار می شود. ورودی آزمایش دیگر, برای مثال 1235 , همان هدف 1234 را خواهد داشت و بنابراین اضافی است. به هر حال, ورودی نامعتبر 8081 یا 8180 , تفاوت ظریفی دارند, آنها سعی در نشان دادن این مورد دارند که برای کلمه های عبوری نزدیک به کلمه عبور معتبر ولی مخالف آن, خطایی وجود دارد.