تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
چکیده: در زندگی و در تست اتوماتیک، با رشد شما بسیاری از مسائل تغییر می‌کند. چالش‌هایی که با آنها روبرو می‌شوید، شکست‌هایی که تجربه می‌کنید و بهترین راه حل‌هایی که برای مشکلات خود پیدا می‌کنید، همه و همه تغییر می‌کنند. بیایید “درس‌های زندگی” را کنار بگذاریم و موضوع را در تست اتوماتیک بررسی کنیم.
در زندگی و در تست اتوماتیک، با رشد شما بسیاری از مسائل تغییر می‌کند. چالش‌هایی که با آنها روبرو می‌شوید، شکست‌هایی که تجربه می‌کنید و بهترین راه حل‌هایی که برای مشکلات خود پیدا می‌کنید، همه و همه تغییر می‌کنند. بیایید “درس‌های زندگی” را کنار بگذاریم و موضوع را در تست اتوماتیک بررسی کنیم. بیشتر تلاش‌های تست اتوماتیک با False Positive ها روبرو می‌شوند: تست‌هایی که حتی اگر اپلیکیشن درست رفتار کند، Fail می‌شوند. این مشکل بزرگیست!
در مرحله اول، کسی باید بفهمد که چرا این تست Fail شد. برای رسیدن به پاسخ این سوال ممکن است لازم باشد تا به صورت دستی به بررسی عملکرد برنامه‌های مربوطه و یا به بازدید و بررسی تست اتوماتیک بپردازید، و یا نیاز باشد تا Test Data را بررسی کنید، و یا بررسی کنید که آیا همه عناصر محیط تست فعال هستند و یا مطابق انتظار کار می‌کنند یا خیر؟ … و یا شاید حتی نیاز باشد تا تمامی موارد بالا را با هم بررسی کنید. هنگامی که مشکل پیدا شد، باید برطرف شود. سپس تست باید مجدداً انجام شود. اگر باز هم تست Fail شد، تست را دوباره اجرا و تکرار کنید.
در بهترین حالت، این فرایند باعث صرف منابع عظیمی می‌شود که می‌تواند به سرعت درROI (بازگشت سرمایه) که احتمالاً امیدوار بودید با تست اتوماتیک به دست آورید، بلعیده شود. کمپانی قدرتمندTricentis که به صورت تخصصی د حوزه تست نرم‌افزار فعالیت می‌کند، دریافته است که ۷۲ درصد از تست‌های Fail شده در حقیقت False Positive هستند.
برای هر دوره، به تمام تست‌هایی که دارید و تمام تست‌هایی که Fail شدن آنها گزارش شده است، فکر کنید. با یک حساب سرانگشتی به این نتیجه خواهید رسید که False Positive ها منابع زیادی را مصرف می‌کنند که می‌تواند به کارهای بسیار ارزنده‌تری اختصاص یابند.
در بدترین حالت، این موضوع به طور کلی ابتکار عمل تست اتوماتیک شما را تضعیف می‌کند. زمانی که شروع کنید به نادیده گرفتن False Positiveها، در یک شیب لغزنده قرار می‌گیرید. برنامه‌نویسان تصور می‌کنند که هر مشکلی که کشف می‌شود، یک False Positive است، و تسترها باید بیشتر کار کنند تا از این میان مشکلات مهم مورد توجه قرار گیرند. علاوه بر این، اگر ذینفعان به نتایج تست اطمینان نداشته باشند، بر اساس خروجی‌های تست، برای ادامه تولید یا انتشار نرم‌افزار تصمیمگیری نخواهند کرد.
به اندازه کافی در مورد اینکه چرا False Positive دردسر بزرگیست صحبت کردیم. حال سوال این است که چگونه این درد را تسکین دهیم؟ خوب، بستگی دارد. همه موارد False Positive یکسان نیستند. تیمی که تازه با تست اتوماتیک شروع به کار کرده است با انواع مختلف False Positive روبرو می‌شود تا تیمی که تست اتوماتیک گسترده‌تر و پیشرفته‌تری را انجام می‌دهد. از آنجا که علل False Positive متفاوت است، بنابراین استراتژی‌های شما هم برای از بین بردن آنها متفاوت خواهد بود.
گویا در مجموعهTricentis ، بیش از یک سال است که اطلاعات مربوط به False Positive ها را از ۲۰۰۰ شرکت در سطح جهان جمع آوری کرده‌اند. اخیراً این داده‌ها تجزیه و تحلیل شده تا مشخص شود چه عواملی باعث Failure(نارسایی) در مراحل مختلف بلوغ تست اتوماتیک می‌شوند و چه راهکارهایی به رفع این Failureها کمک می‌کند. و اما یافته‌های این تحقیق را در زیر می‌بینیم:
انطباق با اصول
در ابتدا، همه چیز در مورد اصول است: هم از نظر اتوماسیون و هم از منظر Failure. هنگامی که شروع به ایجاد تست اتوماتیک می‌کنید، معمولاً با کارهای ساده مانند جستجوی داده یا ایجاد یک شی جدید(مانند یک اکانت) شروع می‌کنید. در این مرحله، تست اتوماتیک شما ممکن است به سادگی خراب شود زیرا شما هنوز شما در حال یادگیری ریزه‌کاری‌های فناوری اتوماسیون یا رویکرد انتخاب شده هستید. این مسائل اساسیِ اتوماسیون در واقع منشا اکثر False Positive ها بوده، و بسیار ناامیدکننده هستند زیرا پیروزی‌های تست اتوماتیک اولیه شما را خنثی می‌کنند.
البته ، برخی از رویکردها نسبت به سایر روش‌ها منحنی یادگیری تندتری دارند و برخی از آنها کمتر از سایر روش‌ها شکست می‌خورند. در هر صورت، شما همیشه نیاز دارید برای تسلط بر اصول اولیه، زمانی را اختصاص دهید. حداقل، نیاز دارید که در مورد Best Practiceهای(بهترین شیوه‌های) مربوط به انواع برنامه‌ها و اینترفیس‌هایی که با آنها کار می‌کنید، روش‌های مختلف تعیین Test Data و گزینه‌های مختلف Validation(اعتبار سنجی) موجود، تحقیق کنید.
دردسر رو به رشد
طولی نمی‌کشد که شما نیاز پیدا می‌کنید که از تسک‌های تولید آبجکت به تسک‌های مدیریت آبجکت وارد شوید. یکی از تعاریفی ریسک که به آن علاقه دارم، این است که “ریسک = نرخ تکرار خسارت”. برای مثال در یک برنامه خدمات بانکی آنلاین، تولید آبجکت‌ها(مثلا افتتاح سپرده) تکرار بالایی دارند اما بسیار کم آسیب و خسارت می‌رسانند. درمقابل تسک های مدیریتی مثل (اصلاح تراکنش‌های متقلبانه در مواردی از جمله پولشویی) تکرار کمی دارند، اما خسارت بسیار بیشتری ایجاد می‌کنند. چرا این موضوع مهم است؟ زیرا برای پوشش دادن ریسک‌ها شما باید تمامی امور مرتبط با تسک‌های مدیریتی را هم مانند تسک‌های تولید آبجکت پوشش دهید و هنگامی که تیم‌ها به سمت خودکار کردن این سناریوهای پیچیده پیش می‌روند، Test Dataها به عنوان محتمل‌ترین منبع False Positive ظاهر می‌شوند.
به طور مثال برگرداندن تراکنش های متقلبانه را بررسی می کنیم. برای خودکار کردن این مورد، ابتدا باید “وضعیتی” را ایجاد کنید که سپرده در ان وضعیت ایجاد شده است. پس از آن، تست باید نشان دهد که برخی از این تراکنش‌ها متقلبانه بوده و مبلغ مورد نظر را بر این اساس کاهش دهد. انجام تنها یکباره چنین تستی به طور خودکار چالش برانگیز است. از طرفی اجرای آن به طور مکرر و بدون ایجاد False Positive مستلزم تسلط بسیار سنگینی بر مدیریت Test Data است. مطالعه ما نشان داد که مسائل مربوط به مدیریت Test Data دلیل اصلی ۲۳٪ از False Positiveها می‌باشند.
زمانی که تست‌های شما از هرم به اصطلاح Agile Test فراتر می روند و با سیستم های زیادی در ارتباط هستند، مسائل مرتبط با محیط تست نیز نمایان می شوند. با توجه به اینکه نرم‌افزار تحت تست به طور متوسط با ۵۲ سیستم وابسته(اعم از سخت افزاری و نرم‌افزاری) ارتباط برقرار می‌کند، یک تست End-to-End(سراسری) ممکن است به چیزی که غیرقابل دسترس است، اصلاح شده یا زمان آن تمام شده، برخورد کند، و ممکن است این اتفاق قبل از اینکه تست شما پاسخ مورد انتظار را دریافت کرده باشد، رخ دهد. می‌دانید نتیجه چه خواهد بود؟ False Positive بیشتر.
۱۶ درصد از False Positive ها را می‌توان در مسائل محیط تست بررسی کرد. مجازی‌سازی سرویس‌ها، در حالت ایده آل، کلید حذف این دسته از مشکلات است. رفتارهایی را که نیاز دارید شبیه سازی کنید، تا به درستی، سازگار و همیشه در دسترس، پیکربندی شوند. مطمئناً، شما می‌خواهید قبل از نهایی کردن(Release)، روی سیستم‌های واقعی تست کنید. اما استفاده از این شبیه سازی‌ها برای تست مداوم روزانه شما، ضمن جلوگیری از دردسر False Positiveها، امکان بازخورد سریع را فراهم می‌کند(به عنوان مثال، اگر تست شما هنگام استقرار مجدد یک سیستم وابسته اجرا شود، می‌توانید بازخورد سریعی از نحوه عملکرد دریافت کنید).
Flakiness
سرانجام ، موذی‌ترین و دشوارترین رام شدن منبع False Positive ها: Flakiness روی تست. گوگل نتیجه تست “Flaky ” را چنین تعریف می کند: “تستی که هم نتیجه موفق(Pass) و هم ناموفق(Fail) را برای یک کد یکسان نشان می دهد.” در بسیاری از موارد، چنین نتایجی واقعاً به مشکلی در کد اشاره دارند. با این حال، درصد بالایی از False Positiveها به این مورد اختصاص دارد.
این نژاد از False Positiveها معمولاً هنگامی ظاهر می‌شوند که شما بر انواع دلایل فوق الذکر فائق آمده باشید و واقعا تست خود را یکپارچه کرده باشید و وارد CI/CD pipeline(مجموعه ای از مراحل است که برای ارائه نسخه جدیدی از نرم افزار باید انجام شود. روشی متمرکز بر بهبود تحویل نرم افزار با استفاده از DevOps یا مهندسی قابلیت اطمینان سایت (SRE) است) خود شده باشید. اغلب، Flakiness نتیجه عملکرد برنامه به صورAsynchronous (ناهمزمان) است که هنگام راه اندازی اتوماسیون در نظر نگرفتید. دلایل دیگر به وجود آمدن این مشکل می‌تواند مسائلConcurrency ، مشکلات شبکه یا وابستگی های ترتیب تست(Test Order Dependencies اشاره به زمان اجرای تست دارد. گاهی اواقت ممکن است داده‌های پیش نیاز یک تست باید توسط تست دیگری که آنرا “تست پیشنیاز” مینامیم، تامین شوند. برای رسیدن به این داده‌ها مشخص است که “تست پیشنیاز” باید قبل از تست اصلی ما انجام شود، و این مثالی از همان وابستگی ترتیب است) باشد. باید اعتراف کنم: حل کردن این مساله دشوار است. استفاده از شناسایی الگوها(Pattern Recognition) و یادگیری ماشینی(Machine Learning) برای شناسایی خودکار مشکلات(سپس اجرای مجدد) تست‌های Flaky به احتمال زیاد برای برطرف کردن مشکل False Positiveها امیدوار کننده به نظر می‌رسد، اما شیطان در جزئیات است.
در حقیقت، من فکر می‌کنم استفاده از هوش مصنوعی و یادگیری ماشینی برای تعیین اینکه آیا Fail شدن تست مرتبط با False Positive است یا خیر، کاری بسیار عملی و ارزشمندیست.
