mirror of
https://github.com/appinfosapienza/so-un-bot.git
synced 2025-05-07 09:39:37 +02:00
Adapt to new bot structure
This commit is contained in:
parent
ff7e08ada9
commit
3f84e1d831
3414 changed files with 41525 additions and 709 deletions
|
|
@ -1 +0,0 @@
|
|||
(a=100, b=false, c=true), (a=90, b=true, c=false)
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
Una Condition è una proposizione booleana, cioè una espressione con valore booleano che non può essere decomposta in espressioni boolean più semplici. Ad esempio, (x + y <= 3) è una condition.
|
||||
|
||||
Una Decision è una espressione booleana composta da conditions e zero o più operatori booleani. Ad esempio, sono decisions:
|
||||
(x + y <= 3)
|
||||
((x + y <= 3) || (x - y > 7))
|
||||
|
||||
Un insieme di test T soddisfa il criterio di Condition/Decision coverage se tutte le seguenti condizioni sono soddisfatte:
|
||||
|
||||
1) Ciascun punto di entrata ed uscita nel programma è eseguito in almeno un test;
|
||||
2) Per ogni decision d nel programma, per ogni condition c in d, esiste un test in T in cui c è true ed un test in T in cui c è false.
|
||||
3) Per ogni decision d nel programma, esiste in test in T in cui d è true ed un test in T in cui d è false.
|
||||
|
||||
Si consideri la seguente funzione:
|
||||
|
||||
int f(int a, bool b, bool c)
|
||||
{ if ( (a == 100) && (b || c) )
|
||||
{ return (1); }
|
||||
else { return (2);}
|
||||
}
|
||||
Quale dei seguenti test set soddisfa il criterio della Condition/Decision coverage?
|
||||
|
|
@ -1 +0,0 @@
|
|||
(a=100, b=false, c=false), (a=90, b=true, c=true)
|
||||
|
|
@ -1 +0,0 @@
|
|||
(a=100, b=false, c=true), (a=90, b=false, c=true)
|
||||
|
|
@ -1 +0,0 @@
|
|||
50%
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
Il branch coverage di un insieme di test cases è la percentuale di branch del programma che sono attraversati da almeno un test case.
|
||||
|
||||
Si consideri il seguente programma C:
|
||||
|
||||
-----------
|
||||
|
||||
#include <stdio.h>
|
||||
|
||||
#include <stdlib.h>
|
||||
|
||||
#include <assert.h>
|
||||
|
||||
#define N 4 /* number of test cases */
|
||||
|
||||
|
||||
|
||||
int f(int x1, int x2)
|
||||
|
||||
{
|
||||
|
||||
if (x1 + x2 <= 2)
|
||||
|
||||
return (1);
|
||||
|
||||
else return (2);
|
||||
|
||||
}
|
||||
|
||||
|
||||
|
||||
int main() { int i, y; int x1[N], x2[N];
|
||||
|
||||
// define test cases
|
||||
|
||||
x1[0] = 5; x2[0] = -2; x1[1] = 6; x2[1] = -3; x1[2] = 7; x2[2] = -4; x1[3] = 8; x2[3] = -5;
|
||||
|
||||
// testing
|
||||
|
||||
for (i = 0; i < N; i++) {
|
||||
|
||||
y = f(x1[i], x2[i]); // function under testing
|
||||
|
||||
assert(y ==(x1[i], x2[i] <= 2) ? 1 : 2); // oracle
|
||||
|
||||
}
|
||||
|
||||
printf("All %d test cases passed\n", N);
|
||||
|
||||
return (0);
|
||||
|
||||
}
|
||||
|
||||
-----------
|
||||
|
||||
Il programma main() sopra realizza il nostro testing per la funzione f1(). I test cases sono i valori in x1[i] ed x2[i].
|
||||
|
||||
Quale delle seguenti è la branch coverage conseguita?
|
||||
|
|
@ -1 +0,0 @@
|
|||
80%
|
||||
|
|
@ -1 +0,0 @@
|
|||
100%
|
||||
|
|
@ -1 +0,0 @@
|
|||
100%
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
Il partition coverage di un insieme di test cases è la percentuale di elementi della partition inclusi nei test cases. La partition è una partizione finita dell'insieme di input della funzione che si sta testando.
|
||||
|
||||
Si consideri il seguente programma C:
|
||||
|
||||
-----------
|
||||
|
||||
#include <stdio.h>
|
||||
|
||||
#include <stdlib.h>
|
||||
|
||||
#include <assert.h>
|
||||
|
||||
#define N 5 /* number of test cases */
|
||||
|
||||
int f1(int x) { return (2*x); }
|
||||
|
||||
int main() { int i, y; int x[N];
|
||||
|
||||
// define test cases
|
||||
|
||||
x[0] = 0; x[1] = 1; x[2] = -1; x[3] = 10; x[4] = -10;
|
||||
|
||||
// testing
|
||||
|
||||
for (i = 0; i < N; i++) {
|
||||
|
||||
y = f1(x[i]); // function under testing
|
||||
|
||||
assert(y == 2*x[i]); // oracle
|
||||
|
||||
}
|
||||
|
||||
printf("All %d test cases passed\n", N);
|
||||
|
||||
return (0);
|
||||
|
||||
}
|
||||
|
||||
Si vuole testare la funzione f1(). A tal fine l'insieme degli interi viene partizionato come segue:
|
||||
|
||||
{0, {-1}, {1}, {tutti glli interi negativi diversi da -1}, {tutti glli interi positivi diversi da 1}}
|
||||
|
||||
Il programma main() sopra realizza il nostro testing per la funzione f1(). I test cases sono i valori in x[i].
|
||||
|
||||
Quale delle seguenti è la partition coverage conseguita?
|
||||
|
|
@ -1 +0,0 @@
|
|||
80%
|
||||
|
|
@ -1 +0,0 @@
|
|||
50%
|
||||
|
|
@ -1 +0,0 @@
|
|||
(a=100, b=true, c=false), (a=90, b=false, c=true), (a=90, b=false, c=false)
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
Una Condition è una proposizione booleana, cioè una espressione con valore booleano che non può essere decomposta in espressioni boolean più semplici. Ad esempio, (x + y <= 3) è una condition.
|
||||
|
||||
Una Decision è una espressione booleana composta da conditions e zero o più operatori booleani. Ad esempio, sono decisions:
|
||||
(x + y <= 3)
|
||||
((x + y <= 3) || (x - y > 7))
|
||||
|
||||
Un insieme di test T soddisfa il criterio di Condition/Decision coverage se tutte le seguenti condizioni sono soddisfatte:
|
||||
|
||||
1) Ciascun punto di entrata ed uscita nel programma è eseguito in almeno un test;
|
||||
2) Per ogni decision d nel programma, per ogni condition c in d, esiste un test in T in cui c è true ed un test in T in cui c è false.
|
||||
3) Per ogni decision d nel programma, esiste in test in T in cui d è true ed un test in T in cui d è false.
|
||||
|
||||
Si consideri la seguente funzione:
|
||||
|
||||
int f(int a, bool b, bool c)
|
||||
{ if ( (a == 100) && b )
|
||||
return (1); // punto di uscita 1
|
||||
else if (b || c)
|
||||
then return (2); // punto di uscita 2
|
||||
else return (3); // punto di uscita 3
|
||||
}
|
||||
Quale dei seguenti test set soddisfa il criterio della Condition/Decision coverage?
|
||||
|
|
@ -1 +0,0 @@
|
|||
(a=100, b=true, c=false), (a=90, b=false, c=true), (a=100, b=true, c=true)
|
||||
|
|
@ -1 +0,0 @@
|
|||
(a=100, b=true, c=false), (a=90, b=false, c=false), (a=100, b=false, c=false)
|
||||
|
|
@ -1 +0,0 @@
|
|||
Customers should be closely involved throughout the development process.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Which of the following is an agile principle?
|
||||
|
|
@ -1 +0,0 @@
|
|||
Customers should just provide requirements and verify them when the project is completed.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Customers should not interfere with the software development.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Testing interfaces for each component (i.e., integration of several units).
|
||||
|
|
@ -1 +0,0 @@
|
|||
Component testing focuses on:
|
||||
|
|
@ -1 +0,0 @@
|
|||
Testing interactions among components (i.e., integration of several units).
|
||||
|
|
@ -1 +0,0 @@
|
|||
Testing functionalities of individual program units, object classes or methods.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Assicurarsi che un sistema che soddisfa i requisiti risolve il problema del "customer".
|
||||
|
|
@ -1 +0,0 @@
|
|||
Quale delle seguenti frasi meglio descrive l'obiettivo del "validity check" che è parte della "requirements validation activity".
|
||||
|
|
@ -1 +0,0 @@
|
|||
Assicurarsi che i requisiti funzionali descrivano tutte le funzionalità del sistema.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Assicurarsi che non ci siano requisiti in conflitto con altri requisiti.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Transition coverage: 40%
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
img=https://unspectacular-subdi.000webhostapp.com/0120_domanda_0.png
|
||||
La transition coverage di un insieme di test cases (cioè sequenze di inputs) per uno state diagram è la percentuale di transizioni (archi nel grafo dello state diagram) percorsi almeno una volta.
|
||||
Si consideri lo state diagram in figura
|
||||
|
||||
|
||||
|
||||
ed il seguente insieme di test cases:
|
||||
Test case 1: act2 act1
|
||||
Test case 2: act1 act0 act1 act0 act2
|
||||
Test case 3: act0 act2 act2 act1
|
||||
Quale delle seguenti è la migliore stima della transition coverage per i test cases di cui sopra?
|
||||
|
|
@ -1 +0,0 @@
|
|||
Transition coverage: 30%
|
||||
|
|
@ -1 +0,0 @@
|
|||
Transition coverage: 80%
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
<pre>
|
||||
class Monitor
|
||||
|
||||
InputReal x, y; // plant output
|
||||
OutputBoolean wy;
|
||||
|
||||
Boolean wz;
|
||||
initial equation
|
||||
wy = false;
|
||||
equation
|
||||
wz = (time > 10) and (x >= 10) and (x <= 20) and ((y <pre 0.5*x) or (y > 0.7*x)) ;
|
||||
algorithm
|
||||
when edge(wz) then
|
||||
wy := true;
|
||||
end when;
|
||||
end Monitor;
|
||||
</pre>
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
Si consideri il seguente requisito:
|
||||
RQ: Dopo 10 unità di tempo dall'inizio dell'esecuzione vale la seguente proprietà: se la variabile x è nell'intervallo [10, 20] allora la variabile y è compresa tra il 50% di x ed il 70% di x.
|
||||
Quale dei seguenti monitor meglio descrive il requisito RQ ?
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
<pre>
|
||||
class Monitor
|
||||
|
||||
InputReal x, y; // plant output
|
||||
OutputBoolean wy;
|
||||
|
||||
Boolean wz;
|
||||
initial equation
|
||||
wy = false;
|
||||
equation
|
||||
wz = (time > 10) and ((x < 10) or (x > 20)) and ((y < 0.5*x) or (y > 0.7*x)) ;
|
||||
algorithm
|
||||
when edge(wz) then
|
||||
wy := true;
|
||||
end when;
|
||||
end Monitor;
|
||||
</pre>
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
<pre>
|
||||
class Monitor
|
||||
|
||||
InputReal x, y; // plant output
|
||||
OutputBoolean wy;
|
||||
|
||||
Boolean wz;
|
||||
initial equation
|
||||
wy = false;
|
||||
equation
|
||||
wz = (time > 10) and (x >= 10) and (x <= 20) and (y >= 0.5*x) and (y <= 0.7*x) ;
|
||||
algorithm
|
||||
when edge(wz) then
|
||||
wy := true;
|
||||
end when;
|
||||
end Monitor;
|
||||
</pre>
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
<pre>
|
||||
class Monitor
|
||||
|
||||
InputReal x, y, z; // plant output
|
||||
OutputBoolean wy;
|
||||
Boolean wz;
|
||||
initial equation
|
||||
wy = false;
|
||||
equation
|
||||
wz = (time > 50) and (x < 0.6*y) and (x + y <= 0.3*z);
|
||||
algorithm
|
||||
when edge(wz) then
|
||||
wy := true;
|
||||
end when;
|
||||
end Monitor;
|
||||
</pre>
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
Si consideri il seguente requisito:
|
||||
RQ: Dopo 50 unità di tempo dall'inizio dell'esecuzione vale la seguente proprietà:
|
||||
se la variabile x è minore del 60% della variabile y allora la somma di x ed y è maggiore del 30% della variabile z
|
||||
Quale dei seguenti monitor meglio descrive il requisito RQ ?
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
<pre>
|
||||
class Monitor
|
||||
|
||||
InputReal x, y, z; // plant output
|
||||
OutputBoolean wy;
|
||||
Boolean wz;
|
||||
initial equation
|
||||
wy = false;
|
||||
equation
|
||||
wz = (time > 50) and (x >= 0.6*y) and (x + y <= 0.3*z);
|
||||
algorithm
|
||||
when edge(wz) then
|
||||
wy := true;
|
||||
end when;
|
||||
end Monitor;
|
||||
</pre>
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
<pre>
|
||||
class Monitor
|
||||
|
||||
InputReal x, y, z; // plant output
|
||||
OutputBoolean wy;
|
||||
Boolean wz;
|
||||
initial equation
|
||||
wy = false;
|
||||
equation
|
||||
wz = (time > 50) and (x < 0.6*y) and (x + y > 0.3*z);
|
||||
algorithm
|
||||
when edge(wz) then
|
||||
wy := true;
|
||||
end when;
|
||||
end Monitor;
|
||||
</pre>
|
||||
|
|
@ -1 +0,0 @@
|
|||
Per ciascun requisito, dovremmo essere in grado di scrivere un inseme di test che può dimostrare che il sistema sviluppato soddisfa il requisito considerato.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Quale delle seguenti frasi meglio descrive il criterio di "requirements verifiability" che è parte della "requirements validation activity".
|
||||
|
|
@ -1 +0,0 @@
|
|||
Per ciascuna coppia di componenti, dovremmo essere in grado di scrivere un insieme di test che può dimostrare che l'interazione tra le componenti soddisfa tutti i requisiti di interfaccia.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Per ciascuna componente del sistema, dovremmo essere in grado di scrivere un insieme di test che può dimostrare che essa soddisfa tutti i requisiti.
|
||||
|
|
@ -1 +0,0 @@
|
|||
c(0)/(1 - p)
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
img=https://unspectacular-subdi.000webhostapp.com/0120_domanda_12.png
|
||||
Si consideri il processo software con due fasi (0 ed 1) rappresentato con la Markov chain in figura. Lo stato iniziale 0 e p è in (0, 1). Il costo dello stato (fase) x è c(x). La fase 0 è la fase di design, che ha probabilità p di dover essere ripetuta causa errori. La fase 1 rappreenta il completamento del processo software, e quindi c(1) = 0.
|
||||
Il costo di una istanza del processo software descritto sopra è la somma dei costi degli stati attraversati (tenendo presente che si parte sempre dallo stato 0.
|
||||
Quindi il costo C(X) della sequenza di stati X = x(0), x(1), x(2), .... è C(X) = c(x(0)) + c(x(1)) + c(x(2)) + ...
|
||||
Ad esempio se X = 0, 1 abbiamo C(X) = c(0) + c(1) = c(0) (poichè c(1) = 0).
|
||||
Quale delle seguenti formule calcola il valore atteso del costo per completare il processo software di cui sopra
|
||||
|
|
@ -1 +0,0 @@
|
|||
c(0)*(1 - p)/p
|
||||
|
|
@ -1 +0,0 @@
|
|||
c(0)/(p*(1 - p))
|
||||
|
|
@ -1 +0,0 @@
|
|||
F(x, y, z) = if (x > y) then (z == x) else (z == y + 1)
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
Un test oracle per un programma P è una funzione booleana che ha come inputs gli inputs ed outputs di P e ritorna true se e solo se il valore di output di P (con i dati inputs) è quello atteso dalle specifiche.
|
||||
Si consideri la seguente funzione C:
|
||||
-----------
|
||||
int f(int x, int y) {
|
||||
int z = x;
|
||||
while ( (x <= z) && (z <= y) ) { z = z + 1; }
|
||||
return (z);
|
||||
}
|
||||
Siano x, y, gli inputs del programma (f nel nostro caso) e z l'output. Assumendo il programma corretto, quale delle seguenti funzioni booleane F(x, y, z) è un test oracle per la funzione f.
|
||||
|
|
@ -1 +0,0 @@
|
|||
F(x, y, z) = if (x > y) then (z == x + 1) else (z == y + 1)
|
||||
|
|
@ -1 +0,0 @@
|
|||
F(x, y, z) = (z == y + 1)
|
||||
|
|
@ -1 +0,0 @@
|
|||
{x = -150, x = -40, x = 0, x = 200, x = 600}
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
Il partition coverage di un insieme di test cases è la percentuale di elementi della partition inclusi nei test cases. La partition è una partizione finita dell'insieme di input della funzione che si sta testando.
|
||||
Si consideri la seguente funzione C:
|
||||
int f1(int x) { return (x + 7); }
|
||||
Si vuole testare la funzione f1(). A tal fine l'insieme degli interi viene partizionato come segue:
|
||||
{(-inf, -101], [-100, -1], {0}, [1, 500], [501, +inf)}
|
||||
Quale dei seguenti test cases consegue una partition coverage del 100% ?
|
||||
|
|
@ -1 +0,0 @@
|
|||
{x = -200, x = -150, x = 0, x = 100, x = 700}
|
||||
|
|
@ -1 +0,0 @@
|
|||
{x = -200, x = -50, x = 0, x = 100, x = 500}
|
||||
|
|
@ -1 +0,0 @@
|
|||
Assicurarsi che un sistema che soddisfa i requisiti risolve il problema del "customer".
|
||||
|
|
@ -1 +0,0 @@
|
|||
Quale delle seguenti frasi meglio descrive l'obiettivo del "validity check" che è parte della "requirements validation activity".
|
||||
|
|
@ -1 +0,0 @@
|
|||
Assicurarsi che i requisiti funzionali descrivano tutte le funzionalità del sistema.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Assicurarsi che non ci siano requisiti in conflitto con altri requisiti.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Requisito funzionale.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
"Ogni giorno, per ciascuna clinica, il sistema genererà una lista dei pazienti che hanno un appuntamento quel giorno."
|
||||
La frase precedente è un esempio di:
|
||||
|
|
@ -1 +0,0 @@
|
|||
Requisito non-funzionale.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Requisito di performance.
|
||||
|
|
@ -1 +0,0 @@
|
|||
0.12
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
img=https://unspectacular-subdi.000webhostapp.com/0120_domanda_17.png
|
||||
Un processo software può essere rappesentato con uno state diagram in cui gli stati rappresentano le fasi (e loro iterazioni) del prcoesso software e gli archi le transizioni da una fase all'altra. Gli archi sono etichettati con le probabilità della transizione e gli stati sono etichettati con il costo per lasciare lo stato.
|
||||
Ad esempio lo state diagram in figura
|
||||
|
||||
|
||||
|
||||
Rappresenta un processo software con 2 fasi F1 ed F2. F1 ha costo 10000 EUR ed F2 ha costo 1000 EUR. F1 ha una probabilita dello 0.4 di dover essere ripetuta (a causa di errori) ed F2 ha una probabilità 0.2 di dover essere ripetuta (a causa di errori).
|
||||
Uno scenario è una sequenza di stati.
|
||||
Qual'e' la probabilità dello scenario: 1, 3, 4? In altri terminti, qual'è la probabilità che non sia necessario ripetere la seconda fase (ma non la prima) ?
|
||||
|
|
@ -1 +0,0 @@
|
|||
0.08
|
||||
|
|
@ -1 +0,0 @@
|
|||
0.32
|
||||
|
|
@ -1 +0,0 @@
|
|||
100%
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
Il branch coverage di un insieme di test cases è la percentuale di branch del programma che sono attraversati da almeno un test case.
|
||||
Si consideri la seguente funzione C:
|
||||
-----------
|
||||
int f(int x, int y) {
|
||||
if (x - y - 2 <= 0) { if (x + y - 1 >= 0) return (1); else return (2); }
|
||||
else {if (x + 2*y - 5 >= 0) return (3); else return (4); }
|
||||
} /* f() */
|
||||
Si considerino i seguenti test cases: {x=1, y=2}, {x=0, y=0}, {x=5, y=0}, {x=3, y=0}.
|
||||
Quale delle seguenti è la branch coverage conseguita?
|
||||
|
|
@ -1 +0,0 @@
|
|||
80%
|
||||
|
|
@ -1 +0,0 @@
|
|||
50%
|
||||
|
|
@ -1 +0,0 @@
|
|||
Accertarsi che i requisiti definiscano un sistema che risolve il problema che l'utente pianifica di risolvere.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Quali delle seguenti attività è parte del processo di validazione dei requisiti ?
|
||||
|
|
@ -1 +0,0 @@
|
|||
Accertarsi che il sistema soddisfi i requisiti dati.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Accertarsi che l'architettura del sistema soddisfi i requisiti dati.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Transition coverage: 35%
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
img=https://unspectacular-subdi.000webhostapp.com/0120_domanda_2.png
|
||||
La transition coverage di un insieme di test cases (cioè sequenze di inputs) per uno state diagram è la percentuale di transizioni (archi nel grafo dello state diagram) percorsi almeno una volta.
|
||||
Si consideri lo state diagram in figura
|
||||
|
||||
|
||||
|
||||
ed il seguente insieme di test cases:
|
||||
Test case 1: act1 act0 act1 act0 act2
|
||||
Test case 2: act0 act2 act2 act0 act1
|
||||
Test case 3: act0 act0
|
||||
Quale delle seguenti è la migliore stima della transition coverage per i test cases di cui sopra?
|
||||
|
|
@ -1 +0,0 @@
|
|||
Transition coverage: 60%
|
||||
|
|
@ -1 +0,0 @@
|
|||
Transition coverage: 80%
|
||||
|
|
@ -1 +0,0 @@
|
|||
Test set: {x=1, y=1}, {x=0, y=0}, {x=2, y=1}, {x=2, y=0}.
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
Il branch coverage di un insieme di test cases è la percentuale di branch del programma che sono attraversati da almeno un test case.
|
||||
Si consideri la seguente funzione C:
|
||||
-----------
|
||||
int f(int x, int y) {
|
||||
if (x - y <= 0) { if (x + y - 1 >= 0) return (1); else return (2); }
|
||||
else {if (2*x + y - 5 >= 0) return (3); else return (4); }
|
||||
} /* f() */
|
||||
Quale dei seguenti test sets consegue una branch coverage del 100% ?
|
||||
|
|
@ -1 +0,0 @@
|
|||
Test set: {x=1, y=1}, {x=2, y=2}, {x=2, y=1}, {x=2, y=0}.
|
||||
|
|
@ -1 +0,0 @@
|
|||
Test set: {x=1, y=1}, {x=0, y=0}, {x=2, y=1}, {x=2, y=3}.
|
||||
|
|
@ -1 +0,0 @@
|
|||
1/(1 - p)
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
img=https://unspectacular-subdi.000webhostapp.com/0120_domanda_21.png
|
||||
Si consideri la Markov chain in figura con stato iniziale 0 e p in (0, 1). Quale delle seguenti formule calcola il valore atteso del numero di transizioni necessarie per lasciare lo stato 0.
|
||||
|
|
@ -1 +0,0 @@
|
|||
(1 - p)/p
|
||||
|
|
@ -1 +0,0 @@
|
|||
1/(p*(1 - p))
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
Si consideri il seguente modello Modelica. Quale dei seguenti UML state diagram lo rappresenta correttamente ?
|
||||
block FSA // Finite State Automaton
|
||||
|
||||
/* connector declarations outside this block:
|
||||
connector InputInteger = input Integer;
|
||||
connector OutputInteger = output Integer;
|
||||
*/
|
||||
|
||||
InputInteger u; // external input
|
||||
OutputInteger x; // state
|
||||
parameter Real T = 1;
|
||||
|
||||
algorithm
|
||||
|
||||
when initial() then
|
||||
x := 0;
|
||||
|
||||
elsewhen sample(0,T) then
|
||||
|
||||
if (pre(x) == 1) and (pre(u) == 0) then x := 3;
|
||||
elseif (pre(x) == 1) and (pre(u) == 1) then x := 3;
|
||||
elseif (pre(x) == 1) and (pre(u) == 2) then x := 2;
|
||||
elseif (pre(x) == 2) and (pre(u) == 0) then x := 0;
|
||||
elseif (pre(x) == 2) and (pre(u) == 2) then x := 0;
|
||||
elseif (pre(x) == 3) and (pre(u) == 0) then x := 2;
|
||||
elseif (pre(x) == 4) and (pre(u) == 0) then x := 3;
|
||||
elseif (pre(x) == 4) and (pre(u) == 2) then x := 2;
|
||||
else x := pre(x); // default
|
||||
end if;
|
||||
|
||||
end when;
|
||||
end FSA;
|
||||
|
|
@ -1 +0,0 @@
|
|||
Transition coverage: 50%
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
img=https://unspectacular-subdi.000webhostapp.com/0120_domanda_23.png
|
||||
La transition coverage di un insieme di test cases (cioè sequenze di inputs) per uno state diagram è la percentuale di transizioni (archi nel grafo dello state diagram) percorsi almeno una volta.
|
||||
Si consideri lo state diagram in figura
|
||||
|
||||
|
||||
|
||||
ed il seguente insieme di test cases:
|
||||
Test case 1: act2 act2 act1 act2 act1
|
||||
Test case 2: act1 act0 act2
|
||||
Test case 3: act2 act1 act0
|
||||
Quale delle seguenti è la migliore stima della transition coverage per i test cases di cui sopra?
|
||||
|
|
@ -1 +0,0 @@
|
|||
Transition coverage: 80%
|
||||
|
|
@ -1 +0,0 @@
|
|||
Transition coverage: 30%
|
||||
|
|
@ -1 +0,0 @@
|
|||
100%
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
Il branch coverage di un insieme di test cases è la percentuale di branch del programma che sono attraversati da almeno un test case.
|
||||
Si consideri la seguente funzione C:
|
||||
-----------
|
||||
int f(int x, int y) {
|
||||
if (x - y <= 0) { if (x + y - 2>= 0) return (1); else return (2); }
|
||||
else {if (2*x + y - 1>= 0) return (3); else return (4); }
|
||||
} /* f() */
|
||||
Si considerino i seguenti test cases: {x=1, y=1}, {x=0, y=0}, {x=1, y=0}, {x=0, y=-1}.
|
||||
Quale delle seguenti è la branch coverage conseguita?
|
||||
|
|
@ -1 +0,0 @@
|
|||
80%
|
||||
|
|
@ -1 +0,0 @@
|
|||
50%
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue