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

اصطلاحات "تأیید" و "اعتبارسنجی" اغلب در ادبیات فنی استفاده می شود و با تجزیه و تحلیل کیفیت هر نرم افزار همراه است. تفاسیر مختلفی از این مفاهیم را می توان در ادبیات علمی یافت. بنابراین، بیایید سعی کنیم این موضوع را درک کنیم.

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

تأیید تأیید انطباق نرم افزار با مشخصات الزامات، معماری یا «وظایف» این اصطلاح شامل مقایسه روش محاسبه با روند توسعه، قوانین و استانداردهای آنها است.

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

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

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

راستی‌آزمایی پاسخ به سؤال «آیا نرم‌افزار درست انجام شده است؟» و اعتبارسنجی پاسخ سؤال «آیا نرم‌افزار درست انجام شده است؟» است.

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

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

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

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

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

20. تأیید و اعتبار سنجی نرم افزار

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

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

تأیید به این سؤال پاسخ می دهد که آیا سیستم به درستی طراحی شده است.

صدور گواهینامه به این سوال پاسخ می دهد که آیا سیستم به درستی کار می کند یا خیر.

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

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

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

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

2. تست نرم افزار.اجرای کدهای اجرایی با داده های آزمایشی و بررسی خروجی و عملکرد محصول نرم افزاری برای بررسی درستی کارکرد سیستم. آزمایش یک روش پویا برای تأیید و اعتبار است زیرا در سیستم در حال اجرا اعمال می شود.

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

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

برنج. 20.1. تأیید و تأیید استاتیک و پویا

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

انواع مختلف تست در مراحل مختلف فرآیند توسعه نرم افزار استفاده می شود.

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

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

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

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

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

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

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

1. تایید و اعتبار سنجی فرآیند تشخیص نقص در یک سیستم نرم افزاری است.

2. اشکال زدایی - فرآیند بومی سازی عیوب (خطاها) و رفع آنها (شکل 20.2).

برنج. 20.2. فرآیند اشکال زدایی

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

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

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

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

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

ارسال کار خوب خود در پایگاه دانش ساده است. از فرم زیر استفاده کنید

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

میزبانی شده در http://www.allbest.ru/

انشا

روش های تایید و تست نرم افزار

معرفی

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

همزمان با توسعه فناوری رایانه، با نفوذ آن به تمام عرصه های زندگی، تعداد خطاهای برنامه ها نیز رو به افزایش است. علاوه بر این، رشد خطاها با رشد تعداد برنامه ها نامتناسب است. هر ساله رتبه برنامه نویسان با bydlocoder ها (و نام آنها legion است) پر می شود که به صورت تصاعدی زمینه خطاها را توسعه می دهند.

خطاها در هر منطقه قابل مشاهده نیستند. به عنوان مثال، هیچ کس به باگ ها و آسیب پذیری های مرورگرهایی مانند "amigo" اهمیت نمی دهد. بله، و ضرر و زیان ناشی از چنین خطاهایی ناچیز است: حداکثر چیزی که یک کاربر معمولی می تواند از دست بدهد، حساب های کاربری در شبکه های اجتماعی، یک و نیم هزار عکس متوسط ​​​​تعطیلات و یک مجموعه پورن است.

اما زمینه هایی وجود دارد که خطاهای برنامه نویسی می تواند منجر به ناگوارترین عواقب شود. یکی از اولین مواردی که توانستم پیدا کنم، فضاپیمای مارینر 1 بود که در 22 ژوئیه 1962، 293 ثانیه پس از پرتاب، به دلیل خطا در برنامه کامپیوتری آنبرد نابود شد. خوبه که اون موقع هیچ مرگی نبود.

و اگر کامپیوتر بوئینگ-747 با چهارصد سرنشین، استثناء ایجاد کند، چه اتفاقی خواهد افتاد؟

برای چنین مناطقی است که می توان آنها را "جدی" نامید که روش های تأیید و آزمایش ابداع شده است.

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

1. تعاریف

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

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

2. تایید

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

موارد فوق تعریف رسمی تأیید است. در واقع، همه چیز بسیار ساده تر است: تأیید تعیین می کند آیا ما برنامه را درست انجام می دهیم؟.

بنابراین، روش های اصلی تأیید، معاینه و بازرسی است.

تایید تخصص برنامه

3. اعتبار سنجی

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

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

4. آزمایش

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

از لحاظ تاریخی، اولین نوع آزمایش، اشکال زدایی بود.

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

1. روش های تست استاتیک

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

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

2. روش های آزمایش پویا

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

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

روش جعبه سفید.

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

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

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

3. تست عملکردی

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

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

وظایف تست عملکردی عبارتند از:

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

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

شناسایی مجموعه داده های ورودی هر تابع و تعیین مناطق تغییر آنها.

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

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

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

5. انواع خطا ANSI/IEEE-7 29 -8 3

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

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

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

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

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

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

ممکن است برنامه نادرست باشد، به عنوان مثال یک الگوریتم غیر معمول را انجام می دهد یا به طور کامل پیاده سازی نشده است.

نتیجه

GOST های روسی مربوط به تأیید و آزمایش نرم افزار ترجمه استانداردهای "بورژوایی" مانند ISO 12207، ANSI/IEEE-729-83 و دیگران هستند (تعداد زیادی از آنها وجود دارد). مشکل این است که این استانداردهای بین المللی به طور متفاوتی با مسائل مربوط به تست و تأیید برخورد می کنند. نمی توان گفت که آنها کاملاً با یکدیگر در تضاد هستند، اما می توانند باعث سردرگمی شوند.

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

نتیجه‌گیری: ساختار روش‌های تأیید، اعتبارسنجی و آزمون باید مشروط در نظر گرفته شود.

کتابشناسی - فهرست کتب

1. دانشنامه رایگان wikipedia.org

2. Kulyamin V.V. روش های تأیید نرم افزار M.: موسسه برنامه نویسی سیستم، 2008

3. Lavrishcheva E., Petrukhin V. سخنرانی "روش های بررسی و آزمایش برنامه ها و سیستم ها": NOU "INTUIT" http://www.intuit.ru/studies/professional_retraining/944/courses/237/print_lecture/6130

میزبانی شده در Allbest.ru

اسناد مشابه

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

چکیده، اضافه شده در 01/11/2009


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

ارائه، اضافه شده در 05/11/2015


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

مقاله ترم، اضافه شده در 2015/12/16


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

مقاله ترم، اضافه شده در 2015/03/22


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

ارائه، اضافه شده در 2016/09/19


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

پایان نامه، اضافه شده 05/03/2018


استانداردهای بین المللی پایه در زمینه فناوری اطلاعات. استاندارد بین المللی ISO/IEC 9126. کیفیت و چرخه عمر. مشخص کردن ویژگی های داخلی و خارجی کیفیت. تجزیه و تحلیل عملکرد نرم افزار.

گزارش، اضافه شده در 1396/06/13


اهداف و مقاصد مهندسی نرم افزار. مفهوم نرم افزار. شش اصل برای استفاده موثر از نرم افزار. انواع نرم افزار: سیستمی، شبکه ای و کاربردی. اصول ساخت نرم افزار.

مقاله ترم، اضافه شده در 2010/06/29


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

ارائه، اضافه شده در 2013/12/27


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

دو مفهوم اعتبار سنجی و تأیید اغلب با هم اشتباه گرفته می شوند. علاوه بر این، اعتبارسنجی الزامات سیستم اغلب با اعتبارسنجی سیستم اشتباه گرفته می شود. پیشنهاد می کنم این موضوع را بررسی کنید.

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

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

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

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

2. سوابق ناقص دانش در مورد شی - چیزی از قلم افتاده است، اشتباهاتی انجام می شود. به عنوان مثال، آنها در مورد بادها می دانستند، اما فراموش کردند که آن را ذکر کنند. این ممکن است منجر به توصیف ناکافی کامل الزامات برای شی شود.

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

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

5. ثبت ناقص نتیجه گیری های به دست آمده در مورد طراحی سیستم. همه چیز حساب شده بود، همه چیز حساب شده بود، اما یادشان رفته بود بنویسند.

6. سیستم ایجاد شده با توضیحات مطابقت ندارد.

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

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

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

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

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

تأیید برنامه، در اصل، نیاز به آزمایش و اشکال زدایی آن را برطرف می کند، زیرا در همان زمان، در سطح بالاتری از مفاهیم و توضیحات همه متغیرها، صحت فرآیندها، پردازش و تبدیل آنها ایجاد می شود.

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

روش ادعاهای استقرایی.

برای مطالعه این روش، برنامه با عباراتی در مورد ویژگی های متغیرهای آن در برخی نقاط ارائه می شود:

الف) متغیرهای ورودی در طول اجرای برنامه تغییر نمی کنند.

ب) حالات متغیرها را در نقاط میانی توصیف کنید.

ج) متغیرهای خروجی از نظر روابط بین متغیرها پس از پایان برنامه توصیف می شوند.

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

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

· زبان نوشتن متون برنامه؛

· زبان فرمولاسیون شرایط تایید.

· زبان شکل گیری و اثبات صحت.

از آنجایی که این زبان ها تا حد زیادی با هم تفاوت دارند، این شرایط یکی از کاربردهای تأیید است.

اثبات صحت دارای مزایای زیر است:

1. این یک فرآیند رسمی شفاف است.

2. نیاز به تحلیل دارد. فرآیند اثبات صحت این امکان را فراهم می کند که بخش هایی از برنامه ها را در نظر بگیریم که در غیر این صورت فقط به صورت تصادفی تجزیه و تحلیل می شوند.

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

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

معایب روش:

1. پیچیدگی; حتی برای برنامه های کوچک و ساده، محاسبات بسیار پیچیده است که می تواند منجر به خطا شود.

2. اشتباهات به دلیل پیچیدگی روش، اشتباه کردن هم در شکل گیری گزاره های قابل اثبات و هم در اثبات آسان است.

3. مشکلات در کار با آرایه ها.

4. فقدان دستگاه قدرتمند ریاضی.

5. شدت کار بالا برای بررسی برنامه نیاز به هزینه های نیروی کار نسبت به نوشتن آن دارد (2 تا 6 بار).

6. عدم بیان. تشکیل یک بیانیه سودمند برای آنچه که به طور شهودی یک محاسبه بسیار ساده است، اغلب آسان نیست:

7. مشکل در درک.

8. نیاز به آموزش. این روش نیاز به تمرین و تمرین زیاد دارد.