Μενού

Δοκιμές επικύρωσης δεδομένων για έργα ETL και μετανάστευσης δεδομένων

  • Κύριος
  • Αλλα
  • Δοκιμές επικύρωσης δεδομένων για έργα ETL και μετανάστευσης δεδομένων

data validation tests

Δοκιμάστε Το Όργανο Μας Για Την Εξάλειψη Των Προβλημάτων

Αυτό το σεμινάριο περιγράφει Έργα ETL & Μετανάστευσης Δεδομένων και καλύπτει Έλεγχους επικύρωσης δεδομένων ή Δοκιμές για Έργα ETL / Μετανάστευσης Δεδομένων για Βελτιωμένη Ποιότητα Δεδομένων:

Αυτό το άρθρο απευθύνεται σε υπεύθυνους δοκιμών λογισμικού που εργάζονται σε έργα ETL ή Data Migration και ενδιαφέρονται να επικεντρώσουν τις δοκιμές τους μόνο σε θέματα Ποιότητας Δεδομένων. Αυτοί οι τύποι έργων έχουν τεράστιο όγκο δεδομένων που αποθηκεύονται στην πηγή αποθήκευσης και στη συνέχεια λειτουργούν από κάποια λογική που υπάρχει στο λογισμικό και μεταφέρεται στον χώρο αποθήκευσης προορισμού.

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

Επικύρωση δεδομένων για έργα ETL και μετανάστευσης δεδομένων

Ο αριθμός των πτυχών ποιότητας δεδομένων που μπορούν να δοκιμαστούν είναι τεράστιος και αυτή η λίστα παρακάτω δίνει μια εισαγωγή σε αυτό το θέμα.

Τι θα μάθετε:

Τι είναι η επικύρωση δεδομένων;

Επικύρωση δεδομένων

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

Παράδειγμα: Η διεύθυνση ενός μαθητή στον πίνακα Student ήταν 2000 χαρακτήρες στο σύστημα προέλευσης. Η επικύρωση δεδομένων επαληθεύει εάν η ακριβής ίδια τιμή βρίσκεται στο σύστημα προορισμού. Ελέγχει εάν τα δεδομένα έχουν περικοπεί ή εάν έχουν αφαιρεθεί ορισμένοι ειδικοί χαρακτήρες.

Σε αυτό το άρθρο, θα συζητήσουμε πολλούς από αυτούς τους ελέγχους επικύρωσης δεδομένων. Ως δοκιμαστές για έργα ETL ή μετεγκατάστασης δεδομένων, προσθέτει τεράστια αξία αν αποκαλύψουμε ζητήματα ποιότητας δεδομένων που ενδέχεται να μεταδοθούν στα συστήματα-στόχους και να διαταράξουν ολόκληρες τις επιχειρηματικές διαδικασίες.

Γιατί να επικυρώσετε δεδομένα για έργα ETL;

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

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

σύστημα στόχου και πηγής

Παράδειγμα: Μια εφαρμογή ηλεκτρονικού εμπορίου έχει εργασίες ETL επιλέγοντας όλες τις παραγγελίες από κάθε πελάτη από τον πίνακα παραγγελιών που συνοψίζει το TotalDollarsSpend από τον πελάτη και το φορτώνει σε έναν νέο πίνακα τιμών πελάτη, επισημαίνοντας κάθε πελάτη βαθμολογία ως πελάτες υψηλής / μεσαίας / χαμηλής αξίας σε κάποιο σύνθετο αλγόριθμο.

Η απλή δοκιμή επικύρωσης δεδομένων είναι να διαπιστωθεί ότι το CustomerRating υπολογίζεται σωστά.

Μια άλλη δοκιμή είναι να επαληθευτεί ότι το TotalDollarSpend υπολογίζεται σωστά χωρίς ελαττώματα στη στρογγυλοποίηση των τιμών ή της υπερχείλισης μέγιστης τιμής.

Γιατί να επικυρώσετε δεδομένα για έργα μετεγκατάστασης δεδομένων;

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

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

Και πάλι, απαιτείται επικύρωση δεδομένων για να επιβεβαιωθεί ότι τα δεδομένα στην πηγή είναι τα ίδια στο στόχο μετά την κίνηση.

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

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

Υπάρχουν διάφορες πτυχές που μπορούν να δοκιμάσουν οι δοκιμαστές σε τέτοια έργα όπως λειτουργικές δοκιμές, δοκιμές απόδοσης, δοκιμές ασφαλείας, δοκιμές υπέρυθρων, δοκιμές E2E, δοκιμές παλινδρόμησης κ.λπ.

Συνιστώμενη ανάγνωση => Δοκιμή μετεγκατάστασης δεδομένων , Εκμάθηση δοκιμών αποθήκης δεδομένων ETL

Σε αυτό το άρθρο, θα εξετάσουμε μόνο την πτυχή δεδομένων των δοκιμών για έργα ETL & Migration.

Φύλλο χαρτογράφησης δεδομένων

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

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

Λήψη προτύπου από Απλοποιημένο φύλλο χαρτογράφησης δεδομένων

Δοκιμές επικύρωσης δεδομένων

# 1) Ομοιομορφία δεδομένων

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

(i) Έλεγχοι στο ίδιο σχήμα:

  • Η οντότητα δεδομένων ενδέχεται να υπάρχει σε δύο πίνακες στο ίδιο σχήμα (είτε το σύστημα προέλευσης είτε το σύστημα προορισμού)
  • Παράδειγμα: Όπως μπορείτε να δείτε στην παρακάτω εικόνα, το ProductID υπάρχει στον πίνακα OrderDetails and Products. Κάντε επαλήθευση ακριβούς αντιστοίχισης για το ProductId που υπάρχει στον πίνακα OrderDetails vs Products.

Απλοποιημένο φύλλο χαρτογράφησης δεδομένων

(ii) Έλεγχοι στα σχήματα:

  • Η οντότητα δεδομένων ενδέχεται να μετεγκατασταθεί ως έχει στο σχήμα Στόχος, δηλαδή υπάρχει στο σύστημα προέλευσης καθώς και στο σύστημα προορισμού
  • Παράδειγμα: Όπως μπορείτε να δείτε στην παραπάνω εικόνα, το ProductID υπάρχει στον πίνακα Προϊόντα στο σύστημα προέλευσης και στον πίνακα Προϊόντα στο σύστημα προορισμού. Κάντε μια επαλήθευση ακριβούς αντιστοίχισης για τον πίνακα ProductId στον πίνακα προϊόντων στο σύστημα προέλευσης έως τον πίνακα ProductId στον πίνακα προϊόντων στο σύστημα προορισμού.

Σημείωση: Είναι καλύτερο να επισημάνετε (κωδικός χρώματος) αντίστοιχες οντότητες δεδομένων στο φύλλο χαρτογράφησης δεδομένων για γρήγορη αναφορά.

# 2) Παρουσία οντότητας

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

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

Μερικές φορές χρησιμοποιούνται διαφορετικά ονόματα πινάκων και επομένως μια άμεση σύγκριση ενδέχεται να μην λειτουργεί. Ίσως χρειαστεί να χαρτογραφήσουμε αυτές τις πληροφορίες στο φύλλο χαρτογράφησης δεδομένων και να τις επικυρώσουμε για αποτυχίες.

Μια άλλη πιθανότητα είναι η απουσία δεδομένων. Υπάρχουν περιπτώσεις όπου το μοντέλο δεδομένων απαιτεί ότι ένας πίνακας στο σύστημα προέλευσης (ή στήλη) δεν έχει αντίστοιχη παρουσία στο σύστημα προορισμού (ή αντίστροφα). Έχετε δοκιμές για να το επικυρώσετε.

  • Παράδειγμα: Όπως μπορείτε να δείτε στην παρακάτω εικόνα, ο πίνακας CustDemographic υπάρχει στο σύστημα προορισμού και όχι στο σύστημα προέλευσης.
  • Πεδίο Τύπος πελάτη στον πίνακα Πελάτες έχει δεδομένα μόνο στο σύστημα προέλευσης και όχι στο σύστημα προορισμού.

βελάκι (ακρίβεια δεδομένων)

# 3) Ακρίβεια δεδομένων

Όπως υποδηλώνει το όνομα, επικυρώνουμε εάν τα δεδομένα είναι λογικά ακριβή. Υπάρχουν δύο κατηγορίες για αυτόν τον τύπο δοκιμής. Με αυτό, ο ελεγκτής μπορεί να εντοπίσει ζητήματα ποιότητας δεδομένων ακόμη και στο σύστημα προέλευσης.

Ακεραιότητα δεδομένων

(εικόνα πηγή )

Σημείωση: Εκτελέστε αυτήν τη δοκιμή στο σύστημα προορισμού και ελέγξτε ξανά το σύστημα προέλευσης για τυχόν ελαττώματα.

(i) Μη αριθμητικός τύπος: Σε αυτήν την ταξινόμηση, επαληθεύουμε την ακρίβεια του μη αριθμητικού περιεχομένου. Παραδείγματα είναι τα email, οι κωδικοί Pin, το τηλέφωνο σε έγκυρη μορφή.

(ii) Ανάλυση τομέα: Σε αυτόν τον τύπο δοκιμής, επιλέγουμε τομείς δεδομένων και επικυρώνουμε για σφάλματα. Υπάρχουν τρεις ομάδες για αυτό:

  • Με βάση την τιμή: Εδώ δημιουργούμε μια λίστα τιμών που μπορούν να προκύψουν για ένα πεδίο (στήλη στον πίνακα). Στη συνέχεια, επικυρώστε εάν οι τιμές στηλών είναι ένα υποσύνολο της λίστας μας.
    • Παράδειγμα: Επαληθεύστε εάν η στήλη Φύλο περιέχει είτε M είτε F.
  • Με βάση το εύρος: Εδώ ορίζουμε ελάχιστο και μέγιστο εύρος για έγκυρες τιμές δεδομένων για μια στήλη, βάσει λογικής ή επιχειρηματικής συλλογιστικής. Στη συνέχεια επικυρώνουμε εάν οι τιμές της στήλης εμπίπτουν σε αυτό το εύρος.
    • Παράδειγμα: 0 έως 120 για Ηλικία.
  • Αρχείο αναφοράς : Εδώ το σύστημα χρησιμοποιεί ένα εξωτερικό αρχείο εγκυρότητας.
    • Παράδειγμα: Είναι έγκυροι οι κωδικοί χώρας, επιλέγουν τη σωστή τιμή από το αρχείο αναφοράς, οι κωδικοί χώρας είναι οι ίδιοι μεταξύ του QA και του περιβάλλοντος παραγωγής; Εάν το αρχείο αναφοράς είχε ενημερωμένο κωδικό χώρας, σωστά ενημερώνεται στο DB;

# 4) Επικύρωση μεταδεδομένων

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

Υπάρχουν δύο ομάδες εδώ:

διαφορά μεταξύ δοκιμών συστήματος και δοκιμών αποδοχής χρηστών

(i) Σχεδιασμός μεταδεδομένων: Ο πρώτος έλεγχος είναι να επιβεβαιωθεί ότι το μοντέλο δεδομένων έχει σχεδιαστεί σωστά σύμφωνα με τις επιχειρηματικές απαιτήσεις για τους πίνακες προορισμού. Οι αρχιτέκτονες δεδομένων ενδέχεται να μετεγκαταστήσουν οντότητες σχήματος ή να κάνουν τροποποιήσεις όταν σχεδιάζουν το σύστημα προορισμού.

Ο επόμενος έλεγχος θα πρέπει να είναι να επιβεβαιωθεί ότι τα σωστά σενάρια δημιουργήθηκαν χρησιμοποιώντας τα μοντέλα δεδομένων.

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

Μερικοί από τους ελέγχους μεταδεδομένων δίνονται παρακάτω:

  • Έλεγχος τύπου δεδομένων: Παράδειγμα: Οι συνολικές πωλήσεις θα λειτουργήσουν σωστά με δεκαδικό (8, 16 ή 20 bytes) ή διπλό τύπο;
  • Έλεγχος μήκους δεδομένων : Παράδειγμα: Θα είναι αρκετό το μήκος δεδομένων για το πεδίο Διεύθυνση με 500 χαρακτήρες; Μπορεί να είναι μια περίπτωση όπου η μετεγκατάσταση δεδομένων γίνεται καθώς νέα γεωγραφία προστίθεται στην εταιρεία. Οι διευθύνσεις της νέας γεωγραφίας ενδέχεται να έχουν υπερβολικά μεγάλη μορφή και η προσκόλληση στο αρχικό μήκος ενδέχεται να προκαλέσει σφάλμα σε περίπτωση χρήσης.
  • Έλεγχος ευρετηρίου: Παράδειγμα: Υπάρχει ευρετηρίαση για τη στήλη OrderId στο σύστημα προορισμού; Τι θα συμβεί εάν συνέβαινε συγχώνευση εταιρειών, που απαιτούν μετεγκατάσταση δεδομένων και ο πίνακας παραγγελιών αυξάνεται 100 φορές σε μέγεθος στο σύστημα-στόχο;
  • Έλεγχος μεταδεδομένων σε όλα τα περιβάλλοντα: Σε αυτόν τον έλεγχο επαληθεύστε ότι τα Μεταδεδομένα ταιριάζουν μεταξύ της δοκιμής QA και του περιβάλλοντος παραγωγής. Οι δοκιμές ενδέχεται να περάσουν στο περιβάλλον QA αλλά να αποτύχουν σε άλλα περιβάλλοντα.

(ii) Αλλαγή δέλτα: Αυτές οι δοκιμές αποκαλύπτουν ελαττώματα που προκύπτουν όταν το έργο βρίσκεται σε εξέλιξη και στη μέση υπάρχουν αλλαγές στα μεταδεδομένα του συστήματος προέλευσης και δεν εφαρμόστηκαν σε συστήματα στόχους.

Παράδειγμα: Νέο πεδίο CSI (δείκτης ικανοποίησης πελατών) προστέθηκε στον πίνακα πελατών στην πηγή, αλλά απέτυχε να γίνει στο σύστημα προορισμού.

# 5) Ακεραιότητα δεδομένων

Εδώ, επικυρώνουμε κυρίως τους περιορισμούς ακεραιότητας όπως Ξένο κλειδί, Πρωτεύον κλειδί αναφοράς, Μοναδικό, Προεπιλογή κ.λπ.

γονικός πίνακας

(εικόνα πηγή )

Για ξένα κλειδιά, πρέπει να ελέγξουμε αν υπάρχουν ορφανές εγγραφές στον θυγατρικό πίνακα όπου το ξένο κλειδί που χρησιμοποιείται δεν υπάρχει στον γονικό πίνακα.

Έλεγχος πληρότητας δεδομένων

Παράδειγμα: Ο πίνακας πελατών έχει το αναγνωριστικό πελάτη που είναι το πρωτεύον κλειδί. Ο πίνακας παραγγελιών έχει το CustomerID ως Ξένο κλειδί. Ο πίνακας παραγγελιών ενδέχεται να έχει ένα αναγνωριστικό πελάτη που δεν βρίσκεται στον πίνακα 'Πελάτες'. Πρέπει να κάνουμε δοκιμές για να αποκαλύψουμε τέτοιες παραβιάσεις περιορισμών ακεραιότητας. Ο πίνακας χαρτογράφησης δεδομένων θα σας δώσει σαφήνεια σχετικά με τους πίνακες που έχουν αυτούς τους περιορισμούς.

Σημείωση: Εκτελέστε αυτήν τη δοκιμή στο σύστημα προορισμού και ελέγξτε ξανά το σύστημα προέλευσης εάν υπάρχουν ελαττώματα.

# 6) Πληρότητα δεδομένων

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

Υπάρχουν δύο τύποι δοκιμών:

(i) Αριθμός εγγραφών: Εδώ, συγκρίνουμε τον συνολικό αριθμό εγγραφών για αντιστοίχιση πινάκων μεταξύ του συστήματος προέλευσης και του στόχου. Αυτός είναι ένας γρήγορος έλεγχος υγιεινής για να επαληθεύσετε την ανάρτηση της εργασίας ETL ή Migration. Έχουμε ένα ελάττωμα εάν οι μετρήσεις δεν ταιριάζουν.

Κατά καιρούς υπάρχουν απορριφθείσες εγγραφές κατά τη διάρκεια της εργασίας. Μερικά από αυτά μπορεί να είναι έγκυρα. Όμως, ως δοκιμαστής, κάνουμε μια υπόθεση για αυτό.

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

  • Όπου είναι εφικτό, φιλτράρετε όλες τις μοναδικές τιμές σε μια στήλη, για παράδειγμα, Το ProductID ενδέχεται να εμφανίζεται πολλές φορές στον πίνακα OrderDetails. Επιλέξτε μια μοναδική λίστα για το ProductID και από τους πίνακες προορισμού και προέλευσης και επικυρώστε. Αυτό μειώνει πολύ τον αριθμό των μετρήσεων ρεκόρ και επιταχύνει τις δοκιμές λογικής.
  • Όπως και οι παραπάνω δοκιμές, μπορούμε επίσης να επιλέξουμε όλες τις κύριες στήλες και να ελέγξουμε εάν τα KPI (ελάχιστο, μέγιστο, μέσο, ​​μέγιστο ή ελάχιστο μήκος κ.λπ.) ταιριάζουν μεταξύ του πίνακα στόχου και του πίνακα προέλευσης. Παράδειγμα: Λάβετε μέσες, ελάχιστες και μέγιστες τιμές από τη στήλη Τιμή στο OrderDetails και συγκρίνετε αυτές τις τιμές μεταξύ πινάκων προορισμού και πηγών για αναντιστοιχίες.
  • Ένας άλλος έλεγχος μπορεί να γίνει για τιμές Null. Επιλέξτε σημαντικές στήλες και φιλτράρετε μια λίστα γραμμών όπου η στήλη περιέχει τιμές Null. Συγκρίνετε αυτές τις σειρές μεταξύ των συστημάτων στόχου και πηγής για την αναντιστοιχία.

Χρονοδιάγραμμα

# 7) Μετασχηματισμός δεδομένων

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

Ακολουθεί μια συνοπτική λίστα δοκιμών που καλύπτονται από αυτό:

(i) Μετασχηματισμός:

  • Παράδειγμα: Ο κωδικός ETL μπορεί να έχει λογική για την απόρριψη μη έγκυρων δεδομένων. Επαληθεύστε αυτά με απαιτήσεις.
  • Ο κωδικός ETL μπορεί επίσης να περιέχει λογική για αυτόματη δημιουργία συγκεκριμένων κλειδιών, όπως τα υποκατάστατα κλειδιά. Πρέπει να έχουμε δοκιμές για να επαληθεύσουμε την ορθότητα (τεχνική και λογική) αυτών.
  • Επικυρώστε την ορθότητα της συμμετοχής ή του διαχωρισμού των τιμών πεδίου μετά την ολοκλήρωση μιας εργασίας ETL ή Migration.
  • Έχετε δοκιμές για να επαληθεύσετε τους ελέγχους ακεραιότητας αναφοράς. Για παράδειγμα, ένας τύπος ελαττώματος θα μπορούσε να είναι ProductId που χρησιμοποιείται στον πίνακα παραγγελιών δεν υπάρχει στον γονικό πίνακα Προϊόντα. Κάντε μια δοκιμή για να επαληθεύσετε τη συμπεριφορά των ορφανών αρχείων κατά τη διάρκεια μιας εργασίας ETL.
  • Κατά καιρούς, τα δεδομένα που λείπουν εισάγονται χρησιμοποιώντας τον κωδικό ETL. Επαληθεύστε την ορθότητα αυτών.
  • Τα σενάρια ETL ή Migration έχουν μερικές φορές λογική για τη διόρθωση δεδομένων. Επαληθεύστε ότι η διόρθωση δεδομένων λειτουργεί.
  • Επαληθεύστε εάν αναφέρθηκαν μη έγκυρα / απορριφθέντα / λανθασμένα δεδομένα στους χρήστες.
  • Δημιουργήστε ένα υπολογιστικό φύλλο σεναρίων δεδομένων εισαγωγής και αναμενόμενων αποτελεσμάτων και επικυρώστε τα με τον επιχειρηματικό πελάτη.

(ii) Περίβλημα: Βεβαιωθείτε ότι η λογική του Μετασχηματισμού έχει καλή ισχύ στα όρια.

  • Παράδειγμα: Τι συμβαίνει όταν η TotalSales αξίας 1 τρισεκατομμυρίου εκτελείται μέσω μιας εργασίας ETL; Λειτουργεί το άκρο σε άκρο; Προσδιορίστε πεδία που ενδέχεται να έχουν μεγάλες τιμές και εκτελέστε δοκιμές με αυτές τις μεγάλες τιμές. Πρέπει να περιλαμβάνουν αριθμητικές και μη αριθμητικές τιμές.
  • Για πεδία ημερομηνιών, συμπεριλαμβανομένου ολόκληρου του εύρους των αναμενόμενων ημερομηνιών - έτη άλματος, 28/29 ημέρες για τον Φεβρουάριο. 30, 31 ημέρες για άλλους μήνες.

# 8) Μοναδικότητα ή επικάλυψη δεδομένων

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

  • Παράδειγμα: Φιλτράρετε για διπλά δεδομένα και επαληθεύστε εάν είναι αυθεντικά. Για παράδειγμα, Η εγγραφή που εξαρτάται από τον εργαζόμενο περιέχει τα ίδια δεδομένα αδελφών δύο φορές.
  • Ο αριθμός τηλεφώνου χρήστη πρέπει να είναι μοναδικός στο σύστημα (επιχειρηματική απαίτηση).
  • Η επιχειρησιακή απαίτηση αναφέρει ότι ο συνδυασμός ProductID και ProductName στον πίνακα προϊόντων πρέπει να είναι μοναδικός, καθώς το ProductName μπορεί να είναι διπλότυπο.

# 9) Υποχρεωτικό

Σε αυτόν τον τύπο δοκιμής, προσδιορίστε όλα τα πεδία που επισημαίνονται ως Υποχρεωτικά και επικυρώστε εάν τα υποχρεωτικά πεδία έχουν τιμές. Εάν υπάρχουν προεπιλεγμένες τιμές που σχετίζονται με ένα πεδίο στο DB, επαληθεύστε εάν συμπληρώνεται σωστά όταν τα δεδομένα δεν είναι εκεί.

  • Παράδειγμα: Εάν δεν καταχωρηθεί το BillDate, τότε το CurrentDate είναι το BillDate.

# 10) Επικαιρότητα

Να τεκμηριώνετε πάντα τις δοκιμές που επαληθεύουν ότι εργάζεστε με δεδομένα από τα συμφωνημένα χρονοδιαγράμματα.

  • Παράδειγμα: Το ProductDiscount ενημερώθηκε πριν από 15 ημέρες και οι καταστάσεις του επιχειρηματικού τομέα αλλάζουν το ProductDiscount κάθε επτά ημέρες. Αυτό σημαίνει ότι οι δοκιμές σας δεν γίνονται με τις σωστές τιμές έκπτωσης.
  • Μια προγνωστική αναφορά ανάλυσης για τον δείκτη ικανοποίησης πελατών υποτίθεται ότι λειτουργεί με τα τελευταία δεδομένα 1 εβδομάδας, η οποία ήταν μια εβδομάδα προώθησης πωλήσεων στο Walmart. Αλλά η εργασία ETL σχεδιάστηκε για να λειτουργεί με συχνότητα 15 ημερών. Αυτό είναι ένα μεγάλο ελάττωμα που μπορούν να αποκαλύψουν οι υπεύθυνοι δοκιμών.

# 11) Μηδενικά δεδομένα

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

  • Παράδειγμα: Φιλτράρετε όλα τα δεδομένα null και επικυρώστε εάν επιτρέπεται το null.
  • Εάν υπάρχουν σημαντικές στήλες για επιχειρηματικές αποφάσεις, βεβαιωθείτε ότι δεν υπάρχουν null.

# 12) Έλεγχος εύρους

Η οντότητα δεδομένων όπου τα εύρη έχουν νόημα για την επιχείρηση πρέπει να δοκιμάζονται.

  • Παράδειγμα: Η ποσότητα παραγγελίας ανά τιμολόγιο δεν μπορεί να υπερβαίνει τα 5K στην κατηγορία λογισμικού.
  • Η ηλικία δεν πρέπει να είναι μεγαλύτερη από 120.

# 13) Επιχειρηματικοί κανόνες

Τεκμηριώστε τυχόν επιχειρηματικές απαιτήσεις για πεδία και εκτελέστε δοκιμές για το ίδιο.

  • Παράδειγμα: Οι πόροι με ηλικία κάτω των 20 ετών δεν είναι επιλέξιμοι. Απαιτούνται έλεγχοι επικύρωσης δεδομένων εάν αυτός ο κανόνας εφαρμόζεται στα δεδομένα.
  • Η ημερομηνία λήξης θα πρέπει να είναι μηδενική εάν η κατάσταση Ενεργού υπαλλήλου είναι Αληθής / Απενεργοποιημένη.
  • Τα δεδομένα FROM πρέπει να είναι μικρότερα από την ΗΜΕΡΟΜΗΝΙΑ.
  • Κάντε τα ποσά αγοράς σε επίπεδο ποσού σε ποσά παραγγελιών

# 14) Συγκεντρωτικές λειτουργίες

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

Πολύ συχνά τα εργαλεία στο σύστημα προέλευσης διαφέρουν από το σύστημα προορισμού. Ελέγξτε εάν και τα δύο εργαλεία εκτελούν συγκεντρωτικές λειτουργίες με τον ίδιο τρόπο.

# 15) Περικοπή και στρογγυλοποίηση δεδομένων

Σε αυτούς τους τύπους δοκιμών, εντοπίζουμε πεδία με λογική περικοπής και στρογγυλοποίησης σχετικά με την επιχείρηση. Στη συνέχεια τεκμηριώνουμε και αποσυνδέουμε τη λογική περικοπής και στρογγυλοποίησης με τους κατόχους προϊόντων και τους δοκιμάζουμε με αντιπροσωπευτικά δεδομένα παραγωγής.

# 16) Δοκιμές κωδικοποίησης

Επικυρώστε εάν υπάρχουν κωδικοποιημένες τιμές στο σύστημα προέλευσης και επαληθεύστε εάν τα δεδομένα συμπληρώνονται σωστά μετά το ETL ή την εργασία μετεγκατάστασης δεδομένων στο σύστημα προορισμού.

  • Παράδειγμα: Οι χαρακτήρες διπλού byte για το FirstName στα Κινεζικά έγιναν δεκτοί στο σύστημα προέλευσης που κωδικοποιήθηκε. Επαληθεύστε τη συμπεριφορά αυτού του πεδίου όταν μετακινηθείτε στο σύστημα προορισμού.
  • Το πεδίο Κωδικός κωδικοποιήθηκε και μετεγκαταστάθηκε. Βεβαιωθείτε ότι λειτουργούν καλά μετά τη μετανάστευση.

# 17) Δοκιμές παλινδρόμησης

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

συμπέρασμα

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

Πρέπει να ληφθεί μέριμνα για τη διατήρηση των αλλαγών του δέλτα σε όλες τις εκδόσεις.

Ζητούμε από τους αναγνώστες να μοιραστούν άλλους τομείς της δοκιμής που έχουν συναντήσει κατά τη διάρκεια της εργασίας τους για να ωφελήσουν την κοινότητα των δοκιμαστών.

Συνιστώμενη ανάγνωση

^