Organisez les apprentissages récents et demandez des corrections s'il y a une inadéquation.
Le processus de base des tests logiciels:
Etape d'analyse des besoins -> Etape de planification des tests -> Ecriture de cas de test -> Etape d'implémentation des tests -> Rapport de test
1. Étape d'analyse de la demande
Les tests logiciels doivent être basés sur les exigences, qui doivent être basées sur les exigences. Par conséquent, au début, vous devez lire attentivement les exigences, comprendre les exigences, analyser les exigences, participer à l'examen des exigences et comprendre et comprendre en profondeur les relations logiques entre les exigences.
2. Phase de planification des tests
Compiler un plan de test logiciel en référence à la spécification des exigences logicielles et au plan de projet global. Il contient principalement les cinq contenus suivants:
a. Objectifs et portée du test
b. Affectation des tâches et calendrier
c. Élaborer une stratégie de test
d. Analyse et prévention des risques
e. Divers indicateurs des éléments d'acceptation
La partie stratégie de test comprend généralement trois parties: la méthode de test, l'outil de test et l'environnement de test. Pour la stratégie de test, le premier tour se concentre sur les processus métier pour s'assurer que les fonctions et les pages en ligne sont affichées normalement; la deuxième fois se concentre sur le test de page pour s'assurer que les processus et les pages de l'activité en ligne sont affichés normalement; le troisième cycle se concentre sur l'ensemble de l'entreprise Le processus et les pages sont les principaux pour s'assurer que les fonctions, processus et pages de chaque section du lancement sont normaux; autres tests de direction tels que test de tolérance aux pannes, test d'autorisation, test d'environnement spécial, etc. Les risques logiciels comprennent les risques commerciaux, les risques de sécurité et les risques de calendrier. La partie acceptation comprend les livrables tels que les exigences de test, les plans de test, les cas de test, les rapports de test, etc., ainsi que les exigences de cas de test et les exigences de taux de réparation des défauts d'acceptation de version.
3. Rédiger des cas de test
Pour les tests logiciels, du point de vue de l'objet testé, il peut être divisé selon les trois méthodes de test suivantes: test de boîte noire, test de boîte blanche et test de boîte grise. Les huit méthodes couramment utilisées de test de boîte noire sont: méthode de classe d'équivalence, méthode de valeur limite, méthode de table de décision, méthode de diagramme de causalité, méthode de transition d'état, méthode de scénario, méthode d'expérimentation orthogonale et méthode d'estimation d'erreur; les méthodes de test de boîte blanche comprennent : Couverture de déclaration, couverture de décision, couverture de condition, couverture de décision / condition, couverture de combinaison de conditions.
4. Phase de mise en œuvre du test
Le contenu de travail de la phase de mise en œuvre des tests comprend la construction de l'environnement de test, l'exécution de cas de test et la régression de bogues. Les tests logiciels peuvent être divisés en quatre étapes, à savoir
- Test unitaire: vérifiez et vérifiez la plus petite unité testable du logiciel, les développeurs de visites générales mettent en œuvre la fonction d'inspection si elle répond aux exigences de conception
- Test d'intégration: également appelé test d'assemblage. Sur la base du test unitaire, le module est assemblé selon les exigences de conception pour vérifier si la fonction correspondante est terminée. La partie d'interface du module de test est principalement testée et le module de stub ou le module de pilote utilisé dans le processus de test doit être conçu
- Test du système: testez le logiciel qui a été confirmé et testé avec le matériel informatique, les périphériques et les logiciels de prise en charge dans l'environnement d'exploitation réel
- Test d'acceptation: également appelé test de livraison, il s'agit d'un test formel des besoins des utilisateurs et des processus métier pour déterminer si le système répond aux critères d'acceptation, et l'utilisateur, le client ou toute autre organisation autorisée décide d'accepter le système.
Ces quatre étapes incarnent le processus de test progressif et l'idée de diviser et de conquérir du petit au grand, de l'intérieur vers l'extérieur. Parmi eux, la granularité des tests unitaires est la plus petite, et l'équipe de développement utilise généralement des tests en boîte blanche pour vérifier si l'unité de test est conforme à la «conception»; les tests d'intégration se font entre les tests unitaires et les tests système, et les développeurs utilisent généralement une boîte blanche plus noire La méthode de test consiste à vérifier si le système répond à la «conception» et s'il répond aux «exigences»; la granularité du test du système est la plus grande, et généralement une équipe de test indépendante adopte une méthode de boîte noire pour tester si le système répond aux «spécifications des exigences» Manuel "; le test d'acceptation est similaire au test du système, la principale différence est que le testeur est différent et que le test d'acceptation est effectué par l'utilisateur.
5. Rapport de test de sortie
Le rapport de test du logiciel est un document récapitulatif avec une valeur et une logique uniques, comprenant le processus de test et les résultats du processus, certains problèmes rencontrés au cours du processus et la prochaine étape du travail d'amélioration. Le rôle du rapport de test se manifeste sous trois aspects: le rapportage, l'évaluation et la réflexion. Le reporting fait référence au reporting aux dirigeants et aux projets autant que possible sous la forme de rapports de test, et à la communication des résultats de test récents; l'évaluation se réfère à l'évaluation de la qualité du logiciel, et l'évaluation dépend de l'équipe de test, et les cas d'utilisation et les cas d'utilisation utilisés dans le projet de test sont exécutés Les résultats et les défauts logiciels trouvés au milieu montrent la qualité du logiciel directement et concrètement; la réflexion signifie réfléchir sur la façon d'améliorer le travail par la révision. Le rapport de test logiciel peut être rédigé dans le cadre du gabarit de référence, guidé par le responsable du test et le leader, et réalisé après la fin d'une phase de test. Son contenu principal devrait inclure:
- Travail d'essai écoulé: temps, travail, participants
- Cas d'utilisation et défauts: fonction, total, exécution, défaut
- Évaluation de la qualité des logiciels: fonctions, risques, problèmes de qualité éventuels
- Suggestions d'amélioration du travail: défauts restants, suggestions de demande, environnement de test, gestion de projet
Modèle de référence: https://blog.csdn.net/xqtesting/article/details/78976456