AccueilMes livresAjouter des livres
Découvrir
LivresAuteursLecteursCritiquesCitationsListesQuizGroupesQuestionsPrix Babelio
Rejoignez Babelio pour découvrir vos prochaines lectures
ISBN : 210070608X
Éditeur : Dunod (19/03/2014)

Note moyenne : 4/5 (sur 1 notes)
Résumé :
Ce livre s'adresse aux développeurs, concepteurs et intégrateurs de logiciels ainsi qu'aux chefs de projets et aux architectes. Avec la montée en charge du big data, et du cloud computing, la fiabilité des logiciels est plus importante que jamais. Concevoir du premier coup et sans aucune erreur un logiciel qui comporte plusieurs millions de lignes de code et plusieurs centaines de composants est évidemment impossible. La nécessité de faire des tests au cours des dif... >Voir plus
Acheter ce livre sur

FnacAmazonRakutenCulturaMomox
Critiques, Analyses et Avis (1) Ajouter une critique
petitsoleil
  07 novembre 2018
Je recommande fortement ce livre, enfin sa dernière édition puisque les métiers du Test sont récents et en pleine évolution.
La lecture de ce livre (2e édition à l'époque) m'a aidée à préparer une certification ISTQB, que j'ai ensuite obtenue sereinement et avec un très bon score
Depuis, j'ai passé une autre certification et je continue le Test logiciel
Commenter  J’apprécie          150
Citations et extraits (27) Voir plus Ajouter une citation
petitsoleilpetitsoleil   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.
+ Lire la suite
Commenter  J’apprécie          41
petitsoleilpetitsoleil   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.
+ Lire la suite
Commenter  J’apprécie          30
petitsoleilpetitsoleil   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
petitsoleilpetitsoleil   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
petitsoleilpetitsoleil   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.
+ Lire la suite
Commenter  J’apprécie          10
autres livres classés : logicielVoir plus
Acheter ce livre sur

FnacAmazonRakutenCulturaMomox

Autres livres de Jacques Printz (1) Voir plus




Quiz Voir plus

Le livre qu'il n'a pas fait

Lequel de ces livres n'est pas un livre de Saint-Exupéry ?

Vol de nuit
Terre des hommes
Vent de sable
Le Petit Prince

10 questions
63 lecteurs ont répondu
Créer un quiz sur ce livre