Résultats du test en ligne - Hightest
Vous avez bien répondu à 0 question(s) sur 20, soit 0 % de réussite. Il faudrait monter
jusqu'à 65 %. Courage !
Qu'est-ce que le débogage ?
1. Le débogage est l'activité de développement qui consiste à trouver, analyser et
corriger les défauts.
2. Le débogage est l'activité de développement qui consiste à vérifier qu'un défaut a
bien été corrigé, c'est-à-dire qu'il ne provoque plus de défaillances.
3. Le débogage est l'activité de test qui consiste à rechercher les défaillances et à les
compiler dans un outil de test dédié.
4. Le débogage est l'activité de test qui consiste à trier les anomalies des faux positifs.
Solution
Voir chapitre 1.1.2, p. 14.
Vous n'avez pas trouvé cette réponse.
Lors de la phase de conception des spécifications, quelle pratique est la plus
adéquate ?
1. Le testeur n’est pas impliqué dans cette phase
2. Le testeur effectue une revue des spécifications afin de détecter au plus tôt les
points à éclaircir ou à corriger
3. Le testeur rédige une partie des spécifications
4. Le testeur rédige l’intégralité des spécifications
Solution
Il est possible de détecter les anomalies d’une application dès la phase de spécification,
alors que rien n’a encore été implémenté. Corriger les contradictions ou les zones
d’ombre d’une spécification, c’est déjà se prémunir contre des bugs. Voir chapitre 1.4.2,
paragraphe 'Analyse de test'.
Vous n'avez pas trouvé cette réponse.
Un test automatisé est en erreur, pourtant l’application fonctionne correctement.
Comment cela s’appelle-t-il ?
1. Un faux positif
2. Un test non-fonctionnel
3. Un faux négatif
4. Un test automatisé n’est en erreur que si l’application présente une anomalie. En
revanche, l’anomalie décelée par le test automatisé n’est pas toujours celle qui était
anticipée au moment de son implémentation.
Solution
Un test non-fonctionnel valide les aspects du logiciel qui ne sont pas liés à ses
fonctionnalités ; on teste par exemple ses performances, sa réaction aux montées en
charge, au stress… Un faux négatif correspond à un test automatisé qui ne remonte
pas d’erreur alors que le scénario testé génère une anomalie. Voir chapitre 1.2.3,
dernier paragraphe.
Vous n'avez pas trouvé cette réponse.
La vocation des tests fonctionnels dynamiques automatisés est de :
1. Trouver certains défauts du logiciels sans exécuter celui-ci
2. Se prémunir contre les régressions des fonctionnalités entre deux versions du
produit
3. Evaluer automatiquement l'utilisabilité d'une application
4. Mesurer automatiquement les performances d’une application
Solution
Si le logiciel n’est pas exécuté, nous avons affaire à un test statique. Le test fonctionnel
automatisé simule un comportement utilisateur et effectue des vérifications qui touchent
aux fonctionnalités. L'utilisabilité et les performances donnent au contraire lieu à des
tests non-fonctionnels. Pour la différence entre tests statiques et dynamiques, voir
chapitre 3.1.3.
Vous n'avez pas trouvé cette réponse.
Lors de l’exécution d’une campagne de test, les cas de test fournissent une ligne
directrice qu'il faut suivre à la lettre.
1. Vrai. Les cas de test ont été créé de manière à assurer la meilleure couverture des
tests possible, il est essentiel de les suivre attentivement.
2. Faux. S'éloigner des cas de tests permet de couvrir des cas non prévus et ainsi
d'améliorer la couverture des tests.
3. Vrai. Les cas de test couvrent les fonctionnalités indiquées dans la spécification ; il
n'est pas nécessaire de rechercher des anomalies en-dehors de ce périmètre.
4. Faux. Les cas de test sont utilisés non pas lors des campagnes de test, mais lors des
tests de confirmation.
Solution
Voir le chapitre 4.4.2, sur les tests exploratoires.
Vous n'avez pas trouvé cette réponse.
Comment se calcule un risque ?
1. Risque = Impacts en cas d’occurrence / Bénéfices en cas de non-occurrence
2. Risque = Somme de la gravité des impacts possibles
3. Risque = Probabilité d’occurrence x Impact en cas d’occurrence
4. Il n’est pas recommandé de calculer les risques, car le résultat du calcul est
susceptible de créer des biais et d’induire l’équipe de test en erreur.
Solution
Pour calculer le risque, il faut multiplier l’indice d’une échelle de gravité par l’indice de
l’échelle de probabilité. Voir 5.5.
Vous n'avez pas trouvé cette réponse.
Qu’est-ce qu’une partition d’équivalence ?
1. Un comportement similaire pouvant être observés au sein de deux versions
différentes d’un même applicatif.
2. Une plage de données qui, lorsqu’elles sont utilisées dans un même test,
doivent générer le même comportement.
3. La somme de tous les comportements possibles permettant d’effectuer une même
action au sein d’un applicatif donné.
4. Un recueil de règles de nommages applicable au développement d’un applicatif
donné.
Solution
Les partitions d’équivalence sont utiles pour couvrir l’ensemble des catégories d’entrées
d’un logiciel ou d’un système. Par exemple, si un film est interdit aux moins de 12 ans,
on peut distinguer deux partitions d’équivalences (âge >= 12 et âge < 12). Les tarifs
d’entrée dans les établissements culturels donnent souvent lieu à de multiples partitions
d’équivalence. Voir chapitre 4.2.1.
Vous n'avez pas trouvé cette réponse.
Une borne d’achat de tickets de bus interdit le paiement en espèce, sauf si
l’utilisateur lui présente une carte d’abonné activée et non périmée. Quel outil est
tout indiqué pour analyser les différents comportements possibles de
l’application ?
1. Un outil de test management
2. Un graphe d’appel
3. Un diagramme d’états et de transitions
4. Une table de décisions
Solution
Voir chapitre 4.2.3. La table pourra ressembler à celle-ci :
Paiement en espèces Paiement en espèces
Cas
possible impossible
Non abonné X
Abonné, carte non activée X
Abonné, carte périmée X
Abonné, carte non activée et
X
périmée
Abonné, carte activée et non
X
périmée
Vous n'avez pas trouvé cette réponse.
Un test unitaire exécute la fonction suivante avec l’argument $soldes = true.
$theme = 'Imprimé zèbre et or';
function creerPancarteRayon(boolean $soldes){
echo 'Découvrez notre collection sur le thème de
la semaine : '.$theme;
if ($soldes) {
echo '. Les articles de ce rayons sont en soldes
: ils ne seront ni repris, ni échangés.';
}
}
I. La couverture des fonctions de cette portion de code est assurée.
II. La couverture des instructions de cette portion de code est assurée.
III. La couverture des décisions de cette portion de code est assurée.
IV. La couverture des chemins de cette portion de code est assurée.
Quelles propositions listées ci-dessus sont justes ?
1. I et II
2. I et III
3. II et IV
4. III et IV
Solution
Toutes les fonctions (c’est-à-dire une : creerPancarteRayon) ont été testées ; la
couverture des fonctions est donc assurée. Avec l’argument soldes à true, le test
unitaire est amené à exécuter chaque ligne du code ; la couverture des instructions est
donc assurée. En revanche, la couverture des décisions n’est pas assurée, car il
faudrait pour cela tester aussi la fonction avec l’argument soldes à false. A fortiori, la
couverture des chemins n’est pas assurée non plus. Voir chapitre 4.3, et le glossaire du
syllabus.
Vous n'avez pas trouvé cette réponse.
L’indépendance de l’équipe de test vis-à-vis de l’équipe de développement
favorise l’impartialité des tests. Mais elle présente aussi des risques. Lequel n’en
fait pas directement partie ?
1. Risque de voir les développeurs perdre le sens de leur responsabilité vis-à-vis de la
qualité
2. Risque pour l’équipe de test de ne pas être au courant de certains changements
3. Risque pour l’équipe de test de manquer de légitimité auprès du client
4. Risque de créer un goulet d’étranglement au niveau de l’équipe de test
Solution
Les équipes de développement sont parfois susceptibles de se reposer sur l’équipe de
test, estimant qu’il n’est plus de leur ressort d’assurer la qualité de leur application. Il
peut également arriver que l’équipe de test soit si indépendante que la communication
en pâtisse ; dans ce cas, des incompréhensions peuvent ralentir le projet. Enfin, une
équipe de test indépendante peut être amenée à intervenir seulement à la fin du projet,
ce qui constitue un goulet d’étranglement. Manquer de légitimité auprès du client ne
constitue pas un risque directe de l’indépendance du test. Voir chapitre 5.1.1.
Vous n'avez pas trouvé cette réponse.
Tout projet de test est soumis à deux grandes familles de risques. Lesquels ?
1. Les risques techniques et les risques fonctionnels
2. Les risques quantitatifs et les risques qualitatifs
3. Les risques contextuels et les risques permanents
4. Les risques projet et les risques produit
Solution
Les risques liés au projet regroupent des problèmes organisationnels et des problèmes
techniques pouvant impacter négativement le déroulement du projet. Les risques liés au
produit regroupent les défaillances potentielles de l’applicatif à tester. Les tests logiciels
sont destinés à réduire les risques produit. Identifier les risques en amont permet
d’élaborer la stratégie de test la mieux adaptée. Voir 5.5.2.
Vous n'avez pas trouvé cette réponse.
Parmi les activités suivantes, lesquelles peuvent être réalisées de manière
informelle ?
1. Les tests d’acceptation
2. Les revues de code
3. Les inspections
4. Le suivi de l’avancement des tests
Solution
Les tests d’acceptation doivent déterminer si l’applicatif correspond au besoin
initialement exprimé ; ils doivent suivre un processus formel en ce qu’ils engagent une
prise de décision (GO/NO GO). Les inspections sont une technique de test statique qui
se base sur des procédures documentées (par exemple des checklists) pour détecter
les défauts du logiciel. Le suivi de l’avancement des tests donne lieu à des métriques
permettant d’évaluer le temps passé sur les différentes activités de test, le coût des
tests, la quantité de défauts trouvés et corrigés… Dans la liste, seule la revue de code
peut être réalisée de manière informelle. Par exemple, « l’analyse par-dessus l’épaule
», pilotée par l’auteur, permet à un autre développeur de fournir une relecture rapide
des modifications effectuées. Voir chapitre 3.2 sur les processus de revue.
Vous n'avez pas trouvé cette réponse.
Qu’est-ce qu’une exigence non-fonctionnelle ?
1. Une exigence laissée de côté suite à un arbitrage de l’équipe de test
2. Une exigence contredite par d’autres exigences
3. Une exigence ne se rapportant pas aux fonctionnalités
4. Une exigence qui n’impacte pas l’expérience utilisateur
Solution
Une exigence non-fonctionnelle peut se rapporter à des attributs de l’application tels
que sa fiabilité, son rendement, sa performance, son utilisabilité, sa maintenabilité, sa
portabilité… Voir chapitre 2.3.2.
Vous n'avez pas trouvé cette réponse.
L’équipe de développement vient de finaliser le développement d’un site
contenant beaucoup d’animations (carrousel d’images, popups…) Le client
souhaite s’assurer que ce grand nombre d’animation ne ralentit pas trop le
chargement du site. Quel type de test est tout indiqué dans ce cas-là ?
1. Test de montée en charge
2. Test de performance
3. Test de robustesse
4. Test de stress
Solution
Un objectif majeur du test de performance est de mesurer la rapidité de chargement
et/ou d'exécution d'une application. Les autres types de tests cités sont similaires mais
mettent l'accent sur le contexte dans lequel se trouve l'application (charge d'utilisateurs,
données d'entrée erronées...) Pour y voir plus clair, nous vous conseillons cet article sur
la différence entre les tests de performance, de charge et de stress.
Vous n'avez pas trouvé cette réponse.
La qualité est définie comme...
1. le taux de conformité aux standards en vigueur de la réalisation spécifique d'un
composant, système ou processus
2. la mesure relative à la satisfaction exprimée par les clients ou utilisateurs à l'issue de
la conception d'un composant, système ou processus
3. le ratio entre la part des composants, systèmes ou processus exempt d'anomalies et
la totalités de ces objets
4. le degré par lequel un composant, système ou processus atteint des exigences
spécifiées et/ou des besoins ou attentes des clients ou utilisateurs
Solution
La notion de qualité est propre à chaque projet et dépend des besoins des clients et
des utilisateurs finaux. Voir le glossaire du syllabus.
Vous n'avez pas trouvé cette réponse.
Cochez la formulation juste.
1. Un développeur introduit une anomalie dans son code. Cette anomalie est
susceptible de générer une erreur du système.
2. Un développeur introduit un défaut dans son code. Ce défaut est susceptible de
générer une anomalie du système.
3. Un développeur introduit un bug dans son code. Ce bug est susceptible de
générer une défaillance du système.
4. Un développeur introduit une erreur dans son code. Cette erreur est susceptible de
générer un bug du système.
Solution
L'erreur (ou méprise) est la cause de l'introduction d'un défaut, ou bug, ou anomalie,
dans le système. Cette cause peut être une mauvaise compréhension, un moment
d'inattention... Le défaut est ensuite susceptible de générer des défaillances du
système. Voir 1.2.3.
Vous n'avez pas trouvé cette réponse.
Les rapports d'incidents peuvent avoir plusieurs objectifs. Lequel n'en fait pas
partie ?
1. Fournir aux développeurs et aux autres parties un retour sur le problème concerné
pour en permettre l'identification, la localisation et la correction nécessaires
2. Fournir aux responsables du test le moyen de suivre la qualité d'un système sous
test et l'avancement du test
3. Fournir aux chefs de projet des métriques de performance relatives à chaque
développeur
4. Fournir des idées pour l'amélioration du processus de test
Solution
Les rapports d'incident visent à améliorer la qualité du produit et les processus de
développement et de test. Il ne s'agit pas de pointer du doigt le 'coupable' du bug. Voir
1.5.1.
Vous n'avez pas trouvé cette réponse.
Dans quel ordre se déroulent en principe les différents niveaux de tests ?
1. Tests de composants, tests d'intégration, tests système, tests d'acceptation
2. Tests de composants, tests système, tests d'acceptation, tests d'intégration
3. Tests de composants, tests d'acceptation, tests système, tests d'intégration
4. Tests de composants, tests d'acceptation, tests d'intégration, tests système
Solution
Voir 2.2.
Vous n'avez pas trouvé cette réponse.
L'agilité s'oppose-t-elle au test ?
1. Non. L'agilité s'oppose au test manuel mais met l'accent sur les tests automatisés.
2. Non. L'agilité favorise une exécution fréquente des tests afin d'éviter les
régressions d'une itération à l'autre.
3. Non. Une démarche agile se doit de rechercher constamment à améliorer les
processus de développement, donc de tester différentes solutions.
4. Non. C'est l'inverse : ce sont les standards du test qui s'opposent à l'agilité, qui
délaisse la qualité au profit de la rapidité.
Solution
A chaque itération, il est essentiel de s'assurer de la qualité du produit afin d'éviter les
régressions. L'agilité ne s'oppose aucunement au test ! Voir les multiples mentions du
test agile dans le syllabus de niveau Fondation.
Vous n'avez pas trouvé cette réponse.
Quand faut-il commencer à tester ?
1. Dès que le code est suffisamment stable. Le risque, en commençant les tests trop
tôt, est de confondre ce qui est en cours et ce qui contient réellement des défauts.
2. Dès qu'il existe un brouillon de spécification. Des bugs peuvent déjà exister
dans la documentation.
3. Dès le début du développement. C'est ce qu'on appelle le TDD (test driven
development).
4. Dès qu'une version alpha du projet est disponible. Il ne faut pas attendre la version
bêta, car elle est directement déployée chez le client.
Solution
Il est possible de détecter des défauts avant même le début du développement. La
documentation, qui peut être lacunaire, peu claire ou contradictoire, est un objet de test
en tant que tel. Voir chapitre 1.4.2, paragraphe 'Analyse de test'.
Vous n'avez pas trouvé cette réponse.
