Ένας πλήρης μη λειτουργικός οδηγός δοκιμών για αρχάριους

complete non functional testing guide

Ένας πλήρης οδηγός για μη λειτουργικές δοκιμές: Σκοπός, τύποι, εργαλείο, δοκιμαστικές θήκες με παραδείγματα

Τι είναι η μη λειτουργική δοκιμή;

Η μη λειτουργική δοκιμή πραγματοποιείται για την επαλήθευση της μη λειτουργικής απαίτησης της εφαρμογής, όπως Απόδοση, Χρησιμότητα, κ.λπ.

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

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

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

Οι δοκιμές ταξινομούνται γενικά σε δύο τύπους:

• Λειτουργική δοκιμή
• Μη λειτουργικές δοκιμές

Τι θα μάθετε:

• Σημασια
• Σκοπός
• Παράδειγμα
• Πλεονεκτήματα
• Πώς να καταγράψετε μη λειτουργικές απαιτήσεις;
  • # 1) Ιστορίες χρηστών / τεχνικών
  • # 2) Κριτήρια αποδοχής
  • # 3) Σε αντικείμενα
• Διαφορά στις λειτουργικές και μη λειτουργικές απαιτήσεις
• Είναι αυτό το μαύρο κουτί ή λευκό κουτί;
• Λίστα ελέγχου μη λειτουργικών περιπτώσεων δοκιμής
  • Λίστα ελέγχου για δοκιμές απόδοσης
  • Λίστα ελέγχου για έλεγχο ασφαλείας
  • Λίστα ελέγχου για δοκιμές τεκμηρίωσης
• Έγγραφο προσέγγισης
  • Πεδίο δοκιμής
  • Μετρήσεις δοκιμής
  • Εργαλεία δοκιμής
  • Βασικές Ημερομηνίες και Παραδοτέα
• Μη λειτουργικοί τύποι δοκιμών
• Μη λειτουργικά εργαλεία δοκιμής
  • # 1) Δοκιμές δοκιμής ευχρηστίας
  • # 2) Δοκιμές δοκιμής απόδοσης
  • # 3) Θήκες δοκιμής δοκιμής ασφαλείας
• συμπέρασμα
• Συνιστώμενη ανάγνωση

Σημασια

Αυτή η δοκιμή έχασε τη δέουσα προσοχή, δεδομένου ότι δεν επηρεάζει τη λειτουργικότητα του συστήματος.

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

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

Όπως απεικονίζει το ίδιο το όνομα, αυτή η δοκιμή επικεντρώνεται στη μη λειτουργική πτυχή της εφαρμογής. Ποιες είναι λοιπόν οι μη λειτουργικές πτυχές; Ή πρέπει να πω ποιες είναι οι δυνατότητες που δεν σχετίζονται με τη λειτουργικότητα της εφαρμογής;

Λοιπόν, εδώ είναι οι απαντήσεις σε αυτές:

• Πώς λειτουργεί η εφαρμογή υπό κανονικές συνθήκες;
• Πώς συμπεριφέρεται η εφαρμογή όταν συνδέονται ταυτόχρονα πάρα πολλοί χρήστες;
• Μπορεί η εφαρμογή να χειριστεί το άγχος;
• Πόσο ασφαλής είναι η εφαρμογή;
• Μπορεί η εφαρμογή να ανακάμψει από οποιαδήποτε καταστροφή;
• Μπορεί η εφαρμογή να συμπεριφέρεται με τον ίδιο τρόπο σε διαφορετικό περιβάλλον ή λειτουργικό σύστημα;
• Πόσο εύκολο είναι να μεταφέρετε την εφαρμογή σε διαφορετικό σύστημα;
• Τα έγγραφα / εγχειρίδιο χρήστη που παρέχονται με την εφαρμογή είναι εύκολα κατανοητά;

Η λίστα συνεχίζεται. Αλλά το σημείο εδώ είναι ότι - δεν συμβάλλονται αυτά τα χαρακτηριστικά στην ποιότητα της εφαρμογής; Η απάντηση είναι ναι. Αυτά τα χαρακτηριστικά είναι εξίσου σημαντικά.

Φανταστείτε ότι μια εφαρμογή πληροί όλες τις απαιτήσεις των χρηστών τέλεια, αλλά ορισμένοι μη εξουσιοδοτημένοι χρήστες πηγαίνουν εύκολα και καταστρέφουν τα δεδομένα που εισήγαγε ο χρήστης στην εφαρμογή, ή η εφαρμογή πεθαίνει όταν φορτώνονται περισσότερα από 5BB οποιουδήποτε αρχείου. Θα λέγατε λοιπόν ότι η εφαρμογή είναι καλής ποιότητας; Προφανώς όχι σωστά !!

Σκοπός

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

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

Παράδειγμα

Αυτός είναι ένας σημαντικός τύπος δοκιμών.

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

Για να κατανοήσουμε τη σημασία του, ας πάρουμε ένα απλό παράδειγμα:

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

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

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

Πλεονεκτήματα

Παρατίθενται παρακάτω μερικά από τα πλεονεκτήματα μιας μη λειτουργικής δοκιμής:

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

Πώς να καταγράψετε μη λειτουργικές απαιτήσεις;

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

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

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

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

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

Παράδειγμα:

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

Επίσης, μπορεί να ελεγχθεί ως πότε (ας πούμε 100) ότι οι χρήστες συνδέονται ταυτόχρονα, πόσος χρόνος χρειάζεται για να συνδεθεί ο χρήστης στο Facebook.

Αυτό διασφαλίζει ότι το σύστημα μπορεί να χειριστεί φορτίο και κίνηση που με τη σειρά του έχει καλή εμπειρία χρήστη.

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

Μια μη λειτουργική απαίτηση πρέπει να καταγράφεται ως:

• Χρήστες / Τεχνικές ιστορίες
• Στα κριτήρια αποδοχής
• Στο Τεχνούργημα

9

# 1) Ιστορίες χρηστών / τεχνικών

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

# 2) Κριτήρια αποδοχής

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

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

# 3) Σε αντικείμενα

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

Διαφορά στις λειτουργικές και μη λειτουργικές απαιτήσεις

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

Περαιτέρω ανάγνωση => Διαφορές μεταξύ λειτουργικών και μη λειτουργικών δοκιμών

Είναι αυτό το μαύρο κουτί ή λευκό κουτί;

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

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

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

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

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

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

Λίστα ελέγχου για δοκιμές απόδοσης

• Ο χρόνος απόκρισης της εφαρμογής θα πρέπει να επαληθευτεί, δηλαδή πόσο καιρό χρειάζεται για τη φόρτωση της εφαρμογής, κάθε είσοδος που δίνεται στην εφαρμογή παρέχει την έξοδο σε πόση ώρα, ανανεώνει το πρόγραμμα περιήγησης κ.λπ.
• Διακίνηση θα πρέπει να επαληθευτεί για τον αριθμό των συναλλαγών που ολοκληρώθηκαν κατά τη διάρκεια δοκιμής φόρτωσης.
• περιβάλλον Η εγκατάσταση θα πρέπει να είναι ίδια με το ζωντανό περιβάλλον, διαφορετικά τα αποτελέσματα δεν θα είναι τα ίδια.
• Χρόνος διεργασίας - Επεξεργαστείτε δραστηριότητες όπως εισαγωγή και εξαγωγή excel, τυχόν υπολογισμοί στην εφαρμογή θα πρέπει να δοκιμαστούν.
• Διαλειτουργικότητα θα πρέπει να επαληθευτεί, δηλαδή ένα λογισμικό θα πρέπει να μπορεί να λειτουργεί μεταξύ των άλλων λογισμικών ή συστημάτων.
• ETL ο χρόνος πρέπει να επαληθευτεί, δηλαδή ο χρόνος που απαιτείται για την εξαγωγή, τη μετατροπή και τη φόρτωση των δεδομένων από τη μία βάση δεδομένων στην άλλη.
• Αύξηση φορτίου σχετικά με την αίτηση πρέπει να επαληθευτεί.

Λίστα ελέγχου για έλεγχο ασφαλείας

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

Λίστα ελέγχου για δοκιμές τεκμηρίωσης

• Τεκμηρίωση χρήστη και συστήματος.
• Έγγραφα για εκπαιδευτικούς σκοπούς.

Έγγραφο προσέγγισης

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

https www google comyoutube σε mp3

• Πεδίο δοκιμής
• Μετρήσεις δοκιμής
• Εργαλεία δοκιμής
• Βασικές Ημερομηνίες και Παραδοτέα

Πεδίο δοκιμής

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

Μετρήσεις δοκιμής

Η προσέγγιση δοκιμής βελτιώνει τις μετρήσεις για μέτρηση και αναφορά κατά τη διάρκεια της δοκιμής, όπως:

• Χρόνος απόκρισης (online)
• Παράθυρο παρτίδας (παρτίδα)
• Διακίνηση ( Για παράδειγμα , ο αριθμός των συναλλαγών ανά μονάδα χρόνου)
• Χρήση ( Για παράδειγμα , το ποσοστό των χρησιμοποιούμενων πόρων)

Εργαλεία δοκιμής

Κυρίως ο Έλεγχος απόδοσης απαιτεί τη χρήση κατάλληλων εργαλείων:

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

Βασικές Ημερομηνίες και Παραδοτέα

Το έγγραφο προσέγγισης δοκιμής απόδοσης θα πρέπει να περιγράφει τα ακόλουθα:

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

Μη λειτουργικοί τύποι δοκιμών

Η παρακάτω εικόνα απεικονίζει τους τύπους μη λειτουργικών δοκιμών:

Δοκιμή απόδοσης:

Αξιολογεί τη συνολική απόδοση του συστήματος .

Τα βασικά στοιχεία είναι τα εξής:

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

Δοκιμή φορτίου:

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

Τα βασικά σημεία είναι:

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

Δοκιμή στρες:

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

Τα βασικά σημεία είναι:

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

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

Δοκιμή όγκου:

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

Τα βασικά σημεία είναι:

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

Δοκιμή χρηστικότητας:

Αξιολογεί το σύστημα για ανθρώπινη χρήση ή ελέγχει εάν είναι κατάλληλο για χρήση.

Τα βασικά σημεία είναι:

• Είναι η παραγωγή σωστή και ουσιαστική και είναι η ίδια με την αναμενόμενη σύμφωνα με την επιχείρηση;
• Διαγνώστηκαν σωστά τα σφάλματα;
• Είναι το GUI σωστό και συμβατό με το πρότυπο;
• Είναι η εφαρμογή εύχρηστη;

Δοκιμή διεπαφής χρήστη:

Αξιολογεί το GUI.

Τα βασικά σημεία είναι:

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

Δοκιμή συμβατότητας:

Αξιολογεί ότι η εφαρμογή είναι συμβατή με άλλο υλικό / λογισμικό με ελάχιστη και μέγιστη διαμόρφωση.

Τα βασικά σημεία είναι:

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

Δοκιμή ανάκτησης:

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

Οι δοκιμές δεν περιορίζονται στα παρακάτω σημεία:

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

Δοκιμή αστάθειας:

Αξιολογεί και επιβεβαιώνει εάν το λογισμικό εγκαθίσταται και απεγκαθίσταται σωστά.

πώς να βρείτε την προεπιλεγμένη μάσκα υποδικτύου

Τα βασικά σημεία είναι:

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

Δοκιμή τεκμηρίωσης:

Αξιολογεί τα έγγραφα και άλλα εγχειρίδια χρήστη.

Τα βασικά σημεία περιλαμβάνουν:

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

Δοκιμή Failover:

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

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

Δοκιμή ασφαλείας:

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

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

Δοκιμή κλιμάκωσης:

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

Δοκιμή συμμόρφωσης:

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

Για Παράδειγμα , Οι έλεγχοι γίνονται για την επαλήθευση της διαδικασίας δημιουργίας δοκιμαστικών περιπτώσεων / σχεδίων δοκιμών και τοποθέτησής τους στην κοινόχρηστη τοποθεσία με το τυπικό όνομα που γίνεται ή όχι. Στο QC, κατά την ονομασία των δοκιμαστικών περιπτώσεων, ακολουθείται ή όχι το τυπικό όνομα της υπόθεσης. Η τεκμηρίωση είναι πλήρης και εγκεκριμένη ή όχι.

Αυτοί είναι οι λίγοι δείκτες που καλύπτονται κατά τον έλεγχο.

Δοκιμή αντοχής:

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

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

Δοκιμή εντοπισμού:

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

Δοκιμή διεθνοποίησης:

Δοκιμή διεθνοποίησης είναι επίσης γνωστό ως δοκιμή i18n.

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

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

Δοκιμή αξιοπιστίας:

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

Δοκιμή φορητότητας:

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

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

Δοκιμή βασικής γραμμής:

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

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

Δοκιμή αποτελεσματικότητας:

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

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

Δοκιμή αποκατάστασης καταστροφών:

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

Δοκιμή συντήρησης:

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

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

Μη λειτουργικά εργαλεία δοκιμής

Υπάρχουν πολλά διαθέσιμα εργαλεία στην αγορά για δοκιμές απόδοσης (Load & Stress).

Λίγα από αυτά αναφέρονται παρακάτω:

• JMeter
• Φορτωτής
• Φορτωτής
• Καταιγίδα
• Neoload
• Πρόβλεψη
• Η φόρτωση ολοκληρώθηκε
• Εργαλείο άγχους Webserver
• WebLoad Professional
• Loadtracer
• vPerformer

Πραγματοποιείται πάντοτε μη λειτουργικός έλεγχος χωρίς τεκμηρίωση και υποθέσεις δοκιμής; Γιατί;

«Μας διδάσκονται πάντα πώς να γράφουμε λειτουργικές δοκιμαστικές περιπτώσεις. Γιατί αυτό? Πραγματοποιείται «μη λειτουργική δοκιμή» χωρίς τεκμηρίωση (με άλλα λόγια, σε ad-hoc βάση) ή είναι μια ξεχωριστή διαδικασία που είναι πολύ πιο δύσκολο να κατανοηθεί; Πώς γράφονται περιπτώσεις δοκιμών για διαφορετικά είδη δοκιμών που συμβαίνουν σε μια εφαρμογή; '

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

Πώς δεν μπορούμε να δούμε και να εξασκηθούμε στη σύνταξη μη λειτουργικών περιπτώσεων δοκιμής;

Ας ξεκινήσουμε με όσα γνωρίζουμε και όπως πάντα ένα πρακτικό σενάριο.

Παράδειγμα: Ακολουθούν τα βήματα που πρέπει να εκτελεστούν σε μια εφαρμογή Online Banking για την εκτέλεση μεταφοράς. Ας το χρησιμοποιήσουμε ως δοκιμή μας για αναφορά.

1. Συνδεθείτε στον ιστότοπο.
2. Επιλέξτε τον τραπεζικό λογαριασμό.
3. Επιλέξτε τον δικαιούχο πληρωμής (αυτός ο δικαιούχος πληρωμής μπορεί να ανήκει στην ίδια τράπεζα ή σε διαφορετική - αυτό εξαρτάται από την επιλογή δεδομένων σας για να εκτελέσετε αυτό το βήμα. Σε κάθε περίπτωση, επιλέξτε έναν. Επίσης, θα υποθέσουμε ότι ο δικαιούχος έχει ήδη προστεθεί.) .
4. Εισαγάγετε το προς μεταφορά ποσό (θετική τιμή, εντός του ορίου, σωστή μορφή κ.λπ.).
5. Κάντε κλικ στο Μεταφορά και ελέγξτε εάν έχει ληφθεί επιβεβαίωση, το υπόλοιπο του λογαριασμού έχει ενημερωθεί και όλα αυτά.

Αυτή είναι η λειτουργική περίπτωση δοκιμής, σωστά;

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

Πώς θα γράψαμε τις δοκιμαστικές περιπτώσεις;

# 1) Δοκιμές δοκιμής ευχρηστίας

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

• Πόσο εύκολη είναι η εφαρμογή;
• Πόσο ικανοποιητική είναι η εμπειρία χρήσης του συστήματος;
• Αν όχι τόσο οικείο αμέσως, πόσο εύκολο είναι να το μάθεις;

Περισσότερες πληροφορίες είναι εδώ: Οδηγός δοκιμής ευχρηστίας

Πώς θα καθορίσει ένας χρήστης τις απαντήσεις στις παραπάνω ερωτήσεις στο πλαίσιο της δοκιμής χρηστικότητας;

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

# 2) Δοκιμές δοκιμής απόδοσης

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

Ρίξτε μια ματιά στο δικό μας Εκπαιδευτικά τεστ επιδόσεων να μάθω περισσότερα για αυτό.

Τώρα, εάν έπρεπε να δοκιμάσω την απόδοση της συναλλαγής μεταφορών, θα έχω 10, 20, 30, 100… 1000… κ.λπ. οι χρήστες εκτελούν τη λειτουργία μεταφοράς ταυτόχρονα ή σταδιακά, ανάλογα με το τι θέλω να στοχεύσω και να συλλέξω δεδομένα.

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

Τα ίδια ακριβώς βήματα με τη λειτουργική δοκιμή, σωστά;

# 3) Θήκες δοκιμής δοκιμής ασφαλείας

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

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

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

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

Ας ρίξουμε μια συγκριτική ματιά:

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

Η πραγματική διαφορά είναι ότι:

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

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

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

συμπέρασμα

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

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

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

Ελπίζουμε ότι αυτή η διαδικασία διερεύνησης σε αυτό το θέμα ήταν τόσο διασκεδαστική για εσάς όσο έχει παρουσιαστεί σε όλους σας. Θα θέλαμε πολύ να ακούσουμε τα σχόλιά σας και τις σκέψεις σας σχετικά με αυτό το θέμα.

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

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

• Λειτουργική δοκιμή εναντίον μη λειτουργική δοκιμή
• Δοκιμή άλφα και δοκιμή beta (Ένας πλήρης οδηγός)
• Οδηγός δοκιμών ασφάλειας εφαρμογών Ιστού
• Πλήρης οδηγός λειτουργικών δοκιμών με τους τύπους και το παράδειγμά του
• Πλήρης οδηγός δοκιμής επαλήθευσης έκδοσης (BVT Testing)
• Τα καλύτερα εργαλεία δοκιμής λογισμικού 2021 (QA Test Automation Tools)
• Οδηγός για αρχάριους για δοκιμές διείσδυσης εφαρμογών ιστού
• Φόρτωση πλήρους οδηγού δοκιμών για αρχάριους