در توسینسو تدریس کنید

و

با دانش خود درآمد کسب کنید

روشهای تست کد برنامه ها قسمت 2

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

انواع تست

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

Black Box Testing یا تست جعبه سیاه

این تست آخرین مرحله تست است و پس از پیاده سازی کامل نرم افزار و اغلب در محیط واقعی انجام می شود. این تست توسط کاربران نهایی برنامه صورت می گیرد تا نظر خود را در رابطه با برنامه اعلام کرده و در صورتی که مشکلی را کشف کردند آنرا به اطلاع شرکت سازنده برسانند. در این نوع تست که Integrated Test نیز نام دارد، کاربر تنها عملکردهای برنامه و امکانات آن را مورد بررسی قرار می دهد. دلیل نامگذاری این نوع تست به نام Black Box Testing آنست که کاربر به مکانیسم درونی برنامه و کد آن کاری ندارد و تنها نیازهای خود را می بیند. در واقع کاربر به برنامه مانند یک جعبه سیاه نگاه می کند. تست جعبه سیاه روی ورودی و خروجی ها تمرکز دارد. به این معنی که کاربر مقادیر را (چه صحیح و چه غلط) وارد کرده و خروجی را چک می کند. هنگام تست جعبه سیاه به موارد زیر توجه کنید:

  • عملکرد برنامه: مطمئن شوید برنامه کاری را انجام می دهد که کاربر می خواهد. برخی اوقات ممکن است توسعه دهنده نیاز کاربر را اشتباهی متوجه شده، در این حالت تماماً یک قابلیت از برنامه را اشتباهی پیاده سازی می کند. پس باید مراقب این خطا نیز باشید.
  • اعتبار سنجی ورودی ها: سعی کنید حملات SQL-Injection انجام دهید یا تاریخ ها و ارقام نادرست وارد کنید. در فیلدها و جعبه متن هایی که رقمی هستند نباید بتوان حروف و علائم را وارد کرد.
  • خروجی ها: مطمئن شوید برنامه شما خروجی های معتبر و گزارشات صحیح تولید می کند. گزارشها باید تمیز و بی عیب و نقص باشند.

Gray Box Testing یا تست جعبه خاکستری

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

  • فایل های log و ... را چک کنید تا مطمئن شوید که برنامه کارها را به درستی انجام می دهد. (البته اگر برنامه شما از عملکرد خود Log تولید می کند!!!)
  • اطلاعاتی که از یک سیستم به سیستم دیگر انتقال می یابد را چک و اعتبارسنجی کنید.

تاکید می کنم که در این تست، تستر هیچ وقت کد شما را نمی بیند.

White box testing یا تست جعبه سفید

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

  • تمام مسیرهای اجرای کد برنامه را چک کنید. این نکته در بخش های قبلی در قالب مبحث Code Coverage و Data Coverage به تفصیل بیان شد.
  • کدهای کنترل خطا (Error catching) را چک کنید. مطمئن شوید که تمام خطاهای احتمالی را کنترل می کند.
  • متدها همانند آنچه انتظار دارید و در مستندات ذکر شده باید کار کنند. مثلاً اگر در توضیح متد، گفته شده که این متد Thread safe است پس باید آنرا از Thread های مختلف اجرا و چک کنید. یا اگر در مستندات قید شده که این متد توانایی گرفتن مقدار null به عنوان پارامتر را دارد، پس به آن مقدار null بدهید و ببینید آیا نتیجه صحیح را می دهد یا در آزمون شکست خواهد خورد!

انواع تست

معیارهای یک تست خوب

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

  • سرعت: تست های کند تست هایی هستند که اجرای آنها زمانبر است. این تست ها زمان بیشتری از برنامه نویس می گیرند و در نتیجه برنامه نویس رقبت زیادی به اجرای آنها ندارد و به ندرت اجرا می شوند؛ و اگر تست ها اجرا نشوند پس خطاها نیز کشف نخواهند شد.
  • استقلال: تست ها باید از یکدیگر مستقل باشند. این بدان معناست که تست ها نباید به وجود یکدیگر وابسته باشند. گاهی ممکن است یک تست را در دل تست دیگری اجرا کنیم یا از کلاس تست دیگری که قبلاً تولید کردیم ارث بری کنیم؛ این کار کاملاً اشتباه است؛ زیرا اگر تست والد را تغییر دهیم، قاعدتاً تست فرزند نیز درچار تغییر می شود، و این کار توسعه تست ها را دچار اختلال می کند.
  • قابل تکرار: تستی که تولید می کنیم در هر زمان و مکان و در هر موقعیتی باید قابل اجرا باشد. برخی اوقات ممکن است تست هایی را تولید کنیم که تنها در شرایط خاصی قابل اجرا باشند. برای مثال در حالتی که Connection String یک سری خصوصیات خاص را در خود داشته باشد. در این حالت باید قبل از اجرای این تست Connection String را نیز تنظیم کنیم. برای حل این مشکل بهتر است یک سری متد تست را قبل و بعد از اجرای تست، اجرا کنیم. بسیاری از فریم ورک های تست این حالت را تعریف کرده اند. برای مثال، جاوا خصوصیات @Before و @After را برای آماده سازی و بازسازی تست ها دارد.

اما گاهی اوقات ممکن است یک سری شرایط خاص را برای برنامه خود در نظر بگیریم. مثلاً اینکه می خواهیم بدانیم برنامه ما در حالت قطع شبکه به چه صورت کار خواهد کرد. در این صورت باید از متدهای fake و شبیه ساز استفاده کنیم. ویژوال استودیو از نسخه 2012 به خوبی این کار را انجام داده.

  • Self Validate: تست ها باید در صورت موفقیت آمیز بودن، مقدار True و در غیر اینصورت مقدار False را بازگردانند؛ فقط همین، نه بیشتر و نه کمتر؛ متدهای تست نباید متن و گزارش بازگردانند. تنها نوع داده ای که این متدها بازگشت می دهند نوع داده bool است. این امر باعث می شود چک کردن متدها راحت تر شود. به این صورت که متدهایی که با موفقیت، و بدون مشکل اجرا می شوند سبز شده و متدهایی که خطایی را میابند قرمز می شوند.
  • تست ها باید به موقع باشند: تنها زمانی که به تست نیاز داشته باشیم آنرا تولید می کنیم. این اساس برنامه نویسی TDD است. هیچ وقت متد تست اضافه ای ایجاد نکنید. این امر از شلوغ کاری جلوگیری می کند.
  • تک وظیفه ای: تک وظیفه ای یعنی اینکه یک متد تست تنها باید یک چیز را تست کند. اگر متدها را به این صورت طراحی کنید؛ هر متدی که با شکست مواجه شود، دقیقا به مکانی اشاره خواهد کرد که مشکل در آن ایجاد شده. این کار باعث می شود پیدا کردن منبع خطا راحت تر شود.

زمان مناسب برای انجام تست

متخصصان دو زمان را برای انجام تست مناسب می دانند یکی بعد از کد نویسی و دیگر قبل از کد نویسی است. متدولوژی های جدید همچون Agile بر نوع دوم تاکید بیشتری دارند.

روش سنتی – بعد از کدنویسی

در روش سنتی پس از نوشتن کد و تایید آن، تست ها نوشته می شوند.این کار ساده تر است؛ زیرا طراحی تست برای کدی که نوشته شده و برنامه نویس ساختار آنرا می بیند بسیار ساده تر از طراحی تست برای کدی است که هنوز نوشته نشده و وجود خارجی ندارد! این امر باعث می شود تست های واضح تری نوشته شوند؛ چراکه برنامه نویس کد را می بیند و براساس آن تست را می نویسد.

روش TDD – Test Driven Development

در این روش که اخیرا بین برنامه نویسان مد شده، پیش از پیاده سازی هر قابلیت ابتدا تست های آن نوشته می شوند و سپس اقدام به کدنویسی قابلیت می کنیم.در این روش برنامه نویس پیش از پیاده سازی یک قابلیت به تست کیس های آن (و مواردی که می تواند در آن تست کند) فکر می کند، سپس یک تست بسیار ساده می نویسد و آنرا اجرا می کند مسلما در ابتدا تست با شکست مواجه می شود؛ پس از آن برنامه نویس در جهت پاس کردن موفقیت آمیز این آزمون اقدام کرده و کد اصلی را می نویسد. اما فقط کدی را می نویسد که موجب پاس شدن تست شود، نه بیشتر و نه کمتر. برنامه نویس همین روال را ادامه می دهد تا تمام برنامه را به این شکل تولید کند. این روش TDD یا Test Driven Development نام دارد. همانطور که قبلاً گفتیم این روش مناسب متدولوژی های Agile است. در این روش کد تمیزتر و کارآمدتر خواهد شد؛ زیرا برنامه نویس تقریباً خط به خط آنرا تست می کند و کیفیت برنامه هم تضمین می شود. این مفهوم در بخش بعدی بیشتر بحث خواهد شد.

چرخه حیات TDD (وضعیت قرمز، سبز، ریفکتور)

چرخه حیات روش Test Driven Development که در بالا توضیح داده شد، در سه گام اصلی خلاصه می شود:

گام اول (وضعیت قرمز)

در این حالت تستی که شما طراحی کرده بودید با شکست مواجه می شود و وضعیت قرمز را نمایش می دهد. مسلماً این مرحله قبل از پیاده سازی کد اصلی حتما رخ می دهد.

گام دوم وضعیت سبز

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

وضعیت ریفکتور

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

چرخه حیات توسعه برنامه مبتنی بر تست

ابزارهای تست برنامه (Testing Frameworks)

Test Frameworks در واقع مجموعه ابزارها و چارچوب ها برای ساده تر، سریع تر و منظم تر کردن تست برنامه است. امروزه کمتر پیش میاید که بخواهیم برنامه خود را به صورت دستی و بدون استفاده از این فریم ورک ها تست کنیم. اغلب این ابزارها تست ها را به صورت اتوماتیک اجرا می کنند. اما این ابزار تست ها را نمی نویسد و شما باید شخصاً برای این کار آستین بالا کشیده و کدهای تست را بنویسید.

چند نمونه فریم ورک تست

فریم ورک رایج برای جاوا jUnit و برای دات نت Nunit می باشد. اما اخیراً ویژوال استودیو ابزارهای فوق العاده ای را ارائه داده؛ ابزار های تست از نسخه 2012 ویژوال استودیو به بعد پیشرفت قابل ملاحظه ای کرده اند. این امر اهمیت روز افزون مقوله تست نرم افزار را نشان می دهد. این بود دیدگاه بنده از مقوله تست. اگر معتقدید جایی اشتباه کرده ام یا موردی را از قلم انداخته ام، خوشحال میشم در بخش نظرات یادآوری کنید. امیدوارم از این مقاله استفاده لازم را برده باشید؛ تا دیداری دیگر بدرود.

نویسنده : جنامی

منبع : جزیره برنامه نویسی و توسعه نرم افزار وب سایت توسینسو

هرگونه نشر و کپی برداری بدون ذکر منبع و نام نویسنده دارای اشکال اخلاقی می باشد

#تست_سورس_کد_نرم_افزار #integrated_test_چیست #تست_کدهای_نرم_افزار #انواع_تست_نفوذ_سنجی #owasp_چیست #متدولوژی_tdd #تست_سلامت_کدهای_نرم_افزار #چگونه_سورس_یک_برنامه_را_تست_کنیم #تست_کدهای_برنامه
عنوان
1 روشهای تست کد برنامه ها قسمت 1 رایگان
2 روشهای تست کد برنامه ها قسمت 2 رایگان
زمان و قیمت کل 0″ 0
1 نظر
محمد نصیری

خیلی جالب بود ، توی پروژه های تست نفوذ سنجی در شبکه ها هم ما همین مکانیزم تست جعبه سفید و سیاه و خاکستری رو داریم که تا الان فکر می کردم فقط روی بستر شبکه چنین مکانیزمهایی وجود داره ، ممنون از شما.

نظر شما
برای ارسال نظر باید وارد شوید.
از سرتاسر توسینسو
تنظیمات حریم خصوصی
تائید صرفنظر
×

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