
استاندارد طرح آزمون نرمافزار
https://itcn.ir/wp-content/uploads/2016/05/software-test.jpg 1200 630 مشاور فناوری اطلاعات - IT consultant مشاور فناوری اطلاعات - IT consultant https://itcn.ir/wp-content/uploads/2016/05/software-test.jpg۱- مقدمه
این سند، استاندارد طرح آزمون نرمافزار از مجموعه گزارشهای خروجی پروژه نظاممهندسی و استانداردهای تولید و توسعه نرمافزار (نماتن) – فاز ۲ را در بردارد. آزمون نرمافزار یکی از حساسترین و مهمترین فعالیتهایی است که در جریان پروژههای نرمافزاری باید اجرا شود. صحت و دقت فعالیتهای آزمون نرمافزار مستقیماً در کیفیت نتایج اینگونه پروژهها مؤثر است، ازاینرو برنامهریزی و اجرای صحیح آزمون نرمافزار میتواند نقش تعیینکنندهای در موفقیت یا شکست پروژههای نرمافزاری ایفا کند. مجریان و مدیران پروژههای نرمافزاری با بهرهگیری از این استاندارد میتوانند کیفیت برنامهریزی و نتایج فعالیتهای آزمون نرمافزار را در پروژههای خود ارتقا بخشند.
۱-۱- هدف
این سند بهمنظور تعیین سرفصلها و محتوای طرح آزمون نرمافزار در پروژههای نرمافزاری تهیه شده است و در آن حداقل مطالب لازم برای تهیه و ارائه اینگونه طرحها تشریح شده است. هدف از تهیه این استاندارد، یکسانسازی طرحهای آزمون نرمافزار در پروژههای نرمافزاری و فراهم آوردن امکان ممیزی و کنترل کیفیت اینگونه طرحهاست.
۲-۱- دامنه کاربرد
استاندارد ارائه شده در این سند، مطالب لازم برای تهیه و ارائه طرح آزمون نرمافزار در پروژههای نرمافزاری را در بر میگیرد. در مورد پروژههای نرمافزاری که قالب ارائه شده در این استاندارد برای تهیه طرح آزمون نرمافزار در آنها استفاده میشود، هیچگونه محدودیتی ازنظر حجم پروژه، نوع نرمافزارهای تولیدشده در جریان پروژه، متدولوژی و مدل فرآیند انتخاب شده و ابزار به کار گرفته شده برای تولید نرمافزار وجود ندارد.
قالب ارائهشده در این استاندارد برای تهیه طرح آزمون نرمافزار، در همه سطوح آزمون (اعم از آزمون واحد[۱]، آزمون یکپارچگی[۲]، آزمون سیستم[۳]، آزمون پذیرش[۴] و)… قابلاستفاده است.
۳-۱- تعاریف
در نگارش این طرح، از اصطلاحات زیر استفاده شده است:
۱-۳-۱- پروژه: منظور از پروژه در این سند، هر پروژه نرمافزاری است که از قالب ارائه شده در این استاندارد، برای تهیه طرح آزمون در آن استفاده میشود.
۲-۳-۱- پروژه نرمافزاری: پروژهای است که موضوع آن انجام همه یا بخشی از فعالیتهای زیست چرخ توسعه نرمافزار[۵] باشد.
۳-۳-۱- زیرپروژه[۶]: بخشی از یک پروژه که با توجه به دامنه، اهداف، نتایج و یا منابع موردنیاز، بتوان آن را بهصورت یک پروژه مستقل در نظر گرفت.
۴-۳-۱- نرمافزار هدف: منظور نرمافزار یا جزء نرمافزاری است که طرح آزمون برای آن تهیه میشود.
۵-۳-۱- کارفرما: شخص حقیقی یا حقوقی است که پروژه به درخواست و سفارش او اجرا میشود.
۶-۳-۱- کارگزار[۷]: شخص حقیقی یا حقوقی است که نسبت به اجرای پروژه متعهد گردیده است.
۷-۳-۱- کارگزار فرعی[۸]: شخص حقیقی یا حقوقی است که انجام بخشی از پروژه از سوی کارگزار به او واگذار شده است.
۸-۳-۱- کاربر: هر یک از افراد واجد صلاحیتی که پس از تهیه نرمافزار، از آن استفاده خواهند نمود.
۹-۳-۱- ناظر: منظور از ناظر، شخص حقیقی یا حقوقی است که از سوی کارفرما بهمنظور نظارت بر حسن اجرای پروژه تعیینشده است. ناظر ممکن است شخص حقیقی یا حقوقی مستقل از سازمان کارفرما، یکی از واحدهای تابعه سازمان کارفرما و یا یک یا چند نفر از کارکنان کارفرما باشد که عهدهدار انجام وظایف نظارتی میگردند.
۱۰-۳-۱- تضمین کیفیت: به مجموعه اقدامات برنامهریزیشده و سامانمندی گفته میشود که برای حصول اطمینان از تطابق ویژگیهای همه یا بخشی از فرآوردهها با مشخصات و نیازهای اعلامشده باید انجام شود[۹].
۱۱-۳-۱ تصدیق[۱۰]: فرآیندی است که برای اطمینان از تطابق ویژگیهای فرآورده (های) یک فعالیت در چرخه توسعه نرمافزار، با نیازهای اعلامشده همان مرحله انجام میشود[۱۱].
۱۲-۳-۱ صحهگذاری[۱۲]: فرآیند ارزیابی یک محصول نرمافزاری که با هدف اطمینان از تطابق ویژگیهای آن با نیازهای کاربر انجام میشود[۱۳].
۱۳-۳-۱ آزمون[۱۴]: فرآیند بررسی یا اجرای یک نرمافزار یا جزء نرمافزاری بهصورت دستی یا خودکار، بهمنظور ارزیابی تطابق ویژگیهای آن با نیازهای مشخصشده از قبل و یا بهمنظور مقایسه بین نتایج موردانتظار و نتایج واقعی. آزمون اساساً پس از هر واحد پیادهسازی قابلاعمال است و موضوع آن برنامههای نوشتهشده و قابلاجرا میباشد. بسته به سطح تکامل برنامههای موضوع آزمون، سطوح مختلفی از آزمون قابلاجرا است.
۱۴-۳-۱ آزمون واحد[۱۵]: نوعی آزمون است که در سطح واحدهای پایهای سیستم (زیر برنامهها، توابع، روالهای پایگاه دادهای و برنامههای نیم ساخته) انجام میشود.
۱۵-۳-۱ آزمون یکپارچگی[۱۶]: پس از ترکیب و یکپارچهسازی اجزا و عناصر نرمافزاری با یکدیگر و تولید برنامههای اجرایی، آزمون یکپارچگی با هدف اطمینان از صحت کارکرد واحدهای نرمافزاری در ترکیب با یکدیگر اجرا میشود. موضوع آزمون یکپارچگی، برنامههای اجرایی یکپارچه و قابل اجرا است.
۱۶-۳-۱ آزمون سیستم[۱۷]: سطحی از آزمون است که در آنهمه عناصر یک سیستم با همدیگر بهعنوان یک کل مورد آزمایش قرار میگیرند. این اجزا عبارتاند از برنامههای اجرایی، پایگاه دادهها، مستندات کاربر، نیروی انسانی و تجهیزات سختافزاری. هدف از آزمون سیستم اطمینان از این نکته است که همه بخشهای سیستم بهدرستی با یکدیگر تبادل داده و عملیات انجام میدهند و در گردش اطلاعات هیچ رخنه[۱۸] پیشبینینشدهای موجود نیست. بهویژه ارتباط سیستم با روالهای دستی (غیرمکانیزه) باید آزمون شود. رویکرد اصلی در آزمون سیستم، طراحی و اجرای سناریوهای آزمون است.
۱۷-۳-۱- آزمون پذیرش[۱۹]: آزمون پذیرش که آزمون پذیرش کاربر هم نامیده میشود، پس از تحویل نسخه اجرایی نرمافزار در محل استفاده عملیاتی و توسط کاربران نهایی (معمولاً با برنامهریزی و هدایت مشترک تیم مجری پروژه) اجرا میشود. هدف از این آزمون اطمینان از این نکته است که سیستم در شرایط عملیاتی معمولی و با اطلاعات واقعی قادر به برآورده کردن نیازهای کاربران میباشد.
۱۸-۳-۱- طرح آزمون: سندی که دامنه، روش، برنامه اجرایی و ضوابط آزمون را از پیش مشخص میسازد.
۱۹-۳-۱- دادههای آزمون[۲۰]: مجموعهای از دادهها که برای آزمون یک نرمافزار یا جزء نرمافزاری تولید میشوند.
۲۰-۳-۱- رویه آزمون[۲۱]: مجموعهای از دستورالعملهای اجرایی برای آمادهسازی، اجرا و ارزیابی نتایج یک آزمون.
۲۱-۳-۱- مورد آزمون[۲۲]: مجموعهای از دادههای آزمون و رویههای آزمون مرتبط با آنها که برای آزمون مورد خاصی از ویژگیها یا عملکرد نرمافزار طراحی و تولید میشوند.
۲۲-۳-۱- آزمون کارکردی[۲۳]: منظور از این آزمون، اطمینان از تطابق تواناییهای نرمافزار آمادهشده با مشخصات کارکردی آن است که در مشخصات نیازمندیها یا اسناد طراحی نرمافزار تشریح شده است. بهمنظور گذر از مرحله آزمون کارکردی، سیستم باید قادر به انجام سناریوهای طراحیشده بر مبنای کارکردهای پیشبینیشده باشد.
۲۳-۳-۱- آزمون همسازی دادهها[۲۴]: نوعی از آزمون که برای اطمینان از رعایت قواعد همسازی دادهها[۲۵] توسط نرمافزار (معمولاً در مورد نرمافزارهای مدیریت بانکهای اطلاعاتی) اجرا میشود. سیستم در صورتی از آزمون همسازی دادهها گذر میکند که اجرای هیچیک از کارکردهای پیشبینیشده بهصورت دائم موجب تخطی از هیچیک از قواعد همسازی دادهها نگردد.
۲۴-۳-۱- آزمون چرخه کسبوکار[۲۶]: آزمونی است که با هدف اطمینان از توانایی نرمافزار در اجرای فرآیندهای کسبوکار[۲۷] که برای پشتیبانی از آنها طراحی شده است، اجرا میشوند. در آزمون چرخه کسبوکار معمولاً دوره زمانی مشخصی را (یک سال، یک ماه و …) بهعنوان دوره آزمون انتخاب نموده و همه فرآیندهای کسبوکار ممکن در این دوره را بهصورت سناریوهای آزمون، توسط نرمافزار اجرا میکنند.
۲۵-۳-۱- آزمون واسط کاربر[۲۸]: آزمونی است که برای اطمینان از نحوه تعامل صحیح کاربران با نرمافزار، از طریق منوها، دریچهها، گزارشها و سایر اجزای واسط کاربر طراحی و اجرا میشود.
۲۶-۳-۱- آزمون عملکرد[۲۹]: هدف از آزمون عملکرد سیستم اطمینان از این نکته است که نرمافزار در انجام کارکردهای تعریفشده، از میزان معقولی از منابع (حافظه، فضای دیسک، پردازنده) استفاده کرده و در زمان قابل قبولی پاسخ میدهد. آستانه پذیرش عملکرد نرمافزار در هر کارکرد معمولاً در مرحله تحلیل نیازها تعیین و مستند میگردد.
۲۷-۳-۱- آزمون تحمل بار[۳۰]: منظور از آزمون تحمل بار، قرار دادن نرمافزار تحت حداکثر بارکاری پیشبینیشده و موردانتظار است. معمولاً آزمون تحمل بار در موارد زیر باید اعمال گردد:
- زمان کار پیوسته (بدون قطع)
- استفاده فعال همزمان از نرمافزار توسط چند کاربر
- کارکرد نرمافزار با استفاده از حداکثر گنجایش پایگاه اطلاعاتی. به این منظور هر جدول باید حاوی حداکثر تعداد پیشبینیشده رکورد باشد.
در هر یک از حالات فوق، همه کارکردهای عادی سیستم باید آزمون شده و کارایی باید در آستانه پذیرش باشد. استفاده از روالهای ماشینی برای آزمون تحمل بار توصیه میشود.
۲۸-۳-۱ آزمون تنش[۳۱]: آزمون تنش برای ارزیابی و تحلیل رفتار نرمافزار در برابر مقادیر مرزی (مثلاً رشتههای ورودی با حداکثر طول، یا مقادیر عددی با حداقل یا حداکثر مقدار) انجام میشود.
۲۹-۳-۱ آزمون امنیت[۳۲]: هدف از اجرای آزمون امنیت، اطمینان از توانایی نرمافزار در حفاظت صحیح دادههای ذخیرهشده در مقابل دسترسیهای غیرمجاز میباشد.
۳۰-۳-۱ آزمون تحمل خرابی[۳۳]: بهطورمعمول نرمافزارها باید در مقابل خرابیهای عمدی یا غیرعمدی در محیط اجرا یا پایگاه دادهها توانایی کشف، تحمل و بازسازی[۳۴] (بازگشت به حالت پایدار) داشته باشند. معمولاً رفتار نرمافزار در حالات زیر آزمون میشود:
- اختلال در محیط سختافزاری (قطع ناگهانی برق، خرابی دیسکهای دستگاه خادم یا ایستگاههای کاری، قطع اتصالات شبکه داخلی)
- قطع و اختلال در خطوط انتقال داده
- آماده نبودن تجهیزات جانبی (چاپگر و …)
- اشکالات سیستمعامل
- عدم تنظیم مناسب پارامترهای محیطی
- دستکاری عمدی در سیستم فایلهای فیزیکی پایگاه دادهها
۳۱-۳-۱ آزمون پیکربندی[۳۵]: هدف از آزمون پیکربندی، ارزیابی رفتار نرمافزار در محیطهای نرمافزاری و سختافزاری با پیکربندیهای مختلف و اطمینان از صحت کارکرد آن (در مقایسه با نیازهای اعلامشده قبلی) میباشد.
۳۲-۳-۱ آزمون بازگشتی[۳۶]: به دلیل احتمال بروز اشکالات جدید پس از هر بار رفع اشکال نرمافزار، پس از هر بار ارائه یک نسخه جدید از نرمافزار، یک دوره آزمون بازگشتی با هدف اطمینان از نکات زیر باید اجرا شود:
- تصحیحات انجام شده، منجر به رفع اشکالات قبلی یا بهبود کارایی سیستم شده باشد.
- تصحیحات انجام شده، منجر به بروز اشکالات جدید در دامنه پوشش آزمونهای قبلی نشده باشد.
برحسب مورد و به تشخیص طراح آزمون، یکی از روشهای زیر برای آزمون بازگشتی در هر مرحله قابلاعمال است:
- انجام دوباره مجموعهای از آزمونهای قبلی بهصورت کامل
- انجام مجموعهای تصادفی از آزمونهای قبلی
۳۳-۳-۱- آزمون صعودی (پایین به بالا)[۳۷]: روشی برای آزمون نرمافزار که در آن ابتدا از واحدهای نرمافزار (سطح پایین) شروع میکنیم و پس از طی هر مرحله هنگامیکه همه واحدهای یک سطح کاملاً موردپذیرش قرار گرفتند، به سطح بالاتر رفته و سطح بالاتر را آزمون میکنیم. در این روش، برنامهریزی و طراحی آزمون نیز باید بهصورت سلسلهمراتبی از پایین به بالا صورت گیرد.
۳۴-۳-۱- آزمون نزولی (بالا به پایین)[۳۸]: در این روش بر مبنای رفتار موردنظر نرمافزار، تعدادی سناریو طرحشده و آزمون ابتدا در بالاترین سطح و از دید کاربر نهایی صورت میگیرد. در هر قسمت در صورت مشاهده اشکال، به اجزای آن واحد توجه میکنیم و به همین صورت تا پایینترین سطحی که اشکال در آن کشف و رفع شود پایین میرویم.
۳۵-۳-۱- محیط عملیاتی: منظور محلی است که نرمافزار پس از تهیه در آن نصب و راهاندازی شده و استفاده عملی از نرمافزار توسط کاربران، در آن صورت میگیرد.
۴-۱- اختصارات
در نگارش این طرح، از اختصارات زیر استفاده شده است:
۴-۱-۱- V&V: فرآیندهای تصدیق و صحهگذاری نرمافزار
۴-۱-۱- VVP: طرح تصدیق و صحهگذاری
۴-۱-۱- QA: تضمین کیفیت
۵-۱- منابع و مراجع
از مراجع زیر برای تهیه این استاندارد استفاده شده است:
- IEEE-829 ANSI/IEEE Std 829-1998, IEEE Standard for Software Test Documentation, 1998
- IEEE-1008 ANSI/IEEE Std 1008-1987, IEEE Standard for Software Unit Testing, 2002
- IEEE-730 ANSI/IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans, 1998
- ISO-12207 Information technology- Software Lifecycle processes, ISO-IEC 12207, 1st Edition, 1999
- ANDRIOLE-86 Andriole, S.J. (ed.), Software Validation, Verification, Testing and Documentation, Petrocelli Books, 1986 ESA-76
- استانداردهای مهندسی نرمافزار ـ آژانس فضایی اروپا، ترجمه: ا.مرآت نیا و ن.مرآت نیا، اداره کل آمار و اطلاعات وزارت کشاورزی ـ ۱۳۷۶
- ISO-9001 استاندارد ایران – ایزو – ۹۰۰۱ مؤسسه استاندارد و تحقیقات صنعتی ایران، چاپ اول، دیماه ۱۳۷۴
۲- قالب طرح آزمون نرمافزار
قالب استاندارد طرح آزمون نرمافزار در این فصل ارائه میشود. در استفاده از قالب استاندارد ارائه شده باید به نکات زیر توجه نمود:
- سرفصلهای ارائه شده در قالب استاندارد، باید بهعنوان سرفصلهای حداقل تلقی گردد. بهاینترتیب افزودن سرفصلهای دیگر به طرحهای آزمون نرمافزار، به دلیل الزامات قراردادی یا دلایل دیگر مجاز میباشد. در این صورت توصیه میگردد افزودن مطالب اضافی بهگونهای صورت پذیرد که سرفصلهای موجود در این استاندارد، با همین ترتیب و همین شمارهگذاری قابلتشخیص باشد.
- برخی از سرفصلهای ذکرشده در قالب استاندارد، با علامت (*) مشخصشدهاند. ذکر مطالب ذیل این سرفصلها در طرح، برخلاف سایر سرفصلها اجباری نیست و میتوان به دلیل حجم پروژه، توافق کارفرما و کارگزار، یا بلاموضوع بودن مطالب آن سرفصل با توجه به موضوع پروژه، چنین سرفصلهایی را از یک طرح حذف نمود، بیآنکه تطابق آن طرح با این استاندارد خدشهدار گردد. در صورت حذف مطالب این سرفصلها از یک طرح، عناوین سرفصلهای حذفشده باید در طرح ذکرشده و دلایل و توجیهات حذف هر سرفصل بیان گردد.
- در تشریح مطالب استاندارد، از واژههای «ضروری است…»، «باید…» و «نباید…» برای بیان ضرورت و الزام استفاده شده است. رعایت موارد مشخصشده با این واژهها برای تطابق یک طرح با این استاندارد ضروری است.
- همچنین از واژه «توصیه میشود…» و «شایسته است…» برای بیان مواردی استفاده شده است که رعایت آنها برای تطابق یک طرح با این استاندارد ضروری نیست، اما رعایت آنها توصیه میگردد.
- واژه «میتوان…» نیز برای بیان موارد اختیاری استفاده شده است. رعایت موارد مشخصشده با این واژه برای تطابق یک طرح با این استاندارد ضروری نیست.
- در صورت توافق کارگزار با کارفرما، میتوان طرح آزمون نرمافزار را بهصورت تدریجی تکمیل و ارائه کرد. در این صورت هریک از سرفصلهایی که در اصلاحیههای بعدی طرح تکمیل خواهد شد، باید با عباراتی نظیر «در اصلاحیههای بعدی تکمیل خواهد شد»، مشخص گردد.
- قسمتهای ابتدایی هر طرح که بهمنظور کنترل مستندات[۳۹] در هر سند گنجانده میشود (مانند صفحه روکش[۴۰]، تأییدیه[۴۱]، تاریخچه[۴۲]، فهرست مطالب و)…، جزء الزامات این استاندارد نبوده و مشمول ضوابط عمومی مستندسازی هر پروژه میباشد.
[صفحه روکش]
[تأییدیه]
[تاریخچه]
[فهرست مطالب]
۱- مقدمه
۱-۱- هدف
۲-۱- دامنه کاربرد
۳-۱- تعاریف
۴-۱- اختصارات
۵-۱- اسناد مرتبط
۶-۱- مرور طرح*
۷-۱- روش تغییر طرح*
۲- دامنه آزمون
۱-۲- اجزای نرمافزار
۲-۲- آنچه آزمون خواهد شد
۳-۲- آنچه آزمون نخواهد شد
۳- رویکرد
۴- شرایط پذیرش/رد
۵- سازمان
۱-۵- ساختار
۲-۵- وظایف و مسئولیتها
۶- روش
۱-۶- گردش کار
۲-۶- نمودار گردش عملیات*
۷- شرایط آغاز، توقف، شروع مجدد و پایان آزمون
۱-۷- آغاز آزمون
۲-۷- توقف آزمون
۳-۷- شروع مجدد
۴-۷- پایان آزمون
۸- مستندسازی
۹- مراحل
۱۰- زمانبندی
۱۱- منابع موردنیاز
۱-۱۱- نیروی انسانی
۲-۱۱- آموزش*
۳-۱۱- سختافزار
۴-۱۱- نرمافزار
۵-۱۱- امکانات ارتباطی*
۶-۱۱- سایر منابع*
۱۲- مفروضات و شرایط اضطراری*
۱۳- پیوستها
۱-۱۳- واژهنامه*
در این بخش هریک از سرفصلهای قالب یادشده تشریح میگردد. باید توجه نمود که سرفصلهای استاندارد، با عبارات زیرخط دار مشخص شده است و سایر عباراتی که در توضیح هر مطلب ذکرشدهاند، جزء قالب استاندارد نمیباشند.
[صفحه روکش]
در صفحه روکش طرح حداقل مطالب زیر باید ذکرشده باشد:
- عنوان «طرح آزمون نرمافزار»
- عنوان کامل پروژه
- عنوان کارفرما
- عنوان کارگزار
- تاریخ تهیه طرح
- شناسه سند (به انضمام شماره اصلاحیه)
- تعداد صفحات سند
[تأییدیه]
- در قسمت تأییدیه، حداقل مطالب زیر باید ذکرشده باشد:
- نام، سمت و امضای تهیهکننده (یا تهیهکنندگان) سند
- نام، سمت و امضای فرد (یا افراد) مسئول کنترل کیفی سند
- نام، سمت و امضای فرد (یا افراد) مسئول تأیید و تصویب سند
- تاریخ بررسی و تأیید سند توسط هریک از تأییدکنندگان
[تاریخچه]
در قسمت تاریخچه، حداقل مطالب زیر باید ذکرشده باشد:
- شماره و تاریخ تصویب[۴۳] هر یک از اصلاحیههای پیشین و اصلاحیه فعلی
- شرح مختصری از دلایل صدور هر اصلاحیه و شماره صفحات یا شماره بندهایی که تغییر کرده است.
[فهرست مطالب]
در فهرست مطالب، حداقل مطالب زیر باید ذکرشده باشد:
- شماره بندهای سند
- عنوان کامل هر بند
- شماره صفحه شروع هر بند
توصیه میگردد در نسخه الکترونیکی سند، عنوان هر بند با استفاده از امکان اتصال ابرمتنی، به ابتدای بند مربوطه در سند متصل شود.
۱- مقدمه
مقدمه طرح باید حداقل شامل بندهای زیر باشد:
۱-۱- هدف
در این بند، هدف از تهیه طرح بهطور خلاصه ذکر میگردد. میتوان به مواردی از قبیل نام پروژه، نام و مشخصات نرمافزاری که طرح برای آن تهیه میشود، اهداف کلی از تهیه طرح و ضرورت تهیه آن اشاره نمود.
۲-۱- دامنه کاربرد
دامنه کاربرد طرح بهطور دقیق باید در این بند تشریح گردد. نام نرمافزار (ها) یا اجزای نرمافزاری مشمول در دامنه طرح باید ذکر گردد. درصورتیکه مطالب مندرج در طرح تنها تا زمان معینی معتبر است، این محدودیت باید بهروشنی مورداشاره قرار گیرد.
با توجه به اینکه دامنه طرح آزمون بهتفصیل در بخش ۲ تشریح میگردد، دامنه کاربرد طرح را میتوان با ارجاع به آن بخش مشخص نمود.
۳-۱-تعاریف
کلیه واژگان تخصصی و اصطلاحاتی که در تهیه طرح از آنها استفاده شده است، باید در این قسمت ذکرشده و برای هریک تعریف روشنی ارائه گردد.
درصورتیکه سند دیگری بهعنوان واژگان[۴۴] پروژه تهیه شده است، میتوان بهجای تکرار مطالب آن در این بند، به آن سند ارجاع داد.
۴-۱- اختصارات*
کلیه اختصارات (کوتهنوشت[۴۵] های) مورداستفاده در طرح، باید فهرست شده و تشریح گردند.
۵-۱- اسناد مرتبط
در این بند فهرست و مشخصات اسناد زیر باید ذکر شود:
- منابع و مراجعی که برای تهیه طرح از آنها استفاده شده است (کتابهای مرجع، اسناد قراردادی و قانونی و …)
- سایر اسناد پروژه که در این طرح به آنها ارجاع داده شده است.
- استاندارد حاضر
برای هر سند فهرست شده در این بند، مشخصات کامل سند تا حدی که شناسایی سند بهصورت یگانه ممکن باشد، باید ذکر گردد. در مورد کتابها، ذکر عنوان، نام نویسنده (یا نویسندگان)، ناشر، نوبت چاپ و تاریخ انتشار توصیه میشود. در مورد سایر اسناد، عنوان کامل، شناسه سند، شماره اصلاحیه (در صورت وجود) و تاریخ انتشار باید قید گردد.
۶-۱- مرور طرح*
در این بند، قسمتهای مختلف طرح و محتوای اجمالی هر قسمت، باید بهصورت گذرا تشریح گردد.
۷-۱- روش تغییر طرح*
در این بند، روش و ضوابط تجدیدنظر و تغییر طرح باید تشریح گردد. اشاره به مواردی از قبیل مرجع یا مراجع تصمیمگیری برای تجدیدنظر، تغییر، کنترل، تأیید، تصویب و انتشار اصلاحیه (های) بعدی توصیه میگردد. اگر برنامه زمانی خاصی برای تجدیدنظر و تغییرات آینده طرح موردنظر میباشد، این برنامه (با ذکر تاریخهای مشخص یا با ارجاع به مراحل و مقاطع پروژه) باید ذکر شود. همچنین فهرست کسانی که در صورت تغییر طرح، نسخه تغییریافته را دریافت خواهند کرد، باید در این قسمت ذکر شود.
۲- دامنه آزمون
بخش دامنه آزمون باید حداقل شامل بندهای زیر باشد:
۱-۲- اجزای نرمافزار
در این بند اجزای عمده نرمافزار هدف (یا کل سیستم) باید فهرست شود. اجزای یک سیستم را معمولاً برنامههای اجرایی اصلی، برنامههای اجرایی کمکی، کدهای اصلی و مستندات تشکیل میدهند.
ذکر نام هر بخش کافی است، اما میتوان اطلاعات دیگری همچون شناسه و مشخصات برای بخشها اضافه کرد.
۲-۲- آنچه آزمون خواهد شد
در این بند، بخشها یا ویژگیهایی از نرمافزار هدف که در دامنه شمول (این نوبت از) آزمون میگنجند، باید بهروشنی مشخص شود.
۳-۲- آنچه آزمون نخواهد شد
در این بند، بخشها یا ویژگیهایی از نرمافزار هدف که مشمول دامنه (این نوبت از) آزمون نمیشوند، باید بهروشنی مشخص شود.
۳- رویکرد
در این بخش، رویکرد کلی برای آزمون باید ذکر شود. توضیحات باید شامل روش و استراتژی کلی (مثلاً آزمون صعودی یا نزولی، آزمون خودکار یا دستی و …)، ابزارها، روشها و معیارهای اطمینان از کفایت آزمون باشد (مثلاً ذکر اینکه هر گزارشی حداقل یکبار باید استخراج شود و مانند آن.)… ذکر روشهای کلی در مورد همه ویژگیهای مورد آزمون اشکالی ندارد، اما توصیه میگردد حداقل در مورد آزمونهای زیر (بهشرط آنکه با توجه به کارکرد نرمافزار و دامنه این نوبت از آزمون موضوعیت داشته باشند) بهصورت جداگانه رویکرد آزمون ذکر گردد:
- آزمون کارکردی
- آزمون همسازی دادهها
- آزمون چرخه کسبوکار
- آزمون واسط کاربر
- آزمون عملکرد
- آزمون تحمل بار
- آزمون تنش
- آزمون امنیت
- آزمون تحمل خرابی
- آزمون پیکربندی
- آزمون بازگشتی
۴- شرایط پذیرش/رد
برای هریک از نرمافزارها یا اجزای نرمافزاری مشمول در دامنه آزمون، شرایط پذیرش یا رد نرمافزار هدف، پس از اجرای آزمون باید بهروشنی و بهصورت دقیق ذکر شود.
۵- سازمان
بخش سازمان باید حداقل شامل بندهای زیر باشد:
۱-۵- ساختار
در این بند، بخشی از واحدها و عناصر موجود در ساختار سازمانی پروژه که در فرآیند آزمون مؤثرند، باید در قالب یک نمودار تشکیلاتی[۴۶] تشریح گردند. ضوابط ترسیم این نمودار به استانداردهای سازمانی کارگزار بستگی دارد، اما رعایت نکات زیر ضروری است:
- برای هر یک از عناصر موجود در نمودار، عنوان کامل و گویایی باید ذکر شود.
- واحدهای سازمانی (کمیته، گروه، واحد و …) باید به نحو مناسبی از افراد (مدیر، مسئول و …) متمایز گردند.
- خطوط فرماندهی و گزارش دهی باید بهطور مشخص و بدون ابهام ترسیم شده باشند.
ذکر اسامی افرادی که در فرآیند آزمون نقش دارند، ضروری است.
درصورتیکه ساختار سازمانی پروژه در طرح مدیریت پروژه تشریح شده باشد، میتوان مطالب این بند را به بند متناظر در طرح مدیریت پروژه ارجاع داد.
۲-۵- وظایف و مسئولیتها
در این بند، وظایف، اختیارات و مسئولیتهای هریک از ارکان و عناصر درگیر در فرآیند آزمون نرمافزار که در بند (۱-۵) ذکرشدهاند، باید تشریح گردد.
۶- روش
بخش روش باید حداقل شامل بندهای زیر باشد:
۱-۶- گردش کار
در این بند، گامهای اجرایی لازم برای انجام مراحل آزمون بهصورت گامبهگام و با جزئیات کافی باید تشریح گردد.
۲-۶- نمودار گردش عملیات*
در صورت لزوم، روند تشریح شده در بند (۱-۶) در این بند در قالب یک نمودار گردش عملیات بهصورت گرافیکی ترسیم میگردد. محدودیتی در مورد استاندارد نمودارسازی وجود ندارد.
۷- شرایط آغاز، توقف، شروع مجدد و پایان آزمون
این بخش باید حداقل شامل بندهای زیر باشد:
۱-۷- آغاز آزمون
در این بند، شرط یا شرایطی که تحقق آن (ها) برای آغاز آزمون ضروری است، باید بهروشنی ذکر گردد.
۲-۷- توقف آزمون
در این بند، شرط یا شرایطی که تحقق آن (ها) موجب توقف و تعلیق موقت فرآیند آزمون میشود، باید بهروشنی ذکر گردد.
۳-۷- شروع مجدد
در این بند، شرط یا شرایطی که تحقق آن (ها) برای آغاز مجدد آزمون (پس از توقف و تعلیق مجدد) ضروری است، باید بهروشنی ذکر گردد.
۴-۷- پایان آزمون
در این بند، شرط یا شرایطی که تحقق آن (ها) برای پایان یافتن آزمون ضروری است، باید بهروشنی ذکر گردد.
۸- مستندسازی
در این بخش، قالب، محتوا و رویه تهیه مستندات لازم در طی اجرای آزمون باید مشخص گردد.
۹- مراحل
در این بخش، مرحلهبندی پیشبینیشده برای ارائه نسخههای قابل آزمون نرمافزار و نوع آزمونهایی که در هر مرحله باید انجام شود، باید تشریح شود. توصیه میشود هر نسخه با یک شناسه واحد متمایز و مشخص گردد.
۱۰- زمانبندی
در این بخش، برنامه زمانی تفصیلی مراحل آزمون، با ذکر توالی، تاریخ شروع و تاریخ پایان هر فعالیت یا مرحله باید ذکر گردد.
۱۱- منابع موردنیاز
این بخش باید حداقل شامل بندهای زیر باشد:
۱-۱۱- نیروی انسانی
در این بند، میزان نیروی انسانی لازم (برحسب تخصصها و زمان لازم) برای اجرای آزمون، باید تشریح گردد.
۲-۱۱-آموزش*
درصورتیکه اجرای آزمون مستلزم آموزشهای خاصی برای اعضای تیم آزمون باشد، در این بند، آموزشهای لازم برای اجرای آزمون، باید تشریح گردد.
۳-۱۱- سختافزار
در این بند، تعداد و مشخصات تجهیزات سختافزاری لازم برای اجرای آزمون، باید مشخص گردد.
۴-۱۱- نرمافزار
در این بند، مشخصات نرمافزارهای لازم برای اجرای آزمون (غیر از نرمافزار هدف)، باید تشریح گردد.
۵-۱۱- امکانات ارتباطی*
درصورتیکه امکانات ارتباطی خاصی برای اجرای آزمون موردنیاز باشد، در این بند، این امکانات باید تشریح گردد.
۶-۱۱- سایر منابع*
درصورتیکه برای اجرای آزمون منابع دیگری غیر از موارد پیشگفته موردنیاز باشد، در این بند، این امکانات باید فهرست گردد.
۱۲- مفروضات و شرایط اضطراری
مفروضات، مخاطرات قابل پیشبینی و عملیات لازم در هنگام بروز شرایط اضطراری باید در این بند مشخص گردد.
۱۳- پیوستها
کلیه مطالب کمکی که ذکر آنها برای فهم مطالب طرح لازم است، باید بهصورت پیوست به انتهای طرح افزوده شود. بهویژه وجود پیوست زیر در انتهای طرح توصیه میشود:
۱-۱۳- واژهنامه*
کلیه واژگان و اصطلاحات فنی استفاده شده در طرح باید در این بخش توضیح داده شوند. برای هر واژه، ذکر برابر انگلیسی و کوتهنوشت (در صورت وجود) ضروری است. واژهنامه باید برحسب حروف الفبای فارسی مرتب شده باشد. توصیه میشود واژهنامه انگلیسی-فارسی نیز ارائه گردد.
[۱] Unit Test
[۲] Integration Test
[۳] System Test
[۴] Acceptance
[۵] Software Development Lifecycle
[۶] Sub-project
[۷] Contractor
[۸] Subcontractor
[۹] IEEE-730: p.3
[۱۰] Verification
[۱۱] ISO-12207: p.5 (Verification)
[۱۲] Validation
[۱۳] ISO-12207: p.5 (Validation)
[۱۴] Test
[۱۵] Unit test
[۱۶] Integration test
[۱۷] System test
[۱۸] Gap
[۱۹] Acceptance test
[۲۰] Test data
[۲۱] Test procedure
[۲۲] Test case
[۲۳] Functional test
[۲۴] Data integrity test
[۲۵] Data integrity rules
[۲۶] Business cycle test
[۲۷] Business process
[۲۸] User interface test
[۲۹] Performance test
[۳۰] Load test
[۳۱] Stress test
[۳۲] Security test
[۳۳] Fault-Tolerance test
[۳۴] Recovery
[۳۵] Configuration test
[۳۶] Regressio
[۳۷] Bottom-Up Test
[۳۸] Top-Down Test
[۳۹] Document Control
[۴۰] Cover Page
[۴۱] Approval
[۴۲] History
[۴۳] Approval
[۴۴] Glossary
[۴۵] Abbreviations (Acronyms)
[۴۶] Organization Chart
مجید باقری
سلام... من مجید باقری هستم! به سایت شخصی من خوش آمدید. در این سایت علاوه بر پیدا کردن پاسخ سوالات خود در حوزه فناوری اطلاعات، می توانید پرسش های خاص خود را نیز برای من ارسال نمائید. در این سایت شما می توانید سوابق علمی و تجربیات حرفه ای من را ببینید و با توانایی های فنی من آشنا شوید. این راهی است به سوی همکاری های بعدی …
همه مطالب ارسالی توسط: مجید باقری