Functional Testing

Functional Testing
Juan C. Sacanamboy - Rubén Valencia - Julio Campaz

Agenda
1. Familia Functional Testing
2. Técnicas de la familia
a. Combinatorial Testing
b. Equivalence Partitioning
c. Exploratory Testing
d. Anti-Random Testing
e. Specification-based Testing
f. Boundary Value Analysis
3. Comparación respecto a otras familias
4. Posibles ambientes
5. Referencias
6. Preguntas

Familia Functional Testing
Son un tipo de técnicas de caja negra que
generan sus casos de pruebas a partir de la
documentación de los componentes de
software. Las actividades verifican una acción
o función específica del software.

Puede hacerse desde 2 perspectivas:
● Basado en requerimientos
● Basado en el proceso del negocio

Generalmente involucra 5 pasos
The identification of functions that the software is expected to perform
The creation of input data based on the function's specifications
The determination of output based on the function's specifications
The execution of the test case
The comparison of actual and expected outputs
To check whether the application works as per the customer need.

Combinatorial Testing (CT)
Se hace testing con un conjunto de pruebas
que cubra todas las combinaciones requeridas
en los valores de los parámetros.
Ventaja: Puede detectar fallas que se generan
por la interacción entre parámetros en el SUT
(Software Under Test).

Ejemplo: Juego en Internet
Parámetros = { Navegador, SO, Tipo de acceso
a la red, Gráficos, Audio, número de jugadores}
Interacción entre parámetros → Fallas

- Probar TODAS las combinaciones de los valores de los
parámetros → Poco práctico.
- La mayoría de combinaciones no producen fallos → Poco
eficiente.
El CT provee una manera práctica para detectar fallas con
una buena relación costo-eficiencia.

1. Crea casos de prueba seleccionando valores de los parámetros y
combinandolos para formar un covering array
Tomada de (Nie & Leung, 2011)

2. Usar el covering array como el conjunto de pruebas.
3. Cada parámetro no va a relacionarse con una falta y algunas faltas pueden
detectarse probando la interacción entre una cantidad pequeña de parámetros.
(Kuhn and Reilly, 2002) y (Kuhn and Wallace, 2004). Todas las faltas
conocidas son causadas por la interacción entre 6 o menos parámetros.
CT tiene un rendimiento próximo al testing exhaustivo pero usando una
cantidad reducida de casos de prueba.

4. No se requiere conocimiento de la implementación.Se requiere una
especificación mínima: parámetros y posibles valores.
5. La generación de casos de prueba puede ser automatizada → Amplia
aceptación en la industria

Falsa confianza
1. No se cubren todas las posibles combinaciones.
2. Si los parámetros y valores no son seleccionados correctamente, se
disminuirá la capacidad de CT para detectar faltas.
3. Si no se detectan todas las interacciones entre los parámetros, CT no
probará esas combinaciones.
Se debe aplicar CT sabiamente. En (Nie & Lieung,2011) se hace una
recopilación de 93 papers y se caracterizan de acuerdo a 8 temas.

1. Modelamiento (Model)
2. Generación de casos de prueba (Gen)
3. Restricciones (Constr.)
4. Caracterización de faltas y diagnóstico (Fault)
5. Mejoramiento de los procedimientos de testing y la aplicación de CT (App).
6. Priorización de casos de prueba (Prior.)
7. Métricas (Metric)
8. Evaluación (Eval.)

Notación
n parámetros
Cada tiene valores discretos de un conjunto finito
R es el conjunto de relaciones de interacción. Todas las interacciones existentes entre parámetros.
Conjunto potencia: Conjunto formado por todos los subconjuntos del mismo.

Ejemplo:
indica que todos los valores del parámetro en pueden generar una falla.
muestra que existen interacciones entre y . Esto quiere decir que todas las parejas
en pueden generar una falla.

Ejemplo práctico
n = 4
a1 = a2 = a3 = a4 = 3
V1 = {Netscape, IE, Firefox}
R = {{c1,c2,c3,c4}} → Todos los parámetros y sus combinaciones pueden afectar el juego.

Definición (Caso de prueba)
Una n-tupla (v,v,...,v) donde
12nes un caso de prueba de un SUT.
T→ Conjunto de todos los posibles casos de prueba.
all T⊆ { (v,v,...,v) | } =
all
12nV1 X V2X...XVn
Ejemplo juego: |Tall| = 34 = 81 casos de prueba

Definición (Esquema Valor)
La n-tupla (-,Vn1,…,Vnk,...) es llamada un esquema k-valor
(k>0), cuando algunos k parámetros tienen valores
definidos y el resto puede tomar cualquier valor permitido,
lo cual se representa con un “-”.

Ejemplo: Se detecta una falla con el caso de prueba t =
(Netscape, Windows, ISDL, Creative) que pudo haber sido
generada por:
-Un esquema de un valor en {(Netscape,-,-,-), (-,Windows,-,-), (-,-,ISDL,-), (-,-,-,Creative)}
-Uno de los esquemas de dos valores en {(Netscape,Windows,-,-), (-,Windows,ISDL,-), (-,-,ISDL,
Creative), (Netscape,-,ISDL,-), (-,Windows,-,Creative), (Netscape,-,-,Creative)}
24 - 1 = 15 posibles causas
2n - 1 esquemas

Definición (Arreglo Ortogonal) - OA
Un arreglo ortogonal (OA) de fuerza τ, es un arreglo Nxn con las
siguientes propiedades:
1. Cada columna i (1 ≤ i ≤ n) contiene solamente elementos del
conjunto Vi con ai = |Vi|
2. Las filas de cada sub-arreglo N x τ cubre todas las τ - tuplas de
valores de las τ columnas exactamente λ veces.
λ = N / (ai1...aiτ )

Orthogonal Array
Testing Systems → CT
(OATS)
-OA difícil de generar
-Conjunto de pruebas muy grande
Ejemplo
Arreglo ortogonal
τ = 2
N = 4

Definición (Covering Array)
Si un arreglo Nxn cumple las siguientes propiedades:
1. Cada columna i (1 ≤ i ≤ n) contiene solamente elementos del
conjunto Vi con ai = |Vi|
2. Las filas de cada sub-arreglo N x τ cubre todas las τ - tuplas de
valores de las τ columnas al menos una vez.
,entonces es denominado un covering array τ-way

τ-way testing
Es un tipo de CT que requiere que cada combinación de
cualquier τ valores de parámetros debe ser probada al
menos una vez.
τ = 1 → Estrategia de combinación Each Choice (EC)
τ = 2 → Pairwise testing (PW)
τ = n → Estrategia All Combination (AC)

Variable Strength Covering Array
R con elementos de diferentes tamaños

Métodos para la generación de casos de prueba
-One Factor One Time (OFOT) o Base Choice (BC)
t = (v1, v2,...,vn) → Caso de prueba
Reemplazar cada valor vi con los otros valores del parámetro ci uno por uno,
manteniendo los otros valores de t iguales.

-Simplified One Factor One Time Method (SOFOT)
t = (v, v,...,v) → Caso de prueba asignado
12nSe cambia cada valor en t uno por uno y se genera un
conjunto de casos de prueba
{tt = (*, v,...,v),tt = (v, *,...,v),...,tt = (v, v,...,*)}
1
2n2
1nn
12* → Valor permitido diferente al valor original en t

Ejemplo SOFOT
t = ( Netscape, Window s, ISDL, Creative)
Tst = { tt1 = (IE, Windows, ISDL, Creative), tt2 = (Netscape, Linux, ISDL,
Creative), tt3 = (Netscape, Windows, Modem, Creative), tt4 = ( Netscape,
Windows, ISDL, Digital)}

Diferentes conjuntos de pruebas de CT tienen
un cubrimiento y costo diferente

Running example: Pizza Ordering Application
Tomada de (Othman & Zamli,
2011)

Tomada de (Othman & Zamli,
2011)

24 = 16 combinaciones
Tomada de (Othman & Zamli, 2011)
τ = 4
Combinación Exhaustiva

Usando τ = 3
18,75% menos que la
combinación exhaustiva

Usando τ = 2
43,75% menos que la

Variable Strength Interaction
Usando τ = 2
Usando τ = 3
18,75% menos que la

Cummulative strength
Usando τ = 2
Usando τ = 3
12,5% menos que la

I/O Based Relations
Usando f1 = f(A,B,C)
Usando f2 = f(A,D)
43,75% menos que la

τ = 2 → Poco efectivo para sistemas con alta interacción de
parámetros.
Mayor interés en la generación de pruebas τ-way
Estrategias τ - way para la generación de casos de pruebas
-GTWay -IPOG
-Jenny - GA y GA-N
-AETG -Density

Estrategias Variable Strength Based para la generación
de casos de prueba
-SA
-ACS
-VS-PSTG

Estrategias I/O Based Relations para la generación de
casos de prueba
-Union and Greedy
-Test Vector Generatoro(TVG)
-Integrated T-Way Test Data Generator (ITTDG)
-Aura
-ParaOrder y ReqOrder

Integrated T-Way Test Data Generator (ITTDG)
Genera un caso de prueba de manera iterativa, añadiendo la mejor
combinación del valor de un parámetro (aquella que cubre la mayor cantidad
de tuplas sin cubrir) hasta que un caso de prueba esté completo y bien
formado.
La iteración continúa hasta que todas las tuplas hayan sido cubiertas (y el
conjunto de pruebas ha quedado bien formado).

Ejemplo: Multiplexor 4-1

Código Java
Mux 4-1
Tomada de (Othman &
Zamli, 2011)
En el experimento se va a comparar la efectividad
de uniform strength, variable strength e input output
based relations para la detección de fallas.
Se inyectan faltas la implementación en Java
usando MuJava. Se generan un total de 53
mutantes.
Luego se generan separadamente casos de prueba
usando las 3 diferentes estrategias para luego
destruir los mutantes usando la implementación de
ITTDG.

Usando un conjunto de pruebas generado por la estrategia Uniform
Strength
Se generan 5 conjuntos de pruebas de fuerza uniforme desde τ = 2 hasta τ = 6
(i.e. combinación exhaustiva).

Usando un conjunto de pruebas generado por la estrategia Variable
Strength
Usando un pairwise testing (i.e. 2-way testing) para todos los parámetros y 3-
way testing para los 4 primeros parámetros se eliminan todos los mutantes con
solamente 11 casos de prueba.

Usando un conjunto de pruebas generado por la estrategia I/O Relations
Based Relation
Analizando el esquema lógico del multiplexor, se puede deducir que hay 5
grupos de entradas que afectan la salida.

Situaciones recomendadas para su uso
En general, cuando la interacción entre parámetros puede generar fallas.
Por estrategia:
Uniform Strength Interaction: Cuando no hay mucho conocimiento del SUT.
Variable Strength Interaction: Cuando se sabe que los efectos de algunos conjuntos de
parámetros afectan en mayor medida la operación del SUT.
I/O Based relations interaction: Cuando el comportamiento I/O del SUT puede ser
establecido.

Equivalence Partitioning
Es muy común y ampliamente usada de
manera informal.
Consiste en dividir (particionar) un conjunto de
condiciones en grupos cuyos elementos se
consideran iguales.

Se evalúa un solo elemento de la partición. Si
está correcto, se considera que todos los
elementos de la partición lo están. De igual
forma en caso contrario.

Ejemplos
Una tienda en una ciudad ofrece descuentos de acuerdo al valor de la compra.
Tomado de http://www.softwaretestingmentor.com/test-design-techniques/equivalence-partitioning/

Ejemplos 3 clases de equivalencia
INT_MIN ≤ X+Y≤ INT_MAX, con
X ∈ {INT_MIN,...,INT_MAX} y
Y ∈ {INT_MIN,...,INT_MAX}

Ejemplos
Tienda de comestibles (http://users.csc.calpoly.
edu/~jdalbey/205/Resources/grocerystore.html)

Situaciones en las cuales es recomendado su uso
-Software con gran cantidad de datos de entrada, lo cual
puede generar grandes casos de prueba.
-Es aplicable en cualquier momento del desarrollo.

Exploratory Testing ET
La ET es aprendizaje simultáneo, diseño de prueba y ejecución de prueba.
En otras palabras, la ET es cualquier prueba en la medida en que el tester
controla activamente el diseño de las pruebas, como son llevadas a cabo.
Luego usa esa información obtenida durante las pruebas para diseñar nuevas
y mejores pruebas
Las ET son un potente enfoque, pero son ampliamente incomprendidas En
algunas ocasiones pueden ser mucho más productivas que una prueba con un
guión.

ET es una práctica profundamente situacional:
EJemplo: Rompecabezas
Características específicas que afectan ET:
-Misión de la prueba
-Misión de la prueba en particular
-El rol del Tester
-El tester(habilidades, talentos y preferencias)

-Herramientas e instalaciones disponibles
-Tiempo disponible
-Datos y materiales de prueba disponible
-Ayuda disponible de otras personas
-Cuál es la preocupación de los clientes del tester
-Estrategia actual de la prueba
-Estado de otros esfuerzos de prueba del mismo producto

-El producto en sí (interfaz,comportamiento,estado actual de la ejecución,
defectos, propósito)
-Lo que el tester sabe acerca del producto (que pasó en pruebas anteriores,
problemas conocidos, problemas pasados, fortalezas y debilidades, áreas de
riesgo y magnitud de riesgo percibido, cambios recientes, cómo se supone
debería trabajar, similitudes o diferencias respecto a otros productos)
-Lo que al tester le gustaría saber de ese producto

Los ET preguntan cuál es la mejor prueba que puedo llevar a cabo en este
momento. Las anteriores consideraciones influyen en lo que la prueba
necesita.
Estos factores cambian continuamente. Por lo que las ET pueden optimizar
todo este proceso, mientras que las secuencias de comandos tienden a ser
menos efectivas con el tiempo.

Las ET son también conocidas como pruebas ad hoc. Desafortunadamente, ad
hoc es muy a menudo relacionado con un trabajo descuidado y negligente.
1990 un grupo llamado Context.Driven school, inició el uso del término
exploratorio, para cambiar esta creencia.

Cuando usar ET:
En general, ET es usado en cualquier situación donde no es obvio lo que debe
hacer la próxima prueba, o cuando se quiere ir más allá de las pruebas
evidentes. Más específicamente las ET encajan en cualquiera de las siguientes
situaciones:
-Se necesita rápida retroalimentación sobre un nuevo producto o característica
-Se necesita aprender del producto rápidamente
-Ya se ha hecho una prueba usando scripts, y se busca diversificar la prueba

Cuando usar ET:
-Se quiere encontrar un simple e importante fallo en un tiempo corto
-Se quiere comprobar el trabajo de otro tester haciendo una breve
investigación independiente
-Se quiere aislar e investigar un defecto particular
-Se quiere improvisar en pruebas con un guión
-Se quiere escribir nuevos guiones de prueba
-Se quiere comprobar el manual de usuario con cada aserción.

Anti-Random Testing
En esta estrategia de prueba, cada prueba aplicada es elegida tal que su
distancia total de todas las pruebas previas es máxima.
La selección de cada prueba depende explícitamente de la pruebas ya
obtenidas.
Se usan la distancia Hamming y la distancia Cartesiana como medidas de
diferencia.

Anti-Random Testing
Definiciones formales usadas para la construcción de secuencias anti-random.
Se asume que todas las variables son binarias.
Anti-random Test Sequence (ATS): Es una secuencia de prueba tal que una
prueba ti es elegida, tal que satisface algún criterio respecto a todas las
pruebas aplicadas antes t0 ,t1 , … ,ti-1 .

Anti-Random Testing
Definición de distancia: Es una medición de lo diferente que son dos
vectores ti y tj.
Definición de distancia Hamming (HD): Es el número de bits en el que dos
vectores binarios difieren. No está definido para los vectores que contienen
valores continuos.
Definición de distancia Cartesiana (CD): la distancia cartesiana entre dos
vectores, A = {aN ,aN-1 , … ,a0} y B = {bN ,bN-1 , … ,b0} es dado por:

Anti-Random Testing
Definición de distancia total de Hamming (THD): Para cualquier vector es la
suma de sus distancias de Hamming con respecto a todos los vectores
anteriores.
Definición de distancia total Cartesiana (TCD): para cualquier vector es la
suma de sus distancias cartesianas con respecto a todo el vector anterior.
Definición de Maximal distance random test sequence (MDATS): Es una
secuencia tal que cada prueba ti es elegida para hacer la distancia total entre ti
y cada una de t0 ,t1 , … ,ti-1 máximo. Por ejemplo:

Anti-Random Testing
es máximo para todas las posibles elecciones de ti . Se usará HD y CD para
construir MHDATSs y MCDATSs.
Utilizando criterio de distancia máxima, cada vez que se intenta encontrar un
vector de prueba lo más diferente posible de todos los vectores aplicados
anteriormente. Así pues, el programa de pruebas de antirandom intenta
mantener la prueba lo más eficiente posible.

Anti-Random Testing
En este enfoque estamos utilizando la hipótesis de que si dos vectores de
entrada tienen sólo una pequeña distancia entre ellos a continuación, los
conjuntos de fallos encontrados por los dos es probable que tenga un número
de defectos en común. A la inversa, si la distancia entre dos vectores es
grande, entonces el conjunto de fallos detectados por uno es probable que
contenga sólo unos pocos de los fallos detectados por el otro.

Anti-Random Testing
Procedimiento 1. Construcción de un MHDATS (MCDATS)
Paso 1. Para cada una de las variables de entrada N, asignar un valor elegido
arbitrariamente para obtener el primer vector de prueba. Esto no da como
resultado ninguna pérdida de generalidad.
Paso 2. Para la obtención de cada nuevo vector, evaluar la THD (TCD) para
cada una de las combinaciones restantes con respecto a las combinaciones ya
elegidos y elegir uno que da la distancia máxima. Añádelo a el conjunto de
vectores seleccionados.

Anti-Random Testing
Paso 3. Repita el paso 2 hasta que se hayan utilizado todas las
combinaciones, o hasta que se han generado el número deseado de vectores.

Specification based testing
● Evalúan tanto el comportamiento esperado
como la funcionalidad.
● Para sistemas criticos.
○ Sistemas de trafico aéreo
○ Sistemas de diagnostico médico

● La especificación brinda las propiedades
que el programa debe satisfacer.
● La especificación debe hacerse en un
lenguaje formal de especificación.

● Dada una particular instancia de entradas
del programa con sus respectivas salidas,
se evalúa si el comportamiento del
programa cumple la especificación,
reemplazando las instancias de las entradas
y salidas en las variables de entrada y salida
de la especificación respectivamente.

Aunque este proceso de evaluación puede
variar dependiendo de la especificación, la idea
básica detrás del enfoque con que se haga, es
considerar un conjunto particular de elementos
en la especificación y calcular la proporción de
tales elementos que intervienen en la
evaluación.

Specification based Testing:
Specification
Hay 2 enfoques principales de especificación
funcional formal de software:
● Especificación basada en modelos.
● Especificación orientada a propiedades.
○ Axiomatica
○ Algebraica

Specification based testing:
Model-Based Specification
● Cobertura de especificación basada en
modelos:
○ como las escritas en Z y VDM, tienen dos partes:
■ Espacio de estados del software.
■ Operaciones requeridas en el espacio.

■ Espacio de estados:
conjunto de variables tipadas, con un
predicado que describe la propiedad invariante
del espacio de estados.

■ Operaciones requeridas en el espacio:
son especificadas por un conjunto de
predicados:
➢ precondiciones: condiciones de las
entradas.
➢ Postcondiciones: condiciones de las
salidas.

Model-Based Evaluation
● Se evalúa muy similar a como se hace con
cualquier expresión condicional en un
lenguaje de programación.
● Cuando una variable de entrada y una de
salida son reemplazadas con una instancia
de datos de entrada y salida, cada
predicado atómico puede ser falso o
verdadero.

● Cuando una variable de entrada y una de
salida son reemplazadas con una instancia
de datos de entrada y salida, cada
predicado atómico puede ser falso o
verdadero.

● Si el resultado de la evaluación de la
especificación completa es verdadero, la
correctitud del software con esa entrada es
confirmada.
● De lo contrario, se encontró un error en el
programa.

● El mismo valor de verdad de una especificación, puede
ser arrojado por diferentes combinaciones de instancias
de entradas y salidas para las variables.
● Se necesita de una prueba adecuada que cubra un
subset de combinaciones factibles de predicados.

● Se necesita de una prueba adecuada que
cubra un subset de combinaciones factibles
de predicados.

Boundary Values Analysis
El objetivo del análisis de límites es probar si
los bordes de un subdominio son correctos.
Entiendo subdominio como un conjunto de
datos que generan la misma computación del
programa.

La dimensión de un espacio de entradas es la
cantidad de variables asignadas en la
especificación.
Un borde de un subdominio en un espacio K-dimensional
es una superficie de dimensión K-
1.

Hay un método de pruebas formulado por
Cohen y White llamado Nx1 domain testing,
estrategia que requiere N casos de pruebas
para ser seleccionados en los límites de un
espacio N-Dimensional y un caso de prueba
por límite.

Boundary Values Analysis: Nx1
Adequacy criteria
Definición del criterio de adecuación de dominio de Nx1:
Sea {D1,D2,...,Dn} el conjunto de subdominios del software
S, que tiene N variables de entrada.
Un conjunto de casos de prueba T se dice que es Nx1
adecuado cuando, para cada subdominio Di, y cada Borde
B de Di, Existen al menos N casos de prueba, y al menos 1
caso justo al lado de B.

Boundary Values Analysis: Nx1
Adequacy criteria
Si el borde esta en el dominio de Di, el caso de prueba del
dominio debe ser un punto de prueba OFF, en caso
contrario un punto de prueba ON.
Este método apunta a detectar si hay errores de
desplazamiento en paralelo, en un borde lineal, donde un
criterio de adecuación de NxN puede detectar un
desplazamiento en rotación

Boundary Values Analysis: NxN
Adequacy criteria
Definición del criterio de adecuación de dominio de Nx1:
S, que tiene N variables de entrada.
Un conjunto de casos de prueba T se dice que es Nx1
adecuado cuando, para cada subdominio Di, y cada Borde
B de Di, Existen al menos N casos de prueba, y al menos
N casos linealmente independientes justo al lado de B.

Boundary Values Analysis: NxN
Adequacy criteria
Si el borde esta en el dominio de Di, el caso de prueba del
dominio debe ser un punto de prueba OFF, en caso
contrario un punto de prueba ON.
Este método apunta a detectar si hay errores de
desplazamiento en paralelo, en un borde lineal, donde un
criterio de adecuación de NxN puede detectar un
desplazamiento en rotación.

Es por esto que el criterio selecciona la posición
específicas de los Casos de prueba ON y OFF.
Se seleccionan vértices como casos de prueba.

Es por esto que el criterio selecciona la posición
específicas de los Casos de prueba ON y OFF.
Se seleccionan vértices como casos de prueba y sus
puntos cercanos.

Boundary Values Analysis: VxV
Domain Adequacy criteria
S, se dice que un conjunto de casos de prueba T es VxV
adecuado si, para cada Di se cumple que T contiene a los
vértices de Di, y por cada vértice V de Di hay un caso de
prueba justo fuera del vértice v. si el vértice v de Di esta en
el dominio Di, entonces el caso de prueba que esta junto a
V, debería ser un punto de prueba OFF, en caso contrario
ser un punto de prueba ON

Boundary Values Analysis: VxV
Domain Adequacy criteria
Este criterio es efectivo para la detección de errores en
dominios lineales, entiendo como lineal aquel dominio que
sus bordes son funciones lineales.
para dominios no lineales se aplica otro criterio.

N+2 Domain Adequacy Criteria
S, que tiene N variables de entrada. Un conjunto de
pruebas T se dice que es N+2 Adecuado si, para cada Di, y
cada borde B de Di, se cumple que hay al menos N+2
casos de prueba X1,X2,...,Xn+2 en T, tal que:

● cada conjunto de N+1 pruebas estan en posición
general, donde un conjunto de {xi
-> }contiene N+1
vectores en posición general, si los N vectores xi
->-x1
->,
N+1 son linealmente independientes.
● Hay al menos un punto de prueba On y uno Off.

● Para cada par de casos de prueba, si los dos son del
mismo tipo, deberìan ir en lados opuestos del
hiperplano formado por los otros N puntos de prueba.

Comparación respecto a otras
familias
Experimentación: Equivalence Partitioning vs. Branch Testing vs. Code
Reading. (Juristo et al., 2012)
El experimento se replicó varias veces en distintos lugares:
-5 veces en la Universidad Politécnica de Madrid (UPM01, UPM02, UMP03,
UPM04, UPM05).
-Universidad de Sevilla (UdS05)
-Universidad Politécnica de Valencia (UPV05)
-Universidad ORT de Uruguay (ORT05)

familias
El experimento usó tres programas escritos en C:
-cmdline: 209 LOC y complejidad ciclomática de 61
-nametbl: 172 LOC y complejidad ciclomática de 29
-ntree: 146 LOC y complejidad ciclomática de 21.

familias
Ninguna de las técnicas alcanzó el 100% de la
efectividad.
Media EP = 79.26%
Media BT = 78.43%
Media CR = 47.23%
Tomada de (Juristo et al., 2012)

familias
Efectividad de la técnica por programa
Tomada de (Juristo et al., 2012)

Posibles ambientes
● Combinatorial Testing
○ CTE XL
○ CTE XL Professional (Kruse et al., 2013)
● Equivalence Partitioning
○ Equivalence Partition Organizer (http://sourceforge.
net/projects/equivalencepart/)

Posibles ambientes
● Specification-Based testing
○ Choc’late

Referencias
● Nie Changhai, Leung Hareton. 2011. A Survey of Combinatorial Testing. ACM Computing
Surveys.
● Peter M. Kruse, Nelly Condori-Fernández, Tanja Vos, Alessandra Bagnato, Etienne Brosse,
(2013). Combinatorial Testing Tool Learnability in an Industrial Environment. ACM.
● Patrick J. Schroeder, Pankaj Bolaki, Vijayram Gopu, (2004). Comparing the Fault Detection
Effectiveness of N-way and Random Test Suites. ISESE’04.
● Kuhn, D. R. and Reilly, M. J. 2002. An investigation of the applicability of design of experiments
to software testing. In Proceedings of the 27th Annual NASA Goddard Software Engineering
Workshop (SEW’02).IEEE Computer Society, Los Alamitos, CA, 91.
● Kuhn, D. R. and Wallace, D. R. 2004. Software fault interactions and implications for software
testing. IEEE Trans. Softw. Engin. 30, 6, 418–421.
● Othman, R. and Zamli K. 2011. T-Way Strategies and Its Applications for Combinatorial Testing.
IJNCAA.
● Juristo N., Vegas S., Solari M., Abrahao S., Ramos I. 2012. Comparing the Effectiveness of
Equivalence Partitioning, Branch Testing, and Code Reading by Stepwise Abstraction Applied
by Subjects. IEEE Fifth International Conference on Software Testing, V&V.

Referencias
H. Zhu, P.A.V. Hall, and J.H.R. May, “Software Unit Test Coverage and Adequacy,” ACM
Computing Surveys, vol. 29, iss. 4, Dec. 1997.
Guide to the Software Engineering Body of Knowledge (SWEBOK),IEEE Computer
Society, v3.

Preguntas
1. ¿Cuál tipo de testing es un caso especial del Variable Strength Interaction Testing?
2. Con t = (Windows, Ethernet, Firefox) y V1= {Windows, Linux}, V2 = {Ethernet, Wifi}, {Firefox,
Chrome}. Genere los casos de prueba usando OFOT(One Factor One Time) y SOFOT
(Simplified One Factor One Time).
3. ¿Cuándo se recomienda usar el Uniform Strength Interaction? ¿Cuándo el Variable Strength
Interaction? ¿Cuándo el I/O based relations Interaction? Responda solamente dos.
4. ¿Qué es una prueba exploratoria?
5. ¿Cuando se usa una prueba exploratoria, diga 2 razones?
6. ¿Qué es una prueba Anti-Random?
7. ¿Que precondición se tiene que cumplir para poder hacer Specification-Based Testing?
8. ¿Cual es la dimensión del espacio de entradas?
9. ¿cuando se dice que dos entradas estan en el mismo subdominio?

Functional Testing

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Functional Testing

Ähnlich wie Functional Testing (20)

Mehr von Juan Camilo Sacanamboy

Mehr von Juan Camilo Sacanamboy (14)

Functional Testing