معرفی انواع روش های تست و بررسی کیفیت نرم افزارها

یکی از فاز های مهم در تولید محصولات نرم افزاری، تست نرم افزار و بررسی کیفیت محصول تولید شده است. متاسفانه در کشور ما آنچه که از سوی برنامه نویسان و شرکت های برنامه نویسی بسیار مورد کم لطفی قرار گرفته، موضوع کیفیت نرم افزار یا Quality Assurance است. تقریباً در بسیاری از نهادها و شرکت های برنامه نویسی اتمام کد نویسی به منزله اتمام و آماده شدن برنامه است.

دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران

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

  1. آشنایی با تست برنامه
  2. انواع تست و آزمون ها
  3. معیارهای تست برنامه
  4. روش های انجام تست
  5. زمان مناسب انجام تست
  6. ابزارهای انجام تست

روشهای کشف خطا در برنامه ها

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

Debug یا خطایابی چیست؟

این روش از قدیم الایام برای کشف دلیل خطاهای برنامه مورد استفاده قرار می گرفته. در این روش برنامه نویس خط به خط کد خود را مطالعه می کند تا دلیل و عامل خطاهای موجود در برنامه کشف و رفع کند. در واقع هدف دیباگ آنست که کشف کند به چه دلیل یک باگ در برنامه رخ داده؛ بنابراین دیباگ یک فعالیت رفع اشکال است نه کشف اشکال. در این روش به نام متغییرها و طریقه استفاده از آنها، به حلقه ها و تمام ساختارهای موجود در برنامه توجه می کنیم، تا دلیل رخ دادن یک خطا را کشف کرده و آنرا رفع کنیم. دیباگ برای کشف سه نوع خطا استفاده می شود که در ذیل توضیح داده شده اند:

خطای لغوی یا Syntax Error چیست؟

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

خطاهای نحوی یا Semantic Error چیست؟

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

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 در لیست خطاها دیده می شود. توجه داشته باشید که این خطاها اغلب اوقات نمی توانند از اجرای برنامه جلوگیری کنند اما نتیجه ای که میخواهید را به شما نخواهد داد.

خطاهای منطقی یا Logical Errors چیست؟

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

این خطاها در اثر اشتباه در تبدیل الگوریتم و فلوچارت به کد ایجاد می شوند. یکی از خطاهای رایج از این نوع خطای Off-By-One است که در هنگام استفاده از حلقه ها ایجاد می شود. در این حالت حلقه شما یک دور کمتر یا بیشتر می چرخد و نتیجه خطا را به شما می دهد. بهشت خطاهای منطقی، زبان های قدیمی مانند اسمبلی و C و C++ هستند. در این زبانها به دلیل استفاده از برخی ساختارها (مانند اشارگرها و goto) احتمال رخ دادن خطاهای منطقی بسیار بالاست.

تست برنامه چگونه انجام می شود؟

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

Code Review یا مرور کد چیست؟

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

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

شما کد را نوشتید و به عنوان خالق آن نمی توانید آنرا نقد و بررسی کنید. درست مانند یک فیلم ساز که فیلمی را می سازد و دیگران آنرا نقد می کنند؛ کد شما نیز باید توسط متخصصان و برنامه نویسان دیگر نقد و بررسی شود. Code Review معمولاً در قالب جلسات پنج نفره و کاملاً رسمی انجام می شود. خب از بحث اصلی خود که تست است دور نشویم و در همینجا مبحث مرور کد را خاتمه می دهیم.

اهمیت تست برنامه در چیست؟

اما چه اهمیتی دارد که کلی از وقت خود را برای تست برنامه ای که تولید کردیم تلف کنیم. من معمولاً برای اثبات اهمیت یک چیز مصداقهای آنرا ذکر می کنم. در اینجا نیز به طور خلاصه چند نمونه را ذکر خواهم کرد:

  1. در سال 2002 طبق تحقیقاتی که یکی از موسسات معتبر انجام داده خطاهای نرم افزاری بیش از 59.5 بیلیون دلار به اقتصاد آمریکا ضرر زده.
  2. یکی از مراحل تضمین کیفیت نرم افزار خطایابی و تست آن است با تست می توان به صورت متوسط 80 درصد خطاها را در برنامه پیش از آنکه ضرری برای ما و اعتبارمان داشته باشند کشف و رفع کنیم.

امیدوارم که با این مصادیق قانع شده باشید که از این پس برنامه های خود را قبل از انتشار تست کنید!!!

چه چیزی را تست کنیم؟

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

معیارهای اندازه گیری تست برنامه

این معیارها مشخص می کنند که چند درصد از کد خود را تست کردید. مهم ترین این معیارها دو مورد گفته شده در ذیل است.

Code Coverage چیست؟

Code Coverage یا به اصطلاح پوشش کد میزان خطوطی که تحت تست و بررسی قرار گرفته اند را نشان می دهد. برای پوشش حداکثر کد به نکات زیر دقت کنید:

  1. دستورات خطی تنها به یک متد تست نیاز دارند؛ ساده ترین دستورات برای تست، این نوع دستورات خطی هستند؛ یعنی دستوراتی که شاخه به شاخه نمی شوند. در این دستورات از حلقه و شرط استفاده نشده و تنها یک سری عبارات ساده، خط به خط و پشت سر هم نوشته شده اند.
  2. شرط if ساده دو تست نیاز دارد؛ یک تست برای زمانی که شرط true شود و یکی دیگر نیز برای زمانی که شرط false شود. این شرط دو شاخه یا Branch دارد. (به هر مسیر از کد که می تواند اجرا شود یک Branch گفته می شود)
  3. هر شرط ترکیبی که دو شرط درون خود داشته باشد چهار متد تست باید داشته باشد. یکی برای حالت FF یکی برای حالت TF دیگری برای حالت FT و آخری نیز برای حالت TT. خلاصه اینکه برای هر شرط در دستور if دو حالت داریم که میزان تست های مورد نیاز نیز براساس تعداد شروط به صورت نمایی افزایش میابد.
  4. برای دستور switch نیز به ازای هر case یک متد تست باید طراحی کنیم.

Data Coverage چیست؟

علاوه بر اینکه خطوط کد را چک می کنیم لازم است که داده های مختلفی به هر قطعه کد بدهیم تا ببینیم که در هر حالت کار را درست انجام می دهد یا خیر. در Data Coverage محدوده خاصی از داده های درست و غلط را به متدهای خود تزریق می کنیم تا ببینیم در هردو حالت چه اتفاقی بر سر نتیجه عملیات می افتد. آیا متدها در هر صورت درست کار می کنند یا اینکه ... بهترین داده هایی که می توان برای این کار برگزید به عبارت زیر هستند:

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

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

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

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

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

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


نظرات