comprehensive hadoop testing tutorial big data testing guide
Αυτό το σεμινάριο εξηγεί τα βασικά, τους τύπους δοκιμών, τα σχέδια, το απαιτούμενο περιβάλλον, τη διαδικασία δοκιμών, την επικύρωση και τις επαληθεύσεις για τη δοκιμή Hadoop και BigData:
Σε αυτό το σεμινάριο, θα δούμε τη βασική εισαγωγή των δοκιμών Hadoop και BigData, όπως πότε και πού θα έρθει η δοκιμή στην εικόνα και τι πρέπει να δοκιμάσουμε ως μέρος της δοκιμής Hadoop.
Θα συζητήσουμε επίσης λεπτομερώς τα ακόλουθα θέματα:
- Ρόλοι και ευθύνες της δοκιμής Hadoop
- Προσέγγιση δοκιμών για δοκιμές Hadoop / BigData
=> Δείτε εδώ για να δείτε το A-Z Of BigData Training Tutorials εδώ.
Τι θα μάθετε:
- Αποθήκευση και επεξεργασία δεδομένων στο Hadoop
- Δοκιμή BigData και Hadoop
- Ποια είναι η στρατηγική ή το σχέδιο για τη δοκιμή BigData;
- Τύποι δοκιμών για δοκιμές BigData
- Εργαλεία για δοκιμές BigData Hadoop
- Δοκιμή περιβάλλοντος και ρυθμίσεων
- Ρόλοι και ευθύνες της δοκιμής Hadoop
- Προσέγγιση δοκιμής για δοκιμή Hadoop / Δοκιμή BigData
- συμπέρασμα
- Συνιστώμενη ανάγνωση
Αποθήκευση και επεξεργασία δεδομένων στο Hadoop
Για να εκτελέσουμε αυτές τις διαδικασίες στο σύστημα Hadoop, έχουμε το ανθρώπινο δυναμικό που κατηγοριοποιείται σε τέσσερις ενότητες.
- Διαχειριστές Hadoop είναι υπεύθυνοι για τη ρύθμιση του περιβάλλοντος και έχουν τα δικαιώματα διαχείρισης για πρόσβαση στα συστήματα Hadoop.
- Προγραμματιστές Hadoop να αναπτύξουν τα προγράμματα σχετικά με τη συλλογή, αποθήκευση και επεξεργασία των δεδομένων από διαφορετικές τοποθεσίες σε κεντρικές τοποθεσίες.
- Δοκιμαστές Hadoop για επικύρωση και επαλήθευση των δεδομένων πριν από την απόσυρση από διαφορετικές τοποθεσίες και μετά την απόσυρση στην κεντρική τοποθεσία, καθώς και την επικύρωση και επαλήθευση κατά τη φόρτωση των δεδομένων στο περιβάλλον του πελάτη.
- Αναλυτές Hadoop λειτουργούν όταν γίνεται η φόρτωση δεδομένων και όταν τα δεδομένα φτάνουν στην αποθήκη στην τοποθεσία του πελάτη. Χρησιμοποιούν αυτά τα δεδομένα για τη δημιουργία αναφορών και ταμπλό. Οι αναλυτές πραγματοποιούν την ανάλυση δεδομένων για ανάπτυξη και ανάπτυξη επιχειρήσεων.
Γνωρίζουμε ότι το Hadoop δεν είναι ένα ενιαίο σύστημα. περιέχει πολλά συστήματα και μηχανήματα. Τα δεδομένα χωρίζονται και αποθηκεύονται σε πολλά μηχανήματα και αν θέλουμε να αποκτήσουμε ξανά πρόσβαση σε αυτά, πρέπει να συνδυάσουμε και να τραβήξουμε τα δεδομένα σε αναφορές και ούτω καθεξής.
Ο προγραμματιστής είναι υπεύθυνος για τη σύνταξη προγραμμάτων στο JAVA και το Python για την εξαγωγή των δεδομένων και την αποθήκευσή τους.
Η άλλη δουλειά ενός προγραμματιστή είναι η επεξεργασία των δεδομένων. Υπάρχουν δύο επίπεδα Hadoop, το ένα είναι για αποθήκευση δηλ. Hadoop HDFS και ένα άλλο για επεξεργασία, δηλαδή Hadoop MapReduce.
Η αποθήκευση σημαίνει ότι όσα δεδομένα έχουμε στην πηγή αποθηκεύονται / εισάγονται στο σύστημα. Η επεξεργασία σημαίνει ότι πρέπει να το χωρίσουμε σε πολλά μηχανήματα και να το συνδυάσουμε ξανά και να το στείλουμε στον πελάτη.
Έτσι, η αποθήκευση και η επεξεργασία γίνονται με σενάρια προγραμματισμού και ο προγραμματιστής είναι υπεύθυνος για τη σύνταξη των σεναρίων.
Εκτός από τον προγραμματισμό, η άλλη μέθοδος αποθήκευσης και επεξεργασίας των δεδομένων στο Hadoop είναι η χρήση εφαρμογών βάσης δεδομένων όπως Hive, Impala, HBase κ.λπ. Αυτά τα εργαλεία δεν χρειάζονται γνώσεις προγραμματισμού.
Δοκιμή BigData και Hadoop
Μόλις η αποθήκευση και η επεξεργασία γίνουν από τον προγραμματιστή, τα δεδομένα πηγαίνουν για τη δημιουργία αναφορών. Πριν από αυτό, πρέπει να επαληθεύσουμε την ακρίβεια των επεξεργασμένων δεδομένων και να ελέγξουμε εάν τα δεδομένα φορτώνονται και επεξεργάζονται σωστά ή όχι.
Επομένως, το πρόγραμμα ή / και τα σενάρια που δημιουργήθηκαν από έναν προγραμματιστή πρέπει να επαληθευτούν από το Hadoop ή το BigData Tester. Ο υπεύθυνος δοκιμών πρέπει να γνωρίζει βασικό προγραμματισμό όπως Mapper, Hive, Pig Scripts κ.λπ. για να επαληθεύσει τα σενάρια και να εκτελέσει τις εντολές.
Έτσι, πριν από τη δοκιμή, οι δοκιμαστές πρέπει να γνωρίζουν τι λειτουργούν όλα τα προγράμματα και τα σενάρια, πώς να γράψουν τον κώδικα και στη συνέχεια να σκεφτούν πώς να τα δοκιμάσουν. Ο έλεγχος μπορεί να γίνει είτε χειροκίνητα είτε χρησιμοποιώντας εργαλεία αυτοματισμού.
Το Hadoop έχει διάφορα είδη δοκιμών, όπως δοκιμή μονάδας, δοκιμή παλινδρόμησης, δοκιμή συστήματος και δοκιμές απόδοσης κ.λπ. Έτσι, αυτοί είναι οι συνηθισμένοι τύποι δοκιμών που χρησιμοποιούμε στις κανονικές δοκιμές μας, καθώς και οι δοκιμές Hadoop και BigData.
Έχουμε το ίδιο είδος ορολογιών δοκιμής όπως στρατηγική δοκιμών, σενάρια δοκιμών και περιπτώσεις δοκιμών κ.λπ. στο Hadoop και BigData Testing. Μόνο το περιβάλλον είναι διαφορετικό και υπάρχουν διαφορετικά είδη τεχνικών που χρησιμοποιούμε για τη δοκιμή του συστήματος BigData και Hadoop, επειδή εδώ πρέπει να δοκιμάσουμε τα δεδομένα και όχι την εφαρμογή.
Πώς να δοκιμάσετε τα BigData και τι απαιτούν όλες οι δοκιμές στα BigData;
Για τη δοκιμή BigData, πρέπει να έχουμε κάποια σχέδια και στρατηγικές.
Επομένως, πρέπει να λάβουμε υπόψη τα ακόλουθα σημεία:
- Ποια είναι η στρατηγική ή το σχέδιο δοκιμών για τα BigData;
- Τι είδους προσεγγιστικές δοκιμές εφαρμόζονται στο BigData;
- Τι απαιτείται για το περιβάλλον;
- Πώς να επικυρώσετε και να επαληθεύσετε τα BigData;
- Ποια είναι τα εργαλεία που χρησιμοποιούνται στο BigData Testing;
Ας προσπαθήσουμε να λάβουμε τις απαντήσεις σε όλες τις παραπάνω ερωτήσεις.
Ποια είναι η στρατηγική ή το σχέδιο για τη δοκιμή BigData;
Η δοκιμή BigData σημαίνει επαλήθευση και επικύρωση δεδομένων κατά την αποθήκευση και την επεξεργασία τους στην αποθήκη δεδομένων.
Κατά τη δοκιμή του BigData, πρέπει να δοκιμάσουμε τον Όγκο και την Ποικιλία των δεδομένων που εξάγονται από διαφορετικές βάσεις δεδομένων και φορτώνονται καθώς και υποβάλλονται σε επεξεργασία σε Data Warehouse ή Hadoop System, αυτή η δοκιμή υπόκειται σε λειτουργικές δοκιμές.
Πρέπει να δοκιμάσουμε την ταχύτητα των δεδομένων που λαμβάνονται από διάφορες βάσεις δεδομένων και ανεβάζουμε στο Hadoop System, το οποίο αποτελεί μέρος του Performance Testing.
Επομένως, ως σχέδιο ή στρατηγική, πρέπει να επικεντρωθούμε τόσο στη λειτουργική όσο και στη δοκιμή απόδοσης των δοκιμών BigData.
Στο BigData Testing, ο υπεύθυνος δοκιμών πρέπει να επαληθεύσει την επεξεργασία τεράστιου όγκου δεδομένων χρησιμοποιώντας Commodity Hardware και σχετικά στοιχεία. Ως εκ τούτου, η ποιότητα των δεδομένων παίζει επίσης σημαντικό ρόλο στη δοκιμή των BigData. Είναι σημαντικό να επαληθεύσετε και να επικυρώσετε την ποιότητα των δεδομένων.
Τύποι δοκιμών για δοκιμές BigData
Στην προηγούμενη ενότητα, είδαμε ότι οι λειτουργικές δοκιμές και δοκιμές απόδοσης διαδραματίζουν ζωτικό ρόλο στη δοκιμή BigData, εκτός από αυτήν ως BigData Tester, πρέπει να κάνουμε μερικούς περισσότερους τύπους δοκιμών, όπως το Database Testing καθώς και το Architectural Testing.
Αυτοί οι τύποι δοκιμών είναι επίσης εξίσου σημαντικοί με το Functional and Performance Testing.
# 1) Αρχιτεκτονικές δοκιμές
Αυτός ο έλεγχος γίνεται για να διασφαλιστεί ότι η επεξεργασία των δεδομένων είναι ορθή και πληροί τις απαιτήσεις. Στην πραγματικότητα, το σύστημα Hadoop επεξεργάζεται τεράστιους όγκους δεδομένων και είναι εξαιρετικά περιεκτικό σε πόρους.
Εάν η αρχιτεκτονική είναι ακατάλληλη, τότε μπορεί να υποβαθμίσει την απόδοση λόγω της οποίας η επεξεργασία των δεδομένων μπορεί να διακοπεί και να προκληθεί απώλεια δεδομένων.
# 2) Δοκιμή βάσης δεδομένων
Εδώ, η επικύρωση της διαδικασίας έρχεται στην εικόνα και πρέπει να επικυρώσουμε τα δεδομένα από διάφορες βάσεις δεδομένων, δηλαδή πρέπει να διασφαλίσουμε ότι τα δεδομένα που συλλέγονται από τις βάσεις δεδομένων προέλευσης ή τις τοπικές βάσεις δεδομένων πρέπει να είναι σωστά και σωστά.
Επίσης, πρέπει να ελέγξουμε ότι τα διαθέσιμα δεδομένα στις βάσεις δεδομένων προέλευσης ταιριάζουν με τα δεδομένα που έχουν εισαχθεί στο σύστημα Hadoop.
Ομοίως, πρέπει να επικυρώσουμε εάν τα δεδομένα στο Hadoop System είναι σωστά και σωστά μετά την επεξεργασία ή πείτε μετά τον μετασχηματισμό και να φορτωθούν στο περιβάλλον του πελάτη με σωστή επικύρωση και επαλήθευση.
Ως μέρος της δοκιμής βάσεων δεδομένων, πρέπει να περάσουμε από το ΣΚΛΗΡΟΣ λειτουργίες δηλ. Δημιουργώ τα δεδομένα στις Τοπικές βάσεις δεδομένων τότε Ανακτώ τα δεδομένα και πρέπει να τα αναζητήσουμε και θα πρέπει να είναι διαθέσιμα στη βάση δεδομένων πριν και μετά τη φόρτωση στην αποθήκη δεδομένων και από την αποθήκη δεδομένων στο περιβάλλον του πελάτη.
Επαλήθευση οποιουδήποτε ΕΠΙΚΑΙΡΟΠΟΙΗΜΕΝΟ Δεδομένα για κάθε στάδιο αποθήκευσης ή φόρτωσης και επεξεργασίας των δεδομένων. Διαγραφή τυχόν κατεστραμμένων δεδομένων ή αντιγράφων και μηδενικών δεδομένων.
# 3) Δοκιμή απόδοσης
Ως μέρος του Performance Testing, πρέπει να ελέγξουμε την ταχύτητα φόρτωσης και επεξεργασίας δεδομένων, όπως το IOPS (Έξοδος εισόδου ανά δευτερόλεπτο).
Πρέπει να ελέγξετε την ταχύτητα εισαγωγής των δεδομένων ή των δεδομένων ως εισόδου από διάφορες βάσεις δεδομένων στην αποθήκη δεδομένων ή στο σύστημα Hadoop και από το σύστημα Hadoop ή την αποθήκη δεδομένων στο περιβάλλον του πελάτη.
Πρέπει επίσης να ελέγξετε την ταχύτητα των δεδομένων που προέρχονται από διάφορες βάσεις δεδομένων και από την αποθήκη δεδομένων ως έξοδο. Αυτό ονομάζουμε έξοδο εισόδου ανά δευτερόλεπτο ή IOPS.
Εκτός από αυτό, μια άλλη πτυχή είναι να ελέγξετε την απόδοση της Απορρόφησης Δεδομένων και της Διανομής Δεδομένων και πόσο γρήγορα τα δεδομένα καταναλώνονται από την Αποθήκη Δεδομένων από διάφορες Βάσεις Δεδομένων και από το Σύστημα Πελάτη από το Hadoop System.
Επίσης, ως Tester, πρέπει να ελέγξουμε την απόδοση της Διανομής Δεδομένων, όπως πόσο γρήγορα τα δεδομένα διανέμονται σε διάφορα αρχεία που είναι διαθέσιμα στο Hadoop System ή στην Data Warehouse. Ομοίως, η ίδια διαδικασία συμβαίνει κατά τη διανομή δεδομένων σε συστήματα πελατών.
Το σύστημα Hadoop ή η αποθήκη δεδομένων αποτελείται από πολλά στοιχεία, οπότε ένας δοκιμαστής πρέπει να ελέγξει την απόδοση όλων αυτών των στοιχείων όπως το MapReduce Jobs, την εισαγωγή και κατανάλωση δεδομένων, τον χρόνο απόκρισης των ερωτημάτων και την απόδοσή τους καθώς και την απόδοση της αναζήτησης λειτουργίες. Όλα αυτά περιλαμβάνονται στη Δοκιμή απόδοσης.
# 4) Λειτουργική δοκιμή
Η λειτουργική δοκιμή περιέχει δοκιμές όλων των υπο-στοιχείων, προγραμμάτων και σεναρίων, εργαλείων που χρησιμοποιούνται για την εκτέλεση των λειτουργιών αποθήκευσης ή φόρτωσης και επεξεργασίας κ.λπ.
Για έναν Tester, αυτοί είναι οι τέσσερις σημαντικοί τύποι και στάδια μέσω των οποίων τα δεδομένα πρέπει να φιλτραριστούν, ώστε ο πελάτης να λάβει τα τέλεια και χωρίς σφάλματα δεδομένα.
Εργαλεία για δοκιμές BigData Hadoop
Υπάρχουν διάφορα εργαλεία που χρησιμοποιούνται για τη δοκιμή BigData:
- Σύστημα αρχείων διανομής HDFS Hadoop για την αποθήκευση των BigData.
- Μείωση χάρτη HDFS για την επεξεργασία των BigData.
- Για NoSQL ή HQL Cassandra DB, ZooKeeper και HBase κ.λπ.
- Εργαλεία διακομιστή που βασίζονται σε σύννεφο όπως το EC2.
Δοκιμή περιβάλλοντος και ρυθμίσεων
Για κάθε τύπο δοκιμής, ο ελεγκτής χρειάζεται κατάλληλες ρυθμίσεις και περιβάλλον.
Παρακάτω δίνεται η λίστα απαιτήσεων:
- Τύπος δεδομένων και εφαρμογών που πρόκειται να δοκιμαστούν.
- Η αποθήκευση και επεξεργασία απαιτεί μεγάλο χώρο για τεράστιο όγκο δεδομένων.
- Η σωστή διανομή αρχείων σε όλους τους DataNodes συνολικά το σύμπλεγμα.
- Κατά την επεξεργασία των δεδομένων, η χρήση υλικού πρέπει να είναι ελάχιστη.
- Εκτελέσιμα προγράμματα και σενάρια σύμφωνα με την απαίτηση της εφαρμογής.
Ρόλοι και ευθύνες της δοκιμής Hadoop
Ως Hadoop Tester, είμαστε υπεύθυνοι για την κατανόηση των απαιτήσεων, την προετοιμασία των εκτιμήσεων δοκιμής, τον προγραμματισμό των δοκιμαστικών περιπτώσεων, τη λήψη ορισμένων δεδομένων δοκιμής για τη δοκιμή ορισμένων δοκιμαστικών περιπτώσεων, τη συμμετοχή στη δημιουργία δοκιμαστικών κρεβατιών, την εκτέλεση των σχεδίων δοκιμής, την αναφορά και την επανεξέταση ελαττωμάτων.
Επίσης, πρέπει να είμαστε υπεύθυνοι για την Ημερήσια αναφορά κατάστασης και την ολοκλήρωση δοκιμής.
Το πρώτο πράγμα που πρόκειται να συζητήσουμε είναι το Στρατηγική δοκιμής . Μόλις έχουμε μια προτεινόμενη λύση στο πρόβλημά μας, πρέπει να προχωρήσουμε και να σχεδιάσουμε ή να σχεδιάσουμε το σχέδιο δοκιμών μας, μπορούμε να συζητήσουμε τη στρατηγική αυτοματισμού που μπορούμε να χρησιμοποιήσουμε εκεί, το σχέδιο για το πρόγραμμα δοκιμών που εξαρτάται από τις ημερομηνίες παράδοσης, επίσης εμείς μπορεί να συζητήσει τον προγραμματισμό πόρων.
Η στρατηγική αυτοματισμού είναι κάτι που θα μας βοηθήσει να μειώσουμε τις μη αυτόματες προσπάθειες που απαιτούνται για τη δοκιμή του προϊόντος. Το πρόγραμμα δοκιμών είναι σημαντικό, καθώς θα διασφαλίσει την έγκαιρη παράδοση του προϊόντος.
Ο προγραμματισμός πόρων θα είναι ζωτικής σημασίας καθώς πρέπει να προγραμματίσουμε πόσες ανθρωποώρες χρειαζόμαστε στις δοκιμές μας και πόσες Hadoop Πόροι απαιτούνται για την εκτέλεση του δοκιμαστικού προγραμματισμού μας.
Μόλις σχεδιάσουμε τις δοκιμές μας, πρέπει να προχωρήσουμε και να δημιουργήσουμε τα σχέδια ανάπτυξης δοκιμών που περιλαμβάνουν τη δημιουργία σχεδίων δοκιμής, τη δημιουργία δοκιμαστικών σεναρίων που θα μας βοηθήσουν να αυτοματοποιήσουμε τις δοκιμές μας και επίσης να προσδιορίσουμε ορισμένα δεδομένα δοκιμών που πρόκειται να χρησιμοποιηθούν στα σχέδια δοκιμών και μας βοηθά να εκτελέσουμε αυτά τα σχέδια δοκιμής.
Μόλις τελειώσουμε με τη δοκιμή ανάπτυξης που περιλαμβάνει τη δημιουργία σχεδίων δοκιμής, δοκιμαστικών σεναρίων και δεδομένων δοκιμής, προχωράμε και αρχίζουμε να εκτελούμε αυτά τα δοκιμαστικά σχέδια.
Όταν εκτελούμε τα Δοκιμαστικά Σχέδια, μπορεί να υπάρχουν ορισμένα σενάρια όπου η πραγματική έξοδος δεν είναι όπως αναμένεται και αυτά τα πράγματα ονομάζονται ελαττώματα. Όποτε υπάρχει κάποιο ελάττωμα, πρέπει να δοκιμάσουμε και αυτά τα ελαττώματα και πρέπει να δημιουργήσουμε και να διατηρήσουμε τους πίνακες για αυτά.
Όλα αυτά τα πράγματα εμπίπτουν στην επόμενη κατηγορία που είναι Διαχείριση ελαττωμάτων .
Τι είναι η διαχείριση ελαττωμάτων;
Η διαχείριση ελαττωμάτων αποτελείται από εντοπισμό σφαλμάτων, διόρθωση σφαλμάτων και επαλήθευση σφαλμάτων. Κάθε φορά που εκτελείται ένα Δοκιμαστικό Σχέδιο έναντι οποιουδήποτε από τα προϊόντα που έχουμε και μόλις εντοπιστεί ένα συγκεκριμένο σφάλμα ή εντοπιστεί κάποιο ελάττωμα, τότε αυτό το ελάττωμα πρέπει να αναφέρεται στον προγραμματιστή ή να ανατεθεί στον προγραμματιστή.
Έτσι ο προγραμματιστής μπορεί να το εξετάσει και να αρχίσει να το επεξεργάζεται. Ως δοκιμαστής, πρέπει να παρακολουθούμε την πρόοδο του Bug και να παρακολουθούμε εάν το σφάλμα έχει διορθωθεί. Εάν το σφάλμα έχει διορθωθεί όπως αναφέρεται, τότε πρέπει να προχωρήσουμε και να το δοκιμάσουμε ξανά και να επαληθεύσουμε εάν έχει επιλυθεί.
Μόλις διορθωθούν όλα τα σφάλματα, κλείσουν και επαληθευτούν, τότε πρέπει να προχωρήσουμε και να παραδώσουμε ένα προϊόν δοκιμασμένο OKAY. Πριν όμως παραδώσουμε το προϊόν πρέπει να βεβαιωθούμε ότι το UAT (User Acceptance Testing) ολοκληρώθηκε με επιτυχία.
Διασφαλίζουμε ότι οι δοκιμές εγκατάστασης και η επαλήθευση των απαιτήσεων γίνονται σωστά, δηλαδή το προϊόν που παραδίδεται στον πελάτη ή στον τελικό χρήστη είναι σύμφωνα με την απαίτηση που αναφέρεται στο Έγγραφο Απαίτησης Λογισμικού.
Τα βήματα που έχουμε συζητήσει βασίζονται στη φαντασία, είτε σε οποιοδήποτε σενάριο δοκιμών είτε σε οποιαδήποτε από τις προσεγγίσεις δοκιμών που πρόκειται να χρησιμοποιήσουμε για αυτά τα βήματα ή πείτε αυτές τις φράσεις για να δοκιμάσετε το προϊόν μας και να παραδώσετε το τελικό αποτέλεσμα, το οποίο είναι OKAY Δοκιμασμένο προϊόν.
Ας προχωρήσουμε και να το συζητήσουμε λεπτομερώς και να το συσχετίσουμε με το Hadoop Testing.
Γνωρίζουμε ότι το Hadoop είναι κάτι που χρησιμοποιείται για Batch Processing και γνωρίζουμε επίσης ότι το ETL είναι ένα από τα πεδία όπου το Hadoop χρησιμοποιείται πολύ. Το ETL σημαίνει Μετατροπή Εξαγωγής και Φόρτωση . Θα συζητήσουμε λεπτομερώς αυτές τις διαδικασίες όταν συζητάμε το Σχέδιο δοκιμών και τη στρατηγική δοκιμών ως άποψη δοκιμής Hadoop.
Σύμφωνα με το παρακάτω διάγραμμα, υποθέτουμε ότι έχουμε τέσσερις διαφορετικές πηγές δεδομένων. Λειτουργικό σύστημα, CRM ( Διαχείριση σχέσεων πελατών ) και ERP ( Επιχειρησιακός προγραμματισμός πόρων ) είναι το RDBMS ή πείτε το Σχεσιακό Σύστημα Διαχείρισης Βάσεων Δεδομένων που διαθέτουμε και έχουμε επίσης ένα σωρό Flat Files που ίσως καταγράφει αρχεία, αρχεία, αρχεία ή οτιδήποτε άλλο σχετικά με τις Πηγές δεδομένων μας.
Ίσως χρησιμοποιούμε το Sqoop ή το Flume ή οποιοδήποτε συγκεκριμένο προϊόν για να λάβουμε τα Δεδομένα, τα αρχεία ή οτιδήποτε άλλο ως Πηγές δεδομένων μου. Μπορούμε να χρησιμοποιήσουμε αυτά τα εργαλεία για να μεταφέρουμε τα δεδομένα από τις Πηγές δεδομένων στον κατάλογο σταδιοποίησης που είναι η πρώτη φάση της διαδικασίας που ονομάζεται Εξαγωγή.
Μόλις ο Δεδομένος σε αυτόν τον Κατάλογο Σταδιοποίησης που στην πραγματικότητα είναι HDFS (Hadoop Distribution File System), θα χρησιμοποιήσουμε ιδιαίτερα τη γλώσσα δέσμης ενεργειών όπως το PIG to Μεταμορφώνω αυτά τα δεδομένα. Οτι Μεταμόρφωση θα είναι σύμφωνα με τα Δεδομένα που έχουμε.
Μόλις τα δεδομένα μεταμορφωθούν ανάλογα χρησιμοποιώντας οποιαδήποτε τεχνολογία δέσμης ενεργειών που έχουμε, θα είμαστε Φόρτωση αυτά τα δεδομένα στην αποθήκη δεδομένων. Από την αποθήκη δεδομένων, αυτά τα δεδομένα θα χρησιμοποιηθούν για ανάλυση OLAP, αναφορά και εξόρυξη δεδομένων ή για το Analytics.
Ας προχωρήσουμε και συζητήσουμε ποιες φάσεις μπορούμε να χρησιμοποιήσουμε για το Hadoop Testing.
Η πρώτη φάση θα είναι η φάση εξαγωγής. Εδώ, πρόκειται να λάβουμε τα δεδομένα από τις Βάσεις δεδομένων προέλευσης ή από Flat αρχεία, και σε αυτήν την περίπτωση, αυτό που μπορούμε να κάνουμε είναι, μπορούμε να επαληθεύσουμε ότι όλα τα δεδομένα έχουν αντιγραφεί επιτυχώς και σωστά από την πηγή στον κατάλογο Staging.
Μπορεί να περιλαμβάνει, επαλήθευση του αριθμού των εγγραφών, του τύπου των εγγραφών και του τύπου των πεδίων κ.λπ.
Μόλις αντιγραφούν αυτά τα δεδομένα στον Κατάλογο Στάδιο, θα προχωρήσουμε και θα ενεργοποιήσουμε τη δεύτερη φάση που είναι ο Μετασχηματισμός. Εδώ, θα έχουμε κάποια επιχειρηματική λογική που θα ενεργεί στα αντιγραμμένα δεδομένα από τα Source Systems και θα δημιουργήσει ή θα μετατρέψει τα δεδομένα στην απαιτούμενη επιχειρησιακή λογική.
Ο μετασχηματισμός μπορεί να περιλαμβάνει ταξινόμηση των δεδομένων, φιλτράρισμα των δεδομένων, σύνδεση των δεδομένων από δύο διαφορετικές πηγές δεδομένων και ορισμένες άλλες λειτουργίες.
Μόλις μετασχηματιστούν τα δεδομένα, θα προχωρήσουμε και θα έχουμε έτοιμα σχέδια δοκιμών και θα ελέγξουμε εάν λαμβάνουμε την έξοδο όπως αναμένεται και όλη η έξοδος που λαμβάνουμε πληροί το αναμενόμενο αποτέλεσμα και τους τύπους δεδομένων, τις τιμές πεδίου και τα εύρη, κ.λπ. είναι κάτι που ισχύει.
Μόλις είναι σωστό, μπορούμε να προχωρήσουμε και να φορτώσουμε τα δεδομένα στην αποθήκη δεδομένων.
Στη φάση φόρτωσης, ελέγχουμε αν ο αριθμός των εγγραφών από το Stage και ο αριθμός των εγγραφών στο Data Warehouse είναι συγχρονισμένοι, ενδέχεται να μην είναι παρόμοιοι, αλλά υποτίθεται ότι είναι συγχρονισμένοι. Βλέπουμε επίσης εάν ο τύπος των δεδομένων που έχουν μετατραπεί είναι συγχρονισμένος.
Δημοσιεύστε ότι θα χρησιμοποιήσουμε αυτά τα Δεδομένα για Ανάλυση OLAP, Αναφορά και Εξόρυξη Δεδομένων που είναι το τελευταίο επίπεδο του προϊόντος μας και σε αυτήν την περίπτωση, μπορούμε να έχουμε μεταγενέστερα ή να πούμε ότι τα Σχέδια δοκιμής είναι διαθέσιμα για όλα αυτά τα επίπεδα.
Όποτε λαμβάνουμε ορισμένα δεδομένα από την Πηγή στον προορισμό, τότε πρέπει πάντα να βεβαιωθούμε ότι μόνο εξουσιοδοτημένα άτομα έχουν Εξουσιοδοτημένη πρόσβαση στα Δεδομένα.
Αυθεντικοποίηση
Εξουσιοδότηση
Τι εννοούμε και από τους δύο αυτούς όρους;
Για να το καταλάβουμε, ας πάρουμε τα πράγματα σε προοπτική από το Διάγραμμα ETL.
Σύμφωνα με το παραπάνω διάγραμμα, παίρνουμε τα δεδομένα μας από Source RDBMS Engines και από Flat Files σε HDFS, και αυτή η φάση ονομάζεται Εξαγωγή.
Ας συζητήσουμε για τον έλεγχο ταυτότητας με συγκεκριμένο τρόπο, υπάρχουν ορισμένες επιχειρήσεις που διαθέτουν Δεδομένα που περιορίζονται από τη φύση τους, αυτός ο τύπος Δεδομένων ονομάζεται Δεδομένα PII σύμφωνα με τα πρότυπα των Ηνωμένων Πολιτειών.
PII σημαίνει Προσωπικά αναγνωρίσιμα στοιχεία, οποιεσδήποτε πληροφορίες όπως η ημερομηνία γέννησης, SSN, αριθμός κινητού τηλεφώνου, διεύθυνση ηλεκτρονικού ταχυδρομείου και διεύθυνση σπιτιού κ.λπ. εμπίπτουν στο PII. Αυτό είναι περιορισμένο και δεν μπορεί να κοινοποιηθεί σε όλους.
Τα Δεδομένα θα πρέπει να κοινοποιούνται μόνο στα άτομα που τα χρειάζονται περισσότερο και σε εκείνα που χρειάζονται τα Δεδομένα για πραγματική επεξεργασία. Έχοντας αυτόν τον έλεγχο και την πρώτη γραμμή άμυνας, ονομάζεται Authentication.
Για παράδειγμα, χρησιμοποιούμε φορητό υπολογιστή και έχουμε εγκατεστημένα τα Windows εκεί, ενδέχεται να δημιουργήσαμε κάποιο λογαριασμό χρήστη στο λειτουργικό μας σύστημα Windows και εκεί εφαρμόσαμε έναν κωδικό πρόσβασης.
Με αυτόν τον τρόπο μόνο το άτομο που διαθέτει τα διαπιστευτήρια για αυτόν τον συγκεκριμένο λογαριασμό χρήστη μπορεί να συνδεθεί στο σύστημα και έτσι θα προστατεύσουμε τα δεδομένα μας από κλοπή ή περιττή πρόσβαση. Το άλλο επίπεδο είναι Εξουσιοδότηση.
Παράδειγμα, Έχουμε δύο διαφορετικούς λογαριασμούς χρηστών στο λειτουργικό μας σύστημα Windows, ένας λογαριασμός χρήστη είναι δικός μας και ένας άλλος μπορεί να είναι ο λογαριασμός χρήστη επισκέπτη. Ο διαχειριστής (WE) έχει το δικαίωμα να κάνει κάθε είδους λειτουργίες, όπως εγκατάσταση και απεγκατάσταση του λογισμικού, Δημιουργία νέου αρχείου και Διαγραφή υπαρχόντων αρχείων κ.λπ.
Ενώ από την άλλη πλευρά, οι επισκέπτες επισκέπτη ενδέχεται να μην έχουν όλα αυτά τα είδη πρόσβασης. Ο επισκέπτης έχει έλεγχο ταυτότητας για σύνδεση στο σύστημα, αλλά δεν έχει την εξουσία να διαγράψει ή να δημιουργήσει τα αρχεία και την εγκατάσταση, καθώς και την απεγκατάσταση οποιουδήποτε λογισμικού στο σύστημα και από το σύστημα αντίστοιχα.
Ωστόσο, ο λογαριασμός χρήστη επισκέπτη λόγω του ελέγχου ταυτότητας έχει το δικαίωμα να διαβάσει τα αρχεία που έχουν δημιουργηθεί και να χρησιμοποιήσει το λογισμικό που είναι ήδη εγκατεστημένο.
Έτσι δοκιμάζεται ο έλεγχος ταυτότητας και η εξουσιοδότηση, σε αυτήν την περίπτωση, όποια δεδομένα είναι διαθέσιμα σε HDFS ή σε οποιοδήποτε από τα συστήματα αρχείων που πρέπει να ελέγξουμε για τον έλεγχο ταυτότητας και την εξουσιοδότηση δεδομένων.
Προσέγγιση δοκιμής για δοκιμή Hadoop / Δοκιμή BigData
Η προσέγγιση δοκιμών είναι κοινή για όλα τα είδη δοκιμών, όχι μόνο επειδή είναι δοκιμή BigData ή Hadoop όταν πηγαίνουμε στο Normal Manual Testing ή Automation Testing ή Security Testing, Performance Testing επίσης, επομένως κάθε είδος δοκιμής ακολουθεί την ίδια προσέγγιση.
Απαιτήσεις
Ως μέρος της προσέγγισης δοκιμών, πρέπει να ξεκινήσουμε με το Απαιτήσεις , Η απαίτηση είναι ένα βασικό πράγμα, στις μέρες μας η ευέλικτη διαδικασία το ονομάσαμε Ιστορίες και Έπη. Το Epic δεν είναι παρά μια μεγαλύτερη απαίτηση, ενώ οι Ιστορίες είναι μικρότερες απαιτήσεις.
Η απαίτηση περιέχει βασικά ποια είναι όλα τα μοντέλα δεδομένων, οι στόχοι, οι πηγές καθώς και τι είδους μετασχηματισμοί πρέπει να εφαρμόσουμε, τι είδους εργαλεία πρέπει να χρησιμοποιήσουμε; Όλα αυτά τα είδη λεπτομερειών θα είναι διαθέσιμα στις Απαιτήσεις.
Αυτή είναι βασικά η απαίτηση πελάτη ή οι απαιτήσεις πελατών. Με βάση αυτήν την απαίτηση θα ξεκινήσουμε τη διαδικασία δοκιμής μας.
Εκτίμηση
Ένα άλλο μέρος μιας προσέγγισης είναι Εκτίμηση , Πόσος χρόνος χρειάζεται για να γίνει ολόκληρη η δραστηριότητα ως μέρος της δοκιμής. Κάνουμε δοκιμαστικό σχεδιασμό, προετοιμάζοντας τα σενάρια δοκιμής, προετοιμασία δοκιμαστικών περιπτώσεων και εκτέλεσης των ίδιων καθώς και θα εντοπίσουμε ελαττώματα και θα τα αναφέρουμε και θα προετοιμάσουμε επίσης δοκιμαστικές εκθέσεις.
Όλες αυτές οι δραστηριότητες θα διαρκέσουν λίγο χρόνο, οπότε πόσος χρόνος χρειαζόμαστε για την ολοκλήρωση όλων αυτών των δραστηριοτήτων και αυτό βασικά ονομάζεται Εκτίμηση. Πρέπει να δώσουμε κάποια πρόχειρη εκτίμηση στη διοίκηση.
Σχεδιασμός δοκιμών
Σχεδιασμός δοκιμών δεν είναι τίποτα άλλο από την περιγραφή σχετικά με τις διαδικασίες, τι πρέπει να δοκιμάσετε, τι όχι να δοκιμάσετε, ποιο είναι το εύρος των δοκιμών, ποια είναι τα χρονοδιαγράμματα, πόσους πόρους απαιτούνται, απαιτήσεις υλικού και λογισμικού και ποια είναι τα χρονοδιαγράμματα καθώς και οι κύκλοι δοκιμών θα χρησιμοποιηθεί, ποια είναι τα επίπεδα δοκιμών που χρειαζόμαστε κ.λπ.
Κατά τη διάρκεια του Προγραμματισμού Δοκιμών, θα κάνουν συγκεκριμένη κατανομή πόρων στο Έργο και ποια είναι τα διαφορετικά μοντέλα που έχουμε, πόσους πόρους απαιτούνται και τι είδους Σετ δεξιοτήτων απαιτούνται, κ.λπ. όλα αυτά τα πράγματα και οι πτυχές θα συμπεριληφθούν στη Δοκιμή Φάση προγραμματισμού.
Τις περισσότερες φορές το επίπεδο προπορευόμενου ή το επίπεδο διαχείρισης θα κάνουν τον προγραμματισμό δοκιμών.
Σενάρια δοκιμής και περιπτώσεις δοκιμής
Μόλις τελειώσουμε με τον προγραμματισμό δοκιμών, πρέπει να προετοιμαστούμε Σενάρια δοκιμής και περιπτώσεις δοκιμής , ειδικά για το Big Data Testing, απαιτούμε μερικά έγγραφα μαζί με το απαιτούμενο έγγραφο. Μαζί με αυτό το έγγραφο απαίτησης, τι χρειαζόμαστε;
Χρειαζόμαστε το Έγγραφο Απαίτησης που περιέχει τις ανάγκες του Πελάτη, μαζί με αυτό χρειαζόμαστε Έγγραφο εισαγωγής δηλ. Μοντέλα δεδομένων. Μοντέλο δεδομένων με την έννοια τι είναι τα σχήματα βάσεων δεδομένων, ποιοι είναι οι πίνακες και ποιες είναι οι σχέσεις όλων αυτών των δεδομένων θα είναι διαθέσιμα στα μοντέλα δεδομένων.
Επίσης, έχουμε το Χαρτογράφηση εγγράφων , Χαρτογράφηση εγγράφων για Π.χ. Στις σχεσιακές βάσεις δεδομένων έχουμε μερικούς πίνακες και μετά τη φόρτωση των δεδομένων μέσω ETL στην αποθήκη δεδομένων σε HDFS, τι χαρτογράφηση πρέπει να κάνουμε; δηλ. Χαρτογράφηση τύπου δεδομένων.
δημιουργώντας ένα δέντρο δυαδικής αναζήτησης στην Ιάβα
Για παράδειγμα, αν έχουμε έναν πίνακα πελάτη σε HDFS, τότε σε HDFS έχουμε έναν πίνακα CUSTOMER_TARGET ή ο ίδιος πίνακας μπορεί να είναι και στο HIVE.
Σε αυτόν τον πίνακα πελατών, έχουμε συγκεκριμένες στήλες και στον πίνακα στόχου πελατών, έχουμε συγκεκριμένες στήλες όπως φαίνεται στο διάγραμμα. Απορρίψαμε τα Δεδομένα από τον Πίνακα Πελατών στον Πίνακα ΣΤΟΧΩΝ ΠΕΛΑΤΩΝ, δηλαδή Πηγή ως στόχο.
Στη συνέχεια, πρέπει να ελέγξουμε την ακριβή αντιστοίχιση, όπως τα Δεδομένα που υπάρχουν στον Πίνακα Πηγή που είναι η Στήλη 1 και η Σειρά 1 του Πίνακα Πελατών και το θεωρούν ως C1R1 και τα ίδια Δεδομένα πρέπει να αντιστοιχιστούν στο C1R1 του Πίνακα ΣΤΟΧΟΥ ΠΕΛΑΤΗ Αυτό βασικά ονομάζεται χαρτογράφηση.
Πώς θα ξέρουμε, ποιες είναι όλες οι αντιστοιχίσεις που πρέπει να επαληθεύσουμε; Έτσι αυτές οι αντιστοιχίσεις θα είναι παρούσες στο έγγραφο χαρτογράφησης. Στο έγγραφο χαρτογράφησης, ο πελάτης θα δώσει κάθε είδους αντιστοιχίσεις.
Επίσης, απαιτήσαμε ένα Έγγραφο σχεδίασης , Απαιτείται Έγγραφο Σχεδιασμού τόσο για την Ομάδα Ανάπτυξης όσο και για την Ομάδα QA, διότι στο Έγγραφο Σχεδιασμού θα παρέχει ο Πελάτης, τι είδους Εργασίες Μείωσης Χάρτη θα εφαρμόσει και τι είδους Εργασίες MapReduce παίρνει Εισόδους και τι είδους MapReduce Το Jobs δίνει αποτελέσματα.
Ομοίως, εάν έχουμε HIVE ή PIG, ποια είναι όλα τα UDF που έχει δημιουργήσει ο Πελάτης, καθώς και ποια είναι όλα τα δεδομένα που θα λάβει και τι είδους παραγωγή θα παράγει κ.λπ.
Για να προετοιμάσουμε τα σενάρια δοκιμής και τις δοκιμαστικές περιπτώσεις, πρέπει να έχουμε όλα αυτά τα έγγραφα με το χέρι:
- Έγγραφο Απαίτησης
- Μοντέλο δεδομένων
- Χαρτογράφηση εγγράφου
- Έγγραφο σχεδίασης
Αυτά μπορεί να διαφέρουν από έναν οργανισμό σε έναν άλλο οργανισμό και δεν υπάρχει υποχρεωτικός κανόνας ότι πρέπει να έχουμε όλα αυτά τα έγγραφα. Μερικές φορές έχουμε όλα τα έγγραφα και μερικές φορές έχουμε μόνο δύο ή τρία έγγραφα ή μερικές φορές πρέπει να βασιστούμε σε ένα έγγραφο επίσης, που εξαρτάται από την πολυπλοκότητα του έργου, τα εταιρικά προγράμματα και τα πάντα.
Κριτικές για τα σενάρια δοκιμής και τις περιπτώσεις δοκιμής
Πρέπει να πραγματοποιήσουμε μια επισκόπηση για τα σενάρια δοκιμής και τις δοκιμαστικές περιπτώσεις, διότι κάπως ή σε ορισμένες περιπτώσεις ξεχνάμε ή χάνουμε κάποιες δοκιμαστικές περιπτώσεις, επειδή όλοι δεν μπορούν να σκεφτούν όλα τα πιθανά πράγματα που μπορούν να γίνουν με τις απαιτήσεις, σε τέτοιες συνθήκες πρέπει να λάβουμε βοήθεια από εργαλεία τρίτων ή από κάποιον άλλο.
Έτσι, όποτε ετοιμάζουμε κάποια έγγραφα ή εκτελούμε κάτι, τότε χρειαζόμαστε κάποιον να ελέγχει τα πράγματα από την ίδια ομάδα, όπως προγραμματιστές, δοκιμαστές. Θα δώσουν κατάλληλες προτάσεις για να συμπεριλάβουν κάτι περισσότερο ή επίσης θα προτείνουν ενημέρωση ή τροποποίηση των σεναρίων δοκιμής και των περιπτώσεων δοκιμής.
Παρέχουν όλα τα σχόλια και βάσει αυτού θα ενημερώσουμε τα σενάρια δοκιμής και τις περιπτώσεις δοκιμών και πολλές εκδόσεις του εγγράφου που πρέπει να κυκλοφορήσουμε σε όλη την ομάδα έως ότου το έγγραφο ενημερωθεί πλήρως σύμφωνα με την απαίτηση.
Εκτέλεση δοκιμής
Μόλις το έγγραφο είναι έτοιμο, θα λάβουμε την εγγραφή από την ανώτερη ομάδα για να ξεκινήσουμε τη διαδικασία εκτέλεσης που βασικά ονομάζεται Test Case Execution.
Εάν θέλουμε να εκτελέσουμε τις δοκιμαστικές υποθέσεις μας κατά την εκτέλεση, πρέπει να ελέγξουμε ότι ο προγραμματιστής πρέπει να στείλει τις πληροφορίες, εάν είναι φυσιολογικός έλεγχος λειτουργίας ή κάποια άλλη δοκιμή ή δοκιμή αυτοματισμού, απαιτείται έκδοση. Όμως, από την άποψη των δοκιμών Hadoop ή BigData, ο προγραμματιστής θα παρέχει εργασίες MapReduce.
HDFS Files - όποια αρχεία αντιγράφονται σε HDFS αυτά τα αρχεία απαιτούνται πληροφορίες για τον έλεγχο των προνομίων, HIVE Scripts που δημιουργήθηκαν από τους Προγραμματιστές για την επαλήθευση των Δεδομένων στον Πίνακα HIVE και επίσης χρειαζόμαστε τα HIVE UDF's που αναπτύχθηκαν από τους Developers, PIG Σενάρια και PIG UDF's.
Αυτά είναι όλα όσα πρέπει να πάρουμε από τους προγραμματιστές. Πριν πάμε για την εκτέλεση θα πρέπει να έχουμε όλα αυτά τα πράγματα.
Για το MapReduce Jobs, θα παρέχουν ορισμένα αρχεία JAR και ως μέρος του HDFS έχουν ήδη φορτώσει τα δεδομένα σε HDFS και τα αρχεία πρέπει να είναι έτοιμα και δέσμες ενεργειών HIVE για την επικύρωση των δεδομένων στους πίνακες HIVE. Όποια και αν είναι τα UDF που έχουν εφαρμοστεί θα είναι διαθέσιμα στο HIVE UDF's. Χρειαζόμαστε το ίδιο πράγμα για PIG Scripts και UDF's επίσης.
Αναφορά και παρακολούθηση ελαττωμάτων
Μόλις εκτελέσουμε τις δοκιμαστικές μας περιπτώσεις, εντοπίζουμε κάποια ελαττώματα, κάποια αναμενόμενα και κάποια πραγματικά δεν είναι ίσα με τα αναμενόμενα αποτελέσματα, οπότε πρέπει να παραθέσουμε τα ίδια και να τα προσφέρουμε στην ομάδα ανάπτυξης για επίλυση, και αυτό βασικά ονομάζεται Αναφορά ελαττωμάτων.
Ας υποθέσουμε ότι αν βρούμε κάποιο ελάττωμα στην εργασία MapReduce, τότε θα το αναφέρουμε στον προγραμματιστή και θα ξαναδημιουργήσουν ξανά την εργασία MapReduce και θα κάνουν κάποιες τροποποιήσεις σε επίπεδο κώδικα και, στη συνέχεια, θα παρέχουν την τελευταία εργασία MapReduce, την οποία πρέπει να δοκιμάσουμε .
Αυτή είναι μια συνεχής διαδικασία, αφού η εργασία δοκιμαστεί και περάσει, πρέπει και πάλι να τη δοκιμάσουμε ξανά και να την αναφέρουμε στον προγραμματιστή και στη συνέχεια να λάβουμε την επόμενη για δοκιμή. Με αυτόν τον τρόπο επιτυγχάνεται η δραστηριότητα αναφοράς και παρακολούθησης ελαττωμάτων.
Αναφορές δοκιμών
Μόλις ολοκληρώσουμε τη διαδικασία δοκιμής και τα ελαττώματα έχουν κλείσει τότε πρέπει να δημιουργήσουμε τις δοκιμαστικές αναφορές μας. Οι δοκιμαστικές εκθέσεις είναι ό, τι έχουμε κάνει για να ολοκληρώσουμε τη διαδικασία δοκιμών μέχρι στιγμής. Όλος ο σχεδιασμός, οι δοκιμαστικές υποθέσεις και οι εκτελέσεις, τι αποτέλεσμα έχουμε, κ.λπ. όλα τεκμηριώνονται μαζί με τη μορφή Δοκιμαστικών Αναφορών.
Πρέπει να στέλνουμε αυτές τις αναφορές σε καθημερινή ή εβδομαδιαία βάση ή σύμφωνα με τις ανάγκες του Πελάτη. Σήμερα οι οργανισμοί χρησιμοποιούν το μοντέλο AGILE, οπότε κάθε Αναφορά κατάστασης πρέπει να ενημερώνεται κατά τη διάρκεια των Καθημερινών Scrums.
συμπέρασμα
Σε αυτό το σεμινάριο, περάσαμε:
- Η στρατηγική ή το σχέδιο δοκιμής των BigData.
- Απαιτούμενο περιβάλλον για δοκιμές BigData.
- Επικύρωση και επαλήθευση BigData.
- Εργαλεία που χρησιμοποιούνται για τη δοκιμή των BigData.
Μάθαμε επίσης για -
- Πώς λειτουργεί η στρατηγική δοκιμών, η ανάπτυξη δοκιμών, οι εκτελέσεις δοκιμών, η διαχείριση ελαττωμάτων και η παράδοση στους ρόλους και τις ευθύνες ως μέρος της δοκιμής Hadoop.
- Προσέγγιση δοκιμής για δοκιμές Hadoop / BigData που περιλαμβάνει Συγκέντρωση απαιτήσεων, Εκτίμηση, Σχεδιασμός δοκιμών, Δημιουργία σεναρίων δοκιμών & Περιπτώσεων δοκιμής μαζί με τις κριτικές.
- Γνωρίσαμε επίσης σχετικά με την εκτέλεση δοκιμών, την αναφορά ελαττωμάτων και την παρακολούθηση και την αναφορά δοκιμών.
Ελπίζουμε ότι αυτό το σεμινάριο δοκιμών BigData θα σας βοηθήσει!
=> Δείτε όλα τα εκπαιδευτικά BigData εδώ.
Συνιστώμενη ανάγνωση
- Εκπαιδευτικός έλεγχος έντασης: Παραδείγματα και εργαλεία ελέγχου έντασης
- Πώς να εκτελέσετε δοκιμές βάσει δεδομένων στο SoapUI Pro - SoapUI Tutorial # 14
- Εκμάθηση δοκιμών αποθήκης δεδομένων με παραδείγματα | Οδηγός δοκιμών ETL
- Testing Primer eBook Λήψη
- Εγχειρίδιο δοκιμών αποθήκης δεδομένων δοκιμών ETL (ένας πλήρης οδηγός)
- Τι είναι το Hadoop; Tutorial Apache Hadoop για αρχάριους
- Εγχειρίδιο καταστροφικών δοκιμών και μη καταστροφικών δοκιμών
- Λειτουργική δοκιμή εναντίον μη λειτουργική δοκιμή