Module 3 : Considérations de génie logiciel

Question 1

étape modèle en cascade

Answer 1

spécifier besoin
analyse
conception
implémenter
intégrer
maintenir

Question 2

processus de compilation

Answer 2

pré processeur
compilateur
éditeur de liens

Question 3

Test unitaire ?

Answer 3

Pour s’assurer qu’un composant logiciel se comporte tel que prévu et spécifié.

Teste les cas normaux et les cas anormaux.

Utilise toujours de façon systématique
l’interface publique de la classe.

Question 4

but test unitaire

Answer 4

Première ligne de défense contre les défauts du logiciel.
Permet de détecter toute anomalie le plus tôt possible

Question 5

Mise en œuvre test unitaires

Answer 5

Doit être structuré.
Doit être répétable
Doit fournir un rapport d’exécution extrêmement
simple
Toutes les méthodes publiques de la classe doivent être testées.
Les tests pour chaque méthode doivent être indépendants les uns des autres

Question 6

assertions

Answer 6

déclarations vérifiant si une condition est vraie

Question 7

résultat d’une assertion

Answer 7

success (test réussi),
nonfatal failure (test échoué)
fatal failure (test échoué et arrête la fonction).

Question 8

exemple de code de test

Answer 8

TEST(Pile,ConstructeurVide)
{
Pile unePile; ASSERT_EQ(0,unePile.getCapacite()); ASSERT_TRUE(unePile.estVide());
}

TEST(Pile,ConstructeurCapacite)
{
Pile unePile(25); ASSERT_EQ(25,unePile.getCapacite()); ASSERT_TRUE(unePile.estVide());

Question 9

2 types d’assertions:

Answer 9

EXPECT_* : assertions non-fatales (continue après échec)
ASSERT_* : assertions fatales (arrête le programme)

Question 10

oPrincipales macros:

Answer 10

ASSERT/EXPECT_TRUE/FALSE(condition)
ASSERT/EXPECT_EQ(v1, v2)/_NE()/_LT()/_LE()/_GT()/_GE()
comparaisons entre deux valeurs v1 et v2 (valeurs comparables)

Question 11

Si 2 tests ou plus opèrent sur des données similaires
o les regrouper dans

Answer 11

un test fixture

Question 12

Pour créer un fixture

Answer 12

Dériver la classe de ::testing::Test. Commencer le corps de la classe avec le mot-clé protected ou public pour que son contenu soit accessible par les sous-classes

Déclarer dans la classe tous les objets à utiliser

Si nécessaire, écrire un constructeur par défaut ou une fonction SetUp() pour préparer les objets pour chaque test (Attention! Veiller à bien écrire SetUp() avec un «u» majuscule)

Si nécessaire, écrire un destructeur ou une fonction TearDown() pour libérer la mémoire allouée dans SetUp()

Au besoin, définir les sous-routines partagées par les tests

Question 13

oPour des tests utilisant un fixture, on écrira – au
lieu de –

Answer 13

oPour des tests utilisant un fixture, on écrira TEST_F() au
lieu de TEST()

Question 14

On doit faire un test pour quelles méthodes?

Answer 14

Méthode publique, pourquoi pas les méthodes privées car c’est testé à travers les publiques: on garantit aux utilisateurs de la classe qui vont utiliser les méthode publique. Les méthodes publiques c’est l’interface avec l’utilisateur. Donc les tests unitaires, on se met à la place de l’utilisateur.

Question 15

Quelle mécanique doit-on utiliser pour les tests?

Answer 15

Google test. Test unitaire pour éliminer les effets de bord d’un test à un autre. On teste une chose à la fois. Les tests doivent être indépendants

Question 16

Quel genre de rapport sera fourni à la fin du test?

Answer 16

Rapport simpliste de pass/fail.

Question 17

Un contrat protège les deux parties

Answer 17

Protège le client (dans ce cas ci vous-mêmes)
oSpécifie quelles sont ses obligations.
oEn retour, est assuré d’un certain résultat.

Protège le fournisseur (sous-contractant)
oSpécifie le minimum requis (de la part du client):
le fournisseur ne peut être tenu responsable d’avoir manqué à des engagements ne figurant pas dans le contrat.

Question 18

spécification d’un contrat

Answer 18

Spécification d’une interface
peut être vue comme un contrat entre un client (l’utilisateur du
composant/classe) et un fournisseur (le composant/classe).

Le contrat dit ce qui doit être rencontré par le client
pour pouvoir appeler une opération de l’interface :
précondition.

Le contrat dit aussi ce qui doit être réalisé par le fournisseur
de fait, ce qui est garanti au client
pour rencontrer ce qui est prévu par l’opération
postcondition.

Question 19

Mécanismes pour exprimer ces conditions

Answer 19

assertions
préconditions
postconditions :
assertions s’appliquant à des méthodes en particulier,

invariants de classe :
assertions s’appliquant à toutes les méthodes d’une classe en tout temps.

Question 20

préconditions

Answer 20

conditions devant être remplies avant
d’exécuter une méthode.
Si le contrat n’est pas rempli, la méthode n’a pas à s’exécuter. [Erreur de programmation]

Question 21

postconditions :

Answer 21

conditions devant être remplies après
l’exécution d’une méthode.
Si le contrat n’est pas rempli, la méthode ne doit
pas retourner. [Erreur de programmation]

Question 22

Une spécification plus complète d’une opération offerte par un composant deviendrait

Answer 22

ole nom de l’opération
ole nombre, le type et l’ordre des paramètres
oles préconditions oles postconditions ole type de retour

Question 23

invariant

Answer 23

oreprésente l’ensemble des conditions logiques devant être respectées pour assurer un comportement correct d’une classe.

Question 24

Les invariants doivent donc être respectés (et testés) :

Answer 24

à la fin de tous les constructeurs.
o à la fin de toutes les méthodes non constantes,
i.e. les méthodes qui modifient l’objet

Question 25

règle absolue des précondition et postconditions

Answer 25

osoit on a la condition dans la précondition,
osoit on l’a dans le corps de la méthode,
jamais dans les deux.

Question 26

Les bénéfices des contrats

Answer 26

Les spécifications des services sont claires;

Les contrats offrent un moyen explicite pour documenter et transférer ces spécifications directement dans le code;

Spécifications dans le code
On peut les tester = on peut garantir la fiabilité du code.

L’utilisation des contrats est vitale pour la réutilisation
de composants.

Question 27

Les MACROs pour le contrat

Answer 27

“fonction” définie par un #define.

Remplacement textuel, fait par le préprocesseur.

Dans le fichier ContratException.h,

Définition de ces classes

+ définition des MACROs suivantes:
PRECONDITION(test);
POSTCONDITION(test);
ASSERTION(test);
INVARIANT(test);
INVARIANTS();

Question 28

Implantation du contrat au niveau d’une méthode

Answer 28

Utilisation des MACROs:

oPRECONDITION(«test_logique»);
pour valider les données en entrée.

oPOSTCONDITION(«test_logique»);
pour valider le bon fonctionnement de la méthode avant le retour de celle-ci.

oASSERTION(«test_logique»);
pour valider un état quelconque au milieu de l’algorithmique