SlideShare a Scribd company logo
1 of 10
Download to read offline
PRUEBAS DE
SOFTWARE
TEMA 1
Prof. Magemyl Egaña
Se realiza para determinar y validar la
funcionalidad del software y que éste
cumpla realmente con los requisitos
funcionales y no funcionales.
Es una estrategia para comprobar los
atributos de un sistema (calidad del
software).
Es la disciplina para corroborar, validar y
verificar el software.
Verifica lo realizado en las fases anteriores.
Evalúa la calidad del producto de software a
lo largo de todo el ciclo de vida.
DEFINICIÓN
02
PRODUCTOS
03
1.PLAN DE PRUEBA PPR: establece la
planificación, organización y estructuración
de las pruebas.
2.CASOS DE PRUEBA CP: conjunto de
condiciones que determinan la calidad del
software.
RESUMEN DEL CICLO RCP: resumen de la
evaluación. Resultados finales de las
pruebas
ROLES
04
1.Supervisa el proceso de prueba.
2.Genera el resultado (medible).
3.Diseña los casos de prueba y
determina qué tipo, nivel y técnica de
prueba se va a aplicar.
4.Ejecuta las pruebas y peticiones de
cambio.
1
T
e
s
t
M
a
n
a
g
e
r
(
G
e
r
e
n
t
e
d
e
P
r
u
e
b
a
)
2
T
e
s
t
a
n
a
l
y
s
t
(
A
n
a
l
i
s
t
a
d
e
p
r
u
e
b
a
)
4
T
e
s
t
e
r
(
P
r
o
b
a
d
o
r
)
3
T
e
s
t
d
e
s
i
g
n
e
r
(
D
i
s
e
ñ
a
d
o
r
d
e
p
r
u
e
b
a
)
¿QUÉ CONSIDERAR AL
HACER LAS PRUEBAS DE
SOFTWARE?
•COSTO: Cuantificar el comportamiento del software.
05
•CONFIABILIDAD: Certificar que el software es lo
suficientemente confiable y acorde a los requesitos y
requerimientos.
•TIEMPO: Ejecución de las pruebas planificadas y
relacionas a la entrega del software.
•CALIDAD: Asegurar ausencia de defectos del software.
ATRIBUTOS
TIPOS
•Funcionales
•No funcionales
•Estructurales
•Relacionadas a cambio
06
NIVELES
•Unitarias
•De sistemas
•De integración
•De aceptación
TÉCNICAS
•Caja negra
•Caja blanca
•Caja gris
TIPO DE PRUEBAS
07
FUNCIONALES: dirigida al cumplimiento del caso de uso,
reglas de negocio, requisitos según la adecuación, exactitud,
interoperabilidad y funcionalidad.
NO FUNCIONALES: dirigida a probar los atributos no
funcionales como fiabilidad, usabilidad, eficiencia,
mantenibilidad y portabilidad. Pueden ser: pruebas de carga,
pruebas de rendimiento, pruebas de stress, pruebas de
estabilidad, pruebas de robustez, prueba de volumen,
pruebas de usabilidad.
ESTRUCTURALES: dirigidas a probar la estructura interna del
software basado en la arquitectura.
RELACIONADAS A CAMBIO: dirigidas a probar el sistema
cuando ha sufrido cambios o corregir un defecto o probar una
nueva funcionalidad.
NIVELES DE PRUEBA
UNITARIAS: dirigida a hallar defectos en un componente,
clase, unidad o módulo, dependiendo del lenguaje utilizado
en el proceso.
INTEGRACIÓN: dirigida a hallar defectos en varios
componentes o módulos y su comportamiento integrado y
detectar defecto en interfaz.
SISTEMAS: dirigida a hallar defectos en el sistema como un
todo, sometiendo al sistema a stress y evaluar su
desempeño, peticiones simultáneas, resistencia, seguridad,
validaciones, recuperación.
ACEPTACIÓN: dirigida al usuario, a su dominio técnico, a su
certificación y al cumplimiento de su requerimiento
08
TÉCNICAS DE PRUEBA
09
CAJA BLANCA: dirigida a validar las líneas de código
desde la entrada hasta la salida. Validar flujo del
código y que camino tomó la prueba.
CAJA NEGRA: dirigida a validar que el resultado de las
pruebas sea el esperado.
CAJA GRIS: es la combinación de técnica de pruebas
de caja blanca y caja negra.
.
PREGUNTAS
Y
RESPUESTAS
10

More Related Content

What's hot

Tema 3- T2: La ERS - Especificación de requisitos de software
Tema 3- T2: La ERS  - Especificación de requisitos de softwareTema 3- T2: La ERS  - Especificación de requisitos de software
Tema 3- T2: La ERS - Especificación de requisitos de softwareMagemyl Egana
 
ISTQB / ISEB Foundation Exam Practice - 6
ISTQB / ISEB Foundation Exam Practice - 6ISTQB / ISEB Foundation Exam Practice - 6
ISTQB / ISEB Foundation Exam Practice - 6Yogindernath Gupta
 
Modelo de desarrollo concurrente
Modelo de desarrollo concurrenteModelo de desarrollo concurrente
Modelo de desarrollo concurrentesamuel ospino
 
Ejemplo plan de_pruebas
Ejemplo plan de_pruebasEjemplo plan de_pruebas
Ejemplo plan de_pruebasnicolas2100
 
Caso de Uso
Caso de UsoCaso de Uso
Caso de Usoutrilla
 
Sesion5 requerimientos de software
Sesion5 requerimientos de softwareSesion5 requerimientos de software
Sesion5 requerimientos de softwareOscar López
 
Los 13 diagramas UML y sus componentes
Los 13 diagramas UML y sus componentesLos 13 diagramas UML y sus componentes
Los 13 diagramas UML y sus componentesVictor Escamilla
 
Esquema comparativo de los tipos de modelos y metodologías
Esquema comparativo de los tipos de modelos y metodologíasEsquema comparativo de los tipos de modelos y metodologías
Esquema comparativo de los tipos de modelos y metodologíasLeo Jm
 
Unit iii(part c - user interface design)
Unit   iii(part c - user interface design)Unit   iii(part c - user interface design)
Unit iii(part c - user interface design)BALAJI A
 
Istqb 2-소프트웨어수명주기와테스팅-2015
Istqb 2-소프트웨어수명주기와테스팅-2015Istqb 2-소프트웨어수명주기와테스팅-2015
Istqb 2-소프트웨어수명주기와테스팅-2015Jongwon Lee
 
Modelado de analisis para aplicaciones web
Modelado de analisis para aplicaciones webModelado de analisis para aplicaciones web
Modelado de analisis para aplicaciones webMaritzaD
 

What's hot (20)

Base de Datos Orientada a Objetos
Base de Datos Orientada a ObjetosBase de Datos Orientada a Objetos
Base de Datos Orientada a Objetos
 
Tema 3- T2: La ERS - Especificación de requisitos de software
Tema 3- T2: La ERS  - Especificación de requisitos de softwareTema 3- T2: La ERS  - Especificación de requisitos de software
Tema 3- T2: La ERS - Especificación de requisitos de software
 
ISTQB / ISEB Foundation Exam Practice - 6
ISTQB / ISEB Foundation Exam Practice - 6ISTQB / ISEB Foundation Exam Practice - 6
ISTQB / ISEB Foundation Exam Practice - 6
 
System testing
System testingSystem testing
System testing
 
Modelo de desarrollo concurrente
Modelo de desarrollo concurrenteModelo de desarrollo concurrente
Modelo de desarrollo concurrente
 
Ejemplo plan de_pruebas
Ejemplo plan de_pruebasEjemplo plan de_pruebas
Ejemplo plan de_pruebas
 
Caso de Uso
Caso de UsoCaso de Uso
Caso de Uso
 
Sesion5 requerimientos de software
Sesion5 requerimientos de softwareSesion5 requerimientos de software
Sesion5 requerimientos de software
 
Los 13 diagramas UML y sus componentes
Los 13 diagramas UML y sus componentesLos 13 diagramas UML y sus componentes
Los 13 diagramas UML y sus componentes
 
Diagramas UML
Diagramas UMLDiagramas UML
Diagramas UML
 
Esquema comparativo de los tipos de modelos y metodologías
Esquema comparativo de los tipos de modelos y metodologíasEsquema comparativo de los tipos de modelos y metodologías
Esquema comparativo de los tipos de modelos y metodologías
 
Unit iii(part c - user interface design)
Unit   iii(part c - user interface design)Unit   iii(part c - user interface design)
Unit iii(part c - user interface design)
 
Clase 12a uml_clases
Clase 12a uml_clasesClase 12a uml_clases
Clase 12a uml_clases
 
Istqb 2-소프트웨어수명주기와테스팅-2015
Istqb 2-소프트웨어수명주기와테스팅-2015Istqb 2-소프트웨어수명주기와테스팅-2015
Istqb 2-소프트웨어수명주기와테스팅-2015
 
Modelado de analisis para aplicaciones web
Modelado de analisis para aplicaciones webModelado de analisis para aplicaciones web
Modelado de analisis para aplicaciones web
 
Unidad 4
Unidad 4Unidad 4
Unidad 4
 
Diagrama UML Casos de Uso
Diagrama UML Casos de UsoDiagrama UML Casos de Uso
Diagrama UML Casos de Uso
 
analisis de aplicaciones web
analisis de aplicaciones webanalisis de aplicaciones web
analisis de aplicaciones web
 
Diseño caso de pruebas
Diseño caso de pruebasDiseño caso de pruebas
Diseño caso de pruebas
 
Modelo 4+1
Modelo 4+1Modelo 4+1
Modelo 4+1
 

Similar to Tema 1 -T3: Pruebas de software

Doo 13-testing
Doo 13-testingDoo 13-testing
Doo 13-testingJulio Pari
 
Curso Basico-Testing-03r003.pdf
Curso Basico-Testing-03r003.pdfCurso Basico-Testing-03r003.pdf
Curso Basico-Testing-03r003.pdfBarcodeBarcode
 
Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1naviwz
 
Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1Vanessa Toral Yépez
 
Estrategias de aplicación de pruebas
Estrategias de aplicación de pruebasEstrategias de aplicación de pruebas
Estrategias de aplicación de pruebasAldo Sánchez
 
Estrategias de aplicación de pruebas
Estrategias de aplicación de pruebasEstrategias de aplicación de pruebas
Estrategias de aplicación de pruebasAldo Sánchez
 
Estrategias de aplicación de pruebas
Estrategias de aplicación de pruebasEstrategias de aplicación de pruebas
Estrategias de aplicación de pruebasAldo Sánchez
 
Estrategias de aplicación de pruebas
Estrategias de aplicación de pruebasEstrategias de aplicación de pruebas
Estrategias de aplicación de pruebasAldo Sánchez
 
Unidad # 8 diseño de planes de prueba
Unidad # 8 diseño de planes de pruebaUnidad # 8 diseño de planes de prueba
Unidad # 8 diseño de planes de pruebaDarleneperalta
 
Pruebas de software
Pruebas de softwarePruebas de software
Pruebas de softwarepanavarrv
 
Ces cacic07-automatizacion y-gestion_pruebas_funcionales
Ces cacic07-automatizacion y-gestion_pruebas_funcionalesCes cacic07-automatizacion y-gestion_pruebas_funcionales
Ces cacic07-automatizacion y-gestion_pruebas_funcionalesginacris
 
Unidad 1_calidad del software
Unidad 1_calidad del softwareUnidad 1_calidad del software
Unidad 1_calidad del softwareraaf0001
 

Similar to Tema 1 -T3: Pruebas de software (20)

Doo 13-testing
Doo 13-testingDoo 13-testing
Doo 13-testing
 
Prubea de software
Prubea de softwarePrubea de software
Prubea de software
 
Curso Basico-Testing-03r003.pdf
Curso Basico-Testing-03r003.pdfCurso Basico-Testing-03r003.pdf
Curso Basico-Testing-03r003.pdf
 
Curso_Pruebas_ee v2.pptx
Curso_Pruebas_ee v2.pptxCurso_Pruebas_ee v2.pptx
Curso_Pruebas_ee v2.pptx
 
Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1Diseã±os de planes_de_pruebas_de_software1
Diseã±os de planes_de_pruebas_de_software1
 
ESTRATE
ESTRATEESTRATE
ESTRATE
 
Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1Diseños de planes de pruebas de software1
Diseños de planes de pruebas de software1
 
Estrategias de aplicación de pruebas
Estrategias de aplicación de pruebasEstrategias de aplicación de pruebas
Estrategias de aplicación de pruebas
 
Estrategias de aplicación de pruebas
Estrategias de aplicación de pruebasEstrategias de aplicación de pruebas
Estrategias de aplicación de pruebas
 
Estrategias de aplicación de pruebas
Estrategias de aplicación de pruebasEstrategias de aplicación de pruebas
Estrategias de aplicación de pruebas
 
Estrategias de aplicación de pruebas
Estrategias de aplicación de pruebasEstrategias de aplicación de pruebas
Estrategias de aplicación de pruebas
 
Unidad # 8 diseño de planes de prueba
Unidad # 8 diseño de planes de pruebaUnidad # 8 diseño de planes de prueba
Unidad # 8 diseño de planes de prueba
 
Pruebas de software
Pruebas de softwarePruebas de software
Pruebas de software
 
Ces cacic07-automatizacion y-gestion_pruebas_funcionales
Ces cacic07-automatizacion y-gestion_pruebas_funcionalesCes cacic07-automatizacion y-gestion_pruebas_funcionales
Ces cacic07-automatizacion y-gestion_pruebas_funcionales
 
Auditoria ii
Auditoria iiAuditoria ii
Auditoria ii
 
Auditoria ii
Auditoria iiAuditoria ii
Auditoria ii
 
Tipos de pruebas de software
Tipos de pruebas de softwareTipos de pruebas de software
Tipos de pruebas de software
 
Pruebas de software
Pruebas de softwarePruebas de software
Pruebas de software
 
Unidad 1_calidad del software
Unidad 1_calidad del softwareUnidad 1_calidad del software
Unidad 1_calidad del software
 
Pruebas
PruebasPruebas
Pruebas
 

Tema 1 -T3: Pruebas de software

  • 2. Se realiza para determinar y validar la funcionalidad del software y que éste cumpla realmente con los requisitos funcionales y no funcionales. Es una estrategia para comprobar los atributos de un sistema (calidad del software). Es la disciplina para corroborar, validar y verificar el software. Verifica lo realizado en las fases anteriores. Evalúa la calidad del producto de software a lo largo de todo el ciclo de vida. DEFINICIÓN 02
  • 3. PRODUCTOS 03 1.PLAN DE PRUEBA PPR: establece la planificación, organización y estructuración de las pruebas. 2.CASOS DE PRUEBA CP: conjunto de condiciones que determinan la calidad del software. RESUMEN DEL CICLO RCP: resumen de la evaluación. Resultados finales de las pruebas
  • 4. ROLES 04 1.Supervisa el proceso de prueba. 2.Genera el resultado (medible). 3.Diseña los casos de prueba y determina qué tipo, nivel y técnica de prueba se va a aplicar. 4.Ejecuta las pruebas y peticiones de cambio. 1 T e s t M a n a g e r ( G e r e n t e d e P r u e b a ) 2 T e s t a n a l y s t ( A n a l i s t a d e p r u e b a ) 4 T e s t e r ( P r o b a d o r ) 3 T e s t d e s i g n e r ( D i s e ñ a d o r d e p r u e b a )
  • 5. ¿QUÉ CONSIDERAR AL HACER LAS PRUEBAS DE SOFTWARE? •COSTO: Cuantificar el comportamiento del software. 05 •CONFIABILIDAD: Certificar que el software es lo suficientemente confiable y acorde a los requesitos y requerimientos. •TIEMPO: Ejecución de las pruebas planificadas y relacionas a la entrega del software. •CALIDAD: Asegurar ausencia de defectos del software.
  • 6. ATRIBUTOS TIPOS •Funcionales •No funcionales •Estructurales •Relacionadas a cambio 06 NIVELES •Unitarias •De sistemas •De integración •De aceptación TÉCNICAS •Caja negra •Caja blanca •Caja gris
  • 7. TIPO DE PRUEBAS 07 FUNCIONALES: dirigida al cumplimiento del caso de uso, reglas de negocio, requisitos según la adecuación, exactitud, interoperabilidad y funcionalidad. NO FUNCIONALES: dirigida a probar los atributos no funcionales como fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad. Pueden ser: pruebas de carga, pruebas de rendimiento, pruebas de stress, pruebas de estabilidad, pruebas de robustez, prueba de volumen, pruebas de usabilidad. ESTRUCTURALES: dirigidas a probar la estructura interna del software basado en la arquitectura. RELACIONADAS A CAMBIO: dirigidas a probar el sistema cuando ha sufrido cambios o corregir un defecto o probar una nueva funcionalidad.
  • 8. NIVELES DE PRUEBA UNITARIAS: dirigida a hallar defectos en un componente, clase, unidad o módulo, dependiendo del lenguaje utilizado en el proceso. INTEGRACIÓN: dirigida a hallar defectos en varios componentes o módulos y su comportamiento integrado y detectar defecto en interfaz. SISTEMAS: dirigida a hallar defectos en el sistema como un todo, sometiendo al sistema a stress y evaluar su desempeño, peticiones simultáneas, resistencia, seguridad, validaciones, recuperación. ACEPTACIÓN: dirigida al usuario, a su dominio técnico, a su certificación y al cumplimiento de su requerimiento 08
  • 9. TÉCNICAS DE PRUEBA 09 CAJA BLANCA: dirigida a validar las líneas de código desde la entrada hasta la salida. Validar flujo del código y que camino tomó la prueba. CAJA NEGRA: dirigida a validar que el resultado de las pruebas sea el esperado. CAJA GRIS: es la combinación de técnica de pruebas de caja blanca y caja negra. .