TestRail - Μεμονωμένες ρυθμίσεις για το έργο

Εισαγωγή

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

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

Σχέδιο-αιτιολόγηση (τι θα εφαρμοστεί)

1. Γενικές απαιτήσεις

   1. Η υπόθεση θα πρέπει να μπορεί να περάσει από οποιονδήποτε

   2. Οι περιπτώσεις θα πρέπει να παραμείνουν σχετικές για όσο το δυνατόν περισσότερο

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

2. Διαχωρισμός σε TestCase και TestScenario

3. Γρήγορος σχηματισμός TestRun διαφόρων τύπων

   1. Καπνός

   2. Οπισθοχώρηση

   3. Δοκιμές κρούσεων κ.λπ.

4. Βελτιστοποίηση υποστήριξης υπόθεσης

   1. Απόρριψη "νεκρών" στιγμιότυπων οθόνης με σκληρό κώδικα και μετάβαση σε "κινητά δεδομένα"

απαιτήσεις

Θα χρειαστείτε πρόσβαση διαχειριστή για επεξεργασία πεδίων

Επιλογή τύπου έργου

Υπάρχουν τρεις τύποι έργων για να διαλέξετε:

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

Προσθήκη πεδίων για προβολή της λίστας των δοκιμαστικών περιπτώσεων

Ας προσθέσουμε ένα πεδίο για εμφάνιση δοκιμαστικών υποθέσεων προτεραιότητας:

Μπορείτε επίσης να προσθέσετε άλλα πεδία.

Ρύθμιση πεδίων και ετικετών μιας δοκιμαστικής περίπτωσης

Άνοιγμα του μενού ρυθμίσεων:

Χρειαζόμαστε αυτά τα πεδία:

Πεδίο "Σύνοψη" (κεφαλίδα δοκιμαστικής περίπτωσης)

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

Σενάριο δοκιμής:

Παράδειγμα: TestScenario - Κύρια περίπτωση χρήσης εφαρμογής για κινητά

δοκιμαστική θήκη:

Παράδειγμα: Κύρια οθόνη - Ενότητα εξουσιοδότησης - Καταχώρηση σύνδεσης

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

Προσθέστε ετικέτα "StartScreen" (η οθόνη από την οποία ξεκινά το TestScenario, επίσης πολλές περιπτώσεις δοκιμής μπορούν να αγγίξουν γειτονικές οθόνες)

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

Δημιουργήστε ένα νέο πεδίο:

Συμπληρώστε τα στοιχεία του νέου πεδίου:

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

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

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

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

Προσθέστε ετικέτα "Screen" (το όνομα της οθόνης που επηρεάζει το TestCase)

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

Παράδειγμα: home_screen, MapScreen, PayScreen, κ.λπ.

Πεδίο MovableData (σύνδεσμος σε βάση δεδομένων διακομιστή μεσολάβησης με μεταβλητά δεδομένα δοκιμής)

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

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

2. Τυπικά βήματα για την οθόνη δοκιμής

3. Ερωτήματα SQL

4. Σύνδεσμοι προς εξωτερικά δεδομένα και άλλα δεδομένα

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

Θα συσκευάσουμε όλα αυτά τα δεδομένα σε ένα εξωτερικό αρχείο, το οποίο θα είναι διαθέσιμο σε όλους στο έργο. Για παράδειγμα, μπορείτε να χρησιμοποιήσετε το Φύλλο Google ή το Excel και να ρυθμίσετε μια αναζήτηση μέσα στο αρχείο. Γιατί αυτοί οι συγκεκριμένοι πωλητές; Το γεγονός είναι ότι ξεκινάμε από το παράδειγμα ότι κάθε άτομο στην ομάδα θα πρέπει να μπορεί να ανοίξει και να περάσει το δοκιμαστικό χωρίς να χρειάζεται να εγκαταστήσει πρώτα κανένα εργαλείο.

Για Φύλλο Google Μπορούν να χρησιμοποιηθούν ερωτήματα SQL. Παράδειγμα:

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

Για Excel Μπορείτε να ρυθμίσετε βολικές μακροεντολές άμεσης αναζήτησης. (φιλτράρισμα) Παράδειγμα по ссылке.

Στην πραγματικότητα, η ιδέα δεν είναι νέα και περιγράφεται στο πρώτο βιβλίο του δοκιμαστή «Testing dot com». (συγγραφέας Savin Roman) Απλώς ενσωματώνουμε τις μεθόδους που προτείνει ο Roman Savin στο TestRail. Για να το κάνετε αυτό, δημιουργήστε ένα πεδίο με έναν σύνδεσμο προς το δημιουργημένο αρχείο:

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

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

Πεδίο «Περιγραφές» (περιγραφή ή ιδέα της δοκιμαστικής περίπτωσης, τυπικές οδηγίες)

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

Παράδειγμα: Όλα τα δεδομένα δοκιμής (πραγματικές διατάξεις, χρήση εργαλείων και άλλα δεδομένα) από αυτήν την περίπτωση δοκιμής επισημαίνονται με συνδέσμους {...} και βρίσκονται στο MovableData. Σύνδεση με το MovableData στο αντίστοιχο πεδίο στην κορυφή.

Ετικέτα "Στοιχείο" (στοιχείο εφαρμογής για κινητά)

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

Παράδειγμα στοιχείων: GooglePay, Παραγγελία, Χρήστες, Χάρτης, Εξουσιοδότηση κ.λπ.

Ετικέτα "TAG" (Άλλες ετικέτες για φιλτράρισμα)

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

Πολύ χρήσιμο για: 

1. γρήγορη σύνταξη του TestRun για διάφορες τυπικές εργασίες: καπνός, παλινδρόμηση κ.λπ.

2. εάν οι δοκιμές θα είναι αυτοματοποιημένες ή ήδη αυτοματοποιημένες

3. οποιεσδήποτε άλλες ετικέτες

Παράδειγμα: Smoke, Automated, WhiteLabel, ForDelete, κ.λπ.

Ρύθμιση της σειράς εμφάνισης των πεδίων στη δοκιμαστική περίπτωση

Έχουμε δημιουργήσει πολλά νέα πεδία, ήρθε η ώρα να τα κανονίσουμε με μια βολική σειρά:

Δημιουργία TestRun

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

Άλλες χρήσιμες συμβουλές

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

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

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

Συμπέρασμα

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

Βιβλιογραφικές αναφορές:

Ιστότοπος πωλητή TestRail

Βιβλίο: "Testing .COM" (συγγραφέας Roman Savin)

Σας ευχαριστώ πολύ για την προσοχή σας!

Πηγή: www.habr.com