انواع تست نرم افزار: هدف‌های تست

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

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

تست کارکردی (Functional Testing)

کارکرد یک سیستم یا یک جزء از سیستم، آنچه که انجام می‌دهد، می‌باشد. بطور معمول کارکرد سیستم در مشخصات نیازمندی های سیستم، الزامات سیستم یا use caseها توصیف می‌شود.

ممکن است برخی از کارکردهایی وجود داشته باشند که "فرض می شود" ارائه می شوند که مستند نیستند و همچنین بخشی از الزامات یک سیستم نیز هستند. در این صورت تست بر اساس الزامات غیرمستند و ضمنی دشوار خواهد بود.

تست های کارکردی بر اساس توابع هستند که در اسناد شرح داده شده یا توسط آزمونگرها درک شده است و ممکن است در تمام سطوح تست انجام شود.

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

تست کارکردی می‌تواند بر اساس استاندارد ISO 9126، با تمرکز بر مناسب بودن، قابلیت همکاری، امنیت، دقت و انطباق انجام شود. به عنوان مثال، تست امنیت، عملکردهای مربوط به تشخیص تهدیدها همچون ویروس‌ها از طرف افراد خارجی مخرب را بررسی می‌کند.

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

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

تست غیرکارکردی نرم افزاری (Non-functional Testing)

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

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

بسیاری تلاش کرده اند تا کیفیت نرم افزار را در مجموعه ای از ویژگی های مربوط به آن ثبت کنند. در این مدلها برخی از ویژگیهای اولیه همچنان ظاهر می‌شوند اگرچه جایگاه آنها در سلسله مراتب می‌تواند متفاوت باشد. سازمان بین المللی استاندارد (ISO) مجموعه‌ای از ویژگی‌های کِیفی را تعریف کرده است. این مجموعه گامی مهم در جهت اجماع در صنعت فناوری اطلاعات شده و بدین ترتیب مفهوم کلی کیفیت نرم افزار را مورد بررسی قرار می دهد. استاندارد ISO 9126 شش ویژگی کیفی و تقسیم هر ویژگی کیفی را به تعدادی از ویژگی‌های فرعی مشخص می‌سازد.

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

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

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

 قابلیت استفاده (سهولت کاربری) که به ویژگی‌های فرعی قابلیت فهم، یادگیری، قابلیت اجرا، جذابیت و انطباق تقسیم می‌شود.

 بهره‌وری که به رفتار در قالب زمان (کارایی)، استفاده از منابع و انطباق تقسیم می‌شود.

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

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

تست ساختاری (Structural Testing)

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

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

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

تکنیک‌های مورد استفاده برای آزمون ساختاری، تکنیک‌های مبتنی بر ساختار هستند که به آنها تکنیک‌های جعبه سفید نیز گفته می‌شود. مدل‌های جریان کنترل (control flow graphs) اغلب برای پشتیبانی از آزمون ساختاری استفاده می‌شوند.

تست‌ تغییرات نرم‌افزار (تست رگرسیون و تست تایید)

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

تست تایید (تست مجدد)

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

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

تست رگرسیون (Regression Testing)

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

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

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

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

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

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