در زیر برخی از اشکال معمول اتوماسیون وجود دارد که ممکن است بخواهید در سیستم CI خود استفاده کنید.
مشاغل اساسی
ساخت: با ساختن یک پروژه از ابتدا، مطمئن می شوید که تغییرات جدید به درستی کامپایل شده و همه کتابخانه ها و ابزارها با یکدیگر سازگار هستند.
بررسی پرز یا سبک: این یک مرحله اختیاری است اما توصیه می شود. وقتی قوانین سبک را اجرا می کنید و تجزیه و تحلیل استاتیک انجام می دهید، بررسی کد می تواند مختصرتر و متمرکزتر باشد.
تست های محلی یا سمت میزبان : آنها بر روی ماشین محلی که ساخت را انجام می دهد اجرا می شوند. در اندروید این معمولاً JVM است، بنابراین سریع و قابل اعتماد هستند. آنها شامل تست های روبولکتریک نیز می شوند.
تست های ابزاری
آزمایش‌هایی که بر روی شبیه‌سازها یا دستگاه‌های فیزیکی اجرا می‌شوند، نیاز به آماده‌سازی، انتظار برای راه‌اندازی یا اتصال دستگاه‌ها و سایر عملیات‌هایی دارند که به پیچیدگی اضافه می‌کنند.
چندین گزینه برای اجرای تست های ابزاری بر روی CI وجود دارد:
- از دستگاه‌های مدیریت‌شده Gradle می‌توان برای تعریف دستگاه‌های مورد استفاده استفاده کرد (به‌عنوان مثال «شبیه‌ساز Pixel 2 در API 27») و تأمین دستگاه را مدیریت می‌کند.
- اکثر سیستم‌های CI با یک پلاگین شخص ثالث (که «عمل»، «ادغام» یا «گام» نیز نامیده می‌شود) برای مدیریت شبیه‌سازهای اندروید ارائه می‌شوند.
- آزمایش‌های ابزاردار را به مزرعه‌ای مانند Firebase Test Lab واگذار کنید. مزارع دستگاه به دلیل قابلیت اطمینان بالا مورد استفاده قرار می گیرند و می توانند بر روی شبیه سازها یا دستگاه های فیزیکی اجرا شوند.
آزمون های رگرسیون عملکردی
برای نظارت بر عملکرد برنامه توصیه می کنیم از کتابخانه های معیار استفاده کنید. اتوماسیون تست‌های عملکرد در طول توسعه نیازمند دستگاه‌های فیزیکی برای اطمینان از نتایج آزمایش سازگار و واقعی است.
اجرای بنچمارک‌ها می‌تواند زمان زیادی طول بکشد، به‌خصوص زمانی که پوشش بالایی از کد و سفرهای کاربر دارید که در حال محک زدن هستید. به جای اجرای همه معیارها برای هر ویژگی یا تعهد ادغام شده، اجرای آنها را به عنوان بخشی از یک ساخت تعمیر و نگهداری برنامه ریزی شده منظم، مانند ساخت شبانه در نظر بگیرید.
نظارت بر عملکرد
شما می توانید رگرسیون های عملکرد را با استفاده از برازش گام نظارت کنید. Step fitting یک پنجره متحرک از نتایج ساخت قبلی را تعریف می کند که شما آن را با ساخت فعلی مقایسه می کنید. این رویکرد چندین نتیجه معیار را در یک متریک رگرسیون خاص ترکیب می کند. برای کاهش نویز در طول تست رگرسیون می توانید از فیتینگ پله ای استفاده کنید.
این باعث کاهش وقوع مثبت‌های کاذب می‌شود که می‌تواند زمانی رخ دهد که زمان‌های بنچمارک برای یک ساخت واحد آهسته باشد و سپس دوباره عادی شود.
بررسی رگرسیون پوشش تست
پوشش تست معیاری است که می تواند به شما و تیمتان کمک کند تصمیم بگیرید آیا آزمایش ها به اندازه کافی تغییر را پوشش می دهند یا خیر. با این حال، این نباید تنها شاخص باشد. معمول است که یک بررسی رگرسیونی تنظیم کنید که با شکست مواجه شود یا زمانی که پوشش نسبت به شاخه پایه کاهش می یابد، هشداری نشان می دهد.
،در زیر برخی از اشکال معمول اتوماسیون وجود دارد که ممکن است بخواهید در سیستم CI خود استفاده کنید.
مشاغل اساسی
ساخت: با ساختن یک پروژه از ابتدا، مطمئن می شوید که تغییرات جدید به درستی کامپایل شده و همه کتابخانه ها و ابزارها با یکدیگر سازگار هستند.
بررسی پرز یا سبک: این یک مرحله اختیاری است اما توصیه می شود. وقتی قوانین سبک را اجرا می کنید و تجزیه و تحلیل استاتیک انجام می دهید، بررسی کد می تواند مختصرتر و متمرکزتر باشد.
تست های محلی یا سمت میزبان : آنها بر روی ماشین محلی که ساخت را انجام می دهد اجرا می شوند. در اندروید این معمولاً JVM است، بنابراین سریع و قابل اعتماد هستند. آنها شامل تست های روبولکتریک نیز می شوند.
تست های ابزاری
آزمایش‌هایی که بر روی شبیه‌سازها یا دستگاه‌های فیزیکی اجرا می‌شوند، نیاز به آماده‌سازی، انتظار برای راه‌اندازی یا اتصال دستگاه‌ها و سایر عملیات‌هایی دارند که به پیچیدگی اضافه می‌کنند.
چندین گزینه برای اجرای تست های ابزاری بر روی CI وجود دارد:
- از دستگاه‌های مدیریت‌شده Gradle می‌توان برای تعریف دستگاه‌های مورد استفاده استفاده کرد (به‌عنوان مثال «شبیه‌ساز Pixel 2 در API 27») و تأمین دستگاه را مدیریت می‌کند.
- اکثر سیستم‌های CI با یک پلاگین شخص ثالث (که «عمل»، «ادغام» یا «گام» نیز نامیده می‌شود) برای مدیریت شبیه‌سازهای اندروید ارائه می‌شوند.
- آزمایش‌های ابزاردار را به مزرعه‌ای مانند Firebase Test Lab واگذار کنید. مزارع دستگاه به دلیل قابلیت اطمینان بالا مورد استفاده قرار می گیرند و می توانند بر روی شبیه سازها یا دستگاه های فیزیکی اجرا شوند.
آزمون های رگرسیون عملکردی
برای نظارت بر عملکرد برنامه توصیه می کنیم از کتابخانه های معیار استفاده کنید. اتوماسیون تست‌های عملکرد در طول توسعه نیازمند دستگاه‌های فیزیکی برای اطمینان از نتایج آزمایش سازگار و واقعی است.
اجرای بنچمارک‌ها می‌تواند زمان زیادی طول بکشد، به‌خصوص زمانی که پوشش بالایی از کد و سفرهای کاربر دارید که در حال محک زدن هستید. به جای اجرای همه معیارها برای هر ویژگی یا تعهد ادغام شده، اجرای آنها را به عنوان بخشی از یک ساخت تعمیر و نگهداری برنامه ریزی شده منظم، مانند ساخت شبانه در نظر بگیرید.
نظارت بر عملکرد
شما می توانید رگرسیون های عملکرد را با استفاده از برازش گام نظارت کنید. Step fitting یک پنجره متحرک از نتایج ساخت قبلی را تعریف می کند که شما آن را با ساخت فعلی مقایسه می کنید. این رویکرد چندین نتیجه معیار را در یک متریک رگرسیون خاص ترکیب می کند. برای کاهش نویز در طول تست رگرسیون می توانید از فیتینگ پله ای استفاده کنید.
این باعث کاهش وقوع مثبت‌های کاذب می‌شود که می‌تواند زمانی رخ دهد که زمان‌های بنچمارک برای یک ساخت واحد آهسته باشد و سپس دوباره عادی شود.
بررسی رگرسیون پوشش تست
پوشش تست معیاری است که می تواند به شما و تیمتان کمک کند تصمیم بگیرید آیا آزمایش ها به اندازه کافی تغییر را پوشش می دهند یا خیر. با این حال، این نباید تنها شاخص باشد. معمول است که یک بررسی رگرسیونی تنظیم کنید که با شکست مواجه شود یا زمانی که پوشش نسبت به شاخه پایه کاهش می یابد، هشداری نشان می دهد.