Бағдарламалық жасақтаманы тексеру және тексеру - Software verification and validation

Жылы бағдарламалық қамтамасыз етуді басқару, бағдарламалық жасақтаманы тестілеу, және бағдарламалық жасақтама, тексеру және тексеру (V&V) - бұл бағдарламалық жасақтама жүйесінің техникалық шарттарға сәйкес келуін және оның мақсатына сәйкес келуін тексеру процесі. Ол сондай-ақ деп аталуы мүмкін бағдарламалық жасақтама сапасын бақылау. Әдетте бұл жауапкершілік бағдарламалық жасақтама тестерлері бөлігі ретінде бағдарламалық жасақтаманың өмірлік циклі. Қарапайым тілмен айтқанда, бағдарламалық жасақтаманы тексеру дегеніміз: «Егер біз X-ті құруымыз керек деп ойласақ, онда біздің бағдарламалық жасақтама өз мақсатына еш қатесіз және олқылықсыз жете ме?» Екінші жағынан, бағдарламалық жасақтаманы растау: «X-ді біз салуымыз керек пе еді? Х деңгейі жоғары деңгейдегі талаптарға сәйкес келе ме?»

Анықтамалар

Тексеру мен валидация бір-біріне ұқсамайды, дегенмен олар жиі шатастырылады. Бом ретінде айырмашылықты қысқаша білдірді[1]

  • Тексеру: біз өнімді дұрыс құрастырып жатырмыз ба?
  • Тексеру: біз дұрыс өнім жасаймыз ба?

«Өнімді дұрыс құру» дегеніміз не екенін тексереді сипаттамалары жүйеге дұрыс енгізілген, ал «дұрыс өнімді құру» қайтадан сілтеме жасайды пайдаланушының қажеттіліктері. Кейбір жағдайларда талап етіледі жазбаша талаптар, сондай-ақ ресми рәсімдер немесе сәйкестікті анықтауға арналған хаттамалар.

Өнімнің құқығын құру әзірлеу процесінің келесі кезеңі үшін кіріс ретінде Талаптардың сипаттамасын пайдалануды білдіреді, жобалау процесі, оның нәтижесі Дизайн ерекшелігі болып табылады. Сонымен қатар, бұл құрылыс процесін қамтамасыз ету үшін Дизайн ерекшеліктерін пайдалануды білдіреді. Процестің нәтижелері оның енгізу сипаттамасын дұрыс жүзеге асырған сайын, бағдарламалық өнім соңғы тексеруге бір қадам жақындайды. Егер процестің нәтижесі дұрыс болмаса, әзірлеушілер мүдделі тараптар қалаған өнімді құрастырмайды. Тексерудің бұл түрі «артефакт немесе спецификацияны тексеру» деп аталады.

Дұрыс өнімді құру бағдарламалық өнімнің мүдделі тараптарының қажеттіліктері мен мақсаттарын қамтитын талаптар спецификациясын құруды білдіреді. Егер мұндай артефакт толық болмаса немесе дұрыс болмаса, әзірлеушілер мүдделі тараптар қалаған өнімді жасай алмайды. Бұл «артефакт немесе спецификацияны тексеру» нысаны.

Ескерту: Тексеру валидациядан бұрын басталады, содан кейін олар бағдарламалық өнім шыққанға дейін қатар жүреді.[түсіндіру қажет ]

Бағдарламалық жасақтаманы тексеру

Бұл бағдарламалық жасақтаманы іске қосу арқылы техникалық сипаттамаларға сәйкестігін тексеруді білдіреді, бірақ бұл мүмкін емес (мысалы, бағдарламалық жасақтама архитектурасы / дизайны / т.с.с. дұрыс орындалғанын кім біледі?). Тек онымен байланысты артефактілерді қарау арқылы біреу техникалық шарттар орындалған жағдайда қорытынды жасай алады.

Артефактты немесе техникалық сипаттаманы тексеру

Бағдарламалық жасақтаманы әзірлеудің әрбір кезеңінің нәтижелері оның кіріс спецификациясымен тексерілген кезде тексерілуі мүмкін (төмендегі CMMI анықтамасын қараңыз).

Артефактты тексеру мысалдары:

  • Талап спецификациясына қарсы жобалық спецификациялардан: архитектуралық дизайн, егжей-тегжейлі дизайн және мәліметтер базасының логикалық моделінің сипаттамалары функционалды және функционалды емес талаптардың техникалық сипаттамаларын дұрыс орындай ма?
  • Жобалық сипаттамаға қарсы құрылыс артефактілерінің ішінен: бастапқы код, пайдаланушы интерфейстері және мәліметтер базасының физикалық моделі жобалық сипаттаманы дұрыс жүзеге асыра ма?

Бағдарламалық жасақтаманы тексеру

Бағдарламалық жасақтаманы растау бағдарламалық өнімнің мақсатқа сай қолданылуын қанағаттандыратынын немесе сәйкестігін тексереді (жоғары деңгейдегі тексеру), яғни бағдарламалық жасақтама спецификация артефактілері ретінде немесе тек бағдарламалық жасақтаманы басқаратындардың қажеттіліктері бойынша емес, пайдаланушының талаптарына сәйкес келеді; бірақ барлық мүдделі тараптардың қажеттіліктері ретінде (мысалы, пайдаланушылар, операторлар, әкімшілер, менеджерлер, инвесторлар және т.б.). Бағдарламалық жасақтаманы тексерудің екі әдісі бар: ішкі және сыртқы. Бағдарламалық жасақтаманың ішкі тексерісі кезінде мүдделі тараптардың мақсаттары дұрыс түсінілген және олар талап етілетін артефактілерде дәл және жан-жақты көрсетілген деген болжам жасалады. Егер бағдарламалық жасақтама талаптың сипаттамасына сәйкес келсе, ол ішкі расталған. Сыртқы валидация мүдделі тараптардан бағдарламалық жасақтама олардың қажеттіліктерін қанағаттандыратындығын сұрау арқылы жүзеге асқанда орын алады. Бағдарламалық жасақтаманы әзірлеудің әртүрлі әдістемелері пайдаланушылар мен мүдделі тараптардың қатысуы мен кері байланыстың әр түрлі деңгейлерін талап етеді; Сонымен, сыртқы тексеру дискретті немесе үздіксіз оқиға болуы мүмкін. Сәтті сыртқы верификация барлық мүдделі тараптар бағдарламалық өнімді қабылдап, олардың қажеттіліктерін қанағаттандыратынын білдірген кезде жүзеге асырылады. Мұндай соңғы сыртқы валидация үшін қабылдау тесті бұл а динамикалық тест.

Сонымен қатар, оның ішкі сипаттамалық талаптарға сәйкестігін, бірақ бағдарламалық жасақтама жұмыс істемейтіндіктен статикалық тексеру аясына кіретінін анықтау үшін ішкі статикалық тестілерді өткізуге болады.

Артефактты немесе техникалық сипаттаманы тексеру

Талаптар бағдарламалық өнім толығымен дайын болғанға дейін расталуы керек (сарқыраманы әзірлеу процесі оларды жобалау басталғанға дейін толық анықталуын талап етеді, бірақ қайталанатын даму процестері бұлай болуын талап етпейді және олардың үнемі жетілдірілуіне мүмкіндік береді).

Артефактты тексеру мысалдары:

  • Пайдаланушы талаптарының спецификациясын растау: Пайдаланушының талаптары спецификациясы деп аталатын құжатта көрсетілген пайдаланушының талаптары олардың шынымен мүдделі тараптардың еркі мен мақсаттарын білдіретіндігін тексеру арқылы тексеріледі. Мұны олармен сұхбаттасу және олардан тікелей сұрау (статикалық тестілеу) немесе тіпті прототиптерді шығару және пайдаланушылар мен мүдделі тараптардың бағалауына мүмкіндік беру арқылы жасауға болады (динамикалық тестілеу).
  • Пайдаланушының кіруін тексеру: Пайдаланушының кірісі (периферия, пернетақта, биометриялық сенсор және т.б. сияқты кез-келген перифериялық құрылғылармен жиналады) жарамды бағдарламалық жасақтама операторлары немесе пайдаланушылары ұсынған мәліметтер домен ережелеріне және шектеулеріне сәйкес келетіндігін тексеру арқылы (мысалы, мәліметтер типі, ауқым және формат).

Тексеруге қарсы тексеру

Сәйкес Қабілеттің жетілу моделі (CMMI-SW v1.1),

  • Бағдарламалық жасақтаманы растау: бағдарламалық жасақтаманы әзірлеу процесінде немесе оның аяғында оның белгіленген талаптарға сәйкес келетіндігін анықтау үшін бағалау. [IEEE-STD-610]
  • Бағдарламалық жасақтаманы растау: берілген даму кезеңінің өнімі осы кезеңнің басында қойылған шарттарға сәйкес келетіндігін анықтау үшін бағдарламалық жасақтаманы бағалау процесі. [IEEE-STD-610]

Бағдарламалық жасақтаманы әзірлеу барысында растауды Пайдаланушы талаптарының ерекшеліктерін тексеру формасы ретінде қарастыруға болады; және әзірлеу процесінің соңында ішкі және / немесе сыртқы бағдарламалық жасақтаманың валидациясына тең болатындығы. Тексеру, CMMI тұрғысынан, артефакт түріне жататыны анық.

Басқаша айтқанда, бағдарламалық жасақтаманы тексеру бағдарламалық жасақтаманы әзірлеу процесінің әр кезеңінің нәтижесі оның сәйкес келетін артефактісі (талап -> дизайн -> бағдарламалық өнім) көрсеткен нәрсені тиімді жүзеге асыруын қамтамасыз етеді, ал бағдарламалық жасақтаманы тексеру бағдарламалық өнімнің қажеттіліктерін қанағаттандырады барлық мүдделі тараптар (сондықтан талап спецификациясы бірінші кезекте дұрыс және дәл көрсетілген). Бағдарламалық жасақтаманы тексеру «сіз оны дұрыс салдыңыз» және өнімнің, әзірлеушілердің жоспарларын орындайтындығын растайды. Бағдарламалық жасақтаманы растау «сіз дұрыс нәрсе салдыңыз» және өнімнің, ұсынылған тәртіпте, мүдделі тараптардың мақсатты қолданылуы мен мақсаттарына сәйкес келетіндігін растайды.

Бұл мақалада қатаң немесе қолданылған тар тексерудің анықтамасы.

Тестілеу тұрғысынан:

  • Ақаулық - кодтағы дұрыс емес немесе жоқ функция.
  • Сәтсіздік - орындалу кезіндегі ақаулықтың көрінісі. Бағдарламалық жасақтама тиімді болмады. Ол «не істеу керек» дегенді жасамайды.
  • Ақаулық - оның сипаттамасына сәйкес жүйе көрсетілген функционалдылыққа сәйкес келмейді. Бағдарламалық жасақтама тиімді болмады (оған CPU циклдары сияқты ресурстар тым көп жұмсалды, жад өте көп пайдаланылды, енгізу-шығару операциялары тым көп орындалды және т.б.), ол қолданылмайтын, сенімді емес және т.б. оны «қалай» жасау керек нәрсе.

Байланысты ұғымдар

Тексеру де, валидация да ұғымдарымен байланысты сапа және бағдарламалық жасақтама сапасының кепілдігі. Верификация және валидация өздігінен бағдарламалық жасақтама сапасына кепілдік бермейді; жоспарлау, қадағалау, конфигурацияны басқару және бағдарламалық жасақтаманың басқа аспектілері қажет.

Ішінде модельдеу және модельдеу (M&S) қоғамдастығы, тексеру, валидация және аккредиттеу анықтамалары ұқсас:

  • M&S Verified - бұл а компьютерлік модель, модельдеу немесе модельдеу және модельдеу модельдеу федерациясы және олармен байланысты деректер әзірлеушінің тұжырымдамалық сипаттамасы мен сипаттамаларын дәл көрсетеді.[2]
  • M&S валидациясы дегеніміз - модель, модельдеу немесе модельдер мен имитациялар федерациясының дәрежесін анықтау процесі және олармен байланысты мәліметтер нақты әлемді мақсатты қолдану (лар) тұрғысынан дәл бейнелеу болып табылады.[2]
  • Аккредиттеу модель немесе имитацияны белгілі бір мақсатта қолдануға болатындығы туралы ресми сертификаттау болып табылады.[2]

ЖАО-ны тексерудің анықтамасы ЖА-ның нақты мақсаттағы қолдануды (-ларды) дәлдігін көрсетуге бағытталған. ЖАО дәлдігінің дәрежесін анықтау қажет, өйткені барлық ЖАО шындықтың жуықтауы болып табылады, және әдетте жуықтау дәрежесінің мақсатты қолдану (лар) үшін қолайлы екендігін анықтау өте маңызды. Бұл бағдарламалық жасақтаманы тексеруден айырмашылығы.

Әдістердің жіктелуі

Жылы миссиялық-сыни ақаусыз өнімділік қажет бағдарламалық қамтамасыз ету жүйелері, формальды әдістер жүйенің дұрыс жұмысын қамтамасыз ету үшін қолданылуы мүмкін.[3] Бұл формальды әдістер қымбатқа түсуі мүмкін, алайда бұл бағдарламалық жасақтаманың жалпы құнының 80 пайызын құрайды.[4]

Сынақ жағдайлары

Тест ісі - бұл процесте қолданылатын құрал. Бағдарламалық жасақтаманы тексеру және өнімнің пайдаланушының талаптарына сәйкес құрастырылған-жасалмағандығын анықтау үшін тестілік жағдайлар дайындалуы мүмкін. Бағдарламалық қамтамасыздандыруды қамтамасыз ету үшін өмір циклінің басында шолулар сияқты басқа әдістер қолданылуы мүмкін.

Тәуелсіз тексеру және растау

ISVV сөзінің мағынасы Бағдарламалық жасақтаманы тәуелсіз тексеру және растау. ISVV қауіпсіздікті қамтамасыз етуге бағытталған бағдарламалық жасақтама жүйелер мен бағдарламалық қамтамасыз етудің сапасын арттыруға, сол арқылы бағдарламалық қамтамасыз етудің пайдалану мерзімі ішінде тәуекелдер мен шығындарды азайтуға бағытталған. ISVV бағдарламалық жасақтама сенімділіктің белгіленген деңгейінде және оның жобаланған параметрлері мен талаптары шегінде орындалатындығына кепілдік береді.

ISVV қызметін процестерді және алынған өнімдерді бағалау үшін бағдарламалық жасақтама жасау процесіне қатыспайтын тәуелсіз инженерлік топтар орындайды. ISVV командасының тәуелсіздігі үш түрлі деңгейде жүзеге асырылады: қаржылық, басқарушылық және техникалық.

ISVV дамыту топтары қолданатын «дәстүрлі» тексеру және растау тәсілдерінен әлдеқайда асып түседі. Соңғысы бағдарламалық жасақтаманың номиналды талаптарға сай жұмыс істеуін қамтамасыз етуге бағытталған болса, ISVV сенімділігі мен сенімділігі сияқты функционалды емес талаптарға және бағдарламалық жасақтаманың істен шығуына әкелуі мүмкін жағдайларға бағытталған. ISVV нәтижелері мен нәтижелері түзету және жақсарту үшін даму топтарына жіберіледі.

ISVV тарихы

ISVV бағдарламалық қамтамасыздандыруға IV&V (Тәуелсіз тексеру және тексеру) қолдануынан туындайды. Ерте ISVV қолдану (бүгінде белгілі) 1970 жылдардың басынан басталады АҚШ армиясы Қауіпсіздікті қамтамасыз етуге арналған IV & V-ге қатысты алғашқы маңызды бағдарламаға демеушілік жасады Баллистикалық зымыран Жүйе.

1970 ж. Аяғында IV & V тез танымал бола бастады. Бағдарламалық жасақтаманың күрделілігінің, көлемінің және маңыздылығының үнемі артуы бағдарламалық қамтамасыздандыруға (ISVV) қолданылатын IV&V-ге сұраныстың артуына әкеледі.

Сонымен, IV&V (және бағдарламалық қамтамасыз ету жүйелеріне арналған ISVV) консолидацияланып, қазір сияқты ұйымдар кеңінен қолданады DoD, FAA, НАСА және ESA. IV&V туралы айтылған DO-178B, ISO / IEC 12207 жылы ресімделген IEEE 1012.

Бастапқыда 2004-2005 жылдары Еуропалық консорциум Еуропалық ғарыш агенттігі, және құрастырған DNV, Critical Software SA, Терма және CODA SciSys plc басқа ұйымдардың қолдауымен ISVV-ге арналған «Тәуелсіз тексеру және растау жөніндегі ESA нұсқаулығы» деп аталатын нұсқаулықтың алғашқы нұсқасын жасады. SoftWcare SL,[5] т.б.

2008 жылы Еуропалық ғарыш агенттігі екінші нұсқасын шығарды, SoftWcare SL - бұл көптеген әр түрлі еуропалық кеңістіктің ISVV мүдделі тараптарынан мәлімет алған редактор болды. Бұл нұсқаулық ISVV-ге қатысты барлық бағдарламалық жасақтама кезеңдеріне қолданылатын әдістемелерді қамтиды.

ISVV әдістемесі

ISVV әдетте бес негізгі фазадан тұрады, бұл кезеңдер дәйекті түрде немесе тігін процесінің нәтижесінде орындалуы мүмкін.

ISVV жоспарлау

  • ISVV қызметін жоспарлау
  • Жүйелік сыни талдау: RAMS әрекеттерінің жиынтығы арқылы маңызды компоненттерді анықтау (ақшаға мән)
  • Сәйкес әдістер мен құралдарды таңдау

Талаптарды растау

  • Тексеру: толықтығы, дұрыстығы, сыналуы

Дизайнды тексеру

  • Бағдарламалық жасақтама талаптары мен интерфейстерге сәйкестігі мен сәйкестігін жобалаңыз
  • Ішкі және сыртқы жүйелілік
  • Техникалық негіздеме мен техникалық қызмет көрсетуді тексеру

Кодты тексеру

  • Тексеру: толықтығы, дұрыстығы, дәйектілігі
  • Кодтық көрсеткіштерді талдау
  • Кодтау стандарттарының сәйкестігін тексеру

Тексеру

  • Тұрақсыз компоненттерді / функционалдылықты анықтау
  • Тексеру қателіктермен жұмыс істеуге бағытталған: даму тобы орындағанға қатысты қосымша (бір уақытта емес!) Тексеру (ақша үшін көбірек, уақыт үшін көбірек)
  • Бағдарламалық жасақтама мен жүйелік талаптарға сәйкестігі
  • Қара жәшікті тестілеу және Ақ жәшікті сынау техникасы
  • Тәжірибеге негізделген әдістер

Нормативті орта

Тексеру және валидация көбіне мемлекеттік органдар басшылыққа алатын заңнамамен реттелетін салалардың сәйкестігі талаптарына сәйкес келуі керек[6][7] немесе өндірістік әкімшілік органдар. Мысалы, FDA бағдарламалық жасақтама нұсқаларын және патчтар тексерілуі керек.[8]

Сондай-ақ қараңыз

Ескертпелер мен сілтемелер

  1. ^ Фам, Х (1999). Бағдарламалық жасақтама сенімділігі. John Wiley & Sons, Inc. б. 567. ISBN  9813083840. Бағдарламалық жасақтаманы растау. Бағдарламалық жасақтаманың дұрыс процесті жүзеге асыруын қамтамасыз ету процесі. Бағдарламалық жасақтаманы растау. Бағдарламалық жасақтама процестің дұрыс орындалуын қамтамасыз ету процесі. «Сол сияқты және сол жерде:» Қысқаша айтқанда, Boehm (3) бағдарламалық жасақтаманы тексеру мен бағдарламалық жасақтаманы растау арасындағы айырмашылықты төмендегідей білдірді: Тексеру: '' Біз өнімді дұрыс құрамыз ба? ? '' Тексеру: '' Біз дұрыс өнім жасаймыз ба? ''.
  2. ^ а б c «Модельдер мен модельдеуге арналған верификация, валидация және аккредиттеу (VV&A) қорғаныс құжаттамасы бөлімі». Зымыранға қарсы қорғаныс агенттігі. 2008 ж. Журналға сілтеме жасау қажет | журнал = (Көмектесіңдер)
  3. ^ Ванг, С-Ж .; Остроф, Дж .; Худон, С. (2014). «Нақты құжаттама және талаптарды растау». Арто, С .; Өлвечки, П.К. (ред.). Қауіпсіздік-сыни жүйелердің формальды әдістері. Спрингер. 262–279 бет. ISBN  9783319054162. Алынған 18 мамыр 2018.
  4. ^ Купман, П. «Күнделікті енгізілген жүйелердегі сенімділік, қауіпсіздік және қауіпсіздік». Бондавеллиде А .; Бразилейро, Ф .; Раджсбаум, С. (ред.) Тәуелді есептеулер. Спрингер. дои:10.1007/978-3-540-75294-3_1. ISBN  978-3-540-75294-3.
  5. ^ SoftWcare SL веб-сайты
  6. ^ «Бағдарламалық жасақтаманы растаудың жалпы қағидалары; өнеркәсіп және FDA персоналы үшін қорытынды нұсқаулық» (PDF). Азық-түлік және дәрі-дәрмектерді басқару. 11 қаңтар 2002 ж. Алынған 12 шілде 2009.
  7. ^ «Өнеркәсіпке басшылық: 11 бөлім, электрондық жазбалар; электрондық қолтаңба - қолдану аясы және қолдану» (PDF). Азық-түлік және дәрі-дәрмектерді басқару. Тамыз 2003. Алынған 12 шілде 2009.
  8. ^ «Өнеркәсіпке арналған нұсқаулық: сөреде (OTS) бағдарламалық жасақтаманы қамтитын желілік медициналық құрылғыларға арналған киберқауіпсіздік» (PDF). Азық-түлік және дәрі-дәрмектерді басқару. 14 қаңтар 2005 ж. Алынған 12 шілде 2009.

Сыртқы сілтемелер