موضوع مقاله: توسعه رفتارمحور | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # توسعه رفتارمحور | مقدمه: توسعه رفتارمحور در مهندسی نرم‌افزار، یک فرایند توسعه نرم‌افزار است که از توسعه آزمون محور مشتق شده‌است. | ## بخش 1: توسعه رفتارمحور | توسعه رفتار محور تکنیک‌ها و قواعد اساسی، توسعه آزمون محور را با ایده‌های طراحی دامنه محور و تجزیه و تحلیل و طراحی شی گرا ادغام می‌کند تا برای تیم‌های توسعه و مدیریت نرم‌افزار، ابزارها و فرایندهای مشترکی برای همکاری در توسعه نرم‌افزار ارائه کند. اگرچه این فرایند، عمدتاً ایده‌ای در مورد چگونگی مدیریت توسعه نرم‌افزار با در نظر گرفتن منافع تجاری و بینش فنی است، لیکن در عمل، استفاده از ابزارهای نرم‌افزاری تخصصی را برای حمایت از روند توسعه در نظر می‌گیرد. م طراحی شده‌اند، اما آن‌ها می‌توانند به عنوان انواع متفاوتی از ابزارهایی که از توسعه مبتنی بر تست پشتیبانی می‌کنند دیده شوند. توسعه رفتار محور تا حد زیادی با استفاده از یک روش سادهٔ زبان مختص دامنه از طریق بهره‌گیری از ساختارهای زبان طبیعی (از جمله جمله‌های انگلیسی مانند) که می‌تواند رفتار و نتایج مورد انتظار را بیان کند، میسر می‌شود. برای مدت طولانی «تست اسکریپت»ها به عنوان یک ابزار فراگیر برای درجه‌های مختلفی از پیچیدگی DSLها مورد استفاده بوده‌اند. توسعه رفتار محور یک تجربه فنی اثر بخش به حساب می‌آید، به خصوص هنگامی که «فضای مسئله» کسب و کار مورد نظر پیچیده‌است. نتیجه کار ایجاد یک همبستگی نزدیکتر بین معیار پذیرش برای یک تابع مشخص و تست‌هایی است که برای تأیید این قابلیت استفاده می‌شود. به همین منوال، به‌طور کلی توسعه رفتار محور یک گسترش طبیعی برای آزمایش‌های توسعه آزمون محور (TDD) می‌باشد. تمرکز اصلی توسعه رفتار محور بر موارد زیر است: از کجای روال شروع کنیم چه چیزی باید مورد آزمون قرار بگیرد و چه چیزی نه. در قلب توسعه رفتار محور یک بازخوانی دربارهٔ رویکرد واحد تست و آزمون پذیرش وجود دارد که به‌طور طبیعی با این مسائل همراه هستند. م پیشنهاد می‌کند که عناوین تست واحد، جمله‌های کاملی باشند که با یک عبارت شرطی آغاز می‌شوند (به عنوان مثال "باید" به زبان فارسی) و باید به ترتیب ارزش کسب و کار نوشته شود. آزمون پذیرش باید با استفاده از چارچوب استاندارد یک داستان کاربر تهیه گردد: "به عنوان یک [نقش] من خواستار [ویژگی] هستم به‌طوری‌که [بهره]". معیارهای پذیرش باید به در قالب سناریو نوشته شده و به صورت کلاس پیاده‌سازی شوند: با توجه به [وضعیت اولیه] زمانی که [رویداد رخ می‌دهد] باید [اطمینان از برخی از نتایج]. با شروع از این نقطه، بسیاری از افراد در طول سالیان چهار چوب‌هایی برای ت.ر.م طراحی کرده‌اند که در نهایت آن را به عنوان یک چارچوب ارتباطی و همکاری برای توسعه دهندگان، تضمین کنندگان کیفیت و شرکای غیرفنی یا ذینفعان کسب و کار در یک پروژه نرم‌افزاری شکل داده‌اند. م) یک روش چابک نسل دوم، یکپارچه، مبتنی بر کشش، چند مالکه و متشکل از مقیاس چندگانه، با قابلیت خودکار سازی بالاست. م یک چرخه تعاملات با خروجی‌های تعریف شده را توصیف می‌کند، که در نتیجه تحویل کار، نرم‌افزار مورد آزمایش قرار می‌گیرد.دن نورس چهارچوب مبتنی بر توسعه رفتار محور JBehave، را ایجاد کرد که توسط یک چهارچوب ت.ر. اصول توسعه رفتار محور توسعه مبتنی بر تست یک روش توسعه نرم‌افزاری است که اساساً بیان می‌کند برای هر واحد نرم‌افزاری یک توسعه دهنده نرم‌افزار باید: نخست یک مجموعه آزمون برای واحد تعریف کند. این تعریف از آنجا که تست‌ها را از لحاظ الزامات نرم‌افزاری سطح بالا، جزئیات فنی ریز یا هر چیز دیگر در بین آن‌ها تبیین می‌کند نسبتاً غیر اختصاصی است؛ بنابراین، از این نقطه نظر می‌توان به ت.ر. توسعه رفتار محور مشخص می‌کند که آزمایش‌های هر واحد نرم‌افزاری باید با توجه به رفتار مورد نظر آن واحد باشد. الهام گرفتن از توسعه نرم‌افزاری چابک برای «رفتار مورد نظر» در این مورد شامل الزاماتی است که توسط کسب و کار تعیین می‌شود — یعنی رفتار مورد نظر که ارزش کسب و کار را برای هر نهاد که واحد نرم‌افزاری را در دست ساخت دارد، به کار گرفته‌است. مشخصه‌های رفتاری به دنبال این انتخاب اساسی، انتخاب دوم ساخته شده توسط BDD در ارتباط با چگونگی مشخص کردن نحوه «رفتار مورد نظر» می‌باشد. در این زمینه، BDD تصمیم به استفاده از قالب نیمه رسمی برای خصوصیات رفتاری می‌کند که از مشخصات داستان کاربری در حوزه تحلیل و طراحی شی گرا گرفته شده‌است. جنبه‌های سناریو این قالب ممکن است به عنوان اعمال منطق هوآر به مشخصه رفتاری واحدهای نرم‌افزاری با استفاده از زبان دامنه در نظر گرفته شود. ت.ر.م مشخص می‌کند که تحلیلگران کسب و کار و توسعه دهندگان باید در این زمینه همکاری داشته باشند و رفتارها را در قالب عبارت‌های داستان‌های کاربریی مشخص کنند، که هر کدام صریحاً در یک سند اختصاصی نوشته می‌شوند. هر داستان کاربر به نحوی باید از ساختار زیر پیروی کند: عنوان: داستان باید یک عنوان روشن و صریح داشته باشد. روایت یک بخش مقدماتی کوتاه که مشخص‌کننده موارد زیر است چه کسی: (کدام تجارت یا نقش پروژه) پیش برنده یا ذی‌نفع اصلی داستان است (بازیگرانی که از داستان سود می‌برند) چه: اثری که ذینفعان می‌خواهند داستان داشته باشد. چنین سناریویی دارای ساختار زیر است: با مشخص کردن شرایط اولیه که در آغاز سناریو درست در نظر گرفته شده‌اند شروع می‌شود. توسعه رفتار محور هیچ الزام رسمی برای اینکه دقیقاً چگونه این داستان‌های کاربر باید نوشته شود ندارد، اما اصرار دارد که هر تیم استفاده‌کننده از آن یک فرمت ساده و استاندارد برای نوشتن داستان‌های کاربر که شامل عناصر ذکر شده در بالا است، طراحی کند. | ## بخش 2: توسعه رفتارمحور | با این حال، در سال ۲۰۰۷، دن نورت یک قالب را برای فرمت متنی پیشنهاد کرد که در ابزارهای مختلف نرم‌افزار ت.ر. مثال بسیار کوتاهی از این فرمت ممکن است مانند این باشد: داستان: مرجوعی کالا به عنوان یک صاحب فروشگاه به منظور پیگیری موجودی کالا من می‌خواهم کالاهای بازگشتی را به موجودی کالا، اضافه کنم. سناریو ۱: موارد مسترد باید به موجودی کالا افزوده شود داریم: یک مشتری قبلاً یک ژاکت سیاه از من خریداری کرده‌است و من سه ژاکت سیاه در انبار دارم. داریم: مشتری قبلاً یک لباس آبی از من خریداری کرده‌است و من دو لباس آبی در انبار موجود دارم و من سه لباس سیاه در انبار موجود دارم. وقتی که او لباس آبی را برای جایگزینی با رنگ مشکی بازمی‌گرداند آنگاه من باید سه لباس آبی در موجودی کالا داشته باشم. خصوصیات به عنوان زبان فراگیر توسعه رفتار محور مفهوم زبان فراگیر را از طراحی دامنه محور وام می‌گیرد. زبان فراگیر یک زبان نیمه رسمی است که توسط همه اعضای یک تیم توسعه نرم‌افزاری به اشتراک گذاشته شده‌است - هم توسعه دهندگان نرم‌افزار و هم پرسنل غیر فنی. زبان مورد نظر، به عنوان یک ابزار رایج برای بحث در رابطه با دامنه نرم‌افزار، توسط همه اعضای تیم مورد استفاده و توسعه قرار می‌گیرد. یک مخاطره متداول در توسعه نرم‌افزار شامل تفکیک ارتباطات بین توسعه دهندگان و ذینفعان کسب و کار است. م از مشخصات رفتار مورد نظر به عنوان یک زبان عمومی برای اعضای تیم پروژه استفاده می‌کند. م بر روی یک زبان نیمه رسمی برای خصوصیات رفتاری اصرار می‌ورزد: برخی از تشریفات برای داشتن یک زبان فراگیر الزامی هستند. علاوه بر این، داشتن چنین زبان فراگیری، یک مدل دامنه مشخصات را طوری ایجاد می‌کند که از رسمی بودن نتیجه شده باشند. همچنین چندین سناریو، هر کدام با پیش شرط، اجراکننده و نتیجه مورد انتظار را شرح می‌دهد. هر یک از این قسمت‌ها دقیقاً با بخش رسمی زبان شناخته می‌شود (بع نوان مثال ممکن است اصطلاح داریم (Given) ممکن است به عنوان یک کلمه کلیدی در نظر گرفته شود) و در نتیجه ممکن است به طریقی توسط یک ابزاری که قسمت‌های فرمال زبان فراگیر را درک می‌کند، مورد استفاده قرار گیرد. با این حال، مدلسازی گرافیکی سناریوهای ادغام نیز در عمل به‌طور موفقیت‌آمیز برای مثال برای اهداف تست استفاده شده‌است. تخصصی قطعه سازی پشتیبانی به نظر می‌رسد، مانند تمرین طراحی مبتنی بر تست، توسعه رفتار محور مبتنی بر استفاده از ابزار پشتیبانی تخصصی در یک پروژه است. م مشابه آنچه برای TDD است می‌باشد، اما درخواست‌های بیشتری را نسبت به توسعه دهندگان ابزار TDD اولیه ایجاد می‌کند. م یک چارچوب آزمایشی برای نرم‌افزار است، کاملاً شبیه ابزارهایی که TDD را پشتیبانی می‌کنند. با این حال، در جایی که ابزارهای TDD در آنچه که برای تعیین تست مجاز است تمایل به فرمت کاملاً آزاد دارد، ابزار ت.ر. همان‌طور که مورد بحث قرار گرفت، زبان فراگیر، تحلیلگران تجاری را قادر می‌سازد تا الزامات رفتاری را به نحوی که توسعه دهندگان آن را درک کنند، بنویسند. م این است که اسناد نیازمندیها را مستقیماً به عنوان مجموعه‌ای از آزمون‌های قابل اجرا ایجاد کند. چنانچه این مورد به دلایل مربوط به ابزار فنی که امکان اجرای مشخصات را فراهم می‌کند قابل دستیابی نباشد، باید سبک نوشتن الزامات رفتاری را تغییر داده یا ابزار را تغییر دهید. اجرای دقیق الزامات رفتاری در هر ابزار متفاوت است، اما عملکرد چابک با روند عمومی زیر مطابقت دارد: ابزار یک سند مشخصات را می‌خواند. این ابزار مستقیماً به‌طور کامل بخش‌های رسمی زبان فراگیر (مانند کلمه کلیدی داریم (Given) در مثال بالا) را درک می‌کند. هر عبارت مستقل در یک سناریو برای آزمون داستان کاربر به نوعی پارامتر تبدیل می‌شود. این ابزارها از توضیحات متنی برای موارد استفاده و چندین ابزار دیگر (مانند CBehave) استفاده می‌کنند. با این حال، این فرمت لازم نیست و چنان‌که ابزارهای دیگری وجود دارد که از فرمت‌های دیگر نیز استفاده می‌کنند. مثال برای ابزارها نمونه‌های متعددی از ابزارهای نرم‌افزاری BDD که در پروژه‌ها امروزی، برای زبانها و سیستم‌های عمل مختلف مورد استفاده هستند وجود دارد. | ## بخش 3: توسعه رفتارمحور | یک متخصص دامنه (یا تحلیلگر کسب و کار) ممکن است بخواهد مشخص کند که وقتی کسی تنظیمات پیکربندی اولیه خانه‌های بازی را تنظیم کند چه باید رخ دهد. برای انجام این کار، ممکن است بخواهید نمونه‌ای از تعدادی از اقداماتی که توسط فردی که خانه‌ها را سوییچ می‌کند مشخص کند. با رفتن به بخش روایت، او می‌تواند این کار را با نوشتن سناریو زیر به یک سند متن ساده (که نوعی سند ورودی است که JBehave قادر به خواندن آن است): داریم: یک بازی ۵ در ۵ وقتی که من وضعیت خانه (۳, ۲)را تغییر می‌دهم آنگاه جدول بازی باید وضعیت زیر را داشته باشند ... وقتی که من وضعیت خانه (۳, ۱) را تغییر می‌دهم آنگاه جدول بازی باید وضعیت زیر را داشته باشند ... وقتی که من وضعیت خانه (۳, ۲)را تغییر می‌دهم آنگاه جدول بازی باید وضعیت زیر را داشته باشند ... متن‌های با فونت پررنگ بخشی از ورودی نیست؛ بلکه در اینجا آمده‌است تا نشان دهد که کدام کلمات به عنوان زبان رسمی شناخته شده‌اند. بر این اساس JBehave قادر به خواندن فایل متنی حاوی سناریو و تجزیه آن به مقادیر (یک بند تنظیم و سپس سه رویداد با شرایط قابل تأیید) می‌باشد. سپس JBehave این مقررات را می‌گیرد و آن‌ها را به کدی که قادر به تنظیم یک آزمون و پاسخ به فراخوانندگان رویداد و تأیید نتیجه است ارسال می‌کند. این کد باید توسط تیم توسعه دهندگان پروژه نوشته شود (در زبان جاوا به دلیل اینکه پلت فرم JBehave بر اساس زبان جاوا می‌باشد). در این مورد، کد مورد نظر ممکن است مشابه کد زیر باشد:کد برای هر نوع عبارتی در یک سناریو یک روش دارد. JBehaveJBehave مشخص می‌کند که کدام روش با کدام عبارت، از چه کاربردی از حاشیه نویسی استفاده کند و هر متد را در هنگام اجرا از طریق سناریو فراخوانی کند .انتظار می‌رود متن هر عبارت سناریو با قالب متن داده شده در کد برای آن بند مطابقت داشته باشد (برای مثال، انتظار می‌رود که در یک سناریو عبارت داریم (Given) با یک جمله از فرم "یک بازی X در Y" دنبال شود). JBehave از تطبیق عبارات به قالب‌ها پشتیبانی می‌کند و دارای پشتیبانی داخلی برای درآوردن الفاظ از قالب و انتقال آن‌ها به عنوان پارامتر به متدها در کد آزمون می‌باشد. کد تست برای هر نوع بند در یک سناریو یک نوع پیاده‌سازی فراهم می‌کند که با کد مورد آزمایش تعامل می‌کند و بر اساس سناریو تست انجام می‌دهد. عملکرد اصلی این کد ایجاد پلی بین یک فایل متنی با یک داستان و کد مورد آزمایش است. توجه داشته باشید که کد آزمون دارای دسترسی به کد مورد آزمایش (در این مورد یک نمونه از بازی) است و در طبیعت بسیار ساده است. کد آزمون باید ساده باشد، در غیر این صورت یک توسعه دهنده مجبور به نوشتن آزمون برای آزمایشهایش خواهد بود. در نهایت، برای اجرای آزمون، JBehave به برخی از برنامه‌های رابطی نیاز دارد که فایل‌های متنی را که حاوی سناریو هستند و وابستگی‌ها (مانند موارد بازیGame)را به کد آزمون تزریق می‌کند، شناسایی کند .این کد رابط در اینجا نشان داده نمی‌شود، زیرا یک نیاز فنی JBehave است و مستقیماً به اصل تست ت.ر.م مربوط نمی‌شود. داستان در مقابل مشخصات یک زیر شاخه جداگانه توسعه مبتنی بر رفتار به وسیلهٔ ابزارهایی است که از مشخصات به عنوان زبان ورودی به جای داستان کاربر استفاده می‌کنند. ابزارهای مشخصات از داستان‌های کاربر به عنوان یک فرمت ورودی برای سناریوهای آزمایش استفاده نمی‌کنند، بلکه از ویژگی‌های عملکردی برای واحدهای مورد آزمایش استفاده می‌کنند. این مشخصات اغلب دارای ماهیت فنی بیشتری نسبت به داستان‌های کاربر هستند و معمولاً برای ارتباط با پرسنل تجاری به اندازه داستان‌های کاربر، مناسب نیستند. یک نمونه از این مشخصه برای پشته می‌تواند به صورت زیر باشد: مشخصات: پشته وقتی که: یک پشته جدید ایجاد می‌شود. وقتی که: یک عنصر به پشته اضافه می‌شود آنگاه: این عنصر در بالای پشته قرار دارد وقتی که: یک پشته دارای N عنصر است. و عنصر E در بالای پشته قرار دارد آنگاه: a یک دستور pop عنصر E را بازمی‌گرداند و اندازه جدید پشته N-1 است چنین ویژگی ممکن است دقیقاً مشخص کند که رفتار مؤلفه مورد آزمایش چیست، اما برای یک کاربر تجاری چندان معنادار نیست. در نتیجه، تست مبتنی بر مشخصات در عمل ت.ر.م به عنوان مکمل تست مبتنی بر داستان دیده می‌شود و در سطح پایین‌تری عمل می‌کند. تست مبنی بر مشخصات اغلب به عنوان یک جایگزین برای آزمایش واحد با فرمت دلخواه دیده می‌شود. از آنجایی که آن‌ها به عنوان جایگزینی برای ابزارهای تست پایهٔ واحد مانند JUnit, دیده می‌شوند، این ابزار تمایل دارد از جدایی داستان و کد تست چشم پوشی کند و ترجیح می‌دهد خصوصیات را مستقیماً در کد تست تعبیه کند. | ## جمع‌بندی | همچنین مفهوم یک پیش شرط مشخصه تحت عنوان بخش before وجود دارد که پیش شرط‌هایی را که مشخصات بر اساس آن است، ایجاد می‌کند.