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

استفاده از پارتیشن‌بندی هم‌ارزی(Equivalence Partitioning) و تحلیل مقدار مرزی در تست Black Box

Boundaries
Boundaries

خلاصه: پارتیشن‌بندی هم‌ارزی و تحلیل مقدار مرزی دو تکنیک مبتنی بر مشخصات(Specification-Based) هستند که در تست Black Box مفید واقع می‌شوند. این مقاله هر یک از این تکنیک‌ها را تعریف کرده و با ارائه مثال‌هایی توضیح می‌دهد که چگونه می‌توانید از آنها برای ایجاد Test Caseهای بهتر بهره بگیرید. با استفاده از این دو تکنیک می‌توانید در زمان صرفه‌جویی نموده و تعداد Test Caseهای مورد نیاز برای ورودی‌ها، خروجی‌ها و مقادیر مؤثر را کاهش دهید.

بخشی از کار تستر، نوشتن Test Caseها مطابق با مجموعه‌ نیازمندی‌هاست. زمانیکه با این نیازمندی‌ها پرزنت می‌شوید، آیا Panای برای طراحی Test Caseها بر اساس مشخصات دارید؟

من همیشه تعریف واژگان را بسیار مفید می‌دانم، بنابراین با تست مبتنی بر مشخصات شروع خواهم کرد. تکنیک‌های تست مبتنی بر مشخصات به عنوان تکنیک‌های تست Black Box یا تکنیک‌های تست ورودی/خروجی محور(Input/Output-Driven Testing Technique) شناخته می‌شوند، زیرا در اینجا تستر نرم‌افزار را به عنوان یک “Black Box” یا جعبه سیاه می‌بیند، چرا که پس از وارد کردن ورودی‌ها، مشخص نیست که خروجی‌ها چه مقادیری خواهد بود. به عبارت دیگر، تسترها از چگونگی ساخت سیستم یا کامپوننت درون جعبه اطلاعی ندارند. در تست Black Box، تستر بر روی آنچه نرم‌افزار انجام می‌دهد تمرکز می‌کند نه چگونگی انجام کار. به این ترتیب تست‌ها بر اساس نیازمندی‌های Functional در پروژه طراحی می‌شوند.

پارتیشن‌بندی هم‌ارزی

پارتیشن‌بندی هم‌ارزی برای کاهش تعداد Test Caseها مورد استفاده قرار می‌گیرد تا به طور موثر ورودی‌ها، خروجی‌ها، مقادیر داخلی و مقادیر زمانی مدیریت شوند. پارتیشن‌بندی برای ایجاد پارتیشن‌های هم‌ارزی استفاده می‌شود که اغلب به آنها کلاس‌های هم‌ارزی(Equivalence Class) گفته می‌شود که مشتمل بر مجموعه‌ای از مقادیر است که باید با یک روش پردازش شوند.

پارتیشن‌بندی هم‌ارزی برای هر دو داده معتبر یا Valid(مقادیری که باید پذیرفته شوند) و داده نامعتبر یا Invalid(مقادیری که باید رد شوند) اجرا می‌شود. با انتخاب یک مقدار کاندید از یک پارتیشن، پوشش(Coverage) برای تمامی اقلام در همان پارتیشن می‌تواند در نظر گرفته شود.

بیایید فرض کنیم اپلیکیشنی که شما در حال تست آن هستید، به شما اجازه می دهد تا کار را از طریق یک جعبه pop-up که پس از کلیک کاربر بر روی دکمه hold بروز می‌کند، ادامه دهید. ورود متن به این جعبه متن pop-up  باید بین ۱ تا ۲۵۵ کاراکتر باشد تا بتواند درخواست hold را به صورت موفقیت آمیز ارسال کند.

در این مثال، سه پارتیشن وجود دارد: یک پارتیشن معتبر و دو پارتیشن نامعتبر.

 پارتیشن معتبر بین ۱ تا ۲۵۵ کاراکتر است و انتظار داریم که سیستم تمامی ورودی‌های ۲۵۵ کاراکتری را به همان روش یکسان مدیریت کند.

اولین پارتیشن نامعتبر ، کارکتر صفر است- زمانیکه هیچ کاراکتری وارد نمی‌شود، انتظار داریم که سیستم درخواست hold را رد کند.(این پارتیشن همچنین شامل کاراکترهای کمتر از صفر نیز هست، البته اگر امکان وارد کردن یک عدد منفی در میان کاراکترها وجود داشته باشد!)

پارتیشن نامعتبر دوم، تمام اعداد مثبت بزرگتر از ۲۵۵ است. انتظار داریم که سیستم مقدار ۲۵۶ و بالاتر از آن را رد کند.

در اینجا یک تجسم از پارتیشن‌های معتبر و نامعتبر ارائه شده است:

Valid And Invalid Values
Valid And Invalid Values

تحلیل مقدار مرزی

تحلیل مقدار مرزی برای تست مقادیری که روی مرز پارتیشن‌های مشخص شده وجود دارد استفاده می‌شود. دو راه برای استفاده از این روش وجود دارد: تست دو مقداره و تست سه مقداره.

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

بر اساس مثال ارائه شده روی تکنیک پارتیشن‌بندی هم‌ارزی، مقادیر مرزی برای حد پایین، صفر و یک خواهند بود. مقادیر مرزی برای حد بالا نیز ۲۵۵ و ۲۵۶ هستند.

در اینجا یک تجسم از مرزهای دو مقداره ارائه شده است:

Boundary And Invalid Values
Boundary And Invalid Values

برای تست سه مقداره، از دو مقدار قبلی و البته مقادیر درون مرز استفاده می‌کنیم. مقادیر داخل مرز نیز باید با کمترین افزایش/کاهش به نسبت مقدار مرزی حاصل شوند.

بنابراین در این مورد، مقادیر مرزی برای حد پایین صفر، یک و دو خواهند بود. مقادیر مرزی برای حد بالا ۲۵۴، ۲۵۵ و ۲۵۶ می‌باشند.

در اینجا یک تجسم از مرزهای سه مقداره ارائه شده است:

Boundary, Valid And Invalid Values
Boundary, Valid And Invalid Values

تصمیم‌گیری در مورد اینکه از تست دو مقداره یا سه مقداره استفاده شود  باید بر اساس ریسک مرتبط با آیتم تحت تست باشد. استفاده از رویکرد سه مقداره باید برای اقلام پرریسک اتخاذ شود.

استفاده از این تکنیک‌ها به همراه هم

این مثال‌ها پیچیده نیستند، با این حال این تکنیک‌ها می‌توانند درصورت نیاز برای سناریو های پیچیده‌تر مورد استفاده قرار گیرند.

یکی از جاهایی که من از این ایده استفاده کردم، در خلال جلسه اخیر طراحی Test Plan بود که در آن پیرامون بهترین روش برای تست به روز رسانی مقدار حداکثری برای فیلد سن در یکی از Updateهای محصول‌مان صحبت کردیم. هدف ما ممیزی این موضوع بود که محصول فقط برای کسانی که در محدوده سنی صفر تا ۸۵ هستند صادر شود؛ حداکثر سن در نسخه قبلی بالای ۸۰ سال بود. طبیعتا، مدیریت می‌خواست برآورد ما را برای تست این تغییر بداند، بنابراین به صورت گروهی شروع به هم‌اندیشی و محاسبه Test Effort کردیم.

اولین پیشنهاد تست هر سن از صفر تا ۱۱۰(بالاترین مقدار در جدول آماری ما) بود. Test Analyst ما برآورد کرد که هر Test Case به نیم ساعت زمان برای طراحی و نیم ساعت زمان برای اجرا نیاز دارد، بنابراین ما به حدود ۱۱۰ ساعت زمان(البته با کمی زمان اتلاف) نیاز داشتیم. اکثر تحلیلگران تستِ دیگر در جلسه مشغول نوشتن و بحث در مورد روش‌ها برای کاهش مقدار زمان مورد نیاز برای تهیه Test Caseها بودند.

در این مرحله، من گفتم که فکر می‌کنم این تست فقط با شش Test Case قابل انجام است. با این جمله بحث ناگهان متوقف شد.

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

به جای این که رویکرد سنتی برای شناسایی دو پارتیشن معتبر(سنین صفر تا ۸۵ساله و سنین ۸۶ ساله به بالا) و ایجاد Test Caseها مرزی سه مقداره برای آنها، ایده من این بود که مرزهای قدیمی را بعنوان یک مورد خاص تلقی کنیم. با توجه به این که حداکثر سن در نسخه قبلی ۸۰ سال بود، بهترین راه برای کاهش ریسک، ایجاد یک پارتیشن معتبر اضافی در پارتیشن معتبر موجود برای بررسی این مرزها بود، یعنی سن ۸۱ تا ۸۵٫ در نتیجه، ما فقط به شش Test Case احتیاج داشتیم: چک کردن سنین ۷۹-۸۰ و ۸۱-۸۴ و ۸۵-۸۶٫

به جای اینکه از مدیریت ۱۱۰ ساعت برای Test Effort زمان بخواهیم، توانستیم فقط شش ساعت درخواست کنیم – و یک روش عالی برای توضیح چگونگی تعیین Test Caseهای مورد نیاز در طول جلسه بازبینی برنامه‌مان با ذینفعانمان داشتیم.

این فقط یک راه استفاده از پارتیشن‌بندی هم‌ارزی و تحلیل مقادیر مرزی بود تا Test Caseها با بیشترین بهره‌وری و رفتار مؤثر را طراحی کنیم. یقین داشته باشید با این روش در زمان صرفه جویی زیادی خواهد شد.

زهرا جاهدی باشیز

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

Test Data Bottleneck

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

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

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

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