3.1 Vue d'ensemble du processus de test logiciel
processus de test logiciel et le processus de développement de logiciels est similaire, ainsi que plusieurs parties du plan de test, la conception des tests, le développement de tests, exécution des tests et évaluation des tests.
(1) programme d'essais. Selon les besoins des utilisateurs un rapport sur les exigences fonctionnelles des spécifications et des indicateurs de performance, la définition de la demande de rapport d'essai correspondant que tous les travaux d'essai ultérieur sera effectué autour des exigences de test. Dans le même temps, sélectionnez le contenu de test approprié, les testeurs arrangements raisonnables, le temps de test et des ressources de test.
(2) la conception des tests. la conception d'essai fait référence à l'étape de la planification des tests de décomposition pour élaborer des exigences de test, répartis en un certain nombre de processus de test exécutable et sélectionnez les cas de test appropriés pour chaque processus de test, afin d'assurer la validité des résultats des tests.
(3) le développement de test. Établir un processus de test automatisé peut être une utilisation répétée.
(4) l'exécution des tests. test automatique Pendant la phase de développement de test de l'établissement, et les défauts constatés pour suivre la gestion. Il est généralement effectué par un test de l'unité de test, les tests d'intégration, les tests de validation et les étapes tests de régression.
(5) les essais et l'évaluation. domaine de liaison Quantifier la couverture des tests et des rapports de suivi des défauts sur l'avancement des travaux et la qualité et l'efficacité de l'équipe de développement de logiciels d'application d'une évaluation complète.
Dans la procédure de test, le test effectué en effectuant les étapes suivantes: tests unitaires, tests d'intégration, tests de validation et d'acceptation, présentés à la figure 3.1.
Figure 3.1 Processus d'exécution des tests logiciels
(1) test unitaire: En testant chaque module logiciel minimum, la mise en œuvre d'un programme d'essai pour chaque unité du code source, le programme vérifie si chaque module est mis en œuvre fonction prédéterminée correctement pour qu'il puisse fonctionner.
(2) Test d'intégration: Le module a été testé pour l'intégration de l'ensemble, visant à tester les questions de structure du programme associés à la conception de logiciels.
(3) les tests de validation: tester le logiciel satisfait aux exigences fonctionnelles et de performance dans le cahier des charges, la configuration logicielle est déterminée complètement et correctement. Dans le même logiciel de test de temps peut coordonner avec l'environnement d'exploitation réelle dans d'autres parties du système (tels que le matériel, base de données et le personnel d'exploitation).
(4) les tests d'acceptation: le processus de test logiciel que la qualité du produit final, le logiciel principal permet aux utilisateurs de tester et re-exécuter un sous-ensemble de tests ont été effectués pour assurer qu'aucune introduction de nouvelles erreurs.
3.2 Tests unitaires
1. contenu de tests unitaires
Des moyens pour tester le module de programme de test, il y a les cinq tâches principales suivantes: l'interface du module de test, structure de données locale de l'essai, les conditions aux limites du test, le chemin d'exécution d'essais et de gestion des erreurs, illustré à la figure 3.2.
Figure 3.2 tâche de test unitaire à résoudre
1) Module d'interface de test
flux de données par le module sous test test, vérifie les données sur le module est correct. Ainsi, une interface doit module comprend une table de paramètres, les paramètres d'appel sous-module, les données globales, entrée de fichier / opérations de sortie pour tester et similaires. En particulier, ce qui suit.
(1) Le nombre de modules coïncide paramètre accepte le nombre réel de paramètres d'entrée du module.
Les types de paramètres formels et les paramètres réels du module (2) correspondent à l'entrée.
Que ce soit sous la forme de paramètres de l'appareil et des paramètres réels utilisés par les entrées module (3) sont alignés.
(4) lorsque l'appel d'autres modules, le nombre du nombre réel de paramètres transmis est appelée avec les paramètres formels du module sont les mêmes.
(5) Lorsque l'appel d'autres modules, le paramètre réel transmis avec les paramètres formels du match du module appelant.
(6) appelle un autre module, l'unité et les paramètres réels de la forme transmise les paramètres du module d'appel sont cohérentes.
(7) le numéro d'appel de fonction interne, et le paramètre d'attribut d'ordre est correct.
(8) Dans le cas du module avec une pluralité d'entrées, si les paramètres de référence de courant indépendante de l'entrée.
(9) si les paramètres de lecture-modification.
(10) si une variable dans l'ensemble de leurs modules ont la même référence de définitions.
Si comprend un module d'E / S externe à l'intérieur, vous devez également tenir compte des facteurs suivants:
(1) les attributs de fichier sont corrects.
(2) OPEN et de fermeture est correcte.
(3) la longueur de la capacité de tampon de la partie d'enregistrement.
Que ce soit pour ouvrir le fichier avant (4) lors des opérations de lecture / écriture.
(5) Au terme de l'identificateur de fichier est fermé le fichier.
(6) l'écriture / saisie de texte pour les erreurs.
(7) I / O vérification d'erreur et si vous souhaitez faire une affaire.
2) la structure de données locale de l'essai
Le test vérifie les problèmes d'intégrité de la structure de données locales, comme une spécification de type de données, initialisation, par défaut, etc., et de tester l'influence sur le module de données globales.
Au cours du module doit être testé à l'intérieur du module peut maintenir l'intégrité des données, y compris le contenu des données internes, sous forme de relations mutuelles et les erreurs ne se produisent pas.
Il est à noter que les types de structures de données locales d'erreurs: description de type incorrect ou incompatible, initialisation incorrecte ou les valeurs par défaut, erreur de nom de variable, comme les fautes d'orthographe ou d'une erreur d'écriture, underflow, débordement ou une erreur d'adresse.
3) Essai de chemin d'exécution
test important de cas de test du module de chemin d'exécution, dans lequel les chemins d'exécution de base et test de piste cyclable peut trouver souvent beaucoup d'erreurs. Étant donné que le test doit être en mesure de découvrir l'erreur de calcul d'erreur, la détermination incorrecte ou flux de contrôle normal généré.
Erreurs courantes: priorité arithmétique incorrect ou trompeur, erreur de fonctionnement en mode mixte, erreur d'initialisation, la précision est pas assez précis, la représentation symbolique incorrecte de l'expression.
Et une couverture pour les conditions de détermination, les cas de test peut être trouvé les erreurs suivantes: comparaison d'erreur de différents types de données, incorrecte ou incorrecte détermination, opération logique incorrecte ou de priorité, lieu en raison d'une erreur doit être la même précision ne peut pas être égale à variable, se termine en boucle incorrects ou inexistants, en ce qui concerne la branche de recyclage ne peut quitter, modifier de façon inappropriée la variable de boucle.
4) Mesure de gestion des erreurs
Gestion des erreurs module d'inspection contient des erreurs ou des défauts. Par exemple, il faut rejeter l'entrée déraisonnable, si la description d'erreur est difficile à comprendre, si l'emplacement de défaut est erroné, que ce soit la cause du rapport d'erreur est erroné, si le traitement des conditions d'erreur est incorrect, la condition d'erreur avant la gestion des erreurs est déjà à l'origine du système l'intervention.
Module de gestion des erreurs de test clé lorsqu'une erreur se produit au travail, les installations de gestion des erreurs qui sont valides.
5) Test de condition aux limites
Test des conditions aux limites est la dernière étape de l'unité d'essai, analyse de la valeur limite doit être utilisée pour concevoir des cas de test. Le test fonctionne correctement à la limite, l'ensemble du module de test pour limiter le traitement des données.
Certains types de données relatives à la frontière, comme premier, dernier, maximum, minimum, maximum, minimum, maximum, minimum et ainsi de suite.
Dans les conditions aux limites du test, le test doit être conçu pour vérifier les points suivants:
(1) si une erreur se produit au 0ème, ...... 1 n fois n cycles.
Prend le calcul ou la détermination de la valeur maximale (2), qu'il y ait une valeur minimale d'erreur.
(3) flux de données, le flux de commande est exactement égal à, supérieur à, si l'erreur est inférieure à la valeur de comparaison déterminée.
Etape 2. Unité de test
Les tests unitaires sont habituellement effectuée à l'étape de codage. Le code source complet dans la préparation et l'examen et la vérification, après avoir confirmé aucune erreur de syntaxe, a commencé à concevoir des cas de test pour les tests unitaires.
Module n'est pas un programme indépendant, en considérant le module de test, en tenant compte de ses liens avec le monde extérieur, utilisez donc un certain module auxiliaire pour simuler d'autres modules associés au module sous test. Module auxiliaire est divisé en deux ce qui suit:
(1) module d'entraînement (Drive): est utilisé sur un module analogique du module sous test, correspondant au module principal de programme en cours de test pour recevoir des données de test, et envoie les données au module sous test, le module sous début d'essai Enfin, la sortie des résultats mesurés.
(2) le talon (Stub): utilisé pour simuler le cours du module dans le module de test invoqué. Stubs étaient seulement quelques traitement de données générales, vous n'avez pas besoin de toutes les caractéristiques des sous-modules sont amenés, mais ne font rien.
Le module sous test, il est associé avec le module d'entraînement et le tourillon forment ensemble un « environnement de test », représenté sur la figure 3.3.
Figure 3.3 environnement de test de test unitaire
3.3 Test d'intégration
Procédé selon les exigences de conception de logiciel, les modules sont reliés entre eux par le biais de tests unitaires, le système de logiciel en tant que composition définie appelée « intégré ». test d'intégration est de test pour ce processus, en fonction de la relation de dépendance entre l'interface du module. La figure 3.4 montre un exemple de la hiérarchie logicielle de la figure.
Parce que les tests d'intégration ne se fait pas dans un environnement réel, mais plutôt dans un environnement de développement distinct ou dans un environnement de test, l'intégration des tests requis pour le personnel choisi dans le groupe de développement général, sous la supervision de la tête du développement. chef de l'équipe de développement chargé de veiller à la mise en œuvre de l'intégration complète de tests en utilisant la technologie d'essai approprié à un contrôle de qualité raisonnable et la supervision. Les tests d'intégration, les tests par un observateur indépendant pour surveiller les essais.
3.4 schéma de la hiérarchie logicielle
1. La tâche principale des tests d'intégration
Est un ensemble de techniques tester le logiciel de système de test intégré, selon la conception des exigences des modules individuels ensemble après assemblage du test unitaire, le logiciel nécessite la structure du logiciel système réaliste, trouvé dans diverses erreurs liées à l'interface. Les tests d'intégration est principalement adaptée aux différents systèmes logiciels suivants:
(1) ont besoin d'un système de logiciels de qualité des logiciels plus élevés, tels que les logiciels de l'aérospatiale, des logiciels de télécommunication, le logiciel du système sous-jacent.
(2) l'utilisation d'une portée plus large, un plus grand nombre d'utilisateurs du logiciel.
(3) à l'aide du programme de langage de développement de logiciel avec un pointeur similaire à C / C ++.
(4) bibliothèques, middleware et d'autres produits.
La tâche principale des tests d'intégration est de répondre aux cinq questions suivantes:
(1) Les modules sont reliés entre eux, chaque module appelle les données d'inspection par l'intermédiaire de l'interface est perdue.
(2) combinant les fonctions respectives, les fonctions de contrôle peuvent atteindre les exigences attendues.
La fonction est (3) un module de fonction à un autre module en souffrirait.
Si (4) la structure globale des données en question, ne serait pas de modifications inhabituelles.
Erreur (5) si le module unique accumulé est agrandi, de manière à atteindre un degré inacceptable.
2. Test Méthode d'intégration
La principale intégration du logiciel de test test de problèmes structurels, de sorte que le test basé sur l'interface du module, la plupart des tests de boîte noire, boîte blanche correctement complétée. Les tests d'intégration devrait suivre les étapes suivantes.
Etape 1: vérification de la relation entre la composition d'un des modules de système complet.
Étape 2: besoins d'interaction et de la communication entre le module d'évaluation, confirmer les interfaces entre modules.
Étape 3: générer un ensemble de cas de test.
Etape 4: un des modules de test différentiels ajoutés séquentiellement à la procédure de test du système et la séquence logique / fonctionnel est répété.
processus de test d'intégration avec une attention particulière au module clé de test, le module clé a généralement une ou plusieurs des caractéristiques suivantes:
(1) correspond à plusieurs demandes de fonction en même temps;
(2) ayant une fonction de commande de haut niveau;
(3) complexe, sujette à erreur;
(4) les exigences de performance particulières.
L'objet principal de l'essai est de vérifier l'intégration et l'interaction de chacun des modules d'interface de la composition du système logiciel, et donc l'intégration des données à partir des exigences de test et de la difficulté du contenu est pas très élevé. L'intégration test généralement ne pas utiliser des données réelles, vous pouvez utiliser une partie des données de test représentatives. Lors de la création de données de test, des conditions aux limites doivent veiller à ce que les données système logiciel entièrement testé.
Y compris les essais et les tests d'intégration progressive intégration de tests d'intégration non progressive.
1) Test d'intégration non-incrémentale
Integration Testing Méthode non-étape supplémentaire pour tester, après des tests unitaires individuelles pour tous les modules, la structure de programme selon la figure reliant les modules entre eux, la procédure de connexion après le test dans son ensemble.
2) incrémental tests d'intégration
méthode incrémentale de tests d'intégration comprend test de haut en bas incrémentale, et un test sandwich intégration progressive de test de bas en haut à partir de.
(1) Essai de haut en bas incrémentielle. Top-down incrémentale par étapes de test et d'intégration progressive schéma structurel selon l'une top-down test. Le module intégré est le premier module maître intégré (programme principal) de commande, puis suivre la hiérarchie de l'intégration du logiciel de commande vers le bas. Descendante manière peuvent être des stratégies intégrées et première profondeur en largeur stratégie, illustrée à la figure 3.5.
Figure en baisse de 3,5 auto-test supplémentaire schématique
(2) Test incrémentale ascendante. test ascendante progressive à partir du module « atomique » (structure de module logiciel du fond), en commençant par la structure ascendante de la figure intégration progressive et d'essais. La figure 3.6 représente un processus de bas en haut de l'essai supplémentaire.
3.6 un schéma de principe d'un test supplémentaire bottom-up
(3) les tests d'intégration sandwich. L'intégration a également appelé l'intégration hybride sandwich, il haut vers le bas et le bas retroussé les avantages et les inconvénients. système sandwich est divisé en trois couches sont intégrées avec une couche intermédiaire en tant que couche cible. La couche supérieure de la couche cible à l'aide de haut en bas en mode test intégré de test, l'utilisation de la couche d'intégration de la stratégie ascendante en dessous de la couche cible, la couche cible est finalement testée.
Comme cela est illustré en utilisant la pile de procédure S2, S3 et S4, le test de l'interface utilisateur M1 3.7, en utilisant les pilotes D5 et D6 fonction du module inférieur M7, M8 et M9 ont été testés. Lorsque l'ensemble du système intégré, la pile de programme S2, S3 et S4 dans le module de couche intermédiaire M2, M3 et M4, les conducteurs D5 et D6 du module remplacé M5 et M6 de la couche intermédiaire, la couche intermédiaire de telle sorte que le module fonctionnel est à tester.
sandwiches tests d'intégration figure schématique 3.7
3.4 test de confirmation
Pour les tests de confirmation pour vérifier la validité du logiciel, à savoir, pour vérifier la fonctionnalité et les performances des logiciels et d'autres caractéristiques correspondent aux besoins de l'utilisateur.
Dans la phase test doit être fait pour confirmer le travail montré à la figure 3.8. Vous devez d'abord tester l'efficacité de l'examen, ainsi que la configuration du logiciel, l'installation et les tests d'acceptation et de test après par les experts, pour devenir un produit livrable logiciel.
l'étape de confirmation de l'essai figure 3.8
1. test de validité
Validité de l'essai dans un environnement simulé, l'utilisation de méthodes d'essai de boîte noire pour vérifier le logiciel testé satisfait aux exigences énumérées dans le cahier des charges. A cet effet, des plans d'essai, les dispositions d'essai du genre à faire, de développer un ensemble d'étapes de test, décrire les cas de test. Pour déterminer si le logiciel dispose conformes aux exigences en mettant en œuvre des procédures d'essai des plans et tests prédéfinis pour assurer que tous les logiciels les exigences fonctionnelles sont satisfaites, tous les logiciels pour atteindre les exigences de performance, tous les documents sont corrects et facile à utiliser.
2. Configuration du logiciel d'examen
Le but de l'examen est de faire en sorte que la configuration du logiciel de configuration logicielle de tous les composants, y compris l'environnement de fonctionnement réel du système sont l'environnement de support complet, la qualité de tous les aspects de la conformité à toutes les exigences. Dans le processus de tests de validation, doivent respecter strictement les dispositions des mesures pour utiliser le manuel d'utilisation Manuel et l'utilisateur, afin de vérifier l'exhaustivité et l'exactitude de la documentation, l'enregistrement des omissions et des erreurs trouvées, et de compléter de façon appropriée et correcte.
3.5 Acceptance Test
les tests d'acceptation des utilisateurs est principalement à tester, les développeurs de logiciels et le personnel d'assurance qualité devrait également participer. Par l'utilisateur de participer à la conception des cas de test, entrée de données de test via l'interface utilisateur, la sortie des résultats d'analyse du test. Les données réelles sont généralement utilisées dans le test de production. Pendant l'essai, en plus d'examiner la fonction et la performance du logiciel, mais aussi pour faire face à la portabilité, la compatibilité, la maintenabilité, les fonctions de récupération d'erreur et d'autres logiciels pour confirmer.
3.5.1 Test α et β essai
Après la livraison du logiciel, les utilisateurs seront comment utiliser effectivement le programme pour les développeurs est imprévisible. Parce que les problèmes des utilisateurs un malentendu de la méthode de fonctionnement du logiciel se produit souvent lors de l'utilisation, la combinaison de données d'anomalie, la génération pour certains utilisateurs semblent être clairs, mais pour d'autres il est difficile de comprendre l'utilisateur sortie, et ainsi de suite.
α et β test test est utilisé pour trouver des erreurs peut être l'utilisateur final peut trouver. essai α de test peut être effectué un utilisateur dans l'environnement de développement, le test peut être effectué dans l'utilisateur de l'entreprise dans la simulation de l'environnement de fonctionnement réel. α test est un test effectué dans un environnement contrôlé. Le but du test est l'évaluation de FURPS des produits logiciels qui fonctionnent, la facilité d'utilisation, la fiabilité, la performance et le soutien, avec un accent particulier sur l'interface et les caractéristiques du produit. Α commence après la fin du test peut être démarré à partir du logiciel encodée, ou commençant après le module (partition) le test est terminé, le test peut être confirmé que le produit pendant certain degré de stabilité et de fiabilité.
β essai est un essai effectué dans un ou plusieurs de l'environnement réel de l'utilisateur par une pluralité d'utilisateurs du logiciel. Et différent de test α est que les développeurs font souvent le site de test non. Par conséquent, β test est effectué dans les développeurs de logiciels d'application sur le terrain sous environnement incontrôlable. Dans le test de β, l'enregistrement utilisateur tous les problèmes rencontrés, y compris les jugements réels et subjectifs, et de faire rapport régulièrement au développeur, le développeur après des rapports complets d'utilisateurs, faire des changements, et enfin les produits logiciels livrés à tous les utilisateurs utiliser. test de β se concentre sur le soutien du produit, y compris la documentation, la formation des clients et le soutien des capacités de production. Seulement lorsque α essai atteint un certain niveau de fiabilité, β peut commencer à tester.
3.5.2 test de régression
Toute étape du cycle de vie du logiciel, tant que le logiciel a changé, vous pouvez donner le défaut du logiciel a causé le problème. Le changement peut être dû à des erreurs logicielles trouvé et apporté des modifications, mais peut aussi être due à la phase d'intégration ou de maintenance a ajouté un nouveau module et d'autres circonstances. Les tests de régression est un test pour vérifier l'intégrité et la précision de la technologie a changé le système, fait référence à la réimplantation d'un sous-ensemble de tests ont été effectués pour faire en sorte que la modification ne présente pas de nouvelles erreurs ou avant en raison du changement provoqué par la découverte l'erreur ne se découvre pas, ce qui est, pour assurer le changement n'a pas apporté des effets secondaires indésirables. Par conséquent, toutes les phases du développement logiciel seront effectués des tests de régression multiple.
1. Condition préalable pour la mise en œuvre des tests de régression
(1) Lorsque le logiciel erreurs pouvant être contenues se trouvent, si le suivi des erreurs et système de gestion ne sont pas parfaites, ces erreurs peuvent être des modifications manquées;
(2) le développeur de l'incompréhension ou mal, il pourrait conduire à une révision faite ne corrige un bogue dans l'apparence extérieure, mais ne résout pas l'erreur elle-même, entraînant une modification a échoué;
(3) la modification est également possible de produire des effets secondaires conduisant à des parties du logiciel n'a pas été modifié pour produire de nouveaux problèmes, de sorte que fonctionnerait fonction normale génère une erreur.
2. Les tests de régression de deux stratégies
Les tests de régression teste à toutes les étapes des activités d'essai, aux fins d'inspection de défaut a été constaté qu'il n'y a pas de modification correcte et le processus de révision n'a pas causé de nouveaux défauts. Les stratégies suivantes peuvent être utilisées pour les tests de régression.
1) test de répétition complète
Répétez le test est complet tous les cas de test une fois de plus complètement exécutés, afin de confirmer les méthodes d'essai modifiées entourant la question de la validité et si les changements ont touché. L'inconvénient est dû prendre des cas d'utilisation complète de mise en œuvre, ce qui augmente les coûts du projet, sera également une incidence sur le calendrier du projet, il est difficile de mettre pleinement en œuvre.
2) test de répétition sélective
Fait référence à des tests répétés sélectifs peuvent être effectués pour sélectionner une partie, afin de confirmer l'exactitude de la question du périmètre modifié et est soumis à des modifications de la méthode d'essai d'impact. Voici plusieurs méthodes de tests répétés sélectifs:
(1) recouvre la méthode des modifications.
(2) Méthode d'influence de l'extérieur.
index (3) a atteint une méthode.
(4) une section transversale à base d'un test de fonctionnement.
(5) Essai de sélection en fonction du risque.
3. processus de test de régression
processus de test de régression a généralement les étapes suivantes.
Étape 1: étape de la formulation des politiques dans les tests, test de régression pour élaborer des stratégies.
Étape 2: Déterminer la version de test de régression.
Etape 3: vérification de validation de régression, les tests de régression tests de régression conformément à la politique.
Etape 4: Par des tests de régression, d'un défaut de suivi unique hors tension.
Étape 5: Les tests de régression ne sont pas transmises, un seul retour de défaut, les développeurs de rééditer, ne régression tester à nouveau.
4. Comparaison des tests de régression et d'essai général
Les tests de régression et le test général par rapport à un certain nombre de points différents, les points suivants ont été attribués à la disponibilité d'un plan d'essai, la portée d'essai, le temps, le développement de l'information, les termes de temps et d'efficacité, etc. sont introduits.
Disponibilité (1) plan d'essai: systèmes de test généraux selon les spécifications et les plans de tests, cas de test sont nouveaux, et les tests de régression peut être un changement de spécification, le programme modifié et la nécessité de mettre à jour le plan de test.
(2) Champ d'application Test: L'objectif général du test est de détecter l'exactitude de l'ensemble du programme, l'objectif est de détecter le test de régression la justesse de la partie pertinente du système modifié et son intégration avec la fonction d'origine.
(3) répartition du temps: le temps nécessaire pour tester le budget général avant que le logiciel est généralement développé, et le temps requis pour les tests de régression (en particulier des tests de régression corrective) ne sont souvent pas inclus dans le calendrier du produit.
(4) le développement de l'information: le développement de tests de connaissances générales et des informations sur les titres disponibles à tout moment, et les tests de régression peuvent être effectués à différents endroits et moments, besoin de conserver des informations pour assurer le bon développement des tests de régression.
(5) Temps d'achèvement: Puisque seule une partie des tests de régression du programme de test, complétant ainsi le temps nécessaire pour les essais est généralement moins de temps que les tests normalement requis.
(6) Fréquence d'exécution: test de régression souvent plusieurs fois au cours du cycle de vie d'un système, une fois que le système a été modifié sur la nécessité pour les tests de régression.
