درک نقش آزمایش جدول تصمیم گیری

یک نوع آزمایش نرم افزار است تست جدول تصمیم گیریبشر در پروژه های دنیای واقعی ، اغلب با استفاده از اکسل ایجاد می شود. وضوح بصری آن حتی برای اعضای تیم غیر فنی که دانش دامنه قوی دارند ، درک آن را آسان می کند.

از طرف دیگر ، هنگام تأیید رفتار کد اجرا شده ، آزمایش ساختاری (مانند تست های واحد) معمولاً استفاده می شود.

(اگر می خواهید عمیق تر به آزمایش ساختاری شیرجه بزنید ، احساس راحتی کنید که پست قبلی من را بررسی کنید: درک معیارهای پوشش تست نرم افزار گام به گام: از پوشش خط گرفته تا MC/DC)

در نگاه اول ، این دو رویکرد ممکن است کاملاً متفاوت به نظر برسد. با این حال ، درک چرا هر دو برای آزمایش یکسان ضروری هستند که در عمل بسیار مهم است. در این مقاله به بررسی دلایل و پیشینه آن می پردازیم.

ساختار اساسی یک جدول تصمیم گیری

یک جدول تصمیم گیری دارای یک ساختار بسیار ساده است. شرایط به صورت عمودی نوشته شده است ، با نتیجه ذکر شده در پایین. هر ستون افقی نشان دهنده a است متبیک– ترکیبی از مقادیر ورودی برای هر شرایط.

• شرایط: فرضیات یا ورودی هایی که برای تصمیم گیری استفاده می شوند (ردیف)
• انواع مختلف: موارد آزمایش ایجاد شده از ترکیب شرایط (ستون ها)

استفاده از این نوع جدول به سازماندهی موارد آزمایش به روشی ساختار یافته و جامع کمک می کند.

دقیقاً مانند آزمایش ساختاری ، بسته به هدف آزمایش نیز استراتژی های مختلفی وجود دارد.

مقایسه استراتژی آزمون در جداول تصمیم گیری

چرا ما از رویکردهای مختلف استفاده می کنیم؟

در این مرحله ، ممکن است تعجب کنید:

“اگر مشخصات را با استفاده از جدول تصمیم گیری تأیید کنیم – کد را بر اساس آن مشخصات پیاده سازی کنید → رفتار را با استفاده از آزمایش ساختاری تأیید کنید …

پس آیا ما واقعاً به آزمایش مبتنی بر جدول تصمیم داریم؟ “

این یک سوال عادلانه است.

با این حال ، حتی اگر ما همان منطق را آزمایش کنیم ، تمرکز از هر رویکرد متفاوت است – و به همین دلیل ما به هر دو نیاز داریم.

چرا آزمایش جدول تصمیم گیری لازم است؟

حتی اگر مشخصات با استفاده از جدول تصمیم گیری به خوبی سازمان یافته باشند و آزمایشات ساختاری مناسب انجام شود ، آزمایش مبتنی بر جدول تصمیم گیری هنوز هم ارزش منحصر به فردی را به روش های زیر به ارمغان می آورد:

1. اجرای همیشه با مشخصات مطابقت ندارد

• وجود دارد الزامات نادیده گرفته یا سوء تفاهم در حین اجرای
• آزمایش جدول تصمیم گیری را تأیید می کند منطق تصمیم گیری با آزمایش دقیق در برابر مشخصات.

2. آزمایش ساختاری نمی تواند منطق گمشده را تشخیص دهد

• آزمایشات ساختاری فقط بررسی می کند آنچه در کد نوشته شده استبشر
• من نمی تواند آنچه را که گم شده است تشخیص دهدبشر
• جدول تصمیم گیری به فاش کردن کمک می کند تصمیماتی که باید وجود داشته باشد اما این کار را نکنندبشر

3. پوشش تست را روشن می کند

• با یک جدول تصمیم گیری ، واضح است کدام شرایط و نتایج در حال آزمایش هستندبشر
• پیدا کردن آن را آسان تر می کند شکاف یا افزونگی در موارد آزمون و امکان پذیر است بررسی های بهتر در بین اعضای تیمبشر

رابطه بین جداول تصمیم گیری و آزمایش ساختاری

ایجاد موارد آزمایشی بر اساس جدول تصمیم گیری می تواند به طور غیرمستقیم شاخه های کد را پوشش دهد (مانند if اظهارات).

با این حال ، آزمایش ساختاری به تنهایی در مواردی مانند:

• منطق با استفاده از چند شکل (وراثت یا اعزام پویا)
• شرایط به پرونده های پیکربندی یا مقادیر پایگاه داده

از آنجا که اینها به صراحت به عنوان شاخه های کد نشان داده نمی شوند ، آنها ممکن است با تست های ساختاری از دست بروندبشر

بخش زیر نمونه های مشخصی را ارائه می دهد.

وقتی منطق از پلی مورفیسم استفاده می کند

پلی مورفیسم به این معنی است که نام روش مشابه بسته به کلاس می تواند متفاوت رفتار کند. این یک ویژگی اصلی برنامه نویسی شی گرا است.

// Java
class User {
    void showDiscount() {
        System.out.println("No discount");
    }
}

class PremiumUser extends User {
    void showDiscount() {
        System.out.println("20% discount");
    }
}

User u = getUser();  // We don't know if it's a regular or premium user
u.showDiscount();    // Behavior changes depending on the class at runtime

در این حالت ، انشعاب با بیانیه ها بلکه با نوع کلاس انجام نمی شود.
بنابراین ، آزمایش ساختاری (که به دنبال شاخه های کد مانند IF) ممکن است این منطق را از دست بدهد.

وقتی شرایط به پرونده های پیکربندی یا پایگاه داده بستگی دارد

بعضی اوقات ، رفتار یک برنامه توسط مقادیر در پرونده های خارجی کنترل می شود ، نه با شرایطی که در کد نوشته شده است.

// config.json
{
  "isFeatureEnabled": true
}

# Python
if config["isFeatureEnabled"]:
    enable_feature()

در چنین مواردی ، آزمایش مبتنی بر مدل (مانند جداول تصمیم گیری) به شما امکان می دهد منطق را از دیدگاه مشخصات تأیید کنید.
به عبارت دیگر:

آزمایش ساختاری بررسی می کند که آیا کد به صورت نوشته شده رفتار می کند یا خیر.

آزمایش مبتنی بر مدل بررسی می کند که آیا رفتار مناسب یا تصمیم در وهله اول از دیدگاه کاربر یا مشخصات گنجانده شده است.

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

آزمایش ساختاری

تمرکز: کدام شعب اجرا می شود؟

• تمرکز بر ساختار کد (در صورت بیانیه ، حلقه ها)
• هدف یا معنی نرم افزار را در نظر نمی گیرد
• با مشخصات و کد منبع قابل انجام است

تست مبتنی بر مدل

تمرکز: آیا تصمیمات لازم اتخاذ می شود؟

• به دانش دامنه و دیدگاه کاربر نیاز دارد
• از مدل ها (مانند جداول تصمیم گیری) برای نشان دادن “چه تصمیماتی باید گرفته شود و چگونه” استفاده می کند
• در دسترس برای غیر مهندسان و ذینفعان بالادست

خلاصه

تست مبتنی بر جدول تصمیم گیری چندین نقاط قوت و مزایای عملی را ارائه می دهد:

• دسته ارزشهای غیر بومی به راحتی (به عنوان مثال ، ظرفیت = هیچ / 0 گیگابایت / 8 گیگابایت / نامحدود)
• درک آسان برای کارشناسان دامنه، برای بررسی و اولویت بندی مفید است
• می تواند تشخیص دهد مشخصات گمشده که اجرا نشده است

جداول تصمیم گیری به عنوان یک عمل می کند پل از فازهای بالادست تا پایین دست.

آنها مشخصات را روشن می کنند ، طراحی و اجرای آن را راهنمایی می کنند و تأیید می کنند که این نرم افزار رفتار می کند همانطور که مشخص شده استبشر

با ترکیب آنها با آزمایش ساختاری ، می توانیم “درست آن را بسازیم” و “ساخت درست”.

این رویکرد دوگانه با پوشش دادن منطق گمشده و اشتباهات اجرای ، نرم افزار با کیفیت بالا را تضمین می کند.