# matklad: حين يفوت الـ fuzzer خطأً في الكود فالخطأ الأول في الـ fuzzer نفسه

> **المغزى:** إصلاح الحالة التي ظهرت وإضافة اختبار لها يترك الأداة التي فاتتها كما هي، فيعود النوع نفسه من الأخطاء من باب آخر.

- المصدر: المغزى (https://almaghza.com/a/2026-10-01-matklad-fuzzer-oracle-bugs/)
- التاريخ: 20 ربيع الآخر - 1 أكتوبر 2026 (2026-10-01)
- القسم: برمجيات
- الوسوم: Fuzzing، اختبار البرمجيات، Rust

نشر Alex Kladov، المعروف باسم matklad وأحد من بنوا rust-analyzer، مقالة في 19 سبتمبر 2026 عن طريقة للعثور على الأخطاء البرمجية، انطلق فيها من نقاش حول المفاضلة بين الـ generative tests والـ unit tests.

والـ generative tests اختبارات تولّد مدخلات كثيرة تلقائيًا بدل أن يكتبها المبرمج يدويًا حالة بحالة. وفي ذلك النقاش، استدل أحد المشاركين على ضعفها بأن الـ fuzzer الذي استخدمه لم يعثر على خطأ معروف في مكتبة regex. فكتب matklad بنفسه fuzzer صغيرًا، فعثر على ذلك الخطأ، وعلى خطأ ثانٍ لم يكن أحد قد انتبه إليه.

والتقنية التي اعتمد عليها تُسمى oracle، وهي أبسط من اسمها. يكتب المبرمج نسخة ثانية من الخوارزمية نفسها، بطيئة وبسيطة إلى حد أن صحتها واضحة. ثم يولّد مدخلات عشوائية ويقارن نتيجتي النسختين. وكلما اختلفت النتيجتان، ظهر خطأ في إحداهما.

أما القاعدة التي خرج بها، فهي أن الخطأ الذي يمر دون أن يكتشفه الـ fuzzer يُعامل أولًا على أنه خطأ في الـ fuzzer. يُصلَح الـ fuzzer حتى يكتشفه، وبعد ذلك فقط يُصلح الكود ويُضاف الـ unit test.

وتخالف هذه القاعدة العادة الشائعة لدى معظم الفرق، وهي إصلاح الحالة التي ظهرت بعينها وإضافة اختبار لها ثم المضي. وبحسب منطق المقالة، تترك هذه العادة سبب فشل الاكتشاف قائمًا، فيعود النوع نفسه من الأخطاء من مدخل آخر.

ولا ترتبط الفكرة بلغة Rust أو بمكتبة regex تحديدًا، فهي تنطبق على أي دالة معقدة يمكن كتابة نسخة بطيئة وواضحة منها للمقارنة.

## المصادر

- [مقالة matklad الكاملة مع كود الـ fuzzer](https://matklad.github.io/2026/09/19/finding-bugs.html)
- [مدونة matklad](https://matklad.github.io/)
- [توثيق مكتبة proptest](https://docs.rs/proptest/latest/proptest/)