دانلودمقاله تست نرم افزار

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

* راههای مخصوص برای تست کردنcomponent ها و تست یکپارچگی سیستمهای شئ گرا درک خواهید کرد.

* با اصول وعملیاتی که ابزارcase حمایت می کند (برای تست کردن) آشنا می شوید.

در فصل 3 روی یک فرآیند تست کردن عمومی که با تست واحدهای برنامه شخصی (مثل توابع و اشیا) آغاز می شد بحث کردیم.این واحدها با هم تشکیل یک زیر سیستم یا سیستم را می دهند و ارتباط و برهم کنش واحدها بر هم تست می شود.در نهایت پس از اتمام سیستم مشتری ممکن است یک سری تستهای قابل قبول روی سیستم انجام دهد تا ببیند آیا سیستم همانطور که تعریف شده کار می کند یا نه؟
یک دید انتزاعی تر از فرآیند تست در شکل 1-20 نشان داده شده است.مرحله تست اجزا(component) با تست عملیات اجزا در ارتباط است که این عملیات می تواند یک تابع باشد یااینکه گروهی از متدهای جمع آوری شده در یک ماژول یا شئ باشد.در طول تست یکپارچگی این اجزا با هم تشکیل زیرسیستم یا سیستم را می دهند.در این مرحله تست باید برروی بر هم کنش بین اجزا وعملیات و کارآیی کل سیستم متمرکزشود.با این وجود حتما" عیوبی که دراین اجزا وجود داشته ودرطی مراحل قبلی خود را نشان نمی دادند آشکار می شوند.
به عنوان قسمتی از فرآیند طراحی v&v،مدیر باید تصمیماتی در مورد اینکه چه کسانی باید مسئول مراحل مختلف تست باشند تصمیم بگیرد.در بیشتر سیستمها برنامه نویسان مسئول تست کد خودشان هستند(ماژول یا شیء) پس از تکمیل تست شخصی کار به یک جمع کننده (integrator) تحویل داده می شود تا ماژولهای تولید شده توسط برنامه نویسان را جمع کند و نرم افزار را بسازد و سپس سیستم را به عنوان «کل» تست کند.(بطورکلی)
با این وجود در مورد سیستمهای حساس و بحرانی ممکن است یک فرآیند رسمی بکار رود که درآن تست کنندگان مستقل، مسئول همه مراحل فرآیندتست هستند.تستها بطور مجزا انجام می شوند و ثبت جزئیات ،بدست می آید.
در هنگام تست سیستمهای بحرانی، تشخیص جزئیات هردو جزء نرم افزاری توسط تیمهای مستقل برای انجام تست برای سیستم بکار می رود.
با این وجود در بیشتر موارد دیگر،تست یک فرآیند شهودی تراست زیرا وقت کافی برای نوشتن جزئیات هر قسمت از سیستم نرم افزار وجود ندارد.معمولا"، رابطهای اجزاء سیستم اصلی مشخص می شوند و برنامه نویسان شخصی و تیمهای برنامه نویسی مسئول طراحی وتولید وتست این اجزا هستند.تست کردن معمولا" بر مبنای یک درک شهودی از اینکه این اجزاء باید چگونه عمل کنند می باشد.
تست تجمعی باید برمبنای تشریح سیستم نوشته شده باشد.که این می تواند یک تشریح مفصل از نیازهای سیستم، همانطور که درفصل5 بحث شد،باشد و یا می تواند یک تشریح از عواملی که از دید کاربر،باید در سیستم پیاده سازی شود باشد. همیشه یک تیم مجزا مسئول تست تجمعی سیستم هستند.همانطور که در فصل 3 بحث شد آنها(تیم) کاربران و مستندات مربوط به احتیاجات سیستم را برای تولید طرح تست تجمعی بطور مفصل بکار می برند.(شکل12-3)
کتابهای مربوط به تست کردن، مثل کتابهای Beizer وHitوPrry بر مبنای تجزیه عملی سیستمهایی که مدل تابعی را بکار می برند، است.
از نقطه نظر تست کردن، سیستمهای شی گراء و تابعی از دو جهت اساسی با هم تفاوت دارند.
1.در سیستمهای تابعی مرز مشخصی بین واحدهای برنامه پایه(تابع) و اجتماعی ازاین واحدهای برنامه پایه (ماژول) وجود دارد. در سیستمهای شیءگرا این چنین مرزی وجود ندارد.اشیا می توانند نهادهای ساده ای مثل یک لیست باشند یا نهادهای پیچیده ای مثل شئ ایستگاه هوا شناسی باشند که همانطور که در فصل 12 بحث شد ، شامل مجموعه ای از اشیاء است.
2.اغلب یک ساختار سلسله مراتبی واضح از اشیاء ،مثل آنچه درسیستمهای تابعی وجود دارد، موجود نیست. استراتژیهای تجمعی (جمع کردن اشیآ) مثل روش بالا به پایین و پایین به بالا که در بخش 2-20 بحث شده اند،اغلب نامطلوبند.
این تفاوتها به این معناست که مرز بین تست اجزاء و تست تجمعی برای سیستمهای شیء گرا محو است.
یک دنباله از فرآیند تولید شیءگرا بطور یکپارچه، که اشیاء ساختارهای پایه بکار رفته در همه مراحل فرآیند نرم افزار، هستند ، وجود دارد.درحالی که بعضی از روشهای تست کردن از طراحی سیستم مستقل هستند ،بعضی روشها تولید شدند که، بطور مخصوص با تست سیستمهای شی گراء، تطابق دارند. من روشهای تست شی گرا را در3-20 بحث می کنم.

تست عیوب
هدف اصلی تست عیوب، کشف نقصهای پنهانی در سیستم نرم افزاری، قبل از ارائه سیستم است. این عیوب با تست validation که می خواهد ثابت کند:
سیستم همانطوری کار می کند که در تشریح سیستم خواسته شده است.تست validation نیاز دارد که سیستم با بکارگیری موارد تست قابل قبول داده شده درست کار کند.یک تست عیوب موفق است که باعث شود سیستم نادرست کار کند و بنابراین خطا کشف شود.این مطلب واقعیت مهمی را در مورد تست کردن بیان می کند و حضور نقص و خطا را ثابت می کند.مدل عمومی فرآیند تست عیوب در شکل 2-20 نشان داده شده است. موارد تست ، تشریح ورودیها برای تست و خروجیهای قابل انتظار،بعلاوه جملاتی که تست چگونه باید انجام شود،می باشد.
داده های تست ورودیهایی هستند که برای تست سیستم تولید شده اند.این داده هاگاهی می توانند بطور اتوماتیک تولید شوند.تولید مورد تست غیر ممکن است،زیرا خروجی های تست نمی توانند پیش بینی شوند.تست کامل که هر دنباله ممکن ازاجزای برنامه را تست کند، غیرممکن است.بنابراین تست باید بر مبنای یک زیر مجموعه از موارد تست ممکن باشد.
سازمانها باید تدابیر و سیاستهایی برای انتخاب این زیر مجموعه ها داشته باشند،بجای اینکه آن را به عهده تیمهای تولیدی بگذارند.این سیاستها ممکن است بر مبنای سیاستهای تست عمومی باشند مثل سیاستی که می گوید: همه دستورات برنامه باید حداقل یکبار اجرا شوند.سیاستهای تست کردن می تواند براساس تجربه بکار بردن سیستم باشد و می تواند روی تست عوامل سیستمهای عملیاتی متمرکز شود.برای مثال
1)همه توابع سیسُتم که از منوها قابل دستیابی هستند باید تست شوند.
2)همه ترکیبات توابعی که از یک منو قابل دستیابی هستند باید تست شوند.
3)وقتی ورودیهای کاربر تهیه شد،همه توابع باید هم با داده های درست و هم داده های نادرست تست شوند.

مواردی خارج ازتجربه با محصولات نرم افزاری وجود دارد مثل word processor یا spread sheet که رهنمودهای (راهکارهای) قابل ملاحظه ای درطول تست محصول بکار می برند.ترکیبات نامعمول از توابع می توانند خطاتولید کنند، درحالیکه ترکیبات معمولی اکثرا" درست کار می کنند.

تست جعبه سیاه
تست جعبه سیاه یا تابعی یک روش برای تست است. درمواردی که تستها از تشریح اجزاء ناشی شود.یک سیستم جعبه سیاه رفتارش فقط با مطالعه ورودیها و خروجیهای مربوطه مشخص نمی شود.نامهای دیگری برای این تست مثل تست تابعی وجود دارد زیرا تست کننده فقط باعملیات در ارتباط است نه با پیاده سازی نرم افزار.شکل 3-20 مدل یک سیُستم که فرض شده در تست جعبه سیاه است را شرح می دهد. این روش هم برای سیستمهای تابعی و هم شی گرا قابل بکارگیری است.
تست کننده ورودیهایی را به اجزاء یا سیستم می دهد و خروجی های مربوطه را می آزماید.اگر خروجیها، همان خروجیهای پیش بینی شده نباشند، آنگاه تست با موفقیت یک مشکل را در رابطه نرم افزار کشف کرده است.
مساله کلیدی برای تست کننده عیوب انتخاب ورودیهایی است که عضوی از مجموعه Ie باشند.در بسیاری ازموارد انتخاب این موارد تست بر مبنای تجربه های قبلی مهندس تست است.آنها این دانش را برای مشخص کردن موارد تستی که با عیوب روبرو می شوند بکار می برند.با این وجود روش سیستماتیک برای انتخاب داده های تست در بخش بعدی وجوددارد که می توانند برای تکمیل این دانش تجربی بکار روند.
پارتیشن بندی معادل
داده های ورودی به یک برنامه به کلاسهای متفاوتی تقسیم می شوند که اعضای هرکلاس خصوصیات معمول دارند. اعداد مثبت،منفی داشته های بدون blank و غیره. برنامه معمولا" برای همه اعضای کلاس یک رفتار را اعمال می کنند.بدلیل این رفتار ،این کلاسها دامنه یا بخشهای متعادل صدا زده می شوند.
یک راه سیستماتیک برای تست عیوب بر مبنای تعریف همه بخشهای معادل که باید توسط برنامه بکار گرفته شوند، است.
در بخش 4-20 هر بخش معادل توسط یک بیضی مشخص شده است. بخشهای معادل ورودی ، مجموعه هایی هستند از داده ها که همه آنها (اعضای مجموعه)در یک راه یکسان پردازش می شوند. بخشهای معادل خروجی، خروجی هایی از برنامه هستند که خصوصیات یکسان دارند بنابراین می توانند به عنوان یک کلاس در نظر گرفته شوند.
همچنین شما می توانید بخشهایی تعریف کنید که ورودیهایش خارج از ورودیهای بخشهای دیگر که انتخاب کرده اید باشند. که اینها تست می کنند که آیا برنامه داده های غیر صحیح را به درستی پردازش می کنند؟
داده های معتبر (valid) و نامعتبر(invalid) نیز بخشهای معادل را تشکیل می دهند.
پس از اینکه شما یک مجموعه از بخشها را تعریف کردید، باید موارد تست را از هر یک از این بخشها انتخاب کنید .یک رهنمود خوب برای انتخاب موارد تست ، انتخاب موارد تست از روی مرزهای بخشها و موارد نزدیک به وسط بخش است.منطق این رهنمون این است که طراحان و برنامه نویسان تمایل دارند مقادیرمعمولی ورودیها را هنگام تولید سیستم در نظر بگیرند. مقادیر مرزی اغلب رفتاری متفاوت دارند (مثلا" صفر ممکن است رفتاری متفاوت از ارقام غیر منفی صحیح دیگر داشته باشد) بنابراین توسط تولید کنندگان در نظر گرفته می شود.خطاهای برنامه اغلب در هنگام پردازش این نوع مقادیر (مرزی) رخ می دهند. بخشهای معادل ممکن است با استفاده از تشریح سیستم یا مستندات کاربر و یابوسیله تجربه های تست کننده برای پیش بینی کلاسهای مقادیر ورودی که منجر به خطا می شوند، تعریف شود.
برای مثال تشریح برنامه ای که بیان می کند که برنامه 4 تا10 ورودی می گیرد و هر ورودی عدد صحیح 5 رقمی بزرگتر از 000ُ10 هستند.شکل 5-20 بخشهای معادل تعریف شده برای این وضعیت و مقادیر داده های ورودی ممکن برای تست را نشان می دهد.برای تشریح اشتقاق موارد تست من یک مثال ساده را تشریح می کنم مثل یک روتین جستجو ، که یک دنباله از عناصر را برای عنصر داده شده (کلید) جستجو می کند.و تابع موفقیت عنصر در دنباله را برمی گرداند. تشریح روتین ، پیش شرایط و پس شرایط را بکار می برد.شکل 6-20
پیش شرایط بیان می کند که روتین جستجو برای کار با دنباله خالی طراحی نشده است. پس شرایط بیان می کند که found وقتی کلید در دنباله باشد، یک می شود.موقعیت کلید با شاخص L مشخص می شود.این شاخص وقتی که عنصر در دنباله نباشد تعریف نشده است . برای این تشریح دو بخش معادل واضح را می توان تعریف کرد:
1.ورودیهایی که کلید عضوی از دنباله است(found=true)
2.ورودیهایی که کلید عضوی از دنباله نیست(found=false)
علاوه بر استخراج بخشهای معادل از تشریح سیُستم ، راهکارهای متعددی برای تست کردن وجود دارد.بعضی از این رهنمودها در دنباله هستند:
1.تست کردن نرم افزار با دنباله ای که فقط یک مقدار ساده دارد. برنامه نویسان طبیعتا" فکر می کنند که دنباله از چندین مقدار تشکیل شده است و گاهی آنها این فرض را در برنامه اعمال می کنند.بنابراین وقتی که یک دنباله ساده ارائه می شود، ممکن است برنامه به درستی کار نکند.
2.بکار بردن دنباله های مختلف با سایزهای متفاوت برای تست:
این کار شانس اینکه یک برنامه ناقص تصادفا" مقادیر درست خروجی را تولید کند کاهش می دهد، بخاطر تنوع ورودیها.
3.تستهایی که در آن عنصر اول، آخر و وسط دنباله دستیابی شود.این روش مشکل در مرزهای بخشها را مشخص می کند.
با بکار بردن این رهنمونها دو بخش معادل اضافی از آرایه ورودی می توانند تعریف شوند:
_ دنباله ورودی که یک مقدار ساده دارد.
_تعداد عناصر دنباله ورودی بزرگتر از 1 است.
این بخشها باید با بخشهای معادل قبلی ترکیب شوند.بخشهای معادل داده شده در شکل 7-20 خلاصه شده اند.یک مجموعه از موارد تست ممکن بر مبنای این بخشها هم در شکل 7-20 نشان داده شده است.اگر عنصر کلید در دنباله نباشد L تعریف نشده است(؟؟). رهنمودی که می گوید دنباله های متفاوت با سایزهای مختلف تولید شود در این موارد تست بکار نرفته است. مجموعه مقادیر ورودی بکار رفته برای تست تابع جستجو کامل نیست.مثلا" این تابع ممکن است اگر دنباله ورودی شامل عناصر1/2/3/4 باشد خطا دهد. با این وجود این منطقی است که اگر یک عضو از کلاس به درستی پردازش شد، بقیه عناصر کلاس نیز با خطا روبرو نمی شوند.البته هنوز خطا ممکن است بوجود آید.
بعضی بخشهای معادل ممکن است هنوز تعریف نشده باشد. خطا می تواند در تعریف بخشهای معادل صورت گیرد یا در تست داده هایی که به درستی تهیه نشده اند. من با ملاحظه ، احتیاط تستهایی که برای ارائه سیُستمی با پارامترهایی به ترتیب غلط ، طراحی شده اند را کنار می گذارم.این نوع خطا بیشتر توسط بازرسی برنامه یا تحلیل ایستای اتوماتیک مشخص می شود. بطور مشابه، تست برای خرابی های غیر قابل انتظار (غیرمترقبه) داده های خارج از اجزاء ، چک نمی شود. بازرسی کد همانطور که در فصل 14 بحث شد، می تواند آشکار کند که این نوع از مشکلات رخ می دهد.
تست ساختاری
تست ساختاری (شکل8-20) روشی از تست کردن است که از دانش پیاده سازی و ساختار نرم افزار سرچشمه می گیرد. برای تمایز این روش، از روش جعبه سیاه این روش گاهی به عناوین تست جعبه سفید، تست جعبه شیشه ای ، تست جعبه واضح وتمیز صدا زده می شود. تست ساختاری معمولا" در رابطه با واحدهای برنامه کوچک مثل روتین ها یا اعمال مربوط به یک شیء صورت می گیرد. در این روش همانطور که از نامش پیداست ، تست کننده می تواندکد را تحلیل کند و دانش بکار رفته در ساختار جزء component را برای تولید داده های تست بکار گیرد.تحلیل کدمی تواند برای پیدا کردن اینکه چند مورد تست نیاز است تا تضمین شود همه دستورات برنامه حداقل یکبار اجرا می شوند، بکار رود. دانشی که الگوریتم برای پیاده سازی بعضی توابع بکار می برد،می تواند برای تعریف بخشهای معادل ، بکار گرفته شود.برای توضیح این مطلب من این بار بجای تشریح روتین جستجو از روتین جستجوی دودویی استفاده می کنم.البته این پیش شرایط سخت تری دارد .دنباله به صورت یک آرایه پیاده سازی می شود، که آرایه باید مرتب باشد و مقدار حد پایین آرایه باید از مقدار حد بالای آن کمتر باشد.با بررسی کد روتین جستجو ما می توانیم مشاهده کنیم که جستجوی دودویی شامل تقسیم فضای جستجو به سه قسمت است. هر یک از این قسمتها یک بخش معادل را تشکیل می دهند.موارد تستی که در آن کلید در بخشهای مرزی بخشهاست باید برای آزمایش کد ،انتخاب شوند.
بنابراین موارد تست نشان داده شده در شکل 7-20 باید تغییراتی مبنی بر اینکه آرایه ورودی به ترتیب صعودی مرتب باشد، داشته باشد. موارد اضافی مبتنی بر دانش بکار رفته در الگوریتم نیز باید به مجموعه تست اضافه شود. اینها عناصری هستند که نزدیک عنصر وسط آرایه هستند. شکل 11-20 یک مجموعه از موارد تست برای روتین جستجوی دودویی را نشان می دهد.
تست شاخه ای
تست شاخه ای روشی از تست ساختاری است که هدفش اجرای هر شاخه اجرایی مستقل که در یک شیء یا برنامه وجود دارد می باشد.اگر همه شاخه های مستقل اجرایی، اجرا شوند همه جملات برنامه باید حداقل یکبار اجرا شده باشد.بعلاوه همه جملات شرطی باید برای true وfalse بودن تست شوند. در یک فرآیند تولید شی گرا ، تست شاخه ای می تواند برای تست متدهای یک شیء بکار رود. تعداد شاخه های اجرایی در یک برنامه به سایز برنامه وابسته است.هنگامی که ماژولها با هم سیستم را تشکیل می دهند، بکار بردن روش تست شاخه ای غیر عملی است.بنابراین روشهای تست شاخه ای اغلب در مرحله تست واحدها و تست ماژولها به کار می رود.
تست شاخه ای همه ترکیبات ممکن همه شاخه های اجرایی در برنامه را تست نمی کند، چون برای همه اجزاء بغیر از یک تعداد جزئی برنامه بدون حلقه، این یک کار غیر ممکن است. یک تعداد نامحدود از ترکیبات شاخه ای در برنامه های حلقه دار وجود دارد.خطاهایی که خودشان را در هنگام اجرای ترکیبات شاخه های عملی نشان می دهند حتی اگر همه دستورات برنامه یک بار اجرا شود، باز هم ممکن است وجود داشته باشند.
نقطه شروع برای تست شاخه ای یک گراف ریزشی برنامه است که این یک مدل اسکلتی از همه شاخه های برنامه است. یک گراف ریزشی از نودهای تصمیم و لبه هایی که نشان دهنده جریان کنترل است تشکیل شده است.گراف ریزشی از جایگزینی دستورات کنترلی با دپاگرامهای معادلش ساخته می شود.
اگر دستورgoto در برنامه وجود نداشته باشد تشکیل گراف ریزشی کار ساده ای است. دستورات ترتیبی (تخصیص، دستورات ورودی/ خروجی، فراخوانی توابع ) می تواند در ساخت گراف ریزشی نادیده گرفته شود.
هر شاخه در یک دستور (if-then-else) با یک مسیر مجزا نشان داده می شود و حلقه ها به وسیله یک فلش برگشتی به نود چک کننده شرط حلقه، نشان داده می شوند. حلقه ها و شاخه های شرطی در گراف ریزشی برای روتین جستجوی دودویی در شکل 12-20 شرح داده شده است. هدف تست ساختاری اطمینان از اجرای حداقل یکبار هر شاخه اجرایی می باشد. یک شاخه مستقل شاخه ای است که حداقل یک شاخه جدید داشته باشد. در اصطلاح برنامه ، به این معنی است که یک یا چندین شرایط جدید را تجربه کند. شاخه های true/false از همه جملات شرطی باید اجرا شوند. گراف ریزشی برای تابع جستجوی دودویی در شکل 12-20 نشان داده شده است با دنبال کردن شاخه های گراف، مشاهده می کنیم که شاخه های مستقل برای گراف ریزشی عبارتند از:
9/8/2/7/6/4/3/2/1
2/7/3/4/3/2/1
2/7/6/4/3/2/1
9/8/3/2/1

فرمت این مقاله به صورت Word و با قابلیت ویرایش میباشد

تعداد صفحات این مقاله 37   صفحه

پس از پرداخت ، میتوانید مقاله را به صورت انلاین دانلود کنید