Software Engineer Labdon
616 subscribers
43 photos
4 videos
2 files
786 links
👑 Software Labdon

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

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
Finally: Unit Testing for LLMs That Doesn't Require a PhD or $100K Budget

🟢 خلاصه مقاله:
** دکتر Ernesto Lee نشان می‌دهد برای ساخت اپلیکیشن‌های مبتنی بر LLM لازم نیست PhD یا بودجه‌های بسیار بزرگ داشته باشید تا تست خودکار جدی و مؤثر پیاده کنید. ایده اصلی این است که هر prompt، chain و فراخوانی ابزار را مثل یک واحد مستقل با مشخصات روشن ببینید و برای آن‌ها تست بنویسید: از اعتبارسنجی ساختار خروجی (مثلاً JSON Schema) و الزامات فیلدها، تا چک‌های ایمنی/سیاست و نمونه‌های طلایی دامنه‌ای. با snapshot test، داده‌های نمونه کم‌حجم اما پوشش‌دهنده لبه‌ها، و mock/stub برای وابستگی‌های خارجی، تست‌ها سریع، ارزان و قابل تکرار می‌مانند.

برای کنترل هزینه و نوسان، می‌توان پاسخ‌ها را cache کرد، بیشتر تست‌ها را با temperature=0 اجرا نمود، محدودیت توکن گذاشت، و مجموعه تست‌های «سریع» را از ارزیابی‌های «سنگین‌تر» دوره‌ای جدا کرد. نسخه‌دهی به promptها و داده‌های طلایی، گزارش‌کردن معیارها و اتصال این چرخه به CI باعث می‌شود هر تغییر کد یا prompt فوراً ارزیابی شود و رگرسیون‌ها دیده شوند. در صورت شکست تست، سریع مشخص کنید مشکل از تغییر prompt است، drift مدل بالادستی یا وابستگی ابزار، و همان یادگیری را به تست‌ها برگردانید.

نتیجه این رویکرد، چرخه توسعه سریع‌تر با اطمینان بیشتر و هزینه کنترل‌شده است. پیام Lee روشن است: Unit Testing عملی و مقیاس‌پذیر برای LLMها در دسترس همه تیم‌هاست، نه فقط تیم‌های بزرگ.

#LLM
#UnitTesting
#AIEngineering
#TestingAutomation
#MLOps
#PromptEngineering
#ContinuousIntegration
#QualityAssurance

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


👑 @software_Labdon
2
🔵 عنوان مقاله
How We Utilize AI Agents in Our Testing and Quality Processes

🟢 خلاصه مقاله:
این مقاله با روایت Utku Kılınçcı چهار کاربرد عملی از به‌کارگیری AI agents در تست و تضمین کیفیت را توضیح می‌دهد: ۱) تبدیل نیازمندی‌ها به تست‌های قابل اجرا و به‌روزرسانی مداوم سبد تست با تغییرات مشخصات، ۲) نقش همکار اکتشافی برای کشف سناریوهای مرزی، ثبت شواهد و بازتولید مشکل، ۳) تحلیل و اولویت‌بندی باگ‌ها از طریق خلاصه‌سازی لاگ‌ها، خوشه‌بندی خطاها و ارائه سرنخ‌های ریشه‌یابی، و ۴) بهبود پایداری رگرسیون و درگاه‌های کیفی CI با شناسایی تست‌های flaky، پیشنهاد خوددرمانی و بهینه‌سازی پایپ‌لاین. در همه موارد، نظارت انسانی، رعایت حریم داده و سنجش نتایج (پوشش، MTTR، روند flakiness و زمان چرخه) ضروری است. نتیجه: پذیرش تدریجی AI agents روی مسائل واقعی، سرعت، پایداری و پوشش تست را به‌طور ملموس افزایش می‌دهد بی‌آنکه مالکیت کیفیت را تضعیف کند.

#SoftwareTesting #AIagents #QualityAssurance #TestAutomation #BugTriage #ContinuousIntegration #SoftwareQuality #DevOps

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


👑 @software_Labdon
🔵 عنوان مقاله
It's Not Your Tests, It's Your Testability

🟢 خلاصه مقاله:
**
بی‌ثباتی تست‌ها همیشه تقصیر تست‌ها نیست؛ اغلب ریشه در سیستم کم‌تست‌پذیر دارد. وقتی زمان، هم‌روندی، تصادفی‌بودن یا وابستگی‌های بیرونی کنترل‌نشده باشند، تست‌ها ناپایدار می‌شوند. راه‌حل، ارتقای تست‌پذیری است: قابل‌کنترل و قابل‌مشاهده کردن سیستم، تزریق زمان و بذر تصادفی، جداسازی مرزهای شبکه با قراردادها و فیک‌ها، و هرمتیک‌کردن محیط تست. Gil Zilberfeld توصیه می‌کند برای جلب حمایت، هزینه فلیکینس را با داده نشان دهید و از بردهای کوچک (مثل افزودن seam، تزریق وابستگی برای زمان/I-O، و تست‌های قراردادی) شروع کنید. با گنجاندن تست‌پذیری در تصمیم‌های معماری و معیارهای پذیرش، تیم از آتش‌نشانی تست‌های flaky به ساخت نرم‌افزار ذاتاً تست‌پذیر و قابل‌اتکا منتقل می‌شود.

#Testability #FlakyTests #SoftwareTesting #QualityEngineering #DevOps #ContinuousIntegration #TestDesign #Observability

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


👑 @software_Labdon
🔵 عنوان مقاله
Running Lighthouse CI in a Lightweight Docker Container

🟢 خلاصه مقاله:
**این مطلب نشان می‌دهد چگونه می‌توان Lighthouse CI را در یک Docker کانتینر سبک اجرا کرد تا سنجش عملکرد وب‌اپ‌ها به‌صورت خودکار و قابل‌اتکا در CI انجام شود. ایده اصلی، ساخت یک ایمیج کوچک (مثلاً بر پایه Alpine + Node) با CLI مربوط به Lighthouse CI و یک Chromium هدلس است تا روی GitHub Actions، GitLab CI، یا CircleCI کاملاً یکسان عمل کند و زمان راه‌اندازی و هزینه‌های CI را پایین نگه دارد. در خط لوله، پس از build و serve کردن برنامه (یا هدف‌گیری یک URL مستقر)، کانتینر اجرا می‌شود، معیارهایی مانند LCP، CLS و TBT را استخراج می‌کند، گزارش‌های HTML/JSON تولید می‌کند، و با baseline و بودجه‌های عملکردی مقایسه می‌کند تا در صورت عقب‌گرد یا عبور از آستانه‌ها، build را fail کند. برای پایداری نتایج، باید شبکه و CPU را شبیه‌سازی (throttle) کرد، cacheها را بین اجراها نگه داشت، به‌صورت non-root اجرا شد و تنها در صورت نیاز از پرچم‌هایی مثل no-sandbox استفاده کرد. این چیدمان به‌راحتی در PRها برای gate کردن mergeها و نیز در اجرای شبانه روی محیط production قابل استفاده است و در نهایت یک سازوکار سبک، تکرارپذیر و کم‌هزینه برای کنترل دائمی عملکرد ارائه می‌دهد.

#Lighthouse #LighthouseCI #Docker #WebPerformance #CI #DevOps #PerformanceBudgets #ContinuousIntegration

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


👑 @software_Labdon