اصول آزمایش نرم افزار در مهندسی نرم افزار

آزمایش یک ضعف مهندسین نرم افزار را آشکار میکند، در حالی که آنها ذاتاً افراد سازنده ای هستند.

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

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

 

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

 

فعالیت تست نرم افزار:

یکی از تعاریفی که برای قابلیت آزمایش ارائه شده است، این است: “قابلیت آزمایش نرم افزار، سهولت آزمایش یک سیستم کامپیوتری است.”

خصوصیت های زیر به نرم افزار قابل آزمایش منتهی میشوند:

1- قابلیت اجرا (عملیاتی بودن – Operability) : هر چه نرم افزار بهتر کار کند، با کارایی بالاتری آزمایش میشود.

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

 

2- قابلیت مشاهده (مشاهده پذیری – Observability) : آنچه میبینید آزمایش میکنید.

خروجی های مجزا برای ورودی ها به عنوان بخشی از آزمایش تولید میشوند. حالت های سیستم و متغیرها در ضمن اجرا قابل رؤیت و قابل پرس و جو هستند.

خروجی غلط به راحتی مشخص میشود و خطاهای داخلی به طور خودکار از طریق مکانینزم های خود آزمایی آشکار و گزارش میشوند.

همچنین می بایست کد مبدأ قابل دسترسی باشد.

 

3- قابلیت کنترل (کنترل پذیری – Controlability) : هرچه نرم افزار بهتر کنترل شود، آزمایش بیشتر به طور خودکار و بهینه قابل انجام است.

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

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

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

 

4- تجزیه پذیری (Decomposability) : با کنترل کردن محدوده آزمایش، با سرعت بیشتری مسائل تجزیه میشوند و آزمایش های هوشمندانه تری انجام میگیرد.

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

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

 

5- سادگی (Simplicity) : هر چه مورد برای آزمایش کمتر باشد، نرم افزار با سرعت بیشتری قابل آزمایش است.

این اصل به کاهش پیچیدگی معماری و منطق برنامه میپردازد.

اصل سادگی نرم افزار خود به چند بخش تقسیم میشود:

– سادگی تابعی (برای مثال، مجموعه ویژگی هایی که حداقل لازم برای دستیابی به نیازها هستند.)

– سادگی ساختاری (برای مثال، معماری پیمانه بندی (ماژولار) میشود تا انتشار اشکالات را محدود کند.)

– سادگی کد (برای مثال، رعایت استاندارد کد نویسی برای سهولت بازبینی و نگهداری)

 

6- پایداری (Stability) : هر چه تغییرات کمتر باشد، انحراف از آزمایش کمتر است.

تغییرات در نرم افزار مداوم نیستند و در زمان وقوع کنترل میشوند؛ همچنین تغییرات در نرم افزار، آزمایش های موجود را نامعتبر نمی سازد.

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

 

7- قابلیت فهم (درک پذیری – Understandability) : هر چه اطلاعات بیشتری در اختیار داشته باشیم، آزمایش هوشمندانه تری انجام میشود.

در حقیقت درک طراحی و وابستگی های بین اجزا باید به خوبی صورت بگیرد.

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

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

همچنین تغییرها در طراحی به آزمایش کننده ها منتقل میشوند.

 

خصوصیت های آزمایش نرم افزار:

نکته قابل بحث در اینجا این است که در مورد آزمایش ها چه نکته هایی مطرح خواهد بود ؟!

صفت های زیر توسط گروهی برای یک آزمایش خوب پیشنهاد میشود:

1- یک آزمایش خوب با احتمال بالا خطا را پیدا میکند.

به منظور دستیابی به این هدف، آزمایش کننده باید نرم افزار را بفهمد و سعی در توسعه تصویری رفتاری از نحوه شکست نرم افزار داشته باشد.

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

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

 

2- یک آزمایش خوب بیش از حد انجام نمیشود.

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

هر آزمایش باید هدف متفاوتی داشته باشد. (حتی اگر تفاوت غیر آشکاری باشد)

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

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

فرض میکنیم سیستم برای پذیرش رمز عبور 8080 برنامه ریزی شده باشد.

کلمه های عبور معتبر و نامعتبر (چهار عدد متوالی) در آزمایش های جداگانه وارد میشوند. به هر حال، هر کلمه عبور معتبر یا نامعتبر باید روش متفاوت شکست را بررسی نماید.

برای مثال، رمز نامعتبر 1234 نباید توسط این سیستم (برنامه ریزی شده برای دریافت کد 8080) پذیرفته شود. واضح است که در صورت پذیرفته شدن، خطایی آشکار میشود.

ورودی تست دیگر اگر 1235 باشد، اضافی است؛ زیرا همان هدف کد 1234 را خواهد داشت.

در حالت کلی، ورودی نامعتبر 8081 یا 8180 تفاوت بسیار ظریفی دارند. آنها سعی در نشان دادن این مورد دارند که برای کلمه های عبوری نزدیک به رمز معتبر ولی مخالف آن، خطایی وجود دارد.

 

3- یک آزمایش خوب، آزمایش بهینه است.

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

در چنین مواردی، آزمایشی که بیشترین احتمال کشف رده عمده ای از خطاها %B