Табыстар:
- CI/CD контекстінде идеядан шығарылымға дейін QA ағынындағы жасанды интеллект пен адамның мақұлдау нүктелерінің рөлін жобалау мүмкіндігі
- CI/CD жүйесінде AI-ға сынақтан автоматты түрде «өтуге» рұқсат бермей, құпия деректер мен кілттерді қорғау үшін шектеулерді қолдану
- Өкілеттік шегінде және қорғаныс мақсаттары үшін қауіпсіздік сынақтарын жүргізу және жауапты ашу және этикалық ашықтық принциптерін қабылдау мүмкіндігі.
Алдыңғы он бірлікте біз жеке тапсырмаларда AI қолдандық: сценарийді құру, автоматтандыру коды, қателер туралы есеп беру, қамтуды талдау, мутацияны тексеру. Бұл соңғы блок олардың барлығын бір жауапты жұмыс процесіне біріктіреді. Қазіргі заманғы QA бір адамның үстелінде аяқталатын жұмыс емес; Бұл CI/CD ішінде өмір сүретін процесс (Үздіксіз интеграция / Үздіксіз жеткізу — код үнемі біріктірілетін, автоматты түрде тексерілетін және жиі және қауіпсіз түрде жариялануға дайындалатын құбыр). Жасанды интеллект осы процестің әр кезеңіне қол жеткізе алады. Бірақ AI күші өскен сайын оны жауапкершілікпен пайдаланудың маңыздылығы да арта түседі: құпиялылық, қауіпсіздікті сынаудағы бедел, этика және ең бастысы, сапалы шешімді адам өз еркінде ұстау. Бұл бөлімде сіз ақырғы ағынды және шекараларды үйренесіз.
AI-мен жұмыс істейтін QA ағыны
Функцияның идеядан шығаруға дейінгі саяхатындағы AI рөлі:
1. Талаптарды талдау. AI талаптардағы анық еместіктерді және қабылдау критерийлерінің жоқтығын белгілейді («бұл ереже құпия сөздің қанша таңбадан тұратынын айтпайды»).
2. Тест құрастыру. Қабылдау критерийлері арасында сценарий мен іс жобалары (2-бірлік), шеткі істер (3-бірлік) бар.
3. Автоматтандыру. Бірлік (6), API (5) және UI (4) сынақ кодының жобалары; әрқайсысы мутация арқылы расталады (10).
4. CI/CD интеграциясы. Әрбір код біріктірілгенде сынақтар автоматты түрде орындалады. AI құбыр конфигурациясының (YAML) жобаларын жасайды, сәтсіз сынақтар журналдарын қорытындылайды және ықтимал негізгі себепті ұсынады.
5. Босату туралы шешім. Тәуекелді талдау (8) және регрессия (9) нәтижелері жиналады — бірақ оның сәтті болуы мүмкін бе, жоқ па, соны сарапшы шешеді.
6. Өндіріс мониторингі және кері байланыс. Тікелей эфирдегі қателер болашақ сынақтарға айналады; AI өндірістік ақаудан регрессия жағдайын ұсынады.
Кеңес: AI-ны CI/CD-де «тесттер жазып, шешім қабылдайтын» емес, «адам қараған жобаларды жылдамдататын» деңгей ретінде орнатыңыз. Автоматты түрде жасалған ешбір сынақ адам тексеріп, мақұлдамай құбырға енбеуі керек.
CI/CD-дегі AI: иә, жоқ жерде
Сахна
AI жарамды
адам маңызды
Сынақ кодының жобасы
Иә
Қайта қарау + мутация
Құбыр YAML жобасы
Иә
Аутентификация + құпия кілтті тексеру
Сәтсіз журнал қорытындысы
Иә
Түбірлік себептерді растау
Нәзік тест диагнозы
Иә
Тұрақты шешім
«Нұсқа болуы мүмкін бе?»
жоқ
Мамандық бағалау және жауапкершілік
Сынақтан автоматты түрде «өтіңіз».
ешқашан
—
Ескерту: Жасанды интеллектке ешқашан CI/CD ішіндегі «сәтсіз сынақтан өту үшін оны түзетіңіз» сияқты мандат бермеңіз. Бұл тестілеу мақсатын бұзады және қателерді автоматты түрде жабады. AI қатені түсіндіре алады, түзетуді ұсына алады; бірақ «тестті жасыл түске бояу» адамның саналы, дәлелді шешімі болуы керек.
Құпиялылық, деректер және қауіпсіздік: өзгермейтін шекаралар
Құпиялық. Сынақ ортасында нақты тұтынушы деректері, өндірістік дерекқор көшірмелері, API кілттері және ішкі жүйе ақпараты сезімтал. Бұларды AI құралдарына бермеңіз. Жеке деректер KVKK және ұқсас ережелерге бағынады; Маска журналдары мен скриншоттар. Мүмкіндігінше синтетикалық (ойдан шығарылған) сынақ деректерін пайдаланыңыз.
Қауіпсіздік сынағы — қорғаныс және рұқсат етілген. Осы модульде үйренген қауіпсіздік сынақтары (авторизация/IDOR сынақтары, файлды жүктеп салу шектеулері, енгізуді тексеру) жазбаша рұқсат пен анықталған аумақта өз өніміңізді тексеруге арналған. Басқа біреудің жүйесіне рұқсатсыз кіру, нақты осалдықтарды қаруландыру немесе ауқымнан тыс тестілеуді орындау үшін AI пайдалану этикалық емес және заңсыз болып табылады. Қауіпсіздік осалдығын тапқан кезде, жауапты ашу принципін сақтаңыз — осалдықты құпия сақтаңыз және оны түзетуге болатындай тиісті тарапқа хабарлаңыз.
Этика және ашықтық. AI жасаған сынақтарды өз жұмысыңыз ретінде көрсетпеңіз; Командада AI қолданып жатқаныңызды айту - бұл ашықтық. Жасанды интеллект шығарылымының дұрыс еместігіне сіз жауаптысыз — «оны AI жазды» деген сылтау емес.
Әлсіз шақыру / Күшті шақыру
Әлсіз: "CI үшін сынақ құбырын орнату."
Күшті: "GitHub әрекеттері үшін CI жұмыс ағынының YAML жобасын жасаңыз: әрбір PR үшін бірлік + API сынақтарын іске қосыңыз, қамту туралы есеп жасаңыз, апта сайын мутация сынамасын (Stryker) орындаңыз. Құпияларды кодқа ендірмеңіз; құпиялар сілтемесін ғана пайдаланыңыз. Сынақтар қызыл болса, біріктіруді блоктаңыз. Бұл ЖОБА; Мен кілттерді басқару және автоматты түрде сынақтан өткізу қадамдарын ӨЗГЕН ЕМЕС. «түзету» немесе «көшіру» қадамы».
Күшті жеделдік; Ол құпиялылыққа, адам тексеруіне және «автоматтандырылған тестілеуге» шектеулер қояды.
Көшірілетін төрт үлгі
1) Тестілеу жоспары:
Сіздің рөліңіз: аға QA жетекшісі. Келесі мүмкіндік үшін идеядан шығарылымға дейін түпкілікті сынақ жоспарының жобасын жасаңыз: [мүмкіндік + қабылдау критерийлері]. Фазалар: талаптарды талдау (белгісіздіктер), сынақ дизайны, автоматтандыру қабаттары (бірлік/API/UI), CI/CD интеграциясы, шығарылым шешімдерінің критерийлері, өндірісті қадағалау. Әр кезеңде AI және АДАМ мақұлдау нүктелерінің рөлін бөлек көрсетіңіз.
2) CI/CD құбырының сұлбасы:
[GitHub Actions/GitLab CI/Azure Pipelines] үшін CI YAML жобасы:- Бірлік + API сынағы + PR-дағы ауқым - Қызыл сынақта біріктіруді болдырмаңыз - Құпия мәндер тек құпиялармен; кодқа ендіру Бұл жоба жобасы; Мен негізгі басқару және бекіту қадамдарын қарастырамын. Автоматты түзету/тексеру қадамын қосу.
3) Сынақ журналын талдау сәтсіз аяқталды:
Бұл CI басып шығаруда сынақтар қызыл болады. Журналды тексеріңіз; сәтсіздіктерді топтаңыз, ықтимал негізгі себебін ажыратыңыз және ҚАЙСЫ нақты сәтсіздік болуы мүмкін және нәзік сынақ/қоршаған орта мәселесі болуы мүмкін. Егер жеке деректер болса, оны жасырыңыз. Шешім мен түзету менікі болады. Журнал: [қою]
4) Қауіпсіздік/құпиялылықты алдын ала тексеру:
Бұл сынақ деректері/журнал AI құралына жіберілмес бұрын мынаны тексеріңіз: онда жеке деректер, API кілті, ішкі жүйе мекенжайы, өндіріс деректері бар ма? Қандай аймақтарды, егер бар болса, маскирлеу/жою қажет екенін көрсетіңіз. Сол күйінде өңдеу. Мазмұны: [қою]
үш шағын іс
1-жағдай - ұшынан-соңына ағынның жылдамдығы. Бір команда жасанды интеллектпен жұмыс істейтін «жазылымды жаңарту» жаңа мүмкіндігін шешті: талаптың белгісіздігі алдыңғы жағында белгіленді, үш деңгейлі сынақтар әзірленді және CI-мен байланысты мутациямен расталды. Бұл мүмкіндік дәстүрлі процесте 5 күнге созылатын тестілеу циклін 2 күнге дейін қысқартты; бірақ адамның мақұлдауы әр кезеңде сақталды және талаптардың белгісіздігі (жаңарту сәтсіз болса не болады) тікелей эфирден бұрын жабылды.
2-жағдай — кілттің ағып кетуінен қайтару. Әзірлеушіде CI YAML жасайтын AI болды, ал AI мысал ретінде YAML-ге нақты көрінетін API кілтін ендірді. «Қауіпсіздік/құпиялылықты алдын ала тексеру» қадамы мұны қамтыды; кілт құпия анықтамаға түрлендірілді. Аудит қадамынсыз кілт нұсқаны басқаруға (git тарихы) ағып кетеді.
3-жағдай – Өкілеттік шегі. Команда мүшесі өзі үйренген IDOR тестін іскер серіктестің «Мен қызық болдым» жүйесіне қолданғысы келді. QA басшысы тоқтатты: жазбаша рұқсатсыз және анықталған ауқымсыз басқа жүйеде қауіпсіздік сынағы өткізу заңсыз. Тестілеу тек өз өнімдерінің сынақ ортасында, өкілеттікпен жүргізілді; Ашық жауапты тарап тиісті топқа хабарланды.
Жалпы қателер
- AI шығару шешімдерін қабылдау. «Оны шығаруға болады ма?» деген сұрақ қою. АИ-ге және қолдың орнына жауапты қою.
- Автоматтандырылған тесттен «өту». CI-де AI сынақты жасыл түске бояйды; қателіктерді жасыру.
- Көлік құралына құпия деректерді/кілтті беру. Өндіріс деректерін, жеке деректерді немесе API кілттерін қадағалаусыз ортақ пайдалану.
- Рұқсат етілмеген қауіпсіздік сынағы. Ауқымды және рұқсатсыз басқа жүйеде шабуылдаушы сынағы.
- Тексерусіз сынақтарды құбырға енгізу. AI эскизін адамның рұқсатынсыз автоматты түрде іске қосыңыз.
- Кінәні АИ-ге қою. Қате нәтижені «АИ жазды» деп қорғау.
Қысқаша
Үздік QA – талаптардан өндірісті қадағалауға дейінгі және CI/CD ішінде өмір сүретін процесс; Әрбір кезеңде AI жобаларды жасайды, журналды қорытындылайды және негізгі себептерді ұсынады. Бірақ шекаралар өзгермейді: адамдар сынақ шешімдерін қабылдайды және мақұлдайды; AI-ға ешқашан сынақтан автоматты түрде «өту» құқығы берілмейді; құпия деректер мен кілттер көлікке кірмейді; Қауіпсіздік сынағы қорғаныс мақсатында жазбаша рұқсат пен анықталған ауқымда тек сіздің өніміңізде орындалады және нәтижелер жауапты ашып көрсету арқылы хабарланады. AI пайдалану кезінде мөлдір болыңыз; Шығарылымның дұрыстығына сіз жауаптысыз. AI жеделдетеді; Сіз сапа мен этикаға кепілдік бересіз.
Қолданбалы тапсырма
Жеке жобаңыздағы мүмкіндікке арналған «соңғы сынақ жоспары» үлгісімен идеядан шығаруға дейінгі жоспарды жасаңыз; Әр кезеңде AI және адамның мақұлдау нүктелерінің рөлін бөлек белгілеңіз. Содан кейін «CI/CD контурының сұлбасы» бар YAML жасаңыз және ендірілген кілт/құпия деректердің бар-жоғын тексеру үшін осы YAML-ге «қауіпсіздік/құпиялылықты алдын ала тексеруді» қолданыңыз. Соңында, жоспарыңыздағы барлық «адамның шешімі» тармақтарын тізімдеңіз және бұл шешімдерді неліктен AI-ға беруге болмайтынын бір сөйлеммен негіздеңіз.
бақылау парағы
- [ ] Мен шығару және сынақ шешімдерін адамның мақұлдауымен байланыстырамын; Мен оны АИ-ге берген жоқпын.
- [ ] CI/CD-де мен AI-ға сынақтан автоматты түрде «өтуге/түзетуге» рұқсат бермедім.
- [ ] Мен құпия деректерді, жеке деректерді және кілттерді көлікке жібермес бұрын тексеріп, маскировкаладым.
- [ ] Мен жазбаша рұқсат пен ауқымда өз өнімімде қауіпсіздік сынақтарын ғана қарастырдым.
- [ ] Мен табылған осалдықтарды жауапты ашу принципімен қарастырдым.
- [ ] Мен AI пайдаланғанымды және нәтиженің дәлдігі үшін өзімді жауапты деп санайтынымды ашық айттым.
Модуль емтиханы
1. QA контекстінде «жалған өту» ең дәл қалай анықталады?
- A) Тест жасыл түске боялғанымен, ол іс жүзінде ешқандай әрекетті растамайды; ✔ Код бұзылса да қызыл түспейді
- B) Сынақ өте баяу және уақыт бітеді.
- C) Тест нақты қатені анықтайды және қызыл түске айналады
- D) Сынақ тек өндірістік ортада орындалады
Түсініктеме: Псевдо-өту - бұл сынақ «өтті» дегенді білдіреді, бірақ шын мәнінде маңызды ештеңені растамайды; Сынақ жасыл, бірақ бағдарламалық құрал ақаулы болса да, оны ұстамайды. Бұл QA-дағы AI-ның бірінші қаупі, өйткені AI ұқыпты көрінетін, бірақ қуыс сынақтар жасауға бейім.
2. Тестілеу және QA процесінде жасанды интеллекттің ең дәл орналасуы қандай?
- A) Жасанды интеллект нұсқаны адамның рұқсатынсыз шығаруға болатындығын шеше алады
- B) Жасанды интеллект жобалар мен идеяларды тудыратын көмекші; «Жариялануға дайын ба» шешімі мен жауапкершілігі сарапшыға тиесілі ✔
- C) Жасанды интеллект тек мәтін жазады және тесттік кодпен мүлдем айналыса алмайды
- D) Жасанды интеллект әрқашан адамға қарағанда дұрыс тест жазады, сондықтан шолу қажет емес
Сипаттама: Жасанды интеллект тестілеуші көмекші, жобалық генератор және идея мультипликаторы; сынақ сценарийлерін, автоматтандыру кодын және есеп жобаларын жасайды. Дегенмен, «бұл бағдарламалық құрал жариялауға дайын ба» немесе «осы сынақтан өтті ме» сияқты сапалы шешімдердің жауапкершілігі мен түпкілікті мақұлдау құзыретті сарапшыға тиесілі.
3. Қателер көбінесе шекті мәндерде болатындығына байланысты, 18 жас шегі үшін 17, 18 және 19-ды бөлек сынау үшін қандай тест құрастыру техникасы қажет?
- A) Мемлекеттік өтпелі тест
- B) Шешім қабылдау кестесі
- C) Шекаралық талдау ✔
- D) Барлау тестілеу
Түсініктеме: Шектік мәнді талдау қателер шекараларда жиі болатынын байқауға негізделген және шекті мәндерді (төменде, дәл үстінде және шектен сәл жоғары) бөлек тексереді. Бұл эквиваленттік сыныптарды толықтыратын күшті әдіс.
4. Жасанды интеллектпен жасалған UI сынақ автоматтандыру кодындағы сынғыштықты азайту үшін элементтерді таңдауда қандай тәсілге артықшылық беру керек?
- A) Мүмкін болатын ең ұзын XPath жолын пайдалану
- B) Элементті экрандағы пиксель орнына сәйкес таңдау
- C) CSS класс атауларына негізделген селекторларды қолдану
- D) Тестілеу үшін қосылған тұрақты атрибуттарды (data-testid) пайдалану ✔
Түсініктеме: Ұзын XPath жолдары мен CSS класс атаулары бет құрылымы мен дизайнына өте тәуелді; Интерфейстің ең аз өзгеруінде ол бұзылады. Тестілеу үшін арнайы қосылған тұрақты атрибуттарға (мысалы, деректер-тесті) дизайн өзгерістері әсер етпейді және сынақтарды сенімді етеді.
5. Неліктен API сынағы тек HTTP күй кодын тексеру үшін жеткіліксіз (мысалы, 200)?
- A) Дұрыс күй коды бар дене деректері бүлінуі мүмкін болғандықтан және тек күйді тексеру оны ұстамайды (жалған сенім) ✔
- B) Күй кодтары API сынақтарында мүлдем сенімді емес болғандықтан
- C) Күй кодын тексеру сынақты айтарлықтай баяулатқандықтан
- D) Күй коды API сынақтарында ешқашан қайтарылмағандықтан
Түсініктеме: Сервер дұрыс күй кодын қайтарған кезде, ол денедегі бүлінген деректерді қайтаруы мүмкін (қате түр, жоқ өріс, дұрыс есептелмеген мән). Тек жағдайға қарайтын сынақ мұны көре алмайды және жалған сенім береді. Сонымен, схема/келісімшарт және бизнес ережелерін тексеруді қосу керек.
6. Бірлік сынақтарын басып шығару кезінде AI-ға «қабылдау ережесіне сәйкес күтілетін мәнді қолмен есептеңіз, функцияның ағымдағы шығысына сілтеме жасамаңыз» деп айту неліктен маңызды?
- A) Қолмен есептеу тесттерді жылдамырақ орындайтындықтан
- B) Әйтпесе, сынақ кодтың ағымдағы (мүмкін қате) әрекетін «дұрыс» деп қабылдайды және қатені растайды ✔
- C) Өйткені жасанды интеллект ондық сандарды мүлде есептей алмайды
- D) Өйткені сынақтарда қабылдау ережелері ешқашан қолданылмайды
Түсініктеме: Егер AI сыналатын функцияның шығысынан күтілетін мәнді алса, ол функция ақаулы болса да сынақтан «өтеді»; Яғни, код не шығарса да, сынақ ақиқат болып есептеледі. Күтілетін мәнді қабылдау ережесінен тәуелсіз есептеу сынақ кодтың айнасы емес, ереженің қақпасы болуын қамтамасыз етеді.
7. Төмендегілердің қайсысы қате туралы жақсы есептің ерекше белгісі болып табылады?
- A) Мүмкіндігінше ұзақ және техникалық болу
- B) Жасанды интеллектпен жазылған
- C) Құрамында әзірлеуші өз бетінше орындай алатын және қатені жасай алатын детерминирленген қайта шығару қадамдары бар ✔
- D) Бұл жай ғана скриншот
Түсініктеме: Қате туралы есептің нақты мәні мынада, әзірлеуші сіздің көмегіңізсіз қатені қайта жасай алады. Нөлден бастап анықталатын, бақыланатын көбейту қадамдары мұны қамтамасыз етеді; Бұл қадамдар жоқ болса, есеп көбінесе «шығару мүмкін емес» деп жабылады.
8. Басты беттегі фирма атауын қате жазу қатесіндегі ауырлық пен басымдық арасындағы қатынасты көрсететін ең дәл өрнек қайсы?
- A) Қарқындылық пен басымдық әрқашан бірдей мәнге ие болуы керек
- B) Бұл қатенің ауырлығы да, басымдылығы да сөзсіз төмен
- C) Қауіптілік пен басымдық бір ұғым, бір белгі жеткілікті
- D) Техникалық қарқындылық төмен болуы мүмкін, бірақ іскерлік басымдылық (бедел) жоғары болуы мүмкін; Екеуі әртүрлі бағаланады ✔
Түсініктеме: Қателік - қатенің техникалық әсері (техникалық тұрғыдан төмен қате), басымдылық - оны тез арада түзету қажет (жоғары, себебі бұл әрбір келуші көретін бедел элементі). Екеуі әрқашан бір бағытта жүре бермейді; Бұл мысал төмен ауырлық-жоғары басымдылық жағдай болып табылады.
9. 90% желімен қамтылған тесттік топтаманың ең дәл интерпретациясы қайсысы?
- A) Бұл жолдардың орындалғанын көрсетеді, бірақ олардың дұрыс әрекет ететінін дәлелдемейді; ✔ жоғары қамту жалған сенім тудыруы мүмкін
- B) Бағдарламалық қамтамасыз етудің 90% қатесіз екенін түбегейлі дәлелдейді
- C) Бұл тамаша сынақ сапасының түпкілікті өлшемі.
- D) Ешқандай қосымша тесттер жазудың қажеті жоқ екенін көрсетеді
Түсініктеме: Жолды қамту тек жолдар орындалғанын көрсетеді; Бұл дұрыс нәтиже беретінін дәлелдемейді. Тіпті сенімсіз сынақтармен 90% қамтуға болады. Қолдану аясы «бәрі сыналған» деген сенімділік емес, «ешқашан қайда қараған жоқ» картасы; нақты қорғаныс мутация сынағы арқылы өлшенеді.
10. Тәуекелге негізделген тестілеуде мүмкіндіктің тәуекелі шектеулі тестілеу күш-жігерін бағыттау үшін қалай есептеледі?
- A) Тек код жолдарының саны бойынша
- B) Сәтсіздік ықтималдығын және ол бұзылған кезде болатын әсерді көбейту арқылы ✔
- C) Ерекшелік дамыған ретімен ғана
- D) Тесттерді жазуға оңай мүмкіндікке ғана басымдық беру
Түсініктеме: Тәуекелге негізделген тестілеуде тәуекел ықтималдық = ықтималдық (бұзылу ықтималдығы) × әсер (бұзылған жағдайда зиян) ретінде бағаланады. Ықтималдылығы жоғары және жоғары әсер ету домендері (төлем, аутентификация) ең қарқынды тестілеуге лайық, ал төмен×төмен домендер жеңіл тестілеуден өтеді.
11. Код өзгермесе де, кейде тапсыратын, кейде сәтсіз болатын (сынғыш/қабыршақ) сынаққа қайталауды қосудың негізгі қаупі қандай?
- A) Тесттің орындалу уақытын қысқарту
- B) Қамту пайызын төмендетеді
- C) Шынайы параллельдік қатені немесе негізгі себебін жабу және симптомды басу ✔
- D) Тест атауын өзгерту
Түсініктеме: Қайталау - емдеу емес, диагностикалық құрал. Шешімсіздік көбінесе нақты нәсілдік жағдайдан немесе тәуелділіктен туындайды; Қайталап көру арқылы сынақтан «өту» осы нақты қатені жабады және тікелей эфирде елеулі проблемаларды тудыруы мүмкін. Алдымен түпкі себебін табу керек.
12. Сынақ жинағының шын мәнінде қорғайтынын анықтаудың ең адал әдісі болып табылатын мутация тесті қалай жұмыс істейді?
- A) Сынақтардың жүру жылдамдығын өлшеу арқылы
- B) Кодтың қанша жол жазылғанын санау арқылы
- C) Тесттерді әртүрлі ретпен орындау арқылы
- D) Кодта әдейі кішігірім үзілістер жасау және сынақтардың оларды ұстайтынын өлшеу арқылы ✔
Сипаттама: Мутацияны тексеру бастапқы кодта шағын әдейі бұрмалануларды (мутацияларды) тудырады; Жақсы сынақ жинағы бұл бұрмалауларды ұстап, қызылға айналуы керек. Ұсталмаған (тірі қалған) мутациялар сынақтар бұл мінез-құлықты сақтамайтынын көрсетеді. Мутация көрсеткіші пайыздық қамтуға қарағанда сапаның әлдеқайда шынайы өлшемі болып табылады.
13. Қауіпсіздік тестілеуін (мысалы, авторизация/IDOR сынақтары) орындау кезінде ұстануға тиіс негізгі шектеу қандай?
- A) Ол тек өз өнімінде, жазбаша рұқсат және белгіленген көлемде, қорғаныс мақсатында жасалуы керек ✔
- B) Ол қызығушылықтың кез келген жүйесіне еркін қолданылуы мүмкін
- C) Оны рұқсатсыз іскер серіктестердің тірі жүйелерінде сынап көруге болады
- D) Кез келген табылған осалдықтар дереу жалпыға ортақ жариялануы керек.
Сипаттама: Осы модульде үйренген қауіпсіздік сынақтары жазбаша рұқсат пен анықталған ауқымда қорғаныс мақсатында өз өніміңізді сынауға арналған. Басқа біреудің жүйесіне рұқсатсыз кіру немесе ауқымнан тыс тестілеуді орындау әдепсіз және заңсыз болып табылады; Кез келген осалдықтар жауапты ашу арқылы хабарланады.
14. CI/CD құбырында AI-ға ешқашан қандай өкілеттік берілмеуі керек?
- A) Сәтсіз сынақ журналдарын қорытындылау
- B) Сәтсіз (қызыл) сынақтан автоматты түрде «өту» немесе оны жасыл түске бояу өкілеттігі ✔
- C) Тесттік код жобасын ұсыну
- D) Pipeline YAML файлының жобасын жасау
Сипаттама: AI сынақ кодының құрылымын, YAML конвейерін және CI/CD-де журнал қорытындысын жасай алады; дегенмен, сәтсіз сынақтан автоматты түрде «өту/түзету» мүмкіндігі ешқашан берілмеуі керек. Бұл тестілеу мақсатын бұзады және қателерді автоматты түрде жабады. Тестті жасыл түске бояу адамның саналы және дәлелді шешімі болуы керек.