تاریخ انتشار نسخه اصلی 26 دسامبر, 2016 همین اول پست بگم که شخصاً میانه ای با استفاده از اصطلاحات و تعاریفی که میخواهم راجع به آنها بنویسم ندارم. هرچند نامگذاری بر روی روشهای مختلف تست نرم افزار، برای مستند سازی و استفاده از آن در ارتباطات ضروریست ولی تمرکز و بکاربردن مدام آنها در ارتباط با افرادی که دانستن یا ندانستن این اصطلاحات تاثیری در کار روزمره شان ندارد، امری غیرضروری و حتی گمراه کننده است. مثلا اینکه به یک برنامه نویس بگویید که من میخواهم برنامه تو را به صورت gray-box تست سیستمی کنم یا به یک مدیر نرم افزار بگویید exploratory test فلان قسمت برنامه با موفقیت انجام شد، در واقع اطلاعاتی اضافی ایست که کمکی به او نمیکند. ولی در هر صورت دانستن این تعاریف برای کسی که تست نرم افزار انجام میدهد مفید بوده و مانند زمینه های دیگر، به فرد دید بازتری نسبت به کارههای روزانه اش میدهد. در ادامه به تعدادی از این تعاریف و اصطلاحات -البته براساس تجربه شخصی و نه نوشته های ویکیپدیایی – اشاره میکنم.
برای شناخت بهتر تستهای نرم افزاری میتوان آنها را به گروه هایی دسته بندی کرد. به طوری که موارد ذکر شده در هر گروه میتواند برخلاف همگروهی خود، با گروه دیگر همپوشانی داشته باشند.
انواع تست از لحاظ دسترسی به کد نرم افزار:
تست White-box: زمانی است که تست کننده دسترسی به کد نرم افزار دارد.
تست Black-box: زمانی که تست کننده دسترسی به کد نرم افزار نداشته و معماری آن برایش اهمیتی نداشته باشد. در واقع میزان دسترسی او همانند یک کاربر معمولی از طریق interface های کاربری است.
تست Gray-box: این مورد برای خود من بییشتر پیش میآید، زمانی است که تست کننده دسترسی به کد ندارد اما از طریق interface غیرکاربری (مانند interface مخصوص debug و عیب یابی) سیستم را تست میکند. مثلا اگر برنامه ای براساس REST API است با دانستن route ها میتوان از طریق افزونه هایی در Chrome مانند Postman آن را تست کرد.
انواع تست از لحاظ سطح انتزاع معماری سیستم:
روش Unit Testing یا تست واحد که ناظر بر تست یک واحد نرم افزاری مانند یک متد یا یک کلاس است.
روش Integration Testing یا تست یکپارچگی که به معنای تست ارتباط میان واحدهای نرم افزاری از طریق رابط نرمافزاری یا Interface است.
روش System Testing که بعد از آن معلوم میشود که آیا Function مورد نظر که در ابتدای از تیم نرم افزاری درخواست شده بود به صورت end to end کار میکند یا خیر.
این تست ها در درون تیم نرم افزاری شامل برنامه نویس و تست کننده فنی نوشته و انجام میشود و بازخوردهای آن نیز در درون تیم تحلیل میشود. در این مراحل نه مشتری و نه مدیر نرم افزار هیچکدام نقشی ندارند.
تست هایی که میتوان آنها را در ارتباط با مشتری و چرخه انتشار نرم افزار تعریف کرد:
روش Acceptance Testing: این تست بررسی میکند که آیا Feature درخواستی از سمت مشتری مطابق با نیازمندی اوست یا خیر. این تست توسط خود مشتری یا فردی در ارتباط با او انجام میشود. توجه داشته باشید که در System Test الزاماً feature تست نمیشود بلکه function بررسی میشود. چیزی که ممکن است الزاماً در ارتباط مستقیم با مشتری نباشد. در واقع این دو با هم تفاوت ماهوی دارند و در یک گروه قرار نمیگیرند.
روش Smoke Testing: تستی است سطحی که قبل از انتشار یک نسخه یا patch انجام میشود. البته این به معنای نبودن test case یا فی البداهه بودن نیست. در واقع تیم تست از قبل تست هایی را برای اطمینان از عدم پیشامد مشکلاتی مانند crash کردن یا کار نکردن سناریوهای ابتدایی آماده کرده است و آنها را قبل از انتشار نرم افزار یا patch به صورت اتوماتیک یا دستی انجام میدهد.
روش Exploratory Testing: این روش زمانی مطرح میشود که تیم نرم افزاری فرصتی برای نوشتن test plan، در آوردن سناریوها و یا اتوماتیک کردن ندارد و میخواهد افراد شرکت انفرادی یا دو به دو بنشینند و هر کدام برروی قسمتی از نرم افزار کار کنند. به این صورت که به انتخاب خود سناریوهایی که فکر میکنند کاربر آنها را انجام میدهد، انجام داده و یافته های خود را مستند کنند. این روش به صورت کاملا دستی انجام میشود. البته نیازی نیست این تست الزاماً قبل از انتشار نرم افزار انجام شود. در بعضی از شرکت ها این روش در غالب Mob testing به منظور آشنایی بیشتر کارکنان با نرم افزار و پیدا کردن bug های احتمالی انجام میشود.
دسته بندی از لحاظ یکپارچی و پایداری سیستم:
روش Regression Testing: خود این واژه به معنای بازگشت به حالت قبلی است. در تست این حالت قبلی وضعیتی است که نرم افزار به درستی عمل میکرده و وضعیت پایداری داشته است. در واقع زمانی که bug ی در سیستم رفع میشود، تست کننده باید اطمینان حاصل کند که نرم افزار به وضعیت پایدار قبل از بروز bug برگشته است یا خیر.
روش Non-regression Testing: تستی است که بعد از اضافه شدن feature ی جدید برای اطمینان از اینکه عملکرد موفق آن انجام میشود. در واقع برخلاف regression سیستم دیگر نباید در وضعیت قبلی باشد.
و در نهایت تقسیم بندی در رابطه با نیازمندیهای عملکردی و غیر عملکردی سیستم مانند تست امنیت، تست کاربری، تست استرس، تست تطبیقی با استاندارد یا پروتکلی خاص و غیره.
همانطور که گفته شد یک تست میتواند ترکیبی از گروهای بالا باشد. مثلا یک تست امنیتی که به صورت دستی و در سطح سیستم به صورت gray-box انجام میگیرد. یا اینکه یک تست Acceptance همیشه در سطح سیستم و به صورت black-box انجام میشود.
