Ընդունման թեստի սահմանում. Փաստաթղթերի մշակում, նախատիպերի արտադրություն և փորձարկում: Ավտոմատացված համակարգերի ստանդարտների հավաքածու

Սովորաբար այս թեստավորումն իրականացվում է մեկ այլ թիմի կողմից, որը կրկնում է շատ բաներ, որոնք ծածկված են ավտոմատ ընդունման թեստում ձեռքով կամ մեկ այլ գործիքով: Դա կարող է արվել, քանի որ ընդունման թեստերը չեն կարող հեշտությամբ իրականացվել տարբեր միջավայրերում, կամ մշակող թիմը չի կարող հեշտությամբ հասկանալ, թե ինչ են անում թեստերը, և օգտագործված տվյալները թաքնված են կոդի մեջ, ինչը դժվարացնում է գտնելը կամ փոխելը: Թեստի մտադրությունը կոդի մեջ թաքցնելը դժվարացնում է հասկանալ, թե ինչ է փորձում անել թեստը:

Դա նաև նշանակում է, որ ոչ տեխնիկական թիմի անդամները չեն կարող հեշտությամբ նպաստել թեստավորմանը, և տեխնիկական մարդիկ ավելի շատ ժամանակ են ծախսում ավտոմատացված թեստային ծածկագրի վրա: Երբ թեստերը պետք է վերամշակվեն, ինչն անխուսափելի է, որ դրանք առանձնացնեն մտադրությունը իրականացման միջոցներից, դուք կարող եք կենտրոնանալ թեստի կատարման վերակառուցման վրա, այլ ոչ թե թեստը պետք է անի:

Մտադրության, իրականացման և տվյալների տարանջատում

Ստորև բերված է դիագրամ, որը ցույց է տալիս մտադրությունը, իրականացումը և տվյալները տարանջատելու գաղափարը: Ներառված է նաև միջավայրը, քանի որ կարևոր է հասկանալ, թե ինչ միջավայրում են իրականացվելու թեստերը և, անհրաժեշտության դեպքում, փոխել տվյալները և կատարել թեստը: Մտադրություն ստեղծելը կարող է իրականացվել ոչ տեխնիկական թիմի անդամների կողմից՝ իրականացումից անկախ լեզվով: Սա կարևոր է, քանի որ նշանակում է, որ իրականացումը կարող է վերամշակվել առանց թեստի նպատակը փոխելու: Ճիշտ է նաև հակառակը. հնարավոր է փոխել թեստի մտադրությունը՝ չազդելով իրականացման վրա, պայմանով, որ կա իրականացում, որը բավարարում է մտադրության պարբերության բոլոր բառերը:

Եթե, վատագույն դեպքում, որոշեք դուրս նետել ամբողջ իրականացումը և սկսել նորից, դուք դեռ կարող եք պահպանել թեստի նպատակը և, հետևաբար, չկորցնել ավտոմատացված թեստերի ամենակարևոր մասը, թե ինչն է փորձում անել: Տվյալները նույնպես պետք է բաժանվեն մտադրությունների և իրականացումների: Դրանով տվյալները կարող են ճշգրտվել թեստում վերացական եղանակով, այնուհետև իրականացումը հեռացնել: Օրինակ, թեստը կարող է ցույց տալ «Gold Client», քանի որ հաճախորդը նույնականացվում է, թեստի մաս չէ, այլ տվյալների շերտի մաս է:

Տվյալների շերտի ստեղծումը և տվյալների աբստրակցիան նոր տեխնիկա չեն. դրանք սովորաբար օգտագործվում են կիրառական ծածկագրի համար և պետք է կիրառվեն ավտոմատացված թեստերի համար, քանի որ առավելությունները դեռևս կիրառվում են: Փորձարկման դեպքում տվյալների շերտը կոչված է տվյալների աղբյուրից տվյալներ ստանալու համար համապատասխան հաճախորդի տեսակի համար:

Թեստային դեպքն այնուհետև կրկնվում է ցանկի բոլոր գրառումների վրա և կատարում է թեստ յուրաքանչյուր հաճախորդի մուտքի վերաբերյալ: Համակարգի թեստերը համապատասխանում են ծրագրային ապահովման փորձարկման մակարդակներից մեկին՝ զուգակցված տարբեր թեստերի հետ, ինչպիսիք են վերականգնումը, անվտանգությունը, ճկունությունը, կատարումը, կապը, ծավալը, լարումը, տվյալների հասանելիությունը, օգտագործման հեշտությունը, շահագործումը, Շրջակա միջավայր, պահեստավորում, կոնֆիգուրացիա, տեղադրում և փաստաթղթեր: Յուրաքանչյուրն ունի տարբեր նպատակ և ունի ընդհանուր նպատակ, որը ցույց է տալիս ծրագրի համակարգված տեսլականը: Ընդունման թեստավորումը մակարդակի ևս մեկ տեսակ է, որը լրացվում է ծրագրային ապահովման թեստի մակարդակներով, այս թեստերը շատ հիմնարար են, քանի որ դրանք են, որոնք թույլ կտան մեզ ստանալ այնպիսի ապրանք, որը համապատասխանում է պահանջվող չափանիշներին և միաժամանակ բավարարում է օգտատերերի պահանջները՝ համաձայն ս.թ. պահանջներ, որոնք նրանք բարձրացրել են հենց սկզբից: Սա ստիպում է համակարգին փորձարկել կենսական թեստավորման գործընթացը, քանի որ արտադրանքի, վրիպակների քանակի և այդ վրիպակների ծանրության առումով, դա զարգացման այն քայլն է, որը սովորաբար հակված է վրիպակների մեծամասնությանը: Նկար 1. Կրկնվող համակարգերի ստուգում Համակարգի թեստերը գործընթացներ չեն համակարգի ֆունկցիոնալությունը ստուգելու համար կամ ամբողջական ծրագիր, քանի որ դա ավելորդ կլինի ֆունկցիոնալ փորձարկման գործընթացում: Համակարգի թեստերն ունեն որոշակի նպատակ՝ համեմատել համակարգը կամ ծրագիրը իր սկզբնական նպատակներին: Այդ նպատակով ներկայացված են երկու արժեք. Համակարգի փորձարկումը չի սահմանափակվում միայն համակարգերով: Եթե ​​արտադրանքը ծրագիր է, ապա համակարգի թեստավորումը փորձ է ցույց տալու, թե ինչպես է ծրագիրը լիովին չի համապատասխանում իր նպատակներին կամ պահանջներին: Համակարգի փորձարկումները, ըստ սահմանման, հնարավոր չեն, եթե չկան գրավոր պահանջներ, որոնք չափելի են արտադրանքի համար: Համակարգի փորձարկումը հետազոտության փուլն է, որտեղ այն ապահովում է, որ յուրաքանչյուր բաղադրիչ կամ մոդուլ փոխազդում է այլ բաղադրիչների կամ մոդուլների հետ, ինչպես նախատեսված է: Համակարգի թեստերն ուղղված են համակարգի խորը ներդրմանը, ամբողջ աշխարհում տեղեկատվական համակարգի ինտեգրման ստուգմանը, այն կազմող տարբեր ենթահամակարգերի և այլ տեղեկատվական համակարգերի միջև, որոնց հետ այն շփվում է միջերեսների ճիշտ աշխատանքը: Դասական համակարգի փորձարկման խնդիրը «մատը ցույց տալն է»: Դա տեղի է ունենում, երբ հայտնաբերվում է սխալ, և յուրաքանչյուր համակարգի տարրի մշակողը մեղադրում է ուրիշներին: Այս աբսուրդի մեջ ընկնելու փոխարեն ծրագրային ապահովման ինժեները պետք է կանխատեսի հնարավոր խնդիրներինտերֆեյսի միջոցով. Համակարգի փորձարկում և փորձարկում 6  Կիրառել մի շարք թեստեր, որոնք նմանակում են վատ տվյալներ կամ այլ հնարավոր սխալներծրագրային ապահովման ինտերֆեյսում:  Մեղավորության դեպքում որպես ապացույց գրանցել թեստի արդյունքները.  Մասնակցեք համակարգի թեստավորման պլանավորմանն ու զարգացմանը՝ համոզվելու համար, որ ծրագրաշարը պատշաճ կերպով փորձարկվել է: Փաստորեն, համակարգի թեստը ներառում է մի շարք տարբեր թեստեր, որոնց հիմնական նպատակն է խորը հաշվարկել համակարգը, երբ այն հաշվարկվում է: Չնայած յուրաքանչյուր թեստ ունի տարբեր նպատակ, դրանք բոլորն աշխատում են համոզվելու, որ համակարգի բոլոր տարրերը պատշաճ կերպով ինտեգրված են և կատարում են համապատասխան գործառույթները: 2 Թեստի համակարգի վերանայում: Երբ պետք է փորձարկում իրականացվի, անհրաժեշտ է պահպանել համակարգեր, այսինքն՝ ծրագրային ապահովման մշակման անբաժանելի մոտեցում: Ծրագրային ապահովման թեստում այս հասկացությունների կիրառումը տալիս է մի շարք սկզբունքներ, որոնք հիմք կծառայեն թեստի համար. դուք պետք է համոզվեք, որ ճշգրիտ գիտեք փորձարկվող ծրագրաշարի նպատակները, ինչպես նաև ձեր հաջողության մակարդակը: Այս տարրերը հայտնաբերվել են պահանջների հավաքման փուլում ձեռք բերված փաստաթղթերում, ինչպես նաև ծրագրային ապահովման բնութագրերում: Այս տեղեկատվությունը անհրաժեշտ կլինի թեստավորման պլանը պատրաստելու համար և հիմք կհանդիսանա թեստային դեպքի մշակման համար: Հաստատված համակարգի մուտքերն ու ելքերը պետք է սահմանվեն: Այս ասպեկտն անհրաժեշտ է թեստային դեպքերի պատրաստման, ինչպես նաև թեստային ընթացակարգերի ստեղծման ժամանակ, հատկապես թեստային դեպքերի վրա հիմնված, որոնք ցույց են տալիս նպատակների կատարումը: Դիտարկենք հիմնական համակարգը, որի վրա աշխատում է փորձարկվող ծրագրաշարը: Սովորաբար դա կազմակերպչական միջավայր է, որը բաղկացած է սարքաշարից, ծրագրային ապահովումից և մարդկանցից: Այս բոլոր տարրերը մեծ ազդեցություն ունեն համակարգի վրա և հատկապես օգնում են անցանկալի իրավիճակների թեստային դեպքերի նախապատրաստմանը, որոնք կապված են անբավարար տվյալների, անբավարար տվյալների հետ: անհրաժեշտ տարրերև բացառությունների առաջացումը: 3 Համակարգի թեստավորման ընդհանուր պատկերացում Համակարգի փորձարկման գործընթացը բաղկացած է երկու փուլից, որոնք ժամանակի ընթացքում կարող են լինել շատ առանձին՝ թեստի պատրաստում և թեստի կիրառում: Առաջինը սերտորեն կապված է պահանջների հետ, ուստի այն տեղի է ունենում նախագծի սկզբում, իսկ երկրորդը պահանջում է ամբողջական համակարգը կամ առնվազն մեկ ինտեգրում, քանի որ մասնակի արտադրանքը, ասվում է, չի թողարկվել, որպեսզի կարողանա կիրառել թեստեր, այնպես որ դա տեղի է ունենում ծրագրի առաջադեմ փուլերում: նախագիծը։ Այս մասերի ճշգրիտ իրավիճակը կախված է ընտրված մոդելից: կյանքի ցիկլ. Երկրորդ և երրորդ գործողությունները կատարելու համար պահանջվում է պահանջների փաստաթուղթ: Թեստավորման առաջին փուլը տրամադրում է հետադարձ կապ՝ պահանջները վերլուծելու, բացերը, երկիմաստությունները և այլ հարցեր հայտնաբերելու համար: Այն նաև տալիս է արժեքավոր խորհուրդներ համակարգի նախագծման և իրականացման վերաբերյալ, եթե դուք նոր եք մշակում: Փորձարկման կիրառման փուլը պահանջում է թեստային պլան և գործարկվող համակարգի տարբերակ: Այս դեպքում կկիրառվեն թեստային գործերը, որոնք պատրաստվել են, արդյունքները կվերլուծվեն և կբացահայտվեն ցանկացած թերություն: Այս երկրորդ քայլը տրամադրում է հետադարձ կապ իրականացման և նախագծման վերաբերյալ՝ ցույց տալով հնարավոր թերությունները, որոնք պետք է շտկվեն: Այն նաև տրամադրում է տեղեկատվություն, որն օգտակար կլինի համակարգը թողարկելու, այն ընդունելու, հուսալիությունը գնահատելու և պահպանելու համար: Նկար 1-ը ցույց է տալիս համակարգի փորձարկման գործընթացը և դրա կապը այլ գործընթացների հետ: Երկրորդ կետը կարևոր է, քանի որ երբեմն համակարգի թեստը շփոթում են ինտերֆեյսի թեստի հետ: Առաջինը ստուգում է բոլոր մասերի փոխազդեցությունը, իսկ երկրորդը վերլուծում է միջերեսի տարրերը և, հնարավոր է, հարակից իրադարձությունների մշակումը: Այնուամենայնիվ, գործիքները, որոնք օգնում են ստուգել ինտերֆեյսը, կարող են օգտագործվել համակարգի թեստերը գործարկելու համար: Մի քանի հարց է առաջանում՝ քանի՞ դեպք կբավարարի։ Ինչպե՞ս ստեղծել հնարավորինս նվազագույնը: Ի՞նչ արժեքներ են հարմար: Համակարգի փորձարկում և փորձարկում 9 1 Փորձարկման պլան Փորձարկման պլանը շատ է կարևոր փաստաթուղթծրագրային ապահովման փորձարկման ժամանակ: Այն բացատրում է թեստավորման նպատակներն ու մոտեցումները, աշխատանքային պլանը, գործառնական ընթացակարգերը, անհրաժեշտ գործիքներև պարտականություններ։ Համակարգի փորձարկում և փորձարկում 10. Պահանջների փաստաթուղթը պետք է պարունակի ծրագրաշարի կողմից կատարվող գործառույթների ցանկը՝ դրանք նկարագրելով և առաջնահերթություն տալով. այն պետք է ներառի նաև ոչ գործառական պահանջներ, որոնք կարող են ներառել կազմակերպչական, գործառնական և այլ ասպեկտներ: Պահանջների լավ պատրաստված փաստաթուղթը պետք է հնարավորություն տա յուրաքանչյուր պահանջի ստուգման, որ այն բավարարված է: Առանձնահատկությունների դեպքում սա նկարագրություն կլինի, իսկ ոչ ֆունկցիոնալ պահանջների դեպքում դա կարող է լինել շատ ճշգրիտ բնութագրեր, ինչպիսիք են արձագանքման ժամանակը: Առայժմ մենք կկենտրոնանանք ֆունկցիոնալ պահանջների վրա՝ մնացածը թողնելով հետագա բաժնի համար: Համակարգի թեստերը կարևոր են հետևյալ գործոնների պատճառով.  Համակարգը ստուգվում է իր ֆունկցիոնալ և տեխնիկական պահանջներ .  Համակարգը փորձարկվում է արտադրական միջավայրին հնարավորինս մոտ միջավայրում:  Համակարգի թեստերը թույլ են տալիս ստուգել, ​​վավերացնել և վավերացնել ինչպես բիզնեսի պահանջները, այնպես էլ կիրառական ճարտարապետությունը: 6 Համակարգի թեստերի տեսակը Ֆունկցիոնալ թեստեր  Ինտեգրման թեստ. - Որում փորձարկման սարքավորումն ունի մուտք դեպի համակարգի սկզբնական կոդը: Երբ խնդիր է հայտնաբերվում, ինտեգրման թիմը փորձում է գտնել խնդրի աղբյուրը և որոշել այն բաղադրիչները, որոնք պետք է վրիպազերծվեն: Ինտեգրման թեստավորումը հիմնականում կապված է համակարգում թերությունների հայտնաբերման հետ:  Առաքման ապացույց. Ահա համակարգի այն տարբերակը, որը կարող է առաքվել օգտատիրոջը: Այստեղ թեստային թիմը մտահոգված է ստուգելու, որ համակարգը համապատասխանում է իր պահանջներին և երաշխավորում է համակարգի հուսալիությունը: Առաքման թեստերը սովորաբար սև տուփի թեստավորում են, որոնցում փորձարկման սարքավորումը պարզապես մտահոգված է համակարգի պատշաճ գործունեությամբ: Բաղադրիչները, որոնք կարող են ինտեգրվել, կարող են լինել առևտրային բաղադրիչներ, որոշակի համակարգին հարմարեցված բազմակի օգտագործման բաղադրիչներ կամ նոր մշակված բաղադրիչներ: Շատ խոշոր համակարգերի համար նրանք հավանաբար կօգտագործեն բոլոր երեք տեսակի բաղադրիչները: Ինտեգրման թեստը ստուգում է, որ այս բաղադրիչներն իրականում աշխատում են միասին, ճիշտ են կանչվում և ճշգրիտ տվյալներ են փոխանցում իրենց միջերեսներով: Համակարգի ինտեգրումը ներառում է բաղադրիչների խմբերի նույնականացում, որոնք ապահովում են համակարգի որոշ ֆունկցիոնալություն և ինտեգրում դրանք՝ ավելացնելով կոդեր՝ միասին աշխատելու համար: Երբեմն ամբողջ համակարգի կմախքը առաջինն է մշակվում, և բաղադրիչներն ավելացվում են: Սա կոչվում է հետինտեգրացիա: Սա դեպի վեր ինտեգրացիա է: Գործնականում, շատ համակարգերի համար ինտեգրման ռազմավարությունը երկուսի համակցությունն է՝ ավելացնելով ենթակառուցվածքի լրացուցիչ բաղադրիչներ և ֆունկցիոնալ բաղադրիչներ: Ինտեգրման երկու մոտեցումներն էլ պահանջում են լրացուցիչ կոդ՝ այլ բաղադրիչներ մոդելավորելու և համակարգը գործարկելու հնարավորություն տալու համար: Ինտեգրման թեստերի ժամանակ հանդիպող հիմնական դժվարությունը սխալների տեղակայումն է: Համակարգի բաղադրիչների միջև կան բարդ փոխազդեցություններ, և երբ հայտնաբերվում է անոմալ ելք, կարող է դժվար լինել որոշել, թե որտեղ է տեղի ունեցել սխալը: Սխալների մեկուսացումն ավելի հեշտ դարձնելու համար դուք միշտ պետք է օգտագործեք համակարգային ինտեգրման և փորձարկման աստիճանական մոտեցում: Այս գործընթացի հիմնական նպատակն է բարձրացնել մատակարարի վստահությունը, որ համակարգը համապատասխանում է իր պահանջներին: Եթե ​​այո, ապա այն կարող է առաքվել որպես ապրանք կամ առաքվել հաճախորդին: Ցույց տալու համար, որ համակարգը համապատասխանում է իր պահանջներին, պետք է ապացուցվի, որ այն ապահովում է նշված ֆունկցիոնալությունը, կատարումը և հուսալիությունը, և որ այն չի խափանում սովորական օգտագործման դեպքում: Առաքման թեստերը սովորաբար սև տուփի փորձարկման գործընթաց են, որոնցում թեստերը բխում են համակարգի բնութագրերից: Համակարգը դիտվում է որպես սև արկղ, որի վարքագիծը պետք է որոշվի միայն դրա համապատասխան մուտքերն ու ելքերը ուսումնասիրելով: Սրա մեկ այլ անուն է ֆունկցիոնալ թեստավորում, քանի որ փորձարկողին հետաքրքրում է միայն ֆունկցիոնալությունը, այլ ոչ ծրագրաշարի իրականացումը: Հետևյալ նկարում մենք կտեսնենք համակարգի մոդելի նկարազարդումը, որը թույլ է տալիս վավերացնել սև արկղում: Փորձարկիչը ներկայացնում է ներածումներ բաղադրիչի կամ համակարգի համար և հաշվի է առնում մուտքերը: Որոշ դեպքերում համակարգը պետք է լինի անսարքության հանդուրժող. այսինքն՝ մշակման խափանումները չպետք է հանգեցնեն ամբողջ համակարգի խափանումներին։ Փորձարկման համակարգեր և ընդունման թեստեր 14 Համակարգի խափանումը պետք է շտկվի որոշակի ժամանակահատվածում, այլապես լուրջ տնտեսական վնաս կհասցնի: Վերականգնման թեստը համակարգային թեստ է, որը հանգեցնում է ծրագրաշարի ձախողման մի քանի ձևերով և ստուգում է, որ վերականգնումը ճիշտ է կատարվում: Եթե ​​վերականգնումը տեղի է ունենում ինքնաբերաբար, դուք պետք է ստուգեք, թե արդյոք վերսկսումը, համակարգի պահուստավորման մեխանիզմները, տվյալների վերականգնումը և վերագործարկումը ճիշտ են: Եթե ​​վերականգնումը պահանջում է մարդու միջամտություն, ապա վերականգնման միջին ժամանակը պետք է որոշվի՝ որոշելու համար, թե արդյոք այն գտնվում է ընդունելի սահմաններում: Նպատակն է սահմանել վերջնակետեր, որտեղ համակարգը սկսում է գործել սահմանված պահանջներից ցածր: Սա չպետք է շփոթել ծավալի թեստի հետ. բարձր լարումը տվյալների կամ գործունեության առավելագույն քանակն է կարճ ժամանակ. Նմանությունը կլինի մեքենագրուհուն գնահատելը: Կորոշվի ծավալի թեստ, եթե մեքենագրողը բախվի մեծ հաշվետվության նախագծին. սթրես-թեստը կորոշի, թե արդյոք մեքենագրողը կարող է մուտքագրել րոպեում 50 բառ ինդեքսով: Խախտումը ներառում է գործունեության լայն շրջանակ.  Հաքեր, ով փորձում է մուտք գործել յուրաքանչյուր խաղում: Անվտանգության թեստը ստուգում է, որ համակարգում ներկառուցված անվտանգության մեխանիզմներն իրականում պաշտպանում են այն ոչ պատշաճ ներխուժումներից: «Համակարգերը պետք է փորձարկվեն, որպեսզի համակարգի անվտանգությունն անձեռնմխելի լինի ճակատային հարձակումներից, բայց նաև նրանցից, ովքեր կատարում են եզրեր կամ թիկունք»: Անվտանգության թեստի ընթացքում յուրաքանչյուր ոք, ով կիրառում է այն, խաղում է այն անձի դերը, ով ցանկանում է մուտք գործել: Այս ամենը արժե այն: Դուք պետք է փորձեք ստանալ ցանկացած գաղտնաբառ արտաքին միջոցներ; կարող է հարձակվել համակարգի վրա՝ օգտագործելով հատուկ ծրագրակազմ, որը նախատեսված է ցանկացած պաշտպանված ճարտարապետություն շրջանցելու համար. նա կարող է հագեցնել համակարգը՝ դրանով իսկ հրաժարվելով ուրիշներին ծառայությունից. կարող է հանգեցնել համակարգում կանխամտածված սխալների՝ վերականգնման ընթացքում մուտք գործելու փորձի համար. դուք կարող եք դիտել տվյալները առանց պաշտպանության՝ համակարգի գաղտնաբառ որոնելու գաղափարով: Եթե ​​բավականաչափ ժամանակ և ռեսուրսներ տրվեն, համակարգը ի վերջո կանի լավ թեստանվտանգության համար։ Համակարգի նախագծողի դերն այն է, որ ընդհատման արժեքը ավելի մեծ է, քան ստացված տեղեկատվության արժեքը: Այնուամենայնիվ, մարդկային գործոնների վերլուծությունը մնում է խիստ սուբյեկտիվ խնդիր: Փորձարկման դեպքերը նախատեսված են ցույց տալու, որ պահեստավորման այս թիրախները չեն գտնվել: Հաճախ հնարավոր կոնֆիգուրացիաների թիվը չափազանց մեծ է յուրաքանչյուրը փորձարկելու համար, բայց եթե հնարավոր է, դուք պետք է փորձարկեք ծրագիրը յուրաքանչյուր տեսակի ապարատային սարքի հետ և նվազագույն և առավելագույն կազմաձևերով: Եթե ​​ծրագիրն ինքնին կարող է կազմաձևվել բաղադրիչները բաց թողնելու համար, կամ եթե այն կարող է աշխատել մի քանի համակարգիչների վրա, ապա յուրաքանչյուր կոնֆիգուրացիա պետք է փորձարկվի: Տեղադրման ընթացակարգերի փորձարկումը համակարգի փորձարկման գործընթացի կարևոր մասն է: Սա հատկապես ճիշտ է համակարգի համար ավտոմատ տեղադրում ներառված է ծրագրային փաթեթում: Սխալ գործարկվող տեղադրիչը կարող է խանգարել օգտվողին համակարգի հետ հաջող փորձ ունենալուց: Օգտագործողի առաջին փորձն այն է, երբ նա տեղադրում է հավելվածը: Դրան հասնելու ուղիներից մեկը փաստաթղթերի օգտագործումն է՝ համակարգի նախորդ փորձարկման դեպքերի տեսքը սահմանելու համար: Այսինքն, երբ դուք ցանկանում եք մշակել ծանրաբեռնված դեպք, դուք պետք է օգտագործեք փաստաթղթերը որպես ուղեցույց իրական փորձարկման դեպքը գրելու համար: Բացի այդ, օգտագործողի փաստաթղթերը պետք է ենթարկվեն ստուգման՝ ճշգրտության և հստակության համար: Փաստաթղթերում ցուցադրված ցանկացած օրինակ պետք է փորձարկվի և ավելացվի անելիքների ցանկում և ներառվի ծրագրում: Համակարգի փորձարկում և փորձարկում 17 գործառնական տեսակետից, համակարգի ընդունումից հետո փաստացի միջավայրում և հիմնվելով սահմանված ոչ ֆունկցիոնալ պահանջների հետ համապատասխանության վրա: Դիմադրության թեստը նախատեսված է աննորմալ իրավիճակներում ծրագրերին դիմակայելու համար: Ըստ էության, դիմադրության թեստ կատարողը կհարցնի. Որքա՞ն հեռու եք այն հասնում մինչև այն ձախողվի: Դիմադրության թեստը համակարգն իրականացնում է այնպես, որ այն պահանջում է ռեսուրսների աննորմալ քանակություն, հաճախականություն կամ քանակություն: Օրինակ՝  Մշակվել են հատուկ թեստեր, որոնք առաջացնում են վայրկյանում 10 ընդհատում, երբ միջին բաժակը մեկ կամ երկու է:  Տվյալների մուտքագրման հաճախականությունը մեծանում է այն քանակով, որը թույլ կտա մուտքագրման գործառույթներին արձագանքել:  Գործարկել փորձնական դեպքեր, որոնք պահանջում են առավելագույն հիշողություն կամ այլ ռեսուրսներ:  Փորձարկման դեպքերը նախատեսված են հիշողության կառավարման խնդիրները լուծելու համար: Ստեղծվում են թեստային դեպքեր, որոնք առաջացնում են սկավառակի ավելորդ որոնումներ: Նկարը դիմադրության թեստի օրինակ է: Կատարման թեստը կիրառվում է թեստավորման գործընթացի բոլոր փուլերում: Նույնիսկ միավորի մակարդակով: Անհատական ​​մոդուլի կատարումը պետք է գնահատվի թեստավորման ընթացքում: Այնուամենայնիվ, միայն այն բանից հետո, երբ համակարգի բոլոր տարրերը լիովին ինտեգրված են, կարող է հասնել համակարգի իրական կատարողականությանը: Կատարողականության թեստերը հաճախ ներառում են դիմադրության փորձարկում և հաճախ պահանջում են ծրագրային և ապարատային հրահանգներ: Այսինքն՝ հաճախ անհրաժեշտ է լինում ճշգրիտ չափել ռեսուրսների օգտագործումը: Արտաքին գործիքների օգնությամբ դուք կարող եք պարբերաբար վերահսկել գործարկման ընդմիջումները, գրանցված իրադարձությունները և սարքաշարի նմուշների կարգավիճակը: Այս թեստերը կատարվում են այնպես, որ հաճախորդը հաստատի, որ համակարգը վավեր է իր համար: Այս թեստերի մանրամասն պլանավորումը պետք է իրականացվի զարգացման փուլում՝ նպատակ ունենալով օգտագործել արդյունքները՝ որպես դրանց վավերականության ցուցում. արտադրություն։ 6 Ընդունման թեստերը2 հիմնականում ֆունկցիոնալ թեստեր են ամբողջական համակարգի վրա և նպատակ ունեն ստուգել, ​​թե արդյոք դրանք սահմանված պահանջները . Հաճախորդի համար դրա կատարումը կամընտիր է, և եթե դրանք հստակորեն նշված չեն, դրանք ներառվում են համակարգի թեստերում: Այսինքն՝ ընդունման թեստերը հաճախ օգտատերի կամ հաճախորդի պատասխանատվությունն են, թեև բիզնեսում ներգրավված յուրաքանչյուրը կարող է դրանք կատարել: Ընդունման փորձարկումը պահանջում է փորձնական միջավայր, որը ներկայացնում է արտադրական միջավայրը: Այս փուլը կամ մակարդակը որպես մեկնարկային կետ սահմանում է արտադրանքի ընդունման ելակետը, որն արդեն հաստատված է սերտիֆիկացման միջավայրում: Համակարգի փորձարկում և ընդունում 19 Նկար - Ընդունման վերահսկում: 1 Ընդունելության թեստերում առկա իրավիճակի ուսումնասիրություն: Որպես թեստերի մի մաս, մենք պետք է ստուգենք ծրագրակազմը, ամենակարևորներից մեկը ընդունման թեստավորումն է: Սրանք այն թեստերն են, որոնք մշակվում են մշակողների թիմի կողմից՝ հիմնվելով վերլուծության փուլում նշված ֆունկցիոնալ պահանջների վրա, որպեսզի ընդգրկեն ամբողջ սպեկտրը և կատարվեն վերջնական օգտագործողի կողմից, բայց ոչ բոլորը, այլ մի քանի օգտվողներ ունեն նշանակալի արդյունք, որը տալիս է. վավերականություն և համապատասխանություն ապրանքին, որը նրանց է մատակարարվում սկզբնապես համաձայնեցվածի հիման վրա: Կախված փորձարկվող համակարգի բարդությունից՝ անկախ նրանից, թե այն բաժանված է մոդուլների և այլն։ այս թեստերի կատարումը կատարվում է այլ կերպ: Եթե ​​հայտը բաժանվեր մոդուլների, դրանք կդիտարկվեին որպես ենթահամակարգեր և բավական բարդ կլինեն, որպեսզի դրանք այլ կերպ վարվեին, պետք է անցկացվեին ընդունելության տարբեր թեստային նիստեր: 2 Ընդունման փորձարկման նպատակը Ընդունման փորձարկումը նպատակ ունի ստանալ վերջնական հաճախորդի ընդունումը մինչև ապրանքի առաքումը, որպեսզի այն մտնի արտադրություն: Երբ կազմակերպությունն իրականացրել է համակարգի թեստեր և ուղղել իր թերությունների մեծ մասը, համակարգը կհանձնվի օգտագործողին կամ հաճախորդին հաստատման համար: Ընդունման թեստավորման նպատակն է ստուգել, ​​որ համակարգը համապատասխանում է ակնկալվող կատարողականին և թույլ է տալիս այդ համակարգի օգտագործողին որոշել դրա ընդունումը իր ֆունկցիոնալության և կատարողականի տեսանկյունից: Ընդունման թեստերը որոշվում են համակարգի օգտագործողի կողմից և պատրաստվում են մշակողների թիմի կողմից, թեև վերջնական կատարումը և հաստատումը կախված է օգտագործողից: Համակարգի վավերացումն իրականացվում է սև արկղի թեստերի միջոցով, որոնք ցույց են տալիս համապատասխանությունը և ներառված են փորձարկման պլանում, որը սահմանում է կատարվող վավերացումները և դրանց հետ կապված փորձարկման դեպքերը: Այս պլանը նախատեսված է ապահովելու, որ օգտագործողի կողմից սահմանված բոլոր գործառական պահանջները բավարարվեն, ինչպես նաև ոչ գործառական պահանջները՝ կապված աշխատանքի կատարման, համակարգի հասանելիության անվտանգության, տվյալների և գործընթացների, ինչպես նաև համակարգի տարբեր ռեսուրսների հետ, 3 Ընդունման փորձարկումների առաջացում: Համակարգը պետք է ընդունվի օգտագործողի կողմից: Այդ իսկ պատճառով, հիմնվելով համակարգի կառուցվածքային բնութագրերի վրա, վերլուծաբանը ստեղծում է թեստային դեպքերի մի շարք, որոնք պետք է անցնեն բավարար չափով: Քանի որ ընդունման թեստերը կարող են մշակվել նախագծման և պրակտիկ գործունեությանը զուգահեռ, նորմալ է, որ այդ գործողությունները սկսվեն վերլուծաբանի կողմից հենց Կառուցվածքային վերլուծության գործողությունն ավարտվի: 4 Ընդունման փորձարկման ռազմավարություններ Եթե համակարգը նախատեսված էր զանգվածային շուկայի համար, ապա գործնական չէր լինի այն փորձարկել առանձին օգտատերերի կամ հաճախորդների համար, որոշ դեպքերում դա հնարավոր չէր լինի: Այս դեպքերում հետադարձ կապը պահանջվում է նախքան ապրանքը վաճառքի հանելը: Հաճախ նման համակարգերն ունեն ընդունման փորձարկման երկու փուլ: Ալֆա և բետա փորձարկում Երբ հաճախորդի համար ստեղծվում է հատուկ ծրագրակազմ, կատարվում են մի շարք ընդունման թեստեր, որոնք թույլ են տալիս հաճախորդին ստուգել բոլոր պահանջները: Կատարվում է հաճախորդի կողմից զարգացման վայրում: Ծրագիրը բնականաբար օգտագործվում է մշակողի հետ՝ որպես օգտագործողի դիտորդ, գրանցման սխալների և օգտագործման հետ կապված խնդիրների հետ մեկտեղ: Ալֆա թեստերն անցկացվում են վերահսկվող միջավայրում: Դուք աշխատում եք վերահսկվող միջավայրում, և հաճախորդը միշտ ունի փորձագետ, որը կօգնի ձեզ օգտագործել համակարգը: Մշակողը հետևում է հայտնաբերված սխալներին և օգտագործման խնդիրներին: Β-բետա թեստերն անցկացվում են α-ալֆա թեստից հետո և մշակվում են հաճախորդի միջավայրում: Այս դեպքում հաճախորդը մենակ է մնում ապրանքի հետ և փորձում է գտնել սխալներ, որոնք տեղեկացնում են մշակողին: Դրանք իրականացվում են ծրագրաշարի վերջնական օգտագործողների կողմից հաճախորդի աշխատատեղերում: Ի տարբերություն ալֆա թեստի, մշակողը սովորաբար ներկա չէ: Այսպիսով, բետա թեստը ծրագրաշարի կենդանի կիրառությունն է այնպիսի միջավայրում, որը չի կարող վերահսկվել մշակողի կողմից: Հաճախորդը գրանցում է բոլոր խնդիրները, որոնք առաջանում են բետա թեստավորման ժամանակ և պարբերաբար զեկուցում է մշակողներին: 5 Ընդունման թեստի մուտքեր, ելքեր, առաջադրանքներ և դերեր: Մուտքի պահանջների ճշգրտում. Առաջադրանքներ Պատրաստել թեստային միջավայրը: Մենք խորհուրդ ենք տալիս ունենալ հատուկ թեստային միջավայր այս տեսակի թեստավորման համար: Տեղադրում թեստային միջավայրում: Համակարգի փորձարկում և փորձարկում 22 Որոշեք կատարվող թեստերը: Հնարավոր կախվածությունները, որոնք կան թեստերի միջև, կհաստատվեն, և թեստերի կատարման կարգը կամ հաջորդականությունը կհաստատվի այդ կախվածությունների հիման վրա: Արդյունքների ընդունում և գրանցում: Շտկվել են սխալներ և սխալներ: Կրկնեք առաջադրանքը, մինչև անցնեք բոլոր թեստերը: Ընդունման թեստի զեկույցի պատրաստում: Բոլոր ներկայացված թեստերի ճիշտ կատարման և արդյունքների ակնարկ: Արտադրական բազայի ստեղծում. Գործունեության պաշտոնական փակում. Թեստի արդյունքները. Ընդունված արտադրանքի ընդունման հաշվետվություն: Ծրագրի ղեկավար. Ընդունման թեստավորման վրա կենտրոնացումը կապված է այն կարծիքի ամրապնդման փորձի հետ, որ այս փուլում ինտեգրված օգտվողը, վաղ փուլում, կօգնի բարելավել այս գործընթացը թեստի պլանավորման և նախագծման փուլում՝ հետագա բարելավումներով բազմաթիվ քանակական և ցանկալի ասպեկտներով: Ինտեգրված ծրագրային ապահովման անվտանգության որակի բարելավում: Ծախսերի նվազեցում. Ծրագրի արդյունքների հուսալիության բարձրացում: Ավելի քիչ սխալներով ծրագրակազմ օգտագործելիս հաճախորդի գոհունակության աճ է նկատվում: Սա բարելավում է զարգացման գործընթացի արդյունավետությունը: 7 Ընդունման թեստավորման չափանիշներ. Ծրագրաշարի ընդունումը ձեռք է բերվում մի շարք թեստերի միջոցով, որոնք ցույց են տալիս, որ դրանք համապատասխանում են պահանջներին: Փորձարկման պլանը նկարագրում է կիրառվելիք թեստի տեսակը, և փորձարկման ընթացակարգը սահմանում է փորձարկման հատուկ դեպքեր, և՛ պլանը, և՛ ընթացակարգը նախատեսված են ապահովելու համար, որ դրանք բավարարեն բոլոր ֆունկցիոնալ պահանջներին, որ վարքագծի բոլոր բնութագրերը ձեռք բերվեն, կատարման բոլոր պահանջները բավարարվեն, փաստաթղթեր: ճիշտ է և հետևել է օգտագործման հարմարավետության և այլ պահանջներին սահմանված պահանջները. 8 Գործիքներ ընդունելության թեստերի համար: Սա թույլ է տալիս հաճախորդներին, փորձարկողներին և ծրագրավորողներին իմանալ, թե ինչ պետք է անի իրենց ծրագրաշարը և ավտոմատ կերպով համեմատեն այն, ինչ իրականում անում է: Թույլ է տալիս գրել թեստեր, որոնք հեշտ է կարդալ և հեշտ պահպանել: Այս գործունեությունը հայտնի է որպես վերջնական թեստ կամ ընդունման թեստ: Սա պահանջում է ընդունելության թեստի տվյալների մուտքագրում և այս գործունեության ընթացքում ստեղծված ինտեգրված համակարգ: Թեստը կանցկացվի օգտագործողի որոշ անդամի կամ բաժնի կամ նույնիսկ որակի վերահսկողության անկախ բաժնի կողմից: Կարևոր է նշել, որ նախորդ վերլուծական, նախագծման և իրականացման գործողություններից յուրաքանչյուրում կարևոր է որակի վերահսկման աշխատանքներ իրականացնել՝ ապահովելու համար, որ դրանք իրականացվել են որակի համապատասխան մակարդակով: Սա ապահովում է, որ վերլուծաբանը արտադրում է որակի բնութագրեր, որ դիզայները արտադրում է որակյալ նմուշներ, և որ ծրագրավորողը արտադրում է որակյալ կոդավորման ծրագրեր: Համակարգչային գիտության մեջ իրականացումը տեխնիկական բնութագրում կամ ալգորիթմ է, օրինակ՝ ծրագիր, ծրագրային բաղադրիչ կամ այլ համակարգչային համակարգ: Բազմաթիվ իրականացումներ տրամադրվում են ըստ հստակեցման կամ ստանդարտի: Մենք ամփոփում ենք հեղինակների նախորդ աշխատանքը՝ ձեռք բերելու թեստային նպատակներ, որոնք ավտոմատ թեստեր մշակելու մեկնարկային կետն են։ Օգտագործման դեպքերից համակարգի փորձարկման համատեքստում փորձարկման նպատակը կարող է արտահայտվել որպես օգտագործման դեպք: Այս սցենարը բաղկացած կլինի քայլերի հաջորդականությունից՝ առանց հնարավոր այլընտրանքի, և մի շարք թեստային արժեքների, և նախադրյալներև այս սցենարի հետ կապված հետկոնֆերանսներ: Փորձարկման սցենարներ ստեղծելու համար նախ ստեղծվում է գործունեության սխեման հիմնական հաջորդականությունից և օգտագործման դեպքի սխալներից ու այլընտրանքային հաջորդականություններից: Գործունեության դիագրամում համակարգի կողմից իրականացվող գործողությունները և մասնակիցների կատարած գործողությունները կարծրատիպային են: Այնուհետև կատարվում է ուղու վերլուծություն, և գործունեության գծապատկերի յուրաքանչյուր ուղի կլինի օգտագործման դեպքի սցենար և, հետևաբար, փորձարկման հավանական թիրախ: 2 Համակարգի թեստերի իրականացում. Համակարգի փորձարկման ճարտարապետություն. Համակարգի թեստերի կատարման և ավտոմատ վավերացման ճարտարապետությունը ներկայացված է Նկար 7-ում: Այս ճարտարապետությունը նման է այլ տեսակի թեստերի ավտոմատացման համար անհրաժեշտ ճարտարապետությանը, ինչպիսիք են միավորի թեստերը: Հիմնական տարբերությունն այն է, որ միավորի թեստում թեստն ինքնին անվանում է գործարկվող կոդը, մինչդեռ թեստային համակարգի ֆունկցիոնալ թեստը և թեստի ընդունումը 27 պահանջում է միջնորդ, որը գիտի, թե ինչպես կառավարել իր արտաքին ինտերֆեյսը: Փորձարկման դեպքերի իրականացում. Թեստ-թեստը թեստավորման նպատակի իրականացումն է: Փորձնական դեպքի ընդհանուր վարքագիծը թվարկված է Ընդհանուր փորձարկման դեպքի վարքագիծ աղյուսակում: Յուրաքանչյուր օգտագործման դեպք կապված կլինի թեստային փաթեթի հետ: Այս փաթեթը կպարունակի թեստեր նշված օգտագործման դեպքի բոլոր սցենարների համար: Ինչպես երևում է թեստի նպատակներից, յուրաքանչյուր քայլ պետք է հստակեցվի՝ արդյոք այն իրականացվում է գործող անձի կողմից, թե ստուգվող համակարգի կողմից: Այս տեղեկատվությունը շատ տեղին է փաթեթի փորձարկման մեթոդների կոդավորման ժամանակ: Դերակատարի կատարած բոլոր գործողությունները վերափոխում են թեստային կոդի ծածկագիրը փորձարկման դեպքի և համակարգի միջև փոխազդեցության: Համակարգի փորձարկում և ընդունման փորձարկում 29 Գործառնական և կատեգորիայի փոփոխական մեթոդաբանությունը կկիրառվի պահանջվող թեստի արժեքները որոշելու համար: Պարզվել է երեքի ինքնությունը տարբեր տեսակներգործառնական փոփոխականներ. Յուրաքանչյուր տեսակ փորձարկման դեպքերում կկիրառվի տարբեր կերպ: Առաջին տեսակը բաղկացած է այն գործառնական փոփոխականներից, որոնք ցույց են տալիս արտաքին սուբյեկտի կողմից տեղեկատվության փոխանցումը համակարգ: Այս տեսակի յուրաքանչյուր փոփոխականի համար կսահմանվի նոր դաս, որի օբյեկտները կպարունակեն տարբեր թեստային արժեքներ այս փոփոխականի համար: Այս տեսակի աշխատանքի փոփոխականի օրինակ է ցուցադրված դեպքի ուսումնասիրության մեջ: Երկրորդ տեսակը բաղկացած է այն գործառնական փոփոխականներից, որոնք ցույց են տալիս ընտրություն արտաքին դերակատարի համար հասանելի բազմաթիվ տարբերակների միջև: Փոխարենը, նման ընտրությունը կիրականացվի ուղղակիորեն որպես կոդի մաս, որն իրականացնում է դերակատարի և համակարգի փոխազդեցությունը: Երրորդ տեսակը բաղկացած է այն գործող փոփոխականներից, որոնք ցույց են տալիս համակարգի վիճակը: Փորձնական դեպքի տեղադրման մեթոդն իրականացնելու համար գրեք անհրաժեշտ կոդը՝ համակարգային վիճակները նկարագրող գործառնական փոփոխականների արժեքը ճիշտ սահմանելու կամ արժեքների համապատասխանությունը ստուգելու համար: Նմանապես, ընդմիջման մեթոդը պետք է վերականգնի այս արժեքները իրենց սկզբնական վիճակներին: Բացի այդ, հետագծման մեթոդը պետք է բացառի, անհրաժեշտության դեպքում, փորձարկման գործի կողմից համակարգ մուտքագրված տեղեկատվությունը փորձարկման գործի կատարման ընթացքում: Այս տեսակի գործառնական փոփոխականների մի քանի օրինակներ ներկայացված են դեպքի ուսումնասիրության մեջ: Այս դեպքում առաջին բանը, որ պետք է անել, կիրառելի է այն, ինչ տեսել են՝ օգտագործման դեպքից թեստային նպատակների հավաքածուն ստանալու համար: Այնուհետև որոշվում են օգտագործվող փորձարկման ամրագոտիների բնութագրերը: Ի վերջո, մենք կիրառում ենք այն, ինչ տեսանք նախորդ բաժիններըթեստային գործն իրականացնել փորձարկման թիրախից: Փորձարկման տակ գտնվող համակարգում հայտնաբերվել են արտեֆակտներ Անգլերեն Լեզու, այնքանով, որքանով Իսպաներեն լեզու չի ապահովվում օգտագործվող գործիքներով: Աղյուսակ 2-ի օգտագործման դեպքը նկարագրում է համակարգում նոր կապի ներդրումը: Որպես հավելում, ցուցադրվում է նաև յուրաքանչյուր հղումով մշակված տեղեկատվությունը նկարագրող տեղեկատվությունը պահելու պահանջը: Օգտագործման դեպքից և ավտոմատ կերպով ստեղծվել է մի շարք սցենարներ, որոնք կլինեն նշված օգտագործման դեպքի փորձարկման թիրախը: Հաշվի առնելով, որ օգտագործման դեպքն ունի անսահմանափակ օղակներ՝ անսահման թվով պոտենցիալ կրկնություններով, ճանապարհներ ստանալու համար ընտրված ծածկույթի չափանիշը 01 չափանիշն է, որը ստուգում և փորձարկում է 30 համակարգի թեստերը, բաղկացած է բոլոր հնարավոր ուղիների ձեռքբերումից՝ ոչ մեկը կամ մեկ անգամ չկրկնելու համար: օղակներից յուրաքանչյուրը: Այս չափանիշով ստացված և իսպաներեն թարգմանված բոլոր սցենարները թվարկված են աղյուսակում: Այս դեպքի ուսումնասիրության համար մենք ընտրել ենք Սցենար 09, որը մանրամասն ներկայացված է Աղյուսակ 5-ում դրա իրականացման համար: Թեստավորում և թեստավորում թեստավորման մեջ 31 Աղյուսակային տեղեկատվության պահանջ հղումների համար: Կարող եք նաև կիրառել կատեգորիաների բաժանման մեթոդը: Այս փոփոխականներից յուրաքանչյուրի բաժինները թվարկված են աղյուսակում: Համակարգի փորձարկում և փորձարկում 32 Օգտագործման դեպքի համար սահմանված աղյուսակի փոփոխականներ: Թեստավորում և թեստավորում թեստավորման մեջ 33 Որոշված ​​փոփոխականների կատեգորիաների աղյուսակ: Ինչպես նկարագրված է Նկար 7-ում, ամրագոտիների թեստը նախատեսված է օգտատիրոջ վարքագիծը մոդելավորելու և արդյունքը գնահատելու մի շարք հայտարարություններ առաջարկելու համար: Այս թարգմանությունը ներկայումս կատարվում է ձեռքով և ներկայացված է աղյուսակում: Փոխանցիչի փորձարկում և փորձարկում 35 Նկար Փորձարկման դեպքի իրականացումը: Հիմնական սցենարում օգտագործողի կողմից կատարված քայլերի գործարկվող կոդի թարգմանությունը: Այսինքն՝ համոզվել, որ կատեգորիաները կան, և որ կատեգորիաները վերականգնելիս կամ նոր հղում տեղադրելիս սխալ պատճառող հանգամանքներ չկան։ Ընդմիջման մեթոդի իրականացումը համակարգում պահվող հղումների սկզբնական հավաքածուի վերականգնումն էր: 2 Ընդունման թեստերի իրականացում. Ընդունման թեստերն աշխատում են միայն հաճախորդների աջակցության կամ գոնե հաճախորդի վստահված անձի հետ՝ չափանիշները որոշելու համար: Առանց վարորդի ընդունման չափանիշների, դժվար է դառնում ստուգել, ​​թե արդյոք դուք ճիշտ ծրագրակազմ եք ստեղծում: Հաճախորդը, զարգացման թիմի բոլոր անդամների հետ միասին, պետք է հավաքվի՝ սահմանելու համակարգը մի շարք «սկրիպտների» առումով, որոնք նկարագրում են, թե ինչ պետք է անի համակարգը և ինչպես պետք է դա անի: Հստակ պահանջներով և հաստատման չափանիշներով թեստեր ստեղծելով, ծրագրաշարն ավելի հավանական է, որ բավարարի հաճախորդների սպասելիքները: Այնուամենայնիվ, սա նշանակում է, որ ինչ-որ մեկը ձեռքով ստուգում է, որ պահանջները բավարարված են, և որ հավելվածն աշխատում է այնպես, ինչպես սպասվում էր: Այստեղ է, որ ընդունման ավտոմատ թեստերը գալիս են ժառանգական փաստաթղթի պահանջների փոխարեն, պահանջները սահմանվում են որպես օրինակներ և սցենարներ, պաշտպանված են աղբյուրի հսկողության մեջ տեղակայման արտեֆակտներով և կարող են իրականացվել ցանկացած ժամանակ՝ ստուգելու համար, թե արդյոք դրանք համապատասխանում են որևէ պահանջի և ճիշտ են աշխատում: Դուք կարող եք օգտագործել նույն մոտեցումը թեստեր գրելու համար, բայց դրանք թեստային դեպքերի կառավարման ծրագրաշարում կամ աղյուսակում մուտքագրելու փոխարեն, դրանք ուղղակիորեն գրեք կոդի մեջ: Համակարգի փորձարկում և փորձարկում 37 1 Ընդունման ավտոմատ փորձարկում. Հետևաբար, ցանկացած նոր ֆունկցիոնալության իրականացման առաջին քայլը ձեր ակնկալիքները թեստով նկարագրելն է: Մյուսները չեն, և ժամանակի ընթացքում պայքարում են գործընթացի վերահսկման հետ, հատկապես երբ ապացույցներն աճում են և թեստավորման ճկունությունը սկսում է վատթարանալ: Թեստի վրա հիմնված մոտեցումը հիմնված է այն թեստերի վրա, որոնք պետք է առաջնորդեն ծրագրային արտադրանքի մշակումը: Արդյունաբերական ծրագրային արտադրանքներում, երբ օգտագործվում են պահանջների ինժեներական մեթոդներ, դրանք հիմնականում ապահովվում են բնական լեզվով, ինչը ենթադրում է անորոշության հայտնի անհարմարություն: Այնուամենայնիվ, վավերացման անհրաժեշտությունը կարող է գերազանցել այն առավելությունները, որոնք կարող են առաջարկել ավելի պաշտոնական և խիստ պահանջների ճշգրտումը: Հաճախորդը պետք է կարողանա կարդալ և հասկանալ պահանջները, որպեսզի կարողանա համաձայնել դրանց: Պահանջների սահմանման ամենատարածված մեթոդները թվարկված են Օգտագործման դեպքեր և օգտվողների պատմություններ բաժնում: Պահանջների սահմանումը հաճախորդին գրավելու բանալին է: Պահանջներ - հասնելու նպատակը, այսինքն՝ ինչ է ակնկալում հաճախորդը ծրագրային ապահովման արտադրանքից: Համակարգի փորձարկում և փորձարկում 38 դերեր՝ կապված պահանջների ճշգրտման և վավերացման և ընդունման փորձարկման հետ: Պահանջների հայեցակարգը դառնում է ընդունելության թեստերի կոնտեյներ, և սրանք են, որոնք կենտրոնական տեղ են զբաղեցնում որպես յուրաքանչյուր պահանջի հստակեցում: Դիտարկենք «Գումարի դուրսբերում» պահանջը բանկոմատի համատեքստում: Տիպիկ նկարագրական ճշգրտումը կարող է լինել հետևյալը. Հաճախորդը պետք է կարողանա կանխիկացնել գանձապահից ընտրված գումարներով: Միշտ ստացեք անդորրագիր, եթե գանձապահին թուղթ չի մնացել: Ինչ վերաբերում է Նախընտրելի հաճախորդին, դուք կարող եք դուրս գալ ավելի շատ փողքան դուք ունեք ձեր հաշվում, սակայն ձեզնից պետք է զգուշացվի, որ ձեզանից տոկոս կգանձվի: Հաճախորդը պետք է ցանկացած պահի կարողանա չեղարկել նախքան դուրսբերումը հաստատելը: Գումարները պետք է կարողանան սպասարկվել գանձապահի կողմից տվյալ պահին ունեցած հաշիվներով, իսկ այլ գումարներ չպետք է ընդունվեն: Նկար - Տեխնիկական այլընտրանքներ Նկար 10-ը ցույց է տալիս այս պահանջի որոշ առանձնահատկությունների այլընտրանքներ: Սրբապատկերները արտացոլում են յուրաքանչյուր բնութագրի հարմարավետությունը: Հետաքրքիր է մշակել հաջորդականության դիագրամ՝ յուրաքանչյուր պահանջի կատարման սցենար սահմանելու համար, սակայն, ընդհանուր առմամբ, դա հարմար չէ, քանի որ. մեծ թվովստեղծված դիագրամներ. Ավելի հետաքրքիր է բացահայտել սցենարները, քան դրանցից յուրաքանչյուրը գծապատկերում: Պատմողական նկարագրությունը միանգամյա չէ, համենայն դեպս դրա համար կարճ սահմանումպահանջները, որոնք ուղղված են ներգրավված հասկացությունների սահմանմանը: Այնուամենայնիվ, օգտագործման մոդելը հարմար չէ երկարաժամկետ սպասարկման միջավայրում ծրագրային արտադրանքի մանրամասն պահանջների կառուցվածքը ցուցադրելու համար, քանի որ միջին ծրագրային արտադրանքը կարող է ունենալ հազարավոր պահանջներ: Շատ պահանջներ պատկերացնելու և կառավարելու համար ավելի համապատասխան մեխանիզմներ են անհրաժեշտ: Կաղապարները օգտագործման դեպքերի համար օգտագործվող ամենատարածված այլընտրանքներից են: Կաղապարները էլեգանտ են և ապահովում են կարգի զգացողություն՝ ըստ բնութագրերի: Այնուամենայնիվ, դրանք ընդհանուր առմամբ հակաարդյունավետ են, քանի որ դրանք հակված են ապահովելու մանրամասների մշակման միասնական մակարդակ բոլոր պահանջների համար: Այս շատ պարզ դեպքերում, դրանք ներառում են այնպիսի բաներ, որոնք ակնհայտ կամ անտեղի են միայն կաղապարի բոլոր բաժինները լուսաբանելու համար: Երբ պահանջը ներառում է մի քանի սկրիպտներ, կաղապարի բոլոր սցենարները սինթեզելու փորձը սովորաբար հանգեցնում է շփոթեցնող բնութագրերի: Այս կերպ պահանջները երկրի համար գործում են որպես կոնտեյներ։ Կախված պահանջից, կարող են օգտակար լինել ճշգրտման այլ լրացուցիչ ձևեր: Օրինակ՝ գործունեության դիագրամ, եթե պահանջի հետ կապված վարքագիծն ունի ալգորիթմական նշան, կամ վիճակի դիագրամ, եթե վարքագիծը ներառում է միացնելու կամ անջատելու գործողություններ՝ համաձայն համակարգի պնդումների և համակարգի ընդունման թեստերի: Էական նախադրյալը պրագմատիզմն է ճշգրտման նկատմամբ, որը չի բացառում հստակեցման այլընտրանքների փոխանակումը, սակայն առաջնային չափանիշը պետք է լինի շահութաբեր լինելու և այդ հստակեցման պահպանմանը նպաստելու ցանկությունը: Մյուս կողմից՝ ջանքերի առումով սպասարկումՀատկապես հետևողականության առումով կարևոր է չչարաշահել տեխնիկական բնութագրերի կրկնօրինակումը կամ կրկնօրինակումը տարբեր միջոցներ ներկայացուցչություն։ Ուղղորդված գրաֆիկը համապատասխան ներկայացում է մակարդակի ճշգրտման համար: Այս գրաֆիկը թույլ է տալիս պատկերացնել տարրալուծման հարաբերությունները և պահանջների միջև կախվածությունը: Այսպիսով, յուրաքանչյուր հանգույց ֆունկցիոնալ կամ ոչ ֆունկցիոնալ պահանջ է: Հանգույցների միջև ընկած աղեղները հարաբերություններ են հաստատում ծնողների և երեխաների միջև կամ «հանգույցների վրա ազդող հանգույցները» կախվածության հարաբերությունները: Այսպիսով, վերոնշյալ օրինակում «Գումարի դուրսբերում» պահանջը կարող է լինել պահանջների կառուցվածքի հանգույց: Վերադարձեք հաճախորդի մուտքագրած քանակով։ Տոմսեր չկան։ Ստանալու թուղթ չկա։ Կենտրոնական համակարգի հետ կապի ժամանակը գերազանցվել է։ Գանձապահի ներքին գործառնությունների մասին ծանուցում. Գործողություն սկսելու ժամանակը սպառվել է: Սա կարող է կապված լինել ֆունկցիոնալ կամ ոչ ֆունկցիոնալ պահանջի հետ: Այն կամընտիր է և օգտագործվում է նախադրյալներ սահմանելու համար՝ նախքան թեստի քայլերը կիրառելը: Սրանք համակարգի հետ գործող դերակատարի փոխազդեցության գործողություններն են: Երբ նրանք կատարում են մի քանի գործողություններ, դրանք կարող են տեղադրվել համարակալված ցուցակում: Սա դերասանների փոխազդեցությունների ազդեցությունն է: Յուրաքանչյուր գործողություն կարող է հանգեցնել մեկ կամ մի քանի արդյունքի: Կարևոր է, որ երբ խոսքը վերաբերում է օգտվողին ուղղված հաղորդագրություններին, տեքստը ներառվի որպես ակնկալվող արդյունքի մաս, այնպես որ ծրագրավորողն արդեն ունի այս տեղեկատվությունը հաստատված հաճախորդի հետ: Սա, ինչպես կնշենք ստորև, կհաստատի պահանջների միջև կախվածությունը: Վիճակը Պետք է լինի նորմալ հաճախորդ: Քայլեր  Փորձեք վերադարձնել սովորական հաճախորդին և պահանջեք մնացորդից ավելի գումար:  Ակնկալվող արդյունքը. Համակարգի փորձարկում և ընդունում 42  Ցուցադրվում է «Պահանջվող քանակությունը գերազանցում է ձեր ընթացիկ հաշվեկշիռը, նորից մուտքագրեք քանակությունը» հաղորդագրությունը և վերադառնում է պատուհան՝ քանակը մուտքագրելու համար: Ընդունման թեստը կօգնի հաստատել, որ դուք կառուցում եք այն հավելվածը, որը ցանկանում է հաճախորդը, մինչդեռ այս սկրիպտների ավտոմատացումը թույլ է տալիս շարունակաբար փորձարկել հավելվածը մշակման գործընթացի ընթացքում և օգտագործել դրանք որպես ռեգրեսիայի թեստավորման փաթեթի մաս՝ համոզվելու, որ ապագա փոփոխությունները չեն խախտում ընթացիկը: պահանջները. Այնուամենայնիվ, ապացույցների, հատկապես ավտոմատացված թեստավորման հետ կապված հաճախորդ ունենալը մի շարք հնարավոր խնդիրներ է ներկայացնում: Հաճախորդները, ընդհանուր առմամբ, ոչ տեխնիկական են և հակված են հեռու մնալ ծրագրային ապահովման մշակումից: Հաճախորդը կարող է տրամադրել տվյալներ և օրինակներ, մինչդեռ փորձարկողները կամ մշակողները կարող են արագ կոդավորել սկրիպտներ և գործարկվող բնութագրեր: Օգտագործողի միջերեսի ընդունման թեստեր Օրինակներում ընդունման թեստերը կենտրոնացած էին բիզնեսի տրամաբանության և տիրույթի օբյեկտների վրա՝ տեսնելու, թե արդյոք տրամաբանությունը հաջողությամբ է աշխատել: Բայց ի՞նչ կասեք, թե ինչպես է օգտատերը համագործակցում հավելվածի հետ: Այս ընդունման թեստերը պետք է լինեն՝ օգտագործողի տեսանկյունից տրամաբանության ճիշտությունը ստուգելու համար, իսկ օգտագործողի տեսակետը օգտատիրոջ միջերեսն է: Եթե ​​հավելվածն ունի լավ անջատում և տրամաբանության լավ տարանջատում UI ծածկագրից, դա պետք է հեշտացնի թեստերի իրականացումը: Եթե ​​դուք փորձարկում եք այս մակարդակում, ապա թեստերը չեն փոխվի օգտագործողի միջերեսում: Թեև թեստավորումը պետք է կենտրոնանա բացառապես տրամաբանության վրա, դա չի նշանակում, որ դուք չպետք է անցնեք ընդունման թեստեր ամբողջ օգտագործողի միջերեսում: Ես սիրում եմ ունենալ ծխի թեստերի մի շարք, որոնք ուղղված են հիմնական ինտերֆեյսին» երջանիկ ճանապարհ«. Նրանք կենտրոնանում են հավելվածի այն մասերի վրա, որոնք օգտատերերն ամենայն հավանականությամբ կօգտագործեն իրենց փորձից առավելագույնը ստանալու համար: նվազագույն քանակփորձարկում. Եթե ​​դուք փորձում եք ծածկել ամեն ինչ հնարավոր ուղիներըև UI-ի օգտագործումը, և եթե UI-ն փոխվի, դուք ստիպված կլինեք փոխել բոլոր թեստերը: Օրինակ, եթե դուք փորձարկեք օգտատիրոջ միջերեսը էլեկտրոնային առևտրի կայքի համար, ճանապարհը հաճույքով կընտրի որևէ ապրանք, ավելացրեք այն զամբյուղի մեջ, ստուգեք այն և կտեսնեք գնման հաստատումը: Եթե ​​այս սցենարը ձախողվի, դուք իսկապես ցանկանում եք պարզել ASAP-ը: Որոշ հավելվածների համար, կախված բարդությունից և կյանքի տևողությունից, դուք կարող եք ավելի շատ ընդունելության թեստեր անցկացնել UI-ում, որպեսզի համոզվեք, որ ավելի շատ վստահություն ունեք UI շերտի նկատմամբ: Այնուամենայնիվ, հաջողված UI թեստավորումն է դժվար հարցև ես տեղ չունեմ այն ​​ծածկելու համար: Համակարգերի փորձարկում և ընդունում 43 3Խելացի թեստեր. Երբ դուք պատմեք պատմությունը և սցենարները հստակ և հասկանալի ձևաչափով, հաջորդ քայլը պատմությունն ու սցենարների ավտոմատացումն է: Սա թույլ է տալիս նրանց աշխատել մշակման ընթացքում՝ հետևելու առաջընթացին և բռնելու ռեգրեսիայի սխալները: Եզրակացություններ և առաջարկություններ. Մյուս կողմից, մենք ունենք համակարգերի թեստեր, որոնք պատասխանատու են ողջ գործընթացի ընթացքում գործողությունների գնահատման համար, որպեսզի հայտնաբերենք սխալները, որոնք կարող են տեղի ունենալ դրա համար, անհրաժեշտ է մշակել ռազմավարություն թեստերով և առանձնացնել կոդի մշակումը ինտերֆեյսի մշակումից, ուստի այն լավագույնն է համակարգային թեստեր իրականացնելը: Ծրագրային ապահովման այս երկու փորձարկումների իրականացումը պետք է իրականացվի որոշակի չափանիշներին համապատասխանող խիստ թեստերով և համակարգի մշակման մեջ ներգրավված շահագրգիռ կողմերի համակարգմամբ: Համակարգի փորձարկում և ընդունում 44 Մատենագիտություն 1. Իզաբել Ռամոս Ռոման, Խոսե Խավիեր Դոլադո Կոսին. Քանակական կառավարման մեթոդներ ծրագրային ապահովման մշակման մեջ. Ալոնսո Ամո, Լոիկ Մարտինես Նորմանդ. Ծրագրային ապահովման մշակման ներածություն. Systems Testing and Acceptance Testing 45 8. -Համակարգչային լեզուների և համակարգերի բաժին. Կառուցվածքային համակարգի վերլուծություն. Մանրէաբանության լաբորատորիայում բակտերիաների նույնականացման մեթոդներ.