سود:
- امکان تولید تست های واحد، ادغام و رابط کاربری با هوش مصنوعی مطابق با هرم تست و شرایط محدودیت و خطا و همچنین سناریوهای شاد
- امکان از بین بردن تست های خالی/بی فایده و پوشش پف کرده با بررسی اینکه آیا هر آزمایش ایجاد شده واقعاً یک رفتار را تأیید می کند.
- با گفتن اینکه کد باید چه کاری انجام دهد، اطمینان حاصل شود که تست باگ را پیدا کرده و از رفع اشکال جلوگیری می کند.
نوشتن کد نیمی از کار است. اثبات درستی کارکرد کد نیمی دیگر است. برنامه های موبایل با صدها دستگاه مختلف، اندازه صفحه نمایش، نسخه های سیستم عامل و رفتارهای کاربر مواجه می شوند. آزمایش همه اینها به صورت دستی غیرممکن است. به همین دلیل است که تست خودکار (کد تست کد - آزمایشی که بدون کلیک انسان اجرا می شود) ستون فقرات کیفیت تلفن همراه است. هوش مصنوعی در نوشتن تستها بسیار کارآمد است، زیرا نوشتن تستها دقیقاً همان الگوی کاری است که دوست دارد: اعتبارسنجی یک رفتار خاص برای ورودیهای خاص. در این واحد، نحوه تسریع تست واحد، تست رابط و اتوماسیون با هوش مصنوعی را یاد می گیریم، اما از کیفیت تست از طریق چشم انسان اطمینان حاصل می کنیم.
هرم آزمایش: چه چیزی و چه مقدار را آزمایش کنیم
یک استراتژی تست سالم شبیه یک هرم است. پایه شامل تعداد زیادی تست واحد است (آزمایش سریع که یک تابع یا کلاس را به صورت مجزا آزمایش می کند). آنها سریع و ارزان هستند. در وسط، تست ادغام کمتر (آزمایش نحوه کار چند قسمت با هم) وجود دارد. در بالا حداقل تست UI/end-to-end وجود دارد (تست با کلیک روی صفحه همانطور که کاربر انجام می دهد انجام می شود). آنها واقع بینانه اما کند و شکننده هستند. هوش مصنوعی در هر لایه کمک می کند، اما بیشترین ارزش در پایه است: تولید سریع تست های واحد منطق تجاری.
نوع تست
دامنه
سرعت
بهره وری هوش مصنوعی
تست واحد
تک عملکرد/کلاس
بسیار سریع
بسیار بالا
ادغام
بین لایه ای
متوسط
بالا
UI / انتها به انتها
همه جریان صفحه نمایش
کند
متوسط (شکننده)
نکته: وقتی به هوش مصنوعی میگویید «تستهایی برای این تابع ایجاد کند»، صراحتاً موارد لبه را بخواهید: ورودی خالی، تهی، عدد منفی، مقدار بسیار بزرگ، خطای شبکه. هوش مصنوعی مسیر شاد را به راحتی ایجاد می کند. اشتباهات واقعی در مرزها پنهان می شوند و اگر آنها را نمی خواهید به بیرون می پرند.
مراحل نوشتن تست با هوش مصنوعی
- رفتار مورد آزمایش را تعریف کنید. "این تابع باید این خروجی را به این ورودی بدهد."
- چارچوب را مشخص کنید. JUnit + MockK در اندروید، XCTest در iOS، اسپرسو (اندروید) یا XCUITest (iOS) برای رابط کاربری.
- حالت های حد را بخواهید. سناریوی شاد + خطا + نقاط شکست.
- اشیاء ساختگی را مدیریت کنید. وابستگیهای خارجی مانند شبکه و پایگاه داده برای آزمایش شبیهسازی میشوند (ساخت - ساختگی کنترلشده به جای سرویس واقعی).
- تست را اجرا کنید و تایید کنید. آیا آزمون قبول می شود، آیا چیزی واقعاً معنی دار را تأیید می کند؟
گام پنجم حیاتی است. هوش مصنوعی گاهی اوقات آزمایش های بی فایده ای را تولید می کند که "همیشه موفق می شوند". به عنوان مثال، آزمایشی که چیزی را تأیید نمی کند یا داده های جعلی خود را بررسی می کند. یک آزمون قبولی و یک آزمون ارزشمند چیزهای متفاوتی هستند.
احتیاط: فقط به این دلیل که هوش مصنوعی می تواند تولید کند به این معنی نیست که آزمایش درست است. گاهی اوقات هوش مصنوعی رفتار فعلی (شاید معیوب) کد را به عنوان "درست" می پذیرد و بر اساس آن تست ها را می نویسد. چنین آزمایشی به جای رفع اشکال، آن را برطرف می کند. شما تعیین می کنید که آزمون چه انتظاری دارد. به هوش مصنوعی بگویید چه کاری باید انجام دهد، نه اینکه کد چه کاری انجام می دهد.
اندازه گیری پوشش و مغالطه تست
پوشش تست (چه درصدی از کد توسط تست ها اجرا می شود) یک معیار مفید اما گمراه کننده است. پوشش 90 درصد نشان می دهد که 90 درصد کد اجرا شده است. اما تأیید نشده است که آن خطوط به درستی کار می کنند. آزمایشی که یک خط را اجرا می کند و نتیجه را بررسی نمی کند، دامنه را افزایش می دهد اما امنیت را ایجاد نمی کند. هدف اعداد بالا نیست، بلکه اعتبارسنجی معنادار است. با هوش مصنوعی میتوانید به سرعت مقیاس را افزایش دهید، اما مطمئن شوید که هر تست واقعاً یک رفتار را آزمایش میکند.
سه کیف کوچک
مورد 1 - وضعیت مرزی مشخص شد. از هوش مصنوعی برای آزمایش عملکرد انتقال پول در یک برنامه بانکی خواسته شد و به طور خاص سناریوهای «مقدار منفی» و «بیش از مانده» اضافه شدند. آزمایش نشان داد که انتقال با مبلغ منفی مسدود نشده است. این یک آسیب پذیری امنیتی بزرگ در تولید خواهد بود. با افزودن یک کنترل یک خطی بسته شد. درس: تست های مرزی با ارزش ترین تست ها هستند.
مورد 2 - آزمایش جعلی. یک تیم از افزایش پوشش به 85 درصد با 40 واحد تست تولید شده توسط هوش مصنوعی راحت شد. در حین بازرسی، مشاهده شد که اکثر تست ها در واقع هیچ خروجی را تأیید نمی کنند، آنها فقط تابع را فراخوانی کرده و assertTrue(true) را نوشته اند. پوشش بالا بود اما محافظت صفر بود. تست ها با اعتبارسنجی واقعی بازنگری و بازنویسی شدند. درس: اعداد پوشش می توانند دروغ بگویند.
مورد 3 - تست UI تسریع شد. یک تیم تجارت الکترونیک یک اسکریپت XCUITest از جریان افزودن به سبد خرید را با هوش مصنوعی در 20 دقیقه نوشت. اگر با دست نوشته می شد نصف روز طول می کشید. شناسه های عناصر صفحه نمایش حدس زده توسط هوش مصنوعی. تیم آنها را با کد واقعی مطابقت داد و آنها را برطرف کرد. سرعت پیش نویس واقعی است، اما تأیید شناسه کار انسانی است.
اعلان ضعیف / اعلان قوی
اعلان ضعیف: "یک آزمایش برای این تابع بنویسید."
اعلان قدرتمند: "تست های واحد را برای این تابع Kotlin با JUnit5 + MockK تولید کنید. عملکرد: انتقال پول (مبلغ، منبع، هدف). رفتارهای آزمایشی (آنچه که کد باید انجام دهد): - انتقال معتبر باید موفقیت آمیز باشد - مقدار منفی یا صفر باید رد شود - مقدار بیشتر از موجودی باید فقط یک خطای شبکه باید رد شود. توصیفی، سرویس خارجی را مسخره کنید، یک ادعای خالی ننویسید."
قالب های قابل کپی
الگوی تست واحد: "تستهای واحد [JUnit/XCTest] را برای این تابع برای [زبان] ایجاد کنید. رفتار مورد انتظار: [چه باید کرد]. شامل: سناریوی شاد، ورودی تهی، نقاط شکست، موارد خطا. اجازه دهید هر آزمون یک رفتار را تأیید کند؛ از ادعای معنیدار استفاده کنید؛ تمسخر [کد]."
الگوی تست رابط کاربری: "یک تست UI از جریان زیر با [Espresso/XCUITest] بنویسید: [جریان کاربر گام به گام]. عناصر صفحه را با شناسه دسترسی انتخاب کنید، به جای متن از شناسه استفاده کنید. استراتژی انتظار را اضافه کنید. به من یادآوری کنید شناسه عناصر را با کد واقعی مطابقت دهم."
الگوی ممیزی آزمایشی:"این تست ها را بررسی کنید: 1) آیا آنها واقعا یک خروجی/رفتار را تایید می کنند یا باطل هستند؟ 2) آیا موارد محدود را پوشش می دهند؟ 3) آیا کد را رفع اشکال می کنند یا انتظار رفتار صحیح دارند؟ تست های ضعیف را پرچم گذاری و تقویت می کنند. [تست ها]."
الگوی بهینهسازی پوشش: "قسمتهای تست نشده این کلاس را شناسایی کنید و آزمایشهای معنیداری را پیشنهاد دهید. اولویتبندی مسیرهایی با ریسک واقعی، نه فقط تعداد پوششها. [کد]"
اشتباهات رایج
- فقط آزمایش سناریوی شاد خطاها در حالت های حد ذخیره می شوند. آنها را آشکارا بخواهید.
- قبولی آزمون خالی/بی فایده. آزمایشهای نوع assertTrue(true) دامنه را افزایش میدهد و هیچ محافظتی ارائه نمیدهد.
- داشتن هوش مصنوعی تأیید می کند که کد چه کاری انجام می دهد. آزمایش باید انتظار داشته باشد که کد باید چه کاری انجام دهد. در غیر این صورت باگ را برطرف می کند.
- اشتباه کردن شماره محدوده برای هدف. پوشش 90 درصد به معنای دقت 90 درصد نیست.
- پیوند دادن به متن در تست UI. هنگامی که متن تغییر می کند، آزمون شکسته می شود. از شناسه پایدار (id) استفاده کنید.
- راه اندازی نادرست ماک ها "تست واحد" که سرویس واقعی را فراخوانی می کند کند و شکننده خواهد بود.
به طور خلاصه
تست ستون فقرات کیفیت موبایل است و هوش مصنوعی در این زمینه به خصوص در تست واحد بسیار کارآمد است. هرم تست را دنبال کنید: واحدهای زیاد، ادغام متوسط، تست UI کمی. صراحتاً از هوش مصنوعی سناریوی شاد و همچنین موارد محدود و مسیرهای خطا را بخواهید. اطمینان حاصل کنید که هر تست ایجاد شده در واقع یک رفتار را تایید می کند. تست های خالی و پوشش باد شده گمراه کننده هستند. مهمتر از همه، به هوش مصنوعی بگویید که کد باید چه کاری انجام دهد، نه اینکه چه کاری انجام می دهد، بنابراین آزمایش باگ را پیدا کند، نه آن را برطرف کند.
وظیفه کاربردی
از هوش مصنوعی با استفاده از «الگوی آزمون واحد» برای یک تابع منطق تجاری (مانند محاسبه تخفیف یا اعتبارسنجی فرم) درخواست کنید و موارد حد را به صراحت مشخص کنید (تهی، منفی، خیلی بزرگ). تست های تولید شده را اجرا کنید، سپس همان تست ها را با "Test audit template" مورد بازرسی قرار دهید. حداقل یک تست ضعیف را پیدا کنید، آن را تقویت کنید و بررسی کنید که آیا تست ها خطای واقعی تابع را می گیرند (با افزودن یک اشکال کوچک).
چک لیست
- [ ] من لایه مناسب را برای هرم آزمایشی انتخاب کردم (واحد اولویت)
- [ ] من موارد محدودیت و خطا را علاوه بر سناریوی شاد می خواستم
- [ ] من تأیید کردم که هر آزمون حاوی یک ادعای معنادار است
- [ ] من به هوش مصنوعی گفتم که کد باید چه کاری انجام دهد، نه اینکه چه کاری انجام می دهد
- [ ] من روی مسیرهای ریسک واقعی تمرکز کردم، نه تعداد پوشش ها
- [ ] من از شناسه پایدار در تست های رابط کاربری استفاده کردم، به متن متصل نشدم