Se II Preparation Questions

14 Questions | By DISI_Education | Last updated: Mar 22, 2022 | Total Attempts: 637

Questions

Settings

Create your own Quiz

Questions and Answers

1.

Quali sono i vantaggi e gli svantaggi di git revert rispetto a reset?
2.

Perche' a volte e' opportuno fare git fetch (e poi git merge) invece che git pull per integrare i cambiamenti dal server nel mio codice?
3.

Immaginate a grandi linee una api REST per esse3. come sarebbe strutturata, ad alto livello? scrivete qualche esempio di URL che immaginate
4.

Scrivere i casi di test che mi consentono di raggiungere 100% MCDC coverage per questa funzione. I casi di test sono come coppie di numeri interi, tipo (0,1). La funzione e' f(a,b) { if (a || b) console.log('a or b') if (a && b) console.log('a and b') }
5.

Quando e' opportuno fare un git commit?
- A.
  
  A intervalli regolari, ad esempio, ogni ora
- B.
  
  Quando ho completato un insieme di modifiche (nuova feature, o un bug fix)
- C.
  
  Quando ho portato il mio codice a un punto al quale voglio poter tornare, se serve
- D.
  
  Quando devo interrompere il lavoro (ad esempio, la sera)
6.

State lavorando ad una feature e state modificando il file app.js sulla branch master. Avete cominciato ma non ancora completato le modifiche. Il vostro collega vi chiede di sospendere il vostro lavoro e sistemare un bug nel codice presente nella master branch (probabilmente proprio nel file app.js). Come gestite il vostro codice e la vostra directory?
- A.
  
  Senza fare commit, fate git branch somebugfix seguito da checkout di somebugfix, rimuovete il bug per poi fare merge su master
- B.
  
  Fate add e commit per non perdere il lavoro parziale fatto sulla feature e poi fate git branch somebugfix seguito da checkout di somebugfix, risolvete il bug e fate merge su master. dopo di che finite il lavoro sulla feature
- C.
  
  Fate un git reset --HARD per tornare al commit precedente, sistemate il bug e fate commit
- D.
  
  Fate git stash, lavorate sul bug (in una branch separata) e fate commit
7.

Quali fra questi NON e' di norma un obiettivo del software testing?
- A.
  
  Trovare bugs nel software.
- B.
  
  Aiutare a stabilire se il software e' pronto per una release
- C.
  
  Accertarsi che il software non contiene bugs
8.

Quali fra queste affermazioni su equivalence partitioning sono corrette?
- A.
  
  Divide lo spazio di dati in input in partizioni, in modo tale che un elemento di una partizione sia rappresentativo, dal punto di vista del testing, di tutta la partizione
- B.
  
  Per un testing accurato non posso avere meno di tre classi di equivalenza
- C.
  
  I test cases devono includere almeno quattro valori per ogni equivalence partition
9.

Quali di queste affermazioni su REST sono vere:
- A.
  
  Lo stile REST richiede esplicitamente che i dati vengano trasferiti in notazione JSON
- B.
  
  Lo stile REST richiede che le API siano esposte con verbi (ad esempio, [baseURL]/calcolaCostoTotale)
- C.
  
  Le applicazioni esposte con lo stile REST tengono lo stato nei clients o nelle resources
10.

Qual e' lo scopo del daily scrum meeting?
- A.
  
  Pianificare il lavoro della giornata
- B.
  
  Rivedere i bugs introdotti nel codice e cercare di risolverli
- C.
  
  Capire dove la sprint precedente ha sbagliato e quindi cosa possiamo migliorare
- D.
  
  Discutere le storie da inserire nella sprint
11.

Considerate questa funzione javascript function f (a,b) { if (a) { console.log('0') if (a && b) { console.log('1') } } else if (b==5) { console.log('2') } console.log('3') } e considerate questi casi di test: f(false,true) f(true,true) f(false,5) f(true) qual e' la path coverage?
- A.
  
  25%
- B.
  
  50%
- C.
  
  75%
- D.
  
  80%
- E.
  
  100%
12.

Considerate questa funzione javascript function g (a,b) { if (a) { console.log('0') if (b) { console.log('1') } } if (b==5) { console.log('2') } console.log('3') } e considerate questi casi di test: g(true,true) g (false,5) g(false,false) qual e' la branch coverage?
- A.
  
  3/6
- B.
  
  4/6
- C.
  
  5/6
- D.
  
  6/6 (100%)
13.

State lavorando ad una feature e state modificando il file app.js sulla branch master. Avete cominciato ma non ancora completato le modifiche. Il vostro collega vi chiede di sospendere il vostro lavoro e sistemare un bug nel codice presente nella master branch (probabilmente proprio nel file app.js). Come gestite il vostro codice e la vostra directory?
- A.
  
  Senza fare commit, fate git branch somebugfix seguito da checkout di somebugfix, rimuovete il bug per poi fare merge su master
- B.
  
  Fate add e commit per non perdere il lavoro parziale fatto sulla feature e poi fate git branch somebugfix seguito da checkout di somebugfix, risolvete il bug e fate merge su master. dopo di che finite il lavoro sulla feature
- C.
  
  Fate un git reset --HARD per tornare al commit precedente, sistemate il bug e fate commit
- D.
  
  Fate git stash, lavorate sul bug e fate commit
14.

Il vostro servizio trentomovies.com offre una API che consente agli utenti di ottenere informazioni su cinema, film, orari. In uno stile architetturale REST, come esponete la funzionalita' di richiesta di informazioni sul cinema astra
- A.
  
  Https://trentomovies.com/getCinemaInfo?cinema=astra
- B.
  
  Https://trentomovies.com/cinemas/astra
- C.
  
  Https://trentomovies.com/cinemas?cinema=astra
- D.
  
  Https://trentomovies.com?cinema=astra usando una http GET
- E.
  
  Https://trentomovies.com?cinema=astra usando una http POST