توسعه آزمون محور

توسعه مبتنی بر آزمون پذیرش (به انگلیسی: Acceptance Test-driven development) ، (خلاصه : ATDD) یک روش توسعه مبتنی بر ارتباط بین مشتریان تجاری ، توسعه دهندگان و آزمایش کنندگان است.  شامل بسیاری از شیوه های مشابه مشخصات با مثال   توسعه رفتار محور،  توسعه محور مثال ،  و پشتیبانی محور است. توسعه همچنین توسعه محور داستان نامیده می شود.  همه این فرایندها به توسعه دهندگان و آزمایش کنندگان در درک نیازهای مشتری قبل از اجرای برنامه کمک می کند و به مشتریان این امکان را می دهد که بتوانند با زبان دامنه خود مکالمه کنند.


ATDD ارتباط تنگاتنگی با توسعه محور تست (TDD) دارد.  این امر با تأکید بر همکاری با مشتری توسعه دهنده و بازرگان تجاری متفاوت است. ATDD شامل تست پذیرش است ، اما نوشتن تست های پذیرش را قبل از شروع برنامه نویسی برنامه نویسی برجسته می کند.

بررسی اجمالیویرایش

آزمون های پذیرش از دید کاربر - نمای بیرونی سیستم.  آنها جلوه های بیرونی قابل مشاهده را بررسی می کنند ، مانند مشخص کردن خروجی صحیح یک سیستم خاص با ورودی خاص. آزمون های پذیرش می توانند تأیید کنند که چگونه وضعیت چیزی تغییر می کند ، مانند سفارش که از "پرداخت" به "حمل شده" می رود. آنها همچنین می توانند تعامل با رابط های سیستم های دیگر ، مانند پایگاه داده های مشترک یا خدمات وب را بررسی کنند. به‌طور کلی ، آنها مستقل از اجرای هستند ، اگرچه ممکن است اتوماسیون آنها نباشد.

ایجادویرایش

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

استراتژی تستویرایش

زمون های پذیرش بخشی از یک استراتژی تست کلی است. آنها آزمایش‌ها مشتری هستند که نشان دهنده هدف تجاری یک سیستم است. تست های مؤلفه تست های پذیرش فنی است که توسط یک معمار ساخته شده است و رفتار ماژول های بزرگ را مشخص می کند. تست های واحد توسط توسعه دهنده ایجاد شده است تا بتواند کد ساده ای را حفظ کند.  آنها غالباً از آزمون های پذیرش و تست های واحد حاصل می شوند. آزمایش عملکردی متقابل شامل تست قابلیت استفاده ،  آزمایش اکتشافی ،  و آزمایش خاصیت (مقیاس بندی و امنیت) است.

معیارهای پذیرش و آزمایش‌هاویرایش

معیارهای پذیرش توصیفی است که توسط یک تست بررسی می شود. با توجه به الزامی از قبیل "من به عنوان یک کاربر ، می خواهم کتابی را از کتابخانه بررسی کنم" ، یک معیار پذیرش می تواند باشد "تأیید کنید که کتاب به عنوان بررسی شده علامت گذاری شده است." آزمایش هر بار با همان اثر قابل اجرا است.

قالب آزمایشویرایش

آزمون های پذیرش معمولاً از این فرم پیروی می کنند: [۱]

داده شده (تنظیم)

یک حالت مشخص از یک سیستم است.

وقتی (ماشه)

یک عمل یا رویدادی رخ می دهد

سپس (تأیید)

وضعیت سیستم تغییر کرده یا خروجی تولید شده است

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

Given Book that has not been checked out
And User who is registered on the system
When User checks out a book
Then Book is marked as checked out

تست کاملویرایش

مراحل قبلی هیچ داده نمونه خاصی را شامل نمی شود ، بنابراین برای تکمیل آزمون اضافه شده است:

داده شده:

کتابی که بررسی نشده است
کتابها
عنوان بررسی شد
کتاب عالی نه
کاربری که در سیستم ثبت شده است

منابعویرایش

  1. Pugh, Ken (2011). Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration. Addison-Wesley. ISBN 978-0321714084.