آزمایشگاه آزمون و تایید نرم‌افزار دانشگاه شهید بهشتی

معرفی

ما که هستیم و چه میکنیم

آزمایشگاه آزمون و تأیید نرم افزار دانشگاه شهیدبهشتی، به هدف توسعه پژوهش و رشد صنعت آزمون نرم افزار و سایر حوزه های مرتبط با کیفیت نرم افزار در کشور، ایجاد شده است. با اتكاء به تجارب غني و با ارزش حاصل از اجراي پروژه‏هاي آزمون در صنعت، آزمایشگاه آزمون و تأیید نرم افزار در حال حاضر از لحاظ كادر تخصصي، اطلاعات فني- كارشناسي يكي از معتبرترین آزمایشگاه‌های مهندسي در زمينه آزمون نرم‌افزار در کشور محسوب مي‌گردد، و آمادگي پذيرش و اجراي طرح‌های بزرگ و پيچيده صنعتي به شكل مستقل و يا با همكاری شركت‌های مشاوره‌‏ای و تولیدکننده نرم‌افزار را در کشور دارا مي‌باشد. کادر علمی، فنی و اجرایی آزمایشگاه از سه عضو هیئت علمی دانشگاه شهیدبهشتی، 11 دانشجوی دکترا (8 نفر از دانشگاه شهید بهشتی و سه دانشجوی دکترای همکار از سایر دانشگاه‌ها)، بیش از 20 دانشجو و فارغ التحصیل کارشناسی ارشد، حدود 6 دانشجوی کارشناسی، چندین و چند نفر از افراد خبره و فعال در حوزه صنعت تشکیل شده است که هم اکنون در انجام فعالیت‌ها و خدمات پژوهشی و صنعتی مرتبط با آزمون و کیفیت نرم‌افزار مشارکت جدی دارند. افراد کلیدی آزمایشگاه بالغ بر ۱۰ سال است که در زمینه آزمون و اشکالزدایی نرم افزار از تجربیات صنعتی و پژوهشی قابل توجه برخوردارند.
مشاهده‌ی صفحه‌ی معرفی

آزمون در صنعت

آزمون­ پذیری

 

آزمون پذیری معیاری است که نشان می دهد یک محصول نرم افزاری (سیستم نرم افزاری، ماژول نرم افزاری، نیازمندیها، یا مستندات طراحی) از آزمون در یک زمینه مشخص پشتیبانی می کند.
آزمون پذیری نرم افزار فرآیند خطایابی و اشکالزدایی آن را تسهیل می کند. هر اندازه نرم افزاری با قابلیت ازمون پذیری بیشتری طراحی شود هزینه آزمون و کشف خطا در مراحل بعد به میزان قابل توجهی کاهش می یابد. بهتر است نرم افزارها در مراحل اولیه تولید با قابلیت آزمون پذیری طراحی شوند. هرچه این فرایند به تاخیر انداخته شود، هزینه های بعدی بیشتر خواهد بود. این مسئله در شکل زیر نشان داده شده است. با اینحال برای نرم افزارهایی که با این قابلیت طراحی نشده اند، با روشهای مختلف می توان این قابلیت را به آنها اضافه نمود.

موضوعاتی که در این حوزه باید آموزش داده شود:
مفهوم آزمون پذیری نرم افزار
آزمون پذیری جعبه سفید که شامل موارد زیر است:
-
پیچیدگی نرم افزار
-عدم قطعیت
-وابستگی
نقاط کنترل و مشاهده (PCO’s) که موارد زیر را در نظر می گیرد:
Asserts
Logging
Design by Contract
No Code Left Behind pattern
Percolation pattern
– 
یاریگرهای آزمون حالت (State Test Helpers) که شامل موارد زیر است:
Set state
Get current state
Logical State Invariant Functions
Reset
All actions controllable
All events observable
– 
ساختار مناسب برنامه ها
No cyclic dependencies
Don’t allow build dependencies to leak over structural and functional boundaries
Partition classes and packages to minimize interface complexity
آزمون تعبیه شده
آزمون پذیری جعبه سیاه که موارد زیر را در نظر می گیرد:
-
اندازه سیستم
-تعداد گرههای شکه

-ناثابتها(variants) شامل گزینه های پیکربندی، تعداد سکوهای پشتیبانی شونده، تعداد نسخه های نرم افزار
-مدل آزمون
-اوراکل
-خودکارسازی

خصوصیات آزمون پذیری
طراحی برای آزمون پذیری نرم افزار (Design for testability)
نحوه طراحی و تولید نرم افزار آزمون پذیر
نحوه تبدیل یک نرم افزاراماده به نرم افزار آزمون پذیر

آموزش طراحی معماری نرم افزار جهت افزایش قابلیت آزمون پذیری

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

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

مکان یابی خطا

ایجاد یک نرم‌افزار عاری از خطا، آرمان تولیدکنندگان نرم‌افزار است. با وجود تلاشهای فراوانی که از سوی تولیدکنندگان نرم‌افزار جهت شناسایی و حذف خطاهای معنایی نرم‌افزار در مراحل مختلف فرآیند توسعه آن صورت می‌گیرد، بخش زیادی از این خطاها به صورت پنهان در برنامه‌ها باقی مانده و بعدها در دستان کاربران نهایی نرم‌افزار نمایان می‌شوند. تخمین‌ها نشان می‌دهند مابین ۵۰ تا ۸۰ درصد هزینه‌ها و تلاش‌های صورت گرفته جهت توسعه و نگهداری نرم‌افزار، صرف آزمون و مکانیابی خطاهای موجود در برنامه‌های نرم‌افزاری می‌شوند. براساس آخرین گزارش منتشر شده (۲۰۱۳) از تحقیق دانشگاه کمبریج هزینه آزمون و اشکال‌زدایی‌نرم‌افزارها، در سطح جهان، به ۳۱۲ میلیارد دلار در سال بالغ می‌شود. برای اینکه تصور بهتری از این مبلغ در ذهن خواننده ایجاد شود، به پرداخت کمک مالی اتحادیه اروپا به کشورهای یونان، ایرلند، پرتغال و اسپانیا از سال ۲۰۰۸ تا به امروز، توجه کنید که در مجموع مبلغی بالغ بر ۵۹۱ میلیارد دلار در ۵ سال اخیر بوده است. این کمک مالی از نصفِ هزینه‌های آزمون در نرم‌افزارها در طی این پنج سال کمتر است! این امر، اهمیت غیرقابل انکار تکنیک‌های خودکار آزمون نرم‌افزار به هدف کاهش زمان و هزینه‌های توسعه نرم‌افزار را نشان می‌دهد. بی‌دلیل نیست که در سالهای اخیر محققان و دانشمندان بسیاری، زمان و تمرکز خود را صرف ابداع و توسعه روش‌ها و ابزارهای خودکارسازی آزمون و مکان یابی خطا نموده‌اند.
تحقیقات نشان می‌دهندشرکت‌های تولید‌کننده نرم‌افزار که از ابزارهای آزمون برای کشف و رفع خطاها در نرم‌افزارهایشان استفاده کردند، به طور متوسط ۲۶% زمان کمتر از شرکت‌هایی صرف کردند که از روشهای دستی و سنتی استفاده می‌کنند. با توجه به اینکه توسعه نرم‌افزارها توسط انسانها انجام می‌شود، بروز اشتباهات و اِشکالات انسانی در هنگام تحلیل، طراحی و نوشتن برنامه‌های پیچیده، که سبب عملکرد نامناسب برنامه شده و باقی‌ماندن خطاهای نهان و آشکارشدن آنها در آینده، اجتناب‌ناپذیر است.
تحقیق ارایه شده زنگ خطر را این‌گونه به صدا در می‌آورد: در صورت عدم به‌کارگیری تکنیک‌های کارآمد آزمون نرم افزار، هزینه‌ها و خسارات حاصل از وجود خطاها و اِشکالات نرم‌افزاری در سالهای آینده به دلیل رشد نمایی صنعت نرم‌افزار، به مراتب بیش از ۳۱۲ میلیارد دلار خواهد بود. تحقیقات مؤسسه بلومبرگ نشان می‌دهد، بین سالهای۲۰۰۷ تا ۲۰۱۱ رشد صنعت نرم‌افزار در کشورهای آمریکا، انگلستان و چین به ترتیب ۳۴%، ۳۸% و ۶۳% بوده است. در همین بازه زمانی،یک افزایش جهانی قابل توجه در میزان دستمزد برنامه‌نویسان صورت گرفته است و همزمان، نیاز برای نرم‌افزارهای سفارشی و در نتیجه فشار بر شرکت‌های تولید‌کننده نرم‌افزار جهت استخدام برنامه‌نویسانِ بیشتر، درحال افزایش بوده است. طبق آمار منتشرشده در سال ۲۰۰۲ توسط مؤسسه ملي استاندارد و فناوري ايالات متحده، خطاهاي پنهان نرم‌افزار سالانه ۵/۵۹ ميليارد دلار هزينه براي آمريکا دربرداشته‌اند. جدیدترین آمار این مؤسسه نشان می‌دهد، هزینه خسارات خطاهای نرم‌افزاری معادل یک درصدِ تولید ناخالص ملی این کشور بوده است. این گزارش به مدیران، سیاستمداران و تصمیم‌سازان در کشورها در رابطه با افزایش سرسام‌آور هزینه‌های اشکال‌زدایی غیرخودکار هشدار می‌دهد و به آنها پیشنهاد می‌کند که با به‌کارگیری تکنیک‌های خودکارِ آزمون و اشکال‌زدایی نرم‌افزارها، به طور مؤثری بر بهبود اقتصاد جهانی تأثیر بگذارند. آمارهای ارایه شده، به وضوح اهمیت موضوع آزمون کارآمد نرم‌افزارها را آشکار می‌سازند.

ترمیم خودکار نرم افزار

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

اوراکل

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

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

  1. دامنه خروجی مورد انتظار را تولید کنیم
  2. مورد آزمون‌ها را اجرا کنیم
  3. نگاشت بین دامنه ورودی به خروجی مورد انتظار را پیدا کنیم
  4. خروجی مورد انتظار(خروجی نگاشت) با خروجی واقعی(خروجی نرم افزار تحت آزمون) مقایسه کنیم
  5. تصمیم گیر در مورد اینکه آیا خطا رخ داده است یا نه

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

  • زبانهای مشخصه سازی

در این روش‌ها رفتار سیستم نرم افزاری در قالب یک مدل ریاضی بیان می‌شود که از مفاهیم صوری برای بیان محدودیت‌های موجود در مدل استفاده می‌کنند

  • اظهارها (Assertion) و قراردادها (Contracts)

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

  • زبانهای مشخصه سازی جبری

در این روش‌ها ماژول‌های نرم افزار را به عنوان رابط در نظر می‌گیرند و پارامترهای تابع نمادهای عملیاتی است

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

سیستم را به عنوان مجموعه ای از وضعیت‌ها در نظر می‌گیرند و عملیات‌ها موجب تغییر وضعیت می‌شوند روش‌های مختلفی مانند Z, B, UML/OCL, VDM/VDM-SL, Alloy بر این اساس ارائه شده است. روش‌های مانند VDM,Z,B مجموعه ای از نامتغیرها (invariant)موجود در نرم افزار را استخراج می‌کنند؛ بطوریکه هر مورد آزمون که در اجرا بوسیله نرم افزار نتیجه اشباه بدهد نامتغیرهم آن را تشخیص می‌دهد. بنابراین نامتغیر یک اوراکل جزئی است. تکنیک‌های خوبی برای تشخیص نامتغیر بوسیله Ernst ارائه شده است که همه آنها در ابزاری به نام Daikon پیاده سازی شده‌اند.

تحلیل آزمون

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

طراحی آزمون

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

پیاده سازی آزمون

در این مرحله، موارد آزمون طراحی شده به اسکریپتهای آزمون تبدیل می شوند. به عبارت دیگر، آزمون خودکارسازی می شود. البته خودکارسازی آزمون به طور کامل نه امکان پذیر است و نه منطقی. تعیین اینکه تا چه حد خودکارسازی آزمون انجام شود، کاملا به تصمیم مدیر آزمون بر اساس شرایط پروژه وابسته است.

آزمون کارایی

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

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

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

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

آزمون امنیت

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

·       محرمانگی

·       جامعیت محتوا

·       قابلیت دسترس‌پذیری

·       احراز هویت و صلاحیت کاربران

·       انکارناپذیری عملکرد نرم‌افزار و کاربران

تعریف می‌شود.

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

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

اجرای آزمون

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

مشاوره و نظارت بر فرآیند آزمون

خدمات آزمایشگاه به صنعت در حوزه های مختلف تحلیل، طراحی، پیاده سازی و اجرای آزمون، مشاوره و نظارت بر فرآیند آزمون، تاسیس دپارتمان آزمون در شرکتها، موسسات و سازمانها، افزایش قابلیت آزمون پذیری نرم افزارها، آموزش زمینه های مختلف مرتبط با آزمون، توسعه، سفارشی سازی و ارائه ابزارهای مختلف آزمون، تولید محتوای مفید و ارزشمند برای استفاده در پروژه ها،برگزاری سخنرانی ها و نشستهای تخصصی در سازمانها، همایشها و … می باشد

فعالیتهای تحقیقاتی و اجرایی

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

مکانیابی خطا و ترمیم نرم افزار

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

روشهای فراابتکاری

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

آزمون اینترنت اشیا

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

انواع آزمون‌های انجام گرفته:

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

چالشهای آزمون:

  • هزینه‌ی سنگین آزمون
  • وابستگی شدید مؤلفه‌های گوناگون به هم
  • دشواری در استخراج  داده‌ی آزمون
  • عدم وجود امکانات مناسب برای انجام آزمون
  • پیچیدگی

آزمون سیستم‌های ارائه‌دهنده خدمات بانکی

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

انواع آزمون‌های انجام گرفته:

  • آزمون پایگاه داده
  • آزمون یکپارچگی
  • آزمون عملکرد
  • آزمون امنیت
  • آزمون قابلیت استفاده
  • آزمون پذیرش توسط کاربر

چالشهای آزمون:

  • دشواری دسترسی به داده‌های بانکی و استفاده از آن‌ها به عنوان داده‌ی آزمون
  • سختی انجام آزمون در هنگام انتقال از سیستم قدیمی به سیستم جدید
  • عدم مستندسازی دقیق نیازهای وظیفه‌مندی و غیر وظیفه‌مندی
  • توسعه‌ی حوزه‌ی آزمون در هنگام یکپارچگی با سیستم‌های دیگر
  • بررسی انطباق سیستم با سیاست‌ها و رویه‌های مشخص‌شده

سیستم‌های ارائه‌دهنده‌ی خدمات سلامت

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

انواع آزمون‌های انجام گرفته:

  • آزمون سیستمهای ارائهدهنده
  • آزمون سیستمهای واسطه
  • آزمون سیستمهای عضویت
  • آزمون سیستمهای درخواست
  • آزمون سیستمهای مالی
  • آزمون پیروی از قوانین
  • آزمون کارایی
  • آزمون عملکرد
  • آزمون پیروی
  • آزمون سکو
  • آزمون قابلیت همکاری

چالشهای آزمون:

  • فقدان دانش در حوزه سلامت و بیمه
  • تبعیت از استانداردهای تعریفشده برای سیستمهای ارائهدهندهی خدمات سلامت
  • یکپارچهسازی با سیستمها منبع
  • تحلیل ریسک و امنیت
  • انطباق با فرآیند
  • سازگاری با دستگاه‌های قابل حمل
  • امنیت و حریم شخصی

مشتریان

برخی مشتریان آزمایشگاه

سازمان فناوری اطلاعات ایران

مجری پروژه "ارائه چارچوب و ابزار ارزيابي کیفیت قبل از بهره‌برداري سامانه‌ هاي نرم‌ افزاري ملي و تدوین مدل مرجع ملی نرم‌افزار"، سال 1396 تا 1397

شرکت خدمات انفورماتیک

آزمون کارایی، بار، استرس، استقامت و مقیاس‌ پذیری سیستم بانکی ABIS، سال 1395 و 1396

شرکت بیمه دی

آزمون کارایی و امنیت سیستم جامع بیمه عمر، سال 1396 و 1397

سازمان امور مالیاتی کشور

مشارکت در ارزیابی کیفیت و آزمون‌ های کارکردی و غیرکارکردی (به ویژه کارایی، نگهداشت‌ پذیری، مدیریت‌ پذیری، مقیاس‌ پذیری، تعامل‌ پذیری، همروندی، دسترس‌ پذیری و مهاجرت داده) سیستم یکپارچه مالیاتی (ITS)، از سال 1390 تا 1395

نیروی انتظامی جمهوری اسلامی ایران

فاز اول ایجاد دپارتمان آزمون در معاونت فاوا، سال 1394

سازمان دامپزشکی کشور

بررسی بهبود کیفیت (به ویژه در حوزه های عملکردی و کارایی) سامانه‌های نرم‌ افزاری سازمان دامپزشکی، سال 1395 و 1396

سازمان هواشناسی کشور

مشارکت در ارزیابی کیفیت و آزمون کارکردی و غیرکارکردی (به ویژه کارایی ، بار، استرس و امنیت) سیستم‌های نرم‌ افزاری پروژه نوین‌ سازی سیستم‌ های اطلاعاتی، سال 1389

کارخانه شاهسوند

، ارزیابی کیفیت و آزمون کارکردی، کارایی، بار و امنیت سیستم ERP مورد استفاده در کارخانه شاهسوند و بیش از 10 شعبه آن در سطح کشور، سال 1388 تا 1391

شرکت راه آهن ایران

تولید و تدوین مستندات نیازمندی های نرم‌افزاری و طراحی معماری نرم افزاری حوزه رفاه و سلامت شرکت راه آهن، سال 1396 و 1397

وزارت آموزش و پرورش

مشارکت در مشاوره و نظارت بر سیستم جامع دانش آموزی، سال 1394 و 1395

سازمان دامپزشکی کشور

مشارکت در پروژه توسعه و تکمیل سامانه یکپارچه خدمات دارو و درمان، سال 1395 و 1396

سازمان دامپزشکی کشور

مشارکت در پروژه باز ساختاردهی سامانه الکترونیکی دارو و درمان و توسعه سامانه صدور مجوزهای سازمان دامپزشکی کشور، سال 1397

سازمان بنادر و دریانوردی

تدوین طرح نگهداشت و به روز رسانی برنامه کلان فناوری اطلاعات و ارتباطات، سال 1390 و 1391

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

طرح تدوین نظام جامع فناوری اطلاعات مدیریت شهری تهران (فاز اول)، سال 1394 و 1395

سازمان تامین اجتماعی

مشارکت در تدوین طرح کلان فناوری اطلاعات و ارتباطات، سال 1392 و 1393

شرکت ملی نفت ایران

مشارکت در مشاوره طرح ERP، سال 1392 و 1393

وزارت ارتباطات و فناوري اطلاعات

تدوين استانداردهاي توليد‏، ارزيابي‏، انتخاب و پياده‌سازي ERP در جمهوري اسلامي ایران، سال 1388

مرکز مطالعات و برنامه ریزی شهر تهران

طراحي مدل آموزش شهروندي به منظور بهره برداري از خدمات الكترونيكي شهرداري تهران، سال 1395

مرکز مطالعات و برنامه ریزی شهر تهران

ارائه مدل اتصال شهرداری تهران به شبکه ملی اطلاعات کشور، سال 1396

بنیاد ملی نخبگان

ارائه یک معماری مناسب برای نرم افزارهای برنامه ریزی منابع سازمانی، سال 1389

شرکت ماشین آلات هپکو

آزمون کارکردی و غیرکارکردی نرم‌افزارهای جامع و یکپارچه توسعه‌یافته برای سازمان‌های مختلف از جمله شرکت مهندسی مواد و ماشین آلات هپکو از سال ۱۳۸۰ تا ۱۳۸۷

رویدادها

سمینار ها و دیگر رویدادهای مربوط به آزمایشگاه آزمون و تایید نرم افزار

بلاگ و اخبار

مطالب و اخبار اخیر

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

۱۴,مرداد,۱۳۹۷

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

مشاهده‌ی مطلب

آزمون امنیت؛ زیرساخت یا نرم‌افزار؟

۳۱,تیر,۱۳۹۶

معمولاً برای صاحبان/تولیدکنندگان نرم‌افزارها آن‌چه مهم است بالا بردن قابلیت‌ها و کارکردهای محصول است. در نتیجه در هنگام تولید محصول نرم‌افزاری تمرکز بر روی قابلیت‌هاست نه امنیت آن. امنیت در بهترین حالت در انتهای مسیر در نظر گرفته می‌شود. در بسیاری از موارد حتی همین اتفاق نیز نمی‌افتد و امنیت محصول نرم‌افزاری به برقراری امنیت در زیرساخت شبکه فرو کاسته می‌شود.

بعداً همین نرم‌افزارها پشت دیوار زخیمی از تجهیزات امنیتی شبکه، از جمله دیوارهای آتش، سامانه‌های تشخیص و جلوگیری از نفوذ و ... قرار می‌گیرند. اما پشت این دیوار به حال خود رها می‌شوند تا 24 ساعته در 7 روز هفته، از راه شبکه‌ی داخلی یا اینترنت، سرگرم کاری باشند که برای آن طراحی شده‌اند. مشکل چنین رویکردی، که معمول هم هست، این است که در خصوص فعل و انفعالات نرم‌افزارها از منظر شبکه، امنیت و زیرساخت فناوری اطلاعات سازمان، همیشه سوالات و ابهام‌هایی وجود دارد. بخش زیرساخت معمولاً از هسته‌ی مرکزی نرم‌افزارها بی‌اطلاع است و کسی از آن‌ها نمی‌خواهد تا در بهر نرم‌افزار غور کنند. در نتیجه وجود ابهام از طرف آن‌ها قابل درک است. اما دیر یا زود زمانی فرا می‎رسد که این افراد باید کاپوت را بالا بزنند و اگر رفتار مشکل‌زایی در نرم‌افزار وجود دارد، گزارش دهند. پر واضح است که در این موقع، تیم زیرساخت در موضع ضعف قرار می‎گیرد.

بگذارید یک نمونه از مشکلات رویکرد بالا را مختصراً توضیح دهم. اغلب نرم‌افزارهای تجاری یک مکانیزم لاگ‌گذاری دارند که در هنگام تبادل داده و انجام تراکنش‌ها، مشخصات تبادل را از آن طریق ثبت می‎کنند. اکثر اوقات این تنها قابلیت امنیتی‌ای است که برای آن‌ها تعبیه شده است. در بسیاری از موارد، وضع از این هم بدتر است و نرم‌افزار لاگ‌گذاری نمی‌کند بلکه وب سرور متناظرش این کار را انجام می‌دهد. وب ‌سرورها جزو منابعی هستند که معمولاً توسط چندین و چند نرم‌افزار مورد استفاده قرار می‌گیرند.در نتیجه سر در آوردن از لاگ‌ آن‌ها گاو نر می‌خواهد و مرد کهن! تجربه‌ -از جمله‌ی تجربه‌ی شخصی این‌جانب- نشان می‌دهد تیم‌های پشتیبانی و زیرساخت آن قدر مشغولیت دارند که بررسی لاگ‌ها، که بخش عمده‌ای‌شان تکراری و معمول است، جزء اولویت‌هایشان نیست. در نتیجه در هنگام مبادا، مشکل فقط رویداد نفوذ یا لو رفتن اطلاعات نیست. بلکه مشکل آن است که منابع داخلی درگیر با نرم‌افزار نیز از واقعه خبردار نیستند. در چنین وضعیت‌هایی معمولاً برخوردها واکنشی و دیر است و بعد از مرگ سهراب.

این سناریو یک نمونه‌ی ساده است که نشان می‌دهد برقراری امنیت شبکه ،حتی در بهترین حالت، کفایت نمی‌کند. لو رفتن اطلاعات کاربری چند ده میلیون از کاربران PS4 به دلیل نبود یا نقص تجهیزات امنیت شبکه و یا پیکربندی نامناسب آن‌ها اتفاق نیفتاد. در واقع برقراری امنیت در لبه‌ی شبکه از منظر حفاظت از منابع نرم‌افزاری این مجموعه، کار زیادی نمی‌تواند انجام دهد. با این حال بسیاری از سازمان‌ها و مراکز فاوا خوشباورانه به استقرار تجهیزات امنیتی، دیوارهای آتش سخت‌افزاری و سامانه‌های تشخیص و جلوگیری از نفوذ اکتفا می‌کنند و بر این باورند که همه‌چیز تحت کنترل است. اما واقعیت آن است که بسیاری از حملات، اقدامات خرابکارانه و رخنه‌ها به نرم‌افزارهای تحت وب در حالی اتفاق می‌افتند که مدیران، مهندسان و تکنسین‌های شبکه و زیرساخت با خوشحالی به جریان‌های خرابکار می‌نگرند و فکر می‌کنند هوا چقدر خوب است!

آن بخشی از امنیت را که ناظر به عملکرد خود نرم‌افزار است، باید از درون برقرار کرد و آزمود. من به راحتی می‌توانم زیر ساخت امنیتی شبکه‌ی خود را در بوته‌ی آزمایش قرار دهم تا ببینم در برابر حملات DoS و DDoS چقدر مقاوم است. اما با آزمون این زیرساخت هیچ‌گاه نمی‌توانم متوجه شوم که آیا نرم‌افزار مورد استفاده‌ام در برابر انواع Injectionها مقاوم است یا خیر. این دو مقوله هرچند مکمل، اما کاملاً جدا از یکدیگرند.

مشاهده‌ی مطلب

تجربیات در یکی از پروژه های آزمایشگ...

۲۲,دی,۱۳۹۵

نبود تست رگرسیون یکپارچه و درست ماژوله بندی نشدن سیستم

یکی از ماژول­های سیستم به خوبی تست شد و عملکرد تعریف شده برای آن به درستی انجام می­شد. بعد از مدتی، خطایی از نوع "نگه­داری" ثبت شد، مبنی بر این موضوع که این کارکرد، برای موارد خاصی به درستی انجام نمی­شود. این در صورتی است که قبلا این کارکرد به درستی انجام می­شد­. بعد از تحقیق فراوان متوجه شدند که تغییری در یکی از ماژول­های دیگر سیستم، باعث این خطا شده است.

 

بازگشت خطاهای قبلی-درست بسته­بندی نکردن نرم­افزار

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

 

نبود یک تعریف مناسب و درست برای تست رگرسیون

در پروژه مرحله­ای از تست به نام تست رگرسیون وجود داشت؛ اوایل به نظر می­رسید هدف و ماهیت تست رگرسیون باید همان معنای قابل قبول را داشته باشد ولی بعدها در جلسات تست رگرسیون این نتیجه به دست آمد که تست رگرسیون از نقطه نظر توسعه دهنده معنی مخصوص به خود را در پروژه دارد و هدف اصلی آن، نوعی تست دورهمی است تا فقط انجام درست فرایندهای اصلی ماژول بررسی و تست شود.

 

تست ماژول به علت نبود سیستم یکپارچه به درستی انجام نشده است

خیلی از فعالیت­های اصلی ماژول به بهانه نبود سیستم یکپارچه تست نشده است، درصورتی که می­شد با ایجاد Stubهایی این کار را انجام داد. انجام ندادن تست کامل ماژول، باعث مشکلات فراوانی در تست یکپارچگی شده است.

 

عدم ایجاد محیط تست مشابه با محیط واقعی

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

 

خطاهای غیرقابل بازتولید

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

تعداد زیادی خطا که نیازمندی جدید نامیده می­شود

در مواردی، خروجی نرم­افزار مطابق خواسته و نیاز کاربر نهایی نرم­افزار نبود ولی متاسفانه اسنادی که به طور غیرکامل و متناقض آماده شده بود، نیز تأییدی بر این موضوع نبود. بعد از تلاش فراون و صحبت با تحلیل­گر و خبره ماژول، نیازمندی که عدم تامین آن در حد Critical بود، به علت اینکه در اسناد، نقیض آن وجود داشت، به عنوان نیازمندی جدید در نظر گرفته می شد.

 

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

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

 

عدم اجرای تست توسط شرکت توسعه­دهنده

خطاهایی به عنوان خطای "فیکس شده"  گزارش شده است، ولی با تست مجدد توسط تیم تست کننده این خطا مجدد بروز می­کرد. بعدها متوجه شده­ایم که اصلاً مورد آزمون مربوطه توسط تیم توسعه دهنده انجام نشده است.

 

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

تست نرم­افزار شامل 1- مواردی است که به طور عادی انجام می­شود و همچنین 2-مواردی که ممکن است غیرعادی باشد و شامل فرایند طبیعی سیستم نمی­شود. این در حالی بود که توجیه کردن تیم توسعه­دهنده در مورد خطا­هایی که توسط فرایند عادی به وجود نیامده است، بسیار کار سختی بود و زیر بار مسئولیت این خطا­ها نمی­رفتند.

 

 

 

مشاهده‌ی مطلب
مشاهده‌ی تمام بلاگ‌ها

اعضا

اعضای آزمایشگاه آزمون و تایید نرم افزار

آموزشی

مطالب آموزشی در حوزه‌ی آزمون و تایید نرم افزار

ابزار pluralsight- Test First Devel...

۳۰,آبان,۱۳۹۵

در این دوره  از محصولات pluralsight  سبک توسعه‌ی test-first برای ساخت نرم‌افرارهای بهتر آموزش داده می‌شود. در این دوره از ارزش آزمون واحد و گردش کار red-green-refactor در طراحی و پیاده سازی نیازمندی‌های کسب وکار پرداخته شده است. ابزارهایی مانند NUnit و JetBrains Resharper برای نوشتن آزمون‌های واحد بهتر به کار گرفته شده است.

مشاهده‌ی مطلب
مشاهده‌ی تمام مطالب

منابع

لینک‌های مفید

مقالات

From Object-Z Specification to Groovy Implementation

Farzin Zaker, Hassan Haghighi and Eslam Nazemi
So far, valuable researches have been conducted on mapping object-oriented specification notations, such as Object-Z, to different object-oriented programming languages, such as C++. However, the results of selecting JVM-based programming languages for mapping have not covered most of basic Object-Z structures. In this paper, the Groovy language, a...

مشاهده ی مطلب

Structural test data generation using a memetic ant colony o...

Hossein Sharifipour , Mojtaba Shakeri, Hassan Haghighi
Test data generation is one of the key activities that has a significant impact on the efficiency and effectiveness of software testing. Since manual test data generation is quite inefficient and even impractical, automated test data generation has been realized to produce an appropriate subset of input data to carry out effective software testing...

مشاهده ی مطلب
مشاهده‌ی تمام مطالب

Empirical Evaluation of Existing Algorithms of Spectrum bas...

Jeongho Kim, Eunseok Lee
Fault localization is an essential step for debugging, even though it is still tedious and time-consuming activity. Many researchers tried to find a good way for it for decades. Many solutions proposed by them have different performance, such as correctness, code coverage, and etc. However there are few attempts to compare those solutions in an obj...

مشاهده ی مطلب

Test data regeneration: generating new test data from exist...

S. Yoo and M. Harman
Existing automated test data generation techniques tend to start from scratch, implicitly assuming that no pre-existing test data are available. However, this assumption may not always hold, and where it does not, there may be a missed opportunity; perhaps the pre-existing test cases could be used to assist the automated generation of additional te...

مشاهده ی مطلب
مشاهده‌ی تمام مطالب

گالری

گالری عکس‌های آزمایشگاه

مشاهده تمام آلبوم ها

تماس با ما

راه‌های ارتباطی آزمایشگاه