• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
U2T4 - Pruebas del Software
 

U2T4 - Pruebas del Software

on

  • 1,950 views

Presentación sobre pruebas del software. El documento que da soporte a esta presentación, puede ser solicitado en luiseduardo.pelaez@gmail.com

Presentación sobre pruebas del software. El documento que da soporte a esta presentación, puede ser solicitado en luiseduardo.pelaez@gmail.com

Statistics

Views

Total Views
1,950
Views on SlideShare
1,794
Embed Views
156

Actions

Likes
2
Downloads
0
Comments
0

4 Embeds 156

http://lepv.mdl2.com 88
http://www.softco.co 57
http://adrianapcardona.blogspot.com 8
http://www.blogger.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    U2T4 - Pruebas del Software U2T4 - Pruebas del Software Presentation Transcript

    • La prueba de Por otro lado, es de software es una las actividadesparadoja. Por un menos entendidaslado es conocida y aplicadas por todos su necesidad –Roger S- Pressman, 2005
    • 1: Concepción2: Objetivos3: Localización de la prueba4: Prueba vs Mantenimiento5: Tipos de prueba6: Niveles de la prueba7: Métodos8: Diseño de casos9: Algunos casos…
    • Software testing is the processconducted to provide stakeholderswith information about the quality ofthe product or service under test. Testtechniques include, but are notlimited to, the process of executing aprogram or application with theintent of finding software bugs(errors or other defects).
    • Pruebas (test): una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstanciaspreviamente especificadas, los resultados se observan y registran y se realiza una evaluación de algúnaspecto.Caso de prueba (test case): la documentación en la que se describen las entradas, condiciones y salidas deun de un diseño de caso de prueba.Defecto (defect, fault, bug): undefecto en el software como, porejemplo, un proceso, una definiciónde datos o un paso de procesamientoincorrectos en un programa.Fallo (failure): la incapacidad de unsistema o de alguno de suscomponentes para realizar lasfunciones requeridas dentro de losrequisitos de rendimientoespecificadosError (error): la diferencia entre unvalor calculado, observado o medidoy el valor verdadero, especificado oteóricamente correcto. Porejemplo, una diferencia de doscentímetros entre el valor calculado yel real.
    • 1: Concepción2: Objetivos3: Localización de la prueba4: Prueba vs Mantenimiento5: Tipos de prueba6: Niveles de la prueba7: Métodos8: Diseño de casos9: Algunos casos…
    • ••
    • Principios de la prueba del software•••••••
    • Principios de la prueba del software• Un buen caso de prueba responde al principio de formalidad de la prueba, y la formalidad exige planificación y diseño de pruebas.• La probabilidad de la existencia de más errores en una parte del software es proporcional al número de errores ya encontrados en dicha parte. Es un fenómeno difícil de explicar, pero la estadística así lo demuestra.••
    • 1: Concepción2: Objetivos3: Localización de la prueba4: Prueba vs Mantenimiento5: Tipos de prueba6: Niveles de la prueba7: Métodos8: Diseño de casos9: Algunos casos…
    • 1: Concepción2: Objetivos3: Localización de la prueba4: Prueba vs Mantenimiento5: Tipos de prueba6: Niveles de la prueba7: Métodos8: Diseño de casos9: Algunos casos…
    • Las pruebas de software no son parte del mantenimiento. Mas bien, impactan el desarrollo y el mantenimiento
    • La prueba afecta a ambas En cuanto al uso, éste implica evolución, lo que conduce al etapas del software (desarrollo mantenimiento en el código. El mantenimiento puede ser: y mantenimiento). La prueba durante el desarrollo puede • correctivo (corrección de errores que aún no habían sido afectar a cualquier fase, por descubiertos); ejemplo: se está probando el • adaptativo (cambio en el entorno cambio de rendimiento para producto y se detecta la una función dada, etc.); y omisión de un requisito, lo que • aumentativo (inclusión de nuevas funciones, etc.). Tanto el mantenimiento adaptativo como el aumentativo implican implica necesariamente, trabajar sobre código, lo que supone la definirlo, diseñarlo, implementa existencia de pruebas rlo y. por último, probarlo. Tangible Intangible Se construye/fabrica Se diseña/desarrolla Resulta un producto que se usa Su uso genera confianza Su uso genera desconfianza Hay deterioro No hay deterioro Se agota/caduca VenceSi el producto es software (lógico), el problema radica en que, en origen, el producto tiene fallos, pero nohay repuestos, y por tanto el arreglo debe realizarse sobre el mismo producto, pero como éste es lógico, elarreglo puede producir nuevos fallos: ¿por qué creer que cuando se arregla el software se está libre delfallo, si cuando se desarrolla no se es capaz de estarlo? Nuevamente, la respuesta se halla en cómo seprueba el producto.
    • 1: Concepción2: Objetivos3: Localización de la prueba4: Prueba vs Mantenimiento5: Tipos de prueba6: Niveles de la prueba7: Métodos8: Diseño de casos9: Algunos casos…
    • variety of testsvariety of stakeholders
    • Types Button-Up test Tipos prueba que consideran la revisión de componentes con visión de lo pequeño a lo grande, de lo primero hacia lo último y de manera jerárquica
    • Types Stand-alone test Tipos prueba que consideran la revisión de componentes de manera independiente visión futura de integración. Si funciona solo, luego funcionara con el todo.
    • ¿Cómo hace pruebas de software el ingeniero en la actualidad?
    • Tipos de pruebas en el desarrollo de so 1: Unitarias (Unit) 2: Integración (Integration) 3: Regresión (Regression) 4: Humo (Smoke or Ad Hoc) 5: Sistema (System) 6: Desempeño (Performance) 7: Carga (Load & Stress) 8: Volumen (Volume) 9: Recuperación (Recovery) 10: Almacenamiento (Store) 11: Requerimientos funcionales (Functional) 12: Interfaz (GUI Test) 13: Instalación (Install)A list of 100 types of Software Testing Types along with definitions. A must read for any SQA professional.
    • Tipos de pruebas en el desarrollo de so 1: Unitarias (Unit) 2: Integración (Integration) 3: Regresión (Regression) 4: Humo (Smoke or Ad Hoc) 5: Sistema (System) 6: Desempeño (Performance) 7: Carga (Load & Stress) 8: Volumen (Volume) 9: Recuperación (Recovery) 10: Almacenamiento (Store) 11: Requerimientos funcionales (Functional) 12: Interfaz (GUI Test) 13: Instalación (Install)
    • «Es la primera prueba realizada de todo el proceso depruebas y corresponde con la prueba de cada módulo delprograma. La realiza el propio programador en su entornode trabajo. Quizás, la única que por conducta generada, sepermite que haga el mismo programador» Centra sus actividades en ejercitar la lógica del módulo y los distintos aspectos de la especificación del mismo. Un error encontrado en esta fase provocaría un retroceso a la fase de diseño detallado e implicaría revisar la lógica y/o las especificaciones del módulo.
    • Los lenguajes han avanzadoen la asistencia a las pruebasunitarias, de tal manera que elprogramador no debainteractuar directamente conellas. Ejemplos de ellos son:Junit, PHPUnit,Microsoft.VisualStudio.QualityTools.UnitTestFramework.Nunit. “Testing cannot be expected to catch every error in the program: it is impossible to evaluate every execution path in all but the most trivial programs” - Microsoft, 1998
    • Prueba de la caja blanca
    • «La prueba de la caja blanca es un métodode diseño de casos de prueba que usa laestructura de control del diseño procedimentalpara derivar los casos de prueba.» • Prueba del camino básico • Notación del grafo de flujo o grafo del programa • Complejidad ciclomática • Prueba de bucles • Bucles simples • Bucles anidados • Bucles concatenados • Bucles no estructurados • Prueba de la estructura de control • Condición simple • Condición compuesta • Condición anidada
    • Tipos de pruebas en el desarrollo de so 1: Unitarias (Unit) 2: Integración (Integration) 3: Regresión (Regression) 4: Humo (Smoke or Ad Hoc) 5: Sistema (System) 6: Desempeño (Performance) 7: Carga (Load & Stress) 8: Volumen (Volume) 9: Recuperación (Recovery) 10: Almacenamiento (Store) 11: Requerimientos funcionales (Functional) 12: Interfaz (GUI Test) 13: Instalación (Install)