Processus de test de projet
-
Après avoir obtenu le document des exigences, rédigez des cas de test
-
Examiner les cas de test
-
En attente du package de développement
-
Environnement de test de déploiement
-
Test de fumée (diagramme d'architecture de page Web)
-
Test d'initialisation de la page (vérifiez si le contenu des données dans la base de données et le contenu affiché sur la page sont cohérents et s'ils sont disposés dans un certain ordre)
7. Cas de test d'exécution spécifiques (presque tous les tests fonctionnels, méthodes de processus, méthodes de scénario)
-
Si vous trouvez un défaut, vous devez remplir le formulaire de défaut
-
Tests non fonctionnels (sql, injection js, efficacité de la page, contournement de la vérification js et ajout direct de données à la base de données)
-
Rédiger le rapport de test final
Méthode de conception de cas de test
Classe d'équivalence, valeur limite, méthode d'expérience orthogonale, méthode de transition d'état, diagramme de causalité, méthode de test de scénario, méthode d'analyse des anomalies, diagramme de causalité, méthode d'estimation des erreurs, table de jugement
Éléments du scénario de test
ID sujet nom du test date de création concepteur description nom de l'étape description de l'étape résultat attendu état d'exécution
Priorité des tests
-
Testez d'abord les pièces modifiées, puis testez les pièces inchangées
-
Testez d'abord les fonctions de base du programme, puis testez les fonctions générales
-
Testez d'abord les fonctions logiques, puis testez les fonctions métier
-
Testez d'abord la situation générale, puis testez la situation anormale
-
Testez d'abord la fonction, puis testez les performances
Ce qui est inclus dans le rapport de test
1. Écrivez l'arrière-plan du test
2. Objectifs du test
3. Plage de test
4. Environnement de test
5. Données de test
6. Normes d'essai (en italique)
7. Progression du test
8. Résultats des tests
9. Conclusion du test
Certaines entreprises utiliseront des rapports de test non standard
Incluez approximativement le temps passé dans le test, le nombre de bogues trouvés par les testeurs dans le test, le nombre de bogues corrigés, le nombre de bogues restants, les raisons des bogues restants, les résultats du test, etc.
Cycle de vie du BUG
Soumettre-Vérification du développement-Acceptation-Rejet-Solution de développement-Testeur Vérification-Fermeture-Échec Ouvrir
État du BUG
-
NOUVEAU: tous les problèmes soumis au statut d'ancrage de développement sont NOUVEAU, ce qui signifie qu'ils ne sont pas traités
-
OUVERT: La personne chargée du développement est initialement considérée comme un problème à transférer, et le testeur et le développeur sont désignés, et le statut est OUVERT.
-
REFUSE: Le docker de développement juge que le problème n'a pas besoin d'être transféré vers le lien suivant, le statut est REFUSE et la raison est renseignée
-
FIXED: le développeur a terminé la réparation et doit être testé, et l'état est FIXED
-
REOPEN: Le service de test a passé le résultat de la réparation du testeur au développeur, et le statut est REOPEN
-
CLOSE: Le testeur juge que le problème est une demande ou un autre problème, et doit en indiquer la raison;
Éléments défectueux
Titre du défaut Statut du défaut Expéditeur Personne responsable Priorité de la charge Gravité du défaut Description Heure Capture d'écran
Niveau de défaut
Problèmes fatals: les fonctions principales ne sont pas disponibles ou le système plante
Problème grave Le processus métier principal ne peut pas être utilisé et une fonction du processus métier principal présente un défaut qui empêche le processus principal de continuer à être utilisé
Problèmes généraux Problèmes généraux, pas de défauts fonctionnels dans le processus principal
Problèmes mineurs Les invites de problèmes d'interface utilisateur ne sont pas standardisées, etc.
Les questions suggérées posent des questions suggestives basées sur votre propre expérience
La différence entre le test WEB et le test APP
- L'architecture est différente.
Le côté Web est basé sur l'architecture b / s, et l'architecture b / s est accessible en fonction de l'adresse du navigateur
Le côté application est une architecture c / s, et l'architecture c / s nécessite un client en tant que transporteur
- La méthode et le processus de publication de la version sont différents.
La version Web est publiée, un nouveau code est développé et déployé à l'adresse de serveur correspondante, et la mise à jour côté Web peut être réalisée de manière uniforme
Version de l'application, le développement doit être packagé (package apk et package ipa), après emballage, il doit être publié sur le canal correspondant
- compatibilité
web, testez la compatibilité de différents navigateurs (ie, chrome, firefox, 360, QQ)
application, testez différentes résolutions, tailles d'écran, marques de téléphones mobiles et versions de système
- Aspect de la performance
web, temps de réponse du test
application, temps de réponse du test, trafic, consommation d'énergie, CPU, GPU, mémoire
- sécurité
web, injection SQL. attaque xss etc.
app, cryptage https, signature, renforcement, cryptage de mot de passe, etc.
6. Fonctionnalités de test d'application
Test d'aptitude
Test de réseau
Test de mise à niveau en ligne
Test d'interruption
Test de consommation d'énergie
Test de réseau faible
Test d'installation et de désinstallation
Test de débit
Le contenu principal des tests d'applications
- test de fonctionnalité
Tester l'exactitude de la logique métier
- Test de compatibilité
version du système
Résolution
Si un bogue est considéré par le développeur comme n'étant pas un bogue, comment le gérer
Commandes Linux courantes
Dans quelles circonstances ne peut pas localiser l'élément
La différence entre la requête GET et la requête POST
Situation du réseau
- Test anormal
Démarrage à chaud
Commutateur de réseau
Récupération du terminal d'information téléphonique
-
Mettre à niveau, installer, désinstaller
-
Test de robustesse
Consommation de ressources de téléphonie mobile
Consommation de données
Test de batterie
Récupération après incident
Si un bogue est considéré par le développeur comme n'étant pas un bogue, comment le gérer
-
Soumettez le problème à la base de données de gestion des défauts pour enregistrement.
-
Obtenir la base et les normes du jugement
Selon les spécifications des exigences, les descriptions de produits, les documents de conception, etc., confirment si les résultats réels sont incompatibles avec le plan et fournissent une base directe pour confirmer les défauts;
S'il n'y a pas de base documentaire, vous pouvez expliquer s'il y a une incohérence basée sur les caractéristiques générales d'un logiciel similaire pour confirmer s'il s'agit d'un défaut;
Selon les habitudes générales d'utilisation de l'utilisateur, pour confirmer s'il s'agit d'un défaut;
Discutez avec le personnel concerné tel que les concepteurs, les développeurs et les représentants des clients pour confirmer s'il s'agit d'un défaut;
-
Présentez un argument raisonnable, expliquez la raison de votre jugement au responsable du test et soyez objectif, rigoureux et non mêlé d'émotions personnelles.
-
Attendez que le responsable des tests prenne la décision finale. S'il y a toujours un différend, vous pouvez le signaler au supérieur via le canal prévu par la politique de l'entreprise, et le supérieur peut prendre une décision.
Commandes Linux courantes
-
ifconfig afficher l'adresse IP
-
cat est utilisé pour afficher tout le contenu du fichier spécifié
-
more affiche le contenu du fichier spécifié sous forme de pagination
-
mkdir create répertoire
-
touchez pour créer un nouveau fichier
-
grep trouve la chaîne qualifiée dans le fichier
-
find Trouver le fichier spécifié
-
tail -f est utilisé pour actualiser automatiquement le contenu des N lignes de données après le fichier d'affichage
-
kill -9 fin forcée
-
netstat -anp | grep port de vue du numéro de port
-
chmod -R 777 donne 777 permissions
Dans quelles circonstances ne peut pas localiser l'élément
-
Mauvais code
-
L'élément n'apparaît pas (besoin d'attendre l'élément)
-
Élément dans iframe
-
Multi fenêtre
-
Une fenêtre contextuelle apparaît (fenêtre contextuelle système, fenêtre contextuelle JS)
-
Les valeurs d'attribut d'élément sont chargées dynamiquement
-
L'élément ne peut pas être déterminé de manière unique
-
Attribut en lecture seule (l'élément n'est pas utilisable)
La différence entre la requête GET et la requête POST
-
GET utilise une URL ou des cookies pour passer des paramètres, POST met des données dans BODY
-
L'URL GET aura une limite de longueur, les données POST peuvent être très volumineuses
-
POST est plus sûr que GET car il n'est pas visible dans la barre d'adresse
-
Généralement, GET est utilisé pour obtenir des données, POST est utilisé pour envoyer des données
Pourquoi faire des tests d'interface
-
Plus le BUG est bas, plus le coût de réparation est bas
-
Lorsque le front-end change, l'interface back-end n'a pas besoin d'être modifiée
-
Vérifier la sécurité et la stabilité du système, la transmission frontale des paramètres n'est pas crédible
Comment se déroule le test d'interface
–Parce que les appels front-end et back-end de notre projet sont principalement basés sur l'interface du protocole http, le test de l'interface consiste principalement à simuler l'envoi et la réception de requêtes http via des outils ou des codes. Il existe de nombreux outils tels que postman, jmeter, soupUI, etc.
-Il peut également être réalisé par l'automatisation d'interface, qui est réalisée par code. Le cadre est similaire à l'automatisation de l'interface utilisateur. L'envoi des demandes est jugé par des assertions.
Points clés des tests d'interface
-
Vérifier si les données renvoyées par l'interface sont cohérentes avec le résultat attendu
-
Vérifiez la tolérance aux pannes de l'interface et si elle peut être gérée lorsque le type passé est incorrect
-
Valeur limite du test d'interface
-
Performances de l'interface
-
Sécurité de l'interface
code d'état http
-
1xx: La requête est normale, mais il n'y a pas de réponse, elle ne peut être utilisée qu'à l'état expérimental
-
2xx: le début de 2 indique que la transmission est réussie
-
3xx: 3 représente la redirection, commun 302
-
4xx: 400 signifie que la grammaire envoyée par le client est incorrecte, 401 signifie que la page consultée n'est pas autorisée, 403 n'a pas l'autorisation d'accéder à la page, 404 signifie qu'il n'y a pas de telle page et 415 est l'erreur de format
-
5xx: le début par 5 représente l'exception du serveur, 500 représente l'exception interne du serveur, 504 représente le délai d'expiration du serveur
La différence entre les cookies et la session
-
Les données des cookies sont stockées sur le navigateur du client, les données de session sont stockées sur le serveur
-
Les cookies ne sont pas très sécurisés. D'autres peuvent analyser les cookies stockés localement et effectuer l'usurpation des cookies. Pour des raisons de sécurité, vous devez utiliser session.
-
La session sera enregistrée sur le serveur pendant un certain temps. Lorsque le nombre de visites augmentera, elle sera plus occupée. Compte tenu des performances de votre serveur, vous devez utiliser des cookies pour réduire les performances du serveur.
Commandes adb couramment utilisées
-
service adb de démarrage du serveur de démarrage adb
-
adb kill-server fermer le service adb
-
appareils adb afficher le numéro de l'appareil
-
adb push ordinateur téléphone
-
ordinateur mobile adb pull
-
adb logcat | grep 包 名 （unix）
-
adb logcat | findstr S'inscrire (gagner)
-
adb shell entrez dans la ligne de commande du shell
-
adb install installe l'application sur le téléphone
-
adb désinstaller désinstaller l'application sur le téléphone
-
adb logcat> Journal de sortie du nom de fichier dans un fichier
-
commande de consommation des ressources de l'application de test adb shell top
Processus commercial produit
Analyse
Demandez le processus d'affaires global d'un projet écrit sur votre CV
Par exemple, la fonction d'enregistrement dans le projet de commerce électronique, l'ensemble du processus depuis le début de l'enregistrement jusqu'à l'enregistrement réussi
Quelle est la version qui répond aux normes en ligne
Critères d'acceptation
(1) Toutes les fonctions définies dans la spécification d'analyse des exigences logicielles ont été entièrement réalisées et tous les indicateurs de performance ont atteint les exigences.
(2) Les erreurs trouvées dans le test d'acceptation ont été corrigées et le taux de réparation des défauts à tous les niveaux a atteint la norme
(3) Tous les éléments de test n'ont aucune urgence résiduelle ou erreur de niveau grave.
(4) Le document d'analyse des exigences, le document de conception et le codage sont cohérents.
(5) Artefacts de test d'acceptation complets (plan de test, cas de test, journal de test, avis de test, rapport d'analyse de test, processus d'installation du logiciel à accepter
séquence. )
Norme de taux de réparation des défauts
(1) Le taux de réparation des erreurs d'urgence et de niveau sévère doit atteindre 100%;
(2) Le taux de réparation des erreurs de niveau ordinaire devrait atteindre 95% ou plus;
(3) Le taux de réparation des erreurs de niveau d'optimisation doit atteindre 60% ou plus;
Remarque: lorsque le projet est urgent, le taux de réparation d'erreur de niveau normal atteint plus de 60%; le taux de réparation d'erreur de niveau optimisé atteint 20%.
Indicateurs de réponse d'état de fonctionnement du serveur
(1) Le taux d'utilisation maximal de cpu% pendant la concurrence ne doit pas dépasser 70 à 80%. S'il y a une concurrence de rendez-vous, il peut être autorisé à approcher ou atteindre 100 & pendant une courte période, mais la plupart d'entre eux ne le sont pas.
95% devraient être vérifiés;
(2) Pendant le test de mémoire, assurez-vous que la mémoire est suffisante et que la mémoire disponible n'est pas inférieure à 20%;
(3) le disque surveille si le disque dur a lu et écrit pas plus de 40%;
(4) La charge moyenne du processeur ne doit pas dépasser le nombre de cœurs de processeur * 2 ou ne doit pas dépasser le nombre de cœurs de processeur.
Processus d'examen des cas de test et participants associés
1: Processus d'examen
R: Effectuez les préparatifs suivants avant de commencer
1. Déterminez la raison de l'examen
2. Déterminez le moment de l'examen
3. Identifiez les participants à l'examen
4. Clarifier le contenu de l'examen
5. Déterminez la fin des critères d'examen
6. Au moins un jour à l'avance, le contenu qui doit être examiné sera envoyé au personnel concerné de la réunion d'examen sous forme de courrier électronique. Et indiquez l'heure et le lieu de l'examen détaillé et le personnel impliqué dans la compensation.
7. Dans l'e-mail, rappelez au personnel concerné de la réunion de révision de lire le contenu de la révision au moins une fois et enregistrez les questions associées afin qu'elles puissent être soulevées lors de la réunion de révision.
8. L'hôte de la réunion (généralement un rédacteur de cas d'utilisation) doit trier les questions pertinentes avant la réunion afin qu'elles puissent être soulevées lors de la réunion.
B: Commencer l'examen
1. Tenez une réunion de révision. Les participants ont fait des commentaires et des suggestions après l'explication du concepteur, et ont en même temps réalisé un dossier d'examen détaillé.
2. Communiquez avec le personnel concerné par courrier général
3. Les outils de GI générale communiquent directement avec le personnel concerné
4. Révision en fonction du contenu de la révision
2: Juger le contenu
1. Si l'agencement structurel de la conception du cas d'utilisation est clair et raisonnable, et s'il est propice à une couverture efficace des exigences.
2. Si l'arrangement de priorité est raisonnable.
3. Que ce soit pour couvrir tous les points de fonction sur les exigences de test.
4. Si le cas d'utilisation est bien exécutable. Par exemple, si les conditions préalables, les étapes d'exécution, les données d'entrée et les résultats attendus du cas d'utilisation sont clairs et corrects; s'il existe des méthodes de vérification évidentes pour les résultats attendus.
5. Les cas d'utilisation redondants ont-ils été supprimés?
6. Contient-il suffisamment de cas de test négatifs? Entièrement défini, si la règle 2 & 8 est utilisée ici, c'est quatre fois le nombre de cas d'utilisation positifs.Après tout, dans un logiciel robuste, 80% du code «protège» 20% de l'implémentation de la fonction.
7. S'il faut concevoir des cas de test pour les scénarios d'utilisation des utilisateurs et les processus d'utilisation à partir du niveau utilisateur.
8. S'il est concis et réutilisable. Par exemple, les étapes ou processus très répétitifs peuvent être extraits et définis comme des étapes standard réutilisables.
3: Réviseurs participants (ici seront divisés en plusieurs niveaux d'examen)
1. Revue du département, revue impliquant tous les membres du département des tests.
2. Revue de l'entreprise, y compris les chefs de projet, les analystes des exigences, les concepteurs d'architecture, les développeurs et les testeurs.
3. Avis des clients, y compris les développeurs et les testeurs du client. Cette situation est plus courante dans les entreprises d'externalisation