استراتژی‌های آزمایش

آزمایش خودکار به روش‌های مختلفی به شما کمک می‌کند کیفیت برنامه را بهبود دهید. برای مثال، این کار به شما کمک می‌کند تا راستی‌آزمایی انجام دهید، پسرفت‌ها را شناسایی کنید، و سازگاری را تأیید کنید. یک استراتژی آزمایش خوب به شما امکان می‌دهد از آزمایش خودکارشده بهره ببرید و روی مزیت مهمی تمرکز کنید: بهره‌وری توسعه‌دهنده.

تیم‌ها وقتی از رویکردی نظام‌مند برای آزمایش همراه با بهبود زیرساخت استفاده می‌کنند، به سطوح بالاتری از بهره‌وری دست می‌یابند. انجام این کار بازخورد به‌موقعی درباره نحوه عملکرد کد ارائه می‌دهد. یک استراتژی خوب آزمایش موارد زیر را انجام می‌دهد:

• مشکلات را در اسرع وقت شناسایی می‌کند.
• به‌سرعت اجرا می‌شود.
• وقتی چیزی نیاز به اصلاح داشته باشد، نشانه‌های واضحی ارائه می‌دهد.

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

android skills add testing-setup

هرم آزمایش

می‌توانید آزمایش‌ها را در برنامه‌های مدرن براساس اندازه دسته‌بندی کنید. آزمایش‌های کوچک فقط روی بخش کوچکی از کد تمرکز می‌کنند و آن‌ها را سریع و قابل‌اعتماد می‌سازند. آزمایش‌های بزرگ دامنه وسیعی دارند و نیازمند تنظیمات پیچیده‌تری هستند که نگهداری از آن‌ها دشوار است. بااین‌حال، آزمایش‌های بزرگ‌تر وفاداری بیشتری دارند* و می‌توانند مشکلات بسیار بیشتری را در یک مرحله کشف کنند.

*وفاداری به شباهت محیط زمان اجرای آزمایش با محیط تولید اشاره دارد.

بیشتر برنامه‌ها باید آزمایش‌های کوچک زیادی و آزمایش‌های بزرگ نسبتاً کمی داشته باشند. توزیع آزمایش‌ها در هر دسته باید به‌صورت هرم باشد، به‌طوری‌که آزمایش‌های کوچک‌تر و متعددتر پایه هرم را تشکیل دهند و آزمایش‌های بزرگ‌تر و کمتر نوک هرم را تشکیل دهند.

کمینه کردن هزینه اشکال

یک استراتژی آزمایش خوب بهره‌وری توسعه‌دهنده را به حداکثر می‌رساند و درعین‌حال هزینه یافتن اشکالات را به حداقل می‌رساند.

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

این یعنی پیش‌از ادغام، آزمایش‌های بسیار کمی اجرا می‌شود. اگر اشکالی وجود داشته باشد، آزمایش‌ها ممکن است تا زمانی که آزمایش‌های سرتاسر شبانه یا هفتگی اجرا شوند، آن را پیدا نکنند.

مهم است که پیامدهای این موضوع را برای هزینه شناسایی و رفع اشکالات درنظر بگیرید و اینکه چرا مهم است تلاش‌های آزمایشی خود را به سمت آزمایش‌های کوچک‌تر و مکررتر سوق دهید:

• وقتی اشکال توسط آزمون واحد شناسایی می‌شود، معمولاً در چند دقیقه برطرف می‌شود، بنابراین هزینه آن پایین است.
• آزمایش سرتاسر ممکن است روزها طول بکشد تا همان اشکال را پیدا کند. این کار می‌تواند چندین عضو تیم را درگیر کند و بهره‌وری کلی را کاهش دهد و احتمالاً انتشار را به‌تأخیر بیندازد. هزینه این اشکال بیشتر است.

بااین‌حال، یک استراتژی آزمایش ناکارآمد بهتر از نداشتن استراتژی است. وقتی اشکالی به مرحله تولید می‌رسد، رفع آن زمان زیادی طول می‌کشد تا در دستگاه‌های کاربر اعمال شود، گاهی اوقات هفته‌ها، بنابراین حلقه بازخورد طولانی‌ترین و گران‌ترین است.

راهبرد آزمایش مقیاس‌پذیر

هرم آزمایش به‌طور سنتی به ۳ دسته تقسیم می‌شود:

• آزمون‌های واحد
• آزمایش‌های یکپارچه‌سازی
• آزمایش‌های سرتاسر.

بااین‌حال، این مفاهیم تعاریف دقیقی ندارند، بنابراین تیم‌ها ممکن است بخواهند دسته‌های خود را به‌طور متفاوتی تعریف کنند، برای مثال بااستفاده از ۵ لایه:

• آزمایش واحد در ماشین میزبان اجرا می‌شود و واحد عملکردی منطق را بدون وابستگی به چارچوب Android درستی‌سنجی می‌کند.
  • مثال: درستی‌سنجی خطاهای یک واحدی در یک تابع ریاضی.
• آزمایش جزء عملکرد یا ظاهر یک واحد یا جزء را به‌طور مستقل از سایر اجزای سیستم تأیید می‌کند. برخلاف تست‌های واحد، سطح تست مؤلفه به انتزاع‌های بالاتر از روش‌ها و کلاس‌های فردی گسترش می‌یابد.
  • مثال: آزمایش نماگرفت برای دکمه سفارشی
• آزمایش ویژگی تعامل دو یا چند مؤلفه یا واحد مستقل را تأیید می‌کند. آزمایش‌های ویژگی بزرگ‌تر و پیچیده‌تر هستند و معمولاً در سطح ویژگی عمل می‌کنند.
  • مثال: آزمایش‌های رفتار واسط کاربر که مدیریت وضعیت در صفحه‌نمایش را درستی‌سنجی می‌کند
• آزمایش برنامه عملکرد کل برنامه را در قالب یک دودویی قابل استقرار تأیید می‌کند. این‌ها آزمایش‌های یکپارچه‌سازی بزرگی هستند که از یک باینری اشکال‌زدایی‌پذیر، مثل ساخت توسعه‌دهنده که می‌تواند شامل قلاب‌های آزمایش باشد، به‌عنوان سیستم تحت آزمایش استفاده می‌کنند.
  • مثال: آزمایش رفتار رابط کاربری برای تأیید تغییرات پیکربندی در دستگاه تاشو، آزمایش‌های بومی‌سازی و دسترس‌پذیری
• آزمایش نامزد انتشار عملکرد ساخت انتشار را تأیید می‌کند. این آزمایش‌ها شبیه آزمایش‌های برنامه هستند، با این تفاوت که باینری برنامه کوچک و بهینه‌سازی‌شده است. این‌ها آزمایش‌های یکپارچه‌سازی سرتاسری بزرگی هستند که در محیطی تا حد امکان نزدیک به محیط تولید اجرا می‌شوند بدون اینکه برنامه را درمعرض حساب‌های کاربری عمومی یا زیرینه‌های عمومی قرار دهند.
  • مثال: سفرهای کاربر حیاتی، آزمایش عملکرد

این دسته‌بندی وفاداری، زمان، دامنه و سطح جداسازی را در نظر می‌گیرد. می‌توانید انواع مختلفی از آزمایش‌ها را در چندین لایه داشته باشید. برای مثال، لایه «آزمایش برنامه» می‌تواند شامل آزمایش‌های عملکرد، نماگرفت، و رفتار باشد.

دسته آزمایش را تعیین کنید

به‌عنوان یک قاعده کلی، باید پایین‌ترین لایه هرم را درنظر بگیرید که می‌تواند سطح مناسبی از بازخورد را به تیم ارائه دهد.

برای مثال، درنظر بگیرید که چگونه پیاده‌سازی این ویژگی را آزمایش کنید: واسط کاربر جریان ورود به سیستم. بسته به اینکه چه چیزی را می‌خواهید آزمایش کنید، دسته‌های مختلفی را انتخاب خواهید کرد:

در برخی موارد، اینکه چیزی به یک دسته تعلق دارد یا به دسته دیگر می‌تواند ذهنی باشد. دلایل دیگری نیز وجود دارد که چرا یک آزمایش به بالا یا پایین منتقل می‌شود، مانند هزینه زیرساخت، ناپایداری، و زمان طولانی آزمایش.

توجه داشته باشید که دسته آزمایش نوع آزمایش را تعیین نمی‌کند و همه ویژگی‌ها لازم نیست در هر دسته آزمایش شوند.

آزمایش دستی نیز می‌تواند بخشی از استراتژی آزمایش شما باشد. معمولاً تیم‌های QA آزمایش‌های «نامزد انتشار» را انجام می‌دهند اما می‌توانند در مراحل دیگر نیز مشارکت داشته باشند. برای مثال، آزمایش اکتشافی برای اشکالات یک ویژگی بدون دستورگان.

زیرساخت آزمایشی

استراتژی آزمایش باید با زیرساخت و ابزارهایی پشتیبانی شود که به توسعه‌دهندگان کمک کند آزمایش‌هایشان را به‌طور مداوم اجرا کنند و قوانینی را که تضمین می‌کند همه آزمایش‌ها موفق باشند اعمال کنند.

می‌توانید آزمایش‌ها را براساس محدوده دسته‌بندی کنید تا مشخص کنید کدام آزمایش‌ها در چه زمان و مکانی اجرا شوند. برای مثال، با پیروی از مدل ۵ لایه:

• آزمون‌های واحد و جزء برای هر تعهد جدید در سیستم ادغام مداوم اجرا می‌شوند، اما فقط برای واحدهای تحت‌تأثیر.
• همه آزمایش‌های واحد، عنصر، و ویژگی قبل‌از ادغام یا ارسال تغییر اجرا می‌شوند.
• آزمایش‌های برنامه پس‌از ادغام اجرا می‌شود.
• آزمایش‌های نامزد انتشار هر شب روی تلفن، دستگاه تاشو، و رایانه لوحی اجرا می‌شود.
• پیش‌از انتشار، آزمایش‌های نامزد انتشار روی تعداد زیادی دستگاه اجرا می‌شود.

این قوانین ممکن است با گذشت زمان و زمانی که تعداد آزمایش‌ها بر بهره‌وری تأثیر می‌گذارد تغییر کنند. برای مثال، اگر آزمایش‌ها را به آهنگ شبانه منتقل کنید، ممکن است زمان‌های ساخت و آزمایش CI را کاهش دهید، اما می‌توانید حلقه بازخورد را نیز طولانی‌تر کنید.