Articles

Qu’est-ce que le test de base dans le logiciel ?

D’abord, nous devrions savoir que ce qu’est la ligne de base avant de comprendre ce qu’est le test de base.

Techniquement parlant –

Une ligne de base est un document formel qui agit comme un document de base pour le travail futur. En parlant en langage profane, pour faire un bâtiment, vous avez besoin d’une base. La même chose s’applique au test. Nous devons créer une ligne de base, à partir de laquelle les tests ultérieurs sont effectués. Tout d’abord, il est très important de savoir qu’il s’agit d’un test non fonctionnel, ce qui signifie qu’il n’a rien à voir avec le test de la fonctionnalité d’une application. Il s’agit plutôt d’un test du document qui établit une base solide pour le travail à effectuer à l’avenir. On peut donc dire qu’il sert de base au développement futur, quel qu’il soit. Il peut s’agir de la performance, du développement de cas de test.

Parler en termes de test de performance –

Si on voit que la performance de l’application d’un serveur particulier avec une charge de 100 utilisateurs, si elle fonctionne bien sur le serveur avec une charge de 100 sans aucune interruption ou lenteur ou panne et après que la performance du serveur diminue drastiquement après qu’une charge de plus de 100 utilisateurs soit appliquée au serveur contenant l’application. Nous pouvons donc dire que la norme pour ce serveur est de 100 utilisateurs. Maintenant, cette norme peut être comparée au serveur standard et la portée future des tests de performance peut être définie.

What Is Baseline Testing In Software

Permettons de comprendre cela avec un autre exemple, supposons que la version 1 a un temps de réponse de 2 secondes, et la version 2 a un temps de réponse de 3 secondes. Maintenant, pour la version 3, le temps de réponse de 2 secondes de la version 2 agit comme base ou ligne de base pour les performances de la version 3. Donc, à partir de maintenant, nous pouvons déduire que la ligne de base est un document auquel on se réfère comme base de comparaison ou de référence pour un travail futur. Il doit y avoir un document auquel on peut se référer comme un document stable finalisé pour un travail futur.

Parler en termes de développement logiciel –

Si nous parlons en termes de développement logiciel, Il y a un document appelé Document de conception. Il peut être un document de bas niveau ou de haut niveau basé sur lequel les travaux de développement commencent. Si nous parlons en termes de test, un document préparé par l’analyste d’affaires qui est en contact avec le client et est responsable de la récupération des exigences du client agit comme un point de référence de contact pour les testeurs pour commencer le processus de développement et de test. L’analyste d’affaires se rend chez le client après avoir pris rendez-vous, prend les exigences et les remplit dans un modèle spécifique. Il discute ensuite de l’exigence avec le responsable de la mission ou le responsable de la gestion du projet pour tester l’exigence et vérifier sa faisabilité. Dans le cas où l’exigence n’est pas claire, il demande au développeur de créer un prototype et s’il est satisfait, il remet le document d’exigence au chef de projet qui prépare la spécification des exigences du logiciel. Un document préparé par un analyste commercial est appelé document d’exigences commerciales, spécification d’exigences fonctionnelles, spécification d’exigences de l’utilisateur, document de conception commerciale ou document commercial, selon la terminologie utilisée par l’organisation. Nous voyons donc ici que le test des exigences est effectué pour finaliser le document d’exigences qui sert de base à la préparation du document de conception ou du plan de projet et du plan de test et constitue la base du développement et du test du logiciel. Ce type de test est appelé test de base. Dans ce type de test, nous vérifions si le document préparé est à la hauteur et répond correctement aux attentes ou, en d’autres termes, nous validons le document et le finalisons.

Une fois le test de base effectué et le document de spécification des exigences logicielles finalisé, nous sommes prêts à aller de l’avant et à commencer le processus de développement et de test. Pour les tests, nous pouvons commencer à préparer des cas de test basés sur les documents d’exigences. Le principal avantage du test de base est que nous pouvons éliminer les erreurs dans les exigences au début du cycle de vie du développement logiciel et supprimer tant de problèmes et d’efforts à un stade ultérieur et nous aider à livrer le projet avec un minimum de reprise et moins d’efforts.

Parler en termes de phase du cycle de vie du développement logiciel –

Comme nous savons que plus de travail dans la phase initiale du cycle de vie du développement logiciel réduit trop d’efforts à un stade ultérieur. Pour comprendre l’importance des tests de base, nous devons avoir une petite compréhension du cycle de vie du développement logiciel. La première phase est une phase d’exigence où l’analyste commercial recueille des informations du client et prépare des documents d’exigence qui sont appelés document d’exigence commerciale ou spécification d’exigence fonctionnelle ou spécification d’exigence d’utilisateur ou document de conception commerciale ou document commercial selon la terminologie utilisée par l’organisation. A partir du document d’exigences, le test du document d’exigences est effectué, ce qui est appelé test de base et l’exigence est finalisée ou nous pouvons dire que l’exigence est gelée. Une fois qu’elle est à la hauteur et qu’elle peut être considérée pour préparer la spécification des exigences du logiciel dans la phase d’analyse. Dans ce document, le chef de projet, le directeur technique ou l’analyste système prépare un plan de projet sur la façon dont le projet sera développé. Sur la base du document SRS, le document de conception comme le document de conception de haut niveau et le document de conception de bas niveau est préparé sur la base duquel une autre phase du cycle de vie du développement logiciel comme le codage, le test et la livraison est faite est réalisée.

Supposons que le test de base n’est pas fait correctement et que le document d’exigences métier n’est pas correctement finalisé, alors le SRS préparé sur la base du document d’exigences métier ne sera pas correct et le document de conception ne sera pas non plus correct et donc toutes les activités de développement et de test ne seront pas conformes aux attentes du client, car il peut y avoir une légère erreur en prenant l’exigence ou l’exigence n’a pas été correctement baseline. A partir de cela, nous pouvons comprendre combien le test de Baseline est important.

Une chose importante est qu’il y a un terme Baseline qui est utilisé dans la gestion de la configuration, bien que la signification soit plus ou moins la même là aussi. Il est lié au versioning du document où la version de base du document est finalisée et la nouvelle version du document est publiée par version d’application logicielle. Mais il y a peu de concept de test de base dans la gestion de la configuration, aussi parce que la version de base de tous les documents, qu’ils soient liés au développement, aux tests, à la conception Web ou à tout autre document préparé en relation avec le développement de logiciels, doit être examinée correctement en termes de formats et de contenu, de sorte que la prochaine version du document est préparée avec moins d’efforts dans un document déjà correctement formaté.

Conclusion:

Nous voyons donc que le test Baseline est d’une importance combien et à moins que et jusqu’à ce que le Document d’exigence ne soit pas correctement validé ou en d’autres termes, si le test Baseline n’est pas fait, il y aura beaucoup de problèmes dans la phase ultérieure et l’utilisation de l’effort sera beaucoup plus dans la résolution des problèmes qui sera juste une perte d’effort et de temps et une nouvelle exigence sera prise et le besoin de passer par toutes les phases du cycle de vie du développement logiciel, afin de résoudre le problème complètement. Donc, nous pouvons dire que le test de base résout de nombreux problèmes à un stade plus précoce, réduit le coût, l’effort et le temps de l’organisation à l’étape ultérieure du cycle de vie du développement logiciel.

⇓ Subscribe Us ⇓

Si vous n’êtes pas un lecteur régulier de ce site Web, alors vous recommande vivement de vous inscrire à notre bulletin d’information électronique gratuit ! !! Inscrivez-vous juste en fournissant votre adresse e-mail ci-dessous:

Happy Testing!!!