پنج شنبه , ۱۳ اردیبهشت ۱۴۰۳

مبانی تست در DevOps

DevOps-Continuous Testing
DevOps-Continuous Testing

چگونه به طور موثر در DevOps تست را انجام دهیم؟ به صورت مداوم(Continuous)، البته. اما چگونه این کار را انجام دهیم؟ در این مقاله کوتاه می‌خواهیم شِمایی از چگونگی انجام تست را در DevOps توضیح دهیم.

DevOps یک متدلوژی یا مجموعه‌ای از ابزارها نیست، بلکه مفهوی برای کنار گذاشتن موانع بین Dev(توسعه) و Ops(بهره‌برداری) به منظور رفع نیاز برای زمان‌بندی‌هایِ کوتاهِ تحویلِ بیشتر و مکرر است.

در DevOps، سازمان‌ها با شیوه چابک‌تر به تغییر نیازمندی‌های(Requirement) کسب و کاری پاسخ می‌دهند. در این مفهوم، مهندسین سیستم، مهندسین Release(انتشار)، سرپرستان پایگاه داده(DBA)، مهندسین شبکه و متخصصان امنیتی در بخش Ops(بهره‌برداری) به طور کامل با توسعه‌دهندگان، مهندسین QA، تحلیلگران کسب و کار و نیز مهندسان محصول در بخش Dev(توسعه) در یک واحد منفرد ارزشمند IT یکپارچه می‌شوند.

چهار فرآیند مداوم(Continuous Process) در DevOps وجود دارد:

  • یکپارچه‌سازی مداوم(Continuous Integration)
  • تحویل مداوم(Continuous Delivery)
  • تست مداوم(Continuous Testing)
  • نظارت مداوم(Continuous Monitoring)

در DevOps، تست در انتهای چرخه Release نیست بلکه در جریان اصلی(Mainstream)/ابتدای چرخه توسعه قرار دارد. مهندسین سیستم و توسعه‌دهندگان، کد را در محیط مناسب برای یکپارچه‌سازی مداوم و تحویل مداوم دریافت می‌کنند و سپس فرآیندهای تست مداوم و نظارت مداوم فعال می‌شود. بعد از این مهندسین تضمین کیفیت با بررسی و تست این موضوع که آیا اپلیکیشن بر اساس طراحی کار می‌کند، در این رابطه که این تیم اپلیکیشن درستی تولید کرده است یا خیر، عملیات اعتبارسنجی(Validation) را انجام می‌دهد.

این یک نقش اساسی برای تیم‌های تست است(نه فقط برای ممیزی کارکرد تغییرات کد بلکه حتی برای ممیزی تغییراتی که کد را دچار شکست نمی‌کنند) تا بدین ترتیب طراحی تست(Test Design)، اتوماسیون تست، و توسعه Test Case را با DevOps انطباق دهند. یک تمایز کلیدی DevOps، موضوع بلوغ تست است. یک سازمان می‌تواند یکپارچه‌سازی، تست، تحویل و نظارت آن را به صورت اتوماتیک انجام دهد، اما هنوز هم با تنظیم هوش تست و اتوماسیون مشکل داریم، که اگر پیش از این حل نشده باشد، می‌تواند منجر به تنگنا شود.

در اکثر پروژه‌ها، Test Architect(معمار تست) را می‌توان در فرآیند عمومی DevOps استفاده کرد. با پیروی از متد Action Based Testing، معمار تست قابلیت‌هایی را برای توسعه و اتوماتیک‌سازیِ سریع Test Caseها در همان اسپرینت و در حالیکه اپلیکیشن تحت تست است، پیشنهاد می‌دهد، در نتیجه اعضای تیم(هر کدام از منظر مهارت خود) اجازه خواهند یافت تا به طور فعال در فرآیند تست و اتوماسیون درگیر شوند. به غیر از QA، دیگر مهارت‌های تیم/نقش‌ها به طور معمول عبارتند از: توسعه، بهره‌برداری و مالکیت محصول.

در چهار فرآیند مداوم مذکور در DevOps، معمار تست(Test Architect) طبق تصویر ذیل نقش بسیار مهمی را برای اتصال و روان‌سازی فرآیند ایفا می‌کند.

TestArchitect
TestArchitect

هنگامی که تست‌های خودکار آماده می‌شوند، می‌توان آنها را در سوئیت‌های تست(Test Suite) قرار داد و اجرا را در Batch Fileها تعریف نمود که می‌توانند بوسیله هر ابزار Continuous Integration یا زمانبندی اجرا شوند و حتی برای تست در مرحله Production(بهره‌برداری) نیز مورد استفاده قرار گیرد. می‌توانیم نتایج اجرای خودکار را در فرمت xUnit، فرمت XML یا فرمت HTML تولید کنیم، که می‌توان آن را خوانده و گزارش را در مقابل آن Run کرد.

ابوالفضل خواجه دیزجی

همچنین ببینید

Test Data Bottleneck

تنگنای داده های تست و راهکار آن

زمان زیادی برای یافتن کیس های مناسب برای داده های تست هدر می شود، چندین …

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *