استراتژی های تست

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

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

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

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

هرم آزمایش

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

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

اکثر برنامه ها باید تست های کوچک و نسبتا کمی تست های بزرگ داشته باشند. توزیع آزمون ها در هر دسته باید یک هرم را تشکیل دهد که تعداد تست های کوچک بیشتر پایه را تشکیل می دهند و تست های بزرگ کم تعداد نوک را تشکیل می دهند.

هزینه یک باگ را به حداقل برسانید

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

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

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

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

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

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

یک استراتژی تست مقیاس پذیر

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

• تست های واحد
• تست های یکپارچه سازی
• تست های پایان به انتها

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

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

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

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

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

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

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

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

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

زیرساخت تست

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

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

• تست‌های واحد و کامپوننت برای هر کامیت جدید، اما فقط برای ماژول‌های آسیب‌دیده، روی سیستم یکپارچه‌سازی مداوم اجرا می‌شوند.
• همه تست‌های واحد، مؤلفه و ویژگی قبل از ادغام یا ارسال تغییر اجرا می‌شوند.
• تست های برنامه پس از ادغام اجرا می شوند.
• تست‌های Release Candidate هر شب روی تلفن، تاشو و تبلت اجرا می‌شوند.
• قبل از انتشار، تست‌های Release Candidate روی تعداد زیادی دستگاه اجرا می‌شوند.

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