تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
در تست‌هایی که به صورت Model-Based طراحی می‌شوند، یک از بازیگران اصلی Control Flow Graph است. همانطور که از نام این روش کاربردی تست مشخص است، اصل و اساس طراحی تست همان طراحی صحیح مدل است. اما غالب اوقات وقتی این روش دقیق را برای تست به شرکت‌ها معرفی می‌کنیم(به ویژه در شرایطی که می‌خواهیم از تکنیک Use Case Testing استفاده کنیم)، آنها در طراحی Control Flow Graph دچار مشکل می‌شوند. از آنجاییکه در تکنیک‌های مبتنی بر Control Flow Graph شما در نهایت باید به استخراج مسیر برسید، اگر گراف‌های شما دچار ایراداتی باشند که در ادامه به آنها خواهیم پرداخت، با یک مشکل بسیار جدی در تولید Logical Test Caseها مواجه خواهید شد، و این مشکل می‌تواند آنقدر جدی شود، که شما باید در بهترین حالت گراف‌ها را مجددا طراحی کنید، و در بدترین حالت ممکن است مدیریت شما را مجبور کند، که به دلیل هزینه بالا از این تکنیک صرفه نظر کنید. در این مقاله به ترتیب این مشکلات را بررسی کرده و راهکار غلبه بر آنها را نیز ارائه می‌دهیم.
- حلقه‌های زائد
الف. حلقه‌های معقول
موضوع حلقه‌ها به دو دلیل یکی از آزار دهنده‌ترین مسائل در موضوع تست است: ۱- این سوال که چه ساختاری واقعا حلقوی است؟ ۲- حلقه را چند بار تست کنیم؟
باید به خاطر داشته باشید که در تکنیک‌های Model-Based معمولا تعداد Test Caseها زیاد است، و همین موضوع می‌تواند برای فرآیند تست یک ریسک محسوب شود. بنابراین تلاش ما باید به روش معقولی به سمت کم کردن Test Caseها در جریان باشد.
اما قبل از اینکه بخواهیم به موضوع حلقه‌های زائد بپردازیم، باید در مورد حلقه‌های معقول صحبت کنیم.
حلقه‌های معقول در تستِ یک Functionality در سطح سیستم معمولا در یکی از دو حالت زیر رخ می‌دهند:
۱- رابطه Parent/Child: این حلقه‌ها تعریف کننده یک رابطه Parent/Child یا تعریف رابطه n..1 در سطح داده‌ها هستند. به عنوان نمونه یک گروه کاربری می‌تواند یک یا چند کاربر داشته باشد. در این حالت شما با یک حلقه مواجه هستید. چرا که می‌توانید عملیات تکراری انتساب کاربر به گروه را برای چندین بار انجام دهید.
۲- ساختارهای محاسباتی: در این حلقه‌ها محاسبات انجام می‌شود، و تکرار حلقه بسته به یک پارامتر محاسباتیست.
نکته: به خاطر داشته باشید که هر حلقه باید حداقل دو بار اجرا شود. اجرای بیش از این برای حلقه الزامی ندارد، مگر اینکه شرایط Business به گونه‌ای باشد که اجرای بیش از این تعداد ضرورت داشته باشد.
ب. حلقه‌های زائد
تقریبا اکثر حلقه‌ها به جز حلقه‌هایی که در بالا گفته شد، حلقه‌های زائد محسوب می‌شوند. البته ممکن است در شرایط خاص شما با حلقه‌هایی مواجه شوید که در دو حالت بالا نمی‌گنجند و به دلیل ایتکه ارزش Functional بالایی دارند شما نمی‌توانید آن Functionality را به جز حلقه با چیز دیگری بیان کنید. در اینجا باید ساختار حلقوی خود را حتما در گراف بگنجانید.
اما نوعی از حلقه‌ها هستند که غالب اوقات افرادی که Control Flow Graphها را با دقت زیادی ترسیم می‌کنند و تمایل دارند همه چیز سیستم را مشخص کنند، با آن دچار مشکل می‌شوند. البته چنین کاری نه تنها هیچ ضرورتی ندارد، بلکه گراف‌ها را به شدت ناخوانا می‌کند، و علاوه بر این استخراج Test Case را نیز به مراتب پیچیده‌تر می‌سازد. این مشکل که معمولا در سطح System Functionality رخ می‌دهد، چیزی نیست جز بازگشت به صفحه قبل یا ابتدای یک Functionality، در صورتیکه هیچ یک دو ساختار بالا برای آن صادق نیست.
مثال: فرض کنید شما در یک فروشگاه الکترونیکی مشغول خرید هستید. طبعا پس از اینکه خرید خود را انجام دادید و فاکتور شما صادر شد، باز هم می‌توانید خرید کنید. همین امکان خرید مجدد باعث می‌شود که طراح Control Flow Graph در موضوع خرید یک حلقه ایجاد کند.
اما در چنین شرایطی باید چه کار کنیم؟ آیا کلا موضوع بازگشت به ابتدای Functionality را فراموش کنیم؟
هرگز. شما باید در انتهای پروسه خرید حتما یک Node اضافه کنید، و در آن Node متذکر شوید، که پس از اتمام خرید مجددا به ابتدای Functionality خرید منتقل می‌شوید. پس از آن باید یک شرط بگذارید که آیا تمایلی برای اجرای مجدد Functionality وجود دارد یا خیر. در صورتیکه پاسخ مثبت باشد، Control Flow Graph به نقطه پایان می‌رسد، چون این فرآیند قبلا یک بار انجام شده، و در زمان اجرای Test Caseها، اجرای مجدد این فرآیند برای شما ارزش افزوده‌ای ندارد. اما اگر تمایل به اجرای مجدد Functionality مذبور ندارد، می‌تواند مسیر را ادامه دهد. این موضوع در تصویر زیر ارائه شده است.
- درخت نبودن Graph بدون در نظر گرفتن حلقه‌های معقول
یکی از موضوعاتی که می‌تواند شما را به سادگی دچار مشکل کند این است که گراف شما بدون در نظر گرفتن حلقه‌های معقول باز هم یک درخت نباشد. این موضوع مانند تصویر زیر خود را در گراف نشان می‌دهد.
اگر چه در طراحی Control Flow Graph چنین ترسیمی درست است، اما اگر به تعداد زیاد در گراف شما رخ دهد، و یا تعداد شرایطی که در ادامه می‌آید زیاد باشد. قطعا در استخراج مسیرها دچار مشکل می‌شوید. در چنین شرایطی باید حتما این ساختا را به حالت درختی تبدیل کنید. در مثال زیر شما چهار مسیر از ابتدا تا انتهای گراف دارید. اما باید این ساختار را الزاما به حالت درختی تبدیل کنید. ممکن است پس از تبدیل گراف به درخت، با درختی مواجه شوید که ۱۰۰ برگ در انتها داشته باشد. اما خیال شما راحت است، که هر مسیر در نهایت به یک برگ می‌رسد، و در حقیقت هر یک از این مسیرها یک Test Case است.
البته نکات بیشتری در مورد Control Flow Graphها در Model-Based Testing وجود دارد. اما مهمترین موضوعات در مورد استخراج مسیر از Control Flow Graphها مواردیست که ذکر شد.
