Autotest Assist: تولید تصادفی آزمون برای کیفیت API در اقتصاد ابری

فهرست مطالب

1. مقدمه

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

آزمودن این APIها ذاتاً پیچیده است، به دلیل فضای وسیع توالی‌های فراخوانی ممکن و ترکیب‌های پارامتر، که آزمون جامع را غیرعملی می‌سازد. آزمون جهت‌دار سنتی، پرزحمت است. این مقاله Autotest Assist را معرفی می‌کند، یک ابزار تولید آزمون تصادفی که برای خودکارسازی آزمون API با خواندن مشخصات API، استنتاج یک مدل و تولید آزمون‌ها طراحی شده است، در حالی که نقاط ضعف مشخصات را نیز آشکار می‌سازد.

2. چالش‌های اصلی در تولید آزمون تصادفی API

الگوی تولید آزمون تصادفی شامل انتخاب تصادفی یک تابع API $f()$ و پارامترهای ورودی مجاز آن $p_1, ..., p_k$، اجرای آن و مشاهده خروجی‌ها و اثرات جانبی است. این فرآیند با چندین چالش حیاتی مواجه است.

2.1 اعتبار نحوی و معنایی ورودی

فراتر از تولید ورودی‌های صحیح از نظر نحوی، مولد باید اطمینان حاصل کند که پارامترها به پیش‌شرط‌های API برای موفقیت فراخوانی پایبند هستند. برای مثال، فراخوانی یک API "خرید کتاب" $g()$ نیازمند یک ارجاع معتبر به کتابی است که از یک API "دریافت کتاب" قبلی $f()$ به دست آمده است.

2.2 تأیید رفتاری و مسئله اوراکل

تعیین اینکه آیا یک فراخوانی API مطابق انتظار رفتار کرده است (مسئله اوراکل آزمون) در آزمون تصادفی، به ویژه برای سیستم‌های حالت‌دار، ساده نیست.

2.3 اشکال‌زدایی و جداسازی مشکل

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

2.4 ادغام با مجموعه‌های آزمون رگرسیون جهت‌دار

یک سؤال کلیدی این است که چگونه یک مورد آزمون ارزشمند، که از طریق تولید تصادفی کشف شده است (به ویژه موردی که یک اشکال را آشکار کرده است)، در یک مجموعه آزمون رگرسیون جهت‌دار پایدار ادغام شود.

2.5 ارزیابی پوشش و اعتماد

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

3. رویکرد Autotest Assist

Autotest Assist با تکیه اساسی بر مشخصات API، دو چالش اول را مورد توجه قرار می‌دهد.

3.1 مشخصات API به عنوان پایه

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

3.2 استنتاج مدل و تولید آزمون

از مشخصات، Autotest Assist یک مدل از رفتار API، وابستگی‌ها و حالت آن را استنتاج می‌کند. سپس از این مدل برای هدایت تولید تصادفی توالی‌های فراخوانی API معتبر از نظر نحوی و معنایی استفاده می‌شود.

3.3 آشکارسازی نقاط ضعف مشخصات

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

4. بینش‌های کلیدی و دیدگاه تحلیلی

5. جزئیات فنی و چارچوب ریاضی

هسته Autotest Assist شامل استنتاج مدل از مشخصات است. ما می‌توانیم یک API $f$ را به عنوان یک تابع با پیش‌شرط‌های $Pre_f$ و پس‌شرط‌های $Post_f$ تصور کنیم. حالت سیستم $S$ توسط فراخوانی‌های API تغییر می‌کند.

الگوریتم تولید را می‌توان به صورت زیر انتزاع کرد:

1. مدل: برای هر API $f_i$، $Pre_{f_i}(S, \vec{p})$ و $Post_{f_i}(S, S', \vec{p}, \vec{r})$ را استخراج کنید که در آن $S$ حالت پیشین، $S'$ حالت پسین، $\vec{p}$ پارامترها و $\vec{r}$ نتایج هستند.
2. انتخاب: به طور تصادفی یک API $f_i$ را انتخاب کنید که $Pre_{f_i}(S_{current}, \vec{p})$ قابل برآورده شدن باشد. این نیازمند حل برای $\vec{p}$ با توجه به $S_{current}$ است.
3. تولید: مقادیر عینی برای $\vec{p}$ تولید کنید که $Pre_{f_i}$ را برآورده کنند.
4. اجرا و اعتبارسنجی: $f_i(\vec{p})$ را اجرا کنید، حالت جدید $S'_{observed}$ و نتیجه $\vec{r}_{observed}$ را مشاهده کنید. تأیید کنید که $Post_{f_i}(S_{current}, S'_{observed}, \vec{p}, \vec{r}_{observed})$ برقرار است.
5. به‌روزرسانی حالت: اگر معتبر بود، $S_{current} = S'_{observed}$ را به‌روزرسانی کنید.

چالش، حل کارآمد محدودیت‌ها در مراحل 2 و 3 است، که به مسئله رضایت‌پذیری نظریه‌ها (SMT) مربوط می‌شود.

6. نتایج تجربی و عملکرد

در حالی که گزیده PDF ارائه شده حاوی نتایج کمی خاصی نیست، مقاله معیارهای عملکردی را القا می‌کند که برای ارزیابی حیاتی خواهند بود:

• نرخ کشف اشکال: تعداد و شدت نقص‌های (در پیاده‌سازی و مشخصات) آشکارشده در واحد زمان آزمون در مقایسه با آزمون جهت‌دار.
• نرخ اعتبار توالی: درصد توالی‌های فراخوانی API تولیدشده تصادفی که از نظر معنایی معتبر هستند (یعنی تمام پیش‌شرط‌ها را برآورده می‌کنند)، که اثربخشی مدل را نشان می‌دهد.
• پوشش فضای حالت: معیارهایی در مورد پوشش حالت‌های مختلف سیستم و مرزهای مقدار پارامتر، که احتمالاً با استفاده از ابزارهای پوشش کد یا پروب‌های حالت سفارشی اندازه‌گیری می‌شوند.
• کشف نقاط ضعف مشخصات: یک تحلیل کیفی از انواع ابهامات یا خطاهای یافت‌شده در مشخصات API در مرحله مدل‌سازی.

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

7. چارچوب تحلیل: یک مثال غیرکدی

یک "API کتابفروشی" ساده‌شده را با دو عملیات در نظر بگیرید:

1. GET /book/{id}: جزئیات کتاب را برمی‌گرداند. پیش‌شرط: کتابی با `{id}` باید در موجودی وجود داشته باشد.
2. POST /cart/{bookId}: یک کتاب را به سبد خرید اضافه می‌کند. پیش‌شرط: کتاب با `{bookId}` باید در دسترس باشد (وجود داشته باشد و موجود باشد).

گردش کار Autotest Assist:

1. استنتاج مدل: ابزار مشخصات را می‌خواند و وابستگی را می‌آموزد: `POST /cart` نیازمند یک فراخوانی موفق `GET /book` اول است (برای اثبات وجود/دسترسی).
2. تولید آزمون: به طور تصادفی تصمیم می‌گیرد `POST /cart/{bookId}` را آزمون کند.
3. حل پارامتر: برای برآورده کردن پیش‌شرط، ابتدا باید یک `bookId` معتبر تولید کند. ممکن است این کار را با یکی از روش‌های زیر انجام دهد:
   الف) فراخوانی `GET /book` با یک ID تصادفی تا زمانی که یکی موفق شود (کاوش).
   ب) استفاده از یک لیست شناخته‌شده از IDها از یک اجرای آزمون قبلی یا داده‌های اولیه.
   سپس از این `bookId` معتبر برای فراخوانی `POST /cart` استفاده می‌کند.
4. کشف نقطه ضعف: اگر مشخصات `POST /cart` فقط به "کتاب باید وجود داشته باشد" اشاره کند اما پیاده‌سازی سطح موجودی را نیز بررسی کند، آزمون تصادفی ممکن است شکست بخورد. Autotest Assist این را به عنوان یک نقطه ضعف مشخصات علامت‌گذاری می‌کند: پیش‌شرط در مشخصات ناقص است.
5. ادغام رگرسیون: توالی `[GET /book/valid_id, POST /cart/valid_id]` که با موفقیت یک مورد را به سبد خرید اضافه کرد، به عنوان نامزد برای مجموعه آزمون رگرسیون جهت‌دار ذخیره می‌شود.

8. کاربردهای آینده و جهت‌های پژوهشی

• استنتاج مشخصات تقویت‌شده با هوش مصنوعی: یکپارچه‌سازی مدل‌های زبانی بزرگ برای تفسیر زبان طبیعی یا مشخصات ناقص و پیشنهاد پیش‌شرط/پس‌شرط‌های رسمی، کاهش بار ایجاد مشخصات کامل از ابتدا.
• تولید تطبیقی و هدایت‌شده با بازخورد: حرکت فراتر از تصادفی بودن محض برای استفاده از یادگیری تقویتی. مولد می‌آموزد که کدام توالی‌های API و مقادیر پارامتر احتمال بیشتری برای یافتن اشکالات جدید یا کاوش فضای حالت پوشش‌نیافته دارند، مشابه تکنیک‌های در Fuzzing تطبیقی.
• آزمون بین‌سرویسی و یکپارچه‌سازی: گسترش مدل برای درک وابستگی‌ها و قراردادهای بین ریزسرویس‌های فروشندگان مختلف، تولید آزمون برای گردش‌های کاری پیچیده چندسرویسی و سناریوهای شکست (مانند الگوهای قطع مدار).
• آزمون انطباق و امنیت: گنجاندن سیاست‌های امنیتی (مانند محدوده‌های OAuth، قوانین حریم خصوصی داده) در مدل برای تولید خودکار آزمون‌هایی که هم الزامات انطباق عملکردی و هم غیرعملکردی را اعتبارسنجی می‌کنند.
• نظارت و آزمون زنده API: استفاده از همان مدل برای تولید یک مجموعه آزمون کم‌حجم و پیوسته که در برابر محیط‌های تولید یا مرحله‌بندی اجرا می‌شود تا رگرسیون‌ها یا انحراف مشخصات را در زمان واقعی تشخیص دهد.

9. منابع

1. Farchi, E., Prakash, K., & Sokhin, V. (2022). Random Test Generation of Application Programming Interfaces. arXiv preprint arXiv:2207.13143v2.
2. Myers, G. J., Sandler, C., & Badgett, T. (2011). The Art of Software Testing. John Wiley & Sons. (برای اصول پایه‌ای آزمون).
3. Osterweil, L., et al. (2020). Shifting Left: The Economic Impacts of Early Defect Detection. Carnegie Mellon University, Software Engineering Institute. (برای تحلیل هزینه-فایده آزمون زودهنگام).
4. Google Testing Blog. (2019). Fuzzing at Scale. Retrieved from https://testing.googleblog.com/. (برای بینش‌های عملی در مورد آزمون تصادفی در مقیاس بزرگ).
5. de Moura, L., & Bjørner, N. (2008). Z3: An Efficient SMT Solver. Tools and Algorithms for the Construction and Analysis of Systems. (برای پایه فنی در حل محدودیت مورد استفاده در تولید آزمون).
6. OpenAPI Initiative. (2023). OpenAPI Specification v3.1.0. https://spec.openapis.org/oas/v3.1.0. (برای استاندارد در مشخصات API قابل خواندن توسط ماشین).