تست نرم‌افزار

از ویکی‌پدیا، دانشنامهٔ آزاد
پرش به: ناوبری، جستجو

اهداف تست نگرش ما در تست نرم افزا ر تست: اجراي یک برنامه با هدف پیدا کردن خطا تست خوب: احتمال پیدا کردن خطاهاي کشف نشده توسط ارزیابی زیاد است. تست موفق: که حداقل یک خطاي کشف نشده را بیابد تست فقط وجود خطا را نشان می دهد و نه عدم وجود آن را. پیدا نشدن خطا در تست به معناي بدون خطا بودن برنامه نیست. اصول تست تست با توجه به نیازمندیهاي کاربر برنامه ریزي قبل از اجرا (test plan) نوشتن برنامه تست قانون پارتو %80 خطاهاي کشف نشده در 20 % کد است تست باید از اجزاي کوچک شروع شود ممکن نیست (exhaustive) تست کامل براي موثر بودن باید توسط شخصثالث بیطرف انجام شود معیارهاي تست پذیر بودن نرم افزار ١. قابلیت اجرا Operability هرچه نرم افزار بهتر کار کند و در محیط هاي بیشتري قابل اجرا باشد، n بهتر قابل ارزیابی است ٢. مشاهده پذیري Observability قابلیت مشاهده نتایج ارزیابی ٣. کنترل پذیري Controlability قابلیت اجراي تستهاي خودکار (مثل امکان اجراي خودکار تست هاي واحد توسط jUnit براي زبان جاوا) ۴. تجزیه پذیري Decomposability ارزیابی می تواند هدفمند تر شود ۵. سادگی Simplicity کاهش پیچیدگی معماري و منطق برنامه ۶. پایداري Stability براي ارزیابی تغییرات کمی بخواهد ٧. درك پذیري Understandability قابلیت درك طراحی و وابستگیهاي بین اجزا سطوح مختلف تست • تست واحد(Unit testing ) • تست یکپارچه سازي(Integration testing ) • تست یکپارچه سازي افزایشی • تست یکپارچه سازي • تست سیستم(System testing ) • تست پذیرش(Acceptance testing ) • تست آلفا • تست بتا تست واحد . پایین ترین سطح تست است micro level هر کد تست واحد، یک قطعه کد یا یک تابع (متد) خاص را تست می کند. این تست نیاز به دانش در مورد طراحی و نحوه عملکرد داخلی تابع یا قطعه کد دارد. توسط برنامه نویس (و نه تست کننده) انجام می شود. تست یکپارچه سازي افزایشی با افزوده شدن قابلیت جدید به نرم افزار، مجددا نرم افزار تست می شود. هدف این تست، بررسی درستی نرم افزار پس از افزوده شدن امکان جدید است. امکانات نرم افزار باید از هم استقلال داشته باشند تا بتوان پیش از تکمیل کل نرم افزار و به صورت افزایشی نرم افزار را تست کرد. توسط برنامه نویس یا تیم تست انجام می شود تست یکپارچه سازي تست نرم افزار حاصل از کنار هم قرار گرفتن قطعات مختلف آن به منظور بررسی درستی عملکرد نرم افزار یکپارچه شده قطعات مختلف شامل قطعه کدها (ماژول هایی از کد برنامه هاي مجزا که در کنار هم برنامه اصلی را تشکیل می دهند برنامه هاي مشتري-کارگزار عمل کننده در یک شبکه پس از تست واحد انجام می شود تست سیستم به منظور بررسی عملکرد نرم افزار بر روي پلتفرم هاي مختلف انجام می شود و نرم افزارهاي OS پلتفرم: سخت افزار + نرم افزار (شامل کاربردي مورد نیاز برنامه) به منظور اطمینان از اینکه برنامه با مولفه هاي دیگر محیط اجرایش به خوبی کار می کند به منظور اطمینان از اینکه نرم افزار ارائه شده در محیط مورد نظر قابل استفاده است. مثالی از مشکل حاصل از انجام ندادن تست سیستم

نرم افزار بازي شیر شاه دیزنی Disney’s Lion King Game

در پاییز سال 1994 شرکت دیزنی اولین CD بازي خود تحت عنوان شیر شاه Lion King که بر اساس کارتونی به همین نام ساخته شده بود را وارد بازار کرد. بسیاري از شرکتهاي دیگر تا آن زمان اقدام به ساخت بازیهاي رایانه اي کرده بودند اما این اولین بار بود که شرکت دیزنی وارد این تجارت شده بود. دیزنی براي فروش این بازي دست به تبلیغات گسترده اي زد و در نتیجه این محصول با فروش بسیار بالایی مواجه شد. اما اتفاقات پس از آن تبدیل به کابوسی براي این شرکت شد. در 26 دسامبر، روز پس از کریسمس تلفن هاي بخش پشتیبانی مشتریان شرکت دیزنی شروع کرد به زنگ زدن و زنگ زدن و زنگ زدن! متصدیان پاسخگویی به تماس ها با خیل عظیمی از والدین عصبانی با بچه هاي گریان مواجه شدند که ادعا می کرند نرم افزار مزبور کار نمی کند. این خبر به سرعت در مطبوعات و تلویزیون نیز پخش شد و کریسمس آن سال را براي بسیاري از پرسنل دیزنی تلخ کرد. تست علت چه بود؟ پس از بررسی مشخص شد که دیزنی نرم افزار خود را بر روي بسیاري از مدل هاي PCتست نکرده بود و در نتیجه تنها بر روي سیستمهایی کار می کرد که برنامه نویسان دیزنی روي آن سیستم ها نرم افزار خود را توسعه داده بودند و نه دستگاههاي متداولی که عموم مردم از آن استفاده می کردند. تست پذیرش به منظور بررسی اینکه نرم افزار نیازهاي مشتري را برآورده می کند، انجام می شود بعد از تست سیستم انجام می شود. شامل: تست آلفا: تست آلفا در سایت توسعه دهنده نرم افزار و در اغلب موارد n توسط کارمندان داخلی و در بعضی از موارد توسط مشتري تعدادي از کاربرانش که به محل دعوت می شوند انجام می گیرد. تست بتا: در تست بتا نسخه هایی از نرم افزار در اختیار تعدادي از کاربران قرار می گیرد تا در بازه اي با آن کار کنند و خطاها را گزارش دهند. روشهاي ارزیابی روش جعبه سفید دانستن نحوه کار داخلی برنامه امکان تایید نحوه عمل هر تکه کد و مسیر اجرا مراحل اولیه ارزیابی روش جعبه سیاه دانستن عمل مورد انتظار و مطلوب امکان تایید کاري که سیستم باید انجام دهد مراحل انتهایی ارزیابی استرتژی تست استراتژی تست نرم‌افزار یک توصیف رسمی از این است که نرم‌افزار چگونه تست خواهد شد. هدف استراتژی تست تعریف همه مراحل برای فرایند تست نرم‌افزار است که شامل برنامه ریزی آزمایش، طراحی ابزار آرمایش، اجرای آزمایش و جمع آوری و ارزیابی داده‌های بدست آمده باشد.

==استراتژی جعبه سیاه==این آزمایش جایگزین آزمایش جعبه سفید نمی‌باشد بلکه مکمل آن است.وخطاهایی متفاوت باآن راتست میکند.

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

در یک استراتژی آزمایش جعبه سیاه ما عموماً موارد زیر را مورد بررسی و آزمایش قرار می دهیم:

۱. بررسی اینکه سیستم نیازمندهای عملیاتی و غیر عملیاتی را تامین می‌کند یا نه.

۲. اعتبارسنجی ورودیها

۳. بررسی مقادیر مرزی برای متغیرها: به یک متغیر مقداری کمتر از حداقل مقداری که می تواند قبول کند یا بیشتر از حداکثر مقداری که می تواند قبول کند می دهیم و سیستم را در این شرایط تست می کنیم.

۴. بررسی خروج‌های سیستم: یک مجموعه از ورودهای صحیح با خروج‌های مربوط به آن را تهیه می کنیم و سپس ورودها را به سیستم وارد می کنیم و خروج‌های که توسط سیستم داده می‌شود را با خروجی‌های واقعی مقایسه می کنیم.

۵. بررسی رفتار سیستم در برابر پردازش ورودها و پرس و جوهای بزرگ و سنگین

برای موارد بالا و مواردی دیگری که ذکر نشد روشهای مختلف تست در استراتژی جعبه سیاه وجود دارد که عبارتند از:

آیا می توان در استراتژی جعبه سیاه، از این مطمئن شد که سیستم به طور کامل تست شده است؟ خیر، هرگز در این استراتژی نمی توان مطمئن شد که سیستم به طور کامل تست شده است. برای نمونه با چه احتمالی کاربر می تواند ورودهای را انتخاب کند تا شرط زیر چک شود.

if ("name=="Lee" && employeeNumber=="1234" && employmentStatus=="RecentlyTerminatedForCause) {

send Lee a check for $1,000,000;

}

پس همیشه در این استراتژی مسیرهای خواهند بود که تست نمی‌شوند و همیشه سیستم با داده‌های ورودی محدود می توانند تست شوند.

استراتژی جعبه سفید[ویرایش]

حال تصور کنید که شما خود یک توسعه دهنده نرم‌افزار هستید، پس شما می توانید به سورس، طراحی و منابع دیگر نرم‌افزار دسترسی داشته باشید. در این حالت سیستم را می توان به یک جعبه شیشه ای (جعبه سفید) تشبیه کرد که شما می توانید براحتی محتویات داخل و نحوه عملکرد آنرا مشاهده کنید. آزمایش جعبه سفید نیز دقیقاً از دیدگاه توسعه دهنده نرم‌افزار را مورد آزمایش قرار می دهد یعنی با این فرض که شما به منطق داخلی و ساختار کد برنامه دسترسی و احاطه دارید و می دانید که سیستم چگونه پیاده سازی شده است. شما با دانستن این موارد می توانید مشخص کنید که آیا اعمال داخلی بر طبق مشخصه‌ها نجام می‌شود و یا نه.

در یک استراتژی آزمایش جعبه سفید ما عموماً موارد زیر را مورد توجه و بررسی قرار می دهیم:

۱. بررسی سطر به سطر کد (Code coverage): در این حالت باید سیستم را به گونه ای اجراء و بررسی کنیم که مطمئن شویم سطر به سطر کد برنامه حداقل یکبار اجراء شده است.

۲. بررسی همه انشعاب‌ها در کد برنامه (branch) : در کد برنامه باید تمام عبارت‌های شرطی ( if elseها و Switch case ها) را تک به تک مورد بررسی قرار داد. به این صورت که در یک عبارت if else هم فسمت if و هم قسمت else هر کدام بصورت مجزا یکبار اجراء شوند.

۳. بررسی همه حلقه‌ها در برنامه : حلقه‌ها در نرم‌افزار نقش اساسی دارند، چون می تونند با اشتباه جزئی مقدار زیادی از منابع را مصرف کرد برای مثال شرط خروج از حلقه به اشتباه هیچ وقت True نشود. برای نمونه حلقه‌ها را با ورودی بزرگتر از شرط خروج حلقه چک کنید یعنی حلقه اصلاً اجر نشود. تستی طراحی کنید که حلقه دقیقاً یکبار اجراء شود، تستی طراحی کنید که حلقه در یک بازه خاص اجراء شود و ....

۴. مدیریت خطای مطلوب : برسی اینکه اگر به یک متد یک ورودی نامعتبر وارد شود، نحوه آگاه سازی و نمایش مطلوب خطا برای کاربر چگونه باشد؟

۵. بررسی امنیت : سیستم را از این جهت که چگونه در برابر دسترسی‌های غیرمجاز، هک، کرک و هر چیز دیگر که می تواند به آن آسیب برساند مورد بررسی قرار می دهد. در اینجا ما باید مکانهای از کد را که داده‌ها را اعتبارسنجی و مدیریت می کنند، دسترسی به منابع یا عملیات مهم و حیاتی را انجام می دهند را بررسی کنیم.

۶. برای موارد بالا و مواردی دیگری که ذکر نشد روشهای مختلف تست در استراتژی جعبه سفید وجود دارد که عبارتند از:

Basis Path Testing, Equivalence Partitioning/Boundary Value Analysis, Method Coverage, Statement Coverage, Branch Coverage, Condition Coverage, Data Flow Testing, Flow Graphs Revisited, ….

منابع[ویرایش]