عیبیابی
عیبیابی BDL بر شواهد تکیه دارد. وقتی عملیاتی شکست میخورد یا نتیجهای غیرمنتظره تولید میکند، پیش از تغییر تعریف یا Runtime، رخداد را طبقهبندی کنید.
دستههای رخداد
مدل فعلی عیبیابی شش دستهٔ اصلی دارد:
| دسته | معنی |
|---|---|
BDL_AUTHORING_DEFECT | BDL تألیفشده نادرست یا نامعتبر است. |
PREEXEC_DETECTION_GAP | BDL نامعتبر است، اما اعتبارسنجی پیش از اجرا باید آن را تشخیص میداد. |
RT_RUNTIME_BUG | Runtime کنترلشده با وجود ورودی معتبر و پشتیبانیشده، نادرست رفتار میکند. |
ENVIRONMENT_OR_BASELINE | خطا ناشی از تفاوت محیط، نصب، نسخهٔ مبنا، وابستگی یا پیکربندی است. |
KNOWN_GAP_OR_UNSUPPORTED | رفتار درخواستی یک شکاف مستند، محدودیت یا عملیات پشتیبانینشده است. |
INSUFFICIENT_EVIDENCE | شواهد قابلاعتماد برای طبقهبندی یا بستن رخداد کافی نیست. |
دستههای رخداد را ادغام نکنید
رفع خطای تألیف خودبهخود نقص اعتبارسنجی را نمیبندد. برای مثال، اگر سند نامعتبر BDL به اجرا برسد، در حالی که Preflight یا ValidateOnly باید آن را رد میکرد، دو مسئلهٔ جدا وجود دارد:
- نقص تألیف
- نقص تشخیص پیش از اجرا
هر دو باید مستقل پیگیری شوند.
شواهد الزامی رخداد
گزارش مفید رخداد Runtime باید تا حد امکان شواهد همان اجرا را حفظ کند. موارد زیر را گردآوری کنید:
- فایل دقیق BDL استفادهشده
- هش یا هویت پایدار آن فایل
- گزارش اجرای همان نوبت
- نسخهٔ مبنای Runtime و بستهها
- نتیجهٔ کامپایل یا ValidateOnly، در صورت وجود
- طرح اجرا
- نتیجهٔ ساختیافتهٔ اجرا
- نتیجهٔ بررسی پس از اجرا یا خروجیگیری
- رفتار مورد انتظار
- رفتار واقعی
بدون این شواهد، ممکن است رخداد همچنان در دستهٔ INSUFFICIENT_EVIDENCE باقی بماند.
روند بررسی اولیه
برای بررسی مشکل این ترتیب را دنبال کنید:
- ورودی دقیق و شواهد اجرا را حفظ کنید.
- نسخههای BDL، Runtime و قرارداد را تأیید کنید.
- تجزیه و اعتبارسنجی را بدون تغییر داده دوباره اجرا کنید.
- دسترسپذیری قابلیت و محدودیتهای شناختهشده را بررسی کنید.
- تأیید کنید فرادادهٔ بومی لازم تعیین شده و حدس زده نشده است.
- طرح اجرا و پیامهای تشخیصی را بازبینی کنید.
- مشخص کنید آیا واقعاً تغییری رخ داده است.
- فرادادهٔ بومی را مستقل دوباره بارگذاری کنید.
- در صورت پشتیبانی، خروجیگیری یا رفتوبرگشت انجام دهید.
- دستهٔ رخداد را بر اساس شواهد تعیین کنید.
ممکن است تغییر پیش از استثنا موفق شده باشد
استثنا همیشه ثابت نمیکند که تغییر شکست خورده است. در برخی عملیات بومی، استثنا پس از اعمال تغییر زیربنایی رخ میدهد. بنابراین نتیجهٔ واقعی را با بارگذاری مستقل یا بررسی پس از اجرا تعیین کنید و فقط به استثنا تکیه نکنید.
وضعیت بومی ناموجود را اختراع نکنید
منطق خروجیگیری و تألیف نباید مقادیری را بسازد که بهطور قابلاعتماد از Native Barsa بازیابی نمیشوند. اگر وضعیت بومی بدون اتلاف قابل خواندن نیست، محدودیت یا پیام تشخیصی را گزارش کنید.
موفقیت build اثبات رفتار Runtime نیست
build یا کامپایل موفق فقط لایهای را تأیید میکند که واقعاً آزمایش شده است. بهتنهایی این موارد را ثابت نمیکند:
- ذخیرهشدن در لایهٔ بومی
- اجرای Runtime
- رفتار مرورگر
- برابری خروجی
- صحت رفتوبرگشت
- دسترسپذیری تألیف برای محیط عملیاتی
هر ادعا را فقط با شواهد همان لایه تأیید کنید.
نمونههای تشخیصی فعلی
نسخهٔ مبنای فعال عیبیابی شامل پیامها و محدودیتهای مستندی مانند این موارد است:
- نقص اتصال شرطی گردشکار، وقتی اتصال شرط بومی واقعاً ناقص است
- محدودیت خروجیگیری بدون اتلاف، وقتی وضعیت بومی لازمِ فرم بازیابی نمیشود
- عملیات حذف بومی که ممکن است به تأیید از طریق بارگذاری مستقل نیاز داشته باشند
- قواعد کسبوکار که بدون رویداد پشتیبانیشده قابل خروجیگیری نیستند و نباید رویداد ساختگی دریافت کنند
این موارد به نسخه وابستهاند؛ همیشه فهرست فعال پیامهای تشخیصی و محدودیتهای شناختهشده را بررسی کنید.
اصل ارجاع مسئله
وقتی شواهد موجود نشاندهندهٔ مشکل Runtime یا اعتبارسنجی است که با اصلاح BDL یا محیط رفع نمیشود، رخداد را برای بررسی تخصصی ارجاع دهید.
عملیات پشتیبانینشده یا دارای محدودیت مستند را بهعنوان نقص Runtime ارجاع ندهید، مگر آنکه شواهد جدید با قرارداد فعال تناقض داشته باشد.
ادامه
برای محدودیتهای مستند، سطوح بهتعویقافتاده و محدودیتهای وابسته به نسخه، بخش محدودیتهای شناختهشده را مطالعه کنید.