se2 7 software testing

2مهندسی نرم افزار

تست نرم افزارمحسن کامیار

دانشگاه فردوسی مشهد

تست نرم افزار

همان طور که می دانیم در روند تولید نرمافزار پارامترهای زیادی تأثیرگذار هستند.

ارتباط بین عوامل دخیل در تولید درک تولید کننده از یک مفهوم انتزاعی سطح

باال برای دستیابی به یک برنامه عملیاتی و قابل اجرا

خطاهای انسانی...

از این رو باید در هر روند تولید مرحلهتست نیز وجود داشته باشد.


اهداف تست تست فرآیندی است که در انگیزه اصلی از

پیگیری آن یافتن یک خطا است یک نمونه تست خوب است اگر بیشترین احتمال

را برای یافتن خطای کشف نشده ای داشته باشد یک نمونه تست موفق، نمونه ای است که بتوان

یک خطای کشف نشده تا کنون را بیابد. در نهایت هدف طراحی یک روند تست است

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


یکی دیگر از مهم ترین کاربردهای تست ایناست که از این طریق می توان معیار خوبی برای ارزیابی قابلیت اطمینان نرم افزارهای

تولیدی دست یافت. پس از تکمیل تست، نمی توان نرم افزار را

بدون خطا فرض نمود، بلکه تنها نشان می دهد خطاهایی در سیستم وجود دارد. میزان و نوع این خطاها نشان دهنده قابلیت اطمینان نرم

افزار می باشد.


مفاهیم اصلی تمام تست ها باید در راستای نیازهای مشتری

صورت گیرند تمام سناریوهای تست باید پیش از شروع آن

برنامه ریزی شوند اصل‘Pareto’ درصد از 80 بیان می کند که

درصد از اجزاء 20خطاهای یافت نشده در سیستم وجود دارند. پس یک فعالیت مهم یافتن این اجزاء و تنها تست آن ها است.


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

باید تنها برروی یک جزء انجام شوند، سپس برروی مجموعه ای از چند عضو و در نهایت

برروی تمام سیستم. در یک تست نمی توان تمام سناریوهای اجرای

نرم افزار را پوشش داد، بلکه باید تنها به پوشش دادن منطق و شرایط مختلف موجود در منطق

اکتفا نمود..تست باید توسط افراد ثالث صورت گیرد


قابلیت تست قابلیت تست برای یک نرم افزار عبارت است

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

داد. از جملهلیست موارد مهم در منطقلیست داده های مرزی...

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


( عملیاتی بودنoperability نرم افزاری که به صورت :)عملیاتی در حال استفاده می باشد دارای باگ های کمتری

است، هیچ باگی باعث محدود شدن عملیات تست نمی گردد و عملیات تست و برطرف کردن آن ها می توانند به

صورت همزمان پیگیری شوند.( قابلیت مشاهدهObservability باید بتوان آنچه را که :)

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

ای از حالت ها و متغیرهای سیستم وجود داشته باشد، تمام موارد تأثیرگذار در خروجی باید مشخص باشند، خروجی

نادرست باید به راحتی قابل تشخیص باشند، خطاهای داخلی باید در طول تست خودکار نرم افزار کشف شوند، سورس

نرم افزار در دسترس باشد.


( قابلیت کنترلControllability هر چه بتوان بهتر نرم :)افزار را کنترل نمود می توان روال تست را بیشتر به

سمت تست خودکار پیش برد. از جمله عوامل مهم عبارتند از: بتوان تمام خروجی ها را با استفاده از ترکیبی از ورودی

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

افزار باید قابل کنترل توسط تست کننده باشند، قالب های ورودی و خروجی باید مشخص باشند، تست ها باید بتوانند

خودکار انجام شوند و قابل تکرار باشند.( قابلیت تجزیهDecomposability هر چه بتوان حوزه :)

تست را کوچک تر نمود، تست راحت تر انجام خواهد شد. موارد مهم عبارتند از: نرم افزار از اجزاء کامال مستقل

ساخته شده باشد، اجزاء سیستم را بتوان کامال مجزا از هم تست نمود.


( سادگیSimplicity هر چه حجم تست کمتر باشد هزینه :)ها پایین تر می آید: سادگی کارکرد )لیست ویژگی ها باید کمترین میزان ممکن برای برآوردن نیازها باشد(، سادگی ساختار )ساختار باید کامال براساس ماژول ها باشد تا از

گسترش خطاها جلوگیری شود(، سادگی کد )باید یک استاندارد کدینگ برای راحتی نگهداری وجود داشته باشد(.

( پایداریStability هر چه حجم تغییرات کم تر باشد :)عملیات تست کمتر است: تغییرات در نرم افزار بسیار کم رخ دهند، تغییرات در نرم افزار کامال کنترل شده و

براساس روال مشخص صورت گیرند، تغییرات تست های انجام شده را باطل نکنند و نرم افزار را بتواند در صورت

بروز خطا موارد را گزارش و به درستی عمل کند.


قابلیت شناخت بهتر: بتوان به سادگی طراحی رادرک نمود، وابستگی های بین اجزاء مختلف مشخص باشند، تغییرات در طراحی گزارش

شوند، مستندات فنی با دقت و کیفیت مناسب موجود باشند.


برای دستیابی به یک تست خوب باید درراستای زیر حرکت نماییم:

مدل ذهنی از برنامه را ایجاد کنیم و سعی کنیمدسته های خطا را تشخیص دهیم. به عنوان مثال خطا در تشخیص محل موس در یک رابط کاربر

گرافیکی تست ها نباید حتی المقدور همپوشانی داشته باشند

زیرا باعث تست شدن بیش از یک بار قسمت هایی از کد می شوند و در نتیجه منابع را هدر می دهند.


را به عنوان 8080برای مثال فرض کنیم کلمه عبور کلمه عبور کلیدی سیستم در نظر گرفته ایم.

باشد. حال 1234نمونه اول تست می تواند رشته یک افزونگی تست را ایجاد می 1235کلمه عبور

می تواند نمونه خوب بعدی باشد.8081کند. اما در یک مجموعه از تست ها که همگی برای یک

دسته خاص از خطاها طراحی شده اند باید بهترین زیرمجموعه برای هدر نرفتن منابع انتخاب شود.

.یک تست نباید خیلی پیچیده و نه خیلی ساده باشد


طراحی تست: به صورت کلی می توانتست ها را به دو دسته زیر تقسیم نمود:

تنها در مورد کارکردهای سیستم اطالعاتیداریم و سیستم نیز در حال حاضر در حال

عملیات می باشد. )تست جعبه سیاه( در مورد مشخصات ریز نحوه عمل اجزاء

مختلف اطالعاتی داریم و از این طریق می توان به راحتی شرایط مختلف برنامه و مواردی از این دست را تست نمود. )تست جعبه سفید(


کامال واضح است که تست جعبه سفید درصورت کامل بودن می تواند تمام خطاها را

کشف نماید. اما به علت وجود مسیرهای منطق بسیار گوناگون در سطح برنامه طراحی

چنین تستی غیر ممکن و در صورت امکان غیرقابل اجرا خواهد بود.

باید سعی کنیم با ترکیب دو دسته تست ذکرشده، سناریوی تستی طراحی نماییم که بتواند

نیازها را برآورده سازد.

تست جعبه سفید

اصطالحا به این روش تست جعبه شیشه اینیز گفته می شود.

در این روش از منطق موجود در برنامه برایتعیین داده های تست استفاده می شود.

پس از طراحی و انجام چنین تستی می توانبه نتایج زیر دست یافت:

تمام مسیرهای مستقل تست شده اند تمام تصمیم های منطقی به صورت کامل تست

شده اند


.تمام حلقه ها برروی مرزهایشان تست شده اند.ساختار داده های داخلی تست کامل شده اند

باید تصمیم گرفت که چرا به جای صرف وقتدر مورد تست جعبه سفید نباید به دنبال تست

کارکردهای مورد انتظار از سیستم برویم؟ برای جواب دادن به آن باید به دنبال ماهیت

خطاها گشت: خطاهای منطقی و فرض هایی که ممکن است در

نظر گرفتن آن ها برخالف واقع باشد.


ممکن است بعضی از قسمت های برنامه با توجهبه طراحی اولیه واسط کاربر در دسترس نباشند.

بسیاری از مواقع خطاها ناشی از ناسازگاری بیننوع داده ها می باشد که تنها در صورت تست

منطق برنامه قابل کشف هستند. پس برای دستیابی به موارد باال و همچنین

اجتناب از هزینه چنین تستی باید بتوانیم تست های جعبه سفید را در مواردی که مسیرهای

منطقی پیچیده داریم استفاده نماییم.

تست مسیر اصلی

.یکی از روش های تست جعبه سفید است در ابن روش سعی می کنیم تا مسیهای

منطقی موجود را از درون توابع مختلف استخراج کنیم و تمام دستورات دخیل در

یک روال را تست نماییم. برای اینکه بتوانیم به این تست دست یابیم

باید یک گراف جریان یا گراف کنترل از برنامه خود تولید نماییم.


نمونه ای از این گراف را می توان در شکلزیر مشاهده نمود )ساختاری مشابه با تمام

انواع فلوچارت ها(.

در این روش باید فلوچارت اولیه دارای هیچنوع شرط پیچیده نباشد.


برای تعیین حداکثر تعداد تست های مورد نیاز از استفاده Cyclomatic Complexityمعیاری به نام

می کنیم. ابتدا باید تعدادindependent path ها را به دست

آوریم. یک مسیر مستقل مسیری است که یالی را که در

مجموعه مسیرهای مستقل دیده نشده است مشاهده نماید.

به مجموعه به دست آمده از این مسیرهاBasis Set.می گوییم


اگر تستی بتواند تمام مسیرهای موجود درمجموعه پایه را پوشش دهد آنگاه تمام شرایط

و دستورات برنامه تست شده اند..مسلما مجموعه پایه یکتا نیست حال برای محاسبهcyclomatic complexity می

توانیم از معیارهای زیر استفاده نماییم. تعداد ناحیه های گراف جریان )ناحیه های محصور

بین یالها( فرمولE-N+2 که E تعداد یال ها و N تعداد

نودهاست.


و یا فرمولP+1 که P تعداد predicate node ها در گرافجریان است. )نودهایی که نمایش دهنده یک شرط

هستند و بیش از یک یال از آن ها خارج می شود( این معیار حد باالیی را برای تعداد مسیرهای

مجموعه پایه و یا همان تعداد داده های تست الزم برای فراگیر بودن تست در اختیار ما قرار می دهند.

پس برای طراحی یک تست با استفاده از روشمسیر اصلی می توان مجموعه گام های زیر را

فرض نمود:


رسم گراف جریان محاسبهcyclomatic complexityتولید مجموعه پایهتولید مجموعه داده تست

دقت کنید که بعضی از مسیرها قابل اجرا-11-10-2-1نیستند به عنوان مثال مسیر

در شکل بعدی و باید در قالب 13مسیرهای دیگر تست گردند.


برای شبه اتومات کردن چنین ساختاری میتوان از ماتریس مجاورت گراف جریان

استفاده نماییم. در این ماتریس هر خانه می تواند وزن یال را نشان دهد که برای مواردی

از قبیل زیر قابل استفاده است:احتمال اجرای یال در برنامهزمان اجرای الزمحافظه الزممنابع مورد نیاز


این مقادیر می توانند تست دقیق تری راممکن سازند.

با استفاده از این ماتریس می توانcyclomatic complexity را به صورت زیر

محاسبه نمود.الگوریتم های زیادی برای اتومات سازی

طراحی تست با استفاده از این

ابزار تولید شده اند.

تست ساختار تصمیم گیری

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

با این روش تلفیق نمود که در ادامه به توضیح در مورد آن ها می پردازیم.

Conditionتست شرایط )Testing)

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

پرانتز از هم جدا شده اند. پس می توان خطاهای ممکن در یک شرط منطقی را در

موارد زیر خالصه نمود:خطا در عملگر منطقیخطا در متغیر منطقیخطا در پرانتزها


خطا در عبارات ریاضی خطا در عملگرهایrelational( , =! ,=< ,<

==) داده های تستی که بتوانند خطاهای موجود در

شرط ها را کشف نمایند مطمئنا می توانند خطاهای کل سیستم را نیز کشف نمایند.

در این روش به جای تستn2 حالت ممکن متغیر سعی می کنیم شرایط را تا حد nبرای

ممکن ساده کنیم.


به عنوان مثال درBRO (Branch and Relational Operator) ابتدا اجزاء مختلف

سیستم را شناسایی می نماییم، سپس سعی می کنیم این اجزاء را به ازاء مقادیر مختلفشان تست نماییم. برای این کار باید

اجزاء تشخیص داده شده مستقل از هم باشند به این معنی که از متغیرهای

مشترک استفاده ننمایند.

(Data Flowتست جریان داده )

در این روش سعی می شود تا حوزه هایتعریف و استفاده داده ها دقیقا تست

شوند تا تداخالت داده ای و همچنین ناحیه هایی که داده مورد استفاده در آن ها وجود

ندارند دقیقا شناسایی شوند.

تست حلقه ها

چهار نوع حلقه را می توان متصور شد وبرای هر یک مجموعه تست های الزم ذکر

شده اند.حلقه ساده

پریدن از روی حلقهتنها یک بار ورود به حلقه2مرور برروی حلقه mمرور برروی حلقه n-1, n , n+1مرور برروی حلقه

تست حلقه ها

حلقه های متداخل تمام حلقه ها را برای کمترین مقدار تنظیم نمایید و داخلی

ترین حلقه را با استفاده از روش حلقه های ساده تست نمایید.

.این کار را به سمت بیرون ادامه دهید حلقه های متصل شده به هم

اگر مستقل از هم هستند با روش حلقه های ساده تستنمایید.

.در غیر این صورت از روش حلقه های متداخل استفاده نماییدحلقه های بدون ساختار

.طراحی را عوض کنید تا در قالب های قبلی قرار گیرد

تست جعبه سیاه

این تست برپایه کارکردهای مورد انتظار ازسیستم انجام می شود و از این رو به داده های

الزم برای تست رفتار سیستم را تولید می نماید.

خطاهایی که در این روش مد نظر می باشند دردسته های زیر قابل تقسیم می باشند:

توابع اشتباه و یا از قلم افتادهخطا در واسط کاربر خطا در داده ساختارها و یا دسترسی به بانک های

داده

تست جعبه سیاه

خطا در رفتار و یا کاراییخطا در شروع و خاتمه

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

دسته ای از خطاها را مشخص نمایند و نه تنها یک نمونه خاص

در ادامه روش های مختلف را بررسی مینماییم.

روش های تست مبتنی بر گراف

در این روش باید تمام اشیاء موجود در نرمافزار و ارتباطات بین آن ها را شناسایی نماییم و سپس داده هایی را طراحی نماییم که بتوانند

این مجموعه اشیاء و روابط را تست نمایند..این گراف ها می توانند دارای اجزاء زیر باشند

)نود ) و وزن هر نود که مشخصات آن را در بر دارد یال های یک سویه )و وزن آن که اطالعاتی را در

مورد اتصال در بر دارد(یال های دو سویه


مدل های زیر را می توان با استفاده از چنینگرافی تولید نمود و بر اساس هر یک تست های

الزم را انجام داد مدل کردن جریان های تراکنشی )عملیات مختلف

در یک تراکنش و ارتباطات بین آنها( مدل کردن روال های حالت نهایی )حالت های

مختلف سیستم و روند حرکت بین آنها( مدل کردن جریان داده ها )اشیاء مختلف و عملیات

الزم برای تبدیل داده ها از یک شیء به دیگری( مدل کردن زمانی )قطعات برنامه و زمان الزم

برای اجرا تا حرکت بین قطعات(

se2 7 software testing

Documents