Payamvdn/NorthPersian_fa_wiki huggingface dataset:
حقوق بشر در مکزیک () به اصول اخلاقی یا هنجارها اشاره دارد که استانداردهای خاصی از رفتار انسان در مکزیک را توصیف می کنند. مشکلات موجود عبارتند از شکنجه، قتل های غیرقانونی و اعدام های سریع، سرکوبی پلیس و اخیراً ترور خبرنگاران مطبوعات. گزارش های دیده بان حقوق بشر. دیده بان حقوق بشر گزارش می دهد که از سال ۲۰۰۶ نیروهای امنیتی مکزیک سربه نیست کردن افراد را گسترش داده اند. همچنین گفته می شود که نیروهای امنیتی مکزیک قتل غیرقانونی شهروندان را به میزان قابل ملاحظه ای بالا برده اند و به طور گسترده ای از شکنجه، ضرب و شتم، القاء غرق شدگی، شوک الکتریکی و سوء استفاده جنسی به عنوان ابزارهایی برای کسب اطلاعات از قربانیان بازداشت شده، بکار می برند. علاوه براین، گزارش می دهد حملاتی که مقامات یا سازمانهای تبهکار به روزنامه نگاران مرتکب می شوند، آنها را مجبور به خودسانسوری می کند. این گزارش همچنین مشکلات مربوط به کودکان مهاجر غیرقانونی، حقوق زنان و دختران، هویت جنسیتی و حقوق معلولین را متذکر می شود. دولت و مبارزه با قاچاق مواد مخدر. در جریان مبارزه دولت با جرایم سازمان یافته مربوط به مواد مخدر، نیروهای امنیتی مرتکب تخلفات حقوق بش
ری شده اند که شامل قتل های غیرقانونی، ناپدید شدن افراد و شکنجه بازداشت شدگان می باشد. تلاش های محدودی برای بررسی و محاکمه این سوءاستفاده ها صورت گرفته است.
پردیس سینمایی آرامش رامسر یک سینما در شهر رامسر، ایران است. این سینما که در مرکز خرید آرامش رامسر قرار دارد در سال ۱۳۹۶ با دو سالن تأسیس شده است.
نگهداری نرم افزار در مهندسی نرم افزار به معنی اصلاح یک محصول نرم افزاری «پس از تحویل» آن است، و هدف این فعالیت آن است که برای بهبود کارایی، و دیگر ویژگی های نرم افزار، خطاهای موجود در آن را تصحیح کند. گرایشی از مهندسی نرم افزار است که شامل نگهداری و اصلاح یک محصول نرم افزاری پس از تحویل است به منظور تصحیح اشکالات پیش آمده و بهبود عملکرد یا ویژگی های دیگر آن نرم افزار. یک دید متعارف نسبت به تعمیر و نگهداری نرم افزار این است که آن را صرفا شامل رفع نقصهای نرم افزاری بدانیم، اما یک مطالعه نشان داده است که بیش از ۸۰٪ از فعالیت های مربوط به تعمیر و نگهداری نرم افزار مرتبط با اقدامات اصلاحی نیست. این دید متعارف توسط کاربرانی که مشکلی در نرم افزار گزارش می دهند که در واقعیت بهبودهایی بر کارایی نرم افزار هستند تقویت می شود. مطالعات جدیدتر درصد فعالیت های مربوط به تعمیر و نگهداری نرم افزار که مرتبط با رفع اشکال هستند را نزدیک به ۲۱٪ گزارش کرده اند. تاریخچه. نگهداری نرم افزار و تکامل سیستم ها برای اولین بار توسط Meir M. Lehman در سال ۱۹۶۹ میلادی مورد بررسی قرار گرفت. طی یک دوره بیش از بیست ساله، تحقیقات او منجر به تدوین
قوانین لیمن (لیمن ۱۹۹۷) شد. یافته های کلیدی تحقیقات وی شامل این است که تعمیر و نگهداری نرم افزار در واقع توسعه تکاملی آن است و نگهداری نرم افزار در واقع از درک آنچه برای سیستم (نرم افزار) در طول زمان اتفاق می افتد در تصمیم گیری کمک می گیرد. لیمن نشان داد که سیستم در طول زمان همچنان در حال تکامل است. آن ها در تکامل و رشد خود در طی زمان پیچیده تر می شوند مگر اینکه برخی از اقدامات مانند کد refactoring به منظور کاهش پیچیدگی صورت پذیرد. در اواخر دهه ۱۹۷۰ یک بررسی گسترده و معروف طی یک مطالعه توسط Lientz و Swanson انجام شد که در آن از سهم زیاد هزینه های تعمیر و نگهداری در هزینه های چرخه حیات یک نرم افزار پرده برداشته شد. آن ها فعالیت های تعمیر و نگهداری را به چهار کلاس طبقه بندی کردند: این بررسی نشان داد که حدود ۷۵٪ از فعالیت های تعمیر و نگهداری صرف دو نوع اول شد و اصلاح خطاها حدود ۲۱٪ از فعالیت های مربوط به تعمیر و نگهداری را به خود اختصاص داد. بسیاری از مطالعات بعدی نتایج مشابهی را نشان می دهند. مطالعات نشان می دهد که مشارکت کاربر نهایی بسیار مهم است و در جمع آوری داده ها و نیازمندی های جدید و تجزیه و تحلیل آن ها
نقش مهمی ایفا می کند، و این علت اصلی هر گونه مشکل در تکامل و تعمیر و نگهداری نرم افزار است؛ بنابراین تعمیر و نگهداری نرم افزار مهم است چرا که بخش بزرگی از کل هزینه های چرخه حیات نرم افزار را به خود اختصاص می دهد و همچنین عدم توانایی در ایجاد تغییر در نرم افزار با سرعت و قابلیت اعتماد مناسب به این معنی است که فرصت های کسب و کار از دست می روند. اهمیت تعمیر و نگهداری نرم افزار. کلید نگهداری نرم افزار توجه به مسائل مربوط به هر دو زمینه مدیریتی و فنی است. کلید مدیریت مسائل عبارتند از: هم ترازی و همراهی با مشتری، ایجاد اولویت هایی برای نیروی انسانی، برآورد صحیح هزینه ها. کلید حل مسائل فنی عبارتند از: برطرف کردن محدود درک، تأثیر، تحلیل، تست، نگهداری و اندازه گیری. تعمیر و نگهداری نرم افزار فعالیت بسیار گسترده ای است که شامل تصحیح خطا و پیشرفت قابلیت های نرم افزار و بهینه سازی آن است. از آنجایی که تغییر اجتناب ناپذیر است، مکانیسم های مورد استفاده باید امکان ارزیابی و کنترل و ایجاد تغییرات را داشته باشند. بنابراین هر کاری که به منظور تغییر نرم افزار انجام می شود بخشی از عملیات تعمیر و نگهداری نرم افزار در نظر گرفته م
ی شود و هدف آن حفظ ارزش نرم افزار در طول زمان می باشد. ارزش نرم افزار را می توان با گسترش پایه مشتری (Customer Base) آن افزایش داد و این امر نیازمند تبدیل شدن نرم افزار به حالتی است که برای استفاده کارآمدتر باشد و فناوری های جدید در آن به کار گرفته شوند. تعمیر و نگهداری ممکن است در طول ۲۰ سال رخ دهد در حالی که توسعه ممکن است مجموعاً ۱–۲ سال طول بکشد. برنامه ریزی تعمیر و نگهداری نرم افزار. بخشی جدایی ناپذیر از نرم افزارها تعمیر و نگهداری آنهاست که نیازمند تهیه برنامه ای دقیق برای تعمیر و نگهداری آن در طول فرایند توسعه نرم افزار است. باید مشخص کنید که چگونه به درخواست های تغییر یا گزارش مشکلات کاربران پاسخ خواهید داد. بودجه فعالیت ها باید شامل تخمینی از منابع مورد نیاز و هزینه های آتی باشد تا دچار مشکل نشویم. تعمیر و نگهداری نرم افزار که می تواند برای ۵–۶ سال (یا حتی دهه ها پس از فرایند توسعه نرم افزار) ادامه داشته باشد نیازمند یک طرح مؤثر است که بتواند دامنه کاری نرم افزار را تعیین کند و زمینه را برای ارائه برآوردی از هزینه های چرخه زندگی نرم افزار فراهم کند. انتخاب استانداردهای مناسب جهت به چالش کشیدن اقدامات
بعدی روی نرم افزار از مرحله اولیه مهندسی نرم افزار است که از دید سهامداران نگران دارای اهمیت بسزایی است. فرایندهای تعمیر و نگهداری نرم افزار. این بخش توصیف شش گام فرایند تعمیر و نگهداری نرم افزار را عنوان می کند: عوامل تعمیر و نگهداری. تأثیر عوامل مؤثر کلیدی بر نگهداری (طبقه بندی شده به ترتیب حداکثر تأثیر مثبت به پایین) نه تنها ماژول های مستعد خطا آزاردهنده و مشکل ساز هستند بلکه بسیاری از دیگر عوامل نیز می توانند موجب تنزل عملکرد بیش از پیش سیستم نیز بشوند. برای مثال "اسپاگتی کد" یک تکه کد بسیار پیچیده است که نگهداری مطمئن و ایمن آن کاملاً دشوار است. یک پیش آمد بسیار معمول است که اغلب تنزل های عملکردی سیستم ناشی از عدم استفاده از ابزارهای نگهداری مناسب است همانند ابزارهای ردیابی نقص، ردیابی تغییر نرم افزار، نرم افزار مدیریت و تست نرم افزار. باید برای استفاده از این ابزارها اهتمام نمود.
توسعهٔ آزمون محور (به انگلیسی: Test-driven development) یک فرایند توسعهٔ نرم افزاری است که بر پایه تکرار یک سری دوره های خیلی کوتاه توسعه قرار دارد: ابتدا برنامه نویس یک مورد آزمایشی (در ابتدا دارای شکست) برای بهبود مطلوب یا ایجاد قابلیت جدید می نویسد، سپس کمترین مقدار تغییرات کدی را که باعث قبول شدن آزمایش می شود می نویسد، سپس کد جدید را با استانداردهای قابل قبول سازماندهی مجدد می کند. یک مهندس نرم افزار آمریکایی به نام کنت بک، که توسعه یا «بازکشف» این روش را به وی نسبت می دهند، در سال ۲۰۰۳ اظهار داشت که TDD طرح های ساده و الهام بخش اعتماد به نفس را تشویق می کند. Test-driven development مربوط به مفاهیم آزمون-برای اولین بار (test-first programming concepts) برنامه نویسی و شدید برنامه نویسی (extreme programming) است که در سال ۱۹۹۹ مطرح شد اما اخیراً علاقه بیشتری را نسبت به خود ایجاد کرده است. برنامه نویسان همین طور می توانند این مفهوم را برای بهبود و اشکال زدایی کد میراث تهیه شده با روش های قدیمی تر به کار گیرند. در این روش، نرم افزار به صورت تدریجی توسعه می یابد. ابتدا تست ها و سناریوهای آزمونی تعریف می شوند
که بر اساس نیازمندی ها و اهداف مشتریان تعیین می شوند. سپس، با نوشتن کدی ساده که تست ها را برآورده کند، پروسه توسعه آغاز می شود. در این مرحله، کد نوشته شده تنها کافیست تا تست ها با موفقیت اجرا شوند و همچنین ممکن است کد اولیه به صورت موقتی باشد. سپس، با ادغام قطعات کد جدید و با تضمین عبور تست ها، کد قابل اجرا و نهایی تولید می شود. این روند تکرار می شود تا نرم افزار به صورت کامل و با تمامی ویژگی ها و تست ها توسعه یابد. استفاده از توسعه مبتنی بر آزمون برای بهبود کیفیت و قابلیت اطمینان نرم افزارها و افزایش سرعت توسعه بهره مندی های قابل توجهی دارد. مطالعات و پژوهش های انجام شده نشان می دهند که استفاده از توسعه مبتنی بر آزمون منجر به کاهش خطاها، اشکالات و باگ های نرم افزار، افزایش کیفیت و عملکرد آن، کاهش هزینه های ناشی از خطاها و تست های دستی و افزایش رضایت کاربران می شود. یکی از مزیت های توسعه مبتنی بر آزمون، امکان شناسایی و رفع مشکلات نرم افزار در مراحل ابتدایی توسعه است. با تعریف تست ها و سناریوهای آزمون، احتمال وقوع خطاها و نقص ها در نرم افزار کاهش می یابد و توسعه دهندگان قادر به شناسایی و رفع این مشکلات در مراح
ل زودهنگام هستند. این امر باعث می شود که هزینه و زمان موردنیاز برای تصحیح خطاها در مراحل بعدی توسعه کاهش یابد و در نتیجه نرم افزار با کیفیت تر و پایدارتری تحویل داده شود. همچنین، توسعه مبتنی بر آزمون به توسعه دهندگان امکان می دهد تا روند توسعه را بهبود دهند و تغییرات در نرم افزار را با اطمینان و کاهش احتمال وقوع خطاها اعمال کنند. با اجرای تست ها در هر مرحله از توسعه، تأیید می شود که تغییرات و بهبودهای اعمال شده در نرم افزار به عنوان انتظاری که دارند عمل می کنند و هیچ اثر غیرمنتظره ای در سایر قسمت های نرم افزار ایجاد نمی شود. با توجه به مزایای مذکور و مطالعات انجام شده در زمینه توسعه مبتنی بر آزمون، این روش به عنوان یک روش مؤثر در توسعه نرم افزار، با توجه به شواهد علمی و مزایای آن، بسیار مورد توجه قرار گرفته است. چرخه توسعه آزمون محور. چرخه توسعه آزمون محور یک فرایند توسعه نرم افزار است که متکی بر تکرار یک چرخه توسعه بسیار کوتاه است که طی آن نیازمندی ها تبدیل به موارد آزمون بسیار خاص می شوند و سپس نرم افزار به قدری بهبود بخشیده می شود که فقط بتواند تست های مطرح شده را پاس کند. این روند مخالف نحوه توسعه سنتی نر
م افزار است که اجازه می دهد تا بخش هایی به نرم افزار اضافه شود که هنوز تست های لازم را نگذرانده است و سپس آن بخش های جدید را تست می کند. توسعه آزمون محور، بر مبنای نوشتن آزمون (Test) برای نرم افزار بر اساس نیازمندی ها (requirements) قبل از نوشتن برنامه شکل گرفته است. در این فرایند هدف توسعه دهنده معطوف به گذراندن این تست ها می شود. ابتدا چون برنامه خالی است، تمامی آزمون ها باید با عدم موفقیت رو به رو شوند، اما برنامه نویس گام به گام برای هر ویژگی (feature) این آزمون ها را پشت سر می گذارد که اگر در هر مرحله موفقیت آمیز نبود، بازمی گردد و کد را دیباگ می کند. البته باید توجه داشت که در متدولوژی TDD علاوه بر آزمون های گام به گام نیازمند آزمون های موازی مستقل نیز هستیم. چرخه کلی روش توسعه آزمون محور شامل گام هایی به ترتیب زیر است که بر اساس کتاب "Test-Driven Development by Example" نوشته شده است: ۱. یک تست جدید بنویس. در روش توسعه آزمون محور هر ویژگی جدید با افزودن یک تست شروع می شود. طبیعی است این تست باید طوری طراحی شود که تنها با افزوده شدن صحیح و کامل ویژگی جدید مطلوب پاس شود. ۲. تمام تست ها را اجرا کن و ببین
آیا تست جدید پاس می شود یا خیر. در این مرحله قصد داریم مطمئن شویم تست جدیدی که افزودیم خطا بدهد، وگرنه با افزودن کد جدید امکان اینکه چک شود ویژگی جدید واقعاً به درستی افزوده شده است یا خیر وجود نخواهد داشت. ۳. کد را بنویس. در این گام تنها کد اضافه ای که نیاز هست تا تست جدید پاس شود را می نویسیم و به زیاده روی در توسعه نمی پردازیم. ۴. مجدداً تست ها را اجرا کن. این بار اگر تمام تست ها پاس شوند مطمئن می شویم که تمام ویژگی های قبلی به درستی کار می کنند و علاوه بر آن ویژگی جدید نیز به طور صحیح اضافه شده است. ۵. کد را Refactor کن. روشن است که کد کل برنامه باید هر چند وقت یک بار تمیز و مرتب شود تا از ایجاد کد کثیف اجتناب شود و امکان بهبود مناسب و سریع در آینده فراهم باشد. در این گام قصد داریم دقیقاً همین کار را انجام دهیم. در این گام به طور ویژه لازم است به ملاحظات توسعه همانند رعایت وراثت و خوانایی و امکان نگهداری مناسب کد و الگوهای طراحی برنامه توجه داشته باشیم. ۶. گام های ۱ الی ۵ را (برای هر ویژگی جدید که اضافه می کنی) تکرار کن. برای هر ویژگی جدید گام های فوق را تکرار می کنیم. اصول کلیدی توسعه آزمون محور. TDD که
در بین برنامه نویسان به دلیل توانایی خود در افزایش بهره وری، کیفیت نرم افزار و قابلیت نگهداری شهرت دارد، بر سه اصل اساسی بنا شده است. این اصول شامل مفاهیم Test-First، توسعه incremental و تست مکرر است. روش Test-First: در TDD، تست ها نقشی محوری در سراسر فرایند توسعه دارند. آن ها به عنوان ناوبر عمل می کنند و کل سفر را هدایت می کنند. هر چرخه توسعه با ایجاد یک تست که عملکرد مورد نظر را تعریف می کند، آغاز می شود. TDD از چارچوب های تست خودکار استفاده می کند و آزمایش را در هر زمان معین تسهیل می کند. این امکان بازخورد دقیق و سریع در مورد رفتار برنامه را فراهم می کند. توسعه incremental: با پذیرش توسعه incremental، پروژه ها به طور طبیعی به اجزای کوچک تر و قابل مدیریت تر تقسیم می شوند. این رویکرد تمرکز برنامه نویس را بر روی مشکل در دست، افزایش می دهد و در عین حال فرصت هایی را برای برنامه ریزی بهتر و توسعه برتر فراهم می کند. تست مکرر: تست مکرر بازخورد ارزشمندی را در رابطه با نیازمندی های اجرا شده به برنامه نویسان ارائه می دهد. این به تشخیص زودهنگام عیوب کمک می کند و احتمال انتشار آن ها را کاهش می دهد. در نهایت، این مورد،
منجر به افزایش سطح کیفیت و بهره وری می شود. TDD با دریافت بازخورد سریع از طریق تست، به نوشتن کد تمیز برای پیاده سازی یک نیازمندی کمک می کند. برای توسعهٔ مبتنی بر آزمون دو قانون تعریف شده است: ۱- همیشه فقط در صورت شکست یک تست، برای آن کد بنویسید: این قانون بر اهمیت نوشتن یک تست شکست خورده قبل از پیاده سازی هر عملکرد جدید یا ایجاد تغییرات در کد موجود تأکید می کند. ایده این است که با ایجاد یک مورد آزمون (test case) شروع کنید که رفتار یا ویژگی مورد نظری که می خواهید پیاده سازی کنید را تعریف می کند. از آن جایی که شما هنوز هیچ کدی ننوشته اید، تست با شکست مواجه خواهد شد. این موضوع، تضمین می کند که شما یک هدف مشخص و دقیق برای پیاده سازی دارید. با پیروی از این قانون، یک حلقه بازخورد ایجاد می کنید که در آن به طور مداوم تلاش می کنید تا با نوشتن حداقل مقدار کد لازم، تست شکست خورده را پاس کنید. پس از گذراندن تست، می توانید به مورد آزمون بعدی بروید یا کد خود را با اطمینان خاطر بازآرایی کنید و بدانید که هیچ مشکل جانبی ناخواسته ای برای خود ایجاد نکرده اید. ۲- همیشه تکراری را حذف کنید: این قانون توسعه دهندگان را تشویق می کند
تا هر گونه افزونگی یا تکرار را در پایگاه کد خود حذف کنند. هنگامی که متوجه الگوهای تکراری یا منطق مشابه در تست ها یا کد تولیدی خود می شوید، استخراج و انتزاع آن ها به اجزا یا توابع reusable، مهم است. تکرار در کد می تواند منجر به مشکلات متعددی شود، مانند افزایش تلاش برای حفاظت و نگهداری، احتمال بیش تر وجود خطاها و کاهش خوانایی کد. با حذف موارد تکراری، طراحی و ساختار کلی پایگاه کد خود را بهبود می بخشید و آن را قابل نگهداری، خواناتر و مستعد به خطای کم تری می کنید. اعمال این قانون نه تنها به حذف تکرار در یک تست یا فایل کد، بلکه به شناسایی الگوهای رایج در چندین تست یا ماژول نیز گسترش می یابد. این دو قانون با هم کار می کنند تا فرایند توسعه را در TDD هدایت کنند. با تمرکز بر نوشتن تست های شکست خورده، ابتدا مطمئن می شوید که کد شما نیازمندی های مورد نظر را برآورده می کند. به طور هم زمان، با حذف تکراری ها، پایگاه کد خود را قابل مدیریت تر و قابل درک تر می کنید که منجر به توسعهٔ بهتر می شود. با توجه به این دو قانون، توسعهٔ مبتنی بر آزمون را می توان به عنوان یک مدل توسعهٔ iterative تعریف کرد که در آن برنامه نویس موارد آزمون
را قبل از نوشتن کد با استفاده از نیازمندی ها استخراج می کند. سپس کدی برای افزایش عملکردی کوچک نوشته می شود تا در تست پاس شود و در صورت شکست تست، کد می تواند به طور مکرر برای افزایش کیفیت و طراحی مجدداً تغییر داده شود. مزایای توسعه آزمون محور. یک مطالعه در سال ۲۰۰۵ به این نتیجه رسید که استفاده از روش توسعه آزمون محور به معنی نوشتن تعداد بیشتری تست هست و برنامه نویسانی که تعداد بیشتری تست می نویسند (برخلاف تصور عموم) بازدهی بیشتری دارند. همین طور برنامه نویسانی که از روش توسعه آزمون محور بهره می بردند گزارش کردند که به تعداد دفعات کمتری نیاز به استفاده از Debugger در کار خود داشتند، که این امر به نوبه خود موجب بهبود و افزایش بهره وری آنها می شود. چنین کاهشی در تعداد دفعات نیاز به استفاده از Debugger طبیعی به نظر می رسد، چرا که هر گام از توسعه و هر ویژگی جدیدی که به برنامه افزوده می شود خود همراه با تست در محل می باشد و تا زمانی که تست مربوطه و تمام تست های پیشین برنامه پاس نشوند به مرحله بعد نمی رویم. همین طور گزارش شده است که در روش توسعه آزمون محور هرگاه به خطایی برخورد کنیم معمولاً بازگشت به آخرین نسخه بدون
خطا و شروع مجدد کار بهینه تر از استفاده از Debugger است که این امر عملاً نیاز به دیباگ کردن کد و هزینه های مالی و زمانی نگهداری و تعمیر کد را کاهش می دهد. از ویژگی ها و مزیت های دیگر این متدولوژی می توان موارد زیر را نام برد: ۱. بررسی کامل تر در ابتدا. این فرایند باعث می شود قبل از نوشتن برنامه، به جنبه های مختلف نیازمندی ها فکر کنیم و مواردی که روش های موجود می توانند شکست بخورند را بررسی کرده و در داخل آزمون ها در نظر بگیریم. ۲. متمرکز کردن اهداف. برنامه نویس هدف خود را با داشتن آزمون ها به روشنی می داند و می توانند صرفاً با تمرکز بر روی همین آزمون ها، از یک هدف و نیازمندی مبهم خود را دور کند. ۳. کاهش هزینه ها در نهایت. ممکن است TDD در ابتدا پرهزینه به نظر بیاید، اما به دلیل این که فرایند آزمون مرحله به مرحله و برای بخش های مختلف برنامه و بر اساس نیازمندی های مورد نیاز است، احتمال وارد شدن هزینه سنگینی که به خاطر عدم تطابق برنامه با نیازها پرداخت خواهد شد کاهش میابد ۴. توسعه گام به گام. در بسیاری از موارد پیش آماده که برنامه را کامل نوشتیم و بعد به آزمون آن پرداختیم و به اشکالی برخوردیم، ولی چون از سر منشأ
مشکلات به صورت دقیق آگاه نبودیم، نتوانستیم آن ها را رفع کنیم. توسعه آزمون محور این مسئله را نیز برای ما برطرف می کند. ۵. مستندسازی. اگر از عملکرد تابعی در برنامه اطمینان نداشته باشیم، می توانیم با بررسی آزمون مربوط به آن تابع و پاسخ مد نظر، شهودی از رفتار مورد انتظار آن تابع داشته باشیم. ۶. کدهای مرتب تر. با توجه به این که از رفتار تابع ها به صورت مجزا می توان اطمینان یافت، می توان refactoring را به صورت آنی تری انجام داد، همچنین سطح های دسترسی توابع (خصوصی و عمومی) را پس از اطمینان از صحت درستی به صورت درجا مشخص کنیم و مجبور نشویم برای تست یک تابع در توابع دیگر این سطح دسترسی ها را تغییر دهیم. استفاده از TDD منجر به نوشتن کدی می شود که تضمین می کند که هر بخش از کد، انجام وظایف خود را با دقت و صحت بالا انجام می دهد. این روش کمک شایانی می کند تا با اعتماد بیشتر به کدی که نوشته شده است، بتوانید آن را بهبود دهید. مخصوصاً از آن جا که شما در ابتدا کدی می نویسید که تست را پاس کند و سپس آن را refactor می کنید، مطمئن خواهید بود که کد شما شامل قسمت هایی که اضافه باشند و نیاز نشوند، نمی باشد و همچنین کد شما بهینه و مرت
ب و منطبق بر اصول clean code می باشد. ۷. کاهش هزینهٔ زمانی رفع مشکلات کد و دیباگ کردن آسان تر. با استفاده از TDD از آن جا که از مراحل ابتدایی تست ها نوشته می شوند، خطاها در مراحل بسیار زودتری شناخته می شوند و در مراحل زودتری معمولاً حل می شوند. این کار باعث می شود که نیاز به صرف زمان و هزینه برای رفع خطاهای بزرگ در مراحل بعدی کاهش می یابد. این به معنی صرفه جویی در زمان و منابع می باشد و سرعت توسعهٔ محصول نیز در این حالات نسبت به حالت عادی که زمان زیادی را برای دیباگ کردن صرف می کنیم به طور قابل توجهی بیشتر می شود. ۸. Test Coverage بالا و تضمین بیشتر از نرم افزار. با استفاده از TDD از آن جا که برای هر فیچری شما تست دارید، پس درصد بخشی از کد که به وسیلهٔ تست ها پوشش داده می شوند و تست می شوند بیشتر از سایر متودولوژی ها می باشد. همچنین از آن جا که برنامهٔ ما با unit testهای مختلف یا به طور کلی آزمون های مختلفی سنجیده می شود، می توانیم اطمینان خوبی از عملکرد آن داشته باشیم. محدودیت ها و معایب توسعهٔ تست محور. ۱. ناتوانی در استفادهٔ عملی. در شرایط پذیرش و استفاده در صنعت، موانع فنی زیادی در هنگام پیاده سازی وجود د
ارد علاوه بر این که درک کامل این که چگونه باید آن را به کار گرفت، مشکل است و برداشت های متفاوتی از آن میان افراد مختلف وجود دارد؛ بنابراین، استفاده عملی از آن بسیار کم است که می توان آن را به عنوان یکی از معایب TDD دید. طبق بررسی ها تنها ۱۲ درصد از TDD به روش صحیح استفاده می کنند. احتمالاً با دستورعمل هایی که نحوهٔ درست پیاده سازی را پیشنهاد می دهند و افزایش دانش صنعت، بتوان این مورد را کمی بهبود بخشید. ۲. سرعت توسعه. TDD ممکن است باعث کاهش سرعت توسعهٔ کد شود. طراحی و نوشتن تست ها به تنهایی زمان بر است و ممکن است در ابتدا توسعهٔ کد و پیشروی را به طور قابل توجهی کندتر کند. علاوه بر این، این روش نیازمند تجربه و آموزش زیادی می باشد تا بهره وری بالایی از آن به دست آید. به همین دلیل، توسعه دهندگان جدید ممکن است برای استفاده از TDD نیاز به یادگیری و تسلط بیشتری داشته باشند. ۳. پیچیدگی بیشتر در فرایند توسعه و افزایش هزینه در برخی موارد. یکی دیگر از معایب TDD، ایجاد پیچیدگی در فرایند توسعه است. این روش نیازمند توجه و هماهنگی بیشتری در نوشتن تست ها، پیاده سازی کدها و اجرای تست ها است. همچنین، برای توسعه دهندگانی که به
سیستم وارد می شوند، ممکن است برای درک کامل فرایند نیاز به زمان و تلاش و توجه بیشتری داشته باشند. این می تواند باعث کاهش کارایی و افزایش هزینه توسعه شود. مقایسهٔ توسعهٔ مبتنی بر آزمون با دیگر متدولوژی ها. در این بخش، توسعه مبتنی بر آزمون را با روش های سنتی مانند توسعه مبتنی بر نیازمندی ها (Requirement-driven Development) و توسعه مبتنی بر مستندات (Documentation-driven Development) مقایسه می کنیم. در توسعه مبتنی بر نیازمندی ها، نرم افزار بر اساس نیازمندی های کاربران و مشتری ها فنی توسعه می یابد. در این روش، ابتدا نیازمندی ها تعریف می شوند و سپس کد نوشته می شود تا نیازمندی ها را برآورده کند. تست ها و آزمون ها نیز پس از نوشتن کد، اجرا می شوند. این رویکرد ممکن است باعث ایجاد تست های ناکارآمد و کاهش کیفیت نرم افزار شود. در مقابل، توسعه مبتنی بر آزمون با تعریف تست ها در مرحله ابتدایی توسعه، از کاهش خطاها و بهبود کیفیت و قابلیت اطمینان نرم افزار بهره می برد. در توسعه مبتنی بر مستندات، نرم افزار بر اساس مستندات و مشخصات فنی توسعه می یابد. در این روش، مستندات تهیه می شوند و بر اساس آن ها نرم افزار پیاده سازی می شود. تس
ت ها و آزمون ها نیز بعد از نوشتن کد، اجرا می شوند. اما ممکن است در این رویکرد، تست ها برای بررسی جوانب های مختلف نرم افزار کافی نباشند و خطاهای مختلفی در فرایند توسعه رخ دهد. در مقابل، توسعه مبتنی بر آزمون با تعریف تست ها و سناریوهای آزمون کاملتر، تمام جوانب و قابلیت های نرم افزار را بررسی کرده و از کیفیت و عملکرد صحیح نرم افزار اطمینان حاصل می کند. مطالعات نشان داده اند که استفاده از توسعه مبتنی بر آزمون منجر به کاهش خطاها، اشکالات و باگ های نرم افزار، افزایش کیفیت و عملکرد آن، کاهش هزینه های ناشی از خطاها و تست های دستی و افزایش رضایت کاربران می شود. در واقع، توسعه مبتنی بر آزمون با استفاده از رویکرد طراحی آزمون اول و پیاده سازی کد بر اساس آزمون ها، موجب تضمین عملکرد صحیح و قابل اعتماد نرم افزار و کاهش خطاها می شود. با توجه به مزایای مذکور و مطالعات انجام شده در زمینه توسعه مبتنی بر آزمون، این روش به عنوان یک روش مؤثر در توسعه نرم افزار، با روش های سنتی مانند توسعه مبتنی بر نیازمندی ها و مستندات قابل مقایسه است و بهبود قابل توجهی در کیفیت و عملکرد نرم افزارها را به همراه دارد. فریم ورک های توسعهٔ مبتنی بر آ
زمون. در این بخش قصد داریم چند نمونه از فریم ورک هایی که برای توسعهٔ مبتنی بر آزمون وجود دارد را معرفی کنیم. برای زبان های برنامه نویسی مختلف که هر کدام ویژگی های خاص خود را دارند، فریم ورک های مختلفی وجود دارد که در این بخش به بررسی تعدادی از محبوب ترین آن ها می پردازیم: PyUnit: یک ابزار استاندارد آزمون واحد پروژه های پایتون است که توسط کنت بک و اریک اما طراحی شده است. در پکیج های پایتون با نام unittest می توان از این ابزار استفاده کرد. PyUnit از موارد آزمون و ابزار اجرای تست (test runners) پشتیبانی می کند. در PyUnit شما می توانید موارد آزمون را طوری سازماندهی کنید که رشته های تعدادی از آن ها با ویژگی های یکسان اجرا شوند. TestNG: یک فریم ورک محبوب تست برای زبان برنامه نویسی جاوا است که به کاربران اجازهٔ اجرای آزمون های خودکار برای اپلیکیشن های وب را می دهد. این فریمورک متن باز است و قابلیت های بیش تری نسبت به JUnit دارد که باعث افزایش محبوبیت آن در برنامه نویسان زبان جاوا شده است. هم چنین می توان با استفاده از این فریم ورک به همراه Selenium که یک ابزار برای مرور خودکار صفحات وب است، تست های خودکار قدرتمندی ب
رای اپلیکیشن های وب ایجاد کرد. Rspec: یک فریم ورک انجام آزمون برای زبان برنامه نویسی ruby است. کارهای آزمون محور. روش آزمون محور در خارج از حیطه توسعه نرم افزار نیز به کار گرفته شده است. این روش تحت عنوان کار آزمون محور در تیم های تولیدی و خدماتی مورد استفاده قرار گرفته است. در کار آزمون محور همانند توسعه نرم افزار آزمون محور، تیم ها تعداد آزمون کنترل کیفیت برای هر جنبه از موضوع کار طراحی می کنند و سپس به ارزیابی آن و طراحی جهت ارضای آن می پردازند تا موفق شوند آن را پاس کنند. شش گام ذکر شده در توسعه نرم افزار آزمون محور با تغییراتی جزئی به شکل زیر برای کار آزمون محور نیز به کار گرفته می شوند: روش های برتر در توسعهٔ مبتنی بر آزمون. در این قسمت تعدادی از روش های برتر (best practices) توسعهٔ مبتنی بر آزمون را بررسی می کنیم: فهم واضح نیازمندی ها هنگام شروع: برای شروع، فهم دقیق و واضحی از نیازمندی های ویژگی ای که قصد توسعهٔ آن را دارید به دست آورید. این کار به شما کمک می کند تا تست های متمرکز و مرتبط بنویسید. نوشتن تست های ریز: هر تست باید روی یک رفتار یا کارایی مشخص تمرکز کند. تست های خود را کوتاه و متمرکز و تنها