AccueilMes livresAjouter des livres
Découvrir
LivresAuteursLecteursCritiquesCitationsListesQuizGroupesQuestionsPrix Babelio
Rejoignez Babelio pour découvrir vos prochaines lectures
Citations sur Pratique des tests logiciels - 2e éd. (27)

petitsoleil
petitsoleil   08 février 2015
Le test aux limites améliore le test par partitionnement, mais ne le remplace pas ; en effet, la construction des frontières, opération parfois complexe, est généralement déduite d'une analyse préalable des partitions liées aux domaines de définitions des paramètres.

On notera que le test aux limites permet de détecter simplement et efficacement certains types d'erreurs de réalisation :
- Mauvais opérateur de relation
- Erreur de borne
- Echange de paramètres
- Ajout d'un prédicat qui ferme un ensemble
- Frontière manquante
- Boucles mal réglées, mauvaise gestion des indices de tableau, etc.

Enfin, on notera également qu'une automatisation poussée peut être atteinte aussi bien dans le cadre de tests structurels que de tests fonctionnels.
Commenter  J’apprécie          41
petitsoleil
petitsoleil   04 février 2015
Les défauts recherchés seront des erreurs de codage au sens large :
- Variables utilisées et non initialisées (erreur de codage la plus fréquente)
- Conditions inversées
- Sortie de boucle prématurée
- Absence de code défensif concernant des conditions d'entrée dans le composant non prévues (non-respect de préconditions)
- Utilisation d'un pointeur nul, etc.

Ces erreurs seront découvertes par la présence de défaillances typiques :
- Message d'erreur sorti à tort
- Sortie du composant sur des valeurs non prévues
- Violation mémoire
- Dépassement de capacité de représentation (overflow), etc.

Pour cela on prévoira des tests qui couvrent dans un premier temps les cas nominaux afin de vérifier que le code chargé de traiter le comportement normal du composant est réalisé correctement.
Ensuite, il faudra prévoir des tests pour vérifier que la prise en compte des cas irréguliers est correcte.
Commenter  J’apprécie          30
petitsoleil
petitsoleil   08 février 2015
Différentes stratégies complémentaires peuvent être mises en œuvre pour tester un logiciel.

Chacune se concentre plus particulièrement sur certains objectifs comme la mise en évidence de défauts dans la réalisation, la vérification de la cohérence ou du caractère complet des spécifications, le respect des standards, etc. Chacune déploiera ses propres méthodes et sera supportée par des outils dédiés comme l'aide à l'exécution, l'aide à la collecte de données, la vérification structurelle, etc.

Cependant, toutes ces stratégies partagent un certain nombre de points communs comme l'impossible exhaustivité, la qualité de la réflexion et l'importance des relations humaines dans tous les processus liés au test.
En cela, la formation et l'expérience du testeur sont irremplaçables.
Commenter  J’apprécie          10
petitsoleil
petitsoleil   03 février 2015
L'origine de ces méthodes dites "agiles" est liée à l'évolution permanente de l'environnement technologique et au fait que le client est souvent dans l'incapacité de définir ses besoins de manière précise et exhaustive dès le début du projet.

Le terme "agile" fait ainsi référence à la capacité d'adaptation du logiciel et des équipes aux changements de contexte et aux modifications de spécifications intervenant pendant le processus de développement.

En 2001, 17 personnes mirent ainsi au point le manifeste agile
http://agilemanifesto.org
dont les grandes lignes sont :
- Individus et interactions plutôt que processus et outils
- Développement logiciel plutôt que documentation exhaustive
- Collaboration avec le client plutôt que négociation contractuelle
- Ouverture au changement plutôt que suivi d'un plan rigide
- Ce manifeste s'oppose aux méthodologies dites "lourdes" comme ISO 12207 et le modèle de développement dit "en cascade", ISO 9000.

Grâce aux méthodes agiles, le client est au cœur de son projet et obtient très vite une première mise en production de son logiciel.
Il est ainsi possible d'associer les utilisateurs dès le début du projet.
+ Lire la suite
Commenter  J’apprécie          10
petitsoleil
petitsoleil   03 février 2015
Les méthodes les plus récentes comme les méthodes dites "agiles" ou l'eXtreme Programming insistent à juste titre sur l'importance des tests et sur le développement guidé par les tests, ie le "Test Driven Development".
Commenter  J’apprécie          10
petitsoleil
petitsoleil   08 février 2015
Il faut prendre garder à ne pas confondre comportement incorrect et valeur incorrecte. En effet, le logiciel peut refuser certaines valeurs qui seront des entrées invalides et avoir un comportement correct (généralement lever une exception ou renvoyer une valeur prédéterminée en erreur)
ou avoir un comportement incorrect (ne pas se rendre compte que la valeur est invalide).

De même, pour une valeur valide le composant peut avoir un comportement correct (il fait ce que l'on attend de lui) ou incorrect (il contient un défaut).
Commenter  J’apprécie          00
petitsoleil
petitsoleil   08 février 2015
Par définition, dans le contexte des tests Boîte noire ou "fonctionnel", une classe d'équivalence est un ensemble de valeurs pour lesquelles on ne peut distinguer le comportement du logiciel. En d'autres termes, quelle que soit la valeur choisie dans une classe d'équivalence, le logiciel aura le même comportement. Ce comportement sera par ailleurs soit correct soit incorrect.

Cette hypothèse de comportement identique pour toutes les valeurs d'une classe d'équivalence permet de réduire drastiquement le nombre de valeurs à utiliser : une seule valeur est suffisante par classe d'équivalence. Si cette valeur ne conduit pas à une exécution incorrecte, alors il en est de même pour toutes les valeurs de la classe. Si au contraire, une erreur de comportement doit survenir, n'importe quelle valeur permettra de la mettre au jour.
Commenter  J’apprécie          00
petitsoleil
petitsoleil   08 février 2015
Considérons le problème suivant : "Comment tester efficacement un composant logiciel qui génère des scripts utilisés pour valider le comportement de serveurs web". Ce composant prend quatre paramètres en entrée (...)
- Le type du poste client (...)
- Le type du navigateur client (...)
- Le type de données téléchargées (...)
- Le fait d'utiliser une connexion sécurisée ou non (...)

Dans cet exemple, il est possible d'énumérer toutes les combinaisons possibles des valeurs de paramètres en entrée et de réaliser ainsi un test exhaustif du composant [ce qui est rare, comme le rappelle souvent l'auteur du livre]. Cela a cependant un coût. Dans notre exemple, il faudrait réaliser
5 * 3 * 4 * 2 = 120 tests différents. (...)

Cette technique [énoncée plus haut, et nommée "all singles", on utilise au moins une fois chaque valeur de chaque paramètre]
permet de réduire très fortement le nombre de jeux de tests à considérer tout en maintenant une certaine qualité : toute valeur d'un paramètre est testée au moins une fois ; un oubli de réalisation ou une grosse erreur seront ainsi facilement détectés. Néanmoins, dès que les erreurs dépendront d'une association particulière de paramètres, ce genre de stratégie ne marchera pas mieux qu'une stratégie purement basée sur le hasard. (...)

Si l'on veut obtenir la garantie de tester toutes ces possibilités sans retomber dans l'énumération totale des valeurs possibles en entrée, il nous faut utiliser une stratégie intermédiaire, comme la stratégie dite "all pairs".
Cette stratégie vise à construire des jeux de tests de telle sorte que toutes les paires de possibilités soient couvertes au moins par un jeu de tests.
Dans notre exemple, il faudra que tous les couples (système/navigateur), (système/type de fichier) et (navigateur/type de fichier) apparaissent au moins une fois dans les jeux de tests.

Cette technique [all pairs] est très efficace, simple à mettre en œuvre et produit des documents de test facilement réutilisables. (...) Malheureusement, elle ne peut pas s'appliquer à tout type de composant logiciel. En effet, la plupart des paramètres prennent leurs valeurs dans des ensembles de cardinal très élevé.
+ Lire la suite
Commenter  J’apprécie          00
petitsoleil
petitsoleil   08 février 2015
Les techniques statiques n'exécutent pas le logiciel à tester et, de ce point de vue, ne sont pas comparables aux techniques dynamiques. Ainsi, elles peuvent être employées à toutes les phases du cycle de vie du logiciel.

L'analyse statique va permettre, à l'aide d'un outil, de vérifier automatiquement certaines propriétés d'un logiciel fini ou partiellement fini et de découvrir ainsi certaines erreurs de conception.
Commenter  J’apprécie          00
petitsoleil
petitsoleil   08 février 2015
Le testeur dispose d'une grande panoplie de méthodes et d'outils pour mener à bien sa mission de traque des erreurs.
Son choix sera guidé par un certain nombre de données comme la possibilité ou non d'exécuter le logiciel (chose impossible dans les phases initiales de conception), la possibilité d'accéder au code source du logiciel,
ou encore le type des erreurs recherchées (fonctionnelles, liées aux performances, conformité à des standards, etc.)
Commenter  J’apprécie          00




    Acheter ce livre sur

    FnacAmazonRakutenCulturaMomox

    Autres livres de Jacques Printz (1) Voir plus




    Quiz Voir plus

    Balzac et la petite tailleuse chinoise

    Combien de livres se trouve dans la valise bien ficelé ?

    10
    4 ou 3
    5 ou 6
    pas précisé

    8 questions
    183 lecteurs ont répondu
    Thème : Dai SijieCréer un quiz sur ce livre