تکنیک های نوشتن تست کیس

در این مطلب شما با تکنیک های طراحی و نوشتن تست کیس (test case design techniques) با رویکرد جعبه سیاه (Black-Box)  و همچنین علت استفاده از آن‌ها آشنا می‌شوید. در مقاله ی تست کیس و تست سناریو به مفاهیم کلی برای نوشتن تست کیس اشاره شده است. دستیابی به آزمایش و تست با کیفیت،نیازمند استفاده از تست کیس مناسب است که با بهره‌بردن از تکنیک های طراحی، این امر دست یافتنی است. انواع متنوعی از تکنیک ها وجود دارد که هر کدام برای شناسایی انواع خطاها و error ها ایجاد شده اند. در نتیجه ما برای هر برنامه و اپلیکیشن باید تست کیس مناسب با هدف آن نرم‌افزار را طراحی کنیم. با این‌کار بصورت عمیق تری نرم افزار بررسی شده و همچنین به پوشش تست (test coverage) مناسب تری دست پیدا می‌کنیم. در ادامه می‌بینیم که روش‌های طراحی تست کیس چیست و یاد می‌گیریم چگونه تست کیس بنویسیم.

تکنیک های طراحی تست کیس

تکنیک‌های طراحی تست کیس به دو قسمت White-Box و Black-Box تقسیم می‌شوند. در این قسمت به برخی از تکنیک‌های رایج در روش Black-Box اشاره می‌کنیم. این تکنیک‌ها عبارتند از:

• Equivalence Partitioning یا پارتیشن بندی هم ارزی
• Boundary Value Analysis یا تحلیل مقدار مرزی
• Decision Table Testing یا جدول تصمیم گیری
• State Transition Testing یا انتقال وضعیت
• Error Guessing

تکنیک Equivalence Partitioning یا پارتیشن بندی هم ارزی

پارتیشن بندی هم ارزی یکی از تکنیک‌های رایج طراحی Test Case است.در این تکنیک دامنه‌های ورودی را به چند قسمت و ناحیه تقسیم می‌کنیم و برای هر ناحیه یک تست درنظر می‌گیریم. با این کار، تعداد Test Case‌ها کاهش پیدا می‌کند.

برای مثال یک input، فقط برای ورودی از جنس عدد دربازه‌ی ۱ – ۱۵ طراحی شده است. هر عددی غیر از این بازه، نامعتبر شناخته می‌شود. یک عدد به دلخواه از این بازه مانند ۵ انتخاب می‌کنیم و خروجی را با این ورودی بررسی می‌کنیم. همچنین انتظار داریم اعداد دیگر هم در این بازه، رفتار مشابهی مانند عدد ۵، از خود نشان دهند. در واقع عدد ۵ یک نماینده برای این بازه درنظرگرفته می‌شود. به هر یک از این نواحی یک کلاس یا پارتیشن گفته می‌شود.

برای پیاده سازی این تکنیک نیاز هست شرایط ورودی‌ها به دقت بررسی شوند و مطابق با سند نیازمندی باشند. بعد از بررسی، ورودی‌ها را به دو دسته‌ی valid و invalid تقسیم می‌کنیم. در مثال قبلی دسته بندی بدین صورت است:

valid : از ۱ تا ۱۵
invalid : بزرگتر از ۱۵ و کوچکتر از ۱

سپس کلاس بندی یا پارتیشن‌ها را ایجاد می‌کنیم. یک کلاس برای بازه‌ی valid و دو کلاس هم برای بازه‌ی invalid. خروجی مانند تصویر زیر می‌شود.

برای هر کلاس یک تست کیس انتخاب می‌کنیم. با این کار، به پوشش تست ۱۰۰٪ با استفاده از این تکنیک، دست پیدا خواهیم کرد. یعنی تمامی سناریو‌های ممکن را (مثبت و منفی) درنظر گرفته‌ایم. معمولا در این روش، یک Test Case، برای تمامی حالات ورودی‌های معتبر کافی است. در حالی که برای ورودی‌های غیر معتبر، باید برای هر حالت یک Test Case درنظرگرفته شود.

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

تکنیک Boundary Value Analysis یا تحلیل مقدار مرزی

این تکنیک از روش Equivalence Partitioning هم استفاده می‌کند و تمرکز اصلی اش بر روی مقادیر مرزی است.چرا که ممکن است بسیاری از خطا‌ها در شرایط مرزی ایجاد شوند. در نتیجه دانستن دقیق دامنه‌ی داده‌ی نیازمندی(Input Domain)، از اهمیت ویژه ای برخوردار است. این تکنیک، مقادیر(Values) را به چند دسته‌ی min, min+, Max -, Max تقسیم می‌کند. در این روش شرایط ورودی و گاهی رابطه ی آن با خروجی را نیز می‌توان بررسی کرد.

مثال ۱)

• فرض کنید شرایط ورودی مانند مثال قبل، ۱-۱۵ است. مانند جدول، مقادیر حداکثری و حداقلی را درنظر می‌گیریم و برای هر کدام یک Test Case درنظر می‌گیریم.
• در این تکنیک حداقل به ۴ تست کیس نیاز داریم تا به پوشش ۱۰۰ درصدی از تست دست پیدا کنیم.

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

تکنیک Decision Table Testing یا جدول تصمیم گیری

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

در این متد ترکیب انواع ورودی‌ها با خروجی مورد انتظار در یک جدول نمایش داده می‌شوند و مطابق با آن تعداد Test Case‌های مورد نیاز بدست می‌آید.

ممکن از برخی از تست کیس های بدست آمده قابل اجرا نباشند که در این صورت آن‌ها را درنظر نمی‌گیریم.

مثال ۱) به جدول زیر توجه کنید. فرض کنید برای ورود در یک سامانه، باید‌ ایمیل و پسورد معتبر وارد کنید.

این جدول از سه قسمت Rules، Conditions و Actions تشکیل شده است. شرایط برای ورود به سامانه، پر کردن فیلد‌های‌ ایمیل و پسورد است. پس۲ شرط (Condition) داریم. Action هم به شرایط خروجی اشاره می‌کند. اگر ورودی‌ها معتبر باشند(true)، وارد می‌شود، اگر نباشد(false)، با خطا مواجه می‌شود. پس خروجی هم ۲ حالت دارد. Rules هم به ترکیب‌های مختلف شرط‌ها (Conditions) اشاره می‌کند. برای بدست آوردن تعداد Test Case‌ها در این روش از فرمول
No of TC = No of Rules = 2^(number of condition)
استفاده می‌کنند.

در این مثال تعداد Test Case‌ ها طبق فرمول برابر با ۴ است (۲ به توان تعداد شروط). پس در نتیجه ۴ Rule باید درنظر بگیریم. این Rules‌ ها بصورت ترکیبی از حالت‌های True و False ایجاد می‌شوند. در این مثال کاربر باید دو فیلد ‌ایمیل و پسورد را وارد کند. اگر هر دو معتبر و صحیح بود، وارد صفحه‌ی اصلی می‌شود، در غیر این صورت با خطا مواجه می‌شود. همانطور که مشاهده می‌کنید برای بررسی این المنت به ۴ Test Case نیاز داریم تا به پوشش کامل از تست برسیم.

مثال ۲)

یک سرویس خرید اینترنتی را در نظر بگیرید. اگر کاربر جدید باشید و اولین بار در اپ ثبت نام کردید ۵۰ درصد تخفیف می‌گیرید، اگر یک کاربر قدیمی و معمولی باشید ۱۰ درصد تخفیف می‌گیرید. همچنین می‌توانید از کد‌های تخفیف ۳۰ درصدی نیز استفاده کنید.

پس سه شرط داریم:

1. New user 50%
2. Old user  10%
3. Discount code 30%

تعداد Test Case‌ها و قوانین طبق فرمول، ۸ عدد می‌شود. (2^Cond). به جدول زیر توجه کنید. در قانون ۳، امکان ندارد که هم کاربر جدید باشید و هم قدیمی، پس این تست رد می‌شود. این شرایط برای قانون‌ها ۳و ۵ و۷ و ۴ هم برقرار است. پس تعداد Test Case‌ها در این مثال به ۴ می‌رسد.

نکته: در دو مثال قبل، حالت های ورودی ها بصورت true و false در نظرگرفته شده است (با توجه به شرایط مسئله). ممکن است این شرایط بصورت مقادیر دیگری هم باشند.

تکنیک State Transition Testing یا انتقال وضعیت

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

برای نمایش این تکنیک از دو روشDiagram و Table استفاده می‌شود.

به مثال ورود در یک سامانه برمی‌گردیم.

ما در این مثال پنج state یا حالت داریم

به دیاگرام رسم شده توجه کنید. همونطور که مشاهده می‌گنید اگر کاربر در تلاش اولش (State 1) پسورد معتبر وارد کند وارد صفحه‌ی اصلی سامانه می‌شود(State 4). اگر نامعتبر و invalid باشد، فرصتی دیگری برای ورود داده می‌شود (State 2) و برای بار دوم پسورد را وارد می‌کند، اگر معتبر باشد، به صفحه اصلی ریدایرکت شده در غیر این صورت به حالت سوم می‌رسد (یعنی دوباره می‌تواند شانسش را برای ورود امتحان کند.) منتهی اگر در سومین تلاشش ورودی نامعتبر وارد کند، در این صورت اکانتش از دسترس خارج می‌شود (State 5)

حال به کمک دیاگرام میتوانیم شرایط را تحلیل و بررسی کنیم و برای همه‌ی حالات Test Case طراحی کنیم.

برای مثال میتوانیم این تست کیس ها را بررسی کنیم:

• وارد کردن پسورد معتبر در اولین گام
• وارد کردن پسورد نامعنبر در اولین گام، سپس وارد کردن پسورد معتبر
• وارد کردن پسورد نامعتبر در اولین و دومین گام، سپس وارد کردن پسورد معتبر
• وارد کردن پسورد نامعتبر در اولین و دومین و سومین گام، سپس وارد کردن پسورد نامعتبر

برای درک حالات مختلف، از جدول هم می‌توان استفاده کرد

تکنیک Error Guessing

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

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

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

نتیجه گیری

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