Δοκιμές συνδεσιμότητας στην κατασκευή ιστοσελίδων: πρώτα ορίζουμε τι συνδέεται με τι

Μια ιστοσελίδα μπορεί να φαίνεται σωστή και παρ' όλα αυτά να αποτυγχάνει τη στιγμή που χρειάζεται να επικοινωνήσει με άλλη υπηρεσία. Φόρμες, ηλεκτρονικό ταχυδρομείο, χάρτες, συστήματα κρατήσεων, εργαλεία ανάλυσης ή άλλες εξωτερικές λειτουργίες δημιουργούν εξαρτήσεις που πρέπει να χαρτογραφηθούν πριν δοκιμαστούν. Στις δοκιμές συνδεσιμότητας, το πρώτο ερώτημα δεν είναι «έχουμε διαδίκτυο;» αλλά «ποιο σύστημα καλεί ποιο, με ποια δεδομένα, υπό ποιες προϋποθέσεις και τι πρέπει να συμβεί αν η απάντηση δεν έρθει όπως αναμένεται;».

Χαρτογράφηση εξαρτήσεων πριν από οποιοδήποτε δοκιμή

Καταγράφουμε κάθε σημείο όπου η ιστοσελίδα εξαρτάται από κάτι έξω από τον δικό της βασικό κώδικα. Μπορεί να είναι API (Διεπαφή Προγραμματισμού Εφαρμογών, Application Programming Interface), υπηρεσία αποστολής ηλεκτρονικό ταχυδρομείο, χάρτης, σύστημα πληρωμών, σύστημα διαχείρισης πελατειακών σχέσεων ή τελικό σημείο σύνδεσης για δεδομένα. Για κάθε σύνδεση σημειώνουμε ποια σελίδα την ενεργοποιεί, τι στέλνει, τι περιμένει να λάβει και ποια λειτουργία του χρήστη επηρεάζεται. Αυτό το εξάρτηση χάρτης γίνεται η βάση για όλο το εύρος των δοκιμών.

Λίστα απαιτήσεων: τι πρέπει να έχει οριστεί

• Όνομα εξάρτησης: ποια υπηρεσία ή σύστημα συμμετέχει.
• Ενεργοποίηση: ποια ενέργεια χρήστη ή διαδικασία ξεκινά τη σύνδεση.
• Δεδομένα: ποια πεδία αποστέλλονται και ποια επιστρέφονται.
• Περιβάλλον: αν υπάρχει ασφαλές δοκιμή τελικό σημείο σύνδεσης ή δοκιμαστικό περιβάλλον.
• Διαπιστευτήρια: ποιος παρέχει και ποιος διαχειρίζεται τα διαπιστευτήρια.
• Επιτυχία: τι ακριβώς πρέπει να συμβεί όταν όλα λειτουργούν.
• Αποτυχία: ποιο μήνυμα βλέπει ο χρήστης και ποιο εναλλακτική συμπεριφορά ενεργοποιείται.
• Ιδιοκτησία: ποιος αναλαμβάνει διερεύνηση όταν η αστοχία βρίσκεται σε τρίτη υπηρεσία.

DNS, domain και πραγματική προσβασιμότητα

Το DNS (Σύστημα Ονομάτων Τομέα, Domain Name System) συμμετέχει στο πώς ένα domain οδηγεί στις σωστές υπηρεσίες. Στο πλαίσιο της προετοιμασίας, επιβεβαιώνουμε ότι οι αναγκαίες εγγραφές και τα περιβάλλοντα αντιστοιχούν σε αυτό που έχει συμφωνηθεί για δημοσίευση. Δεν χρειάζεται ο συντάκτης περιεχομένου να διαχειρίζεται τεχνικά τις εγγραφές, αλλά το απαιτήσεις εύρος πρέπει να ξεκαθαρίζει ποιος έχει πρόσβαση, ποιος εγκρίνει αλλαγές και πώς γίνεται επαναφορά προηγούμενης κατάστασης αν μια μεταβολή οδηγήσει σε πρόβλημα.

Φόρμες και ηλεκτρονικό ταχυδρομείο: η σύνδεση δεν τελειώνει στο κουμπί «Αποστολή»

Μια φόρμα μπορεί να εμφανίσει μήνυμα επιτυχίας χωρίς το μήνυμα να φτάσει ποτέ στον σωστό παραλήπτη. Για αυτό το σενάριο πρέπει να καλύπτει ολόκληρη τη ροή: συμπλήρωση, επικύρωση, στην πλευρά του διακομιστή επεξεργασία, αποστολή, παραλαβή και σωστή αντιστοίχιση πεδίων. Το SMTP (Απλό Πρωτόκολλο Μεταφοράς Αλληλογραφίας, Simple Mail Transfer Protocol) μπορεί να είναι μέρος της αλυσίδας, ανάλογα με την υλοποίηση. Οι δοκιμές φόρμας χρειάζονται πραγματική επιβεβαίωση προορισμού και όχι μόνο οπτικό μήνυμα στην οθόνη.

Δεδομένα δοκιμών χωρίς μπέρδεμα με πραγματικές εγγραφές

Πριν εκτελεστούν δοκιμές, ορίζουμε ποια δεδομένα μπορούν να χρησιμοποιηθούν και πώς θα ξεχωρίζουν από πραγματικές υποβολές. Σε περιβάλλον παραγωγής, ένα δοκιμή αίτημα μπορεί να ενεργοποιήσει πραγματική επιχειρηματική διαδικασία, ειδοποίηση ή αυτοματισμό. Για αυτό επιλέγουμε αναγνωρίσιμα δοκιμή στοιχεία, καταγράφουμε ποιος εκτελεί το σενάριο και διαγράφουμε ή αρχειοθετούμε ό,τι δημιουργήθηκε όταν είναι απαραίτητο. Αν υπάρχει ξεχωριστό δοκιμή περιβάλλον, προτιμούμε να επαληθεύσουμε εκεί όσο το δυνατόν μεγαλύτερο μέρος της ροής πριν από την τελική δοκιμή παραγωγής.

Τι γίνεται όταν η εξωτερική υπηρεσία δεν απαντά

Η αποτυχία είναι μέρος του απαιτήσεις σχεδιασμό. Δεν αρκεί να ξέρουμε πώς λειτουργεί το «ομαλό σενάριο». Ορίζουμε αν η σελίδα θα εμφανίσει προσωρινό μήνυμα, αν θα επιτρέψει επανάληψη, αν θα κρατήσει τα δεδομένα με ασφαλή τρόπο ή αν θα προτείνει εναλλακτική ενέργεια. Το ακριβές εναλλακτική συμπεριφορά εξαρτάται από τη λειτουργία. Σε κάθε περίπτωση, ο χρήστης δεν πρέπει να μένει με ένα αόριστο ένδειξη αναμονής ή με την εντύπωση ότι ολοκλήρωσε κάτι που στην πραγματικότητα απέτυχε.

Διαχωρισμός προβλήματος ιστοσελίδας και τρίτου συστήματος

Όταν μια σύνδεση αποτυγχάνει, χρειάζεται σαφής τρόπος να διαπιστωθεί σε ποια πλευρά βρίσκεται η αιτία. Καταγράφουμε το κατάσταση αιτήματος και απόκρισης όπου επιτρέπεται, τον χρόνο του συμβάντος και το συγκεκριμένο βήμα του σεναρίου. Δεν χρειάζεται να εκθέτουμε τεχνικές λεπτομέρειες στον τελικό χρήστη, αλλά η ομάδα πρέπει να έχει αρκετή πληροφορία για να ξέρει αν θα ερευνήσει κώδικα, ρυθμίσεις ή τρίτη υπηρεσία. Αυτή η διάκριση μειώνει τις άσκοπες αλλαγές σε σημεία που λειτουργούν σωστά.

Σχέση με το γενικό πλάνο δοκιμών

Οι δοκιμές συνδεσιμότητας είναι μέρος μιας μεγαλύτερης στρατηγικής. Το γενικό πλαίσιο για δοκιμές στην κατασκευή ιστοσελίδων καλύπτει επίσης λειτουργία διεπαφής, φυλλομετρητές, περιεχόμενο και άλλες κατηγορίες. Εδώ το εύρος είναι πιο στενό: όλα τα σημεία όπου η σελίδα πρέπει να επικοινωνήσει με άλλη υπηρεσία ή υποδομή. Αυτός ο διαχωρισμός βοηθά να μη χαθούν κρίσιμες εξαρτήσεις μέσα σε έναν τεράστιο γενικό λίστα ελέγχου.

Πότε μια αποτυχία μπλοκάρει τη δημοσίευση

Αν η εξάρτηση υποστηρίζει την κύρια επιχειρηματική ενέργεια, όπως αίτημα, κράτηση ή πληρωμή, η αποτυχία της συνήθως απαιτεί επίλυση ή σαφές εναλλακτικό μονοπάτι πριν το ιστοσελίδα θεωρηθεί έτοιμο. Αν αφορά δευτερεύον στοιχείο, μπορεί να υπάρξει προσωρινή υποβάθμιση λειτουργίας, αρκεί να μην παραπλανά τον χρήστη. Το απαίτηση πρέπει να έχει αποφασιστεί πριν από το δοκιμή ώστε το αποτέλεσμα να οδηγεί σε ενέργεια και όχι σε συζήτηση της τελευταίας στιγμής.

Η ολοκλήρωση είναι συμφωνημένη συμπεριφορά, όχι απλώς «200 OK»

Τεχνική απάντηση από έναν διακομιστής δεν αποδεικνύει ότι η επιχειρηματική ροή ολοκληρώθηκε. Η σωστή δοκιμή επιβεβαιώνει το αποτέλεσμα από την οπτική του χρήστη και από την οπτική του συστήματος που πρέπει να παραλάβει ή να επιστρέψει δεδομένα. Για αυτό η κατασκευή ιστοσελίδων χρειάζεται να συνδέει απαιτήσεις, υλοποίηση και δοκιμές σε μία αλυσίδα. Όταν οι εξαρτήσεις έχουν αποτυπωθεί καθαρά, το δοκιμή γίνεται συγκεκριμένο, επαναλήψιμο και πολύ πιο χρήσιμο για την ομάδα.

Χρονικά όρια, επαναλήψεις και αποφυγή διπλών ενεργειών

Σε κάθε σύνδεση πρέπει να είναι γνωστό πόσο περιμένει η εφαρμογή πριν θεωρήσει ότι κάτι απέτυχε και αν επιτρέπεται αυτόματη επανάληψη. Η λάθος λογική επανάληψη μπορεί να δημιουργήσει διπλές εγγραφές ή διπλές ενέργειες όταν ο χρήστης δεν ξέρει αν η πρώτη προσπάθεια ολοκληρώθηκε. Για αυτό στα απαιτήσεις σημειώνουμε αν μια λειτουργία είναι ασφαλής για επανάληψη χωρίς διπλό αποτέλεσμα, αν χρειάζεται μοναδικό αναγνωριστικό και ποιος είναι ο σωστός χειρισμός όταν η απάντηση καθυστερεί. Το δοκιμή επιβεβαιώνει όχι μόνο την επιτυχία αλλά και ότι η αβεβαιότητα δεν παράγει ανεπιθύμητες παρενέργειες.

Πίνακας ιδιοκτησίας για κάθε διασύνδεση

Ένα απλό ιδιοκτησία πίνακας μπορεί να περιλαμβάνει το διασύνδεση, τον εσωτερικό υπεύθυνο, τον τρίτο πάροχο, το κανάλι υποστήριξης και το εναλλακτική συμπεριφορά. Αυτή η πληροφορία γίνεται κρίσιμη όταν μια εξάρτηση σταματήσει να λειτουργεί μετά τη δημοσίευση. Χωρίς ιδιοκτησία, η ομάδα χάνει χρόνο ψάχνοντας ποιος έχει διαπιστευτήρια ή ποιος μπορεί να ανοίξει αίτημα υποστήριξης. Με σαφή κατανομή, το περιστατικό περνά γρήγορα στον σωστό άνθρωπο. Το απαιτήσεις εύρος συνεπώς δεν είναι μόνο τεχνική λίστα· είναι και συμφωνία λειτουργικής ευθύνης.

Το εύρος κλείνει όταν κάθε εξάρτηση έχει αναμενόμενο αποτέλεσμα

Πριν θεωρήσουμε τα απαιτήσεις επαρκή, πρέπει να μπορούμε να δείξουμε για κάθε σύνδεση ποιος την ενεργοποιεί, ποιο σύστημα απαντά, ποιο αποτέλεσμα θεωρείται σωστό και ποια συμπεριφορά είναι αποδεκτή σε αποτυχία. Αν κάποιο από αυτά παραμένει ασαφές, το δοκιμή περίπτωση θα είναι επίσης ασαφές. Η σαφήνεια αυτή μειώνει τις παρεξηγήσεις ανάμεσα σε προγραμματιστές, χειριστές και τρίτους παρόχους και μετατρέπει ένα γενικό «να ελέγξουμε τη σύνδεση» σε πραγματικά εκτελέσιμη απαίτηση.

Βοήθημα επαλήθευσης πριν κλείσει η δοκιμή

• Το αποτέλεσμα ελέγχθηκε και από την πλευρά του συστήματος προορισμού.
• Η αποτυχία επιστρέφει κατανοητή συμπεριφορά και δεν αφήνει αβέβαιη κατάσταση.
• Δεν δημιουργούνται διπλές εγγραφές μετά από επανάληψη.
• Τα διαπιστευτήρια και τα δεδομένα δοκιμών δεν εκτίθενται σε δημόσιο περιβάλλον.
• Υπάρχει γνωστός υπεύθυνος και εναλλακτικό μονοπάτι για κρίσιμη τρίτη εξάρτηση.