تست خودکار به شما کمک میکند تا کیفیت برنامه را از چندین طریق بهبود بخشید. به عنوان مثال، به شما در انجام اعتبارسنجی، گرفتن رگرسیونها و تأیید سازگاری کمک میکند. یک استراتژی تست خوب به شما امکان میدهد از تست خودکار برای تمرکز بر یک مزیت مهم استفاده کنید: بهرهوری توسعهدهنده .
تیمها وقتی از یک رویکرد سیستماتیک برای تست همراه با بهبود زیرساختها استفاده میکنند، به سطوح بالاتری از بهرهوری دست مییابند. انجام این کار، بازخورد به موقعی در مورد نحوه رفتار کد ارائه میدهد. یک استراتژی تست خوب موارد زیر را انجام میدهد:
- مشکلات را در اسرع وقت تشخیص میدهد.
- سریع اجرا میشود.
- وقتی چیزی نیاز به تعمیر دارد، نشانههای واضحی ارائه میدهد.
این صفحه به شما کمک میکند تا تصمیم بگیرید چه نوع آزمایشهایی را پیادهسازی کنید، کجا و چند وقت یکبار آنها را اجرا کنید.
مهارتهای اندروید
مشاهده در گیتهاب یک استراتژی تست ایجاد کنید
android skills add --skill testing-setup
هرم آزمایش
شما میتوانید تستها را در برنامههای مدرن بر اساس اندازه دستهبندی کنید. تستهای کوچک فقط روی بخش کوچکی از کد تمرکز میکنند و همین امر آنها را سریع و قابل اعتماد میکند. تستهای بزرگ دامنه وسیعی دارند و به تنظیمات پیچیدهتری نیاز دارند که نگهداری آنها دشوار است. با این حال، تستهای بزرگ دقت بیشتری دارند* و میتوانند مشکلات بسیار بیشتری را در یک مرحله کشف کنند.
*وفاداری (Fidelity) به شباهت محیط زمان اجرای تست با محیط تولید اشاره دارد.
اکثر برنامهها باید تستهای کوچک زیادی و تستهای بزرگ نسبتاً کمی داشته باشند. توزیع تستها در هر دسته باید یک هرم تشکیل دهد، که تستهای کوچکتر، قاعده و تستهای بزرگتر، نوک هرم را تشکیل میدهند.
هزینه یک باگ را به حداقل برسانید
یک استراتژی تست خوب، بهرهوری توسعهدهنده را به حداکثر میرساند و در عین حال هزینه یافتن اشکالات را به حداقل میرساند.
مثالی از یک استراتژی احتمالاً ناکارآمد را در نظر بگیرید. در اینجا، تعداد تستها بر اساس اندازه به صورت هرمی سازماندهی نشده است. تستهای سرتاسری بزرگ زیادی وجود دارد و تستهای رابط کاربری کامپوننتها بسیار کم است:
این یعنی قبل از ادغام، تستهای خیلی کمی اجرا میشوند. اگر باگی وجود داشته باشد، ممکن است تستها تا زمان اجرای تستهای پیوسته شبانه یا هفتگی، آن را تشخیص ندهند.
مهم است که پیامدهای این موضوع را برای هزینه شناسایی و رفع اشکالات در نظر بگیرید و اینکه چرا مهم است تلاشهای تست خود را به سمت تستهای کوچکتر و مکررتر سوق دهید:
- وقتی باگ توسط یک تست واحد شناسایی میشود، معمولاً در عرض چند دقیقه برطرف میشود، بنابراین هزینه کم است.
- یک تست سرتاسری میتواند چند روز طول بکشد تا یک اشکال مشابه کشف شود. این میتواند چندین عضو تیم را درگیر کند، بهرهوری کلی را کاهش دهد و احتمالاً انتشار را به تأخیر بیندازد. هزینه این اشکال بیشتر است.
با این اوصاف، یک استراتژی تست ناکارآمد بهتر از هیچ استراتژیای نیست. وقتی یک باگ به مرحله تولید میرسد، رفع آن مدت زیادی طول میکشد تا در دستگاههای کاربر قرار گیرد، گاهی اوقات هفتهها، بنابراین حلقه بازخورد طولانیترین و پرهزینهترین حلقه است.
یک استراتژی تست مقیاسپذیر
هرم آزمایش به طور سنتی به ۳ دسته تقسیم شده است:
- تستهای واحد
- آزمونهای یکپارچهسازی
- آزمونهای پایان به پایان.
با این حال، این مفاهیم تعاریف دقیقی ندارند، بنابراین تیمها ممکن است بخواهند دستهبندیهای خود را به طور متفاوتی تعریف کنند، برای مثال با استفاده از ۵ لایه:
- یک تست واحد روی دستگاه میزبان اجرا میشود و یک واحد منطقی عملکردی واحد را بدون وابستگی به چارچوب اندروید تأیید میکند.
- مثال: بررسی خطاهای خارج از نوبت در یک تابع ریاضی.
- یک تست کامپوننت، عملکرد یا ظاهر یک ماژول یا کامپوننت را مستقل از سایر کامپوننتهای سیستم تأیید میکند. برخلاف تستهای واحد، سطح تست کامپوننت به انتزاعهای بالاتری فراتر از متدها و کلاسهای منفرد گسترش مییابد.
- مثال: تست اسکرین شات برای یک دکمه سفارشی
- یک تست ویژگی ، تعامل دو یا چند جزء یا ماژول مستقل را تأیید میکند. تستهای ویژگی بزرگتر و پیچیدهتر هستند و معمولاً در سطح ویژگی عمل میکنند.
- مثال: تستهای رفتار رابط کاربری که مدیریت حالت را در یک صفحه نمایش تأیید میکنند
- یک تست برنامه ، عملکرد کل برنامه را در قالب یک فایل باینری قابل استقرار تأیید میکند. آنها تستهای یکپارچهسازی بزرگی هستند که از یک فایل باینری قابل اشکالزدایی، مانند یک نسخه توسعهیافته که میتواند شامل قلابهای تست باشد، به عنوان سیستم تحت آزمایش استفاده میکنند.
- مثال: تست رفتار رابط کاربری برای تأیید تغییرات پیکربندی در یک گوشی تاشو، تستهای محلیسازی و دسترسیپذیری
- یک تست کاندید انتشار، عملکرد یک نسخه آزمایشی را تأیید میکند. آنها مشابه تستهای برنامه هستند، با این تفاوت که فایل باینری برنامه کوچکسازی و بهینهسازی شده است. اینها تستهای یکپارچهسازی سرتاسری بزرگی هستند که در محیطی تا حد امکان نزدیک به محیط تولید اجرا میشوند، بدون اینکه برنامه در معرض حسابهای کاربری عمومی یا بکاندهای عمومی قرار گیرد.
- مثال: سفرهای حیاتی کاربر، تست عملکرد
این دستهبندی، وفاداری، زمان، دامنه و سطح جداسازی را در نظر میگیرد. میتوانید انواع مختلفی از تستها را در چندین لایه داشته باشید. به عنوان مثال، لایه تست برنامه میتواند شامل تستهای رفتار، اسکرینشات و عملکرد باشد.
محدوده | دسترسی به شبکه | اعدام | نوع ساخت | چرخه حیات | |
|---|---|---|---|---|---|
واحد | یک متد یا کلاس با حداقل وابستگی. | خیر | محلی | قابل اشکالزدایی | پیش ادغام |
کامپوننت | سطح ماژول یا کامپوننت چند کلاس با هم | خیر | محلی | قابل اشکالزدایی | پیش ادغام |
ویژگی | سطح ویژگی ادغام با کامپوننتهای متعلق به تیمهای دیگر | مسخره شده | محلی | قابل اشکالزدایی | پیش ادغام |
کاربرد | سطح برنامه ادغام با ویژگیها و/یا سرویسهای متعلق به تیمهای دیگر | مسخره شده | شبیهساز | قابل اشکالزدایی | پیش ادغام |
کاندیدای انتشار | سطح برنامه ادغام با ویژگیها و/یا سرویسهای متعلق به تیمهای دیگر | سرور پرود | شبیهساز | نسخه آزمایشی کوچک شده | پس از ادغام |
دسته بندی آزمون را تعیین کنید
به عنوان یک قاعده کلی، باید پایینترین لایه هرم را در نظر بگیرید که میتواند سطح مناسبی از بازخورد را به تیم ارائه دهد.
برای مثال، نحوه آزمایش پیادهسازی این ویژگی را در نظر بگیرید: رابط کاربری یک جریان ورود به سیستم. بسته به آنچه که برای آزمایش نیاز دارید، دستههای مختلفی را انتخاب خواهید کرد:
موضوع تحت آزمایش | شرح آنچه آزمایش میشود | دسته بندی تست | نوع آزمون نمونه |
|---|---|---|---|
منطق اعتبارسنجی فرم | کلاسی که آدرس ایمیل را با یک عبارت منظم اعتبارسنجی میکند و بررسی میکند که فیلد رمز عبور وارد شده است یا خیر. این کلاس هیچ وابستگی ندارد. | تستهای واحد | |
رفتار رابط کاربری فرم ورود | فرمی با دکمهای که فقط پس از اعتبارسنجی فرم فعال میشود | تستهای اجزا | تست رفتار رابط کاربری در حال اجرا روی Roboelectric |
ظاهر رابط کاربری فرم ورود | فرمی که از مشخصات UX پیروی میکند | تستهای اجزا | |
ادغام با مدیر احراز هویت | رابط کاربری که اعتبارنامهها را به یک مدیر احراز هویت ارسال میکند و پاسخهایی را دریافت میکند که میتوانند حاوی خطاهای مختلفی باشند. | تستهای ویژگی | |
گفتگوی ورود به سیستم | صفحهای که فرم ورود را هنگام فشردن دکمه ورود نشان میدهد. | تستهای کاربردی | تست رفتار رابط کاربری در حال اجرا روی Roboelectric |
سفر حیاتی کاربر: ورود به سیستم | یک جریان ورود کامل با استفاده از یک حساب آزمایشی در مقابل یک سرور مرحلهبندی | کاندیدای انتشار | تست رفتار رابط کاربری Compose از ابتدا تا انتها که روی دستگاه اجرا میشود |
در برخی موارد، اینکه چیزی به یک دسته تعلق دارد یا دسته دیگر میتواند سلیقهای باشد. دلایل دیگری نیز میتواند وجود داشته باشد که چرا یک آزمایش به دسته بالاتر یا پایینتر منتقل میشود، مانند هزینه زیرساخت، عدم قطعیت و زمان طولانی آزمایش.
توجه داشته باشید که دستهی آزمون، نوع آزمون را تعیین نمیکند و لازم نیست همهی ویژگیها در هر دسته آزمایش شوند.
تست دستی نیز میتواند بخشی از استراتژی تست شما باشد. معمولاً تیمهای تضمین کیفیت، تستهای کاندیدای انتشار را انجام میدهند، اما میتوانند در مراحل دیگر نیز دخیل باشند. به عنوان مثال، تست اکتشافی برای یافتن باگها در یک ویژگی بدون اسکریپت.
زیرساخت تست
یک استراتژی تست باید توسط زیرساختها و ابزارهایی پشتیبانی شود تا به توسعهدهندگان کمک کند تا بهطور مداوم تستهای خود را اجرا کنند و قوانینی را اجرا کنند که تضمین میکند همه تستها با موفقیت انجام شوند.
شما میتوانید تستها را بر اساس محدوده دستهبندی کنید تا مشخص شود چه زمانی و کجا باید هر تست را اجرا کنید. به عنوان مثال، از مدل ۵ لایهای پیروی کنید:
دسته بندی | محیط (کجا) | محرک (چه زمانی) |
|---|---|---|
واحد | [محلی][4] | هر کامیت |
کامپوننت | محلی | هر کامیت |
ویژگی | محلی و شبیهسازها | پیش ادغام، قبل از ادغام یا ارسال تغییر |
کاربرد | محلی، شبیهساز، ۱ گوشی، ۱ تاشو | پس از ادغام، پس از ادغام یا ارسال تغییر |
کاندیدای انتشار | ۸ گوشی مختلف، ۱ گوشی تاشو، ۱ تبلت | پیش از انتشار |
- تستهای واحد و اجزا روی سیستم ادغام مداوم برای هر کامیت جدید اجرا میشوند، اما فقط برای ماژولهای آسیبدیده.
- تمام تستهای واحد، کامپوننت و ویژگیها قبل از ادغام یا ارسال تغییر اجرا میشوند.
- تستهای برنامه پس از ادغام اجرا میشوند.
- آزمایشهای کاندیدای انتشار ، هر شب روی تلفن، تبلت تاشو و تبلت اجرا میشوند.
- قبل از انتشار، تستهای کاندید انتشار روی تعداد زیادی دستگاه اجرا میشوند.
این قوانین میتوانند با گذشت زمان و زمانی که تعداد تستها بر بهرهوری تأثیر میگذارد، تغییر کنند. برای مثال، اگر تستها را به یک ریتم شبانه منتقل کنید، ممکن است زمان ساخت و تست CI را کاهش دهید، اما میتوانید حلقه بازخورد را نیز طولانیتر کنید.