تست تولید و تضمین کیفیت

سود:

• توانایی تولید تست واحد، موارد لبه و تجزیه و تحلیل شکاف پوشش با هوش مصنوعی
• امکان چاپ انتظارات تست بر اساس مشخصات، نه رفتار فعلی کد
• توانایی آزمایش اینکه آیا یک تست واقعاً با تزریق خطا محافظت می کند یا خیر

نوشتن تست یکی از کارهایی است که ارزش زیادی دارد و اکثر توسعه دهندگان آن را به تعویق می اندازند. یک مجموعه آزمایشی خوب گواه این است که کد مطابق انتظار کار می کند و راه نجاتی برای تغییرات آینده است. مشکل این است که نوشتن تست‌ها تکراری و زمان‌بر است – دقیقاً همان کاری که هوش مصنوعی در آن می‌درخشد. اما یک نکته وجود دارد: هوش مصنوعی اغلب رفتار موجود کد را آزمایش می کند، نه رفتاری که باید باشد. مدیریت این تفاوت ماهیت این واحد است.

در این بخش، تست واحد (آزمایشی که یک تابع را به تنهایی و به تنهایی آزمایش می‌کند)، تست‌های موردی لبه و تولید داده‌های تست با هوش مصنوعی را یاد خواهید گرفت. بستن شکاف در پوشش آزمون؛ و چرا اعتماد کورکورانه به تست های هوش مصنوعی خطرناک است.

دو طرف آزمایش: اصلاح رفتار در مقابل تأیید

یک آزمون می تواند دو هدف متفاوت را دنبال کند. اولین مورد تأیید است: درست بودن کد و مطابقت آن با مشخصات را آزمایش می کند. دوم حفاظت از رگرسیون است: امروز رفتار کد را مسدود می کند، بنابراین اگر فردی به طور تصادفی آن را فردا تغییر دهد، تست خراب می شود و به شما اطلاع می دهد.

هوش مصنوعی در مورد دوم بسیار خوب است. به کد نگاه می کند و مواردی را ایجاد می کند که "آنچه در حال حاضر انجام می دهد" را آزمایش می کند. اما اگر کد از همان ابتدا اشتباه باشد، هوش مصنوعی می‌تواند آن رفتار اشتباه را به عنوان «درست» پین کند. بنابراین باید ادعای هر تستی را که هوش مصنوعی تولید می‌کند مرور کنید: "کد 42 را برمی‌گرداند و تست انتظار 42 را دارد" به این معنی نیست که 42 پاسخ صحیح است.

احتیاط: اگر هوش مصنوعی آزمایش را پشت سر بگذارد، به این معنی نیست که کد "کار می کند"؛ این فقط به این معنی است که "آنطور که هوش مصنوعی انتظار دارد رفتار می کند". شما با نگاه کردن به مشخصات تصمیم می گیرید که آیا انتظار درست است یا خیر.

گام به گام: نوشتن تست های قوی با هوش مصنوعی

1. مشخصات را بدهید نه فقط کد را. اگر اطلاعات "این تابع باید این کار را انجام دهد" را اضافه کنید، هوش مصنوعی می تواند انتظارات صحیح را بنویسد. اگر فقط کد را ارائه کنید، رفتار فعلی را آزمایش می کند.
2. موارد لبه را بخواهید. خالی، تهی، صفر، منفی، بیش از حد بزرگ، قالب بد، همزمانی - به صراحت ادعای خارج شدن از مسیر خوشحال کننده را داشته باشید.
3. چارچوب و سبک تست را مشخص کنید. "استفاده از pytest"، "Arrange-Act-Assert pattern"، "اجازه دهید هر تست یک چیز را آزمایش کند" و غیره.
4. بررسی انتظارات (اظهار). با مشخصاتی که هر ادعای مقدار صحیح را بررسی می کند، مقایسه کنید.
5. شکاف های دامنه را ببندید. تست های موجود را بدهید و بپرسید "کدام شاخه ها و موارد تست نشده اند؟" شما را وادار می کند بپرسید سپس آزمایش های اضافی تولید شده را تأیید کنید.

سه کیف کوچک

مورد 1 - پوشش از 52٪ تا 85٪. پوشش آزمایشی یک ماژول سرویس 52٪ بود. تیم آزمایش‌های موجود را به هوش مصنوعی داده، شاخه‌های آزمایش‌نشده را فهرست کرده و آزمایش‌هایی برای آن‌ها ایجاد کند. با بررسی انسانی، پوشش به 85٪ افزایش یافت. در این فرآیند، هوش مصنوعی یک باگ واقعی (مسیری که کد خطای اشتباه را برمی‌گرداند) را در شاخه باگی که قبلاً هرگز آزمایش نشده بود، کشف کرد.

مورد 2 - تله تثبیت انتظارات نادرست. تابع گرد کردن پول در واقع اشتباه بود. به جای گرد شدن 2.675 به 2.67، به جای 2.68، 2.67 را گرد می کرد. هوش مصنوعی به کد نگاه کرد و نوشت assert round_money(2.675) == 2.67 - خطا را به عنوان "درست" ثابت کرد. هنگامی که توسعه دهنده مشخصات را خواند، انتظارات را اصلاح کرد و باگ واقعی را کشف کرد. آزمایش قانون، نه کد، تفاوت را ایجاد کرد.

مورد 3 - انفجار حالت لبه. هنگامی که از هوش مصنوعی فقط برای یک تابع محدوده تاریخ درخواست "مورد لبه" می کنید. 8 مورد مانند start=end، بازه معکوس، سال کبیسه 29 فوریه، مناطق زمانی مختلف و فاصله صفر تولید کرد. دو مورد از اینها (فاصله معکوس و سال کبیسه) در واقع باعث خطا می شدند. در نظر گرفتن این موارد به صورت دستی اغلب نادیده گرفته می شود. هوش مصنوعی در اینجا به یک شریک "طوفان فکری موردی لبه" تبدیل شد.

چهار قالب قابل کپی

تولید تست مبتنی بر مشخصات:

نقش: توسعه دهنده ای که تست می نویسد. چارچوب: {{pytest/JUnit/Jest...}}. تابع چه کاری باید انجام دهد (مشخصات): {{قاعده}}برای تابع زیر تست بنویسید. انتظارات را مطابق مشخصات بنویسید، نه خروجی فعلی کد. مسیر مبارک + اضافه کردن حداقل 4 مورد لبه. بگذارید هر آزمون یک چیز را آزمایش کند، از نام توصیفی استفاده کنید. {{عملکرد}}

طوفان فکری Edge Case:

موارد لبه/شکست را فهرست کنید که باید در آزمایش این تابع امتحان شوند (تهی، تهی، نقاط شکست، قالب بد، همزمانی، خطای خارجی). برای هر مورد: ورودی، رفتار مورد انتظار. هنوز کد ننویسید، فقط فهرست کنید.{{function}}

تجزیه و تحلیل شکاف پوشش:

در زیر توابع و تست های موجود آمده است. کدام شاخه ها، شرایط و موارد مورد آزمایش قرار نگرفته است؟ نواقص را لیست کنید و فقط برای کمبودها تست های جدید بنویسید. موارد موجود را تکرار نکنید. تابع:{{function}}تست‌ها:{{existing_tests}}

داده های آزمایشی / تولید شی ساختگی:

داده‌های آزمون واقعی را برای آزمایش‌های {{عملکرد/سرویس}} ایجاد کنید: نمونه‌های معتبر، نمونه‌های حاشیه و نمونه‌های نامعتبر به طور جداگانه. یک رفتار ساختگی ساده برای وابستگی خارجی {{X}} پیشنهاد دهید. استفاده از داده های محرمانه واقعی/PII؛ داده های جعلی تولید کنید

اعلان ضعیف / اعلان قوی

ضعیف: "یک تست برای این تابع بنویسید."

قوی: "با pytest. تابع apply_discount (مجموع، درصد) - قانون: تخفیف باید 0٪ تا 30٪ باشد، خارج از محدوده باید ValueError را پرتاب کند، نتیجه باید به 2 اعشار گرد شود. انتظارات را با این قانون بنویسید (نه با کد). مسیر مبارک + این موارد لبه: 0%, 30%، [0, 31%] منفی، کل (منفی)

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

نوع تست

سهم هوش مصنوعی

کنترل انسان

تست واحد جاده مبارک

اسکلت سریع

آیا انتظار درست است؟

موارد لبه

طوفان فکری گسترده

موارد نامربوط را حذف کنید

پر کردن شکاف محدوده

شاخه های رد شده را پیدا می کند

اهمیت را تأیید کنید

داده های آزمایشی / ساختگی

نمونه واقع بینانه تولید می کند

بدون PII، کنترل واقع گرایی

تست ها کیفیت را مدیریت می کنند، نه آن را تضمین می کنند

پوشش بالای تست اعتماد به نفس می‌دهد، اما همچنین می‌تواند گمراه‌کننده باشد: پوشش 100 درصد به معنای «هر خط اجرا شد»، نه «هر خط درست است». افزایش پوشش با هوش مصنوعی آسان است. ارزش واقعی در نوشتن انتظارات معنادار است. ارزش یک تست توانایی آن برای شکستن و هشدار دادن به شما در صورت شکسته شدن کد است. به همین دلیل است که آزمایش‌های تولید شده توسط هوش مصنوعی بر اساس این سؤال است که آیا کد واقعاً هنگام تغییر می‌شکند؟ آن را با سوال تست کنید؛ شکستن عمدی یک خط و دیدن شکست تست (ایده جهش) دلیلی بر کارآمد بودن تست است.

نکته: برای اینکه ببینید آیا آزمایشی که هوش مصنوعی می‌نویسد کار می‌کند، یک اشکال کوچک در کد ایجاد کنید (مثلاً + را به - تغییر دهید) و ببینید آیا آزمایش خراب می‌شود یا خیر. اگر خراب نشود، آن تست از شما محافظت نمی کند.

اشتباهات رایج

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

به طور خلاصه

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

وظیفه کاربردی

یک تابع را انتخاب کنید و ابتدا با دادن کد آن، آزمایشی را روی هوش مصنوعی چاپ کنید. به انتظارات توجه کنید. سپس مجدداً آزمایش را چاپ کنید و مشخصات (رفتار مورد نیاز) را برای همان عملکرد مشخص کنید. انتظارات دو مجموعه تست را با هم مقایسه کنید: آیا تفاوتی وجود دارد که کدام یک باگ واقعی را نشان می دهد؟ در نهایت، با افزودن یک باگ عمدی به کد و مشاهده شکستن تست، بررسی کنید که یکی از تست‌های تولید شده کار کرده است.

چک لیست

• [ ] من تشخیص می دهم که آیا این آزمایش برای اصلاح یا تأیید رفتار است.
• [ ] وقتی درخواست آزمایش می کنم، قاعده (مشخصات) را می دهم که باید وجود داشته باشد، نه کد.
• [ ] من هر ادعای تولید شده را با مشخصات مقایسه می کنم.
• [ ] من صریحاً موارد لبه و خرابی را درخواست می کنم.
• [ ] من به پوشش درصدی به عنوان یک ابزار نگاه می کنم نه یک هدف.
• [ ] من آزمایش می کنم که آیا یک آزمایش واقعاً با تزریق خطاها محافظت می کند یا خیر.