Κέρδη:
- Δυνατότητα παραγωγής δοκιμών μονάδας, ενοποίησης και διεπαφής χρήστη με τεχνητή νοημοσύνη σύμφωνα με την πυραμίδα δοκιμών και την κάλυψη καταστάσεων ορίων και σφαλμάτων καθώς και χαρούμενα σενάρια
- Δυνατότητα εξάλειψης των κενών/άχρηστων δοκιμών και της φουσκωμένης κάλυψης ελέγχοντας ότι κάθε δοκιμή που δημιουργείται επικυρώνει πραγματικά μια συμπεριφορά
- Διασφάλιση ότι η δοκιμή εντοπίζει το σφάλμα και το αποτρέπει από το να διορθώσει το σφάλμα, λέγοντας στην τεχνητή νοημοσύνη τι πρέπει να κάνει ο κώδικας
Το να γράφεις κώδικα είναι η μισή δουλειά. Η απόδειξη ότι ο κώδικας λειτουργεί σωστά είναι το άλλο μισό. Οι εφαρμογές για κινητά συναντούν εκατοντάδες διαφορετικές συσκευές, μεγέθη οθόνης, εκδόσεις λειτουργικού συστήματος και συμπεριφορές χρηστών. Είναι αδύνατο να δοκιμάσετε όλα αυτά χειροκίνητα. Αυτός είναι ο λόγος για τον οποίο οι αυτοματοποιημένες δοκιμές (κώδικας δοκιμής κώδικα — δοκιμή που εκτελείται χωρίς ανθρώπινο κλικ) είναι η ραχοκοκαλιά της ποιότητας για κινητά. Η τεχνητή νοημοσύνη είναι απίστευτα αποτελεσματική στη σύνταξη δοκιμών, επειδή η σύνταξη δοκιμών είναι ακριβώς το είδος της εργασίας με μοτίβο που της αρέσει: επικύρωση μιας συγκεκριμένης συμπεριφοράς για συγκεκριμένες εισόδους. Σε αυτή την ενότητα, θα μάθουμε πώς να επιταχύνουμε τις δοκιμές μονάδας, τις δοκιμές διεπαφής και την αυτοματοποίηση με AI, αλλά να διασφαλίζουμε την ποιότητα της δοκιμής μέσα από τα ανθρώπινα μάτια.
Δοκιμαστική πυραμίδα: τι να δοκιμάσετε και πόσο
Μια υγιής στρατηγική δοκιμών μοιάζει με πυραμίδα. Η βάση περιλαμβάνει μεγάλο αριθμό δοκιμών μονάδας (γρήγορη δοκιμή που δοκιμάζει μια μεμονωμένη συνάρτηση ή κατηγορία μεμονωμένα). είναι γρήγορα και φθηνά. Στη μέση υπάρχει λιγότερη δοκιμή ολοκλήρωσης (δοκιμή του τρόπου με τον οποίο συνεργάζονται πολλά μέρη). Στο επάνω μέρος υπάρχει ελάχιστη δοκιμή διεπαφής χρήστη/από άκρο σε άκρο (η δοκιμή γίνεται κάνοντας κλικ στην οθόνη όπως κάνει ο χρήστης). είναι ρεαλιστικά αλλά αργά και εύθραυστα. Η τεχνητή νοημοσύνη βοηθά σε κάθε επίπεδο, αλλά η μεγαλύτερη αξία βρίσκεται στη βάση: γρήγορη παραγωγή μονάδων δοκιμών επιχειρηματικής λογικής.
Τύπος δοκιμής
Πεδίο εφαρμογής
ταχύτητα
Αποτελεσματικότητα AI
δοκιμή μονάδας
Ενιαία λειτουργία/κλάση
πολύ γρήγορα
πολύ ψηλά
ενσωμάτωσης
ενδιάμεσο
μεσαίο
ψηλά
UI / από άκρο σε άκρο
Όλη η ροή της οθόνης
αργό
Μεσαίο (εύθραυστο)
Συμβουλή: Όταν λέτε στην τεχνητή νοημοσύνη να "δημιουργήσει δοκιμές για αυτήν τη λειτουργία", ζητήστε ρητά περιπτώσεις ακμών: κενή είσοδο, μηδενική, αρνητικός αριθμός, πολύ μεγάλη τιμή, σφάλμα δικτύου. Το AI δημιουργεί ευτυχισμένο μονοπάτι εύκολα. Τα πραγματικά λάθη κρύβονται στα σύνορα και ξεπηδούν αν δεν τα θέλεις εκεί.
Βήματα συγγραφής τεστ με AI
- Καθορίστε τη συμπεριφορά που θα ελεγχθεί. "Αυτή η συνάρτηση θα πρέπει να δίνει αυτήν την έξοδο σε αυτήν την είσοδο."
- Προσδιορίστε το πλαίσιο. JUnit + MockK σε Android, XCTest σε iOS, Espresso (Android) ή XCUITest (iOS) για διεπαφή χρήστη.
- Ζητήστε οριακές καταστάσεις. Ευτυχισμένο σενάριο + σφάλμα + σημεία διακοπής.
- Διαχειριστείτε εικονικά αντικείμενα. Οι εξωτερικές εξαρτήσεις όπως το δίκτυο και η βάση δεδομένων προσομοιώνονται για δοκιμή (ψευδή — ελεγχόμενη παρωδία αντί για την πραγματική υπηρεσία).
- Εκτελέστε τη δοκιμή και επαληθεύστε. Περνά το τεστ, επιβεβαιώνει κάτι πραγματικά σημαντικό;
Το πέμπτο βήμα είναι κρίσιμο. Η τεχνητή νοημοσύνη μερικές φορές παράγει άχρηστα τεστ που «πάντα περνούν». για παράδειγμα, μια δοκιμή που δεν επαληθεύει τίποτα ή ελέγχει τα δικά της πλαστά δεδομένα. Μια επιτυχής δοκιμασία και μια πολύτιμη δοκιμασία είναι διαφορετικά πράγματα.
Προσοχή: Ακριβώς επειδή το AI μπορεί να παράγει δεν σημαίνει ότι το τεστ είναι σωστό. Μερικές φορές το AI αποδέχεται την τρέχουσα (ίσως ελαττωματική) συμπεριφορά του κώδικα ως "σωστή" και γράφει δοκιμές ανάλογα. Τέτοιες δοκιμές διορθώνουν το σφάλμα αντί να το πιάνουν. Εσείς καθορίζετε τι περιμένει το τεστ. Πείτε στο AI τι πρέπει να κάνει, όχι τι κάνει ο κώδικας.
Δοκιμαστικό μέτρο κάλυψης και πλάνη
Η δοκιμαστική κάλυψη (ποιο ποσοστό κώδικα εκτελείται από τις δοκιμές) είναι μια χρήσιμη αλλά παραπλανητική μέτρηση. Η κάλυψη 90% υποδηλώνει ότι το 90% του κώδικα έχει εκτελεστεί. αλλά δεν έχει επαληθευτεί ότι αυτές οι γραμμές λειτουργούν σωστά. Μια δοκιμή που εκτελεί μια γραμμή και δεν ελέγχει το αποτέλεσμα διογκώνει το πεδίο εφαρμογής αλλά δεν παρέχει ασφάλεια. Ο στόχος δεν είναι οι υψηλοί αριθμοί, αλλά η ουσιαστική επικύρωση. Μπορείτε να κλιμακώσετε γρήγορα με την τεχνητή νοημοσύνη, αλλά βεβαιωθείτε ότι κάθε δοκιμή δοκιμάζει πραγματικά μια συμπεριφορά.
τρεις μίνι θήκες
Περίπτωση 1 — Επιβεβαιώθηκε η συνοριακή κατάσταση. Η τεχνητή νοημοσύνη ζητήθηκε για δοκιμές για λειτουργία μεταφοράς χρημάτων σε τραπεζική εφαρμογή και συγκεκριμένα προστέθηκαν σενάρια «αρνητικού ποσού» και «περισσότερο από το υπόλοιπο». Η δοκιμή αποκάλυψε ότι η μεταφορά δεν μπλοκαρίστηκε με αρνητικό ποσό. αυτό θα ήταν μια σημαντική ευπάθεια ασφάλειας στην παραγωγή. Έκλεισε με την προσθήκη ενός στοιχείου ελέγχου μίας γραμμής. Μάθημα: τα τεστ ορίων είναι τα πιο πολύτιμα τεστ.
Περίπτωση 2 — Ψεύτικο τεστ. Μία ομάδα ανακουφίστηκε για να αυξήσει την κάλυψη στο 85% με 40 δοκιμές μονάδων που παρήχθησαν από AI. Κατά τη διάρκεια της επιθεώρησης, διαπιστώθηκε ότι οι περισσότερες δοκιμές δεν επαλήθευσαν στην πραγματικότητα καμία έξοδο, απλώς κάλεσαν τη συνάρτηση και έγραψαν assertTrue(true). Η κάλυψη ήταν υψηλή, αλλά η προστασία ήταν μηδενική. Οι δοκιμές αναθεωρήθηκαν και ξαναγράφτηκαν με πραγματικές επικυρώσεις. Μάθημα: οι αριθμοί κάλυψης μπορεί να λένε ψέματα.
Περίπτωση 3 — Η δοκιμή διεπαφής χρήστη επιταχύνθηκε. Μια ομάδα ηλεκτρονικού εμπορίου έγραψε ένα σενάριο XCUITtest της ροής προσθήκης στο καλάθι με AI σε 20 λεπτά. Αν ήταν γραμμένο στο χέρι, θα έπαιρνε μισή μέρα. Αναγνωριστικά στοιχείων οθόνης εικασμένα με AI. Η ομάδα τα ταίριαξε με τον πραγματικό κωδικό και τα διόρθωσε. Η ταχύτητα του σχεδίου είναι πραγματική, αλλά η επαλήθευση αναγνωριστικού είναι ανθρώπινο έργο.
Αδύναμη προτροπή / Ισχυρή προτροπή
Αδύναμη προτροπή: "Γράψτε μια δοκιμή για αυτήν τη συνάρτηση."
Ισχυρό μήνυμα: "Δημιουργήστε δοκιμές μονάδας για αυτήν τη συνάρτηση Kotlin με JUnit5 + MockK. Λειτουργία: μεταφορά χρημάτων (ποσό, πηγή, στόχος). Συμπεριφορές προς δοκιμή (τι πρέπει να ΚΑΝΕΙ ο κωδικός): - Η έγκυρη μεταφορά πρέπει να είναι επιτυχής - Το αρνητικό ή μηδενικό ποσό πρέπει να απορριφθεί - Το ποσό μεγαλύτερο από το υπόλοιπο πρέπει να απορριφθεί. περιγραφικό, κοροϊδεύεις την εξωτερική υπηρεσία Μην γράφεις κενό ισχυρισμό."
Αντιγράψιμα πρότυπα
Πρότυπο δοκιμής μονάδας: "Δημιουργήστε δοκιμές μονάδας [JUnit/XCTest] για αυτήν τη συνάρτηση για [γλώσσα]. Αναμενόμενη συμπεριφορά: [τι να κάνετε]. Συμπεριλάβετε: χαρούμενο σενάριο, μηδενική είσοδο, σημεία διακοπής, περίπτωση σφάλματος. Αφήστε κάθε δοκιμή να επαληθεύσει μεμονωμένη συμπεριφορά. Χρησιμοποιήστε ουσιαστική διαβεβαίωση, κοροϊδία. [κωδικός]"
Πρότυπο δοκιμής διεπαφής χρήστη: "Γράψτε μια δοκιμή διεπαφής χρήστη της ακόλουθης ροής με [Espresso/XCUITest]: [ροή χρήστη βήμα προς βήμα]. Επιλέξτε στοιχεία οθόνης με αναγνωριστικό προσβασιμότητας, χρησιμοποιήστε το αναγνωριστικό αντί για κείμενο. Προσθήκη στρατηγικής αναμονής. Υπενθυμίστε μου να αντιστοιχίσω τα αναγνωριστικά στοιχείων με τον πραγματικό κώδικα."
Δοκιμαστικό πρότυπο ελέγχου:"Εξετάστε αυτές τις δοκιμές:1) Επιβεβαιώνουν πράγματι μια έξοδο/συμπεριφορά ή είναι μηδενικές; 2) Καλύπτουν περιπτώσεις ορίων; 3) Διορθώνουν σφάλματα στον κώδικα ή αναμένουν σωστή συμπεριφορά; Επισημαίνουν και ενισχύουν τα αδύναμα τεστ. [δοκιμές]"
Πρότυπο βελτιστοποίησης κάλυψης: "Προσδιορίστε μη δοκιμασμένα μέρη αυτής της κατηγορίας και προτείνετε ουσιαστικές δοκιμές. Δώστε προτεραιότητα σε διαδρομές με πραγματικό κίνδυνο, όχι μόνο στον αριθμό των καλύψεων. [κωδικός]"
Συνήθη λάθη
- Απλά δοκιμάζουμε το χαρούμενο σενάριο. Τα σφάλματα αποθηκεύονται σε οριακές καταστάσεις. Ζητήστε τους ανοιχτά.
- Αποδοχή ενός κενού/άχρηστου τεστ. Οι δοκιμές του τύπου assertTrue(true) διογκώνουν το εύρος και δεν παρέχουν καμία προστασία.
- Έχοντας το AI επαληθεύσετε τι κάνει ο κώδικας. Η δοκιμή θα πρέπει να περιμένει τι πρέπει να κάνει ο κώδικας. αλλιώς διορθώνει το bug.
- Λάθος του αριθμού πεδίου για το σκοπό. Κάλυψη 90% δεν σημαίνει ακρίβεια 90%.
- Σύνδεση με κείμενο στη δοκιμή διεπαφής χρήστη. Το τεστ χαλάει όταν αλλάζει το κείμενο. Χρησιμοποιήστε σταθερό αναγνωριστικό (αναγνωριστικό).
- Εσφαλμένη εγκατάσταση μακέτας. Η "δοκιμή μονάδας" που καλεί το πραγματικό σέρβις θα είναι αργή και εύθραυστη.
Συνοπτικά
Οι δοκιμές είναι η ραχοκοκαλιά της ποιότητας των φορητών συσκευών και η τεχνητή νοημοσύνη είναι πολύ αποτελεσματική σε αυτόν τον τομέα, ειδικά στις δοκιμές μονάδων. Ακολουθήστε την πυραμίδα δοκιμών: πολλές μονάδες, μεσαία ενοποίηση, μικρή δοκιμή διεπαφής χρήστη. Ρωτήστε ρητά την τεχνητή νοημοσύνη για το ευτυχές σενάριο, καθώς και για περιορισμένες περιπτώσεις και διαδρομές σφαλμάτων. Βεβαιωθείτε ότι κάθε δοκιμή που δημιουργείται επικυρώνει πραγματικά μια συμπεριφορά. Οι κενές δοκιμές και η διογκωμένη κάλυψη είναι παραπλανητικές. Το πιο σημαντικό, πείτε στην τεχνητή νοημοσύνη τι πρέπει να κάνει ο κώδικας, όχι τι κάνει, έτσι ώστε η δοκιμή να εντοπίσει το σφάλμα, όχι να το διορθώσει.
Εργασία εφαρμογής
Ζητήστε δοκιμές από την τεχνητή νοημοσύνη χρησιμοποιώντας το "Πρότυπο δοκιμής μονάδας" για μια συνάρτηση επιχειρησιακής λογικής (π.χ. υπολογισμός έκπτωσης ή επικύρωση φόρμας) και καθορίστε ρητά περιπτώσεις ορίων (μηδενική, αρνητική, πολύ μεγάλη). Εκτελέστε τις δημιουργημένες δοκιμές και, στη συνέχεια, ελέγξτε τις ίδιες δοκιμές με το "Δοκιμαστικό πρότυπο ελέγχου". Βρείτε τουλάχιστον ένα αδύναμο τεστ, ενισχύστε το και ελέγξτε εάν οι δοκιμές εντοπίσουν ένα πραγματικό σφάλμα της συνάρτησης (προσθέτοντας ένα μικρό σφάλμα).
λίστα ελέγχου
- [ ] Επέλεξα το κατάλληλο επίπεδο για τη δοκιμαστική πυραμίδα (μονάδα προτεραιότητας)
- [ ] Ήθελα περιπτώσεις ορίων και σφαλμάτων εκτός από το χαρούμενο σενάριο
- [ ] Επιβεβαίωσα ότι κάθε δοκιμή περιέχει έναν ισχυρό ισχυρισμό
- [ ] Είπα στο AI τι πρέπει να κάνει ο κώδικας, όχι τι κάνει
- [ ] Εστίασα στις πραγματικές διαδρομές κινδύνου, όχι στον αριθμό των καλύψεων
- [ ] Χρησιμοποίησα σταθερό αναγνωριστικό σε δοκιμές διεπαφής χρήστη, δεν δεσμεύτηκα με κείμενο