Κέρδη:
- Ικανότητα σχεδιασμού του ρόλου της τεχνητής νοημοσύνης και των ανθρώπινων σημείων έγκρισης στη ροή διασφάλισης ποιότητας από άκρο σε άκρο από την ιδέα στην κυκλοφορία στο πλαίσιο του CI/CD
- Στο CI/CD, δεν εξουσιοδοτεί την τεχνητή νοημοσύνη να «περάσει» αυτόματα τη δοκιμή, αλλά εφαρμόζει όρια για την προστασία εμπιστευτικών δεδομένων και κλειδιών
- Ικανότητα διεξαγωγής δοκιμών ασφαλείας εντός των αρχών και για αμυντικούς σκοπούς και υιοθέτησης αρχών υπεύθυνης αποκάλυψης και ηθικής διαφάνειας.
Στις δέκα προηγούμενες ενότητες, χρησιμοποιήσαμε AI σε μεμονωμένες εργασίες: δημιουργία σεναρίων, κώδικας αυτοματισμού, αναφορά σφαλμάτων, ανάλυση κάλυψης, δοκιμή μεταλλάξεων. Αυτή η τελική ενότητα τα συνδυάζει όλα σε μια υπεύθυνη ροή εργασίας. Το σύγχρονο QA δεν είναι μια δουλειά που τελειώνει στο γραφείο ενός ατόμου. Είναι μια διαδικασία που ζει μέσα στο CI/CD (Continuous Integration / Continuous Delivery — ο αγωγός όπου ο κώδικας συνδυάζεται συνεχώς, δοκιμάζεται αυτόματα και προετοιμάζεται για δημοσίευση συχνά και με ασφάλεια). Το AI μπορεί να αγγίξει κάθε στάδιο αυτής της διαδικασίας. Αλλά καθώς η δύναμη της τεχνητής νοημοσύνης μεγαλώνει, τόσο αυξάνεται η σημασία της υπεύθυνης χρήσης της: απόρρητο, εξουσία στις δοκιμές ασφαλείας, ηθική και, το πιο σημαντικό, διατήρηση της απόφασης για την ποιότητα στον άνθρωπο. Σε αυτή την ενότητα, θα μάθετε τη ροή και τα όρια από άκρο σε άκρο.
Ροή QA από άκρο σε άκρο με τεχνητή νοημοσύνη
Ο ρόλος του AI στο ταξίδι ενός χαρακτηριστικού από την ιδέα στην κυκλοφορία:
1. Ανάλυση απαιτήσεων. Το AI επισημαίνει ασάφειες στην απαίτηση και ελλείποντα κριτήρια αποδοχής ("αυτός ο κανόνας δεν λέει πόσους χαρακτήρες είναι ο ελάχιστος κωδικός πρόσβασης").
2. Σχεδιασμός δοκιμής. Τα προσχέδια σεναρίων και περιπτώσεων (ενότητα 2), ακραίες περιπτώσεις (ενότητα 3) είναι μεταξύ των κριτηρίων αποδοχής.
3. Αυτοματισμός. Προσχέδια κωδικών δοκιμής ενότητας (6), API (5) και διεπαφής χρήστη (4). το καθένα επιβεβαιώνεται με μετάλλαξη (10).
4. Ενσωμάτωση CI/CD. Οι δοκιμές εκτελούνται αυτόματα με κάθε συγχώνευση κώδικα. Η τεχνητή νοημοσύνη σχεδιάζει τη διαμόρφωση αγωγών (YAML), συνοψίζει αρχεία καταγραφής αποτυχημένων δοκιμών, προτείνει πιθανή βασική αιτία.
5. Απόφαση αποδέσμευσης. Τα αποτελέσματα της ανάλυσης κινδύνου (8) και της παλινδρόμησης (9) συλλέγονται — αλλά ο ειδικός αποφασίζει εάν μπορεί να είναι επιτυχής.
6. Παρακολούθηση παραγωγής και ανατροφοδότηση. Τα σφάλματα στο live γίνονται μελλοντικές δοκιμές. Το AI προτείνει μια περίπτωση παλινδρόμησης από κατασκευαστικό ελάττωμα.
Συμβουλή: Ρυθμίστε την τεχνητή νοημοσύνη ως ένα επίπεδο στο CI/CD που «επιταχύνει τα προσχέδια που ελέγχονται από τον άνθρωπο» αντί να «γράφει δοκιμές και λαμβάνει αποφάσεις». Δεν πρέπει να εισαχθούν δοκιμές που δημιουργούνται αυτόματα χωρίς να τις αναθεωρήσει και να τις εγκρίνει από άνθρωπο.
AI σε CI/CD: όπου ναι, όπου όχι
Σκηνή
Ταίριασμα AI
ο άνθρωπος είναι απαραίτητος
Δοκιμαστικό προσχέδιο κώδικα
Ναι
Αναθεώρηση + μετάλλαξη
Βύθισμα αγωγού YAML
Ναι
Έλεγχος ταυτότητας + έλεγχος μυστικού κλειδιού
Αποτυχημένη σύνοψη αρχείου καταγραφής
Ναι
Επιβεβαίωση ριζικής αιτίας
Διάγνωση εύθραυστου τεστ
Ναι
Απόφαση μόνιμης λύσης
"Μπορεί να υπάρξει μια έκδοση;"
όχι
Ειδική κρίση και ευθύνη
"Περάστε" αυτόματα το τεστ
ποτέ
—
Προσοχή: Ποτέ μην δίνετε στο AI μια εντολή όπως "διορθώστε το για να περάσει το τεστ αποτυχίας" στο CI/CD. Αυτό ακυρώνει τον σκοπό της δοκιμής και καλύπτει αυτόματα τα λάθη. Το AI μπορεί να εξηγήσει το σφάλμα, να προτείνει διόρθωση. αλλά το «βάψιμο του τεστ με πράσινο» πρέπει να είναι η συνειδητή, αιτιολογημένη απόφαση ενός ατόμου.
Απόρρητο, δεδομένα και ασφάλεια: αμετάβλητα όρια
Απόρρητο. Στο περιβάλλον δοκιμής, τα πραγματικά δεδομένα πελατών, τα αντίγραφα της βάσης δεδομένων παραγωγής, τα κλειδιά API και οι πληροφορίες εσωτερικού συστήματος είναι ευαίσθητα. Μην τα δίνετε σε δημόσια εργαλεία AI. Τα προσωπικά δεδομένα υπόκεινται σε KVKK και παρόμοιους κανονισμούς. Καταγραφή μάσκας και στιγμιότυπα οθόνης. Χρησιμοποιήστε συνθετικά (φανταστικά) δεδομένα δοκιμών όπου είναι δυνατόν.
Δοκιμή ασφαλείας — αμυντική και εξουσιοδοτημένη. Οι δοκιμές ασφαλείας που μαθαίνονται σε αυτήν την ενότητα (δοκιμές εξουσιοδότησης/IDOR, όρια μεταφόρτωσης αρχείων, επικύρωση εισόδου) προορίζονται μόνο για τη δοκιμή του δικού σας προϊόντος εντός της γραπτής εξουσιοδότησης και του καθορισμένου πεδίου εφαρμογής. Η χρήση της τεχνητής νοημοσύνης για πρόσβαση στο σύστημα κάποιου άλλου χωρίς άδεια, η χρήση όπλων σε πραγματικές ευπάθειες ή η εκτέλεση δοκιμών εκτός πεδίου είναι τόσο ανήθικο όσο και παράνομο. Όταν εντοπίσετε ένα θέμα ευπάθειας ασφαλείας, συμμορφωθείτε με την αρχή της υπεύθυνης αποκάλυψης — να διατηρείτε το θέμα ευπάθειας εμπιστευτικό και να το αναφέρετε στο σχετικό μέρος, ώστε να μπορεί να διορθωθεί.
Ηθική και διαφάνεια. Μην παρουσιάζετε τα τεστ που παράγονται από την τεχνητή νοημοσύνη ως δική σας δουλειά. Το να δηλώνετε ότι χρησιμοποιείτε AI στην ομάδα είναι διαφάνεια. Είστε υπεύθυνοι για την ανακρίβεια ενός προϊόντος που παράγεται από την τεχνητή νοημοσύνη — το "το έγραψε το AI" δεν αποτελεί δικαιολογία.
Αδύναμη προτροπή / Ισχυρή προτροπή
Αδύναμο: "Ρύθμιση δοκιμαστικού αγωγού για CI."
Ισχυρή: "Σχέδιο ροής εργασίας CI για ενέργειες GitHub: εκτέλεση δοκιμών μονάδας + API σε κάθε PR, δημιουργία αναφοράς κάλυψης, εκτέλεση δοκιμών μετάλλαξης (Stryker) εβδομαδιαίως. Μην ενσωματώνετε μυστικά στον κώδικα. Χρησιμοποιήστε μόνο αναφορά μυστικών. Αποκλεισμός συγχώνευσης εάν οι δοκιμές είναι κόκκινες. Αυτό είναι ένα DRAFT. δοκιμάζοντας το βήμα «διόρθωση» ή «μετεγκατάσταση»».
Ισχυρή προτροπή. Επιβάλλει όρια στην εμπιστευτικότητα, τον ανθρώπινο έλεγχο και «χωρίς αυτοματοποιημένες δοκιμές».
Τέσσερα πρότυπα με δυνατότητα αντιγραφής
1) Σχέδιο δοκιμών από άκρο σε άκρο:
Ο ρόλος σας: ανώτερος ηγέτης QA. Σχεδιάστε ένα σχέδιο δοκιμών από άκρο σε άκρο από ιδέα σε κυκλοφορία για την ακόλουθη δυνατότητα: [λειτουργία + κριτήρια αποδοχής]. Φάσεις: ανάλυση απαιτήσεων (αβεβαιότητες), σχεδιασμός δοκιμής, επίπεδα αυτοματισμού (μονάδα/API/UI), ενοποίηση CI/CD, κριτήρια απόφασης έκδοσης, παρακολούθηση παραγωγής. Προσδιορίστε τον ρόλο των σημείων έγκρισης AI και HUMAN σε κάθε στάδιο ξεχωριστά.
2) Περίγραμμα αγωγού CI/CD:
Προσχέδιο CI YAML για [GitHub Actions/GitLab CI/Azure Pipelines]:- Μονάδα + δοκιμή API + εύρος στο PR- Αποτροπή συγχώνευσης σε κόκκινο τεστ- Μυστικές τιμές μόνο με μυστικά. ενσωμάτωση σε κώδικα Αυτό είναι ένα προσχέδιο. Θα εξετάσω τα βασικά βήματα διαχείρισης και έγκρισης. Προσθήκη βήματος δοκιμής αυτόματης διόρθωσης/επιτυχίας.
3) Αποτυχημένη ανάλυση καταγραφής δοκιμής:
Σε αυτήν την εκτύπωση CI, τα τεστ είναι κόκκινα. Εξετάστε το αρχείο καταγραφής. ομαδοποιήστε τις αποτυχίες, διακρίνετε την πιθανή βασική αιτία και ΠΟΙΑ μπορεί να είναι η πραγματική αποτυχία και ποια μπορεί να είναι ένα εύθραυστο ζήτημα δοκιμής/περιβάλλοντος. Εάν υπάρχουν προσωπικά δεδομένα, καλύψτε τα. Η απόφαση και η διόρθωση θα είναι δική μου. Καταγραφή: [επικόλληση]
4) Προέλεγχος ασφάλειας/απόρρητου:
Πριν σταλούν αυτά τα δεδομένα/καταγραφή δοκιμής στο εργαλείο AI, ελέγξτε: περιέχει προσωπικά δεδομένα, κλειδί API, εσωτερική διεύθυνση συστήματος, δεδομένα παραγωγής; Καταγράψτε ποιες περιοχές, εάν υπάρχουν, πρέπει να καλυφθούν/αφαιρηθούν. Επεξεργασία ως έχει. Περιεχόμενο: [επικόλληση]
τρεις μίνι θήκες
Περίπτωση 1 — Ταχύτητα ροής από άκρο σε άκρο. Μια ομάδα αντιμετώπισε μια νέα δυνατότητα «ανανέωσης συνδρομής» με μια ροή από άκρο σε άκρο που υποστηρίζεται από AI: αβεβαιότητες απαιτήσεων επισημάνθηκαν εκ των προτέρων, δοκιμές τριών επιπέδων συντάχθηκαν και επικυρώθηκαν με μετάλλαξη, συνδεδεμένα με το CI. Το χαρακτηριστικό μείωσε τον κύκλο δοκιμών, ο οποίος χρειάστηκε 5 ημέρες στην παραδοσιακή διαδικασία, σε 2 ημέρες. αλλά η ανθρώπινη έγκριση διατηρήθηκε σε κάθε στάδιο και η αβεβαιότητα των απαιτήσεων (τι θα συμβεί αν αποτύχει η ανανέωση) έκλεισε πριν από τη ζωή.
Περίπτωση 2 — Επιστροφή από διαρροή κλειδιού. Ένας προγραμματιστής έβαλε το AI να δημιουργήσει το CI YAML και το AI ενσωμάτωσε ένα κλειδί API με πραγματική εμφάνιση στο YAML ως παράδειγμα. Το βήμα "προέλεγχος ασφάλειας/απόρρητου" κατέγραψε αυτό. κλειδί που μετατράπηκε σε μυστική αναφορά. Χωρίς το βήμα ελέγχου, το κλειδί θα διέρρεε στον έλεγχο έκδοσης (ιστορικό git).
Περίπτωση 3 — Όριο εξουσίας. Ένα μέλος της ομάδας ήθελε να εφαρμόσει το τεστ IDOR που έμαθε στο ζωντανό σύστημα ενός επιχειρηματικού συνεργάτη από το «Ήμουν περίεργος». Ο ηγέτης QA σταμάτησε: είναι παράνομη η εκτέλεση δοκιμών ασφαλείας σε άλλο σύστημα χωρίς γραπτή εξουσιοδότηση και καθορισμένο πεδίο εφαρμογής. Οι δοκιμές έγιναν μόνο στο περιβάλλον δοκιμής των δικών τους προϊόντων, με εξουσιοδότηση. Ο ανοιχτός υπεύθυνος ειδοποιήθηκε στην αρμόδια ομάδα.
Συνήθη λάθη
- Η λήψη αποφάσεων για την έκδοση του AI. Θέτοντας την ερώτηση "Μπορεί να κυκλοφορήσει;" στο AI και βάζοντας την απάντηση στη θέση της υπογραφής.
- «Περνώντας» το αυτοματοποιημένο τεστ. Στο CI, έχοντας το AI να βάψει το τεστ με πράσινο. συγκάλυψη λαθών.
- Δίνοντας εμπιστευτικά δεδομένα/κλειδί στο όχημα. Κοινή χρήση δεδομένων παραγωγής, προσωπικών δεδομένων ή κλειδιών API χωρίς επίβλεψη.
- Μη εξουσιοδοτημένη δοκιμή ασφαλείας. Δοκιμή εισβολέα σε άλλο σύστημα χωρίς πεδίο εφαρμογής και άδεια.
- Εισαγωγή δοκιμών στον αγωγό χωρίς επανεξέταση. Αυτόματη εκτέλεση του σκίτσου AI χωρίς ανθρώπινη έγκριση.
- Ρίχνοντας την ευθύνη στην τεχνητή νοημοσύνη. Υπερασπίζοντας τη λανθασμένη έξοδο λέγοντας "Το έγραψε το AI".
Συνοπτικά
Η διασφάλιση της ποιότητας από άκρο σε άκρο είναι μια διαδικασία που εκτείνεται από τις απαιτήσεις έως την παρακολούθηση παραγωγής και ζει εντός CI/CD. Σε κάθε στάδιο, η τεχνητή νοημοσύνη παράγει προσχέδια, συνοψίζει το αρχείο καταγραφής και προτείνει τις βασικές αιτίες. Αλλά τα όρια είναι αμετάβλητα: οι άνθρωποι παίρνουν αποφάσεις δοκιμών και εκδίδουν έγκριση. Το AI δεν έχει ποτέ την εξουσία να «περάσει» αυτόματα τη δοκιμή. εμπιστευτικά δεδομένα και κλειδιά δεν εισέρχονται στο όχημα. Οι δοκιμές ασφαλείας εκτελούνται μόνο στο δικό σας προϊόν, εντός της γραπτής εξουσιοδότησης και του καθορισμένου πεδίου εφαρμογής, για αμυντικούς σκοπούς και τα ευρήματα αναφέρονται με υπεύθυνη αποκάλυψη. Να είστε διαφανείς όταν χρησιμοποιείτε AI. Είστε υπεύθυνοι για την ακρίβεια της εξόδου. Το AI επιταχύνει. Εσείς εγγυάστε την ποιότητα και την ηθική.
Εργασία εφαρμογής
Σχεδιάστε ένα σχέδιο από ιδέα σε κυκλοφορία με ένα πρότυπο "δοκιμαστικό σχέδιο από άκρο σε άκρο" για ένα χαρακτηριστικό από το δικό σας έργο. Σημειώστε τον ρόλο της τεχνητής νοημοσύνης και των ανθρώπινων σημείων έγκρισης ξεχωριστά σε κάθε στάδιο. Στη συνέχεια, δημιουργήστε ένα YAML με "Περίγραμμα διοχέτευσης CI/CD" και εφαρμόστε τον "προέλεγχο ασφαλείας/απόρρητου" σε αυτό το YAML για να ελέγξετε για ενσωματωμένα δεδομένα κλειδιού/μυστικών δεδομένων. Τέλος, απαριθμήστε όλα τα σημεία «ανθρώπινων αποφάσεων» στο σχέδιό σας και αιτιολογήστε με μία φράση γιατί αυτές οι αποφάσεις δεν μπορούν να ανατεθούν στο AI.
λίστα ελέγχου
- [ ] Αποδίδω τις αποφάσεις απελευθέρωσης και δοκιμών στην ανθρώπινη έγκριση. Δεν το παρέδωσα στην ΑΙ.
- [ ] Στο CI/CD δεν έδωσα στο AI την άδεια να "περάσει/διορθώσει" αυτόματα τη δοκιμή.
- [ ] Έλεγξα και κάλυψα εμπιστευτικά δεδομένα, προσωπικά δεδομένα και κλειδιά πριν τα στείλω στο όχημα.
- [ ] Έχω εξετάσει το ενδεχόμενο δοκιμής ασφαλείας μόνο στο δικό μου προϊόν, εντός της γραπτής εξουσιοδότησης και του πεδίου εφαρμογής.
- [ ] Αντιμετώπισα τα τρωτά σημεία που εντοπίστηκαν με την αρχή της υπεύθυνης αποκάλυψης.
- [ ] Δήλωσα με διαφάνεια ότι χρησιμοποίησα AI και θεωρούσα τον εαυτό μου υπεύθυνο για την ακρίβεια της εξόδου.
Εξέταση Ενοτήτων
1. Πώς ορίζεται με μεγαλύτερη ακρίβεια το "false pass" στο πλαίσιο QA;
- Α) Αν και το τεστ γίνεται πράσινο, δεν επιβεβαιώνει στην πραγματικότητα καμία συμπεριφορά. ✔ Δεν γίνεται κόκκινο ακόμα κι αν ο κωδικός είναι κατεστραμμένος
- Β) Το τεστ τρέχει πολύ αργά και τελειώνει.
- Γ) Το τεστ ανιχνεύει πραγματικό σφάλμα και γίνεται κόκκινο
- Δ) Η δοκιμή εκτελείται μόνο στο περιβάλλον παραγωγής
Εξήγηση: Ένα ψευδο-πάσο είναι όταν ένα τεστ λέει «περάσω» αλλά στην πραγματικότητα δεν επιβεβαιώνει τίποτα σημαντικό. Το τεστ είναι πράσινο, αλλά ακόμα κι αν το λογισμικό είναι ελαττωματικό, δεν θα το πιάσει. Αυτός είναι ο νούμερο ένα κίνδυνος της τεχνητής νοημοσύνης στο QA, επειδή η τεχνητή νοημοσύνη τείνει να παράγει τεστ που φαίνονται προσεγμένα αλλά είναι κούφια.
2. Ποια είναι η πιο ακριβής τοποθέτηση της τεχνητής νοημοσύνης στη διαδικασία δοκιμών και QA;
- Α) Η τεχνητή νοημοσύνη μπορεί να αποφασίσει εάν η έκδοση μπορεί να κυκλοφορήσει χωρίς ανθρώπινη έγκριση
- Β) Η τεχνητή νοημοσύνη είναι ένας βοηθός που δημιουργεί προσχέδια και ιδέες. Η απόφαση και η ευθύνη του «είναι έτοιμο για δημοσίευση» ανήκει στον ειδικό ✔
- Γ) Η τεχνητή νοημοσύνη γράφει μόνο κείμενο και δεν μπορεί να ασχοληθεί καθόλου με τον κώδικα δοκιμής
- Δ) Η τεχνητή νοημοσύνη γράφει πάντα το σωστό τεστ από το ανθρώπινο, οπότε η αναθεώρηση είναι περιττή
Περιγραφή: Η τεχνητή νοημοσύνη είναι ένας βοηθός δοκιμών, δημιουργία σχεδίων και πολλαπλασιαστής ιδεών. παράγει σενάρια δοκιμών, κώδικα αυτοματισμού και προσχέδια αναφορών. Ωστόσο, η ευθύνη και η τελική έγκριση των αποφάσεων ποιότητας όπως «είναι αυτό το λογισμικό έτοιμο για δημοσίευση» ή «έχει περάσει αυτό το τεστ» ανήκει στον αρμόδιο εμπειρογνώμονα.
3. Βάσει του γεγονότος ότι τα σφάλματα συμβαίνουν ως επί το πλείστον σε τιμές κατωφλίου, ποια τεχνική σχεδιασμού δοκιμής είναι να δοκιμάζονται τα 17, 18 και 19 χωριστά για το όριο ηλικίας των 18 ετών;
- Α) Δοκιμή μετάβασης κατάστασης
- Β) Πίνακας αποφάσεων
- Γ) Ανάλυση οριακής τιμής ✔
- Δ) Διερευνητικός έλεγχος
Εξήγηση: Η ανάλυση οριακών τιμών βασίζεται στην παρατήρηση ότι τα σφάλματα συμβαίνουν συχνότερα στα όρια και δοκιμάζει τις τιμές κατωφλίου (ακριβώς κάτω, ακριβώς πάνω και ακριβώς πάνω από το όριο) χωριστά. Είναι μια ισχυρή τεχνική που συμπληρώνει τις τάξεις ισοδυναμίας.
4. Ποια προσέγγιση πρέπει να προτιμάται στην επιλογή στοιχείων για τη μείωση της ευθραυστότητας στον κώδικα αυτοματισμού δοκιμής διεπαφής χρήστη που παράγεται με τεχνητή νοημοσύνη;
- Α) Χρησιμοποιώντας τη μεγαλύτερη δυνατή διαδρομή XPath
- Β) Επιλογή του στοιχείου σύμφωνα με τη θέση του pixel στην οθόνη
- Γ) Χρήση επιλογέων με βάση τα ονόματα κλάσεων CSS
- Δ) Χρήση σταθερών χαρακτηριστικών (data-testid) που προστέθηκαν για τη δοκιμή ✔
Επεξήγηση: Οι μεγάλες διαδρομές XPath και τα ονόματα κλάσεων CSS εξαρτώνται εξαιρετικά από τη δομή και το σχεδιασμό της σελίδας. Σπάει με την παραμικρή αλλαγή διεπαφής. Τα σταθερά χαρακτηριστικά που προστίθενται ειδικά για δοκιμές (π.χ. data-testid) δεν επηρεάζονται από τις αλλαγές σχεδιασμού και καθιστούν τις δοκιμές ισχυρές.
5. Γιατί είναι ανεπαρκές για μια δοκιμή API να ελέγχει απλώς τον κωδικό κατάστασης HTTP (π.χ. 200);
- Α) Επειδή τα δεδομένα σώματος με τον σωστό κωδικό κατάστασης μπορεί να είναι κατεστραμμένα και ο έλεγχος κατάστασης από μόνος του δεν θα το καταλάβει (ψευδο-εμπιστοσύνη) ✔
- Β) Επειδή οι κωδικοί κατάστασης δεν είναι καθόλου αξιόπιστοι στις δοκιμές API
- Γ) Επειδή ο έλεγχος του κωδικού κατάστασης επιβραδύνει πολύ το τεστ
- Δ) Επειδή ο κωδικός κατάστασης δεν επιστρέφεται ποτέ σε δοκιμές API
Επεξήγηση: Ενώ ο διακομιστής επιστρέφει τον σωστό κωδικό κατάστασης, ενδέχεται να επιστρέψει κατεστραμμένα δεδομένα στο σώμα (λάθος τύπος, πεδίο που λείπει, εσφαλμένη υπολογισμένη τιμή). Το τεστ που κοιτάζει μόνο την κατάσταση δεν μπορεί να το δει αυτό και δίνει ψεύτικη εμπιστοσύνη. Επομένως, θα πρέπει επίσης να προστεθεί η επικύρωση σχήματος/συμβολαίου και επιχειρηματικών κανόνων.
6. Γιατί είναι σημαντικό να πείτε στην τεχνητή νοημοσύνη να «υπολογίσει με μη αυτόματο τρόπο την αναμενόμενη τιμή σύμφωνα με τον κανόνα αποδοχής, να μην αναφέρεται στην τρέχουσα έξοδο της συνάρτησης» κατά την εκτύπωση δοκιμών μονάδας;
- Α) Επειδή ο χειροκίνητος υπολογισμός εκτελεί τις δοκιμές πιο γρήγορα
- Β) Επειδή διαφορετικά το τεστ αποδέχεται την τρέχουσα (ίσως buggy) συμπεριφορά του κώδικα ως «σωστή» και επιβεβαιώνει το σφάλμα ✔
- Γ) Γιατί η τεχνητή νοημοσύνη δεν μπορεί να υπολογίσει καθόλου δεκαδικούς αριθμούς
- Δ) Επειδή οι κανόνες αποδοχής δεν χρησιμοποιούνται ποτέ σε δοκιμές
Επεξήγηση: Εάν η τεχνητή νοημοσύνη αντλεί την αναμενόμενη τιμή από την έξοδο της υπό δοκιμή συνάρτησης, θα κάνει τη δοκιμή «να περάσει» ακόμα κι αν η συνάρτηση είναι ελαττωματική. Δηλαδή, ό,τι κι αν παράγει ο κώδικας, η δοκιμή λογίζεται ως αληθής. Ο υπολογισμός της αναμενόμενης τιμής ανεξάρτητα από τον κανόνα αποδοχής διασφαλίζει ότι η δοκιμή είναι φύλακας του κανόνα και όχι καθρέφτης του κώδικα.
7. Ποιο από τα παρακάτω είναι το πιο χαρακτηριστικό γνώρισμα μιας καλής αναφοράς σφαλμάτων;
- Α) Να είναι όσο το δυνατόν μακρύς και τεχνικός
- Β) Γράφτηκε από τεχνητή νοημοσύνη
- Γ) Περιέχει ντετερμινιστικά βήματα αναπαραγωγής που ο προγραμματιστής μπορεί να ακολουθήσει ανεξάρτητα και να δημιουργήσει το σφάλμα ✔
- Δ) Είναι απλώς ένα στιγμιότυπο οθόνης
Εξήγηση: Η πραγματική αξία μιας αναφοράς σφάλματος είναι ότι ο προγραμματιστής μπορεί να αναπαράγει το σφάλμα χωρίς τη βοήθειά σας. Τα ντετερμινιστικά, ανιχνεύσιμα βήματα αναπαραγωγής από την αρχή διασφαλίζουν αυτό. Εάν λείπουν αυτά τα βήματα, η αναφορά κλείνει συχνά ως "δεν ήταν δυνατή η παραγωγή".
8. Ποια είναι η πιο ακριβής έκφραση για τη σχέση μεταξύ σοβαρότητας και προτεραιότητας στο λάθος ορθογραφικό λάθος του ονόματος της εταιρείας στην αρχική σελίδα;
- Α) Η ένταση και η προτεραιότητα πρέπει να έχουν πάντα την ίδια αξία
- Β) Τόσο η σοβαρότητα όσο και η προτεραιότητα αυτού του σφάλματος είναι σίγουρα χαμηλή
- Γ) Σοβαρότητα και προτεραιότητα είναι η ίδια έννοια, μια ετικέτα αρκεί
- Δ) Η τεχνική ένταση μπορεί να είναι χαμηλή, αλλά η επιχειρηματική προτεραιότητα (φήμη) μπορεί να είναι υψηλή. Τα δύο αξιολογούνται διαφορετικά ✔
Εξήγηση: Η σοβαρότητα είναι η τεχνική επίπτωση του σφάλματος (τεχνικά χαμηλό τυπογραφικό λάθος), η προτεραιότητα είναι το πόσο επειγόντως πρέπει να διορθωθεί (υψηλή επειδή είναι ένα στοιχείο φήμης που βλέπει κάθε επισκέπτης). Τα δύο δεν πάνε πάντα προς την ίδια κατεύθυνση. Αυτό το παράδειγμα είναι μια κατάσταση χαμηλής σοβαρότητας-υψηλής προτεραιότητας.
9. Ποια είναι η πιο ακριβής ερμηνεία μιας δοκιμαστικής σουίτας με 90% κάλυψη γραμμής;
- Α) Δείχνει ότι οι γραμμές εκτελούνται αλλά δεν αποδεικνύει ότι συμπεριφέρονται σωστά. ✔ Η υψηλή κάλυψη μπορεί να δώσει ψεύτικη εμπιστοσύνη
- Β) Αποδεικνύει οριστικά ότι το 90% του λογισμικού είναι χωρίς σφάλματα
- Γ) Αποτελεί οριστικό μέτρο άριστης ποιότητας δοκιμής.
- Δ) Δηλώνει ότι δεν χρειάζεται πλέον να γράψετε πρόσθετα τεστ
Επεξήγηση: Η κάλυψη γραμμής υποδεικνύει ότι εκτελέστηκαν μόνο σειρές. Δεν αποδεικνύει ότι παράγει σωστά αποτελέσματα. Ακόμη και με δοκιμές χωρίς επιβεβαίωση, μπορεί να επιτευχθεί κάλυψη 90%. Το πεδίο εφαρμογής είναι ένας χάρτης «που δεν κοιτάχτηκε ποτέ», όχι μια διαβεβαίωση «όλα έχουν δοκιμαστεί». Η πραγματική προστασία μετριέται με δοκιμή μετάλλαξης.
10. Σε δοκιμές βάσει κινδύνου, πώς υπολογίζεται ο κίνδυνος ενός χαρακτηριστικού για να κατευθύνει την περιορισμένη προσπάθεια δοκιμών;
- Α) Μόνο με αριθμό γραμμών κώδικα
- Β) Πολλαπλασιάζοντας την πιθανότητα αποτυχίας και το αποτέλεσμα που θα προκύψει όταν αυτή χαλάσει ✔
- Γ) Μόνο με τη σειρά με την οποία αναπτύχθηκε το χαρακτηριστικό
- Δ) Δίνοντας προτεραιότητα μόνο στο χαρακτηριστικό για το οποίο είναι πιο εύκολο να γραφτούν δοκιμές
Επεξήγηση: Στις δοκιμές βάσει κινδύνου, ο κίνδυνος αξιολογείται ως πιθανότητα = πιθανότητα (πιθανότητα βλάβης) × αντίκτυπο (ζημία εάν σπάσει). Οι τομείς υψηλών πιθανοτήτων και υψηλού αντίκτυπου (πληρωμή, έλεγχος ταυτότητας) αξίζουν τις πιο έντονες δοκιμές, ενώ οι τομείς χαμηλού×χαμηλού δέχονται ελαφριές δοκιμές.
11. Ποιος είναι ο κύριος κίνδυνος προσθήκης επανάληψης σε μια δοκιμή που μερικές φορές περνάει και μερικές φορές αποτυγχάνει (εύθραυστη/ξεφλουδισμένη) παρόλο που ο κωδικός δεν έχει αλλάξει;
- Α) Συντόμευση του χρόνου εκτέλεσης της δοκιμής
- Β) Μειώνει το ποσοστό κάλυψης
- Γ) Κάλυψη ενός πραγματικού σφάλματος συγχρονισμού ή βασικής αιτίας και καταστολή του συμπτώματος ✔
- Δ) Αλλαγή του ονόματος του τεστ
Εξήγηση: Η επανάληψη είναι ένα διαγνωστικό εργαλείο, όχι μια θεραπεία. Η αναποφασιστικότητα συχνά προέρχεται από μια πραγματική κατάσταση φυλής ή εθισμό. Το να κάνετε το τεστ «pass» με επανάληψη καλύπτει αυτό το πραγματικό σφάλμα και μπορεί να προκαλέσει σοβαρά προβλήματα στο live. Πρέπει πρώτα να βρεθεί η βασική αιτία.
12. Πώς λειτουργεί ο έλεγχος μετάλλαξης, η πιο ειλικρινής μέθοδος μέτρησης εάν μια σουίτα δοκιμών προστατεύει πραγματικά;
- Α) Με μέτρηση της ταχύτητας λειτουργίας των δοκιμών
- Β) Μετρώντας πόσες γραμμές κώδικα γράφτηκαν
- Γ) Εκτελώντας τις δοκιμές με διαφορετικές σειρές
- Δ) Δημιουργώντας σκόπιμα μικρά σπασίματα στον κώδικα και μετρώντας αν τα τεστ τα πιάνουν ✔
Περιγραφή: Η δοκιμή μετάλλαξης παράγει μικρές σκόπιμες παραμορφώσεις (μεταλλάξεις) στον πηγαίο κώδικα. Μια καλή δοκιμαστική σουίτα θα πρέπει να πιάσει αυτές τις παραμορφώσεις και να γίνει κόκκινο. Οι μεταλλάξεις που δεν εντοπίστηκαν (επιβίωσαν) δείχνουν ότι τα τεστ δεν διατηρούν αυτή τη συμπεριφορά. Η βαθμολογία μετάλλαξης είναι ένα πολύ πιο ειλικρινές μέτρο ποιότητας από την ποσοστιαία κάλυψη.
13. Ποιο είναι το κύριο όριο που πρέπει να τηρείται κατά την εκτέλεση δοκιμών ασφαλείας (π.χ. δοκιμές εξουσιοδότησης/IDOR);
- Α) Θα πρέπει να γίνεται μόνο στο δικό της προϊόν, εντός γραπτής εξουσιοδότησης και καθορισμένου πεδίου, για αμυντικούς σκοπούς ✔
- Β) Μπορεί να εφαρμοστεί ελεύθερα σε οποιοδήποτε σύστημα ενδιαφέροντος
- Γ) Μπορεί να δοκιμαστεί σε ζωντανά συστήματα επιχειρηματικών συνεργατών χωρίς άδεια
- Δ) Τυχόν ευπάθειες που εντοπίζονται θα πρέπει να δημοσιοποιούνται αμέσως.
Περιγραφή: Οι δοκιμές ασφαλείας που μαθαίνονται σε αυτήν την ενότητα προορίζονται μόνο για τη δοκιμή του δικού σας προϊόντος για αμυντικούς σκοπούς, εντός γραπτής εξουσιοδότησης και καθορισμένου πεδίου εφαρμογής. Η πρόσβαση στο σύστημα κάποιου άλλου χωρίς άδεια ή η εκτέλεση δοκιμών εκτός πεδίου εφαρμογής είναι τόσο ανήθικη όσο και παράνομη. Τυχόν ευπάθειες που εντοπίστηκαν αναφέρονται μέσω υπεύθυνης αποκάλυψης.
14. Ποια εξουσιοδότηση δεν πρέπει ποτέ να δίνεται στην τεχνητή νοημοσύνη στο πλαίσιο του CI/CD;
- Α) Συνοψίζοντας αποτυχημένα αρχεία καταγραφής δοκιμών
- Β) Η εξουσία να «περάσει» αυτόματα ένα αποτυχημένο (κόκκινο) τεστ ή να το βάψει πράσινο ✔
- Γ) Πρόταση προσχέδιο κωδικού δοκιμής
- Δ) Σύνταξη αρχείου YAML Pipeline
Περιγραφή: Η τεχνητή νοημοσύνη μπορεί να παράγει περίγραμμα κώδικα δοκιμής, YAML διοχέτευσης και περίληψη καταγραφής σε CI/CD. Ωστόσο, δεν πρέπει ποτέ να δίνεται η δυνατότητα αυτόματης «επιτυχίας/διόρθωσης» μιας αποτυχημένης δοκιμής. Αυτό ακυρώνει τον σκοπό της δοκιμής και καλύπτει αυτόματα τα λάθη. Το να βάψετε το τεστ με πράσινο χρώμα πρέπει να είναι συνειδητή και αιτιολογημένη απόφαση ενός ατόμου.