Software Engineer Labdon
637 subscribers
43 photos
4 videos
6 files
814 links
👑 Software Labdon

حمایت مالی:
https://www.coffeete.ir/mrbardia72

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
Architecture Tests

🟢 خلاصه مقاله:
** تاراس Kizlo در ادامهٔ مجموعهٔ خود دربارهٔ سطوح تست، سراغ موضوع کمتر مطرح‌شده‌ای رفته است: تست‌های معماری. او توضیح می‌دهد که این تست‌ها مجموعه‌ای از قواعد اجرایی‌اند که مرزهای معماری، وابستگی‌های مجاز، نبود حلقه‌های وابستگی و قواعد نام‌گذاری/لایه‌بندی را بررسی می‌کنند تا از فرسایش تدریجی طراحی جلوگیری شود. مقاله نشان می‌دهد چگونه می‌توان این قواعد را کنار تست‌های معمول و در CI/CD اجرا کرد و با ابزارهایی مثل ArchUnit یا NetArchTest آن‌ها را به شکست‌پذیر کردن بیلد گره زد. توصیه‌های عملی شامل شروع از چند قانون پرتأثیر، پرهیز از قواعد شکننده، همگام‌سازی با تصمیم‌های معماری و به‌روزرسانی مداوم تست‌هاست. نتیجهٔ نهایی: تست‌های معماری قصد طراحی را به قراردادهای قابل اجرا تبدیل می‌کنند و به‌عنوان گاردریل‌های ماندگار، ساختار سالم کد را حفظ می‌کنند.

#ArchitectureTests #SoftwareArchitecture #SoftwareTesting #CleanArchitecture #CI/CD #ArchUnit #NetArchTest #CodeQuality

🟣لینک مقاله:
https://cur.at/WG4foAM?m=web


👑 @software_Labdon
🔵 عنوان مقاله
Seriously Testing LLMs

🟢 خلاصه مقاله:
این مقاله به این می‌پردازد که برای آزمون جدی LLMs چه نیاز است. نویسنده با تکیه بر مجموعه‌ای از آزمایش‌ها، نشان می‌دهد چرا اتکا به دمو یا امتیازهای سطحی کافی نیست و چگونه رفتار مدل با تغییر متن راهنما، زمینه و زمان تغییر می‌کند. James Bach در این مسیر روش LARC را معرفی می‌کند؛ رویکردی ساخت‌یافته و اکتشافی برای برنامه‌ریزی، اجرای آزمون‌ها و تفسیر نتایج که بر طراحی موارد تنشی و خصمانه، مشاهده نظام‌مند و بهبود تکرارشونده تأکید دارد تا الگوهای خطا و محدودیت‌های قابلیت اعتماد آشکار شوند. مقاله توضیح می‌دهد که چرا آزمون جامع دشوار و پرهزینه است: خروجی‌های غیرقطعی، نبود داور قطعی برای «درستی»، حساسیت به Prompt و زمینه، به‌روزرسانی‌های مدل که بازتولیدپذیری را می‌شکنند، محدودیت معیارهای کمی، و نیاز به ابزار، داده، محاسبات و داوری انسانی. در نهایت پیشنهاد می‌شود آزمون LLM را یک کار تحقیقاتی-حرفه‌ای ببینیم: اهداف و ریسک‌ها را روشن کنیم، داده‌های متنوع و خصمانه بسازیم، ثبت و رهگیری کامل انجام دهیم، و با اجرای تکرارشونده روش LARC میان عمق و وسعت، خودکارسازی و قضاوت کارشناسی، و هزینه و کفایت تصمیم‌گیری کنیم.

#LLMs #SoftwareTesting #AIQuality #Evaluation #PromptEngineering #Reliability #JamesBach #MachineLearning

🟣لینک مقاله:
https://cur.at/OfLtyHW?m=web


👑 @software_Labdon
👍1
🔵 عنوان مقاله
AI in Testing: Hype or Real Progress?

🟢 خلاصه مقاله:
این یادداشت با نگاهی عمل‌گرایانه، دیدگاه Arik Aharoni را درباره نقش واقعی هوش مصنوعی در تست نرم‌افزار شرح می‌دهد: او نشان می‌دهد کجاها AI ارزش ملموس ایجاد کرده و کجاها همچنان اغراق می‌شود. به‌گفته او، AI در تولید اولیه تست‌ها از نیازمندی‌ها، پیشنهاد موارد مرزی، کاهش شکنندگی تست‌های UI، شناسایی تست‌های flaky، خوشه‌بندی خطاها، اولویت‌بندی ریسک‌محور و ساخت داده‌های آزمایشی مفید است؛ همچنین در بررسی‌های بصری و دسترس‌پذیری می‌تواند رگرسیون‌های ظریف را آشکار کند.

در مقابل، خطاهای مدل‌های زبانی، عدم درک عمیق دامنه، محدودیت‌های امنیت و حریم خصوصی، و دشواری ارزیابی کیفیت تست‌های تولیدی، مانع اعتماد کامل می‌شوند. «عامل‌های» خودمختار تست بدون نظارت انسانی هنوز پایدار نیستند و AI جایگزین طراحی آگاه از معماری، تحلیل ریسک و تأیید انسانی نمی‌شود.

جمع‌بندی Aharoni این است: پیشروی واقعی اما تدریجی است. با اجرای آزمایشی کوچک، معیارهای روشن (مانند نرخ کشف عیب و پایداری تست) و جریان‌های human-in-the-loop، می‌توان از AI در حوزه‌هایی با سیگنال قوی—مثل نگهداشت و تریاژ شکست‌ها—بهره برد؛ AI باید مکمل مهارت تیم‌های QA و مهندسی باشد، نه جایگزین آن.

#AIinTesting #SoftwareTesting #QA #TestAutomation #QualityEngineering #LLM #DevOps #TestStrategy

🟣لینک مقاله:
https://cur.at/6kIevSo?m=web


👑 @software_Labdon
🔵 عنوان مقاله
Epistemic Testing, Chapter 2 — Is that a Test or an Experiment?

🟢 خلاصه مقاله:
در ادامه‌ی یادداشت قبلی، Masoud Bahrami با رویکردی معرفت‌شناختی مرز میان «تست» و «آزمایش» را روشن می‌کند و می‌پرسد: هر بار که می‌گوییم در حال «تست» هستیم، واقعا تست می‌کنیم یا آزمایش؟ او توضیح می‌دهد که تست برای راستی‌آزمایی یک ادعا/الزام مشخص در شرایط کنترل‌شده با اوراکل و معیارهای پذیرش روشن و هدف کاهش سریعِ ریسک‌های شناخته‌شده به‌کار می‌رود؛ در حالی‌که آزمایش برای کشف مجهولات، شکل‌دهی/اصلاح فرضیه‌ها، تحمل ابهام و سنجش سیگنال‌ها از طریق تکرار و اندازه‌گیری طراحی می‌شود. فصل به کیفیت شواهد نیز می‌پردازد: تکرارپذیری، ابطال‌پذیری، دقت اندازه‌گیری و هزینه‌ی کسب اطلاعات. یک تست خوب شامل ادعا، شرایط، اوراکل و قاعده‌ی توقف است؛ یک آزمایش خوب فرضیه، متغیرها، طرح ابزار/اندازه‌گیری و معیار به‌روزرسانی باورها را صریح می‌کند. در هر دو، شفاف‌سازی مفروضات، سوگیری‌ها و تهدیدهای اعتبار ضروری است. راهنمای عملی فصل: پیش از اجرا بپرسید در پی تأیید هستیم یا کشف؛ فرضیه/ادعا چیست؛ چه چیزی شواهد معتبر محسوب می‌شود و کدام اوراکل/متریک به‌کار می‌رود؛ ریسک هدف کدام است؛ و معیار توقف/ادامه/تغییر مسیر چیست. پیام نهایی: با نام‌گذاری درست فعالیت و اتخاذ ذهنیت معرفت‌شناختی، «تست» و «آزمایش» را مکمل هم برای تصمیم‌گیری بهتر و یادگیری سریع‌تر به‌کار بگیرید.

#EpistemicTesting #SoftwareTesting #ExperimentVsTest #QualityAssurance #Evidence #Hypothesis #MasoudBahrami

🟣لینک مقاله:
https://cur.at/4sqUvVw?m=web


👑 @software_Labdon