تست نرم افزار (قسمت 1)

فرمانده گروهان: بزرگترین عاملی که یک سازمان یا شرکت را از سازمانهای و شرکت های دیگر متمایر می کند چیست؟

فرمانده گروهان: محصولی که آن سازمان تولید می کند. محصولی که خروجی نیروی انتظامی است با ارزشترین محصولی است که یک سازمان می تواند تولید کند یعنی امنیت.

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

تست فقط می تواند وجود خطاها را نشان دهد نه عدم وجود آنها را

من عاشق یک پارگراف از یک کتاب طراحی نرم افزار هستم که به طور خلاصه اینرا می گفت: “نرم افزار خوب نرم افزاری است که مشتری را خوشحال کند و زمانی مشتری خوشحال خواهد شد که تمام نیازمندیهای که در نظر دارد برآورده شود”. پس ما به عنوان توسعه دهنده نرم افزار باید مطمئن شویم که مشتری خود را خوشحال خواهیم کرد، فرآیند و شیوه رسیدن به این اطمینان خاطر یعنی هدف تست نرم افزار. تست نرم افزار به طور رسمی جزی از بازبینی و اعتبارسنجی نرم افزار می باشد، که این دو واژه به صورت زیر تعریف و  با هم مقایسه می شوند.

وارسی:  “آیا محصول درستی را می سازیم؟”

اعتبارسنجی: “آیا محصول را به درستی می سازیم؟”

وارسی بررسی می کند که آیا نرم افزار از مشخصاتش پیروی می کند یا خیر. اعتبارسنجی باید تضمین کند که نرم افزار انتظارات مشتری را برآورده می سازد یا نه. توجه کنید که آنچه در مشخصات می آید ممکن است دقیقا خواسته های مشتری را برآورده نسازد.

استراتژی تست

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

استراتژی جعبه سیاه:

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

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

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

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

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

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

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

6.       …

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

functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing, system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing , ….

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

if (name=="Lee" && employeeNumber=="1234" &&
    employmentStatus=="RecentlyTerminatedForCause") {
    send Lee a check for $1,000,000;

}

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

استراتژی جعبه سفید

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

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

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

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

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

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

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

6.       …

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

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

ادامه دارد.

6 comments on “تست نرم افزار (قسمت 1)

  1. طاهری راد on

    با سلاممرسی، مطلب جالبی بود. و انشاالله سربازی به شما خوش بگذرد. یه دوستبا تشکر

  2. علی نوبر on

    در مورد مطالب قابل توجهی که نوشتی:1. در کتاب هنر تست نرم افزار – the art of software testing خواندم (و به نظرم کاملا منطقی می آید) که هدف نهایی از تست نرم افزار یافتن باگهای بیشتر است و نه چیز دیگر! البته ادله محکم و قابل قبولی نیز برای این تعریف ارایه میکند. 2. در متن اشاره کرده ای که “یک مجموعه از ورودهای صحیح با خروج های مربوط به آن را تهیه می کنیم …”. در حوزه تست نرم افزار سناریوی ذکر شده در متن (سناریوی آفتابی-sunny scenario) کاملا لازم است اما سناریوی دیگر (سناریوی بارانی-rainy scenario) که هدف آن کشف اشکالات نرم افزار در مواجهه با مقادیر نادرست (مثلا عدم نمایش پیغام خطای مناسب) است نیز از اهمیت بالایی برخوردار است. 3. در تجربیاتی که داشتم Equivalence Partitioning و Boundary Value Analysis را در تستهای جعبه سیاه نیز به کار بردم که منجر به صرفه جویی در زمان و احتمال کشف خطاهای بیشتری شد.4. پیشنهاد میکنم که در مطالب آینده در حوزه تست به مطلب “پایداری در برابر آفت کش ها” نیز بپرداز.5. ممنون از مطالب آموزنده ات در مورد تست نرم افزار-این حوزه مهجور و کم طرفدار!

  3. بهروز بختیاری on

    سلام آقای نوبردر ابتدا بخاطر پیشنهادهای خوبتان از شما متشکرم.در مورد این مطلب ابتدا من یک متن کامل تر را نوشته بودم که سپس آن را خلاصه کردم ولی با عجله همینطوریکه شما اشاره کردید مثل اینکه اینکار خوب انجام ندادم و بعضی از قمست ها بخصوص 3 مورد اول که در متن اولیه نیز بودند حذف شده اند بخاطر کاملتر کردن و رفع نواقص متن مجددا از شما تشکر می کنم. ولی یک پیشنهاد هم من دارم که خودتان یک متن در مورد 4 بنویسید که هم در حوزه تخصص خود شما هست و هم فکر کنم بسیار کاملتر و بهتر از من بتوانید اینکار را انجام دهید.موفق باشید.

  4. علی نوبر on

    ممنون از لطفت. نظرات درج شده به معنی نقص در مطلب درخور توجه وبلاگ نبود. بلکه احساس کردم شاید بهتر باشد آنرا تکمیل کنم. به هر صورت همین که همت به اشتراک گذاری مطالب خود را این چنین کامل و ویرایش شده داری از خیلی ها (مثل خودم) جلوتری!چشم در اولین فرصت در مورد مطلب پایداری در برابر آفت کش ها (The Pesticide Paradox) در وبلاگم خواهم نوشت. ممنون از اینکه تذکر دادی.موفق باشی.

  5. ابوذر on

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

Comments are closed.