Mga nadagdag:
- Kakayahang magdisenyo ng papel na ginagampanan ng artificial intelligence at mga punto ng pag-apruba ng tao sa end-to-end na daloy ng QA mula sa ideya patungo sa paglabas sa konteksto ng CI/CD
- Sa CI/CD, hindi pinahihintulutan ang AI na awtomatikong 'ipasa' ang pagsubok, ngunit naglalapat ng mga limitasyon para protektahan ang kumpidensyal na data at mga susi
- Kakayahang magsagawa ng pagsubok sa seguridad sa loob ng awtoridad at para sa mga layuning nagtatanggol, at magpatibay ng responsableng pagsisiwalat at mga prinsipyo ng etikal na transparency.
Sa nakaraang sampung unit, ginamit namin ang AI sa mga indibidwal na gawain: pagbuo ng senaryo, automation code, pag-uulat ng bug, pagsusuri sa saklaw, pagsubok sa mutation. Pinagsasama ng panghuling unit na ito ang lahat sa isang responsableng daloy ng trabaho. Ang modernong QA ay hindi isang trabaho na nagtatapos sa desk ng isang tao; Ito ay isang proseso na nabubuhay sa loob ng CI/CD (Continuous Integration / Continuous Delivery — ang pipeline kung saan ang code ay patuloy na pinagsama, awtomatikong sinusubok at inihanda para sa paglalathala nang madalas at ligtas). Maaaring hawakan ng AI ang bawat yugto ng prosesong ito. Ngunit habang lumalaki ang kapangyarihan ng AI, lumalaki din ang kahalagahan ng paggamit nito nang responsable: privacy, awtoridad sa pagsubok sa seguridad, etika, at higit sa lahat, pinapanatili ang kalidad ng desisyon sa tao. Sa unit na ito, matututunan mo ang dulo-sa-huling daloy at mga hangganan.
End-to-end AI-powered QA flow
Ang papel ng AI sa paglalakbay ng isang feature mula sa ideya hanggang sa paglabas:
1. Pagsusuri ng mga kinakailangan. Bina-flag ng AI ang mga kalabuan sa kinakailangan at nawawalang pamantayan sa pagtanggap ("hindi sinasabi ng panuntunang ito kung gaano karaming mga character ang minimum na password").
2. Pagsubok sa disenyo. Ang mga scenario at case draft (unit 2), edge cases (unit 3) ay kabilang sa mga pamantayan sa pagtanggap.
3. Automation. Unit (6), API (5) at UI (4) na mga draft ng test code; bawat isa ay nakumpirma sa pamamagitan ng mutation (10).
4. Pagsasama ng CI/CD. Awtomatikong tumatakbo ang mga pagsubok sa bawat pagsasama ng code. Ang AI ay nag-draft ng pipeline configuration (YAML), nagbubuod ng mga log ng mga nabigong pagsubok, nagmumungkahi ng posibleng ugat.
5. Palayain ang desisyon. Kinokolekta ang mga resulta ng pagsusuri sa peligro (8) at regression (9) — ngunit nagpapasya ang eksperto kung maaari itong maging matagumpay.
6. Pagsubaybay sa produksyon at feedback. Ang mga error sa live ay nagiging mga pagsubok sa hinaharap; Ang AI ay nagmumungkahi ng isang regression case mula sa isang manufacturing defect.
Tip: I-set up ang AI bilang isang layer sa CI/CD na "nagpapabilis ng mga draft na sinuri ng tao" sa halip na "nagsusulat ng mga pagsubok at gumagawa ng mga desisyon." Walang awtomatikong nabuong mga pagsubok ang dapat pumasok sa pipeline nang walang tao na nagsusuri at nag-aapruba sa kanila.
AI sa CI/CD: kung saan oo, kung saan hindi
entablado
AI fit
ang tao ay mahalaga
Test code draft
Oo
Rebisyon + mutation
Pipeline YAML draft
Oo
Authentication + secret key checking
Nabigong buod ng log
Oo
Root cause confirmation
Marupok na pagsusuri sa pagsusuri
Oo
Permanenteng desisyon ng solusyon
"Pwede bang may version?"
hindi
Dalubhasa sa paghatol at pananagutan
Awtomatikong "pumasa" sa pagsusulit
hindi kailanman
—
Babala: Huwag kailanman bigyan ang AI ng mandato tulad ng "ayusin ito upang makapasa sa bagsak na pagsubok" sa CI/CD. Tinatalo nito ang layunin ng pagsubok at awtomatikong tinatakpan ang mga error. Maaaring ipaliwanag ng AI ang error, magmungkahi ng pagwawasto; ngunit ang "pagpipinta ng berdeng pagsubok" ay dapat na may kamalayan, makatuwirang desisyon ng isang tao.
Privacy, data at seguridad: hindi nababagong mga hangganan
Pagkapribado. Sa kapaligiran ng pagsubok, ang aktwal na data ng customer, mga kopya ng database ng produksyon, mga key ng API at impormasyon ng panloob na system ay sensitibo. Huwag ibigay ang mga ito sa mga pampublikong tool sa AI. Ang personal na data ay napapailalim sa KVKK at mga katulad na regulasyon; Mga log ng maskara at mga screenshot. Gumamit ng synthetic (fictional) na data ng pagsubok hangga't maaari.
Pagsubok sa seguridad — nagtatanggol at awtorisado. Ang mga pagsubok sa seguridad na natutunan sa module na ito (mga pagsusuri sa awtorisasyon/IDOR, mga limitasyon sa pag-upload ng file, pagpapatunay ng input) ay para lamang sa pagsubok ng iyong sariling produkto sa loob ng nakasulat na awtorisasyon at tinukoy na saklaw. Ang paggamit ng AI para ma-access ang system ng ibang tao nang walang pahintulot, gamitin ang mga tunay na kahinaan, o magsagawa ng out-of-scope na pagsubok ay parehong hindi etikal at ilegal. Kapag nakakita ka ng kahinaan sa seguridad, sumunod sa prinsipyo ng responsableng pagsisiwalat — panatilihing kumpidensyal ang kahinaan at iulat ito sa nauugnay na partido upang ito ay maayos.
Etika at transparency. Huwag ipakita ang mga pagsubok na ginawa ng AI bilang iyong sariling gawa; Ang pagsasabi na gumagamit ka ng AI sa loob ng koponan ay transparency. Ikaw ang may pananagutan para sa hindi kawastuhan ng isang output na ginawa ng AI — "sinulat ito ng AI" ay hindi isang dahilan.
Mahinang prompt / Malakas na prompt
Mahina: "I-set up ang test pipeline para sa CI."
Strong: "Mag-draft ng CI workflow na YAML para sa GitHub Actions: magpatakbo ng unit + API tests sa bawat PR, bumuo ng coverage report, magpatakbo ng mutation testing (Stryker) linggu-linggo. Huwag mag-embed ng mga lihim sa code; gumamit lang ng secrets reference. I-block ang merge kung pula ang mga test. Isa itong DRAFT; Ire-review at i-edit ko ang lihim na hakbang sa pamamahala at 'pag-validate ng mga hakbang' o HUWAG."
Napakahusay na prompt; Nagpapataw ito ng mga limitasyon sa pagiging kumpidensyal, pagsusuri ng tao, at "walang awtomatikong pagsubok."
Apat na maaaring kopyahin na mga template
1) End-to-end na plano sa pagsubok:
Ang iyong tungkulin: senior QA leader. Mag-draft ng end-to-end na plano sa pagsubok mula sa ideya hanggang sa ilalabas para sa sumusunod na feature: [feature + acceptance criteria]. Mga yugto: pagsusuri ng mga kinakailangan (mga kawalan ng katiyakan), disenyo ng pagsubok, mga layer ng automation (unit/API/UI), pagsasama ng CI/CD, pamantayan ng pagpapasya sa release, pagsubaybay sa produksyon. Tukuyin ang papel ng AI at HUMAN approval point sa bawat yugto nang hiwalay.
2) CI/CD pipeline outline:
CI YAML draft para sa [GitHub Actions/GitLab CI/Azure Pipelines]:- Unit + API test + scope sa PR- Pigilan ang pagsasama sa pulang pagsubok- Mga lihim na halaga lamang na may mga sikreto; pag-embed sa codeIto ay isang draft; Susuriin ko ang mga pangunahing hakbang sa pamamahala at pag-apruba. Pagdaragdag ng autocorrect/pass test step.
3) Nabigong pagsusuri sa log ng pagsubok:
Sa CI printout na iyon, ang mga pagsubok ay pula. Suriin ang log; pangkatin ang mga pagkabigo, tukuyin ang posibleng ugat na sanhi at ALIN ang maaaring tunay na kabiguan at maaaring isang marupok na pagsubok/isyu sa kapaligiran. Kung mayroong personal na data, i-mask ito. Ang desisyon at pagwawasto ay magiging akin. Log: [i-paste]
4) Paunang pagsusuri sa seguridad/pribado:
Bago ipadala ang data/log ng pagsubok na ito sa AI tool, suriin: naglalaman ba ito ng personal na data, API key, address ng panloob na system, data ng produksyon? Ilista kung aling mga lugar, kung mayroon man, ang kailangang takpan/alisin. Pinoproseso kung ano ito. Nilalaman: [i-paste]
tatlong mini case
Case 1 — Bilis ng end-to-end na daloy. Isang team ang humarap sa isang bagong feature na "pag-renew ng subscription" gamit ang isang end-to-end na daloy na pinapagana ng AI: ang mga kawalan ng katiyakan sa mga kinakailangan ay na-flag sa harap, tatlong-layer na pagsubok na na-draft at na-validate ang mutation, na nakatali sa CI. Binawasan ng feature ang ikot ng pagsubok, na tumagal ng 5 araw sa tradisyonal na proseso, sa 2 araw; ngunit ang pag-apruba ng tao ay napanatili sa bawat yugto, at isang kinakailangan na kawalan ng katiyakan (kung ano ang mangyayari kung mabigo ang pag-refresh) ay isinara nang pre-live.
Kaso 2 — Bumalik mula sa pagtagas ng key. Ang isang developer ay nagkaroon ng AI na bumuo ng CI YAML, at ang AI ay nag-embed ng isang tunay na hitsura ng API key sa YAML bilang isang halimbawa. Nakuha ito ng hakbang na "security/privacy precheck"; key na na-convert sa secrets reference. Kung wala ang hakbang sa pag-audit, ang susi ay tatagas sa kontrol ng bersyon (git history).
Kaso 3 — Limitasyon ng awtoridad. Gusto ng isang miyembro ng team na ilapat ang IDOR test na natutunan niya sa live system ng isang business partner dahil sa "Na-curious ako." Huminto ang pinuno ng QA: ilegal na magsagawa ng pagsubok sa seguridad sa ibang sistema nang walang nakasulat na pahintulot at tinukoy na saklaw. Ang pagsubok ay ginawa lamang sa pagsubok na kapaligiran ng kanilang sariling mga produkto, na may awtoridad; Ang bukas na responsableng partido ay naabisuhan sa nauugnay na koponan.
Mga karaniwang pagkakamali
- Ang paggawa ng AI ay gumawa ng mga pagpapasya sa pagpapalabas. Pagtatanong ng "Pwede bang ilabas?" sa AI at inilalagay ang sagot sa lugar ng lagda.
- "Pagpapasa" sa automated na pagsubok. Sa CI, pinintahan ng AI ang pagsubok na berde; pagtatakip ng pagkakamali.
- Pagbibigay ng kumpidensyal na data/susi sa sasakyan. Pagbabahagi ng data ng produksyon, personal na data o mga API key nang walang pangangasiwa.
- Hindi awtorisadong pagsubok sa seguridad. Pagsusuri ng attacker sa ibang system nang walang saklaw at pahintulot.
- Pagpapasok ng mga pagsubok sa pipeline nang walang pagsusuri. Awtomatikong patakbuhin ang AI sketch nang walang pag-apruba ng tao.
- Paglalagay ng sisihin sa AI. Pagtatanggol sa maling output sa pamamagitan ng pagsasabi na "sinulat ito ni AI".
Sa buod
Ang end-to-end na QA ay isang proseso na umaabot mula sa mga kinakailangan hanggang sa pagsubaybay sa produksyon at nabubuhay sa loob ng CI/CD; Sa bawat yugto, ang AI ay gumagawa ng mga draft, nagbubuod ng log, at nagmumungkahi ng mga sanhi ng ugat. Ngunit ang mga hangganan ay hindi nababago: ang mga tao ay gumagawa ng mga desisyon sa pagsubok at naglalabas ng pag-apruba; Ang AI ay hindi kailanman binigyan ng awtoridad na awtomatikong "ipasa" ang pagsubok; ang kumpidensyal na data at mga susi ay hindi pumapasok sa sasakyan; Ang pagsusuri sa seguridad ay isinasagawa lamang sa iyong sariling produkto, sa loob ng nakasulat na awtorisasyon at tinukoy na saklaw, para sa mga layuning nagtatanggol, at ang mga natuklasan ay iniuulat na may responsableng pagsisiwalat. Maging transparent kapag gumagamit ka ng AI; Ikaw ang may pananagutan para sa katumpakan ng output. Bumibilis ang AI; Tinitiyak mo ang kalidad at etika.
Gawain ng aplikasyon
Bumuo ng plano mula sa ideyang ilalabas gamit ang template na "end-to-end test plan" para sa isang feature mula sa sarili mong proyekto; Markahan ang papel ng AI at mga punto ng pag-apruba ng tao nang hiwalay sa bawat yugto. Pagkatapos ay bumuo ng YAML na may "CI/CD pipeline outline" at ilapat ang "security/privacy precheck" sa YAML na ito para tingnan kung may naka-embed na key/secret data. Panghuli, ilista ang lahat ng mga punto ng "pasya ng tao" sa iyong plano at bigyang-katwiran sa isang pangungusap kung bakit hindi maaaring italaga ang mga desisyong ito sa AI.
checklist
- [ ] Iniuugnay ko ang pagpapalabas at pagsubok ng mga desisyon sa pag-apruba ng tao; Hindi ko binigay kay AI.
- [ ] Sa CI/CD hindi ko binigyan ng pahintulot ang AI na awtomatikong "ipasa/itama" ang pagsusulit.
- [ ] Sinuri at tinakpan ko ang kumpidensyal na data, personal na data at mga susi bago ipadala ang mga ito sa sasakyan.
- [ ] Isinaalang-alang ko lang ang pagsubok sa seguridad sa sarili kong produkto, sa loob ng nakasulat na awtorisasyon at saklaw.
- [ ] Tinugunan ko ang mga kahinaang natagpuan sa prinsipyo ng responsableng pagsisiwalat.
- [ ] Malinaw kong sinabi na gumamit ako ng AI at pinanagutan ko ang aking sarili para sa katumpakan ng output.
Pagsusulit sa Module
1. Paano pinakatumpak na tinukoy ang 'false pass' sa konteksto ng QA?
- A) Bagama't nagiging berde ang pagsubok, hindi talaga ito nagkukumpirma ng anumang pag-uugali; ✔ Hindi nagiging pula kahit na sira ang code
- B) Ang pagsusulit ay tumatakbo nang napakabagal at mga oras.
- C) Nakita ng pagsubok ang isang tunay na error at nagiging pula
- D) Ang pagsubok ay tumatakbo lamang sa kapaligiran ng produksyon
Paliwanag: Ang isang pseudo-pass ay kapag ang isang pagsubok ay nagsasabing 'pass' ngunit hindi talaga nagkukumpirma ng anumang bagay na makabuluhan; Ang pagsubok ay berde, ngunit kahit na ang software ay may sira, hindi ito mahuhuli. Ito ang numero unong panganib ng AI sa QA dahil ang AI ay may posibilidad na gumawa ng mga pagsubok na mukhang maayos ngunit walang laman.
2. Ano ang pinakatumpak na pagpoposisyon ng artificial intelligence sa pagsubok at proseso ng QA?
- A) Ang artificial intelligence ay maaaring magpasya kung ang bersyon ay maaaring ilabas nang walang pag-apruba ng tao
- B) Ang artificial intelligence ay isang katulong na bumubuo ng mga draft at ideya; Ang desisyon at responsibilidad ng 'handa na ba ito para sa publikasyon' ay pagmamay-ari ng eksperto ✔
- C) Ang artificial intelligence ay nagsusulat lamang ng teksto at hindi maaaring makitungo sa test code sa lahat
- D) Ang artificial intelligence ay palaging nagsusulat ng tamang pagsubok kaysa sa tao, kaya hindi kailangan ang pagsusuri
Paglalarawan: Ang artificial intelligence ay isang testing assistant, draft generator at idea multiplier; gumagawa ng mga senaryo ng pagsubok, automation code at mga draft ng ulat. Gayunpaman, ang responsibilidad at panghuling pag-apruba ng mga de-kalidad na desisyon tulad ng 'handa na ba ang software na ito para sa publikasyon' o 'naipasa na ba ang pagsusulit na ito' ay pagmamay-ari ng karampatang eksperto.
3. Batay sa katotohanan na ang mga error ay kadalasang nangyayari sa mga halaga ng threshold, aling diskarte sa disenyo ng pagsubok ang hiwalay na pagsubok sa 17, 18 at 19 para sa 18 na limitasyon sa edad?
- A) Pagsubok sa paglipat ng estado
- B) Talaan ng desisyon
- C) Pagsusuri sa halaga ng hangganan ✔
- D) Exploratory testing
Paliwanag: Ang pagsusuri sa hangganan ng halaga ay batay sa obserbasyon na ang mga error ay kadalasang nangyayari sa mga hangganan at sumusubok sa mga halaga ng threshold (sa ibaba lamang, sa itaas lamang, at sa itaas lamang ng limitasyon) nang hiwalay. Ito ay isang makapangyarihang pamamaraan na umaakma sa mga klase ng equivalence.
4. Aling diskarte ang dapat na mas gusto sa pagpili ng elemento upang mabawasan ang pagkasira sa UI test automation code na ginawa gamit ang artificial intelligence?
- A) Gamit ang pinakamahabang XPath path na posible
- B) Pagpili ng elemento ayon sa posisyon ng pixel nito sa screen
- C) Paggamit ng mga tagapili batay sa mga pangalan ng klase ng CSS
- D) Paggamit ng mga stable na attribute (data-testid) na idinagdag para sa pagsubok ✔
Paliwanag: Ang mga mahabang XPath path at mga pangalan ng klase ng CSS ay lubos na nakadepende sa istraktura at disenyo ng pahina; Nasira ito sa kaunting pagbabago sa interface. Ang mga matatag na attribute na partikular na idinagdag para sa pagsubok (hal. data-testid) ay hindi apektado ng mga pagbabago sa disenyo at ginagawang matatag ang mga pagsubok.
5. Bakit hindi sapat para sa isang pagsubok sa API na tingnan lamang ang HTTP status code (hal. 200)?
- A) Dahil ang data ng katawan na may tamang status code ay maaaring masira at ang pagsuri ng status lamang ay hindi makakahuli nito (pseudo-trust) ✔
- B) Dahil hindi maaasahan ang mga status code sa mga pagsubok sa API
- C) Dahil ang pagsusuri ng status code ay nagpapabagal nang husto sa pagsubok
- D) Dahil hindi ibinabalik ang status code sa mga pagsubok sa API
Paliwanag: Habang ibinabalik ng server ang tamang status code, maaari itong magbalik ng sirang data sa katawan (maling uri, nawawalang field, maling nakalkulang halaga). Ang pagsubok na tumitingin lamang sa sitwasyon ay hindi makikita ito at nagbibigay ng maling kumpiyansa. Kaya dapat ding idagdag ang schema/contract at business rule validation.
6. Bakit mahalagang sabihin sa AI na 'manu-manong kalkulahin ang inaasahang halaga ayon sa tuntunin sa pagtanggap, huwag i-reference ang kasalukuyang output ng function' kapag nagpi-print ng mga pagsubok sa unit?
- A) Dahil ang manu-manong pagkalkula ay nagpapatakbo ng mga pagsubok nang mas mabilis
- B) Dahil kung hindi, tinatanggap ng pagsubok ang kasalukuyang (marahil maraming buggy) na pag-uugali ng code bilang 'tama' at kinukumpirma ang bug ✔
- C) Dahil hindi makalkula ng artificial intelligence ang mga decimal na numero
- D) Dahil ang mga tuntunin sa pagtanggap ay hindi kailanman ginagamit sa mga pagsusulit
Paliwanag: Kung nakukuha ng AI ang inaasahang halaga mula sa output ng function na nasa ilalim ng pagsubok, gagawin nitong 'pass' ang pagsubok kahit na mali ang function; Iyon ay, anuman ang ginawa ng code, ang pagsubok ay binibilang bilang totoo. Ang pagkalkula ng inaasahang halaga nang hiwalay sa tuntunin sa pagtanggap ay tumitiyak na ang pagsubok ay isang gatekeeper sa panuntunan, hindi isang salamin ng code.
7. Alin sa mga sumusunod ang pinakanakikilalang katangian ng isang magandang ulat ng bug?
- A) Upang maging kasing haba at teknikal hangga't maaari
- B) Isinulat ng artificial intelligence
- C) Naglalaman ng mga tiyak na hakbang sa pagpaparami na maaaring sundin ng developer nang nakapag-iisa at makagawa ng error ✔
- D) Ito ay isang screenshot lamang
Paliwanag: Ang tunay na halaga ng isang ulat ng bug ay maaaring kopyahin ng developer ang bug nang wala ang iyong tulong. Ang mga deterministiko, nasusubaybayang mga hakbang sa pagpaparami mula sa simula ay tiyakin ito; Kung ang mga hakbang na ito ay nawawala, ang ulat ay madalas na nagsasara bilang 'hindi makagawa'.
8. Alin ang pinakatumpak na expression para sa kaugnayan sa pagitan ng kalubhaan at priyoridad sa pagkakamali ng maling spelling ng pangalan ng kumpanya sa home page?
- A) Ang intensity at priority ay dapat palaging may parehong halaga
- B) Parehong mababa ang kalubhaan at priyoridad ng error na ito
- C) Ang kalubhaan at priyoridad ay pareho ang konsepto, sapat na ang isang label
- D) Maaaring mababa ang teknikal na intensidad ngunit maaaring mataas ang priyoridad ng negosyo (reputasyon); Magkaiba ang pagsusuri sa dalawa ✔
Paliwanag: Ang kalubhaan ay ang teknikal na epekto ng error (typo technically low), ang priyoridad ay kung gaano kabilis ito kailangang ayusin (mataas dahil isa itong elemento ng reputasyon na nakikita ng bawat bisita). Ang dalawa ay hindi palaging pumunta sa parehong direksyon; Ang halimbawang ito ay isang mababang kalubhaan-mataas na priyoridad na sitwasyon.
9. Alin ang pinakatumpak na interpretasyon ng isang test suite na may 90% line coverage?
- A) Ipinapakita nito na ang mga linya ay naisakatuparan ngunit hindi nagpapatunay na ang mga ito ay kumikilos nang tama; ✔ ang mataas na coverage ay maaaring magbigay ng maling kumpiyansa
- B) Conclusively proves na 90% ng software ay bug-free
- C) Ito ay isang tiyak na sukatan ng mahusay na kalidad ng pagsubok.
- D) Nagsasaad na hindi na kailangang magsulat ng anumang karagdagang pagsusulit
Paliwanag: Isinasaad ng saklaw ng row na mga row lang ang naisagawa; Hindi nito pinatutunayan na ito ay gumagawa ng mga tamang resulta. Kahit na may mga pagsubok na walang paninindigan, 90% ang saklaw ay maaaring makamit. Ang saklaw ay isang 'hindi kailanman tumingin kung saan' mapa, hindi isang 'lahat ng bagay ay nasubok na' katiyakan; ang aktwal na proteksyon ay sinusukat sa pamamagitan ng mutation testing.
10. Sa pagsubok na nakabatay sa panganib, paano kinakalkula ang panganib ng isang tampok upang idirekta ang limitadong pagsisikap sa pagsubok?
- A) Sa pamamagitan lamang ng bilang ng mga linya ng code
- B) Sa pamamagitan ng pagpaparami ng posibilidad ng pagkabigo at ang epekto na magaganap kapag ito ay nasira ✔
- C) Sa pagkakasunud-sunod lamang kung saan binuo ang tampok
- D) Priyoridad lamang ang tampok na pinakamadaling sulatan ng mga pagsubok
Paliwanag: Sa pagsubok na nakabatay sa panganib, sinusuri ang panganib bilang probabilidad = probabilidad (posibilidad ng pagkasira) × epekto (pinsala kung nasira). Ang mga domain na may mataas na posibilidad at may mataas na epekto (pagbabayad, pagpapatotoo) ay nararapat sa pinakamatinding pagsubok, habang ang mga domain na mababa×mababa ay tumatanggap ng magaan na pagsubok.
11. Ano ang pangunahing panganib ng pagdaragdag ng isang muling pagsubok sa isang pagsubok na kung minsan ay pumasa at kung minsan ay nabigo (malutong/tumpik-tumpik) kahit na ang code ay hindi nagbago?
- A) Paikliin ang oras ng pagtakbo ng pagsusulit
- B) Binabawasan ang porsyento ng saklaw
- C) Pagtakpan ng totoong concurrency error o ugat na sanhi at pagsugpo sa sintomas ✔
- D) Pagpapalit ng pangalan ng pagsusulit
Paliwanag: Ang muling subukan ay isang diagnostic tool, hindi isang paggamot. Ang pag-aalinlangan ay kadalasang nagmumula sa isang aktwal na kondisyon ng lahi o pagkagumon; Ang paggawa ng pagsubok sa pamamagitan ng muling pagsubok ay sumasaklaw sa tunay na error na ito at maaaring magdulot ng malubhang problema sa live. Kailangang hanapin muna ang ugat na dahilan.
12. Paano gumagana ang pagsusuri sa mutation, ang pinakatapat na paraan ng pagsukat kung talagang nagpoprotekta ang isang test suite?
- A) Sa pamamagitan ng pagsukat sa bilis ng pagtakbo ng mga pagsubok
- B) Sa pamamagitan ng pagbilang kung ilang linya ng code ang isinulat
- C) Sa pamamagitan ng pagpapatakbo ng mga pagsubok sa iba't ibang mga order
- D) Sa pamamagitan ng sadyang paggawa ng maliliit na break sa code at pagsukat kung ang mga pagsubok ay nakuha ✔
Paglalarawan: Ang pagsusuri sa mutation ay gumagawa ng maliliit na intensyonal na pagbaluktot (mutations) sa source code; Ang isang mahusay na suite ng pagsubok ay dapat mahuli ang mga pagbaluktot na ito at maging pula. Ang mga mutasyon na hindi nahuli (nakaligtas) ay nagpapahiwatig na ang mga pagsubok ay hindi nagpapanatili ng pag-uugaling iyon. Ang marka ng mutation ay isang mas matapat na sukat ng kalidad kaysa sa saklaw ng porsyento.
13. Ano ang pangunahing limitasyon na dapat sundin kapag nagsasagawa ng pagsubok sa seguridad (hal. mga pagsusuri sa awtorisasyon/IDOR)?
- A) Dapat lamang itong gawin sa sarili nitong produkto, sa loob ng nakasulat na awtorisasyon at tinukoy na saklaw, para sa mga layuning nagtatanggol ✔
- B) Maaari itong malayang ilapat sa anumang sistema ng interes
- C) Maaari itong subukan sa mga live na sistema ng mga kasosyo sa negosyo nang walang pahintulot
- D) Ang anumang mga kahinaan na makikita ay dapat na agad na mailathala sa publiko.
Paglalarawan: Ang mga pagsubok na panseguridad na natutunan sa modyul na ito ay para lamang sa pagsubok ng iyong sariling produkto para sa mga layunin ng pagtatanggol, sa loob ng nakasulat na awtorisasyon at tinukoy na saklaw. Ang pag-access sa system ng ibang tao nang walang pahintulot o pagsasagawa ng out-of-scope na pagsubok ay parehong hindi etikal at ilegal; Ang anumang mga kahinaan na natagpuan ay iniuulat sa pamamagitan ng responsableng pagsisiwalat.
14. Anong awtoridad ang hindi dapat ibigay sa AI sa pipeline ng CI/CD?
- A) Pagbubuod ng mga nabigong log ng pagsubok
- B) Ang awtoridad na awtomatikong 'ipasa' ang isang nabigong (pula) na pagsusulit o pinturahan ito ng berde ✔
- C) Pagmumungkahi ng draft ng test code
- D) Pipeline YAML file drafting
Paglalarawan: Maaaring gumawa ang AI ng test code outline, pipeline YAML, at log summary sa CI/CD; gayunpaman, ang kakayahang awtomatikong 'ipasa/ayusin' ang isang nabigong pagsusulit ay hindi dapat kailanman ibigay. Tinatalo nito ang layunin ng pagsubok at awtomatikong tinatakpan ang mga error. Ang pagpipinta ng berdeng pagsubok ay dapat na mulat at makatuwirang desisyon ng isang tao.