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

بخشی از مقاله

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

* راههای مخصوص برای تست کردن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
اگر همه اين شاخه ها اجرا شوند می توانيم مطمئن باشيم که
1.هر دستور در تابع حداقل يکبار اجرا شده است.
2.هر شاخه هم برای true و هم برای false تست شده است.
تعداد شاخه های مستقل در يک برنامه می تواند بوسيله محاسبه پيچيدگی سيکلوماتيک(c.c) از گراف ريزشی برنامه بدست آيد.پيچيدگی سيکلوماتيک از يک گراف مرتبط مثل G از فرمول زير به دست می آيد.
2+تعداد نودها –تعداد لبه ها=(G)CC
برای برنامه های فاقد دستور goto مقدارcc يک واحد بيشتر از تعداد شرطها در برنامه است.در يک جمله شرطی يا ترکيبی از شروط بايد همه تستها که روی شرطها می تواند انجام شود را بشماريم. بنابراين اگر 6 دستور if و 1 حلقه while که همه شرطها ساده هستند داشته باشيم cc برابر است با 8.
اگر يک عبارت شرطی يک بيان ترکيبی از دو عملگر(and ياar) بود، cc برابر بود با 10 .ccی يک روتين جستجوی دودويی برابر است با 4 .بعد از کشف تعداد شاخه های مستقل کد، توسطcc، مرحله بعدی طراحی موارد تست برای اجرای هر يک از شاخه هاست. حداقل تعداد موارد تست برای همه شاخه ها برابر است با cc .
طراحی موارد تست در مورد روتين جستجوی دودويی نشان داده شده است. با اين وجود وقتی يک برنامه ساختار درختی پيچيده داشته باشد، پيش بينی اينکه هر مورد تست عملی چگونه پردازش خواهد شد ، مشکل است.در اين مورد يک تحليلگر پويا می تواند برای ايجاد profile اجرايی برنامه ها بکار رود.تحليل گر پويا يک ابزار تست کننده است که در ارتباط با کامپايلر کار می کند.
در طول کامپايل، دستورات کد شده شئی اضافی به توليد کننده کد پيوند می خورد. اينها تعداد دفعاتی که هر دستور برنامه اجرا می شود را می شمارند.
بعد از اجرای برنامه يک profile اجرايی می تواند چاپ شود که تعيين کند کدام قسمتهای برنامه در طول اجرای برنامه با داده های تست اجرا شدند و کدام قسمتها اجرا نشدند. اين profile اجرای بخشهای تست نشده برنامه را مشخص می کند.
تست تجمعی
پس از اينکه اجزای برنامه شخصی تست شدند، آنها بايد با هم تشکيل سيستم کامل و کاربردی را بدهند.اين مرحله شامل ساختن سيستم(فصل 29 را ببينيد) و تست سيستم حاصل،به خاطر بروز مشکلاتی که در اثر بر هم کنش اجزاء بر هم رخ دهد، می باشد. تست تجمعی بايد با استفاده از شرح سيستم توليد شود و هر زمان که تعدادی از اجزاء سيستم بطور قابل استفاده (کاربرد) وجود داشته باشد، تست بايد آغاز شود.مشکل مهمی که در تست تجمعی رخ می دهد خطاهای محلی است که در طول اين مرحله کشف می شود.تاثیرات پيچيده ای بين اجزاء سيستم وجود دارد. وقتی يک خروجی ناهمگون کشف شود پيدا کردن منبع خطا بسيار سخت است.برای ساده تر کردن آن شما بايد هميشه يک روش تدريجی (افزايشی) را برای تست و توليد سيستم بکار ببريد.ابتدا بايد شما يک موقعيت مينيمم از سيستم را ايجاد کنيد، (تشکيل و ترکيب چند جزء کوچک) و اين سيستم را تست کنيد. سپس شما بايد اجزاء را به اين موقعيت مينيمال (minimal) اضافه کنيد و پس از هر افزودن اجزا را تست کنيد.
در مثال نشان داده شده13-20 دنباله تستهای T1 وT2 وT3 ابتدا روی سيستمی که از ماژولهای A و B (سيستم مينيمم) تشکيل شده اجرا می شوند. اگر خطايی رخ دهد تصحيح می شود. ماژول c اضافه می شود و T1وT2 وT3 هم تکرار می شوند تا مطمئن شويم که تاثير (بر هم کنش) غير قابل انتظاری در رابطه A/B وجود ندارد.
اگر مشکل در اين تستها رخ دهد، اين احتمالا" به اين معناست که خطا در نتيجه تاثيرات ماژول جديد است. منبع خطا مشخص شده ، پس براحتی محل خطا تشخيص داده می شود و خطا تصحيح می شود. دنباله تست T4 همچنين روی سيستم اجرا می شود. سرانجام ماژول D اضافه شده و با تست جديد و بعدی D5 تست می شود.
عوامل سيستم ممکن است برای تعدادی از اجزا گسترش يابد. بنابراين پياده سازی يک عامل جديد ممکن است احتياج به چندين جزء برای ترکيب شدن داشته باشد.
تست ممکن است در نتيجه تاثير بين اين اجزاء شخصی با بقيه اجزاء با خطا روبرو شود و ممکن است تعمير خطا کاری دشوار باشد زيرا روی همه اجزا که عوامل سيستم را پياده سازی کردند تاثير می گذارد.بعلاوه وقتی يک جزءجديد اضافه شد و تست شد اين می تواند قالب تاثيرات اجزای قبلی که تست شدند را تغيير دهد.خطاهايی نيزممکن است رخ دهند که در تست موقعيت ساده تر کشف نشده اند.

تست بالا به پايين و پايين به بالا:
استراتژيهای تست بالا به پايين و پايين به بالا روشهای مختلف ترکيب اجزای سيستم را نشان می دهند.
در روش بالا به پايين ، اجزای سطح بالای سيستم ترکيب می شوند ، و قبل از اينکه طراحی و پياده سازی آنها کامل شود تست می شوند.در روش پايين به بالا اجزاء سطح پايين ترکيب شده و تست می شوند قبل از اينکه اجزاء سطح بالا توليد شوند.تست بالا به پايين مجموع قسمتهای فرآيند توليد بالا به پايين است که فرآيند توليد با اجزاء سطح بالا شروع می شود و توليد به سمت پايين در ساختار سلسله مراتبی پيش می رود.برنامه بعنوان يک جزء انتزاعی با زير اجزايی که بوسيله ريشه درخت مشخص شده اند ارائه می شود. بعد از اينکه اجزاء سطح بالا برنامه نويسی و تست شدند زير اجزاء نيز به همان روش پياده سازی و تست می شوند.بنابراين کل سيستم بطور کامل تست می شوند.به وضوح تست پايين به بالا شامل ترکيب و تست ماژولهای سطح پايين در ساختار و سلسله مراتبی و سپس حرکت به سمت بالا و ساخت ماژولها تا اينکه ماژولهای نهايی تست شوند.
اين روش نيازی به طراحی معماری سيستم برای کامل شدن ندارد بنابراين می تواند از يک مرحله آغازين (اوليه) در فرآيند توسعه شروع کند. اين می تواند در هنگامی که سيستم دوباره بکار گرفته شود و اجزا را با استفاده از سيستمهای ديگر تغيير می دهد بکار رود.
تست تجمعی بالا به پايين و پايين به بالا می تواند از چهار نظر مقايسه شود:
1.معماری:روش بالا به پايين به خوبی خطاها در معماری سيستم را کشف می کند و طراحی سطح بالا در يک مرحله آغازين از فرآيند توليد را ايجاد می کند. هنگامی که خطای ساختاری معمولی وجود داشته باشد، کشف بموقع يعنی اينکه می توان بدون هزينه برگشت به مراحل قبل ، تصحيح را انجام داد.با تست پايين به بالا ، طراحی سطح بالا توليد نمی شود مگر در مراحل نهايی فرآيند.
2.اثبات سيستم: با روش بالا به پايين توليد سيستم کاربردی بطور محدود در مراحل آغازين، امکان پذير است.اين يک عامل مهم روانی برای کسانی که در توليد سيستم حضور دارند می باشد.زيرا عملی بودن سيستم برای مديريت را اثبات می کند.
صحت سيستم (validation ) به محض اينکه سيستم قابل اثبات بتواند به کاربر ارائه شود، می تواند انجام شود.با اين وجود،اگر سيستم از اجزای قابل استفاده مجدد ساخته شده باشد، توليد بعضی انواع اثبات با استفاده از روش پايين به بالانيز امکان پذير است.
3.پياده سازی تست: پياده سازی تست بالا به پايين دشوار است زيرا بايد برگها که ستون پايين سيستم را شبيه سازی می کنند توليد شوند. اين برگها ممکن است فقط يک نوع ساده شده از اجزاء مورد نياز باشد، يا ممکن است به تست کننده تقاضای ورود داده مناسب، يا شبيه سازی عملی اشتقاق تست اجزاء را بدهند.
در هنگام بکارگيری تست پايين به بالا شما بايد اشتقاق داده را برای اعمال سطوح پايين بنويسيد.اين اشتقاق داده ها محيط اجزا را شبيه سازی می کنند و اجزايی که بايد تست شوند را فراخوانی می کنند.
4.مشاهده تست: هر دو روش بالا به پايين و پايين به بالا می تواند در مشاهده تست مشکل داشته باشد. در بعضی سيستمها سطوح بالاتر سيستم که در روش بالا به پايين در ابتدا پياده سازی می شوند، خروجی توليد نمی کنند اما برای تست اين سطوح بايد اين کار را انجام دهيم. تست کننده بايد يک محيط مصنوعی برای توليد نتايج تست ايجاد کند. با تست پايين به بالا نيز خلق محيط مصنوعی ممکن است لازم باشد.(اشتقاق تست)] برای مشاهده اجرای اجزاء سطوح پايين تر[
سيستمها معمولا" با ترکيب روشهای بالا به پايين و پايين به بالا توليد و تست می شوند.
برای قسمتهای مختلف سيستم ، زمانبرهای توليد مختلف وجود دارد،به اين معنی که تيمهای ترکيب و تست بايد با هر جزيی که موجود است کار کند. بنابراين مخلوطی از برگها و اشتقاقهای تست بايد در طول فرآيند تست تجمعی توليد شود.

تست رابط
در هنگامی که ماژولها يا زير سيستمها برای خلق سيستمهای بزرگتر با هم ترکيب می شوند، مورد استفاده قرار می گيرد.هر ماژول يا زير سيستم يک رابط تعريف شده دارد که بوسيله اجزای ديگر صدا زده می شود. هدف از تست رابط تشخيص خطاهايی است که ممکن است در سيستم بدليل خطاهای رابط يا فرض نادرست از رابط اتفاق بيفتد.شکل15-20 تست رابط را شرح می دهد.فلشهايی که به مرز جعبه ها می روند به اين معناست که موارد تست (داده های تست) برای اجزاء شخصی کاربرد ندارد ، اما زير سيستم بوسيله ترکيب اين اجزا ساخته می شود. اين نوع از تست مخصوصا" برای فرآیند تولید شی گرا ، در هنگامی که اشیاء و کلاسهای اشیاء دوباره بکار گرفته می شوند، مهم است. اشیاء بطور مخصوص با رابطهایشان تعریف می شوند و ممکن است در ترکیب با اشیاء دیگر در سیستمهای مختلف دوباره بکار گرفته شوند. خطاهای رابط بوسیله تست اشیاء شخصی قابل تشخیص نیست. زیرا خطا در نتیجه بر هم کنش و تاثیر اجزا بر هم رخ می دهد نه در اثر رفتار یک شی ساده .رابطهای مختلفی بین اشیاء وجود دارد به همین دلیل انواع مختلف خطا می تواند رخ دهد.
1.رابطهای پارامتر: این رابطها هنگامی بکار می روند که داده یا بعضی توابع ارجاع شده از یک جزء به اجزاء دیگر عبور کند.
2.رابطهای misunderstand :این رابطها در جایی بکار می روند که یک بلاک از حافظه بین زیر سیستمها مشترک است و داده بوسیله یک زیر سیستم در حافظه قرار می گیرد و توسط زیر سیستمهای دیگر مورد استفاده قرار می گیرد.
3.رابطهای روال: اینها هنگامی بکار می روند که یک زیر سیستم یک مجموعه از روالهایی که می توانند توسط زیر سیستمهای دیگر فرا خوانی شوند را ارائه می دهد.
4.رابطهای انتقال پیام : اینها رابطهایی هستند که هنگامی مورد استفاده قرار می گیرند که یک زیر سیستم تقاضای یک سرویس از زیر سیستم دیگر را توسط عبور پیام به آن بدهد.پیام برگشتی شامل نتایج اجرای سرویس است. بعضی از سیستمهای شی گرا این شکل از رابطه ها را دارند مثل سیستمهای مشتری – خدمتگذار.
خطاهای رابط یکی از اشکال معمول خطا در سیستمهای پیچیده هستند. این خطاها به سه کلاس طبقه بندی می شوند:
1.بکارگیری نادرست رابط: فراخوانی یک جزء ، بعضی از اجزاء دیگر را فراخوانی می کندو خطا در استفاده از رابط رخ می دهد. این نوع از خطا معمولا" مربوط به رابطهای پارامتر می شود ، وقتی که ممکن است پارامترها از نوع نادرست باشند ، ممکن است در یک ترتیب اشتباه یا تعداد نادرستی از پارامترهایی که ممکن است انتقال یابد.
2.عدم درک رابط : یک فراخوانی در یک جزء درک نادرستی از تشریح رابط جزء فراخوانی شده دارد و یک فرض غلط درباره رفتار جزء فراخوانی شده ایجاد می شود. و شی مورد نظر مطابق انتظار عمل نمی کند و این باعث رفتار غیر قابل انتظار در جزء فرا خواننده می شود. مثلا" ممکن است یک روتین جستجوی دودویی فراخوانی شود با یک آرایه نامرتب. این جستجو به خطا منجر می شود.
3. خطاهای زمانی : این نوع خطا در سیستمهای real-time اتفاق می افتد که یک حافظه مشترک یا انتقال پیام را بکار می برند.تولید کننده یا مصرف کننده داده ممکن است با سرعتهای مختلف عمل کنند، در صورتی که مراقبت عملی در رابط طراحی نشود، مصرف کننده داده های منسوخ شده را دستیابی می کند زیرا تولید کننده اطلاعات حافظه مشترک را به روز نکرده است .
تست برای تشخیص عیوب رابط کاری دشوار است زیرا بعضی از خطاهای رابط ممکن است فقط در شرایط نامعمول خودشان را نشان دهند. برای مثال یک شیء که یک صف با طول ثابت را به عنوان ساختار داده پیاده سازی می کند. یک شیء فراخواننده ممکن است فرض کند که صف بعنوان یک ساختار داده نامحدود پیاده سازی شده و برای سر ریز شدن صف نیز ممکن است چک کردن صورت نگیرد. این شرایط در طول تست ، فقط توسط طراحی موارد تست که موجب سرریز می شوند، تشخیص داده می شوند و موجب می شود که سرریز رفتار شیء را در بعضی راههای تشخیص خراب کند.یک خطای دیگر نیز ممکن است در اثر تاثیر خطاها در ماژولها و اشیاء مختلف صورت گیرد.
ممکن است خطاها در یک شیء فقط وقتی رخ دهد که بعضی اشیا را دیگر بطور غیر قابل انتظار رفتار کنند. برای مثال شیء ممکن است که فرض کند شیء دیگر رفتارش درست است. اگر یک درک غیر صحیح درباره مقدار محاسبه شده بوجود آید، مقدار بازگشتی ممکن است معتبر(valid) باشد ولی نادرست است. این خطا خودش را در هنگام محاسبات بعدی نشان می دهد.
بعضی از رهنمونهای کلی برای تست رابط عبارتند از:
1.کدی که قرار است تست شود را آزمایش کنید و هر فراخوانی به اشیاء خارجی را لیست کنید. یک مجموعه تست طراحی کنید که مقادیر پارامترها به اجزای خارجی در انتهای بازه شان باشند.(انتخاب مقادیر مرزی)
2.وقتی اشاره گرها در طول یک رابط انتقال می یابد همیشه رابط را با پارامترهای nil محاسبه کنید.
3.وقتی یک شی از طریق رابط روالی فراخوانده می شود، تستهایی طراحی کنید که باعث خطای اشیاء فرا خواننده شود.فرضیات خطای متفاوت یکی از معمول ترین درک ناصحیح از تشریح سیستم هستند.
4.تست فشار را همانطور که در بخش بعدی بحث شده، در سیستم های انتقال پیام بکار گیرید. تستهایی طراحی کنید که بعضی پیامهای اضافی از آنچه در عمل اتفاق می افتد تو لید می کنند. در این روش ممکن است مشکلات زمانی رخ دهند.
3.هنگامی که چندین شیء از طریق حافظه مشترک، رابطه دارند، تستهایی طراحی کنید که ترتیب فعال شدن این اشیاء را تفاوت دهد.این تستها ممکن است فرضیات واضح تولید شده توسط برنامه نویسان درباره ترتیب تولید و مصرف در حافظه مشترک را آشکار کند.روشهای ایستا اغلب از تست برای تشخیص خطاهای رابط پر هزینه ترند.یک زبان مثل جاوا بعضی خطاهای رابط را بوسیله کامپایلر تسخیر می کند.(در تله می اندازد) در حالی که در زبانی مثلC یک تحلیلگر ایستا مثلLINT (فصل19) خطاهای رابط را تشخیص می دهد. بازرسی برنامه می تواند روی رابطهای اجزاء و سوالاتی که در طول فرآیند بازرسی درباره رفتار فرض شده رابطها پرسیده میشود، تمرکز یابد.

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

تست شی گرا:
در شکل(1-20) گفتیم که دو فعالیت پایه اساسی در فرآیند تست وجود دارد که عبارتند از: تست اجزاء که در آن اجزاء سیستم بطور مجزا تست می شدند و تست تجمعی که جمعی از اجزاء با هم زیر سیستم و سیستم نهایی را برای تست آماده می کنند. این فعالیتها بطور معادل برای سیستمهای شیءگرا قابل کاربرد است. با این وجود، تفاوتهای عمده ای بین سیستمهای شی گرا و سیستمهای تابعی وجود دارد:
1.اشیاء به عنوان اجزاء شخصی اغلب ازیک تابع ساده بزرگترند.
2.اشیایی که با هم تشکیل زیر سیستم می دهند معمولا" آزادانه با هم ارتباط دارند و "بالای سیستم "وجود ندارد.( ساختار سلسله مراتبی)
3.اگر اشیاء دوباره بکار گرفته شود، تست کننده ممکن است به کد منبع اجزاء برای تحلیل دسثرسی نداشته باشد. این تفاوتها به این معنی است که روشهای تست جعبه سفید بر مبنای تحلیل کد، باید گسترش یابد تا بتواند اشیاء بزرگ را پوشش دهد و روشهای دیگر برای تست تجمعی باید تطابق پیدا کند. با این وجود پس از اینکه سیستم، تولید شد این واقعیت که آن به عنوان سیستم شی گراتولیدشده نباید برای کاربر مشخص شود.

چهار سطح از تست می تواند تعریف شود:
1.تست عملیات شخصی مربوط به شیء: توابع یا روالهایی در شیء موجود است و در روشهای جعبه سیاه و جعبه سفید می تواند بکار رود.
2.تست کلاسهای شیء مجزا: اصل تست جعبه سیاه بدون تغییر باقی می ماند، اما عبارت یک کلاس معادل باید برای پوشش دنباله روابط مربوطه گسترش یابد. بطور مشابه، تست ساختاری احتیاج به نوعی متفاوت از تحلیل دارد.این در بخش (1-3-20) بحث شده است.
3.تست گروهی اشیاء: تست بالا به پایین یا پایین به بالا برای تولید گروهی از اشیاء وابسته نامناسب است. روشهای دیگری بعنوان سناریو بر مبنای تست باید بکار رود. این در بخش (2-3-20) بحث شده است.
4.تست سیستم شی گرا: validation و verification در مقابل شرح احتیاجات سیستم انجام می شود، دقیقا" همانطور که برای هر نوع دیگری از سیستم انجام می شود. روشهای تست برای سیستمهای شیءگرا به سرعت و اکنون یک برنامه خوب از اطلاعات موجود روی تکنیکهای تست شی گرا موجود است.(1999.Binde ) بخش بعدی یک نگاه کلی بر روشهای پایه تست سیستمهای شی گرا دارد.

تست کلاس شیء:
روش تستی که در بخش (3-1-20) بحث شد در رابطه بود با تضمین اینکه همه جملات برنامه حداقل یکبار اجرا شود یا همه شاخه های اجرایی، اجرا شود. یک تست کامل، برای تست اشیاء باید شامل:
1.تست جداگانه، جدا از همه عملیات مربوط شیء
2.بازرسی و فعال کردن همه صفات مربوط به شیء
3.بررسی اجرای شیء در همه حالات ممکن. این بدان معناست که همه رویدادهایی که باعث تغییر حالت در شیء می شوند، باید شبیه سازی شوند.
برای مثال، ایستگاه هوایی از فصل 12 که رابطش در شکل(16-20) نشان داده شده است را در نظر بگیرید. آن شیء فقط یک صفت ساده دارد که همان شناسه اش است. این یک ثابت است که وقتی یک ایستگاه هوایی نصب می شود (set) یک می شود. شما نیاز دارید که موارد تست را برای گزارش هوا، تست، startup و shutdown تعریف کنید. در حالت ایده آل شما باید متدها را به تنهایی تست کنید، اما در بعضی موارد تست دنباله ای از موارد لازم است.