گام‌هایی کوچک با تست

گام‌هایی کوچک با تست

 

در سال ۱۹۹۹ گروهی از توسعه‌دهندگان متدولوژی eXtreme Programing  یا به اختصار XP را پدید آوردند. در این متدولوژی به جای آن‌که ابتدا کد برنامه را نوشته و سپس آن را تست نمایند، برعکس عمل می‌کردند. یعنی ابتدا کد تست را می‌نوشتند، سپس کدهای برنامه را برای پاس کردن آن تست‌ها اضافه می‌کردند. به این صورت‌ که، قبل از شروع به طراحی و پیاده سازی روال‌ها، ابتدا یک تست برای نیازها و یا خواسته جدید پیاده‌سازی می‌شد و بعد با توجه به ورودی و خروجی‌های تست، نیازهای تست را با کمترین کد پیاده سازی می‌کردند. این عمل تا زمانی ادامه پیدا می‌کرد ‌که به نتیجه نهایی و مطلوب برسد. به این شیوه، برنامه نویسی اول تست Test‌First Development می‌گفتند که به توسعه تست محور Test Driven Development یا به اختصار TDD نیز معروف است. TDD حاصل تکامل فرآیند تولید نرم‌افزار بوده و بسیاری از مشکلات و چالش‌های تولید نرم‌افزار را رفع می‌کند.TDD ترکیبی از روش TFD یا TestFirst Development و refactoring است. دو دیدگاه مختلف در مورد هدف استفاده از TDD وجود دارد:

دیدگاه اول: این دیدگاه معتقد است که TDD روشی برای تمرکز بیشتر بر روی فاز طراحی می‌باشد. در واقع هدف اصلی آن استخراج هر چه بیشتر نیازمندی‌هاست و این کار را با کمک use case ها و user story ها انجام می‌دهد.
دیدگاه دوم: این دیدگاه،TDD را یک روش برنامه‌نویسی می‌داند. در واقع TDD باعث می‌شود کد مرتبی نوشته شده که به خوبی کار می‌کند.
به‌طور کلی نوشتن تست باعث می‌شود که با اضافه شدن کدهای جدید در برنامه، از به وجود آمدن باگ تا حدی جلوگیری شود. این روش را می‌توان به صورت چرخه‌ای نشان داد:
چرخه حیات TDD :
۱– افزودن تست قبل از نوشتن کد: در این بخش برنامه‌نویس با توجه به خواسته‌ها و یا نیازهای جدید یک تست را پیاده‌سازی می‌کند.
۲- اجرا کردن تست‌ و fail شدن آن: البته این تست درحالت عادی باید fail شود، چون اگر fail نشود به معنی وجود نیاز یا خواسته بوده و نیاز به توسعه نیست. برای پیاده‌سازی این تست از Use case ها و … برای فهم کامل نیازها می‌توان استفاده نمود. دو مرحله فوق شامل بخش Red نمودار هستند، زیرا با اجرای تست ، تست رد شده و نتیجه قرمز رنگ است.
۳- نوشتن کدی که منجر به Pass شدن تست‌ها می‌شود: در این مرحله کدهای لازم برای برآورده شدن نتیجه مطلوب نوشته شده تا تست پاس شود. کدها به‌صورت خیلی کلی و سطحی پیاده‌سازی می‌شود. البته بعد از گذر از چند مرحله، پیاده‌سازی کدها پیچیده‌ترو پیشرفته‌تر خواهد شد. این مرحله شامل بخش Green نمودار است، زیرا تست پاس شده است و نتیجه سبز رنگ است.
۴- اجرای تست‌ها و Pass شدن همه تست‌ها : در این مرحله همه تست کیس‌های نوشته شده با موفقیت انجام می‌شوند. گذر از این مرحله یعنی پیاده‌سازی دقیق هر آن‌چه‌ که نیاز بوده است.
۵- Refactoring : در این مرحله کدهای نوشته شده دوباره بررسی می‌شود و در صورت نیاز تصحیح، پیاده‌سازی یا حذف صورت می‌گیرد. بنابراین کدهای برنامه بهبود مییابند تا مطابق با اصول و قواعد طراحی باشند. البته عملکرد بیرونی کد نبایستی تغییر کند و باعث رد شدن تستی که قبلا پاس شده، شود. این مرحله شامل بخش زرد رنگ نموداراست.

graphic_1-farsi

از مزایای TDD می توان موارد زیر را نام برد:

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

طراحی بهتر : برنامه‌نویسان با سبک TDD قواعد SOLID را رعایت کرده که باعث طراحی بهتر برنامه می‌شود.

تطبیق کامل کد با نیازمندی بیزنس : وقتی که نیازمندی به صورت یک تست نوشته شود، کدی که آن تست را برآورده می‌کند با احتمال بسیار زیاد آن نیازمندی را نیز برآورده خواهد نمود.

– طراحی کتابخانه‌های ساده‌تر و متمرکز‌تر : به خاطر این‌که برای اکثر کلاس‌های برنامه Interface ساخته می‌شود و شما اولین تست کننده کلاس خود هستید، توانایی طراحی کتابخانه مناسب را در شما به وجود می‌آورد.

تقویت ارتباط بین برنامه ساز و کاربر بیزنس : تست‌ها بیان کننده نیازمندی‌های کاربر بیزنس است، تستر می‌تواند در فرآیند توسعه نرم‌افزار شریک شده و ارتباط محکمی بین تیم توسعه و تیم تست برقرار شود.

کدهای بدون استفاده را از برنامه بیرون نگه میدارند: ممکن است برنامه‌نویس‌ها کدهایی که احتمالا برای رفع نیازمندی‌های بعدی است را بنویسند که بعدا مورد نیاز نباشد، با TDD چنین مشکلی پیش نمی‌آید.

امکان تست رگراسیون : شما به محض نوشتن یک تست و پاس کردن آن می‌توانید کل تست‌ها را اجرا کنید تا مطمئن شوید که کد جدید اثر جانبی بر سایر بخش‌های برنامه نداشته است.

پیشگیری از بروز خطاهای تکراری: وقتی‌که یک تست برای یک باگ ظاهر شده در برنامه می‌نویسید، پس از هر بار اجرای تست‌ها می‌توانید مطمئن شوید که دیگر چنین باگی رخ نمی‌دهد.

معماری با کیفیت با امکان توسعه‌پذیری و تغییرپذیری: برنامه‌نویسی همراه  با تفکر تستر، باعث تولید برنامه‌ای مستحکم می‌شود که به راحتی قابل تغییر بوده و نسبت به خطاها مقاوم است.

-کاهش زمان تولید نرم‌افزار

-بالا رفتن اعتماد شما نسبت به کد برنامه

-باگ کمتری تولید شده بنابراین اعتماد مصرف‌کنندگان نیز نسبت به برنامه شما بالا می‌رود.

-نظم در کد

-انعطاف پذیری بیشتر برنامه

-ریسک تولید نرم‌افزار به علت باگ کمتر به حداقل می‌سد.

یکی از مشکلات TDD این است که تست‌ها تنها برای توسعه دهندگان قابل درک هستند و افراد بیزنس نمی‌توانند از آن سر در بیاورند. همان‌طور که بیان شد هر تست بیانگر یک نیازمندی است که با پاس شدنش، آن نیازمندی برطرف می‌شود. بنابراین اگر تست‌ها برای افراد بیزنس قابل درک باشند، می‌توانیم از آنها برای طراحی و نظارت بر تست‌ها استفاده کنیم.

برای رسیدن به این هدف روش توسعه مبتنی بر رفتار (Behavior Driven Development) مطرح شده است. BDD یکی از مشتقات TDD است که بر اساس هم‌کاری نزدیک تیم توسعه و تیم بیزنس برای ساخت نرم‌افزار با کیفیت عمل می‌نماید. در BDD به جای عبارت تست، از مشخصه (Specification) استفاده می‌گردد. این روش توسعه، از الگوریتم زیر پیروی می‌کند :

نیازمندی‌های بیزنس به شکل رفتارهای نرم‌افزار تعریف می‌گردند و هر رفتار به مجموعه‌ای از مشخصه‌های قابل اجرا تبدیل می‌شوند. مشخصه‌ها به زبان بیزنس بوده و برای همه قابل فهم است. کدهای مناسب برای پاس کردن مشخصه‌ها نوشته می‌شوند. با اعمال قواعد Refactoring کدهای برآورده کننده مشخصه‌ها بهینه می‌شوند. هر تغییر یا نیازمندی جدید به صورت یک رفتار در نرم‌افزار ثبت شده و مراحل فوق برای آن تکرار می‌شود.

برای اجرای TDD نیاز به Automated Test Unit می‌باشد. در واقع تست‌ها قبل از کد پیاده‌سازی می‌شوند و فقط True یا False برمی‌گردانند. ابزارهای مورد استفاده برای Unit testing برای PHP پکیجی با اسم PHPUnit است برای جاوا JUnit و برای دات نت NUnit که توسط آن‌ها می‌توانید تست‌های نوشته شده را اجرا کنید و Fail و Pass شدن آن‌ها را تحت نظر داشته باشید.

 منبع (+ )

8 نظر برای نوشته «گام‌هایی کوچک با تست»

  • دی ۱۲, ۱۳۹۳ در ساعت ۳:۲۰ ب.ظ
    لینک

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

    پاسخ
    • دی ۱۳, ۱۳۹۳ در ساعت ۹:۴۴ ق.ظ
      لینک

      سلام ممنون
      یکی از اهداف تستولوژی همکاری دوستان علاقه‌مند به تست نرم‌افزار هست
      در آینده‌ای نه چندان دور ایده‌هایی برای این همکاری در سایت اعلام می‌شه.

      پاسخ
  • بهمن ۱۱, ۱۳۹۳ در ساعت ۹:۱۵ ق.ظ
    لینک

    مطالب خیلی خوبه ، امیدوارم در ادامه مقالات به کد نویسی عملی انوع تست هم برسیم :دی

    پاسخ
    • بهمن ۱۱, ۱۳۹۳ در ساعت ۱:۳۶ ب.ظ
      لینک

      ممنون
      در حال حاضر مشغول مطالعه TestNG هستم. در آینده شاید پستی در باب کدنویسی تست هم منتشر شد !

      پاسخ
  • اسفند ۱۸, ۱۳۹۳ در ساعت ۸:۵۷ ق.ظ
    لینک

    سلام
    من نرم افزار خوندم و به تازگی در شرکتی برای تست نرم افزار استخدام شدم
    ولی پروسه تست در اینجا زیاد رو اصول نیست
    میخواستم راهنماییم کنید که چجوری میتونم تست نرم افزار های اینجارو رو اصول انجام بدم
    اینم بگم که برنامه نویس نبودم

    پاسخ
    • تیر ۲۰, ۱۳۹۴ در ساعت ۱۱:۱۲ ق.ظ
      لینک

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

      پاسخ
  • بهمن ۳۰, ۱۳۹۴ در ساعت ۱۰:۱۶ ق.ظ
    لینک

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

    پاسخ
  • آذر ۱۶, ۱۳۹۵ در ساعت ۵:۰۶ ب.ظ
    لینک

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

    پاسخ

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *