FAQ sur les tests de logiciels

1. Qu'est-ce que le test logiciel ?

Le processus d'exécution d'un programme afin de détecter les erreurs.

2. Quel est le but des tests logiciels ?

Avec le moins de main-d'œuvre, de ressources matérielles et de temps, découvrez divers défauts et erreurs cachés dans le logiciel, améliorez la qualité du logiciel et évitez les risques commerciaux.

3. Qu'est-ce que le test des documents d'exigences ?

S'il existe des contradictions logiques dans les exigences de test et si les exigences sont techniquement réalisables.

4. Qu'est-ce que le test de document de conception ?

Testez si la conception répond à toutes les exigences et si la conception est raisonnable.

5. Qu'est-ce que le test alpha ?

Il s'agit d'un test effectué par un utilisateur dans l'environnement de développement, ou il peut s'agir d'un test contrôlé effectué par des utilisateurs au sein de l'entreprise dans un environnement d'exploitation réel simulé. Le test alpha ne peut pas être effectué par des programmeurs ou des testeurs. Les tests alpha peuvent commencer une fois que le codage du produit logiciel est terminé, ou après que le test du module (sous-système) est terminé, ou après que le produit a atteint un certain niveau de stabilité et de fiabilité lors du test de confirmation.

6. Qu'est-ce que le test bêta ?

Test par plusieurs utilisateurs du logiciel dans l'environnement d'utilisation réel d'un ou plusieurs utilisateurs. Cela ne peut pas être fait par des programmeurs ou des testeurs. Les tests bêta se concentrent sur la prise en charge du produit, y compris la documentation, la formation des clients et le support de production pour le produit. Les tests bêta ne peuvent être lancés que lorsque les tests alpha ont atteint un certain niveau de fiabilité.

7. Qu'est-ce qu'un module pilote ?

Le module pilote est appelé "programme principal" dans la plupart des cas, il reçoit des données de test et transfère ces données au module sous test.

Il permet de simuler le module supérieur de l'unité sous test et peut appeler le module sous test. Pendant le processus de test, le module pilote accepte les données de test, appelle le module testé et transmet les données pertinentes au module testé.

8. Quelle est la fonction du module pilote ?

1) Accepter l'entrée de test ;
2) Juger l'entrée ;
3) Transmettre l'entrée à l'unité testée pour conduire l'unité testée à s'exécuter ;
4) Accepter le résultat d'exécution de l'unité testée et juger le résultat ;
5) Utiliser le résultat du jugement comme Les résultats d'exécution du cas d'utilisation sont sortis dans le rapport de test.

9. Qu'est-ce qu'un module de bout ?

Il est utilisé pour simuler le module inférieur appelé pendant le processus de travail du module sous test. Le module stub est appelé par le module testé et n'a généralement que peu de traitement de données.

Dans les tests unitaires, lors du test d'un module, il est nécessaire de concevoir un module pilote et un module stub.

Exécutez l'unité testée, afin d'isoler l'unité, selon l'interface testée, développez le pilote correspondant et le programme stub.

10. Qu'est-ce que le test boîte blanche ?

Les tests en boîte blanche, également appelés tests structurés, tests basés sur du code, sont une méthode de conception de cas de test. Il dérive des cas de test de la structure de contrôle du programme, qui est un test du fonctionnement interne de l'unité testée. L'outil de test de la boîte blanche consiste à tester le code source.Le contenu principal du test comprend l'analyse lexicale et l'analyse syntaxique, l'analyse des erreurs statiques, la détection dynamique, etc.

11. Qu'est-ce que le test boîte noire ?

Les tests de boîte noire sont également appelés tests fonctionnels, qui consistent à détecter si chaque fonction peut être utilisée normalement grâce à des tests. Les tests de boîte noire se concentrent sur la structure externe du programme, quelle que soit la structure logique interne, et testent principalement l'interface logicielle et les fonctions logicielles.

12. Qu'est-ce qu'un test statique ?

Tester un logiciel en examinant la documentation, en lisant du code, etc. est appelé test statique. La méthode de test statique consiste à ne pas exécuter le programme testé lui-même, mais uniquement à vérifier l'exactitude du programme en analysant ou en vérifiant la syntaxe, la structure, le processus, l'interface, etc. du programme source.

13. Qu'est-ce qu'un test dynamique ?

Tester un logiciel en exécutant des programmes est appelé test dynamique. Dans les tests dynamiques, les tests en boîte blanche et les tests en boîte noire sont généralement utilisés pour concevoir des cas de test à partir de différentes perspectives afin de trouver des bogues dans les codes logiciels.

14. Qu'est-ce qu'un test de régression ?

Une stratégie et une méthode de test pour s'assurer que la fonction d'origine est normale lorsque le programme est modifié.

15. Quelles sont les méthodes de test en boîte blanche ?

Inspection de code, analyse structurelle statique, métriques de qualité statique, couverture logique, test de chemin fondamental, test de domaine, test de symbole, couverture de chemin et variation de programme.

16. Comment diviser les niveaux de défauts logiciels ?

Le niveau des défauts logiciels peut être décrit par gravité et priorité ;
1) Gravité : mesure le degré de satisfaction de l'impact des défauts sur la satisfaction client, divisé en
①erreurs fatales, qui peuvent causer des problèmes tels que des anomalies et des plantages de ce module et d'autres modules associés ;
②Erreur grave, le problème est limité à ce module, entraînant un dysfonctionnement ou une sortie anormale du module ;
③Erreur générale, une partie de la fonction du module échoue ;
④Module suggéré, la personne qui a proposé le problème doit donner des suggestions d'amélioration du test module ;
2) Priorité : le défaut est éliminé L'urgence de la réparation ;
① Solution immédiate (niveau P1) : Le défaut rend le fonctionnement du système presque inutilisable ou le test ne peut pas continuer et doit être réparé immédiatement ;
② Haute priorité (niveau P2) : le défaut est grave et affecte le test, auquel il faut donner la priorité ;
③ Normal Queuing (niveau P3) : les défauts doivent être mis en file d'attente pour réparation normalement ;
④ Faible priorité (niveau P4) : les défauts peuvent être corrigés quand il est temps;

17. Quelle est la différence entre les tests boîte blanche et les tests boîte noire ?

1) Tests de la boîte noire : connaissant les spécifications de conception fonctionnelle du produit, des tests peuvent être effectués pour prouver si chaque fonction implémentée répond aux exigences.
2) Le test boîte noire du logiciel signifie que le test est effectué à l'interface du logiciel. Cette méthode considère l'objet de test comme une boîte noire, et le testeur ne considère pas du tout la structure logique et les caractéristiques internes du programme, mais vérifie seulement si la fonction du programme est conforme à sa description de fonction selon la spécification des exigences du programme. Par conséquent, les tests de boîte noire sont également appelés tests fonctionnels ou tests basés sur les données.
3) Essais en boîte blanche : connaissant le processus de fonctionnement interne du produit, il peut être testé pour prouver si chaque opération interne répond aux exigences des spécifications de conception et si tous les composants internes ont été vérifiés.
4) Le test boîte blanche du logiciel est une inspection détaillée des détails procéduraux du logiciel. Cette méthode considère l'objet de test comme une boîte ouverte, ce qui permet aux testeurs d'utiliser la structure logique interne et les informations associées du programme pour concevoir ou sélectionner des cas de test et tester tous les chemins logiques du programme. Déterminez si l'état réel est cohérent avec l'état attendu en examinant l'état du programme à différents points. Par conséquent, les tests en boîte blanche sont également appelés tests structurels ou tests pilotés par la logique.

18. Quel est l'objectif principal des tests de la boîte noire pour trouver des erreurs ?

1) Y a-t-il des fonctionnalités incorrectes ou manquantes.
2) Sur l'interface, l'entrée peut-elle être acceptée correctement ? Le résultat correct peut-il être sorti.
3) S'il y a des erreurs de structure de données ou des erreurs d'accès aux informations externes (telles que les fichiers de données).
4) Si la performance peut répondre aux exigences.
5) S'il y a des erreurs d'initialisation ou de terminaison.

19. Qu'est-ce que le test de la boîte blanche vérifie principalement pour les modules de programme ?

1) Testez au moins une fois tous les chemins d'exécution indépendants des modules de programme.
2) Pour tous les jugements logiques, les deux situations de prendre « vrai » et de prendre « faux » peuvent être testées au moins une fois.
3) Exécutez le corps de la boucle dans les limites de la boucle et dans les limites de l'exécution.
4) Tester la validité des structures de données internes.

20. Si vous pouvez effectuer des tests de boîte noire parfaits, avez-vous encore besoin de tests de boîte blanche ?

1) Tout d'abord, les tests de logiciels ont un défaut fatal, c'est-à-dire des tests incomplets et incomplets. Étant donné qu'un programme ne peut effectuer qu'un petit nombre de tests limités (par rapport au grand nombre de tests exhaustifs), lorsqu'aucune erreur n'est trouvée, on ne peut pas dire qu'il n'y a pas d'erreurs dans le programme. Il n'y a donc pas de test boîte noire parfait.
2) Deuxièmement, même si un test de boîte noire parfait est effectué, il est impossible de tester des parties spécifiques à l'intérieur du programme. De plus, lorsque la spécification elle-même est erronée, le problème ne peut pas être trouvé.
3) Enfin, les tests en boîte blanche peuvent effectuer des tests de couverture sur des parties internes spécifiques du programme, de sorte que les tests en boîte noire et en boîte blanche sont complémentaires, et il est plus raisonnable de les combiner pour concevoir des cas de test. L'expérience montre que les tests boîte blanche sont généralement utilisés pour les tests unitaires, les tests boîte grise pour les tests d'intégration et les tests boîte noire pour les tests système.

21. En combien d'étapes les tests logiciels doivent-ils être divisés ? Décrivez brièvement les points qui doivent être testés à chaque étape ? Quelle est la signification de chaque étape ?

1) D'une manière générale, il peut être divisé en tests unitaires, tests d'intégration, tests système et tests d'acceptation. Les
tests initiaux se concentrent sur chaque module pour garantir l'exactitude du code source. Cette étape devient les tests unitaires, suivis de l'intégration du module et intégration pour Form un progiciel complet. Les tests d'intégration se concentrent sur les problèmes de vérification et de composition du programme.
Après l'intégration du logiciel, la validation et les tests du système doivent être effectués. Les tests de confirmation fournissent l'assurance finale que le logiciel répond à toutes les exigences fonctionnelles et de performance. Les tests de validation appliquent uniquement l'approche de test de la boîte noire.

Il existe cinq phases de test logiciel : test unitaire, test d'intégration, test système, test d'acceptation et test de régression. Chaque étape est divisée en cinq étapes : plan de test, conception de test, conception de cas d'utilisation, résultats d'exécution, rapport de test.
1) Les tests unitaires consistent à tester les composants de base d'un logiciel, tels qu'un module, un processus, etc. C'est la partie la plus fondamentale des tests dynamiques de logiciels, et c'est aussi l'une des parties les plus importantes. Son but est de tester les composants les plus élémentaires du logiciel L'exactitude des unités constituantes. Utilisez principalement la méthode de test de la boîte blanche.
2) Le test d'intégration est un test effectué au cours du processus d'intégration du système logiciel, et son objectif principal est de vérifier si les interfaces entre les unités logicielles sont correctes. La méthode de test de la boîte noire est principalement utilisée, complétée par la méthode de test de la boîte blanche.
3) Le test du système est un test approfondi du système logiciel intégré, qui a vérifié que l'exactitude et les performances du système logiciel répondent aux exigences spécifiées dans sa spécification, et vérifie si le comportement et la sortie du logiciel sont corrects.
4) Les tests d'acceptation visent à démontrer à l'acheteur du logiciel que le logiciel répond aux besoins de ses utilisateurs. Ses données de test sont généralement un sous-ensemble des données de test du système.

Test d'acceptation : Divisé en test α et test β Test
α : Il s'agit d'un test interne réalisé par des testeurs, des développeurs et du personnel interne.
Test β : C'est le test public après le test interne, et finalement remis à l'utilisateur pour test.

5) Le test de régression est un test effectué après la modification du logiciel pendant la phase de maintenance du logiciel, dont le but est de vérifier si la modification du logiciel est correcte.

22. Qu'est-ce que les tests unitaires ?

Le test unitaire, également connu sous le nom de test de module, est un test de vérification de l'exactitude de la plus petite unité de conception de logiciel, le module de programme. Les tests unitaires doivent concevoir des cas de test à partir de la structure interne du programme. Plusieurs modules peuvent être testés indépendamment en parallèle.

23. Qu'est-ce qu'un test d'intégration ?

Les tests d'intégration, également appelés tests d'assemblage, testent généralement tous les modules de programme de manière séquentielle et incrémentielle sur la base de tests unitaires. Concentrez-vous sur les tests de la partie interface des différents modules.

24. Qu'est-ce que le test système ?

Le test du système fait référence au test de l'ensemble du système logiciel dans son ensemble, y compris les fonctions de test, les performances et l'environnement matériel et logiciel dans lequel le logiciel s'exécute. Le test du système est effectué une fois l'intégration du système terminée. Au début, il teste principalement si les fonctions du système répondent aux exigences. Au stade ultérieur, il teste principalement si les performances du fonctionnement du système répondent aux exigences, et la compatibilité du système dans différents environnements logiciels et matériels.

25. Qu'est-ce qu'un test d'acceptation ?

Les tests d'acceptation visent à démontrer à l'acheteur du logiciel que le système logiciel répond aux besoins de ses utilisateurs. Ses données de test sont généralement un sous-ensemble des données de test du système.

26. Qu'est-ce qu'un test de régression ?

Le test de régression est un test effectué après la modification du logiciel pendant la phase de maintenance du logiciel. Son but est de vérifier que les modifications apportées au logiciel sont correctes.

27. Quelles mesures de gestion sont prises pour les défauts ?

1) Introduire des outils de gestion des défauts.
2) En fonction du cycle de vie des défauts, considérez la gestion de la soumission des défauts, la gestion de l'état des défauts et la gestion de l'analyse des défauts.
3) Tous les défauts trouvés doivent être soumis à l'outil de gestion des défauts immédiatement et avec précision, qui est la gestion de la soumission des défauts.
4) Une fois le défaut soumis, il doit être attribué au développeur correspondant en temps opportun. La personne qui a soumis le défaut doit prêter une attention particulière à l'état du défaut et aider le défaut à être résolu dès que possible .
5) Une fois le défaut résolu, il est nécessaire de vérifier immédiatement la réparation du défaut.
Objectif : ① pour résoudre les défauts dès que possible ; ② pour faciliter l'analyse des défauts ultérieurement.
6) Afin de mieux améliorer le processus de développement et le processus de test, il est nécessaire d'analyser les défauts, de résumer les catégories de défauts, la répartition par âge des défauts et d'autres informations, qui est la gestion de l'analyse des défauts.

28. Quel est l'objectif des tests unitaires, des tests d'intégration et des tests système ?

1) Les tests unitaires sont le niveau le plus bas d'activité de test à effectuer pendant le développement de logiciels, dans lequel une unité logicielle indépendante est testée indépendamment du reste du programme et les tests se concentrent sur les modules du système, y compris la vérification de l'exactitude des sous-programmes, etc.
2) Tests d'intégration, également appelés tests d'assemblage ou tests conjoints. Sur la base des tests unitaires, tous les modules sont assemblés en sous-systèmes ou systèmes conformément aux exigences de conception, et des tests d'intégration sont effectués. La pratique a montré que bien que certains modules puissent fonctionner indépendamment, cela ne garantit pas qu'ils puissent fonctionner normalement lorsqu'ils sont connectés. Les problèmes qui ne peuvent pas être reflétés localement dans le programme sont susceptibles d'être exposés globalement, affectant la réalisation des fonctions. L'objectif du test est la connexion entre les modules et le transfert des paramètres.
3) Le test du système consiste à assembler les sous-systèmes testés en un système complet pour le test. C'est une méthode efficace pour vérifier si le système peut effectivement fournir les fonctions spécifiées dans la spécification du schéma du système. Les tests se concentrent sur le fonctionnement de l'ensemble du système et la compatibilité avec d'autres logiciels.

29. Quelle est la méthode de base pour la conception de cas de test en boîte blanche ?

Test de chemin de base, analyse des valeurs limites, test de couverture, test de boucle, test de flux de données, test d'instrumentation de programme, test de mutation. La base est la spécification de conception détaillée et sa structure de code.

30. Quelles sont les bases de la conception des cas de test boîte noire ?

Tests basés sur les besoins de l'utilisateur, méthode d'analyse des diagrammes fonctionnels, méthode de partition de classe d'équivalence, méthode d'analyse des valeurs limites, méthode de devinette d'erreur, méthode du diagramme de cause à effet, méthode d'analyse basée sur la table de décision, méthode de conception d'expérience orthogonale. La base est la spécification des besoins de l'utilisateur et la spécification de conception détaillée.

Je suppose que tu aimes

Origine blog.csdn.net/qq_48826058/article/details/124481125
conseillé
Classement