Attualmente sto verificando il syllabus per la certificazione ISTQB "Technical Test Analyst". Questo syllabus (d'ora in poi chiamato "TTA syllabus") contiene un capitolo dedicato a "condition testing" (apparentemente questo è anche chiamato "condition coverage" o "condition coverage testing ".)
Test delle condizioni come definito nel programma TTA mi sembra una cosa estremamente strana e probabilmente anacronistica che ha più a che fare con Grandma's Ham Story rispetto ai test del software. Lasciami spiegare ...
Che cos'è il "test delle condizioni" in base al programma TTA?
In riferimento al "Syllabus di livello avanzato - Analista tecnico di test, versione 2012" del ISTQB, disponibile qui , "test delle condizioni" è definito come segue a pagina 12:
Compared to decision (branch) testing, which considers the entire decision as a whole and evaluates the TRUE and FALSE outcomes in separate test cases, condition testing considers how a decision is made. Each decision predicate is made up of one or more simple “atomic” conditions, each of which evaluates to a discrete Boolean value. These are logically combined to determine the final outcome of the decision. Each atomic condition must be evaluated both ways by the test cases to achieve this level of coverage.
Applicability
Condition testing is probably interesting only in the abstract because of the difficulties noted below. Understanding it, however, is necessary to achieving greater levels of coverage that build upon it.
Quindi chiariamo le parole
Supponiamo di avere qualche sotto-test del software su cui vogliamo eseguire test whitebox (cioè abbiamo il codice sorgente). Il codice contiene naturalmente molti di quei predicati decisionali che tutti conosciamo e amiamo e che compaiono dopo stringhe come if , while , until ecc.
Un esempio del predicato decisionale potrebbe essere:
((x>y+z) AND (y<-3)) OR ((z²+x²<4) AND (z≤y))
Questopredicatodidecisioneaccettauntriplo(x,y,z)divaloriinteri(adesempio)erestituisceunvalorebooleano,b_out.
Lefunzionidiprimolivellochemappano(x,y,z)a{TRUE,FALSE}sonochiamatecondizioni(anchecondizioniatomiche)nelprogrammaTTA.
Coperturadeltestdellecondizioni
Siraggiunge"condition testing coverage" eseguendo test case fino a quando tutte le condizioni trovate nella decisione hanno prodotto almeno una volta true e almeno una volta falso .
Si può quindi raggiungere la copertura del test delle condizioni eseguendo i seguenti cinque casi di test (ad esempio):
Ciascunodeib0,b1,b2,b3comparealmenounavoltacontrueealmenounavoltaconfalso.Inalcunicasiditest,nonciinteressaundatovaloreinquantononhaalcunainfluenzasullacondizionedicuivogliamoottenerel'output.
Addendum:coperturadecisionale
Perinciso,latabelladellaveritàmostraancheche"copertura decisionale" è stata raggiunta per questa decisione, poiché b_out si presenta almeno una volta con vero e almeno una volta con falso , quindi verrebbero coperti entrambi i rami di qualsiasi codice.
E ora la domanda
Che cosa significa "test delle condizioni" come sopra definito?
Non ti aiuterà affatto ad accertare la correttezza del predicato decisionale.
Che è meglio fare con un'ispezione di codice, lasciando che un secondo team scriva la stessa espressione e confronti gli output o esegua test case a "valori limite" (es. qui, per y = -4, - 3, -2).
Il controllo delle singole condizioni mi sembra più utile per testare l'ALU della CPU o magari testare l'output del compilatore. È certamente adatto per controllare manualmente il codice assembler scritto o verificare la logica assemblata manualmente.
E questo mi fa pensare che il "condition testing" potrebbe essere un residuo dei giorni in cui le condizioni erano effettivamente cablate sui pannelli (ad esempio in ENIAC ) e potrebbe quindi essere soggetto a errori di cablaggio. In questi giorni, la condizione è scritta in codice di alto livello ed è esattamente quella che vuoi concettualmente. Mentre la revisione potrebbe essere utile, un test della condizione è solo una perdita di tempo.
O mi manca qualcosa?
Addendum: ricerca della letteratura
Una ricerca della libreria IEEE Xplore per "test delle condizioni" produce solo due documenti rilevanti per il software (tutti gli altri sembrano rilevanti solo per l'hardware), entrambi di KC Tai del Dipartimento di Informatica della North Carolina State University.
Verifica di una di queste strategie di test del software basate sulle condizioni rivela che l'autore usa il termine condizione nel senso di decisione sopra, cioè in questo documento "condition testing" è in realtà "test decisionale". La condizione utilizzata nel sillabo TTA è chiamata condizione semplice . Sembra che le definizioni dei syllabus TTA non siano ampiamente utilizzate.
Dall'astratto:
A computer program consist of statements, such as IF and WHILE statements, that contain conditions, which are combinations of Boolean and relational expressions. A testing approach, referred to as condition testing, is to test a program by focusing on testing the conditions in this program. A number of condition testing strategies have been developed, but they are not effective for detecting errors in complicated conditions. In this paper, we define two condition testing strategies, based on the detection of Boolean and relational expression [i.e. expression of the form E1 op E2, where E1 and E2 are arithmetic expressions and op is one of six possible relational operators: < <=, =, !=, >, >=] errors in a condition. For these two condition testing strategies, we show some theoretical properties and explain why they are practical and effective for testing programs containing complicated conditions.