تست نویسی چیست؟

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

با توجه به استاندارد ANSI/IEEE 1059، تست را می توان اینگونه تعریف کرد - فرآیندی برای تجزیه و تحلیل یک آیتم برنامه برای تشخیص تفاوت بین شرایط موجود و مورد نیاز (یعنی نقص / خطا / اشکال) و ارزیابی ویژگی های آیتم برنامه.

چه کسی تست می‌نویسد؟

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

• تست کننده برنامه
• توسعه دهنده برنامه
• سرپرست/مدیر پروژه
• کاربر نهایی

شرکت‌های مختلف برای افرادی که برنامه را بر اساس تجربه و دانش خود تست می‌کنند، عناوین مختلفی دارند، مانند تست کننده برنامه، مهندس تضمین کیفیت برنامه، تحلیلگر QA و غیره.

امکان تست برنامه در هیچ زمانی در طول چرخه آن وجود ندارد. دو بخش بعدی بیان می کند که چه زمانی آزمایش باید شروع شود و چه زمانی باید آن را در طول SDLC پایان داد.

اگر دنبال ورود به بازار کار هستید حتما آموزش های ویدیویی عملی را دنبال کنید : آموزش لاراول

چه زمانی تست نویسی را شروع کنیم؟

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

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

آزمایش به اشکال مختلف در هر مرحله از SDLC انجام می شود:

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

• بررسی طرح در مرحله طراحی با هدف بهبود طراحی نیز به عنوان آزمایش محسوب می شود.

• آزمایش انجام شده توسط یک توسعه دهنده پس از تکمیل کد نیز به عنوان آزمایش دسته بندی می شود.

چه زمانی تست را متوقف کنیم؟

تعیین زمان توقف آزمایش دشوار است، زیرا آزمایش یک فرآیند بی پایان است و هیچ کس نمی‌تواند ادعا کند که یک برنامه 100٪ تست شده است. جنبه های زیر باید برای توقف فرآیند آزمایش در نظر گرفته شود:

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

توقف تست نویسی با تایید و اعتبارسنجی

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

تفاوت های بین تایید و اعتبارسنجی

سطر	تایید	اعتبار سنجی
۱	تایید این سوال را می‌پرسد: "آیا آن را درست می‌سازی؟"	اعتبارسنجی این نگرانی را برطرف می کند: "آیا چیز درستی می سازی؟"
۲	اطمینان حاصل می کند که سیستم برنامه تمام عملکردها را برآورده می کند.	اطمینان حاصل می کند که عملکردها با رفتار مورد نظر مطابقت دارند.
۳	تأیید ابتدا انجام می شود و شامل بررسی اسناد، کد و غیره می شود.	اعتبار سنجی پس از تأیید صورت می گیرد و عمدتاً شامل بررسی کل محصول است.
۴	توسط توسعه دهندگان انجام می‌شود.	توسط آزمایش کنندگان انجام می‌شود.
۵	فعالیت‌های ثابتی دارد، زیرا شامل جمع‌آوری بررسی‌ها و بازرسی‌ها برای تأیید یک برنامه است.	این دارای فعالیت های پویا است، زیرا شامل اجرای برنامه بر اساس نیازها می شود.
۶	این یک فرآیند عینی است و برای تأیید یک برنامه نیازی به تصمیم ذهنی نیست.	این یک فرآیند ذهنی است و شامل تصمیمات ذهنی در مورد چگونگی عملکرد یک برنامه است.

تست برنامه یا نرم افزار - افسانه ها

در زیر برخی از رایج‌ترین افسانه‌ها در مورد تست برنامه آورده شده است.

تست نویسی خیلی گران است

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

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

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

فقط محصولات کاملاً توسعه یافته تست می شوند

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

تست کامل امکان پذیر است

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

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

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

نقص‌های ایجاد شده به دلیل کم کاری تست کنندگان است

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

تست کنندگان مسئول کیفیت محصول هستند

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

Test Automation باید تا جایی که امکان دارد برای کاهش زمان استفاده شود

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

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

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

تنها وظیفه یک تست کننده یافتن اشکال است

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

اگر دنبال ورود به بازار کار هستید حتما آموزش های ویدیویی عملی را دنبال کنید : آموزش انگولار

تست برنامه – (تضمین کیفیت) QA، (کنترل کیفیت) QC و تست

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

نکاتی را که QA، QC و Testing را متمایز می کند

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

تست نویسی به روش حسابرسی و بازرسی

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

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

جلسات بازرسی رسمی ممکن است شامل فرآیندهای زیر باشد:

• برنامه ریزی
• آماده سازی کلی
• جلسه بازرسی
• دوباره کاری
• پیگیری

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

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

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

تست برنامه - استانداردهای ISO

بسیاری از سازمان ها در سراسر جهان استانداردهای مختلفی را برای بهبود نیازهای کیفی برنامه خود توسعه و پیاده سازی می‌کنند.

ISO/IEC 9126 - این استاندارد با جنبه‌های زیر برای تعیین کیفیت یک برنامه برنامه سروکار دارد:

• مدل با کیفیت
• معیارهای خارجی
• معیارهای داخلی
• استفاده معیارهای با کیفیت

این استاندارد مجموعه ای از ویژگی های کیفیت را برای هر برنامهی ارائه می دهد، مانند :

• عملکرد
• قابلیت اطمینان
• قابلیت استفاده
• بهره وری
• قابلیت نگهداری
• قابل حمل بودن

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

ISO/IEC 9241-11 - قسمت 11 این استاندارد به میزان استفاده از یک محصول توسط کاربران مشخص برای دستیابی به اهداف مشخص با اثربخشی، کارایی و رضایت در زمینه استفاده مشخص می پردازد.

این استاندارد چارچوبی را پیشنهاد کرد که اجزای قابلیت استفاده و رابطه بین آنها را توصیف می کند. در این استاندارد قابلیت استفاده از نظر عملکرد و رضایت کاربر در نظر گرفته شده است. بر اساس ISO 9241-11، قابلیت استفاده به زمینه استفاده بستگی دارد و سطح قابلیت استفاده با تغییر زمینه تغییر خواهد کرد.
ISO/IEC 25000:2005 - ISO/IEC 25000:2005 معمولاً به عنوان استانداردی شناخته می شود که دستورالعمل هایی را برای الزامات و ارزیابی کیفیت برنامه (SQuaRE) ارائه می دهد. این استاندارد به سازماندهی و ارتقای فرآیند مربوط به الزامات کیفیت برنامه و ارزیابی آن‌ها کمک می‌کند. در واقع، ISO-25000 جایگزین دو استاندارد قدیمی ISO، یعنی ISO-9126 و ISO-14598 می شود.

SQuaRE به بخش های فرعی تقسیم می شود مانند :

• ISO 2500n - بخش مدیریت کیفیت
• ISO 2501n - بخش مدل کیفیت
• ISO 2502n - بخش اندازه گیری کیفیت
• ISO 2503n - بخش الزامات کیفیت
• ISO 2504n - بخش ارزیابی کیفیت

محتویات اصلی SQuaRE عبارتند از :

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

ISO/IEC 12119 - این استاندارد با بسته‌های برنامهی تحویل داده شده به مشتری سروکار دارد. این فرآیند با تولید مشتری متمرکز سر و کار ندارد. مطالب اصلی مربوط به موارد زیر است :

• مجموعه ای از الزامات برای بسته‌های برنامهی
• دستورالعمل برای آزمایش بسته برنامهی تحویل داده شده در برابر الزامات مشخص شده

برخی از استانداردهای دیگر مربوط به فرآیندهای QA و تست در جدول زیر ذکر شده است :

استانداردهای مربوط به فرآیندهای QA و تست

ردیف	استانداردها و توضیحات
۱	IEEE 829 استانداردی برای فرمت اسناد مورد استفاده در مراحل مختلف تست برنامه.
۲	IEEE 1061 روشی برای ایجاد الزامات کیفیت، شناسایی، پیاده سازی، تجزیه و تحلیل و اعتبارسنجی فرآیند و محصول معیارهای کیفیت برنامه
۳	IEEE 1059 راهنمای برنامه‌های تأیید و اعتبار سنجی برنامه.
۴	IEEE 1008 استانداردی برای تست واحد(Unit Test)
۵	IEEE 1012 استانداردی برای تأیید و اعتبارسنجی برنامه
۶	IEEE 1028 استانداردی برای بازرسی برنامه
۷	IEEE 1044 استانداردی برای طبقه بندی ناهنجاری‌های برنامهی
۸	IEEE 1044-1 راهنمای طبقه بندی ناهنجاری‌های برنامهی
۹	IEEE 830 راهنمای توسعه مشخصات مورد نیاز سیستم
۱۰	IEEE 730 استانداردی برای برنامه های تضمین کیفیت برنامه
۱۱	IEEE 1061 استانداردی برای معیارها و روش شناسی کیفیت برنامه
۱۲	IEEE 12207 استانداردی برای فرآیندهای چرخه عمر برنامه و داده های چرخه عمر
۱۳	BS 7925-1 واژگانی از اصطلاحات مورد استفاده در تست برنامه
۱۴	BS 7925-2 استانداردی برای تست اجزای برنامه

انواع تست

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

تست دستی

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

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

تست خودکار

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

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

چه چیزی را خودکار کنیم؟ امکان خودکارسازی همه چیز در یک برنامه وجود ندارد. مناطقی که کاربر می تواند در آن تراکنش انجام دهد مانند فرم ورود یا فرم های ثبت نام، هر منطقه ای که تعداد زیادی از کاربران می توانند به طور همزمان به برنامه دسترسی داشته باشند باید خودکار شوند. (آموزش کار با فرم ها (form) در html)

چه زمانی باید خودکار شود؟ تست خودکار باید با در نظر گرفتن جنبه های زیر از یک برنامه استفاده شود :

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

چگونه خودکار کنیم؟ خودکار شدن با استفاده از یک زبان کامپیوتری مانند برنامه نویسی VB و یک برنامه خودکار انجام می شود. ابزارهای زیادی وجود دارد که می توان از آنها برای نوشتن اسکریپت های خودکار سازی استفاده کرد. قبل از ذکر ابزارها، اجازه دهید فرآیندی را که می‌توان برای خودکارسازی فرآیند تست استفاده کرد، شناسایی کنیم :

• شناسایی مناطق درون یک برنامه برای خودکار کردن
• انتخاب ابزار مناسب برای خودکار کردن تست
• نوشتن اسکریپت تست
• توسعه تست
• اجرای اسکریپت‌ها
• ایجاد گزارش نتایج
• شناسایی هر گونه اشکال بالقوه یا مشکلات عملکرد

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

• HP Quick Test Professional
• Selenium
• IBM Rational Functional Tester
• SilkTest
• TestComplete
• Testing Anywhere
• WinRunner
• LoadRunner
• Visual Studio Test Professional
• Watir

اگر دنبال ورود به بازار کار هستید حتما آموزش های ویدیویی عملی را دنبال کنید :شی گرایی php

روش های تست برنامه

روش‌های مختلفی برای تست برنامه وجود دارد. این قسمت به طور خلاصه روش های موجود را شرح می‌دهد.

تست جعبه سیاه

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

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

مزایا و معایب تست جعبه سیاه

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

تست جعبه سفید

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

تست‌کننده باید به داخل کد منبع نگاهی بیندازد و بفهمد کدام واحد/تکه کد به خوبی رفتار می‌کند.

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

مزایا و معایب تست جعبه سفید

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

تست جعبه خاکستری

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

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

مزایا و معایب تست جعبه خاکستری

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

مقایسه روش های تست و تست نویسی

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

مقایسه روش‌های تست

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

تست سطوح

در طول فرآیند آزمایش سطوح مختلفی وجود دارد. در این بخش توضیحات مختصری در مورد این سطوح ارائه شده است.

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

• تست عملکردی (Functional Testing)
• تست غیر عملکردی (Non-functional Testing)

تست عملکردی (Functional Testing)

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

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

پنج مرحله در هنگام آزمایش عملکرد یک برنامه کاربردی

گام	توضیحات
۱	تعیین عملکردی که برنامه مورد نظر قرار است انجام دهد.
۲	ایجاد داده های آزمایشی بر اساس مشخصات برنامه.
۳	خروجی بر اساس داده های تست و مشخصات برنامه.
۴	نگارش سناریوهای آزمایشی و اجرای موارد آزمایشی.
۵	مقایسه نتایج واقعی و مورد انتظار بر اساس موارد آزمایشی اجرا شده.

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

تست واحد (Unit Testing)

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

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

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

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

تست یکپارچه سازی (Integration Testing)

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

• تست ادغام از پایین به بالا
• تست ادغام از بالا به پایین

روش‌های تست یکپارچه سازی

ردیف	روش‌های تست یکپارچه سازی
۱	ادغام از پایین به بالا این آزمایش با تست واحد آغاز می شود و سپس با آزمایش ترکیبات سطح بالاتر واحدها به نام ماژول ها یا بیلدها دنبال می شود.
۲	ادغام از بالا به پایین در این تست ابتدا ماژول های بالاترین سطح و سپس به تدریج ماژول‌های سطح پایین تست می‌شوند.

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

تست سیستم (System Testing)

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

تست سیستم به دلایل زیر مهم است :

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

تست رگرسیون (Regression Testing)

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

تست رگرسیون به دلایل زیر مهم است :

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

آزمون پذیرش (Acceptance Testing)

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

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

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

تست آلفا (Alpha Testing)

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

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

تست بتا (Beta Testing)

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

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

تست غیر عملکردی (Non-Functional Testing)

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

برخی از انواع مهم و متداول تست غیرعملکردی در زیر مورد بحث قرار گرفته است.

تست عملکرد (Performance Testing)

بیشتر برای شناسایی هر گونه تنگنا یا مشکلات عملکرد به جای یافتن اشکالات در یک برنامه استفاده می شود. دلایل مختلفی وجود دارد که به کاهش عملکرد یک برنامه کمک می کند :

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

تست عملکرد از نظر جنبه های زیر یکی از انواع تست های مهم و اجباری محسوب می شود :

• سرعت (یعنی زمان پاسخ، رندر داده‌ها و دسترسی)
• ظرفیت
• ثبات
• مقیاس پذیری

تست عملکرد می تواند کیفی یا کمی باشد و می تواند به زیر انواع مختلفی مانند تست بار (Load testing) و تست استرس (Stress testing) تقسیم شود.

تست بار (Load testing)

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

بیشتر اوقات تست بار با کمک ابزارهای خودکار مانند Load Runner، AppLoader، IBM Rational Performance Tester، Apache JMeter، Silk Performer، Visual Studio Load Test و غیره انجام می‌شود.

کاربران مجازی (VUsers) در ابزار تست خودکار تعریف شده و اسکریپت برای تایید تست بارگذاری برنامه اجرا می‌شود. تعداد کاربران را می توان به طور همزمان یا افزایشی بر اساس نیاز افزایش یا کاهش داد.

تست استرس (Stress testing)

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

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

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

تست قابلیت استفاده (Usability Testing)

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

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

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

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

علاوه بر تعاریف مختلف کاربردپذیری، استانداردها و مدل‌ها و روش‌های کیفیتی وجود دارد که قابلیت استفاده را در قالب ویژگی‌ها و زیرمجموعه‌هایی مانند ISO-9126، ISO-9241-11، ISO-13407، و IEEE std تعریف می‌کنند. 610.12 و غیره.

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

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

تست امنیت (Security Testing)

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

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

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

تست قابلیت حمل (Portability Testing)

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

• انتقال یک برنامه نصب شده از یک کامپیوتر به کامپیوتر دیگر.
• ساخت فایل اجرایی (.exe) برای اجرای برنامه بر روی پلتفرم های مختلف.

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

• برنامه باید با در نظر گرفتن الزامات قابل حمل طراحی و کدگذاری شود.
• تست واحد بر روی اجزای مرتبط انجام شده است.
• تست یکپارچه سازی انجام شده است.

محیط تست ایجاد شده است.

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

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

روش های رایج مستندنویسی در تست

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

• Test Plan
• Test Scenario
• Test Case
• Traceability Matrix

Test Plan

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

یک test plan شامل موارد زیر است :

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

Test Scenario

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

اصطلاحات « test scenario» و « test cases» به جای یکدیگر استفاده می‌شوند، اما یک test scenario چندین مرحله دارد، در حالی که یک test cases دارای یک مرحله واحد است. از این منظر، test scenario ، موارد آزمایشی هستند، اما شامل چندین مورد آزمایشی و ترتیبی هستند که باید اجرا شوند. جدای از این، هر تست به خروجی تست قبلی بستگی دارد.

Test Case

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

علاوه بر این، test case برای پیگیری پوشش تست یک برنامه نوشته شده است. به طور کلی، هیچ الگوی رسمی وجود ندارد که بتوان از آن در نوشتن test case استفاده کرد. با این حال، مؤلفه‌های زیر همیشه در دسترس هستند و در هر test case گنجانده می‌شوند :

• Test case ID
• ماژول محصول
• نسخه محصول
• تاریخچه ویرایشها
• هدف
• مفروضات
• پیش شرط‌ها
• مراحل
• خروجی مورد نظر
• نتیجه واقعی
• Post-conditions

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

Traceability Matrix

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

هر الزام در سند RTM با مورد آزمایشی مرتبط با آن مرتبط است تا آزمایش بر اساس الزامات ذکر شده انجام شود. علاوه بر این، شناسه اشکال نیز گنجانده شده است و با الزامات مرتبط و test case مرتبط است. اهداف اصلی RTM عبارتند از :

• اطمینان حاصل کردن از این که برنامه مطابق با الزامات ذکر شده توسعه یافته است.
• به یافتن علت اصلی هر اشکال کمک می‌کند.
• به ردیابی اسناد توسعه یافته در مراحل مختلف SDLC کمک می‌کند.

تکنیک‌های تخمین در تست نویسی

برآورد تلاش های مورد نیاز برای تست یکی از وظایف اصلی و مهم در SDLC است. تخمین صحیح به تست برنامه به حداکثر پوشش کمک می‌کند. در این بخش برخی از تکنیک‌هایی که می‌توانند در تخمین تلاش‌های مورد نیاز برای آزمایش مفید باشند، توضیح می‌دهد.

تجزیه و تحلیل نقطه عملکردی - این روش بر اساس تجزیه و تحلیل نیازهای کاربر کاربردی برنامه با دسته بندی های زیر است :

• خروجی ها
• سوالات
• ورودی ها
• فایل های داخلی
• فایل های خارجی

تجزیه و تحلیل نقطه تست - این فرآیند تخمین برای تجزیه و تحلیل نقطه تابع برای تست جعبه سیاه یا پذیرش استفاده می شود. عناصر اصلی این روش عبارتند از :

• اندازه
• بهره وری
• استراتژی
• رابط
• پیچیدگی
• یکنواختی

روش Mark-II - این یک روش تخمینی است که برای تجزیه و تحلیل و اندازه گیری تخمین بر اساس دیدگاه عملکردی کاربر نهایی استفاده می شود. روال روش Mark-II به شرح زیر است :

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

می‌توانید از سایر تکنیک‌های برآورد محبوب استفاده کنید مانند :

• تکنیک دلفی
• تخمین مبتنی بر قیاس
• تخمین بر اساس شمارش test case
• برآورد بر اساس وظیفه (فعالیت).
• روش IFPUG

نوشتن اولین تست واحد (Unit Test) در زبان‌های مختلف

در اینجا نحوه راه اندازی یک محیط تست پایه برای Unit Tests برای زبان های برنامه نویسی معروف را توضیح خواهیم داد.

تست نویسی با NodeJs/JavaScript

امروزه جاوا اسکریپت پرکاربردترین زبان برنامه نویسی است. به لطف اکوسیستم node js و سادگی آن، چارچوب ها/ابزارهای زیادی داریم.

برای ایجاد یک راه اندازی تست کامل، می توانید از generatorهایی مانند Yeoman استفاده کنید. برخی از فریمورک‌های دیگر مانند React، Angular، تنظیمات محیط آزمایشی را با کد تولید شده ارائه می‌کنند. برای React، بیشترین استفاده از مولد create-react-app است. شما کل تنظیمات را به صورت پیش فرض دریافت می کنید.

با این حال، برای تنظیم اولیه، می توانید مراحل زیر را دنبال کنید.

پيش نياز اجرای تست :

• Nodejs
• npm/npx

مراحل :

۱ - ساختار پوشه را ایجاد کنید

۲ - util.js را ایجاد کنید و تابع را در دایرکتوری src اضافه کنید

۳ - یک فایل test در پوشه تست ایجاد کنید ) نام باید حاوی test.js باشد (

۴ - بسته npm را راه اندازی کنید و فریمورک تست jest را نصب کنید

$ mkdir src test//util.js
exports.add = (a, b) => a+b$ npm init --y 
## install jest testing framework 
$ npm i --save-dev jest 

تست های پایه را اضافه کنید و دوباره اجرا کنید :

//util.test.jsconst {add} = require("../")describe("Util.js", () => {    it("should able to add", () =>{ 
  expect(add(1,1)).toBe(2)    
 })    
it("should fail to add", () =>{        
  expect(add(1,1)).toBe(3)    
 })
})

Test case را اجرا کنید:

$ npx jest

تست نویسی با Java

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

پيش نياز اجرای تست :

• جاوا
• Gradle (نسخه ۵.۵.۱ و بالاتر)

مراحل :

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

پس از اجرای gradle init، به ترتیب گزینه ها را انتخاب کنید:

3. library -> 3. java -> 1. Groovy -> 1 Junit 4 <-| Enter <-| Enter

## Create lib using gradle$ md java_code$ gradle init##  --> 3: library 
    --> 3: Java 
    --> 1: Groovy
    --> 1: JUnit 4
    --> enter <-|
    --> enter <-|

تست را اجرا کنید:

## run test case
$ ./gradlew test

تست نویسی با Python

من از پایتون به عنوان یک زبان برنامه نویسی استفاده کرده‌ام. در حین تنظیم، تنظیم تست برای یک عملکرد ساده برای من بسیار دشوار بود. تا به حال، هنوز، من فریمورک مناسبی برای تنظیم پیدا نکرده‌ام. اما من موفق شدم چند مورد تست اساسی را اجرا کنم.

پيش نياز برای اجرای تست :

• پایتون (3.6 و بالاتر)
• Pip (۱۹.۳.۱ و بالاتر)

مراحل :

۱ - یک پوشه ایجاد کنید و کد منبع را اضافه کنید. util.py و test_util.py را اضافه کنید

$ md project && md project/src && cd $_$ vi util.py// util.py
def add(a, b):
    return a+b$ vi test_util.py// test_util.py
import util 
def test_answer():
    assert util.add(1,1) == 2
def test_answerFail():    
    assert util.add(1,1) == 3

۲ - ماژول pytest را با استفاده از pip نصب کنید

$ pip install -U pytest

۳ – test case را اجرا کنید

$ pytest -q src/test_util.py

تست نویسی با Rust

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

پيش نيازها برای اجرای تست:

• Rust
• Cargo

مراحل :

۱ - ایجاد lib با استفاده از Cargo

۲ - کد تست را در همان فایل بنویسید

۳ – test case را اجرا کنید

## Create lib using cargo
$ cargo new rust_lang --lib// src/lib.rs
mod util {   
  pub fn add(a:i32, b:i32) -> i32 {       
     a+b    
  }
}// test code in same file#[cfg(test)]mod tests {
 use super::*;    
 #[test]
 fn it_works() {
   assert_eq!(util::add(1,1), 2);    
 }    
 #[test] 
 fn it_will_works() {
    assert_eq!(util::add(1,1), 3);
 }
}

اجرای test case :

$ cargo test -- --nocapture

تست نویسی با Go lang

Go یکی از پرکاربردترین زبانهای برنامه نویسی است. تنظیم یک محیط تست در گولنگ بسیار دشوار است. حتی تنظیم GOPATH پیچیده است. اما انجام آن غیر ممکن نیست. در اینجا مراحل زیر وجود دارد که می توانید دنبال کنید.

مراحل :

۱ - ایجاد پوشه util/ و test/

۲ – مسیر پوشه را برای رفتن به مسیر ماژول کپی کنید

۳ – test case را اجرا کنید

## Create folder util/ and test/// util/lib.gopackage util 
/// Test function Add
func Add(a int, b int) int { 
  return a + b
}//test/lib_test.go
package test 
import ( 
"testing"  
util "github.com/xdeepakv/go_lang/util"
) 
func TestAddPass(t *testing.T) { 
 got := util.Add(1, 1) 
 if got != 2 {  
   t.Errorf("Add not working properly") 
  }
}
func TestAddFail(t *testing.T) { 
 got := util.Add(1, 2) 
 if got != 2 {  
   t.Errorf("Add not working properly") 
 }
}

تلاش اول :

cd go_lang
go test -v ./test/

مسیر Go را علامت بزنید، پوشه را به ماژول go path کپی کنید

## Check go path$ echo $GOPATH## Default would be ~/go
## Copy folder to go path module$ cp -R ../go_lang $GOPATH/src/github.com/xdeepakv
$ cd $GOPATH/src/github.com/xdeepakv/go_lang

تلاش دوم :

test case را اجرا کنید.

$ go test -v ./test/

تست نویسی با Swift

ایجاد یک کتابخانه swift با مدیریت بسته swift آسان است. با این حال، نوشتن یک test case چالش برانگیز است. برای ایجاد یک تست می توانید مراحل زیر را دنبال کنید:

پيش نيازها برای اجرای تست:

• سوئیفت ۵.۱ به بالا

مراحل :

۱ - lib را با استفاده از بسته swift ایجاد کنید

۲ - Tests/utilTests/utilTests.swift

## Create lib using swift package$ md util && swift package init --type library
// util/util.swift
public class Util {
public class func add(_ a: Int, _ b: Int) -> Int {
    return a+b
  }
}// Tests/utilTests/utilTests.swift
func testExample() {
 XCTAssertEqual(Util.add(1,2), 2)
}

test case را اجرا کنید.

$ swift test

مراحل تست نویسی برای سایر زبان‌ها به زودی در همین مقاله به روز خواهد شد.

امروزه استفاده از نتایج اینترنتی و حضور در این نتایج یک از عوامل پیشرفت کسب و کارها است برای همین سئو یکی از کانال های مفید برای این مورد است: انجام سئو سایت