ارزیابی کیفیت نرم افزار و تضمین کیفیت سیستم های نرم افزاری

تفاوت کنترل کیفیت و تضمین کیفیت

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

مفهوم تست نرم افزار يا ارزیابی کیفیت نرم افزار

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

دلایل اهمیت تست نرم افزار

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

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

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

کیفیت نرم‌افزار

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

کیفیت نرم‌افزار مطابق با نیازهای عملیاتی و استاندارد‌های توسعه نرم‌افزار تعریف و تدوین می‌گردد و در این میان، توجه به سه اصل زیر اهمیت دارد:

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

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

این سطوح عبارت اند از:

1. تست واحد (Unit testing)؛
2. تست یکپارچه سازی (Integration testing)؛
3. تست سیستم (System testing)؛
4. تست پذیرش (Acceptance testing):

• – تست آلفا (Alpha test)؛
• – تست بتا (beta test):
• تست گاما (Gamma test):

1- تست واحد (Unit testing)

در این نوع تست، قسمت های کوچک برنامه را تست می کنیم؛ مثلاً توابع یا کلاس ها در زبان های object oriented. در این تست، با کل برنامه کاری نداریم و هدف ما، اطمینان از کارکرد قسمت های کوچک برنامه است. تست واحد، در سطح کد است و یک ابزار مناسب برای آن JUnit است. این ابزار، تست خودکار انجام می دهد.

تست واحد یا micro level، پایین ترین سطح تست است. هر کد تست واحد، یک قطعه کد یا یک تابع (متد) خاص را تست می کند. این تست، نیاز به دانش در مورد طراحی و شیوه عملکرد داخلی تابع یا قطعه کد دارد. این نوع تست، توسط برنامه نویس انجام می شود؛ نه تست کننده.

2-تست یکپارچه سازی (Integration testing)

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

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

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

3-تست سیستم (System testing)

در این نوع تست، تمام سیستم تست می شود و حتی خود نرم افزار، سخت افزار و ارتباطات بین کامپوننت ها مورد توجه قرار می گیرد. خود تست سیستم، شامل: تست گرافیک رابط کاربری(GUI test)، Smoke test ، تست هایی از قبیل تست کارایی(Performance test) و تست نصب( Installation test) می باشد و همه تست های سیستمی، توسط کارشناسان نور در بخش بررسی نرم افزار مرکز انجام می شود.

این تست به منظور بررسی عملکرد نرم افزار روی پلتفرم های مختلف و نرم افزارهای پلتفرم OS انجام می شود. سخت افزار و نرم افزار، یعنی موارد کاربردی مورد نیاز، به منظور اطمینان از این امر است که برنامه با مؤلفه های دیگر محیط اجرایش به خوبی کار می کند و نیز جهت اطمینان از اینکه نرم افزار ارائه شده در محیط مورد نظر قابل استفاده است. نمونه مشکل حاصل از انجام ندادن تست سیستم نرم افزار، بازی شیر شاه دیزنی (Disney’s Lion King Game) در پاییز سال ۱۹۹۴ است. شرکت دیزنی اوّلین CD بازی خود تحت عنوان شیر شاه Lion King را که بر اساس کارتونی به همین نام ساخته شده بود، وارد بازار کرد. بسیاری از شرکت های دیگر تا آن زمان اقدام به ساخت بازی های رایانه ای کرده بودند؛ اما این اوّلین بار بود که شرکت دیزنی وارد این تجارت شده بود. دیزنی برای فروش این بازی، دست به تبلیغات گسترده ای زد و در نتیجه، این محصول با فروش بسیار بالایی مواجه شد؛ اما اتفاقات پس از آن، تبدیل به کابوسی برای این شرکت شد. در ۲۶ دسامبر، روز پس از کریسمس، تلفن های بخش پشتیبانی مشتریان شرکت دیزنی شروع کرد به زنگ زدن، زنگ زدن و زنگ زدن! متصدیان پاسخگویی به تماس ها با خیل عظیمی از والدین عصبانی با بچه های گریان مواجه شدند که ادعا می کرند نرم افزار مزبور کار نمی کند. این خبر به سرعت در مطبوعات و تلویزیون نیز پخش شد و کریسمس آن سال را برای بسیاری از پرسنل دیزنی تلخ کرد. علت چه بود؟ پس از بررسی مشخص شد که دیزنی نرم افزار خود را روی بسیاری از مدل های PC تست نکرده بود و در نتیجه، تنها روی سیستم هایی کار می کرد که برنامه نویسان دیزنی روی آن سیستم ها نرم افزار خود را توسعه داده بودند و نه دستگاه های متداولی که عموم مردم از آن استفاده می کردند.

4-تست پذیرش (Acceptance testing)

تست پذیرش به منظور بررسی اینکه نرم افزار نیازهای مشتری را برآورده می کند، انجام می شود و بعد از تست سیستم انجام می شود. این نوع تست، شامل موارد ذیل است:

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

 

• تست گاما (Gamma test):

مدل‌های ارزیابی کیفیت نرم‌افزار

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

مدل McCall

این مدل در سال 7-1976م توسط نیروی هوایی آمریکا، جنرال الکتریک و مرکز توسعه هوایی روم با هدف بهبود کیفیت محصولات نرم‌افزاری ارائه شد. در ایالات متحده آمریکا از این مدل برای پروژه‌‌های با مقیاس بزرگ نظامی و فضایی استفاده شده است. سطح اول مدل McCall شامل 11 ویژگی کیفی: صحت، قابلیت اطمینان، کارایی، قابلیت استفاده، قابلیت نگهداری، آزمایش‌پذیری، انعطاف‌پذیری، انتقال‌پذیری، قابلیت استفاده مجدد و قابلیت همکاری است. در سطح دوم مدل نیز، 23 معیار کیفی ارائه شده است که ارتباط چند به چند با ویژگی‌های اصلی سطح اول دارد. ایده اصلی مدل، تعیین ارتباط بین عوامل کیفی و معیار‌‌های ارزیابی محصول است. هرچند انتقادهایی به این مدل وارد است، ولی مزیت عمده این مدل، ارتباط بین ویژگی‌های کیفی و معیار‌‌ها است.

مدل Boehm

این مدل در سال 1978م برخی ویژگی‌ها را با تأکید بر قابلیت نگهداری نرم‌افزار به مدل McCall اضافه کرد. همچنین این مدل، ملاحظاتی در خصوص ارزیابی نرم‌افزار با توجه به نوع کاربرد آن و ویژگی‌هایی مرتبط با سخت‌افزار اضافه کرد. عیب اصلی این مدل، عدم ارائه راهکاری به منظور ارزیابی و اندازه‌گیری ویژگی‌های کیفی است.

مدل FURPS

این مدل که توسط دو شرکت HP و Robert Grady در سال 1987م ارائه شده، شامل دو گروه متفاوت از نیازمندی‌‌های نرم‌افزار است:

• – نیازمندی‌های عملیاتی که با ورودی و خروجی مورد نیاز تعریف می‌شود.(F)
  – نیازمندی‌های غیرعملیاتی که شامل چهار ویژگی: قابلیت استفاده، قابلیت اطمینان، کارایی و قابلیت پشتیبانی است. (URPS)

عیب این مدل، عدم وجود معیاری برای سنجش میزان انتقال‌پذیری نرم‌افزار است.

مدل Dromey

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

1. انتخاب مجموعه‌ای از صفات سطح بالا که برای ارزیابی لازم است؛
2. تهیه فهرستی از اجزای سیستم؛
3. تشخیص ویژگی‌های دارای کیفیت برای هر جزء سیستم (کیفیت‌هایی از اجزای مرحله قبل که بیشترین تأثیر را در ویژگی‌های محصول نهایی دارند)؛
4. تصمیم راجع به این‌که هر ویژگی چگونه بر صفات کیفیت تأثیر می‌گذارد؛
5. ارزیابی مدل.

مدل ISO/IEC-9126

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

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

رویکردهای ارزیابی یا (Test) از جزء به کل

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

1.static test:

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

2. dynamic test:

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

3. white-box test:

دانستن شیوه کار داخلی برنامه، امکان تأیید چگونگی عمل هر تکه کد و مسیر اجرا مراحل اولیه ارزیابی.  در این تست، کارکرد ساختارهای داخلی برنامه بررسی می شود و اینکه منطقاً به کد احتیاج هست تا مثلاً متدهای مختلف بررسی شوند. فنونی که در این نوع تست استفاده می شود، به این شرح است:

• – تست API: در تست جعبه سفید، هر API را به صورت جدا گانه تست می کنیم.
• – بررسی سطر به سطر کد(Code coverage): یعنی بررسی خطوط کد، به صورت خط به خط و جزءبه جزء؛ به صورتی که خطوط کد و مسیرهای مستقل داخل یک پیمانه حداقل یک بار اجرا و تست شوند.
• – متدهای Fault injection: طی این متد، یک کد خطا در کد تزریق می کنیم تا خطایی رخ دهد و بتوانیم موردی را تست کنیم.
• – متدهای mutaion test: برای تست نرم افزار، خودمان یک خطا را در کد ایجاد می نماییم.

4. Black-box test:

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

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

5. تست جعبه خاکستری (grey-box.): در این نوع تست، در مورد ساختار داخلی نرم افزار و الگوریتم آن اطلاعاتی داریم و از آن برای طراحی تست استفاده می کنیم؛ درحالی که در تست هایی که طراحی می کنیم، هیچ دسترسی به ساختار داخلی نرم افزار نداریم و مانند یک جعبه سیاه به آن می نگریم.

5. Gray-box test:

 

منیع تصویر

https://www.educba.com/software-development/software-development-tutorials/software-testing-tutorial/

مولفه های اصلی در تست نرم افزار در حوزه ارزیابی کیفیت نرم افزار

انواع تست نرم افزار در حوزه ارزیابی کیفیت نرم افزار

– تست نصب: 

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

– تست سازگاری:

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

– تست smoke و sanity:

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

– تست smoke:

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

– تست رگرسیون:

تست فوق، روی یافتن باگ بعد از یک تغییر اساسی در کد پروژه تمرکز دارد؛ به عنوان مثال، وقتی یک فیچر به پروژه اضافه می گردد، با این تست، باگ های احتمالی را مشاهده می کنیم. جایی که یک کد عمده یا یک کتابخانه به پروژه افزوده می شود، معمولاً باگ های زیادی مشاهده می شود. شاید به دلیل conflict با کد قبلی یا هر دلیل دیگری، در این قسمت باید این تست مربوطه را انجام داد. معمولاً قدم اوّل تست regression، این است که تست کیس های پیشین را دوباره تکرار کنیم و ببینیم که این تغییر کد، موجب ظهور باگ های قبلی نشده باشد. عمق تست، به ریسک فیچر اضافه شده بستگی دارد. این نوع تست، در شرکت های تجاری بیشتر مورد توجه قرار می گیرد.

– تست پذیرش:

این نوع تست، می تواند دو مفهوم داشته باشد؛ اوّلی همان تست smoke که مطمئن می شویم اگر برنامه با حداقل منابع کار می کند. بنابراین، احتمالاً در بیشتر شرایط نیز کار می کند. دومین مفهوم، مربوط به سمت مشتری می شود که مثلاً آنها هم یک آزمایشگاه داشته باشند و روی سخت افزار خودشان برنامه را تست کنند که به این تست، user acceptance test یا UAT نیز گفته می شود. این نوع تست، می تواند در بین فازهای پروژه هم معنا پیدا کند؛ به این شکل که در صورت موفقیت در این تست، برنامه به فاز بعدی می رود.

– تست آلفا:

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

– تست بتا:

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

– تست Functional و Non-functional:

تست functional برای ما کارکرد (function) خاصی را تست می کند. در واقع، سناریوهای پیاده سازی شده را تست می نماید؛ مثلاً برنامه قرار است بتواند یک عکس را نمایش بدهد. این تست، مسئله مزبور را بررسی می کند که آیا برنامه می تواند عکس نمایش دهد یا خیر؟ در مقابل، تست Non-functional مربوط به آن قسمت برنامه است که به کاربر ارتباط مستقیم ندارد؛ مثل کارایی سیستم یا قابلیت گسترش برنامه، رفتار برنامه در یک شرایط خاص و یا امنیت برنامه. این نوع تست، نقطه شکست برنامه را می یابد. تست Non-functional در واقع، کیفیت برنامه را آزمایش می کند.

– تست مخرب:

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

– تست کاربری:

این تست، بررسی می کند که آیا کارکردن با رابط کاربری برنامه راحت است، یا نه.

– تست امنیت:

در واقع، تست متدهای مختلف امنیت در برنامه است و تستی مهم به شمار می رود؛ به خصوص در برنامه هایی که حریم خصوصی افراد در آن تعریف می شود و باید با نفوذ هکرها مقابله کرد.

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

– تست A/B:

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

– تست Concurrent: 

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

– تست conformance یا typing:

این نوع تست، بررسی می کند که برنامه بر اساس استانداردهای تعریف شده کار می کند یا نه؛ مثلاً در تست کامپایلرها، این تست بدین هدف انجام می شود که بدانیم آیا کامپایلر مورد نظر بر اساس استانداردهای لازم آن زبان خاص، درست کار می کند؟

– تست ad-hoc testing:

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

تست کارکردی یا تست عملکردی (نرم افزارهای تحت وب، دسکتاپ، موبایل و نهفته) (Functional test/ Acceptance test)

برخی ابزارهای تست در ارزیابی کیفیت نرم افزار

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

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

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

– Appium: نرم افزار تست خودکار

– Calabash: نرم افزار تست خودکار.

– xamarin test cloud: با این شرکت، می توان یک تست خودکار روی تعداد بسیاری گوشی به طور هم زمان انجام داد.

– Testdriod: تست خودکار نرم افزار موبایل روی گوشی های واقعی اندروید و iOS.

– prefecto mobile: تست خودکار و functional برنامه. استفاده از مدل continuous quality این نرم افزار، commercial است.

– SOASTA touch test: تست خودکار نرم افزار موبایل، به صورت functional.

– Testin: این نرم افزار، این قابلیت را فراهم می سازد که نرم افزارهای خود را روی بیشتر از 300 گوشی تست کنیم. حالت cload آن، امکانات بیشتری مانند automated compatibility و performance testing دارد.

– Ubertesters: این برنامه کمک می کند که روند توسعه نرم افزار بر اساس پروسه QA، سازمان یافته تر باشد.

– crashlytics: این برنامه، یک نرم افزار آزاد برای iOS و اندروید است.

– Ranorex: این برنامه، یک نرم افزار تست موبایل است که به وسیله آن یک تست را رکورد می کنیم و می توانیم آن را روی deviceهای بسیاری اجرا نماییم.

– Experitest: نرم افزار تست خودکار و تست functional. با این نرم افزار می توان یک تست رکورد کرد و آن را به دفعات زیاد روی یک دیوایس اجرا نمود. می توان با زبان های python و C# یک تست را نوشت و روی گوشی های مختلف اجرا کرد.

– Android Lint: یک ابزار است که به eclipse اضافه می شود و کدهای پروژه را به منظور یافتن اِشکال چک می کند و همچنین، از نظر امنتتی و کارایی، عملکرد نرم افزار را بهبود می بخشد.

– FindBugs: یک نرم افزار تست کد استاتیک است که می توان از آن برای اصلاح برنامه های جاوا استفاده کرد.

– Maveryx: یک نرم افزار تست برای تست functional، تست خودکار و تست GUI در نرم افزارهای اندروید است.

– clang static analyzer: یک ابزار اپن سورس برای iPhone است که تست static انجام می دهد و نرم افزار را آنالیز می نماید.

– Analyze code for Xcode: یک افزونه برای Xcode است که در زمان compile، کد را آنالیز کرده، اِشکال ها و باگ ها را گزارش می دهد.

– Monkeytalk: یک نرم افزار آزاد است که تست خودکار و functional را با روش های بسیاری مثل smoke test انجام می دهد.

– Caliper: یک نرم افزار اپن سورسِ ساخته شده توسط گوگل است که نتایج javamicrobenchmarks را روی اپلیکیشن ما نشان می دهد. این روش، در واقع، یک تست کارایی با benchmarkهای موجود است.

– EMMA: این برنامه، یک ابزار مناسب برای اندازه گیری code coverage مربوط به یک برنامه جاواست.

– Robotium: یک فریم ورک تست خودکار است که بدون نیاز به دانش زیاد در مورد اپلیکیشنِ مورد تست، می توان آن را آزمایش کرد. نوع تست آن، balck-box است؛ یعنی نیازی به این نیست که کد برنامه را در اختیار داشته باشیم.

– Robolectric: یک فریم ورک unit test است که کلاس ها را دنبال می کند و قابلیت این را دارد که بدنه متدها را دوباره بنویسد؛ به گونه ای که به صورت default مقادیر را به Null یا 0 برگرداند.

– Monkeyrunner: به IDE اضافه می شود و به ما اجازه می دهد که تست functional بگیریم. این نوع تست، به سورس کد برنامه احتیاجی ندارد و بر روی دیوایس و emulator اجرا می شود و در نتیجه، می توان با python برنامه نوشت.

– Apthwack: یک API آزاد برای تست نرم افزار است که به کمک آن، برنامه را آپلود کرده، تست می کنیم که اشکال ها را به ما می گوید. این متد، روی تعداد بسیاری دیوایس فرایند تست را انجام می دهد و مصرف منابع را به ما گزارش می دهد.

– HP: یک راه حل تست شرکت hp با قابلیت های تست موبایل، مانیتورینگ نرم افزار موبایل، امنیت نرم افزار موبایل و شبیه سازی شبکه با کارایی بالاست.

– mobilelabs: یک راه حل جامع برای تست نرم افزار موبایل در کلود (فضای ابری) است.

مراجع ارزیابی کیفیت نرم افزار:

• https://www.educba.com/grey-box-testing/
• http://www.rahavardnoor.ir/index.php/authors/item/830-teste-narmafzar
• http://www.rahavardnoor.ir/index.php/authors/item/76-arzyabi
• http://www.rahavardnoor.ir/index.php/authors/item/811-barrasi-kayfiyate-narmafzar-va-systemhaye-modiriyate-an

حسنی، فرنود. «چالش های مدیریتی تولید نرم افزار درایران»، نشریه کتاب ماه کلیات، مهر و آبان 84، ش 94 و 95.
کاظمی، علی. «تأثیر رهبری معنوی اسلامی بر عملکرد سازمانی مورد مطالعه شرکت گاز استان لرستان»، نشریه مدیریت اسلامی، بهار و تابستان 92، ش 5.
پارسا، سعید. مهندسی نرم افزار. انتشارات علم و صنعت، اسفند 1391ش.
پایگاه اینترنتی ویکی پدیا. (دسترسی در: بهار 1395). نشانی: www.wikipedia.org

 

مدیریت سرور، پشتیبانی و کانفیگ سرور – آفاق هاستینگ