گردش کار سرتاسر، ادغام CI/CD، اخلاق و امنیت: استفاده مسئولانه از هوش مصنوعی

سود:

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

در ده واحد قبلی، ما از هوش مصنوعی در وظایف فردی استفاده کردیم: تولید سناریو، کد اتوماسیون، گزارش اشکال، تجزیه و تحلیل پوشش، تست جهش. این واحد نهایی همه آنها را در یک گردش کار مسئول ترکیب می کند. QA مدرن شغلی نیست که به میز یک نفر ختم شود. این فرآیندی است که در CI/CD زندگی می کند (ادغام مداوم / تحویل مستمر - خط لوله ای که کد به طور مداوم ترکیب می شود، به طور خودکار آزمایش می شود و برای انتشار مکرر و ایمن آماده می شود). هوش مصنوعی می تواند تمام مراحل این فرآیند را لمس کند. اما با افزایش قدرت هوش مصنوعی، اهمیت استفاده مسئولانه از آن بیشتر می‌شود: حریم خصوصی، اقتدار در تست‌های امنیتی، اخلاقیات، و مهم‌تر از همه، حفظ تصمیم کیفیت در اختیار انسان‌ها. در این واحد، جریان و مرزهای سرتاسری را یاد خواهید گرفت.

جریان QA با هوش مصنوعی سرتاسر

نقش هوش مصنوعی در سفر یک ویژگی از ایده تا انتشار:

1. تجزیه و تحلیل نیازمندی ها. هوش مصنوعی ابهامات موجود در الزامات و معیارهای پذیرش را نشان می دهد ("این قانون نمی گوید حداقل تعداد نویسه رمز عبور است").

2. طراحی تست. پیش نویس های سناریو و مورد (واحد 2)، موارد لبه (واحد 3) از جمله معیارهای پذیرش هستند.

3. اتوماسیون. پیش نویس کد آزمون واحد (6)، API (5) و UI (4). هر کدام با جهش تایید می شوند (10).

4. یکپارچه سازی CI/CD. با هر ادغام کد، تست ها به طور خودکار اجرا می شوند. هوش مصنوعی پیکربندی خط لوله (YAML) را ترسیم می‌کند، گزارش‌های آزمایش‌های ناموفق را خلاصه می‌کند، و علت اصلی احتمالی را نشان می‌دهد.

5. تصمیم آزادی. نتایج تجزیه و تحلیل ریسک (8) و رگرسیون (9) جمع آوری می شوند - اما متخصص تصمیم می گیرد که آیا می تواند موفقیت آمیز باشد یا خیر.

6. نظارت بر تولید و بازخورد. خطاها در لایو به تست های آینده تبدیل می شوند. هوش مصنوعی یک مورد رگرسیون از یک نقص تولید را پیشنهاد می کند.

نکته: هوش مصنوعی را به‌عنوان لایه‌ای در CI/CD تنظیم کنید که «پیش‌نویس‌های بررسی‌شده توسط انسان را تسریع می‌کند» به‌جای «نوشتن آزمایش‌ها و تصمیم‌گیری». هیچ آزمایشی که به طور خودکار تولید می شود نباید بدون بازبینی و تایید انسان وارد خط لوله شود.

هوش مصنوعی در CI/CD: جایی که بله، جایی که خیر

مرحله

AI مناسب است

انسان ضروری است

پیش نویس کد تست

بله

تجدید نظر + جهش

پیش نویس خط لوله YAML

بله

احراز هویت + چک کردن کلید مخفی

خلاصه گزارش ناموفق

بله

تایید علت ریشه ای

تشخیص تست شکننده

بله

تصمیم راه حل دائمی

"آیا نسخه ای وجود دارد؟"

نه

قضاوت و مسئولیت تخصصی

به طور خودکار "گذراندن" آزمون

هرگز

-

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

حریم خصوصی، داده ها و امنیت: مرزهای تغییرناپذیر

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

تست امنیتی - دفاعی و مجاز. تست‌های امنیتی آموخته‌شده در این ماژول (تست‌های مجوز/IDOR، محدودیت‌های آپلود فایل، اعتبارسنجی ورودی) فقط برای آزمایش محصول شما در مجوز کتبی و محدوده تعریف‌شده است. استفاده از هوش مصنوعی برای دسترسی بدون اجازه به سیستم شخص دیگری، ایجاد سلاح در آسیب‌پذیری‌های واقعی یا انجام آزمایش‌های خارج از محدوده، هم غیراخلاقی و هم غیرقانونی است. وقتی آسیب‌پذیری امنیتی پیدا کردید، از اصل افشای مسئولانه پیروی کنید - آسیب‌پذیری را محرمانه نگه دارید و آن را به طرف مربوطه گزارش دهید تا بتوان آن را برطرف کرد.

اخلاق و شفافیت تست های تولید شده توسط هوش مصنوعی را به عنوان کار خودتان معرفی نکنید. بیان اینکه از هوش مصنوعی در تیم استفاده می کنید شفافیت است. شما مسئول نادرستی یک خروجی تولید شده با هوش مصنوعی هستید - "هوش مصنوعی آن را نوشت" بهانه ای نیست.

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

ضعیف: "راه اندازی خط لوله آزمایشی برای CI."

Strong: "پیش نویس یک گردش کار CI YAML برای GitHub Actions: اجرای واحد + تست های API در هر PR، تولید گزارش پوشش، اجرای آزمایش جهش (Stryker) به صورت هفتگی. اسرار را در کد جاسازی نکنید، فقط از مرجع اسرار استفاده کنید. اگر تست ها قرمز هستند، ادغام را مسدود کنید. این یک کلید DRAFT است. من یک DRAFT را یک کلید مدیریت می کنم. آزمایش مرحله «اصلاح» یا «مهاجرت»».

اعلان قدرتمند؛ محدودیت هایی برای محرمانگی، بازبینی انسانی و "بدون تست خودکار" اعمال می کند.

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

1) طرح آزمایش انتها به انتها:

نقش شما: رهبر ارشد QA. یک طرح آزمایشی سرتاسر از ایده تا انتشار برای ویژگی زیر تهیه کنید: [ویژگی + معیارهای پذیرش]. مراحل: تجزیه و تحلیل نیازمندی ها (عدم قطعیت ها)، طراحی آزمایش، لایه های اتوماسیون (واحد/API/UI)، ادغام CI/CD، معیارهای تصمیم انتشار، ردیابی تولید. نقش نقاط تایید هوش مصنوعی و HUMAN را در هر مرحله به طور جداگانه مشخص کنید.

2) طرح کلی خط لوله CI/CD:

پیش نویس CI YAML برای [GitHub Actions/GitLab CI/Azure Pipelines]:- واحد + تست API + دامنه در PR- جلوگیری از ادغام در تست قرمز- مقادیر محرمانه فقط با اسرار. جاسازی در کد این یک پیش نویس است. من مراحل کلیدی مدیریت و تایید را بررسی خواهم کرد. افزودن یک مرحله آزمون تصحیح خودکار/گذراندن.

3) تجزیه و تحلیل لاگ آزمون ناموفق:

در آن چاپ CI، تست ها قرمز هستند. گزارش را بررسی کنید؛ شکست ها را گروه بندی کنید، علت اصلی احتمالی را تشخیص دهید و کدام یک ممکن است شکست واقعی باشد و کدام یک ممکن است یک مشکل شکننده آزمون/محیط باشد. اگر اطلاعات شخصی وجود دارد، آن را پنهان کنید. تصمیم و اصلاح با من خواهد بود. ورود به سیستم: [چسباندن]

4) پیش‌بررسی امنیت/حریم خصوصی:

قبل از اینکه این داده/ گزارش آزمایشی به ابزار هوش مصنوعی ارسال شود، بررسی کنید: آیا حاوی داده‌های شخصی، کلید API، آدرس سیستم داخلی، داده‌های تولید است؟ فهرست کنید که کدام مناطق، در صورت وجود، نیاز به پوشاندن/حذف شدن دارند. پردازش همانطور که هست. محتوا: [چسباندن]

سه کیف کوچک

مورد 1 - سرعت جریان انتها به انتها. یک تیم با ویژگی جدید «تجدید اشتراک» با یک جریان سرتاسر مبتنی بر هوش مصنوعی مقابله کرد: عدم قطعیت‌های مورد نیاز در جلو، آزمایش‌های سه لایه پیش‌نویس و تأیید جهش، مرتبط با CI. این ویژگی چرخه آزمایش را که در فرآیند سنتی 5 روز طول می کشید، به 2 روز کاهش داد. اما تایید انسان در هر مرحله حفظ شد و عدم قطعیت الزامات (در صورت عدم موفقیت در به‌روزرسانی چه اتفاقی می‌افتد) قبل از اجرای زنده بسته شد.

مورد 2 - بازگشت از نشت کلید. یک توسعه‌دهنده AI CI YAML را تولید کرد و هوش مصنوعی یک کلید API واقعی را به عنوان مثال در YAML تعبیه کرد. مرحله «پیش‌بررسی امنیت/حریم خصوصی» این را نشان می‌دهد. کلید تبدیل به مرجع اسرار بدون مرحله ممیزی، کلید به کنترل نسخه (سابقه git) نشت می کند.

مورد 3 - حد اختیار. یکی از اعضای تیم می‌خواست آزمون IDOR را که یاد گرفته بود در سیستم زنده شریک تجاری از «من کنجکاو بودم» اعمال کند. رهبر QA متوقف شد: انجام تست امنیتی روی سیستم دیگری بدون مجوز کتبی و محدوده تعریف شده غیرقانونی است. آزمایش فقط در محیط آزمایش محصولات خود آنها با اقتدار انجام شد. مسئول باز به تیم مربوطه اعلام شد.

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

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

به طور خلاصه

QA End-to-End فرآیندی است که از الزامات تا ردیابی تولید گسترش می‌یابد و در CI/CD زندگی می‌کند. در هر مرحله، هوش مصنوعی پیش نویس ها را تولید می کند، گزارش را خلاصه می کند و دلایل اصلی را پیشنهاد می کند. اما مرزها تغییر ناپذیر هستند: انسان ها تصمیمات آزمایشی را می گیرند و تاییدیه را آزاد می کنند. هرگز به هوش مصنوعی این اختیار داده نمی شود که به طور خودکار آزمایش را "گذراند". اطلاعات محرمانه و کلیدها وارد خودرو نمی شوند. تست امنیتی فقط بر روی محصول شما، در چارچوب مجوز کتبی و محدوده تعریف شده، برای اهداف دفاعی انجام می شود و یافته ها با افشای مسئولانه گزارش می شوند. هنگام استفاده از هوش مصنوعی شفاف باشید. شما مسئول دقت خروجی هستید. هوش مصنوعی شتاب می گیرد؛ شما کیفیت و اخلاق را تضمین می کنید.

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

یک طرح از ایده به انتشار با یک الگوی "طرح آزمایشی سرتاسر" برای یک ویژگی از پروژه خود تهیه کنید. نقش هوش مصنوعی و نقاط تایید انسان را به طور جداگانه در هر مرحله مشخص کنید. سپس یک YAML با «طرح خط لوله CI/CD» ایجاد کنید و «بررسی پیش‌بینی امنیت/حریم خصوصی» را در این YAML اعمال کنید تا کلید/داده‌های محرمانه جاسازی شده را بررسی کنید. در نهایت، تمام نکات "تصمیم گیری انسانی" را در برنامه خود فهرست کنید و در یک جمله توجیه کنید که چرا نمی توان این تصمیمات را به هوش مصنوعی واگذار کرد.

چک لیست

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

امتحان ماژول

1. چگونه "گذر نادرست" در زمینه QA با بیشترین دقت تعریف می شود؟

• الف) اگرچه تست سبز می شود، اما در واقع هیچ رفتاری را تایید نمی کند. ✔ حتی اگر کد خراب باشد قرمز نمی شود
• ب) آزمون بسیار کند اجرا می شود و زمان آن تمام می شود.
• ج) تست یک خطای واقعی را تشخیص می دهد و قرمز می شود
• د) آزمایش فقط در محیط تولید اجرا می شود

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

2. دقیق ترین موقعیت یابی هوش مصنوعی در فرآیند تست و QA چیست؟

• الف) هوش مصنوعی می تواند تصمیم بگیرد که آیا نسخه می تواند بدون تایید انسان منتشر شود یا خیر
• ب) هوش مصنوعی دستیار تولید پیش نویس و ایده است. تصمیم و مسئولیت «آیا آماده انتشار است» بر عهده کارشناس است ✔
• ج) هوش مصنوعی فقط متن می نویسد و به هیچ وجه نمی تواند با کد تست کار کند
• د) هوش مصنوعی همیشه تست درست می نویسد تا انسان، بنابراین بررسی غیر ضروری است

توضیحات: هوش مصنوعی یک دستیار آزمایش، تولید کننده پیش نویس و چند برابر کننده ایده است. سناریوهای تست، کد اتوماسیون و پیش نویس گزارش را تولید می کند. اما مسئولیت و تایید نهایی تصمیمات کیفی مانند "آیا این نرم افزار آماده انتشار است" یا "آیا این آزمون قبول شده است" بر عهده کارشناس ذیصلاح است.

3. با توجه به اینکه خطاها بیشتر در مقادیر آستانه رخ می دهد، کدام تکنیک طراحی آزمون برای محدودیت سنی 18 سال به طور جداگانه آزمون 17، 18 و 19 است؟

• الف) آزمون انتقال حالت
• ب) جدول تصمیم گیری
• ج) تحلیل ارزش مرزی ✔
• د) آزمایش اکتشافی

توضیح: تجزیه و تحلیل ارزش مرزی مبتنی بر مشاهده این است که خطاها اغلب در مرزها رخ می دهند و مقادیر آستانه (درست زیر، درست بالاتر و درست بالاتر از حد) را به طور جداگانه آزمایش می کند. این یک تکنیک قدرتمند است که کلاس های هم ارزی را تکمیل می کند.

4. برای کاهش شکنندگی کد اتوماسیون تست UI تولید شده با هوش مصنوعی، کدام رویکرد باید در انتخاب عنصر ترجیح داده شود؟

• الف) استفاده از طولانی ترین مسیر XPath ممکن
• ب) انتخاب عنصر با توجه به موقعیت پیکسل آن بر روی صفحه نمایش
• ج) استفاده از انتخابگرها بر اساس نام کلاس های CSS
• د) استفاده از ویژگی های پایدار (data-testid) اضافه شده برای تست ✔

توضیح: مسیرهای طولانی XPath و نام کلاس های CSS به شدت به ساختار و طراحی صفحه وابسته هستند. با کوچکترین تغییر رابط خراب می شود. ویژگی‌های پایداری که به‌طور خاص برای آزمایش اضافه شده‌اند (مانند داده-testid) تحت تأثیر تغییرات طراحی قرار نمی‌گیرند و آزمایش‌ها را قوی می‌کنند.

5. چرا فقط بررسی کد وضعیت HTTP (مثلاً 200) برای یک تست API کافی نیست؟

• الف) زیرا داده های بدن با کد وضعیت صحیح ممکن است خراب شود و بررسی وضعیت به تنهایی نمی تواند این مورد را تشخیص دهد (شبه اعتماد) ✔
• ب) زیرا کدهای وضعیت به هیچ وجه در تست های API قابل اعتماد نیستند
• ج) زیرا بررسی کد وضعیت سرعت تست را بسیار کند می کند
• د) زیرا کد وضعیت هرگز در تست های API برگردانده نمی شود

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

6. چرا هنگام چاپ تست های واحد بسیار مهم است که به هوش مصنوعی بگوییم "مقدار مورد انتظار را طبق قانون پذیرش به صورت دستی محاسبه کند، خروجی فعلی تابع را ارجاع ندهید"؟

• الف) زیرا محاسبه دستی تست ها را سریعتر اجرا می کند
• ب) زیرا در غیر این صورت آزمایش رفتار فعلی (شاید باگ) کد را به عنوان "درست" می پذیرد و اشکال را تأیید می کند ✔
• ج) چون هوش مصنوعی اصلا نمی تواند اعداد اعشاری را محاسبه کند
• د) زیرا قوانین پذیرش هرگز در آزمون ها استفاده نمی شود

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

7. کدام یک از موارد زیر متمایزترین ویژگی گزارش اشکال خوب است؟

• الف) تا حد امکان طولانی و فنی باشد
• ب) نوشته شده توسط هوش مصنوعی
• ج) شامل مراحل بازتولید قطعی است که توسعه دهنده می تواند به طور مستقل دنبال کند و خطا ایجاد کند ✔
• د) این فقط یک اسکرین شات است

توضیح: ارزش واقعی گزارش اشکال این است که توسعه دهنده می تواند بدون کمک شما اشکال را تولید کند. مراحل بازتولید قطعی و قابل ردیابی از ابتدا این امر را تضمین می کند. اگر این مراحل از دست رفته باشند، گزارش اغلب به عنوان «نمی‌توان تولید کرد» بسته می‌شود.

8- دقیق ترین عبارت برای رابطه شدت و اولویت در اشتباه املایی نام شرکت در صفحه اصلی کدام است؟

• الف) شدت و اولویت باید همیشه ارزش یکسانی داشته باشد
• ب) هم شدت و هم اولویت این خطا قطعا کم است
• ج) شدت و اولویت یک مفهوم است، یک برچسب کافی است
• د) شدت فنی ممکن است کم باشد اما اولویت تجاری (شهرت) ممکن است زیاد باشد. این دو متفاوت ارزیابی می شوند ✔

توضیح: شدت اثر فنی خطا است (اشتباه تایپی از نظر فنی کم)، اولویت این است که چقدر فوری باید رفع شود (زیاد چون یک عنصر شهرت است که هر بازدیدکننده ای می بیند). این دو همیشه در یک جهت نیستند. این مثال یک وضعیت با شدت کم-اولویت بالا است.

9. دقیق ترین تفسیر از مجموعه تست با پوشش خط 90 درصد کدام است؟

• الف) نشان می دهد که خطوط اجرا شده اند اما رفتار صحیح آنها را ثابت نمی کند. ✔ پوشش بالا می تواند اعتماد به نفس کاذب بدهد
• ب) به طور قطع ثابت می کند که 90 درصد نرم افزار بدون اشکال است
• ج) معیار قطعی کیفیت عالی آزمون است.
• د) نشان می دهد که دیگر نیازی به نوشتن تست اضافی نیست

توضیح: پوشش ردیف نشان می دهد که فقط ردیف ها اجرا شده اند. ثابت نمی کند که نتایج درستی به بار می آورد. حتی با تست های بدون ادعا می توان به پوشش 90 درصدی دست یافت. Scope یک نقشه «هرگز در کجا نگاه نشد» است، نه تضمین «همه چیز آزمایش شده است». حفاظت واقعی با آزمایش جهش اندازه گیری می شود.

10. در آزمایش مبتنی بر ریسک، چگونه ریسک یک ویژگی برای هدایت تلاش محدود تست محاسبه می شود؟

• الف) فقط با تعداد خطوط کد
• ب) با ضرب احتمال شکست و اثری که در هنگام خرابی ایجاد می شود ✔
• ج) فقط به ترتیبی که ویژگی توسعه یافته است
• د) اولویت بندی فقط ویژگی هایی که راحت ترین تست ها برای آن نوشته می شود

توضیح: در تست مبتنی بر ریسک، ریسک به صورت احتمال = احتمال (احتمال خرابی) × تاثیر (در صورت شکستن آسیب) ارزیابی می شود. دامنه‌های با احتمال زیاد و تأثیر زیاد (پرداخت، تأیید اعتبار) مستحق شدیدترین آزمایش هستند، در حالی که دامنه‌های کم و کم آزمایش سبک را دریافت می‌کنند.

11. خطر اصلی افزودن یک امتحان مجدد به آزمونی که گاهی اوقات موفق می شود و گاهی اوقات ناموفق است (شکننده/پوسته) با وجود اینکه کد تغییر نکرده است چیست؟

• الف) کوتاه شدن زمان اجرای آزمون
• ب) درصد پوشش را کاهش می دهد
• ج) پوشاندن یک خطای همزمان واقعی یا علت اصلی و سرکوب علامت ✔
• د) تغییر نام آزمون

توضیح: تلاش مجدد یک ابزار تشخیصی است نه یک درمان. بلاتکلیفی اغلب از یک وضعیت واقعی نژادی یا اعتیاد ناشی می شود. انجام تست "گذراندن" با تلاش مجدد این خطای واقعی را پوشانده و می تواند مشکلات جدی در پخش زنده ایجاد کند. ابتدا باید علت اصلی را پیدا کرد.

12. تست جهش، صادقانه ترین روش برای اندازه گیری اینکه آیا یک مجموعه آزمایش واقعاً محافظت می کند، چگونه کار می کند؟

• الف) با اندازه گیری سرعت اجرای تست ها
• ب) با شمارش چند خط کد نوشته شده است
• ج) با اجرای تست ها به ترتیب های مختلف
• د) با ایجاد وقفه های کوچک در کد و اندازه گیری اینکه آیا تست ها آنها را می گیرند یا خیر ✔

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

13. محدودیت اصلی که باید هنگام انجام تست امنیتی رعایت شود (مثلاً آزمایشات مجوز/IDOR) چیست؟

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

توضیحات: تست های امنیتی آموخته شده در این ماژول فقط برای آزمایش محصول شما برای اهداف دفاعی، در مجوز کتبی و محدوده تعریف شده است. دسترسی به سیستم شخص دیگری بدون اجازه یا انجام آزمایش خارج از محدوده، هم غیراخلاقی و هم غیرقانونی است. هر گونه آسیب پذیری یافت شده از طریق افشای مسئولانه گزارش می شود.

14. هرگز نباید در خط لوله CI/CD چه اختیاراتی به هوش مصنوعی داده شود؟

• الف) خلاصه کردن لاگ های تست شکست خورده
• ب) اختیار «گذراندن» خودکار یک آزمون ناموفق (قرمز) یا رنگ سبز آن ✔
• ج) پیشنهاد پیش نویس کد آزمون
• د) طراحی فایل YAML خط لوله

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