یکی از فاز های مهم در تولید محصولات نرم افزاری، تست نرم افزار و بررسی کیفیت محصول تولید شده است. متاسفانه در کشور ما آنچه که از سوی برنامه نویسان و شرکت های برنامه نویسی بسیار مورد کم لطفی قرار گرفته، موضوع کیفیت نرم افزار یا Quality Assurance است. تقریباً در بسیاری از نهادها و شرکت های برنامه نویسی اتمام کد نویسی به منزله اتمام و آماده شدن برنامه است.
اما اغلب شرکت های پیشتاز جهانی در این زمینه دقیقاً برخلاف این روال عمل می کنند. آنها معتقدند که پیش از انتشار نرم افزار می بایست اقداماتی را در جهت تضمین و ارتقاء کیفیت نرم افزار از جمله رفع خطاهای احتمالی، افزایش کارائی و ساده تر کردن نرم افزار انجام داد.در این مقاله که در دو بخش ارائه شده سعی داریم شما را با با یکی از معیارهای مهم در تضمین کیفیت نرم افزار که همانا تست برنامه است آشنا کنیم. در طول این مقاله با موضوعات زیر مواجه خواهیم شد:
به طور کلی سه روش برای کشف خطا در برنامه هایی که توسعه می دهیم وجود دارد. این سه روش در زیر توضیح داده شده اند.
این روش از قدیم الایام برای کشف دلیل خطاهای برنامه مورد استفاده قرار می گرفته. در این روش برنامه نویس خط به خط کد خود را مطالعه می کند تا دلیل و عامل خطاهای موجود در برنامه کشف و رفع کند. در واقع هدف دیباگ آنست که کشف کند به چه دلیل یک باگ در برنامه رخ داده؛ بنابراین دیباگ یک فعالیت رفع اشکال است نه کشف اشکال. در این روش به نام متغییرها و طریقه استفاده از آنها، به حلقه ها و تمام ساختارهای موجود در برنامه توجه می کنیم، تا دلیل رخ دادن یک خطا را کشف کرده و آنرا رفع کنیم. دیباگ برای کشف سه نوع خطا استفاده می شود که در ذیل توضیح داده شده اند:
این نوع خطاها در اثر تایپ نادرست فرامین و کلمات کلیدی در کد برنامه تولید می شود. معمولاً این خطاها توسط محیط های برنامه نویسی امروزی (IDE) به راحتی کشف می شوند. مثلاً در ویژوال استودیو زیر این نوع خطاها با خط قرمزی مشخص می شود. در صورتی که چنین خطایی در برنامه داشته باشیم، برنامه ما اصلا اجرا نخواهد شد. این خطا ساده ترین نوع است.
این خطاها در نحو زبان ایجاد می شوند به این معنی که شما در تولید یک جمله صحیح در زبان برنامه نویسی دچار خطا می شوید. این مثال را در نظر بگیرید:
We went to the park yesterday.
ما دیروز به پارک رفتیم. این یک جمله صحیح است. اما جمله زیر را در نظر بگیرید:
We went to the park tomorrow.
ما فردا به پارک رفتیم. این جمله از نظر گرامری و نحوی غلط است.چنین حالتی در برنامه نویسی نیز می تواند به صورت های زیر رخ دهد:
در دستور switch بعد از case ها دستور break را قرار ندهید. در این صورت در تله آبشار سقوط خواهید کرد. (این خطا در C# به کاربر اعلام می شود) یا اینکه پس از دستور for یک علامت سمی کالون قرار دهید. در این صورت با یک حلقه پوچ مواجه خواهید شد.
For(int i=0;i<=100;i++);
خوشبختانه در بیشتر مواقع نیز IDE های مدرن در صورت کشف چنین خطاهایی به شما اخطار می دهند. این اخطارها در ویژوال استودیو معمولاً به رنگ سبز نمایش میابند؛ یا اینکه در قالب یک Warning در لیست خطاها دیده می شود. توجه داشته باشید که این خطاها اغلب اوقات نمی توانند از اجرای برنامه جلوگیری کنند اما نتیجه ای که میخواهید را به شما نخواهد داد.
این خطاها پیچیده ترین نوع خطاها هستند و کشف آنها زمانبر است. متاسفانه کامپایلر و محیط برنامه نویسی قادر به کشف این خطاها نمی باشند و برنامه ظاهراً نرمال و بدون هیچ مشکلی اجرا می شود، اما نتیجه مورد توقع شما را نمی دهد. در این نوع خطاها خود شما هستید که به عنوان برنامه نویس باید دست به کار شده و این خطاها را رفع کنید.
این خطاها در اثر اشتباه در تبدیل الگوریتم و فلوچارت به کد ایجاد می شوند. یکی از خطاهای رایج از این نوع خطای Off-By-One است که در هنگام استفاده از حلقه ها ایجاد می شود. در این حالت حلقه شما یک دور کمتر یا بیشتر می چرخد و نتیجه خطا را به شما می دهد. بهشت خطاهای منطقی، زبان های قدیمی مانند اسمبلی و C و C++ هستند. در این زبانها به دلیل استفاده از برخی ساختارها (مانند اشارگرها و goto) احتمال رخ دادن خطاهای منطقی بسیار بالاست.
همانطور که در بخش پیشین گفتیم، کامپایلر و IDE شما می تواند قسمتی از خطاها مانند خطاهای لغوی و در برخی اوقات خطاهای نحوی را کشف کند. اما بقیه خطاها را چگونه می توان کشف و ضبط کرد؟ این کار را می توان توسط تست و Code Review (مرور کد) انجام داد.تست که خود شامل چند نوع است در واقع فعالیتی است برای کشف خطاهای برنامه است. تاکید می کنم که این کار تنها بر امر کشف خطا تمرکز می کند و هیچ اقدامی برای رفع آن انجام نمی دهد. برای رفع خطاهای برنامه پس از کشف آنها توسط تست، از تکنیک دیباگ که در بالا ذکر شده استفاده کنید.
مرور کد یا نقد کد عبارت است از یافتن خطاهایی که جزئی از برنامه و روال کار آن هستند. این نوع خطاها اکثرا خطاهایی هستند که از دید برنامه نویس مخفی شده اند و در واقع برنامه نویس آنها را خطا تلقی نمی کند؛ بنابراین طبیعی است که در خلال تست کشف نشده و در دیباگ هم مرتفع نشوند!
مرور کد و جستجو برای خطاهایی که در انبوهی از کدها مخفی شده اند، مکانیسم دیگری است برای کشف خطاها و اطمینان از اینکه برنامه نویس تمام نیازمندیهای کاربران را مرتفع کرده. پس از آنکه کد خود را نوشتید و سپس تست و دیباگ کردید و نیز پس از آن که تمیزکاری و Refactor را انجام دادید؛ آنگاه نوبت به مرور کد می رسد. اولاً این کار نباید توسط شما انجام شود؛
شما کد را نوشتید و به عنوان خالق آن نمی توانید آنرا نقد و بررسی کنید. درست مانند یک فیلم ساز که فیلمی را می سازد و دیگران آنرا نقد می کنند؛ کد شما نیز باید توسط متخصصان و برنامه نویسان دیگر نقد و بررسی شود. Code Review معمولاً در قالب جلسات پنج نفره و کاملاً رسمی انجام می شود. خب از بحث اصلی خود که تست است دور نشویم و در همینجا مبحث مرور کد را خاتمه می دهیم.
اما چه اهمیتی دارد که کلی از وقت خود را برای تست برنامه ای که تولید کردیم تلف کنیم. من معمولاً برای اثبات اهمیت یک چیز مصداقهای آنرا ذکر می کنم. در اینجا نیز به طور خلاصه چند نمونه را ذکر خواهم کرد:
امیدوارم که با این مصادیق قانع شده باشید که از این پس برنامه های خود را قبل از انتشار تست کنید!!!
تا جایی که برای شما مقدور است تمام کد و تمام پیچ و خم های کدتان را تست کنید؛ اما آیا عملا چنین چیزی ممکن است؟ واقعیت آنست که نمی توانید به صورت صد در صد کدتان را تست کنید. اگر یک برنامه با 50 هزار خط کد (اصطلاحاً می گوییم 50 کیلو خط) داشته باشید؛ تست این برنامه کار بسیار سخت و وقت گیری خواهد بود. بنابراین در ادامه شما را با معیارهایی آشنا می کنیم تا میزان تست برنامه را اندازگیری کنید؛ و بدانید چند درصد از برنامه خود را تست کرده اید.
این معیارها مشخص می کنند که چند درصد از کد خود را تست کردید. مهم ترین این معیارها دو مورد گفته شده در ذیل است.
Code Coverage یا به اصطلاح پوشش کد میزان خطوطی که تحت تست و بررسی قرار گرفته اند را نشان می دهد. برای پوشش حداکثر کد به نکات زیر دقت کنید:
علاوه بر اینکه خطوط کد را چک می کنیم لازم است که داده های مختلفی به هر قطعه کد بدهیم تا ببینیم که در هر حالت کار را درست انجام می دهد یا خیر. در Data Coverage محدوده خاصی از داده های درست و غلط را به متدهای خود تزریق می کنیم تا ببینیم در هردو حالت چه اتفاقی بر سر نتیجه عملیات می افتد. آیا متدها در هر صورت درست کار می کنند یا اینکه ... بهترین داده هایی که می توان برای این کار برگزید به عبارت زیر هستند:
یادتان باشد برای که برای تست، هم از مقادیر معتبر و هم نامعتبر استفاده کنید.
تا اینجا در رابطه با اهمیت تست و روشهای کشف و رفع خطاها صحبت کردیم، همچنین در رابطه با معیارهای تست برنامه و ابزارها و واحدهایی که در این رابطه استفاده می شوند چند کلمه ای صحبت کردیم. اکنون به ادامه مطلب خواهیم پرداخت...
تست برنامه به صورت کلی به سه دسته تقسیم می شود که توسط افراد مختلف و در مراحل مختلف تولید برنامه انجام می شود. در این قسمت انواع این تست ها مورد بررسی قرار می گیرند.
این تست آخرین مرحله تست است و پس از پیاده سازی کامل نرم افزار و اغلب در محیط واقعی انجام می شود. این تست توسط کاربران نهایی برنامه صورت می گیرد تا نظر خود را در رابطه با برنامه اعلام کرده و در صورتی که مشکلی را کشف کردند آنرا به اطلاع شرکت سازنده برسانند. در این نوع تست که Integrated Test نیز نام دارد، کاربر تنها عملکردهای برنامه و امکانات آن را مورد بررسی قرار می دهد. دلیل نامگذاری این نوع تست به نام Black Box Testing آنست که کاربر به مکانیسم درونی برنامه و کد آن کاری ندارد و تنها نیازهای خود را می بیند. در واقع کاربر به برنامه مانند یک جعبه سیاه نگاه می کند. تست جعبه سیاه روی ورودی و خروجی ها تمرکز دارد. به این معنی که کاربر مقادیر را (چه صحیح و چه غلط) وارد کرده و خروجی را چک می کند. هنگام تست جعبه سیاه به موارد زیر توجه کنید:
این تست توسط افراد متخصصی به نام تستر انجام می شود. تست جعبه خاکستری مانند تست جعبه سیاه است با این تفاوت که این تست شما را به کد نزدیک تر می کند؛ اما باز هم کد را نخواهید دید. همانطور که گفته شد این نوع تست توسط واحد جداگانه ای به نام واحد تست و آزمون برنامه انجام می شود. در تست جعبه خاکستری می توانید موارد زیر را مورد بررسی قرار دهید:
تاکید می کنم که در این تست، تستر هیچ وقت کد شما را نمی بیند.
این تست مستقیما کد را تحت نظر دارد. در این تست شخص آزمونگر که معمولاً خود شما (برنامه نویس) هستید کد را به صورت کامل و بررسی می کنید. در این تست شما با خط به خط کدهای برنامه سروکار دارید. در این نوع تست شما عملکرد کدهای نوشته شده را چک می کنید لذا باید با کدهای نوشته شده آشنا باشید، به همین دلیل است که تاکید می کنیم این تست باید توسط توسعه دهنده برنامه انجام شود. این نوع تست را به صورت زیر انجام دهید:
اما یک تست خوب باید چگونه باشد؟ در واقع چگونه باید تست ها را طراحی کنیم تا با کمترین مشکلات در نگهداری، پشتیبانی و توسعه برنامه مواجه شویم. در این بخش پارامترهای یک تست خوب را بیان می کنیم :
اما گاهی اوقات ممکن است یک سری شرایط خاص را برای برنامه خود در نظر بگیریم. مثلاً اینکه می خواهیم بدانیم برنامه ما در حالت قطع شبکه به چه صورت کار خواهد کرد. در این صورت باید از متدهای fake و شبیه ساز استفاده کنیم. ویژوال استودیو از نسخه 2012 به خوبی این کار را انجام داده.
متخصصان دو زمان را برای انجام تست مناسب می دانند یکی بعد از کد نویسی و دیگر قبل از کد نویسی است. متدولوژی های جدید همچون Agile بر نوع دوم تاکید بیشتری دارند.
در روش سنتی پس از نوشتن کد و تایید آن، تست ها نوشته می شوند.این کار ساده تر است؛ زیرا طراحی تست برای کدی که نوشته شده و برنامه نویس ساختار آنرا می بیند بسیار ساده تر از طراحی تست برای کدی است که هنوز نوشته نشده و وجود خارجی ندارد! این امر باعث می شود تست های واضح تری نوشته شوند؛ چراکه برنامه نویس کد را می بیند و براساس آن تست را می نویسد.
در این روش که اخیرا بین برنامه نویسان مد شده، پیش از پیاده سازی هر قابلیت ابتدا تست های آن نوشته می شوند و سپس اقدام به کدنویسی قابلیت می کنیم.در این روش برنامه نویس پیش از پیاده سازی یک قابلیت به تست کیس های آن (و مواردی که می تواند در آن تست کند) فکر می کند، سپس یک تست بسیار ساده می نویسد و آنرا اجرا می کند مسلما در ابتدا تست با شکست مواجه می شود؛ پس از آن برنامه نویس در جهت پاس کردن موفقیت آمیز این آزمون اقدام کرده و کد اصلی را می نویسد. اما فقط کدی را می نویسد که موجب پاس شدن تست شود، نه بیشتر و نه کمتر. برنامه نویس همین روال را ادامه می دهد تا تمام برنامه را به این شکل تولید کند. این روش TDD یا Test Driven Development نام دارد. همانطور که قبلاً گفتیم این روش مناسب متدولوژی های Agile است. در این روش کد تمیزتر و کارآمدتر خواهد شد؛ زیرا برنامه نویس تقریباً خط به خط آنرا تست می کند و کیفیت برنامه هم تضمین می شود. این مفهوم در بخش بعدی بیشتر بحث خواهد شد.
چرخه حیات روش Test Driven Development که در بالا توضیح داده شد، در سه گام اصلی خلاصه می شود:
در این حالت تستی که شما طراحی کرده بودید با شکست مواجه می شود و وضعیت قرمز را نمایش می دهد. مسلماً این مرحله قبل از پیاده سازی کد اصلی حتما رخ می دهد.
در این حالت برنامه نویس قابلیت مورد نظر را در برنامه به درستی پیاده سازی کرده (یا مشکل پیش آمده را برطرف می کند) و با اجرای دوباره تست وضعیت سبز را نشان می دهد. این بدان معنی است که قابلیت یا متد مورد نظر به درستی مطالعه شده و کار مورد نظر را انجام می دهد اما الزاماً به این معنی نیست که کار ما تمام شده. ممکن است بتوانیم تغییراتی در کد ایجاد کنیم که کارائی، امنیت یا خوانایی کد را بالا ببرد.
پس از آنکه قابلیت را به درستی پیاده سازی کرده و تست پاس شد، در صورت نیاز کد خود را اصلاح کرده تا تمیزتر، واضحتر، ایمن تر یا سریعتر شود. به این کار اصلاحاً Refactor گفته می شود. ریفکتور موضوع وسیعیست که در این مجال نمی گنجد اما چند مثال از آنرا در ایجا برای شما بازگو خواهم کرد.یکی از ساده ترین حالات ریفکتور تغییر نام متغیرها و اعضاء به نام های مناسب تر و معنی دار تر است. یک مثال دیگر از ریفکتور استفاده از foreach بجای for برای مرور مجموعه هاست (البته تنها در صورتی که از یک مجموعه یا ارایه استفاده می کنید.) خلاصه اینکه هر کاری بکنید تا کدتان تمیزتر و سریعتر شود.
Test Frameworks در واقع مجموعه ابزارها و چارچوب ها برای ساده تر، سریع تر و منظم تر کردن تست برنامه است. امروزه کمتر پیش میاید که بخواهیم برنامه خود را به صورت دستی و بدون استفاده از این فریم ورک ها تست کنیم. اغلب این ابزارها تست ها را به صورت اتوماتیک اجرا می کنند. اما این ابزار تست ها را نمی نویسد و شما باید شخصاً برای این کار آستین بالا کشیده و کدهای تست را بنویسید.
فریم ورک رایج برای جاوا jUnit و برای دات نت Nunit می باشد. اما اخیراً ویژوال استودیو ابزارهای فوق العاده ای را ارائه داده؛ ابزار های تست از نسخه 2012 ویژوال استودیو به بعد پیشرفت قابل ملاحظه ای کرده اند. این امر اهمیت روز افزون مقوله تست نرم افزار را نشان می دهد. این بود دیدگاه بنده از مقوله تست. اگر معتقدید جایی اشتباه کرده ام یا موردی را از قلم انداخته ام، خوشحال میشم در بخش نظرات یادآوری کنید. امیدوارم از این مقاله استفاده لازم را برده باشید؛ تا دیداری دیگر بدرود.
