کشف کنید که چگونه انواع مختلف آزمایش را با یک استراتژی معقول و متناسب با پروژه شما ترکیب کنید.
خوش برگشتی! مقاله آخر زمینه های زیادی را در مورد نحوه نزدیک شدن به انواع مختلف تست و محتوای آنها بیان کرد و تعاریف نوع تست را روشن کرد. این تصویر میم کوچک را به خاطر دارید؟ ممکن است از خود پرسیده باشید که چگونه همه انواع تست هایی که در مورد آنها آموخته اید می توانند با هم کار کنند.
در مرحله بعد، دقیقاً آن را یاد خواهید گرفت. این مقاله مقدمه ای در مورد نحوه ترکیب این انواع آزمایش در استراتژی های معقول و انتخاب یکی از آنها که با پروژه شما مطابقت دارد، ارائه می دهد.
شما می توانید استراتژی ها را با تعدادی از اشکال مقایسه کنید تا معنای آنها را بهتر درک کنید. در اینجا لیستی از استراتژی ها با اندازه و دامنه توسعه مربوطه آمده است.
بیایید نگاهی دقیق تر به استراتژی ها بیندازیم و معنای پشت نام آنها را بیاموزیم.
تعیین اهداف تست: با این تست ها به چه چیزی می خواهید برسید؟
قبل از شروع ساختن یک استراتژی خوب، هدف آزمایشی خود را مشخص کنید. چه زمانی فکر می کنید که درخواست شما به اندازه کافی آزمایش شده است؟
دستیابی به پوشش تست بالا اغلب به عنوان هدف نهایی برای توسعه دهندگان در هنگام آزمایش در نظر گرفته می شود. اما آیا همیشه بهترین رویکرد است؟ ممکن است هنگام تصمیم گیری در مورد یک استراتژی آزمایشی یک عامل مهم دیگر را در نظر بگیرید - پاسخگویی به نیازهای کاربران شما.
به عنوان یک توسعه دهنده، شما همچنین از بسیاری از برنامه ها و دستگاه های دیگر استفاده می کنید. از این نظر، شما کاربری هستید که برای "فقط کار" به همه این سیستم ها متکی است. به نوبه خود، شما به توسعه دهندگان بی شماری تکیه می کنید تا تمام تلاش خود را برای کارکرد برنامه ها و دستگاه های خود انجام دهند. برای برگرداندن این موضوع، به عنوان یک توسعه دهنده، شما نیز تلاش می کنید تا به این اعتماد عمل کنید. بنابراین اولین هدف شما باید همیشه ارسال نرم افزارهای کارآمد و خدمات رسانی به کاربران باشد. این به تست هایی که برای اطمینان از کیفیت برنامه می نویسید نیز گسترش می یابد. Kent C. Dodds در پست Static vs Unit vs Integration vs E2E Testing for Frontend Apps آن را به خوبی خلاصه می کند:
هرچه تست‌های شما بیشتر شبیه روش استفاده از نرم‌افزار شما باشد، اعتماد به نفس بیشتری می‌توانند به شما بدهند.
توسط کنت سی دادز
کنت آن را به عنوان کسب اعتماد به نفس در آزمون ها توصیف می کند. هرچه با انتخاب نوع تست مناسب به کاربران نزدیک‌تر شوید، بیشتر می‌توانید به تست‌های خود برای داشتن نتایج معتبر اعتماد کنید. به عبارت دیگر، هر چه از هرم بالاتر بروید، اعتماد به نفس بیشتری خواهید داشت. اما صبر کنید، هرم چیست؟
تعیین استراتژی های آزمون: نحوه انتخاب استراتژی تست
به عنوان اولین قدم، تعیین کنید که کدام بخش از الزامات را باید بررسی کنید تا مطمئن شوید که برآورده شده اند. دریابید که از چه نوع تست هایی استفاده کنید و در چه سطحی از جزئیات می توانید به بیشترین اطمینان دست پیدا کنید و در عین حال ساختار هزینه کارآمد را حفظ کنید. بسیاری از توسعه دهندگان با استفاده از قیاس به این موضوع می پردازند. در اینجا رایج ترین آنها وجود دارد که با کلاسیک شناخته شده شروع می شود.
کلاسیک: هرم آزمایشی
به محض اینکه شروع به جستجوی استراتژی های تست کنید، احتمالاً با هرم اتوماسیون تست به عنوان اولین قیاس مواجه خواهید شد. مایک کوهن این مفهوم را در کتاب خود با عنوان "موفقیت با چابک" معرفی کرد. بعدها، مارتین فاولر در مقاله هرم تست عملی خود این مفهوم را گسترش داد. شما می توانید هرم را به صورت بصری به صورت زیر نشان دهید:
همانطور که در این نقشه نشان داده شده است، هرم آزمایشی از سه لایه تشکیل شده است:
واحد . این تست ها را در لایه پایه هرم پیدا می کنید زیرا اجرا سریع و نگهداری آن ها ساده است. آنها منزوی هستند و جزئی ترین واحدهای آزمایشی را هدف قرار می دهند. به عنوان مثال، یک آزمایش واحد معمولی برای یک محصول بسیار کوچک را ببینید.
ادغام . این تست ها در وسط هرم قرار دارند، زیرا سرعت اجرای قابل قبولی دارند اما شما را بیشتر از تست های واحد به کاربر نزدیک می کنند. نمونه ای از تست یکپارچه سازی، تست API است. همچنین می توانید تست های جزء را به این نوع طبقه بندی کنید.
تست های E2E (که به آن تست های رابط کاربری نیز می گویند). این تست ها یک کاربر واقعی و تعامل آنها را شبیه سازی می کنند. چنین آزمایشاتی به زمان بیشتری برای اجرا نیاز دارند و بنابراین هزینه بیشتری دارند. آنها در بالای هرم هستند.
اعتماد در مقابل منابع
همانطور که قبلا به اختصار توضیح داده شد، ترتیب لایه ها تصادفی نیست. آنها اولویت ها و هزینه های مربوطه را نشان می دهند. این به شما تصویر واضحی از تعداد تست هایی که باید برای هر لایه بنویسید به شما می دهد. شما قبلاً این را در تعریف انواع تست مشاهده کرده اید.
از آنجایی که تست‌های E2E نزدیک‌ترین تست‌ها به کاربران شما هستند، بیشترین اطمینان را به شما می‌دهند که برنامه شما طبق برنامه کار می‌کند. با این حال، آنها به یک پشته برنامه کامل و یک کاربر شبیه سازی شده نیاز دارند، بنابراین، آنها همچنین به طور بالقوه گران ترین هستند. بنابراین اعتماد به نفس در رقابت مستقیم با منابعی است که برای اجرای تست ها نیاز دارید.
هرم سعی می کند این مشکل را با تمرکز بیشتر شما بر روی تست های واحد و اولویت بندی دقیق موارد تحت پوشش تست های E2E حل کند. به عنوان مثال، مهم ترین سفرهای کاربر شما یا مکان هایی که آسیب پذیرترین نقاط در برابر نقص هستند. همانطور که مارتین فاولر تاکید می کند، دو نکته ضروری در هرم کوهن به شرح زیر است:
- تست هایی با دانه بندی های مختلف بنویسید.
- هر چه سطح بالاتری کسب کنید، آزمون های کمتری باید داشته باشید.
هرم تکامل یافت! انطباق اهرام آزمایشی
چندین سال است که بحث ها حول محور هرم می چرخد. به نظر می رسد هرم استراتژی های آزمایش را بیش از حد ساده می کند، بسیاری از انواع آزمایش را کنار گذاشته و دیگر با همه پروژه های دنیای واقعی سازگار نیست. بنابراین، ممکن است گمراه کننده باشد. آیا هرم از شکل افتاده است؟ گیرمو راخ در مورد آن نظر دارد:
تست ها را بنویسید. نه خیلی زیاد. بیشتر ادغام.
نوشته گیلرمو راخ
این یکی از متداول ترین نقل قول ها در مورد این موضوع است، بنابراین اجازه دهید آن را تجزیه کنیم:
- "نوشتن تست". نه تنها به این دلیل که اعتماد ایجاد می کند، بلکه به این دلیل که در زمان نگهداری صرفه جویی می کند.
- "نه خیلی زیاد". پوشش 100٪ همیشه خوب نیست زیرا در این صورت تست شما اولویت بندی نمی شود و تعمیر و نگهداری زیادی انجام می شود.
- "بیشتر ادغام". در اینجا مجدداً تأکید بر تست‌های یکپارچه‌سازی است: آنها بیشترین ارزش تجاری را با ارائه سطح اطمینان بالای روزانه به شما در عین حفظ زمان اجرای معقول دارند.
این باعث می شود دوباره درباره هرم تست فکر کنید و تمرکز خود را به تست یکپارچه سازی معطوف کنید. در چند سال گذشته، انطباق های زیادی پیشنهاد شده است، بنابراین بیایید به رایج ترین آنها نگاه کنیم.
الماس تست
انطباق اول تاکید بیش از حد بر تست واحد را حذف می کند، همانطور که در هرم آزمایش دیده می شود. تصور کنید که در تست های واحد به پوشش 100% رسیده اید. با این حال، دفعه بعد که شما refactor را انجام می دهید، باید بسیاری از این تست های واحد را به روز کنید و ممکن است وسوسه شوید که از آنها صرف نظر کنید. بنابراین آنها فرسایش می یابند.
در نتیجه، و همراه با تمرکز بیشتر روی تست یکپارچه سازی، شکل زیر ممکن است ایجاد شود:
یک هرم به الماس تبدیل می شود. شما می توانید سه لایه قبلی را مشاهده کنید، اما با اندازه های مختلف، و لایه واحد بریده شده است:
- واحد . تست های واحد را به روشی که قبلا تعریف کرده اید بنویسید. با این حال، از آنجایی که آنها تمایل به فرسایش دارند، اولویت بندی می کنند و فقط بحرانی ترین موارد را پوشش می دهند.
- ادغام . تست‌های یکپارچه‌سازی که می‌شناسید، آزمایش ترکیب واحدهای منفرد.
- E2E . این لایه تست های رابط کاربری مشابه هرم تست را انجام می دهد. مراقب باشید که تست های E2E را فقط برای بحرانی ترین موارد تست بنویسید.
تست لانه زنبوری
اقتباس دیگری نیز وجود دارد که توسط Spotify معرفی شده است، که مشابه الماس آزمایشی است اما بیشتر برای سیستم های نرم افزاری مبتنی بر میکروسرویس ها تخصصی است. لانه زنبوری آزمایشی یک قیاس بصری دیگر برای دانه بندی، دامنه و تعداد تست هایی است که برای یک سیستم نرم افزاری مبتنی بر میکروسرویس نوشته می شود. به دلیل اندازه کوچک آنها، بیشترین پیچیدگی در یک میکروسرویس در خود سرویس نیست، بلکه در نحوه تعامل آن با دیگران است. بنابراین یک استراتژی تست برای یک میکروسرویس باید در درجه اول بر روی تست های یکپارچه سازی تمرکز کند.
این شکل ما را به یاد لانه زنبوری می اندازد، بنابراین نام آن. دارای لایه های زیر است:
- تست های یکپارچه مقاله Spotify از نقل قولی از JB Rainsberger برای تعریف این لایه استفاده می کند: "آزمایشی که بر اساس درستی سیستم دیگری موفق می شود یا شکست می خورد." چنین تست‌هایی وابستگی‌های خارجی دارند که باید در نظر بگیرید، و برعکس، سیستم شما ممکن است وابستگی باشد که سیستم‌های دیگر را از بین ببرد. مشابه تست های E2E در سایر قیاس ها، از این تست ها فقط برای ضروری ترین موارد استفاده کنید.
- تست های یکپارچه سازی مشابه سایر سازگاری ها، باید روی این لایه تمرکز کنید. این شامل تست هایی است که صحت خدمات شما را به شکلی مجزاتر تأیید می کند، اما همچنان در ترکیب با سایر خدمات. این بدان معناست که تست‌ها شامل برخی سیستم‌های دیگر نیز می‌شوند و بر روی نقاط تعامل تمرکز می‌کنند، به عنوان مثال، از طریق تست‌های API.
- تست های مربوط به جزئیات پیاده سازی این تست‌ها شبیه تست‌های واحد هستند - تست‌هایی که بر روی بخش‌هایی از کد متمرکز می‌شوند که به طور طبیعی ایزوله هستند و بنابراین پیچیدگی داخلی خود را دارند.
اگر می‌خواهید درباره این استراتژی تست اطلاعات بیشتری کسب کنید، به پست مقایسه هرم آزمایشی با لانه زنبوری توسط مارتین فاولر و مقاله اصلی Spotify مراجعه کنید.
جایزه تست
در حال حاضر می توانید تمرکز مکرر روی تست های یکپارچه سازی را مشاهده کنید. با این حال، نوع دیگری که در مقاله قبلی با آن برخورد کردید، آزمایش در تئوری نیست، اما همچنان جنبه مهمی است که باید در استراتژی تست در نظر بگیرید. تجزیه و تحلیل استاتیک در هرم آزمایشی و در اکثر اقتباس هایی که تاکنون دیده اید وجود ندارد. تطبیق جایزه آزمایشی وجود دارد که ضمن حفظ تمرکز بر روی تست های یکپارچه سازی، تجزیه و تحلیل استاتیک را در نظر می گیرد. جایزه آزمایشی از نقل قول قبلی گیلرمو راخ نشات گرفته و توسط کنت سی دادز توسعه داده شده است:
جایزه آزمایشی قیاسی است که دانه بندی آزمون ها را به روشی کمی متفاوت نشان می دهد. دارای چهار لایه است:
- تجزیه و تحلیل استاتیک . نقشی حیاتی در این قیاس دارد و به شما امکان می‌دهد تا با اجرای مراحل اشکال‌زدایی که قبلاً توضیح داده شده است، اشتباهات تایپی، اشتباهات سبک و سایر اشکالات را پیدا کنید.
- تست های واحد آنها اطمینان می دهند که کوچکترین واحد شما به درستی آزمایش شده است، اما جایزه آزمایشی به اندازه هرم آزمایشی روی آنها تأکید نمی کند.
- ادغام . این تمرکز اصلی است زیرا هزینه و اطمینان بالاتر را به بهترین نحو متعادل می کند، مانند سایر سازگاری ها.
- تست های رابط کاربری از جمله E2E و تست های بصری، آنها در بالای غنائم آزمایشی قرار دارند، مشابه نقش آنها در هرم آزمون.
برای مطالعه بیشتر در مورد جایزه آزمایشی، پست وبلاگ کنت سی دادز در مورد این موضوع را ببینید.
برخی از رویکردهای بیشتر متمرکز بر UI
این همه خوب و خوب است، اما مهم نیست که استراتژی خود را چگونه، "هرم"، "لانه زنبوری" یا "الماس" بنامید، هنوز چیزی کم است. در حالی که اتوماسیون تست ارزشمند است، مهم است که به یاد داشته باشید که تست دستی هنوز ضروری است. آزمایش خودکار باید وظایف معمول را کاهش دهد و مهندسان تضمین کیفیت را آزاد کند تا روی مناطق مهم تمرکز کنند. به جای جایگزینی تست دستی، اتوماسیون باید تکمیل کننده آن باشد. آیا راهی برای ادغام تست دستی با اتوماسیون برای نتایج بهینه وجود دارد؟
آزمایش مخروط یخ و آزمایش خرچنگ
در واقع دو انطباق از هرم تست وجود دارد که بیشتر بر روی این روش‌های آزمایش متمرکز بر رابط کاربری تمرکز دارد. هر دو مزیت اطمینان بالا را دارند، اما طبیعتاً به دلیل اجرای آهسته تر تست، هزینه بیشتری دارند.
اولین مورد، مخروط یخ آزمایشی، شبیه هرم در معکوس است. بدون مرحله آزمایش دستی، به آن پیتزای آزمایشی نیز می‌گویند.
مخروط یخ تمرکز بیشتری روی تست دستی یا UI دارد و کمترین تمرکز را روی تست واحد دارد. اغلب در پروژه‌هایی شکل می‌گیرد که توسعه‌دهندگان تنها با چند تفکر در مورد استراتژی تست کار را شروع کردند. کد یخ یک ضد الگو در نظر گرفته می شود و به درستی چنین است. از نظر منابع و کار دستی پرهزینه است.
خرچنگ آزمایشی شبیه مخروط یخ آزمایشی است، اما با تأکید بیشتر بر E2E و آزمایش بصری:
این استراتژی تست شامل یک جنبه دیگر است: تأیید می کند که برنامه شما عملکرد و ظاهر خوبی دارد. خرچنگ آزمایشی اهمیت آزمایش بصری را که در مقاله قبلی تعریف شد، برجسته می کند. تست ادغام، که به تست کامپوننت و API تقسیم می‌شود، بیشتر به پس‌زمینه حرکت می‌کند، و تست واحد در اینجا نقش فرعی‌تری دارد. می توانید جزئیات بیشتر در مورد این استراتژی آزمایش را در این مقاله در مورد خرچنگ آزمایشی بیابید.
این دو استراتژی تست در حالی که هزینه بیشتری دارند، جایگاه خود را دارند: به عنوان مثال، در پروژه های کوچکتر که در آن به تست های کمتری نیاز است یا پیچیدگی کمتری باید پوشش داده شود. در این مورد، ممکن است یک استراتژی تست کامل با تمرکز بر تست یکپارچه سازی بیش از حد طراحی شود.
اگرچه این دو استراتژی تست پرهزینه‌تر هستند، اما جایگاه خود را دارند، به عنوان مثال، در پروژه‌های کوچک‌تری که نیاز به تست‌های کمتری دارند و نیازی به پوشش پیچیدگی زیادی ندارند. در این مورد، یک استراتژی تست در مقیاس کامل متمرکز بر تست یکپارچه سازی ممکن است غیر ضروری پیچیده باشد.
توصیه عملی: بیایید استراتژی کنیم!
اکنون با رایج ترین استراتژی های تست آشنا شده اید. شما با کلاسیک - هرم آزمایشی - شروع کردید و با بسیاری از انطباق های آن آشنا شدید. اکنون باید آنها را برای محصول خود ارزیابی کنید و تصمیم بگیرید که کدام یک برای پروژه شما بهترین است. پاسخ به این سوال باید با " بستگی دارد " مورد علاقه همه شروع شود. هر چند که آن را کمتر دقیق نمی کند.
انتخاب مناسب ترین استراتژی تست از بین مواردی که شرح داده شد – و حتی آنهایی که حذف شده اند – به برنامه شما بستگی دارد. این باید معماری شما، نیازهای شما، و آخرین اما نه کم اهمیت ترین، کاربران و الزامات آنها را برآورده کند. همه اینها ممکن است از یک برنامه به برنامه دیگر متفاوت باشد. این کاملا طبیعی است. به یاد داشته باشید که مهمترین هدف شما خدمت به کاربران است نه تعریف کتاب درسی.
اغلب اوقات، جداسازی و تعریف تست های دنیای واقعی به صورت جداگانه دشوار است. حتی خود مارتین فاولر نیز بر جنبه مثبت تعاریف متفاوت ، مانند آزمون‌های واحد، تأکید می‌کند. همانطور که جاستین سرلز به درستی در توییت خود می گوید:
[…] تست‌های رسا بنویسید که مرزهای واضحی را مشخص می‌کنند، سریع و قابل اعتماد اجرا می‌شوند و فقط به دلایل مفید شکست می‌خورند.
توسط جاستین سرلز
روی تست‌هایی تمرکز کنید که خطاهای واقعی را گزارش می‌کنند که ممکن است کاربران با آن مواجه شوند، و از هدف خود منحرف نشوید. تست ها باید به گونه ای طراحی شوند که به نفع کاربر باشد، نه اینکه فقط پوشش 100٪ ارائه دهد یا اینکه در مورد کدام درصد از نوع تست بنویسد بحث شود.
روی تست هایی تمرکز کنید که خطاهای واقعی را گزارش می کنند که کاربران شما ممکن است با آن مواجه شوند و از هدف شما منحرف نشوند. تست‌ها باید به گونه‌ای طراحی شوند که به نفع کاربر باشد، نه اینکه فقط پوشش 100% ارائه دهند یا جرقه بحث‌هایی در مورد اینکه چند درصد از یک نوع تست خاص را باید بنویسید، ایجاد کنند.