Cycle de vie Software Testing

Le cycle de vie du logiciel de test consiste en une série d'étapes à travers laquelle un produit passe par un logiciel et décrit les différentes activités relatives aux essais qui sont effectués sur le produit. Voici une explication de la STLC avec un organigramme.

Introduction à cycle de vie Software Testing

Dans chaque organisme de contrôle est une étape importante dans le développement d'un produit logiciel. Cependant, la façon dont elle est effectuée diffère d'une organisation à l'autre. Il est conseillé d'effectuer le processus de test dès les premières étapes, en ce qui concerne le cycle de vie de développement logiciel ou SDLC pour éviter toute complication.

Software Testing phases du cycle de vie

Tests de logiciels a son propre cycle de vie qui répond à toutes les étapes de la SDLC. Le test de logiciels schéma du cycle de vie peut aider à comprendre ses différentes phases. Ils sont les suivants: 1. Etape exigence

2. Planification des tests

3. Analyse test

4. Test Design

5. Vérification du test et de la construction

6. Exécution des tests

7. Analyse des résultats

8. De suivi des bogues

9. Rapports et de réparation

10. Test final et mise en œuvre

11. Poster mise en œuvre

Etape exigence

Il s'agit de la première étape du processus de tests de logiciels du cycle de vie. Dans cette phase, les développeurs de participer à l'analyse des besoins pour la conception d'un produit. Le rôle des testeurs de logiciels est également nécessaire dans cette phase, car ils peuvent penser du point de les «utilisateurs» de vue que les développeurs ne peuvent pas. Ainsi, une équipe de développeurs, testeurs et utilisateurs peuvent être formés, afin d'analyser les exigences du produit. Les réunions officielles de l'équipe peuvent être organisées dans le but de documenter les exigences qui peuvent en outre être utilisés en tant que logiciel spécification des exigences ou SRS.

Planification des tests

La planification des tests signifie déterminer à l'avance un plan bien à l'avance pour réduire les risques supplémentaires. Un document bien conçu plan de test joue un rôle important dans la réalisation d'une approche axée sur les processus. Une fois les exigences du projet sont confirmés, un plan de test est documenté. La structure du plan de test est comme suit: 1. Introduction: Cette section décrit l'objectif du plan de test.

2. Eléments d'essai: Les éléments qui sont nécessaires à la préparation de ce document seront énumérés ici comme SRS, plan de projet.

3. Caractéristiques à tester: Ceci décrit la zone de couverture du plan de test, qui est, la liste des fonctionnalités à tester, que sont fondées sur les exigences implicites et explicites du client.

4. Caractéristiques de ne pas tester: Les fonctionnalités intégrées ou composé qui peuvent être ignorés de la phase de test sont énumérés ici. Caractéristiques qui sont hors de portée des essais, comme les modules incomplets ou ceux de la gravité bas, par exemple, les fonctions graphiques qui ne gênent pas le processus peut être inclus dans la liste.

5. Approche: Il s'agit de la stratégie de test qui doit être adapté au niveau du plan. Il devrait être dans l'acceptation avec les niveaux supérieurs et inférieurs du plan.

6. Article réussite / d'échec: Relatif à la question show stopper. Les critères utilisés pour expliquer a quel élément test a réussi ou échoué.

7. Suspension critères et les exigences de reprise: Les critères de suspension précise les critères qui doivent être utilisés pour suspendre tout ou partie des activités de test, tandis que les critères reprise spécifie quand le test peut reprendre avec la partie suspendue.

8. Testez livrable: Cela inclut une liste de documents, rapports, tableaux qui sont nécessaires pour être présentée aux parties prenantes sur une base régulière au cours du processus de test et après son achèvement.

9. Vérification des tâches: Cette phase de test répertorie les tâches qui doivent être effectuées. Cela inclut des essais, l'évaluation des résultats et de les documenter sur la base du plan de test conçu. Cela permet également aux utilisateurs et testeurs pour éviter fonctions incomplètes et éviter le gaspillage des ressources.

10. Besoins de l'environnement: Les exigences particulières du plan de test en fonction de l'environnement dans lequel l'application doit être conçu sont listés ici.

11. Responsabilités: Cette phase attribue des responsabilités à des personnes qui peuvent être tenues pour responsables en cas de risque.

12. Les besoins en personnel et de la formation: formation sur l'application / du système et sur les outils de test à utiliser doit être expliqué aux membres du personnel qui sont responsables de l'application.

13. Risques et charges: Ce met l'accent sur les risques probables ainsi que divers événements qui peuvent se produire et ce qui peut être fait dans de telles situations.

14. Approbation: Ce décide qui peut approuver le processus le plus complet et permettre la poursuite du projet au prochain niveau qui dépend du niveau du plan.

Analyse test

Une fois que la documentation relative au plan d'essai est terminée, la prochaine étape est d'analyser quels types de tests logiciels devraient être effectués aux différents stades de la SDLC.

Test Design

Conception du test se fait sur la base des exigences du projet documenté dans le SRS. Cette phase détermine si le test manuel ou automatisé qui doit être fait. Lors des tests d'automatisation, des chemins différents pour les essais doivent être identifiés en premier lieu et de l'écriture de scripts qui doit être fait si nécessaire. Une liste de contrôle de bout-en-bout qui couvre tous les aspects du projet est nécessaire dans le processus de conception de test.

Vérification du test et de la construction

Dans cette phase, le plan de test, la conception des tests et des scripts de test automatisés sont terminées. Les plans de tests de stress et la performance sont également effectuées à ce stade. Lorsque l'équipe de développement se fait avec une unité de code, l'équipe de test est nécessaire pour les aider à tester cette unité et signaler tout bug dans le produit, s'il est trouvé. Les tests d'intégration et les rapports de bogues est fait dans cette phase du cycle de vie des logiciels de test.

Exécution des tests

Planification et exécution des cas de tests différents est fait dans cette phase. Une fois les tests unitaires est terminée, la fonctionnalité des tests se fait dans cette phase. Dans un premier temps, de niveau supérieur tests sont effectués pour déterminer les échecs de haut niveau et les bugs sont immédiatement signalées à l'équipe de développement pour obtenir la solution de contournement nécessaire. Rapports d'essais doivent être documentés correctement et les bugs doivent être signalés à l'équipe de développement.

Analyse des résultats

Après l'exécution réussie du cas de test, l'équipe de test a pour retester il de comparer les valeurs attendues avec les valeurs réelles, et de déclarer que le résultat de réussite / échec.

De suivi des bogues

C'est l'une des étapes importantes que le document Profil des défauts (DPD) doit être mis à jour pour laisser les développeurs savent à propos du défaut. Document Profil défaut contient suivants1. Id défaut: l'identification unique du défaut.

2. Id Test Case: l'identification des cas de test pour ce défaut.

3. Description: Description détaillée du bug.

4. Résumé: Ce champ contient des informations clé sur le bug, ce qui peut aider à réduire au minimum le nombre d'enregistrements à rechercher.

5. Défaut présenté par: Nom du testeur qui a détecté / rapporté le bogue.

6. Date de soumission: Date à laquelle le bogue a été détecté et signalé.

7. Construire n °: Nombre de séries de tests requis.

8. Version n °: Les informations de version de l'application logicielle dans laquelle le bogue a été détecté et corrigé.

9. Assigné à: Nom du développeur qui est censé corriger le bogue.

10. Gravité: degré de gravité de la faute.

11. Priorité: La priorité de corriger le bug.

12. Statut: Ce champ affiche l'état actuel du bogue.

Rapports et de réparation

Le test est un processus itératif. Le bug qui est rapporté et fixé par l'équipe de développement, doit se soumettre à la procédure de test à nouveau pour s'assurer que le bug trouvé a été résolu. Les tests de régression doit être fait. Une fois que l'analyste de la qualité garantit que le produit est prêt, le logiciel est publié pour la production. Avant la libération, le logiciel doit subir une autre série de tests de haut niveau. Ainsi, le test est un processus continu.

Test final et mise en œuvre

Cette phase se concentre sur les autres niveaux de tests, tels que l'acceptation, de la charge, le stress, la performance et des tests de reprise. L'application doit être vérifiée dans des conditions déterminées par rapport à la SRS. Divers documents sont mis à jour et différentes matrices d'essais sont terminés à ce stade du cycle de vie des logiciels de test.

Poster mise en œuvre

Une fois que les résultats des tests sont évalués, l'enregistrement des erreurs survenues au cours des différents niveaux du cycle de vie des logiciels de test, est fait. Création de plans d'amélioration et de mise en valeur est un processus continu. Cela permet d'éviter des problèmes similaires se produisent dans les projets futurs. En bref, la planification de l'amélioration du processus de test pour les futures applications se fait dans cette phase.

En savoir plus sur:

* Types de tests de logiciels

* Méthodes de test de logiciels

* Tutoriel Software Testing

Ce fut un aperçu du cycle de vie des logiciels de test. Défauts logiciels ne sont pas toujours causés par des erreurs de codage. En fait, les lacunes exigence peut également entraîner des erreurs dans une application. Bien que les tests du logiciel peut être effectuée à n'importe quel stade de la phase de développement, le processus est le plus souvent mis en œuvre lorsque les conditions d'une application ont été précisées et le codage est terminé....