Écrivez dans chaque case quelles variables sont soit DEF, P-USE ou C-USE, utilisez des virgules pour séparer les variables s'il y en a plusieurs. Nous verrons la réponse complète en classe.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

puissance(x, y):
  w = abs
(y);
  z = 1
;
  while (w != 0
): 
    z = z*
x;
    w = w-1
;
  
  if y<0
: 
    z = 1/
z;
  return
 z;

Voici le code qui vous est proposé lors d'un code review. Il est supposé classifié en deux populations distinctes des clients pour leur offrir deux versions de votre site web. En tant que personne responsable d'approuvé ou non le code, acceptez-vous ce code ? 

Si oui, pourquoi ? Sinon, pourquoi ? Précisez votre raisonnement.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Returns a random value between low and high 
def my_random
(low, high):
    r = random.uniform(0, 1
)
    r = pow(r, 0.75
)
    return low + (high - low) *
 r
def new_connection
():
    if my_random(0, 100) < 50: # we want to split the userbase in two population to do a statistical test
        return
 FrontendVersionA()
    else
: 
        return
 FrontendVersionB()

Tel que vous l'avez vu en cours, Netflix et de nombreuses compagnies utilisent l'architecture Microservice plutôt que Monolithique pour leur services backend. Dans cet environnement, il tente de contrôler le chaos avec une méthode de test aléatoire : le Chaos Monkey.

Il existe de nombreux types de Monkey. Du latency monkey au doctor monkey, ils ont tous une particularité qui va tester une partie de l'infrastructure afin de valider si elle serait capable de maintenir le service, même lors d'une panne à 3h00 le matin, un samedi.

Cependant, cela soulève une question : pourquoi cet architecture crée-t-elle autant de Chaos et pourquoi la stratégie Chaos Monkey est préféré à d'autre approche dans ce cas là ?

Expliquez votre raisonnement appuyés par 3 exemples clés de problème crées par une architecture en Microservice afin de démontrer que la stratégie Chaos Monkey est la meilleur pour se genre de problème.

Vous pouvez utiliser cet espace pour écrire tout commentaire/hypothèse (le cas échéant) que vous avez pour la question à développement et toutes ses parties.

Maintenant que vous avez défini tous les éléments nécessaires, définissez les cas de tests pour catégorie partition selon le critère Each Choice (EC). Il est attendu pour chaque cas de test la valeur de chaque paramètre ainsi que l'oracle qui permettra la validation du test (opération réussi ou échec). Écrivez vos cas de test ligne par ligne ou dans un tableau.

Dans le code plus haut, on souhaite satisfaire le critère ALL-USE. Combien de DC-PATH sont nécessaire pour satisfaire ALL-USE pour les variable t, distance et direction_dot_plane ?

Combien de C-USE sont présent dans le code ci-haut.

Combien de P-USE sont présent dans le code ci-haut ?

Satisfaire le critère de couverture MC/DC RACC aurait rajouté des tests supplémentaires. Vrai ou Faux ?

Lorsque vous regardez un commit avec Git au travers de votre terminal, il est possible que vous utilisez l'argument "pretty". Par exemple, voici un exemple d'utilisation possible :

1

git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'
 --abbrev-commit 

Au travers du code source de git, on peut retrouver le fichier qui effectue le "format" de sortie dans votre terminale dans le fichier git/pretty.c. Il contient la fonction suivante qui va nous intéresser pour la suite :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

static int is_rfc2047_special(char ch, enum
 rfc2047_type type)
{
	/*
	 * rfc2047, section 4.2:
	 *
	 *    8-bit values which correspond to printable ASCII characters other
	 *    than "=", "?", and "_" (underscore), MAY be represented as those
	 *    characters.  (But see section 5 for restrictions.)  In
	 *    particular, SPACE and TAB MUST NOT be represented as themselves
	 *    within encoded words.
	 */
	/*
	 * rule out non-ASCII characters and non-printable characters (the
	 * non-ASCII check should be redundant as isprint() is not localized
	 * and only knows about ASCII, but be defensive about that)
	 */
	if (non_ascii(ch) || !
isprint(ch))
		return 1
;
	/*
	 * rule out special printable characters (' ' should be the only
	 * whitespace character considered printable, but be defensive and use
	 * isspace())
	 */
	if (isspace(ch) || ch == '=' || ch == '?' || ch == '_'
)
		return 1
;
	/*
	 * rfc2047, section 5.3:
	 *
	 *    As a replacement for a 'word' entity within a 'phrase', for example,
	 *    one that precedes an address in a From, To, or Cc header.  The ABNF
	 *    definition for 'phrase' from RFC 822 thus becomes:
	 *
	 *    phrase = 1*( encoded-word / word )
	 *
	 *    In this case the set of characters that may be used in a "Q"-encoded
	 *    'encoded-word' is restricted to: <upper and lower case ASCII
	 *    letters, decimal digits, "!", "*", "+", "-", "/", "=", and "_"
	 *    (underscore, ASCII 95.)>.  An 'encoded-word' that appears within a
	 *    'phrase' MUST be separated from any adjacent 'word', 'text' or
	 *    'special' by 'linear-white-space'.
	 */
	if (type !=
 RFC2047_ADDRESS)
		return 0
;
	/* '=' and '_' are special cases and have been checked above */
	return !(isalnum(ch) || ch == '!' || ch == '*' || ch == '+' || ch == '-' || ch == '/'
);
}

Pour la fonction ci-dessus :

Combien de test faut-il pour satisfaire la couverture des branches ?  

Combien de test faut-il pour satisfaire la couverture des conditions ?