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

توجه : به همراه فایل word این محصول فایل پاورپوینت (PowerPoint) و اسلاید های آن به صورت هدیه ارائه خواهد شد

  مقاله تست نرم افزار دارای ۴۲ صفحه می باشد و دارای تنظیمات در microsoft word می باشد و آماده پرینت یا چاپ است

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

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

بخشی از متن مقاله تست نرم افزار :

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

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

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

در فصل ۳ روی یک فرآیند تست کردن عمومی که با تست واحدهای برنامه شخصی (مثل توابع و اشیا) آغاز می شد بحث کردیم.این واحدها با هم تشکیل یک زیر سیستم یا سیستم را می دهند و ارتباط و برهم کنش واحدها بر هم تست می شود.در نهایت پس از اتمام سیستم مشتری ممکن است یک سری تستهای قابل قبول روی سیستم انجام دهد تا ببیند آیا سیستم همانطور که تعریف شده کار می کند یا نه؟

یک دید انتزاعی تر از فرآیند تست در شکل ۱-۲۰ نشان داده شده است.مرحله تست اجزا(component) با تست عملیات اجزا در ارتباط است که این عملیات می تواند یک تابع باشد یااینکه گروهی از متدهای جمع آوری شده در یک ماژول یا شئ باشد.در طول تست یکپارچگی این اجزا با هم تشکیل زیرسیستم یا سیستم را می دهند.در این مرحله تست باید برروی بر هم کنش بین اجزا وعملیات و کارآیی کل سیستم متمرکزشود.با این وجود حتما” عیوبی که دراین اجزا وجود داشته ودرطی مراحل قبلی خود را نشان نمی دادند آشکار می شوند.

به عنوان قسمتی از فرآیند طراحی v&v،مدیر باید تصمیماتی در مورد اینکه چه کسانی باید مسئول مراحل مختلف تست باشند تصمیم بگیرد.در بیشتر سیستمها برنامه نویسان مسئول تست کد خودشان هستند(ماژول یا شیء) پس از تکمیل تست شخصی کار به یک جمع کننده (integrator) تحویل داده می شود تا ماژولهای تولید شده توسط برنامه نویسان را جمع کند و نرم افزار را بسازد و سپس سیستم را به عنوان «کل» تست کند.(بطورکلی)
با این وجود در مورد سیستمهای حساس و بحرانی ممکن است یک فرآیند رسمی بکار رود که درآن تست کنندگان مستقل، مسئول همه مراحل فرآیندتست هستند.تستها بطور مجزا انجام می شوند و ثبت جزئیات ،بدست می آید.

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

تست تجمعی باید برمبنای تشریح سیستم نوشته شده باشد.که این می تواند یک تشریح مفصل از نیازهای سیستم، همانطور که درفصل۵ بحث شد،باشد و یا می تواند یک تشریح از عواملی که از دید کاربر،باید در سیستم پیاده سازی شود باشد. همیشه یک تیم مجزا مسئول تست تجمعی سیستم هستند.همانطور که در فصل ۳ بحث شد آنها(تیم) کاربران و مستندات مربوط به احتیاجات سیستم را برای تولید طرح تست تجمعی بطور مفصل بکار می برند.(شکل۱۲-۳)

کتابهای مربوط به تست کردن، مثل کتابهای Beizer وHitوPrry بر مبنای تجزیه عملی سیستمهایی که مدل تابعی را بکار می برند، است.
از نقطه نظر تست کردن، سیستمهای شی گراء و تابعی از دو جهت اساسی با هم تفاوت دارند.
۱در سیستمهای تابعی مرز مشخصی بین واحدهای برنامه پایه(تابع) و اجتماعی ازاین واحدهای برنامه پایه (ماژول) وجود دارد. در سیستمهای شیءگرا این چنین مرزی وجود ندارد.اشیا می توانند نهادهای ساده ای مثل یک لیست باشند یا نهادهای پیچیده ای مثل شئ ایستگاه هوا شناسی باشند که همانطور که در فصل ۱۲ بحث شد ، شامل مجموعه ای از اشیاء است.

۲اغلب یک ساختار سلسله مراتبی واضح از اشیاء ،مثل آنچه درسیستمهای تابعی وجود دارد، موجود نیست. استراتژیهای تجمعی (جمع کردن اشیآ) مثل روش بالا به پایین و پایین به بالا که در بخش ۲-۲۰ بحث شده اند،اغلب نامطلوبند.
این تفاوتها به این معناست که مرز بین تست اجزاء و تست تجمعی برای سیستمهای شیء گرا محو است.
یک دنباله از فرآیند تولید شیءگرا بطور یکپارچه، که اشیاء ساختارهای پایه بکار رفته در همه مراحل فرآیند نرم افزار، هستند ، وجود دارد.درحالی که بعضی از روشهای تست کردن از طراحی سیستم مستقل هستند ،بعضی روشها تولید شدند که، بطور مخصوص با تست سیستمهای شی گراء، تطابق دارند. من روشهای تست شی گرا را در۳-۲۰ بحث می کنم.

تست عیوب
هدف اصلی تست عیوب، کشف نقصهای پنهانی در سیستم نرم افزاری، قبل از ارائه سیستم است. این عیوب با تست validation که می خواهد ثابت کند:
سیستم همانطوری کار می کند که در تشریح سیستم خواسته شده است.تست validation نیاز دارد که سیستم با بکارگیری موارد تست قابل قبول داده شده درست کار کند.یک تست عیوب موفق است که باعث شود سیستم نادرست کار کند و بنابراین خطا کشف شود.این مطلب واقعیت مهمی را در مورد تست کردن بیان می کند و حضور نقص و خطا را ثابت می کند.مدل عمومی فرآیند تست عیوب در شکل ۲-۲۰ نشان داده شده است. موارد تست ، تشریح ورودیها برای تست و خروجیهای قابل انتظار،بعلاوه جملاتی که تست چگونه باید انجام شود،می باشد.

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

سازمانها باید تدابیر و سیاستهایی برای انتخاب این زیر مجموعه ها داشته باشند،بجای اینکه آن را به عهده تیمهای تولیدی بگذارند.این سیاستها ممکن است بر مبنای سیاستهای تست عمومی باشند مثل سیاستی که می گوید: همه دستورات برنامه باید حداقل یکبار اجرا شوند.سیاستهای تست کردن می تواند براساس تجربه بکار بردن سیستم باشد و می تواند روی تست عوامل سیستمهای عملیاتی متمرکز شود.برای مثال
۱)همه توابع سیسُتم که از منوها قابل دستیابی هستند باید تست شوند.
۲)همه ترکیبات توابعی که از یک منو قابل دستیابی هستند باید تست شوند.

۳)وقتی ورودیهای کاربر تهیه شد،همه توابع باید هم با داده های درست و هم داده های نادرست تست شوند.

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

تست جعبه سیاه
تست جعبه سیاه یا تابعی یک روش برای تست است. درمواردی که تستها از تشریح اجزاء ناشی شود.یک سیستم جعبه سیاه رفتارش فقط با مطالعه ورودیها و خروجیهای مربوطه مشخص نمی شود.نامهای دیگری برای این تست مثل تست تابعی وجود دارد زیرا تست کننده فقط باعملیات در ارتباط است نه با پیاده سازی نرم افزار.شکل ۳-۲۰ مدل یک سیُستم که فرض شده در تست جعبه سیاه است را شرح می دهد. این روش هم برای سیستمهای تابعی و هم شی گرا قابل بکارگیری است.

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

پارتیشن بندی معادل
داده های ورودی به یک برنامه به کلاسهای متفاوتی تقسیم می شوند که اعضای هرکلاس خصوصیات معمول دارند. اعداد مثبت،منفی داشته های بدون blank و غیره. برنامه معمولا” برای همه اعضای کلاس یک رفتار را اعمال می کنند.بدلیل این رفتار ،این کلاسها دامنه یا بخشهای متعادل صدا زده می شوند.
یک راه سیستماتیک برای تست عیوب بر مبنای تعریف همه بخشهای معادل که باید توسط برنامه بکار گرفته شوند، است.

در بخش ۴-۲۰ هر بخش معادل توسط یک بیضی مشخص شده است. بخشهای معادل ورودی ، مجموعه هایی هستند از داده ها که همه آنها (اعضای مجموعه)در یک راه یکسان پردازش می شوند. بخشهای معادل خروجی، خروجی هایی از برنامه هستند که خصوصیات یکسان دارند بنابراین می توانند به عنوان یک کلاس در نظر گرفته شوند.

همچنین شما می توانید بخشهایی تعریف کنید که ورودیهایش خارج از ورودیهای بخشهای دیگر که انتخاب کرده اید باشند. که اینها تست می کنند که آیا برنامه داده های غیر صحیح را به درستی پردازش می کنند؟
داده های معتبر (valid) و نامعتبر(invalid) نیز بخشهای معادل را تشکیل می دهند.

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

برای مثال تشریح برنامه ای که بیان می کند که برنامه ۴ تا۱۰ ورودی می گیرد و هر ورودی عدد صحیح ۵ رقمی بزرگتر از ۰۰۰ُ۱۰ هستند.شکل ۵-۲۰ بخشهای معادل تعریف شده برای این وضعیت و مقادیر داده های ورودی ممکن برای تست را نشان می دهد.برای تشریح اشتقاق موارد تست من یک مثال ساده را تشریح می کنم مثل یک روتین جستجو ، که یک دنباله از عناصر را برای عنصر داده شده (کلید) جستجو می کند.و تابع موفقیت عنصر در دنباله را برمی گرداند. تشریح روتین ، پیش شرایط و پس شرایط را بکار می برد.شکل ۶-۲۰

پیش شرایط بیان می کند که روتین جستجو برای کار با دنباله خالی طراحی نشده است. پس شرایط بیان می کند که found وقتی کلید در دنباله باشد، یک می شود.موقعیت کلید با شاخص L مشخص می شود.این شاخص وقتی که عنصر در دنباله نباشد تعریف نشده است . برای این تشریح دو بخش معادل واضح را می توان تعریف کرد:
۱ورودیهایی که کلید عضوی از دنباله است(found=true)
۲.ورودیهایی که کلید عضوی از دنباله نیست(found=false)

علاوه بر استخراج بخشهای معادل از تشریح سیُستم ، راهکارهای متعددی برای تست کردن وجود دارد.بعضی از این رهنمودها در دنباله هستند:
۱تست کردن نرم افزار با دنباله ای که فقط یک مقدار ساده دارد. برنامه نویسان طبیعتا” فکر می کنند که دنباله از چندین مقدار تشکیل شده است و گاهی آنها این فرض را در برنامه اعمال می کنند.بنابراین وقتی که یک دنباله ساده ارائه می شود، ممکن است برنامه به درستی کار نکند.
۲بکار بردن دنباله های مختلف با سایزهای متفاوت برای تست:
این کار شانس اینکه یک برنامه ناقص تصادفا” مقادیر درست خروجی را تولید کند کاهش می دهد، بخاطر تنوع ورودیها.

۳تستهایی که در آن عنصر اول، آخر و وسط دنباله دستیابی شود.این روش مشکل در مرزهای بخشها را مشخص می کند.
با بکار بردن این رهنمونها دو بخش معادل اضافی از آرایه ورودی می توانند تعریف شوند:
_ دنباله ورودی که یک مقدار ساده دارد.
_تعداد عناصر دنباله ورودی بزرگتر از ۱ است.

این بخشها باید با بخشهای معادل قبلی ترکیب شوند.بخشهای معادل داده شده در شکل ۷-۲۰ خلاصه شده اند.یک مجموعه از موارد تست ممکن بر مبنای این بخشها هم در شکل ۷-۲۰ نشان داده شده است.اگر عنصر کلید در دنباله نباشد L تعریف نشده است(؟؟). رهنمودی که می گوید دنباله های متفاوت با سایزهای مختلف تولید شود در این موارد تست بکار نرفته است. مجموعه مقادیر ورودی بکار رفته برای تست تابع جستجو کامل نیست.مثلا” این تابع ممکن است اگر دنباله ورودی شامل عناصر۱/۲/۳/۴ باشد خطا دهد. با این وجود این منطقی است که اگر یک عضو از کلاس به درستی پردازش شد، بقیه عناصر کلاس نیز با خطا روبرو نمی شوند.البته هنوز خطا ممکن است بوجود آید.

بعضی بخشهای معادل ممکن است هنوز تعریف نشده باشد. خطا می تواند در تعریف بخشهای معادل صورت گیرد یا در تست داده هایی که به درستی تهیه نشده اند. من با ملاحظه ، احتیاط تستهایی که برای ارائه سیُستمی با پارامترهایی به ترتیب غلط ، طراحی شده اند را کنار می گذارم.این نوع خطا بیشتر توسط بازرسی برنامه یا تحلیل ایستای اتوماتیک مشخص می شود. بطور مشابه، تست برای خرابی های غیر قابل انتظار (غیرمترقبه) داده های خارج از اجزاء ، چک نمی شود. بازرسی کد همانطور که در فصل ۱۴ بحث شد، می تواند آشکار کند که این نوع از مشکلات رخ می دهد.

تست ساختاری
تست ساختاری (شکل۸-۲۰) روشی از تست کردن است که از دانش پیاده سازی و ساختار نرم افزار سرچشمه می گیرد. برای تمایز این روش، از روش جعبه سیاه این روش گاهی به عناوین تست جعبه سفید، تست جعبه شیشه ای ، تست جعبه واضح وتمیز صدا زده می شود. تست ساختاری معمولا” در رابطه با واحدهای برنامه کوچک مثل روتین ها یا اعمال مربوط به یک شیء صورت می گیرد.

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

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

بنابراین موارد تست نشان داده شده در شکل ۷-۲۰ باید تغییراتی مبنی بر اینکه آرایه ورودی به ترتیب صعودی مرتب باشد، داشته باشد. موارد اضافی مبتنی بر دانش بکار رفته در الگوریتم نیز باید به مجموعه تست اضافه شود. اینها عناصری هستند که نزدیک عنصر وسط آرایه هستند. شکل ۱۱-۲۰ یک مجموعه از موارد تست برای روتین جستجوی دودویی را نشان می دهد.

تست شاخه ای
تست شاخه ای روشی از تست ساختاری است که هدفش اجرای هر شاخه اجرایی مستقل که در یک شیء یا برنامه وجود دارد می باشد.اگر همه شاخه های مستقل اجرایی، اجرا شوند همه جملات برنامه باید حداقل یکبار اجرا شده باشد.بعلاوه همه جملات شرطی باید برای true وfalse بودن تست شوند. در یک فرآیند تولید شی گرا ، تست شاخه ای می تواند برای تست متدهای یک شیء بکار رود. تعداد شاخه های اجرایی در یک برنامه به سایز برنامه وابسته است.هنگامی که ماژولها با هم سیستم را تشکیل می دهند، بکار بردن روش تست شاخه ای غیر عملی است.بنابراین روشهای تست شاخه ای اغلب در مرحله تست واحدها و تست ماژولها به کار می رود.

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

اگر دستورgoto در برنامه وجود نداشته باشد تشکیل گراف ریزشی کار ساده ای است. دستورات ترتیبی (تخصیص، دستورات ورودی/ خروجی، فراخوانی توابع ) می تواند در ساخت گراف ریزشی نادیده گرفته شود.

هر شاخه در یک دستور (if-then-else) با یک مسیر مجزا نشان داده می شود و حلقه ها به وسیله یک فلش برگشتی به نود چک کننده شرط حلقه، نشان داده می شوند. حلقه ها و شاخه های شرطی در گراف ریزشی برای روتین جستجوی دودویی در شکل ۱۲-۲۰ شرح داده شده است. هدف تست ساختاری اطمینان از اجرای حداقل یکبار هر شاخه اجرایی می باشد. یک شاخه مستقل شاخه ای است که حداقل یک شاخه جدید داشته باشد.

در اصطلاح برنامه ، به این معنی است که یک یا چندین شرایط جدید را تجربه کند. شاخه های true/false از همه جملات شرطی باید اجرا شوند. گراف ریزشی برای تابع جستجوی دودویی در شکل ۱۲-۲۰ نشان داده شده است با دنبال کردن شاخه های گراف، مشاهده می کنیم که شاخه های مستقل برای گراف ریزشی عبارتند از:
۹/۸/۲/۷/۶/۴/۳/۲/۱
۲/۷/۳/۴/۳/۲/۱
۲/۷/۶/۴/۳/۲/۱
۹/۸/۳/۲/۱
اگر همه این شاخه ها اجرا شوند می توانیم مطمئن باشیم که
۱هر دستور در تابع حداقل یکبار اجرا شده است.
۲هر شاخه هم برای true و هم برای false تست شده است.
تعداد شاخه های مستقل در یک برنامه می تواند بوسیله محاسبه پیچیدگی سیکلوماتیک(c.c) از گراف ریزشی برنامه بدست آید.پیچیدگی سیکلوماتیک از یک گراف مرتبط مثل G از فرمول زیر به دست می آید.
۲+تعداد نودها –تعداد لبه ها=(G)CC
برای برنامه های فاقد دستور goto مقدارcc یک واحد بیشتر از تعداد شرطها در برنامه است.در یک جمله شرطی یا ترکیبی از شروط باید همه تستها که روی شرطها می تواند انجام شود را بشماریم. بنابراین اگر ۶ دستور if و ۱ حلقه while که همه شرطها ساده هستند داشته باشیم cc برابر است با ۸
اگر یک عبارت شرطی یک بیان ترکیبی از دو عملگر(and یاar) بود، cc برابر بود با ۱۰ .ccی یک روتین جستجوی دودویی برابر است با ۴ .بعد از کشف تعداد شاخه های مستقل کد، توسطcc، مرحله بعدی طراحی موارد تست برای اجرای هر یک از شاخه هاست. حداقل تعداد موارد تست برای همه شاخه ها برابر است با cc .
طراحی موارد تست در مورد روتین جستجوی دودویی نشان داده شده است. با این وجود وقتی یک برنامه ساختار درختی پیچیده داشته باشد، پیش بینی اینکه هر مورد تست عملی چگونه پردازش خواهد شد ، مشکل است.در این مورد یک تحلیلگر پویا می تواند برای ایجاد profile اجرایی برنامه ها بکار رود.تحلیل گر پویا یک ابزار تست کننده است که در ارتباط با کامپایلر کار می کند.
در طول کامپایل، دستورات کد شده شئی اضافی به تولید کننده کد پیوند می خورد. اینها تعداد دفعاتی که هر دستور برنامه اجرا می شود را می شمارند.
بعد از اجرای برنامه یک profile اجرایی می تواند چاپ شود که تعیین کند کدام قسمتهای برنامه در طول اجرای برنامه با داده های تست اجرا شدند و کدام قسمتها اجرا نشدند. این profile اجرای بخشهای تست نشده برنامه را مشخص می کند.
تست تجمعی
پس از اینکه اجزای برنامه شخصی تست شدند، آنها باید با هم تشکیل سیستم کامل و کاربردی را بدهند.این مرحله شامل ساختن سیستم(فصل ۲۹ را ببینید) و تست سیستم حاصل،به خاطر بروز مشکلاتی که در اثر بر هم کنش اجزاء بر هم رخ دهد، می باشد. تست تجمعی باید با استفاده از شرح سیستم تولید شود و هر زمان که تعدادی از اجزاء سیستم بطور قابل استفاده (کاربرد) وجود داشته باشد، تست باید آغاز شود.مشکل مهمی که در تست تجمعی رخ می دهد خطاهای محلی است که در طول این مرحله کشف می شود.تاثیرات پیچیده ای بین اجزاء سیستم وجود دارد. وقتی یک خروجی ناهمگون کشف شود پیدا کردن منبع خطا بسیار سخت است.برای ساده تر کردن آن شما باید همیشه یک روش تدریجی (افزایشی) را برای تست و تولید سیستم بکار ببرید.ابتدا باید شما یک موقعیت مینیمم از سیستم را ایجاد کنید، (تشکیل و ترکیب چند جزء کوچک) و این سیستم را تست کنید. سپس شما باید اجزاء را به این موقعیت مینیمال (minimal) اضافه کنید و پس از هر افزودن اجزا را تست کنید.
در مثال نشان داده شده۱۳-۲۰ دنباله تستهای T1 وT2 وT3 ابتدا روی سیستمی که از ماژولهای A و B (سیستم مینیمم) تشکیل شده اجرا می شوند. اگر خطایی رخ دهد تصحیح می شود. ماژول c اضافه می شود و T1وT2 وT3 هم تکرار می شوند تا مطمئن شویم که تاثیر (بر هم کنش) غیر قابل انتظاری در رابطه A/B وجود ندارد.
اگر مشکل در این تستها رخ دهد، این احتمالا” به این معناست که خطا در نتیجه تاثیرات ماژول جدید است. منبع خطا مشخص شده ، پس براحتی محل خطا تشخیص داده می شود و خطا تصحیح می شود. دنباله تست T4 همچنین روی سیستم اجرا می شود. سرانجام ماژول D اضافه شده و با تست جدید و بعدی D5 تست می شود.
عوامل سیستم ممکن است برای تعدادی از اجزا گسترش یابد. بنابراین پیاده سازی یک عامل جدید ممکن است احتیاج به چندین جزء برای ترکیب شدن داشته باشد.
تست ممکن است در نتیجه تاثیر بین این اجزاء شخصی با بقیه اجزاء با خطا روبرو شود و ممکن است تعمیر خطا کاری دشوار باشد زیرا روی همه اجزا که عوامل سیستم را پیاده سازی کردند تاثیر می گذارد.بعلاوه وقتی یک جزءجدید اضافه شد و تست شد این می تواند قالب تاثیرات اجزای قبلی که تست شدند را تغییر دهد.خطاهایی نیزممکن است رخ دهند که در تست موقعیت ساده تر کشف نشده اند.

تست بالا به پایین و پایین به بالا:
استراتژیهای تست بالا به پایین و پایین به بالا روشهای مختلف ترکیب اجزای سیستم را نشان می دهند.
در روش بالا به پایین ، اجزای سطح بالای سیستم ترکیب می شوند ، و قبل از اینکه طراحی و پیاده سازی آنها کامل شود تست می شوند.در روش پایین به بالا اجزاء سطح پایین ترکیب شده و تست می شوند قبل از اینکه اجزاء سطح بالا تولید شوند.تست بالا به پایین مجموع قسمتهای فرآیند تولید بالا به پایین است که فرآیند تولید با اجزاء سطح بالا شروع می شود و تولید به سمت پایین در ساختار سلسله مراتبی پیش می رود.برنامه بعنوان یک جزء انتزاعی با زیر اجزایی که بوسیله ریشه درخت مشخص شده اند ارائه می شود. بعد از اینکه اجزاء سطح بالا برنامه نویسی و تست شدند زیر اجزاء نیز به همان روش پیاده سازی و تست می شوند.بنابراین کل سیستم بطور کامل تست می شوند.به وضوح تست پایین به بالا شامل ترکیب و تست ماژولهای سطح پایین در ساختار و سلسله مراتبی و سپس حرکت به سمت بالا و ساخت ماژولها تا اینکه ماژولهای نهایی تست شوند.
این روش نیازی به طراحی معماری سیستم برای کامل شدن ندارد بنابراین می تواند از یک مرحله آغازین (اولیه) در فرآیند توسعه شروع کند. این می تواند در هنگامی که سیستم دوباره بکار گرفته شود و اجزا را با استفاده از سیستمهای دیگر تغییر می دهد بکار رود.
تست تجمعی بالا به پایین و پایین به بالا می تواند از چهار نظر مقایسه شود:
۱معماری:روش بالا به پایین به خوبی خطاها در معماری سیستم را کشف می کند و طراحی سطح بالا در یک مرحله آغازین از فرآیند تولید را ایجاد می کند. هنگامی که خطای ساختاری معمولی وجود داشته باشد، کشف بموقع یعنی اینکه می توان بدون هزینه برگشت به مراحل قبل ، تصحیح را انجام داد.با تست پایین به بالا ، طراحی سطح بالا تولید نمی شود مگر در مراحل نهایی فرآیند.
۲اثبات سیستم: با روش بالا به پایین تولید سیستم کاربردی بطور محدود در مراحل آغازین، امکان پذیر است.این یک عامل مهم روانی برای کسانی که در تولید سیستم حضور دارند می باشد.زیرا عملی بودن سیستم برای مدیریت را اثبات می کند.
صحت سیستم (validation ) به محض اینکه سیستم قابل اثبات بتواند به کاربر ارائه شود، می تواند انجام شود.با این وجود،اگر سیستم از اجزای قابل استفاده مجدد ساخته شده باشد، تولید بعضی انواع اثبات با استفاده از روش پایین به بالانیز امکان پذیر است.
۳پیاده سازی تست: پیاده سازی تست بالا به پایین دشوار است زیرا باید برگها که ستون پایین سیستم را شبیه سازی می کنند تولید شوند. این برگها ممکن است فقط یک نوع ساده شده از اجزاء مورد نیاز باشد، یا ممکن است به تست کننده تقاضای ورود داده مناسب، یا شبیه سازی عملی اشتقاق تست اجزاء را بدهند.
در هنگام بکارگیری تست پایین به بالا شما باید اشتقاق داده را برای اعمال سطوح پایین بنویسید.این اشتقاق داده ها محیط اجزا را شبیه سازی می کنند و اجزایی که باید تست شوند را فراخوانی می کنند.
۴مشاهده تست: هر دو روش بالا به پایین و پایین به بالا می تواند در مشاهده تست مشکل داشته باشد. در بعضی سیستمها سطوح بالاتر سیستم که در روش بالا به پایین در ابتدا پیاده سازی می شوند، خروجی تولید نمی کنند اما برای تست این سطوح باید این کار را انجام دهیم. تست کننده باید یک محیط مصنوعی برای تولید نتایج تست ایجاد کند. با تست پایین به بالا نیز خلق محیط مصنوعی ممکن است لازم باشد.(اشتقاق تست)] برای مشاهده اجرای اجزاء سطوح پایین تر[
سیستمها معمولا” با ترکیب روشهای بالا به پایین و پایین به بالا تولید و تست می شوند.
برای قسمتهای مختلف سیستم ، زمانبرهای تولید مختلف وجود دارد،به این معنی که تیمهای ترکیب و تست باید با هر جزیی که موجود است کار کند. بنابراین مخلوطی از برگها و اشتقاقهای تست باید در طول فرآیند تست تجمعی تولید شود.

تست رابط
در هنگامی که ماژولها یا زیر سیستمها برای خلق سیستمهای بزرگتر با هم ترکیب می شوند، مورد استفاده قرار می گیرد.هر ماژول یا زیر سیستم یک رابط تعریف شده دارد که بوسیله اجزای دیگر صدا زده می شود. هدف از تست رابط تشخیص خطاهایی است که ممکن است در سیستم بدلیل خطاهای رابط یا فرض نادرست از رابط اتفاق بیفتد.شکل۱۵-۲۰ تست رابط را شرح می دهد.فلشهایی که به مرز جعبه ها می روند به این معناست که موارد تست (داده های تست) برای اجزاء شخصی کاربرد ندارد ، اما زیر سیستم بوسیله ترکیب این اجزا ساخته می شود. این نوع از تست مخصوصا” برای فرآیند تولید شی گرا ، در هنگامی که اشیاء و کلاسهای اشیاء دوباره بکار گرفته می شوند، مهم است. اشیاء بطور مخصوص با رابطهایشان تعریف می شوند و ممکن است در ترکیب با اشیاء دیگر در سیستمهای مختلف دوباره بکار گرفته شوند. خطاهای رابط بوسیله تست اشیاء شخصی قابل تشخیص نیست. زیرا خطا در نتیجه بر هم کنش و تاثیر اجزا بر هم رخ می دهد نه در اثر رفتار یک شی ساده .رابطهای مختلفی بین اشیاء وجود دارد به همین دلیل انواع مختلف خطا می تواند رخ دهد.
۱رابطهای پارامتر: این رابطها هنگامی بکار می روند که داده یا بعضی توابع ارجاع شده از یک جزء به اجزاء دیگر عبور کند.
۲رابطهای misunderstand :این رابطها در جایی بکار می روند که یک بلاک از حافظه بین زیر سیستمها مشترک است و داده بوسیله یک زیر سیستم در حافظه قرار می گیرد و توسط زیر سیستمهای دیگر مورد استفاده قرار می گیرد.
۳رابطهای روال: اینها هنگامی بکار می روند که یک زیر سیستم یک مجموعه از روالهایی که می توانند توسط زیر سیستمهای دیگر فرا خوانی شوند را ارائه می دهد.
۴رابطهای انتقال پیام : اینها رابطهایی هستند که هنگامی مورد استفاده قرار می گیرند که یک زیر سیستم تقاضای یک سرویس از زیر سیستم دیگر را توسط عبور پیام به آن بدهد.پیام برگشتی شامل نتایج اجرای سرویس است. بعضی از سیستمهای شی گرا این شکل از رابطه ها را دارند مثل سیستمهای مشتری – خدمتگذار.
خطاهای رابط یکی از اشکال معمول خطا در سیستمهای پیچیده هستند. این خطاها به سه کلاس طبقه بندی می شوند:
۱بکارگیری نادرست رابط: فراخوانی یک جزء ، بعضی از اجزاء دیگر را فراخوانی می کندو خطا در استفاده از رابط رخ می دهد. این نوع از خطا معمولا” مربوط به رابطهای پارامتر می شود ، وقتی که ممکن است پارامترها از نوع نادرست باشند ، ممکن است در یک ترتیب اشتباه یا تعداد نادرستی از پارامترهایی که ممکن است انتقال یابد.
۲عدم درک رابط : یک فراخوانی در یک جزء درک نادرستی از تشریح رابط جزء فراخوانی شده دارد و یک فرض غلط درباره رفتار جزء فراخوانی شده ایجاد می شود. و شی مورد نظر مطابق انتظار عمل نمی کند و این باعث رفتار غیر قابل انتظار در جزء فرا خواننده می شود. مثلا” ممکن است یک روتین جستجوی دودویی فراخوانی شود با یک آرایه نامرتب. این جستجو به خطا منجر می شود.
۳ خطاهای زمانی : این نوع خطا در سیستمهای real-time اتفاق می افتد که یک حافظه مشترک یا انتقال پیام را بکار می برند.تولید کننده یا مصرف کننده داده ممکن است با سرعتهای مختلف عمل کنند، در صورتی که مراقبت عملی در رابط طراحی نشود، مصرف کننده داده های منسوخ شده را دستیابی می کند زیرا تولید کننده اطلاعات حافظه مشترک را به روز نکرده است .
تست برای تشخیص عیوب رابط کاری دشوار است زیرا بعضی از خطاهای رابط ممکن است فقط در شرایط نامعمول خودشان را نشان دهند. برای مثال یک شیء که یک صف با طول ثابت را به عنوان ساختار داده پیاده سازی می کند. یک شیء فراخواننده ممکن است فرض کند که صف بعنوان یک ساختار داده نامحدود پیاده سازی شده و برای سر ریز شدن صف نیز ممکن است چک کردن صورت نگیرد. این شرایط در طول تست ، فقط توسط طراحی موارد تست که موجب سرریز می شوند، تشخیص داده می شوند و موجب می شود که سرریز رفتار شیء را در بعضی راههای تشخیص خراب کند.یک خطای دیگر نیز ممکن است در اثر تاثیر خطاها در ماژولها و اشیاء مختلف صورت گیرد.
ممکن است خطاها در یک شیء فقط وقتی رخ دهد که بعضی اشیا را دیگر بطور غیر قابل انتظار رفتار کنند. برای مثال شیء ممکن است که فرض کند شیء دیگر رفتارش درست است. اگر یک درک غیر صحیح درباره مقدار محاسبه شده بوجود آید، مقدار بازگشتی ممکن است معتبر(valid) باشد ولی نادرست است. این خطا خودش را در هنگام محاسبات بعدی نشان می دهد.
بعضی از رهنمونهای کلی برای تست رابط عبارتند از:
۱کدی که قرار است تست شود را آزمایش کنید و هر فراخوانی به اشیاء خارجی را لیست کنید. یک مجموعه تست طراحی کنید که مقادیر پارامترها به اجزای خارجی در انتهای بازه شان باشند.(انتخاب مقادیر مرزی)
۲وقتی اشاره گرها در طول یک رابط انتقال می یابد همیشه رابط را با پارامترهای nil محاسبه کنید.
۳وقتی یک شی از طریق رابط روالی فراخوانده می شود، تستهایی طراحی کنید که باعث خطای اشیاء فرا خواننده شود.فرضیات خطای متفاوت یکی از معمول ترین درک ناصحیح از تشریح سیستم هستند.
۴تست فشار را همانطور که در بخش بعدی بحث شده، در سیستم های انتقال پیام بکار گیرید. تستهایی طراحی کنید که بعضی پیامهای اضافی از آنچه در عمل اتفاق می افتد تو لید می کنند. در این روش ممکن است مشکلات زمانی رخ دهند.
۳هنگامی که چندین شیء از طریق حافظه مشترک، رابطه دارند، تستهایی طراحی کنید که ترتیب فعال شدن این اشیاء را تفاوت دهد.این تستها ممکن است فرضیات واضح تولید شده توسط برنامه نویسان درباره ترتیب تولید و مصرف در حافظه مشترک را آشکار کند.روشهای ایستا اغلب از تست برای تشخیص خطاهای رابط پر هزینه ترند.یک زبان مثل جاوا بعضی خطاهای رابط را بوسیله کامپایلر تسخیر می کند.(در تله می اندازد) در حالی که در زبانی مثلC یک تحلیلگر ایستا مثلLINT (فصل۱۹) خطاهای رابط را تشخیص می دهد. بازرسی برنامه می تواند روی رابطهای اجزاء و سوالاتی که در طول فرآیند بازرسی درباره رفتار فرض شده رابطها پرسیده میشود، تمرکز یابد.

تست فشار
پس از اینکه یک سیستم بطور کامل جمع شد، تست سیستم برای خصوصیات خارجی (فصل۲ را ببینید) مثل کارآیی و قابلیت اطمینان امکان پذیر است. تست کارآیی باید طراحی شود تا تضمین شود که سیستم می تواند بارکاری همکارش را پردازش کند.این مرحله شامل طراحی یک سری از تستهاست که بار کار بطور پیوسته افزایش می یابد تا اینکه کارآیی سیستم غیر قابل قبول شود.
کلاسهایی از سیستمها برای دستکاری بار کاری مشخص شده ای طراحی شده اند. برای مثال یک سیستم پردازش کار ممکن است برای پردازش بیشتر از ۱۰۰ تراکنش طراحی شده باشد، یک سیستم عامل ممکن است طراحی شده باشد که بیشتر از ۲۰۰ پایانه مجزا را دستکاری کند. تست فشار این تستها را در محدوده خارج از مقدار ماکزیمم بارکاری طراحی شده ، ادامه می دهد تا اینکه سیستم با شکست مواجه شود. این نوع از تست دو عملیات دارد:
۱رفتار شکست سیستم را تست می کند. موقعیتی ممکن رخ می دهد که در آن یک ترکیب غیر قابل انتظار رویدادها که بارکاری قرار شده در سیستم از بار ماکزیمم بیشتر شود. در این موقعیت این مهم است که شکست سیستم منجر به خرابی داده ها یا گم شدگی سرویسهای کاربر نشود. تست سیستم چک می کند که بارکاری سیستم منجر به خطای نرم شود بجای فروریختگی در زیر بار کاری.
۲فشار به سیستم وارد می شود و ممکن است که باعث شود عیوبی که در حالت عادی خود را نشان نمی دادند پدیدار شوند. اگر چه این جای بحث دارد که بروز خطاها در حالت عادی بعید است. ممکن است ترکیبات نا معمولی از موقعیتهای عادی وجود داشته باشد که باعث تکرار تست فشار می شود. تست فشار عملا” برای سیستمهای توزیع شده بر مبنای شبکه ای از پردازشگرها مناسب است. این سیستمها بار کار سنگینی را قبول می کنند، بنابراین شبکه در داده های هماهنگ که پردازشگرهای مختلف ردوبدل می کنند غرق می شوند لذا پردازشگرها کندتر و کندتر می شوند هنگامی که منتظر دریافت داده از پردازشگرهای دیگر هستند.

تست شی گرا:
در شکل(۱-۲۰) گفتیم که دو فعالیت پایه اساسی در فرآیند تست وجود دارد که عبارتند از: تست اجزاء که در آن اجزاء سیستم بطور مجزا تست می شدند و تست تجمعی که جمعی از اجزاء با هم زیر سیستم و سیستم نهایی را برای تست آماده می کنند. این فعالیتها بطور معادل برای سیستمهای شیءگرا قابل کاربرد است. با این وجود، تفاوتهای عمده ای بین سیستمهای شی گرا و سیستمهای تابعی وجود دارد:
۱اشیاء به عنوان اجزاء شخصی اغلب ازیک تابع ساده بزرگترند.
۲اشیایی که با هم تشکیل زیر سیستم می دهند معمولا” آزادانه با هم ارتباط دارند و “بالای سیستم “وجود ندارد.( ساختار سلسله مراتبی)
۳اگر اشیاء دوباره بکار گرفته شود، تست کننده ممکن است به کد منبع اجزاء برای تحلیل دسثرسی نداشته باشد. این تفاوتها به این معنی است که روشهای تست جعبه سفید بر مبنای تحلیل کد، باید گسترش یابد تا بتواند اشیاء بزرگ را پوشش دهد و روشهای دیگر برای تست تجمعی باید تطابق پیدا کند. با این وجود پس از اینکه سیستم، تولید شد این واقعیت که آن به عنوان سیستم شی گراتولیدشده نباید برای کاربر مشخص شود.

چهار سطح از تست می تواند تعریف شود:
۱تست عملیات شخصی مربوط به شیء: توابع یا روالهایی در شیء موجود است و در روشهای جعبه سیاه و جعبه سفید می تواند بکار رود.
۲تست کلاسهای شیء مجزا: اصل تست جعبه سیاه بدون تغییر باقی می ماند، اما عبارت یک کلاس معادل باید برای پوشش دنباله روابط مربوطه گسترش یابد. بطور مشابه، تست ساختاری احتیاج به نوعی متفاوت از تحلیل دارد.این در بخش (۱-۳-۲۰) بحث شده است.
۳تست گروهی اشیاء: تست بالا به پایین یا پایین به بالا برای تولید گروهی از اشیاء وابسته نامناسب است. روشهای دیگری بعنوان سناریو بر مبنای تست باید بکار رود. این در بخش (۲-۳-۲۰) بحث شده است.
۴تست سیستم شی گرا: validation و verification در مقابل شرح احتیاجات سیستم انجام می شود، دقیقا” همانطور که برای هر نوع دیگری از سیستم انجام می شود. روشهای تست برای سیستمهای شیءگرا به سرعت و اکنون یک برنامه خوب از اطلاعات موجود روی تکنیکهای تست شی گرا موجود است.(۱۹۹۹Binde ) بخش بعدی یک نگاه کلی بر روشهای پایه تست سیستمهای شی گرا دارد.

تست کلاس شیء:
روش تستی که در بخش (۳-۱-۲۰) بحث شد در رابطه بود با تضمین اینکه همه جملات برنامه حداقل یکبار اجرا شود یا همه شاخه های اجرایی، اجرا شود. یک تست کامل، برای تست اشیاء باید شامل:
۱تست جداگانه، جدا از همه عملیات مربوط شیء
۲بازرسی و فعال کردن همه صفات مربوط به شیء
۳بررسی اجرای شیء در همه حالات ممکن. این بدان معناست که همه رویدادهایی که باعث تغییر حالت در شیء می شوند، باید شبیه سازی شوند.
برای مثال، ایستگاه هوایی از فصل ۱۲ که رابطش در شکل(۱۶-۲۰) نشان داده شده است را در نظر بگیرید. آن شیء فقط یک صفت ساده دارد که همان شناسه اش است. این یک ثابت است که وقتی یک ایستگاه هوایی نصب می شود (set) یک می شود. شما نیاز دارید که موارد تست را برای گزارش هوا، تست، startup و shutdown تعریف کنید. در حالت ایده آل شما باید متدها را به تنهایی تست کنید، اما در بعضی موارد تست دنباله ای از موارد لازم است.