آزمون ویژگی‌محور چگونه خطاهای پنهان را پیدا می‌کند؟

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

تولید تصادفی به‌تنهایی آزمون خوبی نمی‌سازد. کیفیت کار به ویژگی روشن، مولد واقع‌بینانه، کوچک‌سازی شکست و بازتولید قابل‌اعتماد وابسته است. این روش جای آزمون‌های نمونه‌ای، مرور کد یا آزمون یکپارچگی را نمی‌گیرد؛ در کنار آن‌ها راهی برای کشف مرزهایی است که نویسندهٔ آزمون دستی شاید به ذهنش نرسد.

آزمون مبتنی بر ویژگی چیست؟

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

این رویکرد در ادبیات نرم‌افزار گاهی آزمون مولد یا آزمون مبتنی بر ویژگی نامیده می‌شود و با آزمون تصادفی بی‌قید فرق دارد. مولد باید ورودی‌هایی بسازد که دامنهٔ واقعی برنامه را نمایندگی کنند و ویژگی باید معنای مورد انتظار را بیان کند. برای مسیر کلی تبدیل ایده به برنامه، مبانی اجرای کد زمینه می‌دهد؛ اینجا تمرکز بر چگونه آزمودن رفتار است.

یک ویژگی خوب چه شکلی دارد؟

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

ویژگی‌ای که صرفاً همان الگوریتم را دوباره پیاده کند ممکن است همان خطا را تکرار کند. از چند خاصیت مستقل استفاده کنید: حفظ اندازه، یکتایی، ترتیب، محدودیت دامنه یا رابطهٔ رفت‌وبرگشت. هر ویژگی باید روشن کند چه چیزی تضمین می‌شود و چه چیزی نه. در محاسبات ممیز شناور، برابری دقیق شاید مناسب نباشد؛ تلورانس باید از نیاز مسئله و خطای عددی ناشی شود.

یک ویژگی جبری می‌تواند رابطه‌ای مانند جابه‌جایی عمل‌ها یا حفظ یک ناوردا باشد، اما باید پیش‌شرط دامنه را نیز بگوید. جمع اعداد صحیح و ممیز شناور رفتار یکسان ندارند، زیرا گردکردن و سرریز اثر می‌گذارند. اگر ویژگی از تابعی استفاده کند که همان خطای احتمالی را دارد، دو کد نادرست ممکن است یکدیگر را تأیید کنند؛ مرجع مستقل یا رابطهٔ دوم این خطر را کاهش می‌دهد.

آزمون مبتنی بر ویژگی با fuzzing هم‌پوشانی دارد، اما همیشه هدف یکسانی ندارد. فازر ممکن است پوشش شاخه یا یافتن crash را دنبال کند، در حالی که آزمون ویژگی یک رابطهٔ معنایی را به‌عنوان oracle می‌سنجد. ابزارهای مدرن می‌توانند هر دو ایده را ترکیب کنند: ورودی را کاوش کنند و هم‌زمان ناورداها را بررسی کنند. مهم است پیشاپیش بدانید معیار موفقیت چیست و کدام نوع شکست ثبت می‌شود.

مولد ورودی چگونه فضای حالت را می‌پوشاند؟

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

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

در مولد می‌توان وزن بیشتری به مرزها یا الگوهای کم‌احتمال داد. برای مثال، شناسهٔ معتبر و رشتهٔ تقریباً معتبر هر دو ممکن است لازم باشند؛ رشتهٔ ناقص مسیر خطای پارسر را می‌آزماید. برچسب‌گذاری دسته‌های تولیدشده نشان می‌دهد مولد چه سناریوهایی را پوشش داده است. اگر ورودی‌های زیادی رد شوند، بهتر است مولد از ابتدا دادهٔ معتبر بسازد تا زمان آزمون در فیلترکردن تلف نشود.

مولد سازنده معمولاً بهتر از تولید کور عمل می‌کند: برای درخت نحوی معتبر، ابتدا گره می‌سازد و سپس عملگر و فرزندها را با محدودیت عمق انتخاب می‌کند. برای اعداد، وزن‌دهی به صفر، مرز دامنه و مقادیر نزدیک سرریز احتمال کشف خطا را بالا می‌برد. seed و اندازهٔ نمونه باید قابل‌تنظیم باشد تا آزمون سریع محلی و آزمون گستردهٔ پیوسته از یک مولد مشترک بهره ببرند.

محصول اورجینال INZIP

قالب وردپرس باریستا مخصوص کافه تم نسکافه ای روشن (دو زبانه)

دانلود پوسته وردپرس باریستا؛ قالب کافیشاپ، رُستری قهوه و فروشگاه قهوه دوزبانه با منوی رومیزی، رزرو آنلاین میز با کد پیامکی و ووکامرس. طراحی اختصاصی inzip.ir

تحویل آنی آپدیت رایگان بدون قفل لایسنس پشتیبانی واقعی

۳,۹۹۰,۰۰۰ تومان ۲,۹۶۰,۰۰۰ تومان

بازدید و دانلود آنی

٪۲۶

تخفیف ویژه

سود شما

۱,۰۳۰,۰۰۰ تومان

کوچک‌سازی چگونه نمونهٔ شکست را ساده می‌کند؟

وقتی یک ورودی بزرگ ویژگی را نقض می‌کند، چارچوب تلاش می‌کند آن را به نمونه‌ای کوچک‌تر کاهش دهد که همچنان شکست می‌خورد. برای فهرست، این کار می‌تواند حذف عضوها یا ساده‌کردن مقدارها باشد؛ برای متن، کوتاه‌کردن رشته و کاهش نمادها. نمونهٔ کوچک معمولاً علت را آشکارتر می‌کند و تبدیل آن به آزمون بازگشتی را آسان‌تر می‌سازد.

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

برای ساختارهای پیچیده، کوچک‌سازی به راهبرد دامنه‌ای نیاز دارد. مولد گراف می‌تواند رأس‌ها یا یال‌های اضافی را حذف کند، اما باید شرط اتصال یا بی‌چرخه‌بودن را حفظ کند. نوشتن reducer سفارشی زمان‌بر است، ولی نمونهٔ شکست کوتاه و فهم‌پذیر می‌سازد. اگر کاهش ممکن نباشد، ثبت ورودی خام و شرایط محیطی هنوز برای بازتولید خطا ارزشمند است.

ویژگی‌ها خطاهای مرزی را آشکار می‌کنند

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

این مزیت به معنی پوشش کامل نیست. اگر مولد هیچ‌گاه حالت مهمی نسازد یا ویژگی نادرست باشد، آزمون موفق کاذب می‌شود. برای افزایش ارزش، مولد را از قرارداد واقعی ورودی بسازید و توزیع آزمون را بازبینی کنید. سنجش پوشش کد می‌تواند نشان دهد چه شاخه‌هایی اجرا شده‌اند، اما پوشش بالا به‌تنهایی ثابت نمی‌کند ویژگی‌ها همهٔ رفتارهای مهم را بررسی کرده‌اند.

تکرارپذیری در آزمون تصادفی چگونه حفظ می‌شود؟

ابزار معمولاً از بذر شبه‌تصادفی استفاده می‌کند؛ ثبت آن اجازه می‌دهد توالی ورودی‌ها دوباره ساخته شود. اگر آزمون شکست، نسخهٔ چارچوب، بذر، تنظیمات مولد و وضعیت وابستگی‌ها را نگه دارید. بدون این اطلاعات، خطایی که فقط گاه‌به‌گاه رخ می‌دهد دشوارتر بازتولید می‌شود. گاهی ورودی نهایی کوچک‌شده از بذر هم مهم‌تر است و باید در گزارش ذخیره شود.

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

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

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

آزمون‌های حالت‌مند چه چیزی را بررسی می‌کنند؟

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

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

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

چطور از ویژگی نادرست یا بدیهی دوری کنیم؟

ویژگی باید به نیاز مستقل تکیه کند، نه اینکه خروجی تابع را با همان منطق داخلی دوباره محاسبه کند. مثال‌های مرجع، استانداردهای فرمت و ناورداهای دامنه می‌توانند مبنا باشند. اگر ویژگی بیش از حد کلی باشد، برنامهٔ معیوب هم از آن عبور می‌کند؛ اگر بیش از حد سخت باشد، ورودی معتبر را رد می‌کند. بازبینی ویژگی به اندازهٔ بازبینی کد اهمیت دارد.

برای یک تابع رمزگذاری، شاید ویژگی «رمزگشایی پس از رمزگذاری دادهٔ اولیه را بازیابد» کافی نباشد؛ دو تابع معیوب ممکن است با هم سازگار باشند. نمونه‌های شناخته‌شده، آزمون سازگاری میان پیاده‌سازی‌ها و بررسی قالب استاندارد کمک می‌کنند. دربارهٔ عددها، واحدها، دقت و پیش‌شرط‌ها صریح باشید. یک آزمون سبز فقط می‌گوید ویژگی نوشته‌شده نقض نشده، نه اینکه همهٔ نیازها درست‌اند.

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

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

آزمون مبتنی بر ویژگی با چه روش‌هایی ترکیب می‌شود؟

آزمون واحدی برای نمونه‌های ثابت، آزمون مبتنی بر ویژگی برای گسترهٔ ورودی، آزمون یکپارچگی برای تعامل اجزا و آزمون سامانه برای مسیر کاربر نقش‌های متفاوت دارند. برای آزمایش علمی، مقالهٔ طراحی آزمایش بر متغیرها و تکرار تأکید می‌کند؛ آزمون نرم‌افزار نیز از فرض روشن و ثبت شرایط سود می‌برد، هرچند هدف و معیار آن‌ها یکی نیست.

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

آزمون رابط کاربری با ویژگی می‌تواند محدودیت‌های قابل‌شمارش را بررسی کند، مانند اینکه پس از ثبت فرم، داده در فهرست دیده شود؛ اما برداشت دیداری یا رضایت کاربر به معیار دیگری نیاز دارد. روش را متناسب با خروجی انتخاب کنید. آزمون مولد مکمل بازبینی انسانی و آزمون دسترس‌پذیری است، نه جانشین آن‌ها. گزارش باید شکست را به زبان قابل‌فهم برای نگهدارندهٔ کد تبدیل کند.

چه وقت این روش بیشترین ارزش را دارد؟

وقتی فضای ورودی بزرگ است، قواعد کلی و قابل‌بیان دارید و خطاهای مرزی هزینه‌سازند، آزمون مبتنی بر ویژگی می‌تواند ارزش زیادی داشته باشد. تبدیل داده، پارس، ساختارهای الگوریتمی و عملیات روی مجموعه‌ها نمونه‌های مناسبی هستند. در مقابل، بررسی ظاهر رابط یا متنی که پاسخ مورد انتظارش کاملاً انسانی است، همیشه با یک ویژگی کوتاه سنجیده نمی‌شود.

شروع را با یک تابع کوچک و یک قاعدهٔ معنادار انجام دهید، سپس کیفیت مولد و گزارش شکست را ارزیابی کنید. اگر نمونهٔ شکست در پرونده ثبت می‌شود، شناسه‌ای قراردادی مانند «آزمون ۱۱۵» فقط برچسب پیگیری است، نه اندازهٔ پوشش یا کیفیت آزمون. معیار واقعی، توان کشف نقص‌های مرتبط و امکان بازتولید و اصلاح آن‌هاست؛ شمار ورودی‌ها به‌تنهایی نشانهٔ کیفیت نیست.

این روش هنگام بازنویسی یا بهینه‌سازی سودمند است: ویژگی ثابت می‌ماند و پیاده‌سازی‌های قدیم و جدید روی ورودی‌های یکسان مقایسه می‌شوند. می‌توان ورودی‌ها را از لاگ‌های پالایش‌شده نیز استخراج کرد، مشروط به حذف اطلاعات حساس. شکست‌های ارزشمند را به آزمون ثابت منتقل کنید و مولد را دوره‌ای با ورودی‌های واقعی بازبینی کنید.